Thread: Programming Interface standardisation?

Or one could design really independent apps chatting over a sharedmem structure.

I agree with you guys completely. That is the main reason why I started to write my own frontend. I hated the fact that if some new hardware/software product comes out, you need to update the frontend and bump the version up. That was my main drive to writing my software. For now I’m not willing to release my software to the carPC community yet cause I need to finish the Radio and TV plugins (currently I have plugins for Internet, GPS application embedding, DVD, Video, and MP3 with search features similar to itunes). That will be enough to be useful to most people. My hope is to make my front end scaleable and keep the shell code protected but release the plugins as open source to get people to write better plugins.

I’m not sure when I will release for Beta testing but it is working right now. I’m also writing a skin maker to help create the skins. And yes my front end will support BMP, ICON, GIF, JPEG, TIFF, WMF, EMF, PNG (transperent buttons YAY) and it will also support odd shaped Buttons so buttons aren’t always square and can overlap. As I see a lot of people complaining about that.

I haven’t been advertising my front end much cause I don’t want people to think its vaporware or anything. I’m very busy with my current job and I don’t want people hassling me on when its coming out. But if you guys have any questions about it, PM me.

If you guys do start to come up with a standard I’d like to put my 2 cents in since I have been working on my frontend for ~ 1.5 years and I ironed out quite a few problems already.

Oh and my frontend is written in C++ and is message based with the plugins. This makes the frontend very fast and robust when interfacing the core program with the plugins.

Cool. Some of your ideas sound similar to my own... Too bad it's C++. I'd rather stick with .NET. Oh well... either way I'm not entirely up to speed yet to be of much help.

I've written it in C++ cause I don't have .Net studio. but that doesn't matter cause the plugins can be written in almost any language. Basically the plugins are just DLLs so anything that can call DLL functions will work. I did it this way so people could write their plugins in VB, C, C++, or anything else that supports DLLs. So you can use .Net for plugins

i'm glad the idea of plugin flexibility is climbing. now that we have a decent selection of front ends, and apps to be used along with them, each piece can be interchanged.....i really like where this is going.

Originally Posted by Peoples

i'm glad the idea of plugin flexibility is climbing. now that we have a decent selection of front ends, and apps to be used along with them, each piece can be interchanged.....i really like where this is going.

To interchange would mean that they would have to have the same procedural calls..... unlikely.... very unlikely.

Say I have a rearcam cropped to 640*212 (roughly my rearmirror ratio) displayed in a subform, I have a hardware module that monitors car status (handbrake, rearlights) and a mp3player modules.

Now when moving back, how would the hardware module tell to video module to go fullscreen @ full res & tell to mp3player to mute ?

One should have a logic table to rule how independant modules interact with eachother.

Originally Posted by jmbickham

Actually I very much like your idea. I rate it higher than stuff like "skinning"...

"Skins" - good point....
IMHO "Skins" are as they are now (they are just bitmaps) are an uncomplete concept. The question: Are you adding bitmaps to your App's Form ? No you are not - you are adding ActiveX controls (Buttons, ListBoxes, Labels...) !
This M$ concept is really powerful as it merges "bitmaps" (graphic) with control logic.
So for our car usage the standard ActiveX controls shipped with Windows are not usable - but we could design our own ! (and yes this is done in all frontends but this code is merged inside instead of seperating into a ActiveX control )
So a "skin" would be a collection of ActiveX Control DLL's (and those need extern bitmaps - so they should also be there)

This concept is so powerful... imagine replacing the bitmap in the ActiveX control replaced with Flash.ocx !
Yes moving to Flash without touching the source of the plugin itself !

Originally Posted by Specimen

I agree with you guys completely. That is the main reason why I started to write my own frontend. I hated the fact that if some new hardware/software product comes out, you need to update the frontend and bump the version up...

Full ack.
I can't understand why anyone could include hardwaredrivers in a user application ??? Are printerdrivers in MS Office ???

Originally Posted by Specimen

That will be enough to be useful to most people. My hope is to make my front end scaleable and keep the shell code protected but release the plugins as open source to get people to write better plugins.

That is a good way for "commercial" frontends - and yeah I had the same idea.

Originally Posted by Specimen

Oh and my frontend is written in C++ and is message based with the plugins. This makes the frontend very fast and robust when interfacing the core program with the plugins.

Is "message based" early or late binding ? (example: CF uses early binding - Frodo uses late binding).
IMHO its important to use as much early binding as possible - as it improves handling for other developers.

.NET discussion:
Sorry guy but .NET is the only alternative IMHO - as there are a lot of different coders there are a lot of programming languages everyone could use (VB.NET, C# and Delphi .NET ? more?)

Originally Posted by Specimen

I don't have .Net studio.

No problem :
it's .NET
http://www.sharpdevelop.net/
may be its possible to migrate to C# ? (I think you as a C coder would prefer C# over VB ?)

Originally Posted by DeltaFX

Say I have a rearcam cropped to 640*212 (roughly my rearmirror ratio) displayed in a subform, I have a hardware module that monitors car status (handbrake, rearlights) and a mp3player modules.

Now when moving back, how would the hardware module tell to video module to go fullscreen @ full res & tell to mp3player to mute ?

One should have a logic table to rule how independant modules interact with eachother.

Hmmm....
The hardwaremodule has not anything to do with a module (Media, Navi, ...) (?) so it should be plugged into the main container (itself is also a plugin as it should be able to communicate with different hardware (CAN, IO-Board at parallel Port,...) ... It delivers information about iginition, selected gear, rpm, doors status ?

I see the following code in your rearcam plugin:

Code:

Private WithEvents moSystemIO As MainContainer.SystemIO
...
Private Sub moSystemIO_Gear(ByVal Gear As MainContainer.SystemIO.Gears) Handles moSystemIO.NewGear
   If Gear=Reward Then
        iMainContainer.RequestArea(me, 800, 480)
        iMainContainer.CommonVolume(20%)
   Else
        iMainContainer.RequestArea(me, 640, 212)
        ...
   End If
   ....
End Sub