Thread: .Net FrontEnd

it would be if it were coded with platform independence in mind, Will it run in linux? ( Using mono). Another good features would be radio fm and a way to control the cellphone ( phoco is not crossplatform) A guy here code one that is cross platform in c++ i think, and he used mplayer wich runs in windows and linux to. Also another great feture would be to implement what another guy also did "to have 2 separate displays and 2 separate audio outputs. I wanted the front display and sound tied together, and the rear display and sound tied together. That way, I could listen to my tunes, while the kids in the back seat could listen to thier own tunes, or watch a video."

As far as multi-platform, that probably won't happen, considering it takes advantage of some of the win32 functions and will eventually be compiled in WinFx. If mono will advance to where it simulates the WinFx libraries, then by all means i can be multi-platform, but at this point in time, its unlikely.

The rest is what makes the beauty of plugins apparent. Ideally you can implement/modify any feature you want into the program. Many plugins will be included with the program files(as i described), and others i will develop later as add-ons, or other people can implement them very easy as well to suit their/your needs.

Oh yeah, I am yet to implement the style engine and was wondering if anybody has any experience with the System.Windows.Forms.Design.VisualStyles namespace. Havn't really read over it that much but do you know if that namespace has the needed classes to style controls? From first glance it looks as if it does, but if anybody has any resources on it please let me know. All the style engines I've seen out there dont' have xml based files which are something i really want/need.

Originally Posted by gyro

Any progression ?

Little bit, havn't had much time to work on it. But the skinning engine is complete, the style engine is not. I also created a plugin manager form where you can view info on plugins, their status, speech commands linked with actions. You can also add speech commands to do specific functions here too.

Here's the first functional build of the plugin manager.

• The first tab obviously tells about the plugin.
• The second tab lists all the available action interfaces (for use with speech commands and skin layouts)
• The third tab just lists all the speech commands(and allows u to create speech commands)
• The fourth tab lists all the other plugins that the current plugin requires to work
• The fifth tab lists all the required controls for the main panel to be defined in the skin.
• And the sixth tab is a placeholder for a group of settings controls which would be part of the plugin.

The framework is just about done, now i just need to go on to designing the rest of the included plugins (ie media player, OBDII, etc). And skins for each of them.

Update...
Lately i've just been working on the plugins(ie media player, gps, etc) and so far i've just about finished the functionality of the mediplayer(no real skins yet). The media player is built directly from directshow (using a custom C# object oriented COM wrapper made by yours truely.) So no bundled winamp or wmp libraries.

A little about the media player...
Can play any file that your system can handle (thanks to directshow).
Can play and interact with DVD's (assuming you have a DVD codec such as PowerDVD)
It can play from any input devices(aka dv camera, tv tuner, etc)
Stores media id3 tags in a database(oledb) for speed.
Fully Skinnable.
Etc.

Originally Posted by zzachattack2

This is a .Net 2.0 based frontend,
...[*]Completely plugin based, with ability to manage plugins.
...[*]Allow plugins to interact with each other and load based on a dependancy algorithm.
...

Great work ! especially from the "plugin interaction" I want to know more !

Can you please also look at this thread:
Programming Interface standardisation?

Nice thread... those needs are why i started my project in the first place. Anyways pretty soon i'll be releasing the plugins interface, so people can start designing their own plugins if they would like.

The plugin interaction isn't too special, it just works a little like this...

All running plugins are inside a pluginhost. And every plugin inherits the Plugin class. So interacting with a plugin can be as simple as invoking a known member on a select plugin using reflection. Or... if you know the interface to a specific plugin, you can cast the select plugin to its known type and interact directly with it.

So say i have a OBDII plugin that needs to stop music during an error, all it does is find the mediaplugin in the pluginhost (either by its guid or name) and invokes a method such as "stop" using reflection. Or the other method is if the mediaplugin type is known, i can find that plugin in the host, cast it to the type mediaplugin, and interact with it directly.

Both methods have their benefits.