kdelirc news

[Michael Zanetti]

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.

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

> > > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-utils-devel/attachments/20100215/5ca06a7b/attachment.sig