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

Now, THAT is what I'm talking about!

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.

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.

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

Originally Posted by Goose

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

How much are those things? Are they pretty easy to write software for?


Ok, this is probably a bad time to say it but...I'm writing my own carpc software in vb also. It was just because all of the players out there have excess crap I don't need...I want minimal. So after I get through with it I'm going to release the source code for it. I don't want to try to take the time to customize it for every persons whim blah blah blah so I'm going to just give them the code and let them make it like they want it.

If everything was open source people would easily be able to slap together a carpc software that works just like they want it to. I'm willing.

damnit why do i always get to be the first one on the second page?!

Hi grayscale

Where are you on this project?

If Coyotee were still around and released MC we could do, like you say. Instead I spend hours message about getting things to work by jumping thru hoops when it would be really easy in the MC app. I just dont want to reinvent the wheel.

I have my graphics all done. And the winamp controlling and the DVD/Divx Part halfway through. I still haven't set up a database for the playlist. If i can somehow read a m3u file in VB (haven't tried yet) then that would be unnessary because the title and all that stuff is embedded into it. So I need to get GPS, Radio, and probably parallel relay control done.

The interface is minimal. It's in grayscale because I obviously like grayscale . The lines are thick because I figured on the LCD it's harder to see. I have yet to see this on my LCD, but if I notice anything needs to be changed due to being unable to see things etc I will. I MIGHT evenutally add a little color lol. Also, I haven't tried to use my LCD in 800x480 but if I can get widescreen then I'm going to redo my interface a bit. The two down arrows in the applications box will drop down a more extensive list of apps to run which will then run in a picturebox in another screen which still has limited music control. The genre dropdown actually will just point to a few sub directories in my music folder such as rock techno bass hardcore etc...here you go

btw for now I've stolen frodoplayers buttons...I hope you don't mind frodo?

damnit why do i always get to be the first one on the second page?

It's not as bad as having the last post on the page before. Nobody ever sees those.

m3u files are just simple text files, listing tracks. Theres nothing to them. Looks like its coming on really well.

I've been ploughing through all these debates about how software should be written... phew, no wonder nothing much gets done. I like what you are doing, and rather than just talking about bottom-up and top-down, you just got on and wrote something! I have the same problem at my clients, they will spend months debating which particular shade of green to use for a button.