Page 1 of 5 12345 LastLast
Results 1 to 10 of 45

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

  1. #1
    Low Bitrate migrane's Avatar
    Join Date
    Apr 2004
    Location
    Windsor, Ontario
    Posts
    95

    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 Images Attached Images    

  2. #2
    FLAC jbors's Avatar
    Join Date
    Nov 2003
    Posts
    959
    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.

  3. #3
    Variable Bitrate NoPistonPC's Avatar
    Join Date
    Apr 2004
    Location
    Boston
    Posts
    360
    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)

  4. #4
    FLAC jbors's Avatar
    Join Date
    Nov 2003
    Posts
    959
    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.

  5. #5
    Low Bitrate migrane's Avatar
    Join Date
    Apr 2004
    Location
    Windsor, Ontario
    Posts
    95
    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

  6. #6
    Low Bitrate migrane's Avatar
    Join Date
    Apr 2004
    Location
    Windsor, Ontario
    Posts
    95
    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

  7. #7
    Banned eatyummypuppies's Avatar
    Join Date
    Feb 2004
    Location
    li, ny
    Posts
    439
    Quote 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?

  8. #8
    Low Bitrate migrane's Avatar
    Join Date
    Apr 2004
    Location
    Windsor, Ontario
    Posts
    95
    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

  9. #9
    Variable Bitrate NoPistonPC's Avatar
    Join Date
    Apr 2004
    Location
    Boston
    Posts
    360
    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)

  10. #10
    Low Bitrate migrane's Avatar
    Join Date
    Apr 2004
    Location
    Windsor, Ontario
    Posts
    95
    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

Page 1 of 5 12345 LastLast

Similar Threads

  1. Car 5.1 Dsp Options Vs Pc 5.1 Dsp
    By port20 in forum Car Audio
    Replies: 13
    Last Post: 05-29-2006, 03:10 AM
  2. Toyota 4-Runner Car PC (first attempt)
    By RP28FLA in forum Show off your project
    Replies: 11
    Last Post: 04-15-2004, 06:57 PM
  3. Car PC + Palm = ??
    By Wolfsburged in forum Newbie
    Replies: 1
    Last Post: 04-11-2004, 01:16 PM
  4. f/s : Car PC or HTPC
    By Bikr in forum Classified Archive
    Replies: 11
    Last Post: 04-08-2004, 03:57 PM
  5. About power Supply to PC in car
    By Sk8te in forum General Hardware Discussion
    Replies: 2
    Last Post: 11-11-2000, 11:39 AM

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
  •