StatusBar (Footer) API

[mickey@…]

​http://wiki.openmoko.org/wiki/Footer contains a status bar that listens to dbus.
Since the footer is a separate process, it needs to keep track of the current
application and (re)display its status bar contents.

libmokoui needs to offer an API that encapsulates the dbus call used to send a
message to the footer -- similarities to the GtkStatusBar? API would be preferred.

[jluebbe@…]

It sometimes show the title for Task Manager and Dates.

[alphaone@…]

libmokoui should offer a class with an API similar to GtkStatusBar? (having a
stack of messages, but only one context - the application).
The actual status bar application just offers a way to display a message through
DBus. Then when an application is shown the class takes care of sending the
message on top of the stack to the status bar. Additionally, if the stack is
altered while the application is still active, the class will update the
StatusBar? application.

Nice to have functionality would include a DBus interface per application so the
task manager can poll the current message (i.e. get_current) and show it as the
title of the application.

[rob@…]

I think that using dbus for this is completely overkill. When you send a message
on the bus every process on the bus is woken up resulting in a context switch.

A much nicer solution I think would be to use X properties to convey this
information. This should give much better performance especially if a lot of
updates are being made (e.g. updating a progress bar.)

I'm going to spend some time today and tomorrow working on this. Another thing
that we could do is allow the process to use xembed (via GtkPlug/GtkSocket?) to
embed a widget of their own choosing.

I know on the desktop the status notification area uses dbus however that needs
to receive messages from processes without an X window, from my understanding of
the purpose of the footer there will always be an X window for the process that
wants to control the panel

[rob@…]

Over the weekend I knocked up some reference code showing how we could use X
properties to do this. Basically the strategy is this:

The footer keeps track of the _NET_WINDOW_ACTIVE property that is set by the
window manager on the root window, it uses this to notice when the
active/topmost window changes.

When the window changes is attempts to get the _MOKO_STATUS_MESSAGE property
from the window and also tracks for changes to this property. It uses the
contents of this property for the message.

The net result is that whenever the client of the topmost window changes the
property the other client knows and can fetch it. If the top-most window is
changed to something that does not have this property the old value of the
message is retained (e.g. dialog box.)

I would propose adding the code for setting the property to MokoWindow? so that
all applications can exploit it trivially and even if they don't the property
can be set to an empty value.

[rob@…]

Client code for reference code

[rob@…]

Display code for reference code

[alphaone@…]

There's no footer in our new UI (OM-2007.2), so this bug doesn't apply any more.

[anonymous]

Milestone Phase 2 deleted