No announcement yet.

.Net FrontEnd

  • Filter
  • Time
  • Show
Clear All
new posts

  • .Net FrontEnd

    This is a .Net 2.0 front end. Features have changed tremendously and this post will be updated when appropriate.

  • #2
    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."


    • #3
      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.


      • #4
        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.


        • #5
          Any progression ?
          Car : Hyundai Tucson
          Carpc :
          Lilliput 7" touchscreen indash 90% done
          PSU : M2-ATX
          Epia M10K /512DDR/80GB Maxtor
          Software : Windows XP Pro 100% done
          RR with DigitalFX skin
          In car : 80% done


          • #6
            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.


            • #7
              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.
              Attached Files


              • #8
                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.


                • #9
                  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:


                  • #10
                    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.


                    • #11
                      After some consideration I decided to drop the style engine. If I/You want the skins to have a better look than the base windows gui, there are plenty of free control libraries out their. I will probably release my own control library in the future, but the style engine seems like a bit overkill. Also im planning on making a skin-designer, similar to that of visual studios form designer.


                      • #12
                        I've been following this thread off and on for several months. I was afraid it had gone dead.

                        Glad you hear you've made some significant progress.

                        What is your timeline right now as far as making this available for people to start working with it?

                        Looks awesome so far.


                        • #13
                          thanks for the interest. Im glad some people are interested. anyways, i'm hoping to release the interface sometime in the next month. I just need to finish up some basic testing, documentation, and a couple features.


                          • #14

                            How about calling this "Car.Net"?

                            I'm looking forward to seeing your code.


                            • #15
                              Thanks for the idea.

                              I thought I'd tell a little about the skinning...
                              Im pretty much done with the skin engine and added a few more features which include:

                              1. At the top of each skin file a "required assembly" tag is required (similar to those "using" statements in a code file). This is because the engine is completely reflection based, so at the start of parsing the skin it creates a collection of all objects inheriting control in each assembly. This allows for you to add custom controls in your skin. So if you want to add Control123 thats in Controls.dll, just add that assembly to the required assemblies group and your done. Just call control123 like any other control and assign any property.

                              2. Also I was thinking, if people create their own controls to use in skins, they might have types of properties that require special processing to assign them. So the skin now has a collection of delegate references (SkinReaderTypes) which will convert the base string value from the xml file into whatever type necessary. Say you have a property that needs to hold some type of binary sound data, obviously you can't store that in the skin file, you could just write "sounddata.wav" for the value and then in your plugins constructor add a new SkinReaderType to the skin which will allow the skinreader to convert the file name into the sound data. I know there isn't any specific information here on how to do this, but I'm just giving you the idea. The skin reader already has all the basic skinreadertypes (int, long, float, double, Bitmap, Image, Color, Font, ANY enum, etc).