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

Anyone here think Meedio would fill this bill for a framework. It's designed to be modular and extensible.

Although, it's gonna be a commercial app.

Originally Posted by ose-ml320

Anyone here think Meedio would fill this bill for a framework. It's designed to be modular and extensible.

Although, it's gonna be a commercial app.

I think it will..we'll find out in June or was it July?

Originally Posted by Grayscale

frodo: sounds excellent, maybe you could start deciding the format of configs, etc, show it to us and then we can put in our two cents?

Ok, I've gotta go take a dump, I'll work up some notes.

Frodo

Originally Posted by frodobaggins

Fine. If there is really an interest in this, I will code up an open source example
of a framework. The framework will consist basically of a main screen with
buttons. You can add and delete buttons at will. The main screen will allow you
through a configuration file to add graphical plugins that can be launched from
the screen. The main application will expect the plugins to expose certain
interfaces so the plugins can be called.

For example, you would like to add a dvd player. You code one up
as a plugin. Then you add the plugin to the main config file. When
the app is launched, there will be a DVD button. When you click the
button, the main app will call the start command of the plugin. The
plugin will then start and do what it wants, when the plugin is done
it will notify the host app that it has finished.


There are a lot of other things to be decided on first though.
1. Configuration format, although plugins will be responsible
for their own config, we don't want 8 different types of config
files running around that not everyone knows how to edit.
2. What interfaces the host will make available to plugins.
---IE should the host expose a volume class ?
3. What interfaces should the plugins expose to the calling app ?
---IE obviously - begin, terminate
4. Skin format, should be as consistent as possible, but not mandatory

That's all for now, comments ?

Frodo

What we need to find out right now is if there are a couple of "key abstactions" that are consistent between plugins. That is what does a "parent app" need to pass to a "child plugin" in order for that plugin to successfuly initialize and get control of resources as well as be able to return control to the parent or another child plugin. This brings up a couple of issues.
- One. What makes sense to pass to a plugin.
Well for one it is resources (sound, video etc) and inherited configuration items. That is I am going to pass to the plugin a handle that it can use to draw itself as well as information about how big my screen is and how many colors it supports etc. All items that need to be inherited from the parent app such that the display of the plugins will be consistent.

- Two. What does a plugin need to communicate to another plugin or to the parent app. Picture the following scenario. You are watching a dvd when your OBD-II plugin senses that there is something wrong with the engine. Naturally you would want to know about this. Therefore the OBD plugin sends a "broadcast" letting all the plugins know that it needs control of the resources (sound, video etc) the dvd plugin then pauses itself and surrenders control of the resources to the obd app.

hope this makes sense. Curious to see what other ppl think. Glad to see that with the notable contribution of most of you guys we could at least "get this party started"

as always,
Migrane

back from the trip...friday i'll be leaving again for another week.

maybe this should go into a new thread...this description doesn't have much to do with what we're talking about now and only the chosen few who checked this thread out know about it i'm afraid .

Migrane i believe you are absolutely correct in what you've said. we just need to set up our own protocol of commands the client and parents send between each other. of course we need start, terminate, interrupt...but what others? I think most of the data passed between application and plugin would mostly be string data. should the audio from say the xm plugin have to go through to the parent application? if it does it would make it more complicated but it would also allow more control...that is the main application would have say an equalizer or volume control that every plugin might not have.

to be honest, i actually don't know how the data from say an xm radio plugin would do that. the only client / server stuff i deal with uses strings. any more experienced programmers have any suggestions on this? i think i'm just confusing myself...

Originally Posted by Grayscale

back from the trip...friday i'll be leaving again for another week.

maybe this should go into a new thread...this description doesn't have much to do with what we're talking about now and only the chosen few who checked this thread out know about it i'm afraid .

Migrane i believe you are absolutely correct in what you've said. we just need to set up our own protocol of commands the client and parents send between each other. of course we need start, terminate, interrupt...but what others? I think most of the data passed between application and plugin would mostly be string data. should the audio from say the xm plugin have to go through to the parent application? if it does it would make it more complicated but it would also allow more control...that is the main application would have say an equalizer or volume control that every plugin might not have.

to be honest, i actually don't know how the data from say an xm radio plugin would do that. the only client / server stuff i deal with uses strings. any more experienced programmers have any suggestions on this? i think i'm just confusing myself...

I will have to ponder on all of the aspects of this problem. The idea is that from the getgo there is no such thing as a perfect design. There are good designs out there and there are a lot of bad designs as well. (no news here) The way to a good design is littered with compromises. What I am looking for is for a way to make the right compromises in such a design and there is no better way than to make this an open discussion and the fruits of it an open application.

as always,
Migrane.

PS. frodo has started another thread with his take on the issue.
As philosiphical as it sounds i think it might work.

i agree, there are too many compromises you will have to make...so I'm sticking with the "i'm going to build my own app, then release the source code" policy.

frodo: keep up the good work man! at least you're giving an effort, unlike me!

Gray

There are a few such ventures happening at the moment, and I agree with you, just keep at it. At what stage do you feel like sharing the source code?

Is this also a VB app, seems as though thats a favorite amoung the coders here.

I haven't dont anything with VB for years. My bread and butter has been c/c++/java/sql, but Im sure I can figure out VB if thats your chosen language.

What I would like is a language that has built in support for skinning. Swing/Java had some good ideas about uncoupling the controls funtionality from its appearance, but Swing has a lot of other shortcomings. You would need a multiprocessor car computer just to get it to be responsive!

Originally Posted by mobileh1

Gray

There are a few such ventures happening at the moment, and I agree with you, just keep at it. At what stage do you feel like sharing the source code?

Is this also a VB app, seems as though thats a favorite amoung the coders here.

I haven't dont anything with VB for years. My bread and butter has been c/c++/java/sql, but Im sure I can figure out VB if thats your chosen language.

What I would like is a language that has built in support for skinning. Swing/Java had some good ideas about uncoupling the controls funtionality from its appearance, but Swing has a lot of other shortcomings. You would need a multiprocessor car computer just to get it to be responsive!

Yep, it's VB. I'm basically going to be using a lot of image controls and their click() events or I'm going to put a background on a form with blank image controls or something. Haven't quite decided. The app isn't skinned right now, that was just what i've done in photoshop. Also I'm going to be connecting to a MySQL database for the mp3 list most likely. Changed my mind about the m3u thing. But I MIGHT do that. I am sounding a bit undecided on things right now but thats because I haven't been at a computer for 4 days and will be going on another 1 week trip Friday. So, I will try to keep everyone informed.