What Will Be The Ui?

[cb88]

The fast in kernel VT switching would be very nice to have at some point X could run on one VT and games on others

 

[DrOctavius]

But we still don't know if the pandora will run using the framebuffer or if it will use an Xserver.

Squidge, do you know something about that?

I don't have anything concrete, but I would suspect it using the frame buffer by default, but having the option of launching the X server for PDA stuff and what not. Maybe. Possibly.

Or in other words, "No, I don't know anything about that"

Ask DJW, he's the OS guru


You need both (framebuffer and X11) a framebuffer will have high performace when you need it and X11 allows you to port a lot of existing apps.

 

[Svartalf]

You need both (framebuffer and X11) a framebuffer will have high performace when you need it and X11 allows you to port a lot of existing apps.

Something along the lines of DirectFB perhaps?

 

[blachner]

Qtopia renders straight to the framebuffer, without X. This is not suitable for the pandora, so an Xserver with some GUI made with Qt4 would probably be better.

Qtopia also can run on X11. See this thread on the OpenMoko mailing list.

 

[TomCooksey]

KDrive is of no use on the Pandora if you want to do any 3D in X applications (I assume people do?). Hardware 3D acceleration is done using DRI, which is an X.org specific thing. Back in 2003 someone tried to get DRI working with KDrive and I believe they got something to run on some old hardware (rage128 I think). I think this has bit-rotted away to nothing as DRI & KDrive have evolved over the past 5 years. The only possibility of using KDrive is if Imagination Technologies (the guys who designed the SGX 3D processor in the Pandora) do their own implementation. Failing that, you need full X.org, which is not small.

Qtopia is a set of applications written using the Qt libraries. It is designed to work with Qt/Embedded, which is what I work on. I currently have Qt/Embedded up & running on an OMAP3430, using OpenGL ES to do window compositing (think Compiz) etc. This is using the PowerVR SGX "null" drivers. These drivers basically allow us to open the screen as a surface we can bind a context to. We also have pixel buffers and other fun things which don't require any native window system. I.e. There's no eglCreateWindowSurface() or eglCreatePixmapSurface(). These drivers work without any window system and is what I'm guessing you're going to get on the Pandora (can anyone from Pandora confirm this?).

I am currently working on getting OpenGL ES working in windows from multiple client processes, via QGLWidget class. I'm planning to put up a video up in the next month or so. I'm hoping that once people see something working on real hardware, it will sway them. I'll post in this form once I have the video up.

 

[BCable]

The problem is where you want to dump it to. The only place you have on the pandora is flash memory and using flash as swap space wares it out. What I think you could do instead (and I think Qtopia supports this) is terminate all the GUI applications asking them to save their state. When the game ends, the GUI applications are re-launched and told to restore their state. The the applications still need to save their state somewhere, which again will eventually ware out the flash.

So does this mean we are going to have the same and/or similar system that the GP2X uses, and not have a fully multiprocess environment? That's the one thing that irritated me the most about the GP2X.

I know most of this thread is about display libraries, such as X/Qt/GTK etc, but what about the actual GUI interface?

I guess my question is, will there be multiple window support? I'd personally really like a system similar to Ion3 or AwesomeWM. Using a tiling interface for applications would allow for better usage of such a small screen (not for games, though, obviously).

I know the GP2X could background processes and such, but it was an extreme hassle and after it was running you couldn't access it anymore because the GUI was killed if you executed a game. You could basically only do one thing at a time. Not really that much of an issue with a gaming centered device like the GP2X, but when you get PIM stuff and internet access it would be nice to have for instance IM software running (IRC connected to bitlbee or something), play a game, get a message and switch to the other window without exiting your game and such. Or the ability to listen to music while playing a game, switch to the music window and change songs, switch back, etc.

I'm sure direct ports of these WMs will be a bad idea, but something specialized and similar would be nice. Has any discussion of this been made before?

 

[Orkie]

I would think it is very unlikely X will be used for the default GUI. I do think including kdrive is a good idea, but purely for running more desktop-ish applications, not custom written games and emulators.

 

[Squidge]

So does this mean we are going to have the same and/or similar system that the GP2X uses
Games and emu's are likely to be run from a simple gui launcher like on the GP2X, whilst PIM apps will probably require X to be launched first. So you'll be able to swap between PIM-style apps, but not between games/emus and PIM apps. Emulators are typically resource hungry, so eating up those valuable resources and then launching emulators would be a bad idea. It would also mean posts on these forums about people complaining why Emu 'X' doesn't work when it does for someone else, only to find out that they had certain background tasks running that the other user didn't.

 

[sindbad]

KDrive is of no use on the Pandora if you want to do any 3D in X applications (I assume people do?). Hardware 3D acceleration is done using DRI, which is an X.org specific thing. Back in 2003 someone tried to get DRI working with KDrive and I believe they got something to run on some old hardware (rage128 I think). I think this has bit-rotted away to nothing as DRI & KDrive have evolved over the past 5 years. The only possibility of using KDrive is if Imagination Technologies (the guys who designed the SGX 3D processor in the Pandora) do their own implementation. Failing that, you need full X.org, which is not small.

The xserver would be turned off when a game starts, thus no complications with 3D over the xserver.

However since EXA was prototyped on KDrive, if documentation for the GPU is available KDrive could draw everything hardware accelerated (like the openmoko guys made Xglamo for the SMedia chip). And with this would come the possibility of fancy 3D GUIs.

 

[BCable]

Games and emu's are likely to be run from a simple gui launcher like on the GP2X, whilst PIM apps will probably require X to be launched first. So you'll be able to swap between PIM-style apps, but not between games/emus and PIM apps. Emulators are typically resource hungry, so eating up those valuable resources and then launching emulators would be a bad idea.

With the GP2X I put up with it and was fine with it. It was a gaming device to me, and an absollutely amazing one at that. But once you start saying you are trying to bridge the gap between mobile computing and gaming devices, and provide a 600 Mhz processor and 128 MB of RAM, I think the community would be stupid to continue with the launcher interfaces.

It's true this is no EEE, and shouldn't be compared with it, but I can hardly justify buying a Pandora if it's going to have the exact same interface that the GP2X has. All I'd be purchasing is the ability to emulate PSX. I've been dieing to have that in my pocket, but that would hardly worth the price, and I doubt many other people could justify it as well. Sure you get PIM, but most people already have a solution for that which they can access pretty readily. WiFi? I'm usually near a computer anyway and if I'm not I can just remember and look whatever I want up later. This wouldn't be bridging any gap if this is all it can do, it just turns it into a PSP competitor, not a unique device like they at least sound like they are trying to do.

It would also mean posts on these forums about people complaining why Emu 'X' doesn't work when it does for someone else, only to find out that they had certain background tasks running that the other user didn't.

We have stickies and FAQs here, why wouldn't a simple pre-help sticky thread work to fix that? Say something like, before you post here, you must turn off your device, turn it back on, then launch the application you are trying to get working. If it works, go away . Sure there'll be people who ignore it, but sacrificing features on a device that could act as a dedicated server (this already surpasses my personal dedicated server) JUST to prevent nagging/annoying problems?

I'm just getting a bit sick of devices like these that fail to accept the fact that they are computers and could do much more with the computing power behind them.

I also came up with a better idea which would require less resources. Instead of a tiling WM, it could just simply be the ability to switch windows. Take GMenu2X or something similar, add an extra tab for running processes, and have a list of them on it. Select one and it becomes full screen, so window management and resizing and stuff doesn't have to be calculated, then have the ability to switch back to the menu within the application or through a key combination.

To summarize, if we really want to continue with the GP2X style of application launching, the Pandora will be barely evolutionary IMHO. I was under the impression this mindset was being scrapped for a multiprocess environment, which would be revolutionary.

If it is the GP2X application launching style, then I'll just go hide in a corner and make shallow attempts at creating that system myself .

 

[DJWillis]

Did people miss the hints of simple and advanced menu systems?

There is a lot to be said for keeping a simple unitask launcher but people are quite right that running a full mini Linux distro on the thing is also very appealing.

So what about a basic unitask launcher with an advanced mode that can be launched on demand (think X server with some form of PDA skin)?

Nothing to stop users setting the advanced mode to be the boot default and some use of runlevels and maybe some clever environment flags should make it easy for apps to find out what state the device is in when they run. Remember that a lot of stuff that really bangs the hardware is going to want to chuck out X and any of it's friends before it eats the system for lunch .

As of now I am messing with GNOME (mobile platform) sat ontop of X, Matchbox, GTK+ and the Sato GUI from Poky Linux at the moment, I quite like it . The other thing I am messing with is Clutter. I am starting to really like it (I think that it can be used to create some really tasty GUI's with OpenGL ES and webkit tied to Clutter is very nice . If anybody has used the Cluttler Toolkit before give me a shout.

Anyway, that is just what I am messing with 'for the hell of it', don't expect to see any of that directly in the device setup and assume anything I say is potentially a complete pile of c**p

 

[BCable]

As of now I am messing with GNOME (mobile platform) sat ontop of X, Matchbox, GTK+ and the Sato GUI from Poky Linux at the moment, I quite like it . The other thing I am messing with is Clutter. I am starting to really like it (I think that it can be used to create some really tasty GUI's with OpenGL ES and webkit tied to Clutter is very nice . If anybody has used the Cluttler Toolkit before give me a shout.

Personally I think GNOME/KDE is overkill, I just want to be able to launch multiple programs at once

There is a lot to be said for keeping a simple unitask launcher but people are quite right that running a full mini Linux distro on the thing is also very appealing.

So what about a basic unitask launcher with an advanced mode that can be launched on demand (think X server with some form of PDA skin)?

How exactly does GMenu2X launch its applications? I was pretty sure that multiple process support was available for the GP2X if you backgrounded them, but I can't be too sure. I remember a screen disabling program I used and possibly a background music player... It's been awhile.

I always figured it just fork/exec-ed the process then exited. Then when the application was done, the BIOS recalled the default application (GMenu2X), and that was that.

So if this is indeed how it works, why would a separate launcher have to be used like you say? Couldn't it be just a boolean value in the application that is toggleable by the user?

That's a good idea to make it simple/advanced mode, though.

 

[Squidge]

I always figured it just fork/exec-ed the process then exited. Then when the application was done, the BIOS recalled the default application (GMenu2X), and that was that.

So if this is indeed how it works, why would a separate launcher have to be used like you say? Couldn't it be just a boolean value in the application that is toggleable by the user?

That's a good idea to make it simple/advanced mode, though.

We've always stated it'll be simple/advanced, your just not read the posts correctly

Yes, it'll probably be a simple boolean value toggleable by the user, but they will most likely still be seperate launchers for ease of use and development (After all, one will be created with the frame buffer in mind, and the other with X in mind. It'll be a bit daft to link in all the X libraries for the simplistic menu - your just bloating the app and increasing load time for no reason)

 

[BCable]

We've always stated it'll be simple/advanced, your just not read the posts correctly

I tend to do that a lot. :/

Yes, it'll probably be a simple boolean value toggleable by the user, but they will most likely still be seperate launchers for ease of use and development (After all, one will be created with the frame buffer in mind, and the other with X in mind. It'll be a bit daft to link in all the X libraries for the simplistic menu - your just bloating the app and increasing load time for no reason)

I wasn't saying to use X for the simplistic menu, I was saying to use FB for the advanced menu as well, at least with my second idea. What is the plan for the advanced menu? Is it going to be complete X with window management, or just another launcher?

With FB for the advanced menu as well, then if you want to launch an X application, it can load and run on top of it. Maybe a simple call to whatever X's focus method is for each running application when switching 'back' to the FB device, and have X running multiple windows that are all full screen or something (this part I don't really know about, I'm just throwing ideas out there).

That way, even when capable of multiple processes, you don't have to run X if you aren't using it. A FB menu system, executing a media player like CraigAMP or something, then also executing a game, for instance. Or you could execute X and have whatever X apps you want running, but only if it's absolutely necessary.

I know loading X would be overkill for the simple mode, I'm not stupid . I'm just saying, loading X in the 'advanced' mode might be overkill as well.

I think I'm being a complete dolt though and we're talking about two completely different simple/advanced modes.

 

[ldesnogu]

My understanding is that it's not Xserver + Xlib that is slow to start but the billions of libraries KDE/Gnome rely on that are just layers above Xlib.

At least a few years ago (read: long before Qt and glib) X started quickly.

 

[Arialia]

My understanding is that it's not Xserver + Xlib that is slow to start but the billions of libraries KDE/Gnome rely on that are just layers above Xlib.

At least a few years ago (read: long before Qt and glib) X started quickly.

Yes you're right Laurent, i remember that with the first Slackware on disk 3.5

 

[BCable]

My understanding is that it's not Xserver + Xlib that is slow to start but the billions of libraries KDE/Gnome rely on that are just layers above Xlib.

At least a few years ago (read: long before Qt and glib) X started quickly.

Well, it depends on what you do with X. I don't use GNOME or KDE, and X starts up pretty quickly. However, then again, that's on a 1.6 Ghz processor.

My dedicated server is 500Mhz, 96 MB of RAM. I hooked up a head to it and ran X on it at one point, just for kicks, and it ran Fluxbox just fine, and Mozilla on top of that as well. It did take more than a few seconds to load up, though.

But the point is, why even have X running if you don't need it? FB is going to be loaded regardless, more than likely, and then X as well? Why unless it's necessary? As Squidge mentioned, with emulators running, every little piece of resource counts.

 

[Squidge]

I wasn't saying to use X for the simplistic menu, I was saying to use FB for the advanced menu as well, at least with my second idea. What is the plan for the advanced menu? Is it going to be complete X with window management, or just another launcher?

FB for advanced menu is fine, but then you want multiple processors and the ability to swap between them. Doesn't that mean those processes need to be built with that in mind using some kind of library? It seems daft to do all that work when it's all been done for us already via X and a suitable Window manager.

 

[BCable]

FB for advanced menu is fine, but then you want multiple processors and the ability to swap between them. Doesn't that mean those processes need to be built with that in mind using some kind of library? It seems daft to do all that work when it's all been done for us already via X and a suitable Window manager.

Well, managing a bunch of windows with existing WMs will be tedious and annoying with existing WMs, so at least a WM will probably need to be developed specifically for the device anyway.

I guess it depends what types of applications people decide to write. With SDL apps (for them to be compatible with the "simple mode", they would need to be SDL anyway), I can imagine all of them being 800x480 resolution, requiring no window decorations, and the most "window management" required would be to simple toggle between the multiple fullscreen running applications. Which wouldn't be very difficult to write if you just provide a list of running applications to select from and switch to, as I was talking about earlier.

Then again, I don't know enough about how FB works to be talking about this . Can multiple FBs be created (I would think so with the kernel VT stuff)? Is it infinite? Can one FB be used, then the direct accessing application be swapped out with another process, then reattached at a later date (sort of like GNU screen)?

I'm thinking this might be my ignorance of how FB works that has me thinking these things . I've been imagining most new applications for the Pandora to be very very similar to those already on the GP2X. With talks of GTK and Qt being used, coupled with the fact that I haven't held the device in my hands to fully understand how big or small the screen is as well as how easy the inputs are, everything I'm saying might not be relevant at all.

 

[Vorporeal]

In terms of the possibility of running a resource-intensive app (emulator or high-quality/low-optimization game) from the advanced/X GUI, would it be possible to suspend the entire interface to SD, run the application, then reload the GUI upon the application's completion? It would be hibernation without the halting of the system and the running of an application instead. It's possible that this is the idea, it seemed like nobody mentioned it (or I misread their post when they did).