[Shr-Devel] Dbusification of phone UI and general phone UI architecture and the role of ophonekitd in all of that.

[Julien Cassignol]

On Sun, Aug 9, 2009 at 9:53 PM, Tom<tom at stosb.com> wrote:

> This is all nice but it causes two major problems, first of all since it's a
> library you can have two "out of sync" windows of the same kind open as the
> library is not aware of the
> state of the other UI parts

That's wrong, but nevermind :-)


> Another possible design (which I agree with):
> The same as there is now, just rename libframeworkd-phonegui to a more
> maintainable name, something like libphone-ui (I had to mention it, although
> it's not related to the main point! :) )
> and make another UI daemon (hopefully called ophoneuid for consistency) that
> will be responsible to offer the dbus methods
> and will stay aware of the current UI state of the phone.
> ophonekitd will keep it's current role (including calling for ui objects,
> just using dbus calls).

So mainly your other daemon would just wait for dbus calls from
ophonekitd. Ophonektid would only act as a wrapper. Hence, to me, no
need to do another daemon for that :-)

> Why the second option one is better:
>
> ophonekitd should register to GSM as soon as possible (hopefully at the very
> beginning of the boot sequence of the phone), if it'll host the GUI loop
> it'll have to wait for X to load in order to start (as it's doing now) which
> will slow everything down, and is bad in general.
> It'll be easier to implement reloading of frontend choosing without turning
> off GSM.

Actually we were intending to use libmodulo for that, which implies
we'll be able to restart/reload/suspend things without restarting the
actual process.
For X, as told mrmoku, we can (should) multithread.

-- 
Julien Cassignol
http://www.ainulindale.net