Thread: An Open Source, Fast and Modular, C# Front End

Originally Posted by malcom2073

That's precisely how RevFE and nghost (if I recall correctly?) work.

nghost2 is a glorified message bus between components and plugins. But it doesn't do it quite how I would like. RevFE actually does it right IMHO. All RevFE's core does it load up plugins and allow communication between them. It's what gave me the idea for the multi-processed plugin system for nghost3.

Originally Posted by NSFW

It just occurred to me that a front end core could consist only of an event system, a plugin loader, and a set of APIs for shared resources: audio, (mixing and exclusive use when appropriate) display (skinning), phone, etc.

Which if you look at the wiki i have up is pretty much what this will do (with some exceptions). All plugins implement the same basic interface for their type (media player, navigation, etc.)- this is to ensure compatability with other plugins and between different versions of the same component (destinator, navit, etc.). Certain functions such as the media player are implemented to allow them to tell the framework what they can and cant handle (for example can play an mp3 cant play a dvd). The framework then passes the message between each mediaplayer plugin until it finds one that can. It can also be set to use certain plugins for certain media types.

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.

Hello,

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
- OBD
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...

Cheers
Borte

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.

Originally Posted by ws6vert

Just tried on an old sony vaio laptop. Everything looks fine, CPU load of about 15 up to 30 for repeated presses.

Computer Specs:
1.73 ghz Centrino processor
1 gig ram

Sweet.....thanks