kdelirc news

[F. Scheffold]

Hi Friederich,

Am Samstag 13 Februar 2010 02:09:39 schrieb Friedrich W. H. Kossebau:
> Hi Michael (and Frank),
> 
> Jeudi, le 11 février 2010, à 15:33, Michael Zanetti a écrit:
> > Hello kdeutils team,
> > 
> > We from kdelirc have made some major changes in branches/work/kdelirc. We
> > 
> >  have refactored also the last parts from the old KDE3 version. The whole
> >  framework is now much more extensible for future development.
> > 
> > Also, since lircd handling has moved to solid we should now be able to
> > run
> > 
> >  on other platforms and support different types of remotes.
> > 
> > During the rework also the UI changed a bit and we have moved the systray
> > 
> >  app from a standalone app to a kded module.
> 
> Sounds like pretty and good work :)
> 
> > Because of those major changes I think the name KDELirc doesn't fit any
> > 
> >  more and would like to ask if I'm allowed to rename the application.
> 
> IMHO: Your baby, your name. And switching names to reflect new states
> sounds sensible.
> 
> >  Currently we are going for "KRemoteControl" as a more generic name.
> >  However, as we don't have an application in the menu any more (just a
> >  kded service and a Remote Control Configuration kcmshell plugin) the
> >  name isn't of any big importance any more.
> 
> 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.

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

> > 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 :)
> 
> Apart from that no objection, in fact it sounds really good what you have
> been doing.
> 
> Cheers
> Friedrich

Cheers Frank