Announcement

Collapse
No announcement yet.

RFC: new car pc app (sanity check ?!) :)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RFC: new car pc app (sanity check ?!) :)

    Hello all,

    Did a proof of concept hta (html application) to see how my car app would look like. I have used Macromedia tools to do the graphics and embedded a WMP control and another free winamp control that was working with an older version of winamp.

    Things look good so I want to take this a bit further and start with building a VB app that will load mht (web archive) files as skins. That is to say that you should be able to create a nice web ui with buttons some macromedia flash etc etc save it as an mht and then load that mht into a VB form using the IE control. There are ways of capturing the links pressed within that control and accessing the rest of the document from within the IE control (list of links, pictures, layers, sizes etc).

    Given a placeholder image in the mht I can then figure out the location where the WMP control needs to be overlayed or for that matter any other application that can be run within a picturebox.

    This will allow anyone to create a fully customizable skin and with the help of a config file assign a variety of actions to the "buttons" in the UI.

    Does this sound like a doable idea !? Do you see any gotchas that I might be missing ?! Technical feedback from all you MS coders out there as well as other comments or concerns are appreciated.

    thanks,
    Migrane.
    Attached Files
    ... you don't need eyes to see ... you need vision !!!

  • #2
    I would suggest to use another language. Just for curiousity.
    Or you can download sources for all vb apps out there and do not start from scratch at least.
    Save yourself some energy please.
    Best wishes.
    Golf IV, EPIA-ME6000 in dash, LCD in dash.
    Car pc integration with ease
    Car mediacenter

    Comment


    • #3
      Everyone wants to have their own bling-bling frontend for theit CarPC. Even with so many choices already out there (MediaCar, MediaEngine, FrodoPlayer, VOICES, etc...) people keep wanting to build new carpc software from scratch. It would be great to see an effort to build solid re-usable backend components and save the community from so much repeated work. Then when someone doesn't like an exisiting front-end they can whip out a new one in a matter of a few days by piggy-backing on the work of those that write and maintain the backends. This way we can have ONE solid GPS backend, ONE solid mp3 backend, ONE solid video backend, etc... Thay way it would be easy for all of us to work together to make those individual components ROCK SOLID.

      Having said that, I've done diddly squat to help with this effort, so I'll go back into my corner now...
      1994 RX-7, EPIA P4-ITX w/ Celeron 2.4 Ghz, Arise PSU, Xenarc 700TSV (new model)

      Comment


      • #4
        I think most of the tools you mentioned using the same _solid_ backend: ActiveX. That's why they're using VB.
        I would do it the same way though if I would agree to give up to m$ completely.
        Car pc integration with ease
        Car mediacenter

        Comment


        • #5
          jbors: Please post some pics of your setup.

          NoPistonPC: I totally agree with that although the trend seems to be that the apps are kept closed source and at the present time lack the flexibility and to be honest the "bling-bling-ness" that I am looking for.

          Building a framework that would enable someone to create his own skin and position/control some plugins/apps would be great.

          Still looking for comments with regards to that maybe we can whip up an action plan to aim for the above. From what I have seen so far there are alot of skilled ppl in here that can chip in to the collective effort

          Migrane
          ... you don't need eyes to see ... you need vision !!!

          Comment


          • #6
            jbors: I have explored the Linux route for this application because that is what I am more comfortable with. But, as much of a Linux g33k as I am I must admit that the hardware support, ease of integration and available software are just not there yet in Linux.
            No real gps software in linux unfortunately, XFree performance sux etc. etc.

            Migrane
            ... you don't need eyes to see ... you need vision !!!

            Comment


            • #7
              Originally posted by NoPistonPC
              Everyone wants to have their own bling-bling frontend for theit CarPC. Even with so many choices already out there (MediaCar, MediaEngine, FrodoPlayer, VOICES, etc...) people keep wanting to build new carpc software from scratch. It would be great to see an effort to build solid re-usable backend components and save the community from so much repeated work. Then when someone doesn't like an exisiting front-end they can whip out a new one in a matter of a few days by piggy-backing on the work of those that write and maintain the backends. This way we can have ONE solid GPS backend, ONE solid mp3 backend, ONE solid video backend, etc... Thay way it would be easy for all of us to work together to make those individual components ROCK SOLID.
              I've been thinking about this a lot during the past few weeks, skimming over some application planning & development books, drawing flow charts, etc. I've come to the conclusion that the ideal application would simply be a holder for several plugins; a skeleton of an actual media player, just as you described.

              In planning this, you realize that you could simply let each plugin have its own form, but that would require skinners to skin every plugin, which is not very efficient. We've seen other applications like that. Another idea I was playing with was to have a several different types of forms that would accomplish nearly anything you could want in a carputer system, but this gets complicated; when the plugins are using something like a Mappoint control, you would have to pass all the graphics to the front end. It quickly becomes a mess.

              So herein lies the dilemma: how to abstract the front end (skins) from the plugin system.

              What I've come up with so far is a "control-based skin". ie. Skinners would make a skin for several types of controls (ex: text boxes, list boxes, command buttons, maybe several user controls) along with a few back ground images. This would solve the problem. This is pretty much what Windows does, we would just make a simplified version of it for a smaller number of controls.

              I was planning on discussing this with Carcomp for the next version of MediaEngine as I'm supposed to be contributing to that project. Well, what do think Carcomp?

              Comment


              • #8
                Is this a good time to ask everyone that can contribute to elaborate on some technical ideas ?!?

                Lets start with some suggestions on the following:

                - skinning
                - mp3 player (id3 tags, indexing,playlists, visualisation)
                - video/dvd player
                - tv/fm tuner
                - audio mixer
                - gps app integration
                - obdII ?!
                - phone control

                lets put the nuts and bolts on the table and see what we can piece together

                Migrane
                ... you don't need eyes to see ... you need vision !!!

                Comment


                • #9
                  I'm going to try to explain my take on all this. This is more for my benefit than anything else, so I can wrap my head around this.

                  There are different approaches one can take to building a CarPC frontend. One is the "top-down" approach, and the other is the "bottom-up" approach.

                  People advocating the "top-down" approach think first about all the functions an application may need to perform and how the application will look and flow as a unified front-end for these functions. They might consider ways to support skinning of this front-end and even ways to extended it's functionality. They think of the guts behinid the front-end as a set of plugins that "fill-out" the skeleton. A popular example of this way of thinking is WinAmp. WinAmp provides a skinnable front-end and a core set of front-end interfaces (play, stop, pause buttons, volume control, a plug-in configuration screen, etc...). Developers can then go and fill-in this skeleton by writing plugins to handle various sound formats and create new functionality within the front-end framework created by NullSoft. However, although the look of WinAmp can be changed, the workflow of the application (or what kinds of actions you can perform through the front-end interface is fixed). For instance, there is no way to squeeze in a "play-at-twice speed" button between the play and FF buttons.

                  Alternatively, people advocating the "bottom-up" think first about INDIVIDUAL functions an application must perform. For instance, they will determine that an application might require the ability to play mp3s, while someone else might decide they want to tune a radio channel. They don't bother worrying about what else the application may need to do (like GPS or checking weather, etc...) and they definitely don't worry about how it will look like to the user. So they immediately set out to write code to read an mp3 file and control playback while the other guy writes code to tune a radio. They might package this code into individual programs or they might decided to compile them into libraries. They will probably have a completely different command-line interface. They release these packages to the public either as open-source or as closed-source binaries. A year later, someone else might come along and write a program that talks to your GPS device and plots your position on a map. Note that none of these programs have a user interface or if they do, they also release a library that lets you access their core functionallity without using the UI. The great thing about this situation is that eatyummypuppies can come along and decide he wants to create an application that controls mp3 playback, tunes his radio, and plots his position on a map. So he creates a quick a VB wrapper for each of these programs and pulls them together into his skinnable CarPC interface he creates. Migrane on the other hand, just wants to create a kick *** mp3player, so he just takes the mp3 module and makes a web archive based mp3 interface. Both of these guys don't have to worry about how to load an mp3 file or fast forward through it. Now the cool part is that if migrane finds a bug in the mp3 code he's using, he can tell the original author to fix it. When the author releases the next version of this mp3 code, eatyummypuppies's player will also automatically have that same bug fixed when he get the latest version of the mp3 code. A good example of this "bottom-up" way to think about things is the program AutoGordianKnot that puts a nice user-friendly front-end to multiple stand-alone tools like AVISynth, VobSub, DeComb, etc...:



                  Neither approach is perfect, but I feel for the purpose of a CarPC front-end, which is really a bunch of separate tools brought together into a unified interface, the bottom-up approach makes more sense. So I say this: let's not worry about the UI and skins and plugins. Instead, let's figure out what functionality we want in an mp3 player, video player, radio tuner, xm tuner, GPS navigator and go about building these components as individual building blocks whose functionality can be accessed through command-line calls, over TCP/IP sockets, or as DLL calls (anything not requiring a UI). This way, the MediaCar, MediaEngine, FrodoPlayer and all the other guys can focus on building a nice looking UI for these programs instead of repeating each other's work (some of them are already doing this for GPS by using the destinator SDK, we just need to build similar things for mp3s, radios, etc...). And, eatyummypuppies can build his skinnable framework and migrane can use his web archives to build their UI to their personal tastes. When the guys that wrote the core back-end programs fix a problem or add a features, EVERYONE's frontends will benefit.


                  Plan of action:

                  1) get more developers on mp3car.com to buy into this (i think a lot of them already are from the posts that I read by the linux guys)

                  2) figure out what stuff is already out there so we don't re-invent the wheel. We'll probably find that most of the work is already done. I'm not sure which of the existing front-ends are open source but we might just be able to pull out mp3, video, and radio code from them and package them up into separate components.

                  3) package things up and create simple command-line, socket, or DLL interfaces that makes sense for CarPC UIs to use. By simple interface I mean provide a simple function like "void CreateMusicDatabase(String musicPath)".


                  Holy ****! i just saw how much crap I wrote... okay, this is making me sick. I need to take a break from this forum for a while.


                  EDIT: Okay, i was just thinking about this and I think a lot of the windows-based CarPC front-ends already use the bottom-up approach. Most of the code is really front-end glue for components like WinAmp, Destinator SDK, PowerDVD, etc. I guess the stuff I was blabbing about probably applies more to Linux where less software is available that provides the functionality of the basic CarPC components.
                  1994 RX-7, EPIA P4-ITX w/ Celeron 2.4 Ghz, Arise PSU, Xenarc 700TSV (new model)

                  Comment


                  • #10
                    Thanks NoPistonPC and eatyummypuppies for the elaborate replies

                    Reading your post reminded me of a book (Object-Oriented Design Heuristics by Arhur J. Riel) I tend to refer to when I'm in need of a "paradigm alignment"

                    I think you have touched on a couple of heuristics that probably yield a good design:

                    QUOTE

                    - Users of a class must be dependent on its public interface, but a class should not be dependent on its users.
                    - Do not put implementation details such as common-code private functions into the public interface of a class.
                    - A class should only capture one and only one key abstraction.

                    END QUOTE

                    In our case replace class by plugin/component and I think we'r on the right track.

                    Looking for some more oppinions, suggestions, comments or concerns as well as concrete suggestions for apps to fulfill specific tasks (console/lib based mp3 player etc)

                    Migrane
                    ... you don't need eyes to see ... you need vision !!!

                    Comment


                    • #11
                      I am releasing my xm ActiveX for this very purpose, any of the developers here will be able to use it. No UI, Nothing but straight code calls.

                      Frodo
                      [H]4 Life
                      My next generation Front End is right on schedule.
                      It will be done sometime in the next generation.
                      I'm a lesbian too.
                      I am for hire!

                      Comment


                      • #12
                        Now, THAT is what I'm talking about!
                        1994 RX-7, EPIA P4-ITX w/ Celeron 2.4 Ghz, Arise PSU, Xenarc 700TSV (new model)

                        Comment


                        • #13
                          NoPistonPC,
                          My initial concept was actually what you’re describing, thinking that it would result in a hundred front ends in Flash, HTML, Java, VB and any other language. But I later realized that it can never work.


                          Alternatively, people advocating the "bottom-up" think first about INDIVIDUAL functions an application must perform.
                          We’re not talking about Gordian knot here. A carputer system will have more than simple text data to pass to and from the plugin architecture. Sure this would work to play and stop music, or to check the status of shuffle, but how would a plugin that itself has no front end utilize an Activex control? Again, the Mappoint control is a good example. And Activex controls wouldn’t be the only limitation.


                          For instance, there is no way to squeeze in a "play-at-twice speed" button between the play and FF buttons.
                          My whole point was how to separate the front end from the plugin architecture. Keep in mind that this discussion describes the very highest level of design. To clarify the distinction between plugin and front end in my system: each plugin would have its own form or forms, described by the creator of the plugin. Instead of skinning the entire plugin form(s) (Winamp 2.x) or completely abstracting the front end from the plugin (Gordian Knot), the line will be drawn at control level. We’ll benefit partially from each method. Since buttons would have their own skins, your additional button could easily be implemented in a configuration file by defining its position and function.

                          The parameters of each plugin, I think, would be handled by the main application in XML. This would fit naturally with a few multi-tier plugins. For example, a “media” plugin could have “sub-plugins” for Winamp or Mediaplayer, which would result in a single interface for both applications. But I don’t want to scare anyone; that could be dealt with much later in the project.

                          And yes, I think all functions of a plugin should be accessible from TCP/IP, command line, etc. This would be accomplished in a similar way to girder, athough, I’m not certain exactly how this will work yet.

                          Comment


                          • #14
                            Maybe we should split this thread up so poor migrane can have his thread back?

                            My first post would probably be a good spot since I quoted NoPistonPC.

                            Comment


                            • #15
                              Originally posted by migrane
                              Is this a good time to ask everyone that can contribute to elaborate on some technical ideas ?!?

                              Lets start with some suggestions on the following:

                              - skinning
                              - mp3 player (id3 tags, indexing,playlists, visualisation)
                              - video/dvd player
                              - tv/fm tuner
                              - audio mixer
                              - gps app integration
                              - obdII ?!
                              - phone control

                              lets put the nuts and bolts on the table and see what we can piece together

                              Migrane
                              You forgot One thing. Integrate own section with 8 buttons that controles 8 ports in pararell ports in the PC... (so yu can use it to sett on/off neon under the car, int the trunk and so on....)
                              Project done in: [####################] - 85%
                              - Custom center console
                              - Custom trunk
                              Se my project here

                              Comment

                              Working...
                              X