"stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
Former author of LinuxICE, nghost, nobdy.
Current author of Automotive Message Broker (AMB).
Works on Tizen IVI. Does not represent anyone or anything but himself.
The other half is the plugin host which contains the various event hooks, the rendering methods and some other good stuff. There is a system wide event hook, a powerchange event hook, a media event hook, a navigation event hook, etc. This allows plugins to only listen in to the events they need to and for multiple plugins to receive the same message. When an event is fired, an application can return true to indicate it has been handled and it will no longer be passed to other plugins. System Events are based on an enum which maintains compatability with older plugins but for features that are not implemented fast enough - there are functions for plugin to plugin string communication.
There is also what I guess you were calling the shared api, but in this case im calling it "The Framework". It contains a set of common functions and helpful methods that are shared between all the plugins and are guaranteed to work the same on every platform.
I'm over simplifying a bunch, and leaving out a bunch but hopefully that all sounds good.
Update - I've been pretty busy these past few weeks but I have some time off after the weekend which i plan on using to finish the graphics engine and get some code in the svn repository.
I've been working on some side projects when I have a few mins free and theres a pretty good chance they'll be developed during breaks between the main coding. One of which is the OBDII plugin for elm hardware (but of course since its open source its very easy to adapt to the others). Im putting together a vin decoding database so that the obd reader can query the car for a vin, use that to figure out make, model and engine and then communicate using manufacturer specific codes in addition to standard obd pids. Its about 50% complete but once I get to about 80% i'm going to wrap it in an app and move on to the next side project - the gaps should be easy to fill in by beta testers.
Also, should have a demo video of the speech recognition engine thats going to be ported over to openMobile up next week- it will be with streetdeck since thats the only front end with a nav interface designed well enough to really show off its potential but hopefully you guys can look past that.
I just discovered this thread after being absent from the forum for a while (summer vacation) and found it quite interesting.
A quick intro of myself: I've built myself a couple of frontends the last 5 years. 2 versions in VB and 3 in C# although only the vb ones made it into my car.
Creating the frontend in C# has also been a way for me to learn C# so I ended up with recreating the whole thing three times. But my basic ideas have always stayed the same (just the engine and coding practises that has gotten better).
Based on this I'd like to throw in my 5 cents for how a frontend should be structured...
- The main goal with the whole frontend should be that it's fast/stable for the user. The last thing anyone wants is something that keeps crashing when your using it in the car.
- It should be able to run "outta the box". Meaning that it should have basic functionality built in, but at a bare minimum. Less is more!! This would help users that just want to install and run. Other functionallity can be supported via plugins.
- It should be expandable / configurable to support tweakers/powerusers and to keep it ready for the future.
- Fully pluginbased!! No built in functionality bloating the code. All functions of the frontend should be a plugin.
- Built in editor! The program should have it's own built in skin editor (WYSIWYG) that runs the exact same code as the program it self. Also including a script editor.
Here's a example of how I would like the program structure to look like:
-> Main program <-
- Responsible for loading and managing plugins
- Passing of messages from and to plugins
- Passing of events to and from plugins
- Script engine: Use an already existing script engine in the actual skin language instead of trying to create a new scripting language for each frontend. I implemented Script.Net (C# scripting engine) in my frontend and it worked like a charm. Doing it this way gives the best from both worlds. You can create custom commands that can simplify some tasks while still giving the skinner the full power of the language.
-> Plugin: Graphical output module <-
- Responsible for presenting a canvas for plugins to draw on.
This would open up the possibility to have different graphical engines based on computer and skin demands. A low end computer could use GDI but with less eyecandy and a higer end computer could use WPF.
-> Other plugins <-
- Music player
- Video player
And so on... Extending functionallity is easy as long as it's plugin based.
I already have much of this programmed in C# for WPF with the exeption of the graphical output module. This was something that I came up with later. So right now it only supports WPF and is in a very early stage.
Hope this post made some kind of sence...
Failure is not an option...
The only full multizone / multiscreen cross platform open source Front End -> OpenMobile
Can someone with a nice slow machine give this a shot and tell me if the animation is smooth and if the CPU load is nice and low?
This is just a quick proof of concept for alpha blending and animations....should be platform independent - just requires .net or mono.
Just tried on an old sony vaio laptop. Everything looks fine, CPU load of about 15 up to 30 for repeated presses.
1.73 ghz Centrino processor
1 gig ram
Same results here on a 1.7ghz Pentium M with 1gb RAM.
Tested on my samsung N110 netbook as well. CPU load of about 12 to 25 on a intel atom 270 1.6 ghz with 1 gig ram.