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

Yay! Sync up with this guy and write the code to make his graphics real.
http://www.mp3car.com/vbulletin/rr-s...ndows-7-a.html

Are you familiar with the Scrum approach to software development? One of the key concepts is to sort your features by how valuable the are to the end user, work on them in that order. Simple idea, but since it seems like 9 out of 10 new front end projects never come to fruition I am compelled to bring it up.

If you can make a front end that does just one thing (e.g. music player), but does it really well, then maybe that will sustain interest in the project long enough to get all of the components built that are needed to get widely adopted. It would have more staying power than a front end has a sorta-decent music player and a sorta-decent phone support and sorta-decent OBD2, and so on.

While I'm here I'm also going to suggest separate executable for the main screen, the music player, the hands-free phone support, and so on. If one crashes, the others keep going and the dead one gets re-launched the next time the use selects that feature from the main screen. Plus it opens the door to competing implementations of each feature - if someone doesn't like your hands-free component, they can rewrite it (re-using your skinning, etc) without getting involved with the rest of the code, and users can swap out the executable for a specific feature when a better one comes along.

FWIW, I've also been doing C# for several years (and C++ for several years before that) but my employment contract forbids me from getting involved in projects like this. Kinda sucks, but I like my job. So I'm just here as a cheerleader.

I completely agree with you about Bluetooth lacking. It's one of the main things I wanted to do with my CarPC and I haven't gotten anything to work yet. BlueSoleil was next on my list to try but I'd love to have something that was really meant for CarPC use.

I've read a little bit about AppDomains but never used them... you're right, that does seem like a good mechanism for component isolation.

This is why I have started to write my own C# based frontend... I realy did not want a heap of coms and install ditt, before datt works and such.

Regarding dll's... I have found that using fmod for audio and therefore a dll is the easiest approach, instead of reinventing the wheel completely. Using the developer API you have FULL controll of everything, and as I know it... it's the best of what's available.

But I must admitt. I do plan to use VLC in my project for the video part.

First up for me, is to get the music part to work flawlessly.

Originally Posted by malcom2073

justchat: Check out RevFE in my signature. It is a lightweight, completely modular and skinnable frontend in c++ (which requires no extra components besides microsoft's runtimes) While I wish you luck, I did try this in c# first and I quickly ran out of CPU as c# runs much slower than native c++. Some lessons I have learned that I think it would be wise for you to integrate:

Thread the plugins. Whatever you do, do NOT load them using the assembly loader unless it is in a thread. If you do plugins in the main gui thread it will quickly slow down, and speed of UI is key.

Don't pass around data: Keep actual structures where they are created. For instance for the media player, I pass a list of songs, and when you click on a song I pass the index on the list of which one you clicked. The other way to do this would be to pass a Playlist class to the media player display which in c# would lead to lots of memory usage, and in c++ requires passing pointers around which is never a good idea.

Database: sqlite3 is wonderful, but use pre-prepared transactions. They are MUCH faster than sequential database executions. On the order of 10-20 times faster which in c# makes all the difference in the world.

Audio: FMOD isnt bad, but please do not use an external program like VLC. If users can unzip and USE your frontend rather than having to install stuff it would greatly increase the usability. Some frontends have completely missed this idea. *cough*RR*cough*

Documentation: I've actually been falling on my face on this one, but keep GOOD documentation for both skins and plugins. Write it as you put in features rather than saving it for later.

GPL: If you want to be open source, go GPL or go home. (I know most MS/c# people hate gpl) this ensures you will never pull a RR and will get you more support imo.

Just my two cents, I'll watch this and post some more as I think of things.

For stuff like UI development, C# is imperceptibly slower than native code, if you do it right. At my day job I am working on a server application that's 90% C# today, and was 100% C++ several years ago. We've learned some lessons about C# (actually I should say, about .Net) but generally speaking the perf cost is negligible. The biggest things to watch out for are garbage collection (don't go nuts with creating huge numbers of objects, unless they're very short lived, don't use string concatenation in a loop, etc) and reflection (use only when necessary).

Your plugin loading issue sounds like reflection... with native code you can quickly load a DLL and GetProcAddress a few things and you're good to go. With managed code, the loader needs to import a bunch of type information, which takes a while. You only need to worry about the load though. Once loaded, you can call into the plugs with no overhead. (I'm actually not sure if that last bit is true for AppDomains though - is serialization necessary to cross the AppDomain boundaries?)

Doing non-trivial operations on the UI thread is bad news in managed code or native code. Outlook 2007 is all native code and the UI thread locks up all the time because they completely failed to understand this point. All the goddamn time (I'm not bitter or anything).

Keep actual structures where they are created. For instance for the media player, I pass a list of songs, and when you click on a song I pass the index on the list of which one you clicked. The other way to do this would be to pass a Playlist class to the media player display which in c# would lead to lots of memory usage, and in c++ requires passing pointers around which is never a good idea.

You have to pay attention to the difference between reference types (passed by reference, much like passing pointers, costs almost nothing) and value types (passed by copying bytes from one place to another, cost is proportional to the number of bytes that need to be copied). Passing a Playlist will cost no more than passing a single integer if Playlist is a reference type.

I agree that GPL is the best way to make a project like this survive. It's kind of rare to see people contribute freely to a project whose license allows the original author to pack it all up and go home if they want. RR, being the dominant player, does get that kind of charity but IMO that just means that no new entry in this field will be able to do the same.

Personally I'd look into using Windows built-in support for playing music. But then again I wouldn't personally put a video player of any sort in my front end. Waay too distracting.