kdelirc news

[F. Scheffold]

Am Mittwoch 17 Februar 2010 19:26:44 schrieb Michael Zanetti:
Hi,

> On Wednesday 17 February 2010 18:59:36 F. Scheffold wrote:
> > > I'm still not sure if a plasmoid is of any real use here. The kded
> > > module features a KNotification item indicating any activity and
> > > having a context menu for interactions. I really can't see what a
> > > plasmoid could do better here... In fact, IMO it would bring more
> > > hazzle to the user forcing it to add the plasmoid manually to the
> > > panel for just exactly the same functionality as the notification item
> > > brings out of the box.
> > 
> > My thoughts:
> > 
> > As the readme on the api reference says, a kded daemon is a service that
> > runs in the background and performs a number of small tasks.
> > 
> > For my opinion a daemon (background process) should not provide a
> > interface to provide direct user interaction. This should be done by a
> > seperate user interface, which communicates with the daemon. So you have
> > it loosely coupled.
> 
> KNotificationItem is "loosely coupled". It is a standard interface,
> communicating to the actual tray item over DBus. The whole DBus stuff is
> just hidden in the KNotificationItem.
> 
I did not talk about knotification.  I meant  the tray applet, there you can 
select  the current remote's mode and launch the kcm configuration utiliity 
like the functionallity which the current irkick provides. And that should not 
be part of the kded daemon krcd. Using knotification (as dbus message 
notifier) inside is ok.

> > Common example like powerdevil or networkmanager do this in excat the
> > described way. They have no tray, they provide the interaction with a
> > plasmoid over a dataengine and a kcm module. And they get events like
> > your battery gets low or network gets unavailable with signals from the
> > daemon handle to display. The other daemons e.g. khotkeys do not provide
> > a status indiaction tray, only a seperate kcm configuration module for
> > setup. Currently I don't know any kded daemon which uses a tray....
> 
> Check out knetworkmanager, korganizer etc...
> 
korganizer is a application like kmail or kopete which has no kded daemon. Its 
just currently launched via a desktop file in /usr/share/autostart/.

Networkmanager consists of a kded daemon but the tray icon which provides
setting up a network connection and launches the kcm shell 
"kcm_networkmanagement_tray" is a seperate application (called 
knetworkmanager). In this shell you can setup to show / hide the tray icon.
The kded daemon which monitors the status of the network interfaces can be 
started via systemsettings -> service manager.

> > And since kde 4.4 you are able to integrate plasma popup widget's (like
> > battery  or network) direct in you systemtray . Just click settings for
> > the tray and choose plasma mini programs and then you got it. The user
> > only must do this at one time to get the applet available in tray.
> 
> Still a useless interaction... Enabling the daemon through the kcm module
> (like networkmanagement does) seems enough to me... Don't wanna have to add
> a plasmoid manually here.
> 
> > I'm also not sure what happened if plasma crashed. Maybe the kded trayed
> > daemon will be also crashed...
> 
> A tray crash would not even be noticed by the daemon. The NotificationItem
> returns as soon as any system tray application (implementing the
> freedesktop notification standard) registers again.
> 
In this case you're right. But not sure if a the kded daemon implements the ui 
for the tray.

> This brings me to another pro for the NotificationItem: It works also on
> other desktop environments (without plasma) that implement the standard
> (e.g. gnome).
> 

> > The  other question is what the "common kde way" is to handle such
> > issues. Maybe we should investigate these things first before we make a
> > decision.
> 
> As far as I can see plasmoids are only used if UI elements not available in
> standard context menus are needed. I see our use case just like the
> KOrganizer daemon. Its signalling status changes and provides very little
> interaction in a context menu.
> 

I think we're talking past to  each other.

A seperate tray program plasma or small app which talks to the kded daemon 
would be nice and I think wanted by the users. So we can provide the current 
user interaction like it's current in irkick. In this case a plasma applet 
would be nice for kde users, while the other way a kde tray app can be used in 
other window managers. In this case I agree.

We can provide the data engine as it is currently implemented in the work 
branch and I can implement a plasma applet outside from kdelirc when the 
refactoring is done and time is left ;-). A least we provide a interface for 
this then. So a kde user has then the choice using the plasma or the kde tray 
app which can be launched via autostart. In other window managers the tray app 
satisfies the users need.


Cheers Frank


> Cheers,
> Michael