On Saturday 10 May 2008 17:09:25 Kevin Krammer wrote:
> Hi folks,
>
> earlier this week I renamed our (Akonadi's) D-Bus interfaces from org.kde
> to org.freedesktop namespace to avoid anybody seeing that as a KDE
> dependency.
>
> While doing that I encountered the one currently used between server and
> tray: org.freedesktop.akonaditray
>
> For those not following the development that closely, this basically allows
> the server, resources and agents to get some parent window when they need
> to open a window/dialog or to send notifications to.
>
> The current implementation is a system tray application
> (kdepim/akonadi/tray) since this is known to work on all desktop
> environments.
>
> However, a system tray is a specific implementation of this service, e.g.
> others might want to implement it as a Plasmoid or GNOME panel applet, so
> I'd prefer to have a more generic name for the service and its interface.
>
> Therefore I'd like to ask for suggestions, probably something like
> org.freedesktop.Akonadi.UserInterface
> or
> org.freedesktop.Akonadi.WindowPeer
>
> Cheers,
> Kevin

Why should the server have control of the GUI directly (i.e. have a concept of 
a UI or Window)? IMHO a server should just send out signals/notifications on 
which the UI should act. If a 'conversation' needs to take place, the server 
could send out a signal/notification synchronously, which triggers the UI to 
perform the conversation with the user, and then returns a result from the 
conversation.

This way the server can stick to the domain model, and the UI implementation 
does not need to conform to and expose a UI interface.

It all sounds a bit like a (indirect, through dbus) circular dependency to me.

grtz,
Sander


_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/