From: Fredrik T. <fr...@do...> - 2003-05-14 02:14:55
|
On Wednesday 14 May 2003 01:04, you wrote: > El Tuesday 13 May 2003 18:30, Rizsanyi Zsolt escribi=F3: > > Seemed like you are not really for using lircc as backend of > > finglonger. > > I'm not really sure, I think the main point for me is the DCOP > support in lirccd (and I hope the config file format can be > discussed too :) ) That depends on how you want to modify the config file format.=20 The main feature of lirccd is, after all, it's universal=20 configurability. While I do realize that it's not the easiest=20 format to parse for GUI applications, I wouldn't want to lose=20 functionality in favor of ease-of-use. We don't want another=20 Windows, right? As for DCOP, I have nothing against it if it's implemented in the=20 right way. You see, I don't want it to be mandatory for building=20 or using lirccd, so I want it to be configurable at build time=20 and autodetectable at run time. Far from all programs use DCOP,=20 after all. > > On Friday 09 May 2003 00.09, Antonio Larrosa Jim=E9nez wrote: > > > El Jueves, 8 de Mayo de 2003 10:38, Zsolt Rizsanyi=20 escribi=F3: > > > > > 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 > > > > > =09=09=09=09* command, or lirccd will wait for it > > > > > =09=09=09=09* 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 install a > > > file similar to kwintv.flp (Finglonger profile) where > > > finglonger can read it. as you see, it's quite simple and > > > standard configuration file format. The example is for > > > KWinTV, the TV viewer. > > > > > > finglonger_remote_AverTV_rc is the configuration of the > > > remote control, which is the one users modify (using > > > kcontrol) to "bind" key events to actions in the profiles. > > > > IMHO if you would use lircc as backend, then the way to go > > would be to drop the finglonger remote files (like > > finglonger_remote_AverTV_rc) and only use *.flp files. In > > that case finglonger would be only a kcm module to configure > > lircc. > > I suppose you mean using only *.flp files _and_ some other > config file (lirccd's config file) instead of finglonger's > remote file, isn't it ? Yeah. > Note that flp files only contains the interface that > applications export to the world, and the "remote files" > contain the actual bindings between the remote buttons and the > actions in each profile that should be run. So kcmfinglonger > (the kcontrol module) is mainly used to changes _just_ the > "remote files", and only in some cases the profile files (in > case the user would like to make his own profiles to manage > several applications without changing the profile or to define > custom actions). > > That is, each application should distribute a flp file which > would be "static", but that is completely independent from any > specific remote controls or from button informations. Yeah, I got that. > > To properly configure lircc for the KDE (or maybe other) > > apps it would use the *.flp files. > > > > What do you think about this suggestion? > > It would be great, but I hope you understand what it means: > lirccd should generate dcop calls (connecting to the dcop > server running on the current desktop). How does lirccd works > when there are multiple users in a system running different > applications? Is it owned by the user? or started by root at > the system runlevel scripts ? It is indeed owned by the user. The entire point of lirccd was to=20 have it as a per-user daemon, so to speak. I see no problem in=20 running lirccd as many users simultaneously, but on the other=20 hand I see no point in it either, since only one user will have=20 access to the actual remote control, right? On the other hand I=20 guess that lirccd should keep from running if logged in=20 remotely, however, since you don't want to receive IR messages=20 from the one logged in locally. I haven't thought of that until=20 now, but that shouldn't be too hard to fix, on the other hand. Currently, lirccd is started manually by the user when he/she=20 wants to use it, but I'm in the process of implementing in the=20 client library (for direct access, that is, not DCOP), so that=20 it will be started on-demand. Anyway, it's not started at system=20 boot. I'm guessing that in the case of finglonger, the kicker=20 applet would have to start it. > On other areas, how does lirccd support different profiles > currently? how does it report the status change? should it > emit dcop signals also when changing the status? I ask all > that because I planned to do a finglonger applet for kicker's > system tray that would display a different icon depending on > the state. How would that be possible when using lirccd? I guess it would be possible in two ways. The first would be to=20 make it part of lirccd's "DCOP interface", to emit DCOP signals=20 when the status changes. The way I'd prefer but you probably=20 wouldn't, would be to add it to the config file, though. Lirccd=20 has no problems in running code at status change. > I hope you understand that I had a lot of ideas in my mind and > I wouldn't like to change them if that means less features. > Otoh, if it's possible to be in a win-win situation, then the > better :). > > > AFAIK lircc provides that feature too. > > Ah, good. Actually, lirccd has a far more advanced feature there. It uses a=20 fully hierarchical menu system instead of .lircrc-like modes.=20 The problem is that you currently only can go to modes (or=20 binding trees, as I call them in lirccd terminology) that are=20 either subtrees of the current tree, or go to the parent tree of=20 the current tree. I'm planning on adding a tree jumping=20 function, though. > > I dont think it is a good idea to add dcop interface to non > > KDE > > DCOP is not only for KDE, there are DCOP bindings for C, > python, etc. They're there for being used :) Yeah, but let's face it. Not everyone would probably want to use=20 DCOP. It's not the only way of getting input, after all. > > It would be nice though if finglonger would allow > > configuring lircc for non KDE programs. Maybe a special > > *.flp files could be made for non-KDE programs which would > > be distributed with finglonger. > > Of course, that's what I wanted to do, but not really using > "special" flp files, but defining specialized action methods > instead of just DCOP calls and executing applications. In that case, lirccd is already up to the task. If you look at=20 the sample configuration files at the home page=20 (http://www.dolda2000.cjb.net/~fredrik/lirccd/) you will see=20 that lirccd can do virtually anything. And if there's a=20 functionality that you want that it doesn't have, it's really=20 easy to implement a function for it. > > I think this would be possible, at least for basic mplayer > > configuration. (Who need more can always edit lircc > > configuration files by hand) > > The problem I see with this is that I don't think applications > should support infrared remotes directly. Instead of that, > every application should have a generic scripting mechanism > (DCOP or other) which finglonger would use to make the > applications do actions. Indeed, if all programs used such an interface, it would be a=20 wonderful world. However, I really don't think that all=20 developers want to do that. And for example in MPlayer,=20 implementing a lirc communication layer isn't just easy, but=20 even elegant. > That's one of the main benefits of finglonger, suddenly, > _every_ kde application can be controlled from the remote > controller, even if they know nothing about lirc. For example, > I could download/upload my mail in kmail from the remote, or > navigate through a web page in konqueror (following links, > moving trough the page, etc.) . Indeed, that is really good. But like I said, it wouldn't be hard=20 to implement a DCOP calling function in lirccd, either. > > > > > 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 to configure it. > > > > Entering numbers is a so common feature of remotes that I > > think that it is worth even to have special handling for > > them. I dont know what would be needed for that though. > > I had clear from the beginning that I wanted to see a small > window next to finglonger's kicker applet with the numbers I > was pressing in the remote, but... > > > Not even the above line does solve the problem right, since > > there are people who have more than 10 channels (and want to > > switch to channel 32 for example) ;) I don't see how that would be a problem? Just change the regex=20 above to [0-9]+, and the problem should be solved, right? Also,=20 lirccd offers a smooth way to "simulate" that functionality for=20 remotes with only ten buttons as well. Consider this: global channel =3D ""; bind "[0-9]" channel +=3D button; bind "OK" { sendstring("appname", "channel " + channel); channel =3D ""; } I don't know about you, but I like it. > ... Exactly, that was the reason I kept wondering :) > Not that it's difficult to do, but it's complicated to find an > easy user interface for the user to configure that setting. That, however, I can easily understand. But shouldn't that be=20 possible to achieve with some kind of "common configurations" or=20 something like that. Like I've stated, I'm really no expert when=20 it comes to user-friendlyness, but say that you can have some=20 kind of "common configuration modules", that you then merge with=20 the flp files that the user chooses to use. Wouldn't something=20 like that be possible? > > > Well, the configuration module is nearly finished, and > > > once it's done, the only thing left would be the actual > > > daemon (which would dock in the panel to show some > > > feedback). Given that the internal data structures and all > > > > What kind of feedback would it show? > > Current profile, numbers being pressed, etc. That should be very possible to do if you implement with lirccd=20 if you add DCOP functionality to it. Say that you have a number=20 editing "common configuration module" like above. It could then=20 look something like this (I don't know how DCOP works, but you=20 should be able to see what I mean): global edit =3D ""; bind "[0-9]" { edit +=3D button; dcopsend("FLAppletIface", "SetEditString", array(edit)); } Think about it. Fredrik Tolf |