Page 1 of 25 1234567891011 ... LastLast
Results 1 to 10 of 241

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

  1. #1
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359

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

    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.

  2. #2
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    301
    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.

  3. #3
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    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.

  4. #4
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    301
    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.

  5. #5
    Maximum Bitrate Crinos's Avatar
    Join Date
    Mar 2009
    Location
    Kristiansand, Norway
    Posts
    489
    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.

  6. #6
    Variable Bitrate UnusuallyGenius's Avatar
    Join Date
    Mar 2009
    Location
    Grand Rapids, Mi
    Posts
    306
    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
    - Project: Unified Car Control
    - Original OpenMobile Interface Designer

  7. #7
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    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.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

  8. #8
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    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.

  9. #9
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    I'm fairly decent at c# so if you need any help let me know I'd be willing to pitch in.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

  10. #10
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    301
    Quote Originally Posted by malcom2073 View Post
    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.

Page 1 of 25 1234567891011 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •