Scale Gui Multi-tasking

[aissen]

Hi all,

I’ve got some questions regarding the development of a andora1: GUI(Scale) I talked about in this thread.

Here is how Zoxc planned it for multi-tasking:

Scale will open the menu.

The menu will launch an application. The menu prints loading app name to the screen and send a message to the application then it will just wait for a Home key press. If the application is a background application a loading message will appear and you will just be returned to the menu.

The application will reply with name, icon if it supports Scale. If it doesn't support Scale, it will do nothing.

When the Home key is pressed Scale will check which application has the screen (that would be the last started or switched application) and if it has registered with name and icon, if not Scale will pause the application, save the screen to a buffer and show the menu. If it has registered Scale will send it a message to stop printing to screen, if it doesn't respond within a timeline, Scale will pause the application, save the screen to a buffer and show a menu on top of that buffer with the following options: Wait, Kill and Minimize.

When the menu restores an application it will send a message to resume printing to screen if it supports Scale, or print the application's buffer to the screen and resume it.

Now, I don’t completely agree, so I looked quickly at gmenu2x, but it doesn’t do multi-tasking, and just launch the applications in its place (execlp). Therefore I’d like to ask the following questions:

- How do you send an application to background on keyboard shorcut(*home* key), without a running X Server?
- Would using SIGSTOP/SIGCONT be relevant to pause an app? Wouldn’t there be a problem with applications using timers?
- To save the screen of an app, would reading the framebuffer device be enough?
- If the GUI doesn’t rely on X, how do you switch between framebuffer apps and kdrive apps?
- Is it desirable to use an IPC mechanism to control an app? To send it a message for pause/resume, and receive messages for icon/title updates.
- Last but not least, how do you test that on an x86 machine ? =P

 

[multiplex]

Not sure of the specifics, but I have some vague big picture stuff that might be helpful.

- How do you send an application to background on keyboard shorcut(*home* key), without a running X Server?

You mean for reading the key press? I think you could for instance read events off one of the files in /dev/input, though there are probably higher and lower level ways that I don't know of. I'm not entirely sure if those are independent of X.
QUOTE

- Would using SIGSTOP/SIGCONT be relevant to pause an app? Wouldn’t there be a problem with applications using timers?


Probably, it's the only way I can think of to force an arbitrary process to pause. If the application can't handle being arbitrarily paused, it's broken anyway, as the OS may need to do that for other reasons, like hibernation. There may be (many) apps that are thus broken, though, especially emulators that need to maintain an FPS. I can't find a clock one could use to get only the unpaused time, so I'm not really sure how to do it 'right'. Maybe just reset the counter on any absurdly high values.
QUOTE

- To save the screen of an app, would reading the framebuffer device be enough?


Dunno. This post seems relevant, as I'd think he'd mention it if it was that easy.
QUOTE

- If the GUI doesn’t rely on X, how do you switch between framebuffer apps and kdrive apps?


Killing the X server would be a no-go, X applications tend to get grumpy when they lose their connection. Maybe you could switch to a different virtual terminal with ctrl-alt-f1 etc. / chvt.
QUOTE

- Is it desirable to use an IPC mechanism to control an app? To send it a message for pause/resume, and receive messages for icon/title updates.


Well they're different processes, so if they're going to communicate, you'll per definition need an IPC mechanism. Even SIGSTOP/SIGCONT counts as IPC.
That said, yes, I'd say you'll definitely need some IPC protocol to offer a smooth GUI experience, especially considering the above problems with SIGSTOP...
When programming MIDlets for cell phones, for example, you have methods that are called to notify the application when it gains and loses focus. X applications could conceivably be expected to use window focus as a similar hint to pause.
One could use dbus, but it's a bit bloated for small devices, so if it's not going to be running anyway, I wouldn't bother. (dbus-daemon is currently taking 668 kB of resident memory on my computer)
Sockets are familiar to most programmers, and will work for this use.
What I'd do is make it a short and sweet shared library. That should keep the boilerplate down to one line each for setup and destruction, and a very short event handler, either polled or callback.
What I'd do is a bit moot, though, just do whatever the official GUI does, if it deals with this.

The icon and title modifications sound like overkill. If they wanted to do fancy stuff like that, why not use X?
QUOTE

- Last but not least, how do you test that on an x86 machine ? =P


Well actually, the device specific thing I see so far is the frame buffer. I have a frame buffer device here on my desktop at /dev/fb0, but I'm not sure I'd trust it to function exactly like on the Pandora, what with different drivers and resolution and all. Just set up a Linux PC with libraries and programs like on the Pandora, don't write byte-order dependent code, and you should be good. If it turns out you need to do something more hardware-specific, write scaffolding code for now and test the parts you can.

Sorry for the vacuity, I thought this post would end up bit more informative when I started writing it. :rolleyes:

 

[Tinnus]

I may be wrong, but I'm pretty sure X will be running all the time if any kind of multitasking is happening (even if the windows are all fullscreen).