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

justchat_1 · 07-14-2009, 09:42 PM

Ok hopefully that title was enough to get your attention. I think something fully open source and written in managed code is long overdue. I'm a c# developer with ~7 years experience and own a full web server that can be used for source hosting/project planning/etc. There should be more then enough experience on these forums to pull this off.

My Goals for the project:

Well written efficient design
Fully Modular plugins on a shared framework and rendering engine
Fully Skinnable
Designed for 7" car screen with large buttons that can be used from a touch screen or other input devices
Internal SQL based database instead of text file craziness
Very fast lightweight media player plugin with full support for tag reading and storage
Native Navit Plugin
Native Bluetooth Plugin with support for everything - including the infamous LG phones
Native NextGen Speech Recognition (see domnitzsolutions.com for my other work)

What I don't wan't to see:

That com madness that other front ends seem to think is ok. You shouldnt need to install 5-6 programs just to get music, movies, nav and email.
Dll's and helper exe's all over the place to try to patch together something that could have been done much better from scratch

Looked around on the forums and haven't found anything even close. Oh and anyone thinking of posting a "just use riderunner" post - dont and save me a rant.

NSFW · 07-14-2009, 10:59 PM

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.

justchat_1 · 07-14-2009, 11:28 PM

Thats actually not a bad idea...not sure if you saw the link in my sig but I have heavy heavy experience in the fields that i feel are really lacking in the commercial front ends: bluetooth, a media player written from scratch and speech recognition like nothing else out there (once i get some money off it to pay for dev costs with streetdeck-ill open source the important code).

What im really in need of are some graphics guys. His skin idea looks pretty good my only concern with that approach is that the widget idea is unusable on a smaller screen and i would like to see media info on the bottom so it can be viewed when navigating or in other modules.

As far as the separate executables this is where i want to be a bit different. One of the coolest things with managed code is that you can compile a full application including its plugins into native code as its running. Each plugin runs in the same process but in its own application domain (seperate thread, seperate environment). If a plugin hangs or crashes it can be closed and restarted without any effect on the UI. The advantage though is that they are part of the same program with no comm overhead and can even share libraries. Plus being able to use mono and have this be open source and platform independent could be pretty cool.

Great Suggestions though....cheerleading in the right direction can be just as helpful as writing the actual code.

NSFW · 07-15-2009, 12:29 AM

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.

Crinos · 07-15-2009, 02:38 AM

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.

UnusuallyGenius · 07-15-2009, 05:18 AM

I would like to lend some GUI design assistance. I design graphics but have no programing experience beyond VBA. Here is a link to my thread. I think you are on track with my overall vision for a fe. http://www.mp3car.com/vbulletin/othe...ml#post1328134

malcom2073 · 07-15-2009, 05:31 AM

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.

justchat_1 · 07-15-2009, 10:39 AM

Crinos: I think you may have missed something here....I would count VLC as something that needs to be installed to get things working. It also would be slower due to having to use com to interface with it. The media player I have in mind is almost fully done and uses only c#, directshow and sqlite3.

UnusuallyGenius: I did see your thread but was under the impression it was aimed at powermate use (even the UI screens I saw seemed to be designed that way). Either way, graphics assistance would be great thanks for the offer.

malcom2073: I did see your app and I think it is probably the most promising one i've seen thats still in active development. I think we both see things mostly the same way - and you nailed my biggest problem with rr

. I thought I said it in the first post but just looked and guess I didnt - yes it will be GPL or something more open.

malcom2073 · 07-15-2009, 11:28 AM

I'm fairly decent at c# so if you need any help let me know I'd be willing to pitch in.

NSFW · 07-15-2009, 01:04 PM

Quote: 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).

Quote:

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.

2k1Toaster · 07-15-2009, 01:16 PM

I too am a fan of C#, but how are you planning on managing the graphics? Are you going to use the built in?

nalav · 07-15-2009, 01:24 PM

Yet another Windows based front end. Aren't there enough already? Supporting Linux could spark a bit more interest. Or maybe that's your plan and you just haven't mentioned it yet...

justchat_1 · 07-15-2009, 01:50 PM

nalav: How many other windows front ends require no other programs to be installed? How many others have native support for bluetooth (including the hands-free profile) and don't rely on external media players? How many are GPL'd?

2k1toaster: Thats the area i'm still looking for input on. I had considered using WPF but I think its a bit on the slow side and would rule out porting to linux or macOS. I've considered directx or opengl but building an engine from scratch is no easy task. I've considered a windows forms app with a skinning engine but dismissed that immediately. So i'm going to look at everyones input and we can weigh the pros and cons.

NSFW: you really know your stuff.

Quote:

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?)

The load does take time but if you load the plugins in the background the user never notices. Tricks like storing plugin info in the assembly info can make it even faster. Yea app domains require some method to cross the boundary which is more overhead then they help prevent. So i've actually rethought it and will probably use a thread manager type of system. Each plugin is called on a unique thread in the same appDomain which has its own error handling (one of the cool features of managed code) and the main thread (different from the UI thread) can kill any plugin that hangs or crashes.

Quote:

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

Like I hinted at above - absolutely true. I prefer doing a main/background thread, a UI thread and threads for each plugin. Should the main thread ever hang, the UI thread is still responsive and can restart the program.

Quote:

But then again I wouldn't personally put a video player of any sort in my front end. Waay too distracting.

Similar to streetdeck - video and other things you shouldnt be doing while moving are disabled when the gps indicates movement. To disable that functionality you need to accept the whole - your an idiot its not our fault disclaimer.

UnusuallyGenius · 07-15-2009, 03:53 PM

Quote: Originally Posted by NSFW

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

i so totally hate Outlook 2007, it freezes more than it is worth...still cant find a free single app that manages everything in one place like Outlook does...if you know of any free ones let me know(i'm cheap)

at justchat_1: i am so willing to lend my time to graphical design, i you want i will PM you my email for collaboration. and as far as my FE, i was originally going for the Powermate interface, but decided to do it more tailored to touchscreen to appease the masses.

2k1Toaster · 07-15-2009, 04:37 PM

Well I wrote my software in C# and the graphics just bogged everything down big time. So I switched to XNA (managed DX10 basically). It sucked. So I switched to OpenGL and could never get it stable. So I switched to DirectX, and it is not great, but it works.

If you want my code for DX, let me know.

User Name		Remember Me?
Password