New environment for linux

kshots · 04-04-2007, 10:26 AM

I'm considering and attempting to gauge the level of interest in writing a new "environment" for linux. Here's what it should do:

1. Basic menu interface over an extremely simplified window manager (perhaps evilwm)

2. Plugin-based, to allow 3rd party plugins to override nearly any feature.

3. 3D menus plugin - something similar to beryl without the rotating cube effects and such. Maybe a 3D flaming background of an active engine, with rotating menu icons. Possibly also animating all menu context switches. Note this is only a plugin - there should also be a basic 2D menu plugin.

4. Native GPS capability via a plugin - Come on, we're on a 7" LCD touchscreen (well, most of us), we need a custom GPS application, not something designed for a fine pointer like a real mouse.

5. Media playback plugin

6. Voice activation input plugin (Ok, in this case I'm looking for help in the form of a 3rd party plugin)

7. Cell phone plugin

The general interface would be similar to the MythTV interface, except it would use mouse (touchscreen) input rather than keyboard / remote control input.

I'm hesitant to simply call this a frontend because it does more than wrap a bunch of applications in menus - it will in some cases be doing some complex application work. Therefore I'm more inclined to call it an "environment."

Also of note - I see there are other solutions, like Velocity. Honestly, when I saw Velocity, I was wondering if there was a point to doing anything else, and possibly going into writing plugins for it... until I realized that it was restricting itself to the capabilities of flash. The way I see it, that eliminates the 3D menus or any other 3D plugin, and possibly other 3rd party plugin ideas. Therefore, I'm pushing this forward as an alternative idea.

This environment would be written in C++ with Qt 4.x. I'm open to the idea of keeping this project cross-platform (C++ and Qt work on nearly everything), but I suspect some functions would be a royal PITA to implement cross-platform (like v4l (radio) support, GPS support, etc... the 3D menus should work on anything, but I can't go much beyond that).

Please note, I am only trying to gauge whether or not to begin this project - not a single line of code has been written. If I do begin, it will be under the GPL for all Qt-specific code sections, and under the BSD license for anything clear of the Qt taint (In other words, it will be free and open source).

PreDeToR_ · 04-24-2007, 08:44 AM

Dude that sounds like a great idea...

I was thinking of doing the same thing, but my qt is not that good...

Let me know how it goes...

kshots · 04-24-2007, 01:23 PM

Ok, I've decided to proceed with this project.

I've written the most of basic framework, at least to the point where it should be possible for people to start writing plugins. I've included several sample plugins as placeholders (they load to the main framework, but until some code is written, that's all they do).

I'm calling it evilcpc (Evil Car PC). I've submitted the project to sourceforge for hosting a few minutes ago. If you're really interested in looking at what's going on, I'm running a subversion repository for the code, reachable at *moved (see below)*. If you're not that good at Qt, it's pretty easy to pick up (assuming you know OO concepts reasonably well). You can find some good documentation on their site

Right now, I'm just focusing on the framework. All the real work will be done with the plugins.

nasa · 04-24-2007, 01:35 PM

Have you seen this?

http://www.mp3car.com/vbulletin/linu...nter-beta.html

Nasa

kshots · 04-24-2007, 02:05 PM

No, I had missed that. However, I can see that a lot of what I'd want to do would be very difficult under that environment, at least on the 3D side.

The trouble with SDL is that it's either 2D or 3D - nothing in-between. If I were to attempt to modify nghost to be 3D, I'd have to start from scratch on all the various widgets. Under Qt, I could work in 2D and 3D at the same time by taking control of the protected paintEvent() function of my QGLWidget, outputting all my 3D stuff, then slapping my 2D stuff on top.

I may be interested in helping him out with his plugin architecture difficulties (I have written several plugin-based projects, using ldopen (unix), lt_ldopen (libtool), and Qt plugins). I may then be interested in contributing a few plugins... but if I want the flashy 3D stuff it would probably be easier to work with under Qt (Though I don't particularly like the GPL - I prefer BSD myself, which SDL allows for).

PreDeToR_ · 04-25-2007, 01:16 AM

Keep us up-to-date...

I would love to you a very pretty linux based system....

And have a look at the code...

I had a look at the code for headunit, but it is very difficult to read, so if you could comment a lot, and give ppl ideas of what you doing.

Cause then you can have ppl, modifying the code and submitting the code to you,
so that you can include it into the project...

This can be a really nice system... and can easily be ported to windows/mac... so then
you can have an even bigger user/suggestion base...

KEEP UP THE GOOD WORK!!!

kshots · 04-25-2007, 09:07 AM

Yeah, I was intending to write API documentation when SF accepts the project, but I can get a head start on it earlier. My priority will of course be plugin documentation, to allow people to write plugins as soon as possible.

For the most part, the code is ultra simple and self-explanatory... it's just spread across many files. Because of its simplicity, I didn't see much of a need for comments, but I definately see the need for documentation.

shotgunefx · 04-25-2007, 10:09 AM

Quote: Originally Posted by kshots

No, I had missed that. However, I can see that a lot of what I'd want to do would be very difficult under that environment, at least on the 3D side.

The trouble with SDL is that it's either 2D or 3D - nothing in-between. If I were to attempt to modify nghost to be 3D, I'd have to start from scratch on all the various widgets. Under Qt, I could work in 2D and 3D at the same time by taking control of the protected paintEvent() function of my QGLWidget, outputting all my 3D stuff, then slapping my 2D stuff on top.

...

I've been working on a Perl/SDL Music/Dash front end Auto-DAC for awhile now.

SDL is nice, one thing that hurts for an app like this though is the lack of widgets. I've heard some people have mated WX to SDL for a best of breed solution, but I haven't experimented with it yet as I don't have the time at the moment.

When I was having problems with the Perl bindings not keeping up with the SDL releases, I started looking at QT, but I was able to patch the issues that were occuring, though if I hit any more major roadblocks, I may very well go that route.

I haven't experimented with the OpenGL aspects yet, but it's on the todo as I have a nice 3d model of my car that I want to use with the OBDII side of things. I've not heard that in SDL 2D and 3D were mutually exclusive, I've actually read several places that if anything, it's faster due to hardware acceleration. Am I missing something?

kshots · 04-25-2007, 11:18 AM

I've started putting in plugin documentation. You can find it here. Note that it's a work in progress, and that I'm focusing exclusively on the plugin documentation at the moment. Currently the input plugin documentation is nearly complete, and the other docs should follow shortly.

EDIT: For the most part, the plugin documentation is now complete. This does not mean that the interface is complete - I note at least some missing functionality in the menuing system (something to feed in menu items), and there may well be more. At this point, I am open to ideas of what each plugin must implement, to be placed into the interface.

kshots · 04-25-2007, 11:23 AM

Quote: Originally Posted by shotgunefx

I've not heard that in SDL 2D and 3D were mutually exclusive, I've actually read several places that if anything, it's faster due to hardware acceleration. Am I missing something?

The issue with SDL is that it's difficult to work with the OpenGL context window using 2D widgets. It's solid and very fast if all you're doing is 3D (and hence an excellent choice for gaming), but I find it very difficult to make decent 2D/3D applications with it.

An example would be a 3D model editor. You would run into at least two problems with SDL on such a project - only being able to have one context (and one window), and just widgets in general.

shotgunefx · 04-25-2007, 11:36 AM

Quote: Originally Posted by kshots

The issue with SDL is that it's difficult to work with the OpenGL context window using 2D widgets. It's solid and very fast if all you're doing is 3D (and hence an excellent choice for gaming), but I find it very difficult to make decent 2D/3D applications with it.

An example would be a 3D model editor. You would run into at least two problems with SDL on such a project - only being able to have one context (and one window), and just widgets in general.

I certainly hear you on the widget issue. A big PITA. The way I'm approaching it at the moment is just writing stuff like that in Perk/TK and launching those processes from the main app.

kshots · 04-25-2007, 04:51 PM

Finished up a functional shell configuration utility. The idea here was to be flashy and foolproof without a frontend capability, so the thing is remotely configurable. Hence it's an ncurses application utilizing Qt's QSettings for the evilcpc project. The settings saved by the utility are used by the core to initialize. The utility is under trunk/evilcpcconfig.

You can try it out by downloading from the subversion repository, compiling some of the plugins and running the configuration utility. Put all the plugins in one folder, navigate there with the utility, and the select your plugins. Space toggles a plugin on and off. If there's only one plugin, at the moment it's difficult to tell whether it has been selected or not.

Plugin settings are stored under ~/.config/War Games/evilcpc.conf (This is standard for using QSettings).

Another possibility I'm considering is running a http daemon for run-time configuration, rather than simply a shell that will tell it which plugins to invoke the next time it starts.

EDIT: The plugin interface needs a configuration section. I'm considering two ways of implementing this.

1. The plugin can be configured during run-time. Default options must be defined. A configure() function will be added to the interface.

Pros: Online configuration
Cons: Must assume that no keyboard is available (mouse input only), little johnny can royally screw up your evilcpc configuration by poking at the touch screen.

2. The plugin will be configured while off-line using the configuration utility

Pros: Idiot proof - little johnny's not going to screw up your plugin setup by poking at your touch screen, can assume keyboard input
Cons: Plugin coders will need to know how to manipulate ncurses in addition to Qt (more work / know-how required - I'm trying to avoid that), if I change the configuration utility to an http daemon, the whole configuration interface would change

I need input / suggestions on how I should approach this. Any other ideas?

kshots · 04-26-2007, 05:54 PM

Ok, the project has been moved to sourceforge. This includes the subversion server - I've shut down the old svn repository to avoid confusion.

The new site is here

EDIT:

If you were using the old svn server and want to maintain your current environment, run the following command to switch to the sf subversion server:

svn switch --relocate https://warfaresdl.com/svn/evilcpc https://evilcpc.svn.sourceforge.net/svnroot/evilcpc

That should tell your local copy to look for and post updates to the sf site

kshots · 04-27-2007, 11:26 AM

Update: The core is operational. It loads all selected plugins (from the configuration utility), connects the selected input plugins to the selected menu plugin, passes all menu item plugins to the menu plugin, and shows the menu plugin's widget full-screen and executes. From this point, all the work will be done by the plugins.

This does not mean that development on the core is finished or finalized, but it means that all plugins can now be written and tested.

kshots · 05-17-2007, 03:12 PM

Further update:

The core now connects the input plugin signals to matching menu item slots via reflection. This means that the input plugins can develop custom signals to connect to custom slots on menu item plugins without a recompile of the core, and with minimal integration efforts (just match the signal name to the slot name).

For example, the voice input stub now features "activate" signals for each of the menu item plugins to allow these plugins to be activated anywhere in the environment (if/when voice activation becomes available, you should be able to say "gps" from the mp3 player menu item, and the gps menu item will appear)

This feature has been tested with the voice input stub (the core detects the signals and slots, which were not in the interface, matches them, and connects them to each other). I am considering doing the same thing between individual menu item plugins, menu plugins, mixer plugins, and input plugins, just to be as flexible as possible.

This should allow people to release plugin "suites" that are tightly integrated into each other, allowing for example a gps button inside an mp3 player interface to activate the gps interface from the mp3 interface.

I am working now on updating the plugin developer documentation to describe the process of developing custom signals and slots that get recognized by the core via the reflection process described above. For the most part, it simply involves following a simple naming convention for the signals and slots, with signal names matching slot names. Parameters must also be identical, but this will not cause undefined behaviour if they do not match - a non-exact match will not be connected, so you can have similar signals/slots with different parameters with no problems. A signal can be connected to multiple slots, just use the one signal and multiple slots with the same name in multiple plugins.

As you may have surmised from above, I'm also going to be adding yet another interface to the plugin architecture - a mixer interface. I have yet to see a good cross-platform mixer library, so I feel it is best to offer a plugin approach to let a mixer plugin load a mixer library that is appropriate to the operating system being targetted. For example, linux users would use the alsa or oss libraries, windows users would likely use direct-sound libraries, and I'm not sure what mac users would use, but there must be some library available to fill that niche.

To make a long story short, there's been a lot of progress with the environment, it's usable as it stands in terms of writing plugins... but the plugin interface is about to undergo major changes, so it is not recommended to do any serious plugin work quite yet.