New Linux Project (windows maybe)

**bigb** · 03-08-2004, 03:01 PM

I think you might have mis-understood the "port" server/client idea. Basically a plugin would do the following :
telnet localhost 9999
XCar -> Welcome!
<plugin sends "hello">
XCar -> Mp3 Plugin v0.1 Accepted Successfully.
(say the user presses a button to play an mp3)
XCar -> Mp3 Plugin -> Play Loaded Track Now
MP3Plugin -> XCar -> Now Playing /mnt/music/<filename>

Or something to that affect. I am trying to make it as EASY as possible for people to write software that will work well with this. I am also trying to make it very easy to use software that is already out there, and run it in a "non-window mode", ontop of a current screen, so it appears as though it's part of this application. That may sound easy, but it's not due to the various ways people write software for X11, and the various windows managers. KDE, Gnome, GTK, Qt, etc..

For an example, I'm developing on a KDE 3.x(home brew), and Qt 3.2. I switch over to gnome, and things don't work quite as well. More screen flicker due to X11's flush when doing OSD over Mplayer. (Which yes, I do have working.. lol).. Just the little things. I am going to assume most people will be running this in KDE, but it's not locked into a specific WM.

Windows is a whole nother story.. haha..

Originally Posted by dieselBenz

I like the idea of having the ability to "embed" standalone apps. But instead of making everything a standalone app, how about having one plugin for launching, killing and resizing an external app? This should be a really simple plugin, and once made, people would need no programming skills to add features/programs.

I like the port idea, but it's maybe not the easiest to program? (and a bit overkill until people start building networks of computers into their cars... I would thinl simple function calling is more effective.)
How about each plugin "subscribe" to messages of different sorts? For example, the mp3 plugin will need keypress input, and output song name, time etc. The wardriving plugin will need gps information and keypress, output network names etc...
The core will then manage several defined message queues and call functions in the loaded plugins. I think this may be an effective and not too complicated solution.

Another idea is the xmms way of doing things, where you can send messages to xmms on the command line. For example, xmms -pause will pause the running xmms.

Just some thoughts...

**hijinks21** · 03-08-2004, 03:10 PM

when you get the code ready let me know.. i'd love to take a look. I don't use kde as a WM at home or work. I use fluxbox but have qt 3.x installed.. i believe its 3.2

**mespork** · 03-09-2004, 12:25 AM

Originally Posted by hijinks21

when you get the code ready let me know.. i'd love to take a look. I don't use kde as a WM at home or work. I use fluxbox but have qt 3.x installed.. i believe its 3.2

You honestly can't beat fluxbox, everything you need, nothing you don't, it is the only thing I like to run on. I was trying to an interface a while back using DirectFB as the window manager because it is so compact and ment for embedded applications.

**dieselBenz** · 03-09-2004, 02:42 AM

I think I know what you mean by server/client idea. I just have a feeling that sending commands via telnet would be a lot slower than calling a function in a loaded library/object. Of course this won't matter for simple "play track.mp3" commands, but it might for stuff like audio streams for instance? Just trying to think of possible problems before it's too late...
I don't have a lot of experience with different WMs and advanced gui programming, but I know it's sort of a chaos at times... I run mainly kde, and have some qt/kde experience.

Originally Posted by bigb

I think you might have mis-understood the "port" server/client idea. Basically a plugin would do the following :
telnet localhost 9999
XCar -> Welcome!
<plugin sends "hello">
XCar -> Mp3 Plugin v0.1 Accepted Successfully.
(say the user presses a button to play an mp3)
XCar -> Mp3 Plugin -> Play Loaded Track Now
MP3Plugin -> XCar -> Now Playing /mnt/music/<filename>

Or something to that affect. I am trying to make it as EASY as possible for people to write software that will work well with this. I am also trying to make it very easy to use software that is already out there, and run it in a "non-window mode", ontop of a current screen, so it appears as though it's part of this application. That may sound easy, but it's not due to the various ways people write software for X11, and the various windows managers. KDE, Gnome, GTK, Qt, etc..

For an example, I'm developing on a KDE 3.x(home brew), and Qt 3.2. I switch over to gnome, and things don't work quite as well. More screen flicker due to X11's flush when doing OSD over Mplayer. (Which yes, I do have working.. lol).. Just the little things. I am going to assume most people will be running this in KDE, but it's not locked into a specific WM.

Windows is a whole nother story.. haha..

**jol** · 03-09-2004, 05:05 AM

Hey I thought of another thing

I want to seek within movie files, you cant do that with any program anymore, just jump to xx:xx. Eaven if it's only jump to 5% forward of the total file time, it would feel like seek, get me?

**mpattonm** · 03-09-2004, 05:27 AM

Try thinking about embedding Navigator instead http://www.mapfactor.cz/navigator_eng.htm
Navigator claims to be available for both Win and Linux and has an SDK available. Linux version of Navigator is developped under QT.
Embedding Roadmap might be also a good choise for US. http://roadmap.saignon.net/ The problem is it would require another giant library (those "gnome" libraries - whats thier name anyway) beside QT.

**hijinks21** · 03-09-2004, 07:01 AM

Originally Posted by mpattonm

Try thinking about embedding Navigator instead http://www.mapfactor.cz/navigator_eng.htm
Navigator claims to be available for both Win and Linux and has an SDK available. Linux version of Navigator is developped under QT.
Embedding Roadmap might be also a good choise for US. http://roadmap.saignon.net/ The problem is it would require another giant library (those "gnome" libraries - whats thier name anyway) beside QT.

if its gnome its gtk or gtk2.. excellent find.. thanks for the link. too bd they just have EU maps

**nottastocker** · 03-09-2004, 07:56 AM

Originally Posted by dieselBenz

I think I know what you mean by server/client idea. I just have a feeling that sending commands via telnet would be a lot slower than calling a function in a loaded library/object. Of course this won't matter for simple "play track.mp3" commands, but it might for stuff like audio streams for instance? Just trying to think of possible problems before it's too late...
I don't have a lot of experience with different WMs and advanced gui programming, but I know it's sort of a chaos at times... I run mainly kde, and have some qt/kde experience.

the question is, how many features will the core program have? if you're going to write functions to play mp3's, what should be left to the module besides the interface? it also kinda limits the functionality, at least at first glance. how about having the core program taking in WAV format sounds, then using its configuration file to figure out how to play them trough the system?

**hijinks21** · 03-09-2004, 09:09 AM

Originally Posted by dellysse_com

the question is, how many features will the core program have? if you're going to write functions to play mp3's, what should be left to the module besides the interface? it also kinda limits the functionality, at least at first glance. how about having the core program taking in WAV format sounds, then using its configuration file to figure out how to play them trough the system?

my idea of a good core is something that just handles input and output. Also handles all of the controls to pass them around the program. After that it is up the the modules to do the rest. For example say you have a GPS and a audio module loaded and thats it to make the example simple. You are taking a trip and enter in your location in the GPS module to get your route. Then you go to the audio module load up a nice long playlist. Now as your driving the gps module sends like a notify event which some text that is "in 1 mile turn left on exit 53". So the core knows the notify event as something it needs to place on like a notify bar or such that for 30 seconds overlays over the top of what is currently in use (audio module) so as you are playing your music you get a notify box saying you need to turn right.

So instead of trying to jam everything in one app that if you need to make a major change you might have to change EVERYTHING.. you are just changing the core or how a module sends an event.

**bigb** · 03-09-2004, 01:23 PM

I guess that's the big question. What is a "core" supposed to handle? If the core handles audio, then we have an issue w/ people like me that actually use 5.1 cards, or specific output cards. Anyone using SoundBlasters USB audio hubs? Another problem right there.

We could also risk losing alot of portability by attempting to re-write an audio engine for windows. It's not like we can just use simple MCI API to output audio. Of course I could very easly add the ability to play WAV's on both platforms, if I do, then it's up to someone out there to code up an mp3 decoder that plays nicely w/ the plugin scheme. Not exactly a task the "average" programmer is up to.

What I WAS planning :
Have MP3 support built in, but yet very pluggable/skinnable.
Have Video support built in, and again, skinnable/pluggable.

Everything else, would be up to anyone who chooses to write plugins. GPS, Traffic, Internet support, Email, etc.. The plugin method is still up in the air as far as I can see. I didn't plan on allowing a plugin direct access to the audio/video, though methods can be created to allow an application to pass wav/mp3 audio for the subset to play.

The reason for this :
When playing audio from one application, often it is no longer available to other applications on Linux. (yes, there are work arounds for this, but on a default install, this is usually how it is). My thoughts were if I had the main app playing an Mp3, and say the GPS plugin wanted to "speak" a direction, the main app could lower/pause the volume on the playing mp3, and then output the GPS wav/mp3.

And as far as KDE, I'm just using it as my winmgr, none of what I have written so far depends on KDE at all, and is also pretty easily portable to GTK.

As far as telnet, it was never intended that telnet be used as a way to pass audio, it was simply one way for an application to pass useful information to the main application. (it also serves as a good way to test various inputs, such as IR, and custom keyboards).