Car PC Linux Ideas

So the other day i was at work and i saw one of those plasma displays that shows time, weather, and other things. I got to thinking about building one using a Beagleboard XM that i have. My initial idea was to setup a webserver either on the beagleboard or remotely. When the system boots up it would just open a full screen browser window linking to my display page coded to refresh on set intervals. I had a base Ubuntu install with no GUI.

This is where i ran into trouble. I had to pick a window manager or desktop manager such as gnome or kde. I didn't want or need all the bloat that comes with window managers and desktop managers. All i wanted to do was load a browser window. I finally got Xorg to load firefox, but i couldn't specify a url, window dimensions, or a full screen option. Frustration was setting in.

I have been working on my different car pc versions over the years now. I purchased a beagleboard xm with the intention to make it my new car pc. Hardware was in and it was time to pick a front end to use. I ran windows for a long time on different hardware and became accustomed to RideRunner. Ive ran Ubuntu on different setups with Linux Ice and OpenMobile. Both which have great developers, but didn't seem to work with all the things i wanted.

This brings me back to my initial rant on the time and weather display system. Do we really need to load an entire OS then a front end on top of it? In windows it is probably possible to eliminate much of the UI elements and just load your application, but i would think that it would be easier on linux.

Ive looked into running GUI applications on linux without a window or desktop manager. It looks like Xorg programming is near impossible. GTK and other GUI programming libraries began to surface as i was doing research. It still seems very difficult to run a stand alone application.

If you think about what a lot of front ends are doing, they begin to resemble an OS in itself. I know that Linux Ice took this approach of making the OS the front end, but it still uses lots of outside sources. I would imagine that a front end built as its own entity would run faster and have less hardware requirements.

I may be completely off base with what i am presenting here, but i would like to hear your all thoughts. I know this forum is filled with intelligent people who love their car pc's. I feel that there are a lot of people kind of doing there own thing when we should be working together. Im thinking that a custom linux distro that runs just a front end would be awesome.

Thanks for listening,

Stephen

Stephen,

I don't think you understand how GUIs work... Please look at the picture on the top of this page: http://web.mit.edu/qt-dynamic/www/qt-embedded.html (I did a quick google search to find something to illustrate my upcoming points). Don't get caught up on the fact that this discribes QT, the basics hold for QT/KDE/GTK/Window/etc. Each level of the diagram represents a greater level of abstraction from the actual hardware. In other words, everything builds on top of everything else. The low levels provide the communications to specif hardware, while providing more general APIs to the next layer. That layer provides even more generalized APIs to the next layer (so on and so on). Each level provides functinality necessary to enable the GUI environment, along with a set of common interfaces in both up and down directions. In today's computer environment, applications use the most generalized set of APIs in the computer environment.

What does this mean? It means if you want to run *just* and application -- it needs to create all the layers below it. That makes application development significantly more difficult. It would result in fragment interfaces, terrible memory management, long development cycles, etc, etc. Do developers do this? Sure, if you have a very controlled enironment with limited hardware capabilities -- but that really isn't the case any more.

So all that said, you will need something like Xorg or Wayland. You will need a WM (there's a lot out there). And for what you want, that's not a bad thing... You realize that the browser application requires a WM (unless you are running a terminal browser, which isn't what you described). For a slim WM, take a look at ratposion. Another nice WM is E17 (enlightenment). OpenICE essential was it's own WM with apps running on top.

BTW: Windows has a WM, it's just embedded in the OS -- and it always runs.

Thanks for the clarification nasa. This QT embedded seems very interesting. From my understanding, it can run without an xwindow system ontop of the framebuffer? I have been trying to get into linux programming and customization and ive been hitting a lot of walls here and there. Especially with the beagleboard and the extensive knowledge that is required to customize it. Mainly i want to just boot into a full window application.

Edit: I just found this awesome article explaining creating 3D UIs for the beagelboard. (http://jkridner.s3.amazonaws.com/esc/ESC-341_Dompe.pdf )

There are huge advantages to having a app-based system (think processes) rather than a plugin system (ie, different modules that occupy the same address space)... especially when it comes to speed, stability and resource management. Imagine, one of the sole purposes of the kernel (on Linux or any OS) is to manage CPU, memory, and hardware resources. Because this is one of it's major functions, it's very good at it. It's also very good at taking advantage of multiple CPUs so if you have a dual core system, you're getting the most out of your system with no extra work or complicated thread management. Why would you write software that duplicates (probably badly) what the kernel is already doing? Not only that, but when you write a monolithic, single process frontend, you also end up rewriting the window manager and many other subsystems.

Stability is also an issue with monolithic frontends. Say some clown (like myself) writes a badly written plugin for your frontend and it crashes. Because they share address space, the kernel shuts down the entire process to protect the rest of the operating system. What just happened? You just lost your entire interface and now you have nothing.

LinuxICE started out as just Linux with a frontend. But we soon discovered how much duplication we had going on. LinuxICE2 fixed some of that as it separated the dock, media scanning backend and desktop into separate processes. We realized shortly after the 2.0 release that it wasn't enough. We needed a better application framework to provide a consistent user interface across all the applications. At about that time, MeeGo was emerging and offered a common API and all the things we needed. Not to mention it consisted of a much larger development force. It's better to join an existing ecosystem than it is to continue building one from scratch with only a handful of people.

That said, the MeeGo APIs (uses Qt) are way nice. I wish I had more time to devote to developing car stuff.

In my opinion, even QT embedded is quite bloated. For my Car PC software (not yet installed) I have a custom application written in SDL (and running in X), and navit. I have previously used a similar SDL program running on the framebuffer. I don't use a window manager and it works fine. I chose to use X to make it easier to run the two apps at the same time. Therefore I need to raise or lower the application depending on what should be foregrounded, I have that working nicely now it it wasn't too difficult.

All I would do is start X with the 'X' command, set the DISPLAY variable, start firefox (you should be able to pass the URL as a command line parameter). If it isn't maximised, it should be possible to write a small program to do this (effectively acting as the window manager but without all the bloat). I will even volunteer to write this for you if you want.

Alternatively, a framebuffer app could do the job nicely without too much bloat.

Quote:

---

Originally Posted by StevePER

In my opinion, even QT embedded is quite bloated. For my Car PC software (not yet installed) I have a custom application written in SDL (and running in X), and navit. I have previously used a similar SDL program running on the framebuffer. I don't use a window manager and it works fine. I chose to use X to make it easier to run the two apps at the same time. Therefore I need to raise or lower the application depending on what should be foregrounded, I have that working nicely now it it wasn't too difficult.

All I would do is start X with the 'X' command, set the DISPLAY variable, start firefox (you should be able to pass the URL as a command line parameter). If it isn't maximised, it should be possible to write a small program to do this (effectively acting as the window manager but without all the bloat). I will even volunteer to write this for you if you want.

Alternatively, a framebuffer app could do the job nicely without too much bloat.

---

Yeh, the "too much bloat" argument was what I went by when I developed nghost1 and 2. That was before I tried/learned it. Then I discovered that writing a good UI toolkit and API for other developers is not easy, takes a lot of time, and usually ends up being a buggy, slow, just-as-bloated pile of crapware that you were trying to avoid in the first place. ...Unless of course you have a sizable development team. If you are developing a one-off for just yourself, that's fine. But even then, I find Qt to be both more performant, less bloaty and less buggy than anything I was doing before. I write my system daemons (ie, nobdy and proximity) in Qt because 1, Qt is easy to install (usually an apt-get away on most distros), 2 it makes my life easier by providing everything I need where I would otherwise pull in 3 or 4 different components in as deps anyway, and 3, it's stable and fast.