Re: New client program - lirccd

[Antonio L. <la...@kd...>]

El Jueves, 8 de Mayo de 2003 10:38, Zsolt Rizsanyi escribi=F3:
> I'm CCing this to Antonio Larrosa Jim=E9nez, since maybe he will be also
> interessted.

Sure, I'm interested.

> Note to him: The first mail regarding this topic can be found at:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D2056376&forum_id=
=3D
>5339

Thanks.

> > On Thursday 08 May 2003 02:13, Zsolt Rizsanyi wrote:
> > > I pretty much like the idea of using a client daemon to handle
> > > state information and I think it is a must for a really
> > > featurefull use of lirc.

Definitely.

> >
> > bind "Rewind" sendstring("mplayer", "seek -10");
> > bind "FF" sendstring("mplayer", "seek +10");
> > bind "Play" exec("gmplayer &"); /* Note that you have to include
> > 				* an ampersand (&) at the end of the
> > 				* command, or lirccd will wait for it
> > 				* to complete. */
> >

I've attached the sample configuration of Finglonger in two files.
Some of it doesn't work yet, but there's really little left to finish it.
first, every application that wants to make use of a remote control, should=
=20
install a file similar to kwintv.flp (Finglonger profile) where finglonger=
=20
can read it. as you see, it's quite simple and standard configuration file=
=20
format. The example is for KWinTV, the TV viewer.

finglonger_remote_AverTV_rc is the configuration of the remote control,=20
which is the one users modify (using kcontrol) to "bind" key events to=20
actions in the profiles.

Note that I'm talking about profiles because that's one of the new things=20
that finglonger provides. The ability for a button to do something=20
different depending on the current profile. For example, a CHANNEL_UP
button may make KWinTV change channel if we're in the KWinTV profile, but=20
change the song played by xmms or noatun if we're in the respective=20
profile.

> > While this doesn't necessary fully make sense to someone without
> > programming experience, I'd say that it's certainly not
> > impossible to understand, and especially not to extend. See
> > below as well.
>
> It is pretty much easy for everybody who also does configure mplayer by
> hand
>

One of my ideas was to provide mplayer with a dcop interface, that way, it=
=20
would be _really_ simple to script it and also to make a finglonger=20
profile for it. If someone wants to help me with that, I can provide some=20
information.

> > It also includes the actual button name in the variable "button",
> > as well, so this might be appealing to you:
> > bind "[0-9]" sendstring("appname", "channel " + button);

I was thinking to do something like it but wasn't sure of how to do the GUI=
=20
to configure it.

> > > Also I would like to note, that there is a project to develop
> > > one place graphical configuration for all the KDE programs.
> > > The project is in very early stages, but it aimed to create a
> > > client daemon for handling state information. It would be much
> > > better if lircc could be used instead of developing a separate
> > > daemon.
> >
> > I'm not sure what you mean. Is there this a project to configure
> > all KDE programs for LIRC?
>
> Yes there is. Its called finglonger, and it is more like in planning
> stages. It is the idea of Antonio Larrosa Jimenez.

Well, the configuration module is nearly finished, and once it's done, the=
=20
only thing left would be the actual daemon (which would dock in the panel=20
to show some feedback). Given that the internal data structures and all=20
that is nearly finished (because it was done for the configuring module).=20
I can say there's little more to do. The only problem is that I have exams=
=20
in next month and I have a work, so I'm short on free time to work on it.

> It can be found in KDE cvs under kdenonbeta/finglonger

yep, if someone wants to help, you'll be welcome.

> It will work like this: Every (KDE) program which wants lirc input
> provides a profile file with all the available actions which can be
> executed on the program (eg. a tv viewer app would provide actions like
> fullscreen, chanup, chandown, ch [num]), and the necessary dcop message
> needed to send to the program when that action happens.
> (dcop is a method to send commands to apps from other applications or
> from the shell using the kdcop application)

yes, and don't forget the dcop bindings for C, python, perl, etc.

> Then a Kontrol Center module would allow configuration, where you bind
> the buttons of your remote (read from the lirc socket) to the various
> actions of the available programs.

You can see some (old) screenshots at:
http://developer.kde.org/~larrosa/tmp/kcmremote1.png
http://developer.kde.org/~larrosa/tmp/kcmremote2.png
=2E..
http://developer.kde.org/~larrosa/tmp/kcmremote5.png

> With the current plans this configuration would be saved in KDE config
> files and read by a separate KDE Lirc daemon along with the action
> definitions and would send the appropriate dcop messages to when a lirc
> keypress event arrives.

It won't just do dcop calls, but also execute apps, and probably other ways=
=20
to pass messages between apps (if any). Although of course, the preferred=20
method would be to use dcop calls, because an application providing a dcop=
=20
interface wouldn't just be controlled from a remote controller, but also=20
from scripts, other apps or whatever.

> IMHO it would be nice if there would be no need for two separate daemons
> for KDE and non KDE programs.
> But for that, all the features planned for KDE should be provided by
> your lirccd.

I hope we can join efforts.

> I will forward this mail also Antonio Larossa Jimenez to maybe get his
> ideas too.

Thanks for forwarding it.

Greetings,

=2D-
Antonio Larrosa Jimenez
KDE developer - la...@kd...
http://developer.kde.org/~larrosa/
=46urious activity is no substitute for understanding.