kdelirc news

[F. Scheffold]

Am Montag 15 Februar 2010 21:26:33 schrieb Michael Zanetti:
Hi,

at least I found  some time to answer...
> Hi,
> 
> back from holidays... Thanks for your input.
> 
> > > And no applet? What about IrKick? Wil there be no status indicator or
> > > another small control (of the remote control system, like switching IR
> > > on/off or showing input arriving?
> > 
> > Currently I implemented a plasmoid which can be integrated in the sytem
> > tray. It's not finished yet but I have something similar like the battery
> > applet on my mind. There you can set the mode and "mute" your remote
> > control, to ignore button events and launch the kcm configuration dialog.
> > The status indication will be triggered with the kde notification system.
> > Button presses are animated in the plasmoid icon.
> 
> 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. 

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....

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.

I'm also not sure what happened if plasma crashed. Maybe the kded trayed 
daemon will be also crashed...
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.


> > > >  It's more how the directories in the
> > > >  codebase are named. Anyways, if someone knows a better name (I know
> > > >  there are some people who hate Ksomething names) I'm open for
> > > >  suggestions.
> > > 
> > > So this name will not be visible, both in the UI and in the API? What
> > > about D- Bus object and interface names? The module/lib names might
> > > need to be unique, too.
> > > (e.g. libkremotecontrol/dbusinterface.cpp seems to use "org.kde.irkick"
> > > as D- Bus object name?)
> > 
> > The remote control daemon dbus interface is currently  registerd as node
> > in kded (modules/kremotecontrol).
> 
> I meant the name is not of any big importance for the user as IMO titles
> for the context menu and the systemsettings module should be named "Remote
> Controls" instead of "InsertSomeFancyNameHere". While for development I
> think the name should be as descriptive as possible and KRemoteControl
> matches it pretty well.
> 
> > > KRemoteControl sound sensible for the default implementation, K as
> > > namespace prefix and RemoteControl as generic describing name of the
> > > functionality.
> > > 
> > > Only problem might be that while at first remote control reminds of the
> > > classic remote control at first, in general computer systems this might
> > > be also used for other stuff (like remote desktop control or ), so the
> > > name alone might mislead an accidental by-passer of the
> > > directory/modules :) But not really a stopper.
> > 
Indeed the modules kcm and kded are integrated "deep" in systemsettings. 
A meaninful name would be mouch better there as a convient alias. So the user 
can see quickly for that the entry stands. At this point I agree with you.
My propsal for the name sounds perhaps better for a standalone application, 
maybe ;-)


> > For my opinion: I don't care how the app should be named.
> > K Remote Control Daemon (krcd) and K Remote Desktop Client (krdc) - ok
> > this sounds very similar to the user in the short form, Michael and I
> > also detected this. so we are not unhappy if anyone have a good concise
> > other name. I have an idea  this weekend to call it something like K
> > Couch Potato or Kouch Potato (or for the K hater's only Couch Potato)
> > wich should be indicate the possibility to control your apps with a
> > gagdet like a remote or so....But this I first have to discuss with
> > Michael. But I think, before we are moving it back in trunk and passed
> > review it's a good time to make some thougts about this and hear some
> > other suggestions.
> > 
> > In the end and as you mentioned: Our baby, our name ;-)
> 
> My vote still goes to KRemoteControl currently :)
> 
As I said, I don't care. Due to my answer above, KRemoteControl should be the 
best (I also need'nt to rename the current created classes and desktop files 
then ;-) ).

> > > > So if everyone (especially Friedrich) agrees with my proposal I would
> > > > like
> > > > 
> > > >  to merge the branch back in a month or so (when we are finished with
> > > >  polishing the ui and bringing back the last outstanding features).
> > > 
> > > If it's such a great rewrite it might be a good idea to pass officially
> > > through kdereview, especially if it also affects kdelibs/solid. Using a
> > > documented process should make it more simple for all invoved :)
> 
> There are no solid API changes contained in this step. The solid part is
> already delivered with 4.4. However, I agree that going through kdereview
> sounds reasonable right now.
> 
> > > Apart from that no objection, in fact it sounds really good what you
> > > have been doing.
> 
> Thanks,
> currently there is still quite some polishing work left to do so the move
> won't happen too soon. I'll keep you up to date.
> 
> Cheers,
> Michael

Cheers Frank