From: Fredrik T. <fr...@do...> - 2003-05-02 19:22:59
|
Hi all! I know I've been on you about this before, but please consider it. I've been designing a client program for LIRC - lirccd (lirc client=20 daemon), that features extremely flexible configuration, and a better=20 way to implement other client programs (since lirccd handles all the=20 state information instead of letting liblirc_client do it). The project's site is as follows: http://www.dolda2000.cjb.net/~fredrik/lirccd/ Please, at least put up a link to it on the LIRC applications page on=20 lirc.org. I did write this in the purpose of using it, and IMHO I=20 think it's really good, and it has served me really well. The only=20 thing is that the documentation isn't really too good. I have also made a patch for MPlayer which makes use of it, and it's a=20 really good thing in itself as well. Thank you very much for providing LIRC! Fredrik Tolf |
From: <col...@hi...> - 2003-05-04 09:15:51
|
Hi! Fredrik Tolf "fr...@do..." wrote: [...] > I've been designing a client program for LIRC - lirccd (lirc client > daemon), that features extremely flexible configuration, and a better > way to implement other client programs (since lirccd handles all the > state information instead of letting liblirc_client do it). I have already thought about modifying liblirc_client to support a client daemon that could manage the state for all aplications. liblirc_client would connect to the client daemon using some IPC method (pipe, socket, etc.). The major point here is that my changes wouldn't change the current API and no client program would have to be modified. As the client daemon would have to read the config file, liblirc_client also won't be bound to the current config file semantics anymore. I thought of adding a Sha-Bang like line to the config file which will tell liblirc_client which client daemon should be invoked: #! /usr/bin/lirc_clientd Of course you could drop-in your daemon here as well, as long as the behaviour of the daemon is standardized in some way. That way the user has the choice which config file format he wants to use. Fredrik, maybe you may want to follow-up on this idea and work it out? I just don't see how I could have the time to do it myself. Christoph |
From: Fredrik T. <fr...@do...> - 2003-05-04 21:49:12
|
On Saturday 03 May 2003 21:48, Christoph Bartelmus wrote: > Hi! > > Fredrik Tolf "fr...@do..." wrote: > [...] > > > I've been designing a client program for LIRC - lirccd (lirc > > client daemon), that features extremely flexible configuration, > > and a better way to implement other client programs (since lirccd > > handles all the state information instead of letting > > liblirc_client do it). > > I have already thought about modifying liblirc_client to support a > client daemon that could manage the state for all aplications. > liblirc_client would connect to the client daemon using some IPC > method (pipe, socket, etc.). That's precisely what my liblircc does right now. The socket name is=20 ~/.lircc, and the configuration file's name is ~/.lirccrc. Both of=20 these are overridable with cmdline options, though. > The major point here is that my changes wouldn't change the current > API and no client program would have to be modified. As the client > daemon would have to read the config file, liblirc_client also > won't be bound to the current config file semantics anymore. At first, this was my thought as well. Actually, I don't really=20 remember why I didn't get around to actually implement it. The thing=20 is, of course, that lirccd does work a bit differently. The idea is=20 that after the client has connected to the socket, it sends its name=20 over it to lirccd, and in that way, lirccd can filter the commands to=20 only send the commands to the client that it's actually intended for. The greatest advantage is that liblircc only has three functions: the=20 initializer function, the cleanup function, and the function to read=20 the next command. There is also a reentrant version of the last one,=20 so four really. I don't think that it would actually be a problem for me to implement=20 a compatibility library, though. It would just be that most functions=20 would be noops. > I thought of adding a Sha-Bang like line to the config file which > will tell liblirc_client which client daemon should be invoked: > > #! /usr/bin/lirc_clientd That is an idea, of course, which I hadn't though of, but seems pretty=20 smart. It does of course pose some problems since my current config=20 file format is C-based, though, and cpp doesn't like Sha-Bang lines.=20 I could, of course, just read the first line before passing it to=20 cpp. That feels like a pretty ugly hack, though, I must say. I'm sure=20 I can work it out, though. Of course, I would personally recommend that lirccd be started at=20 login time, because it has quite much value in itself, as well. I use=20 it, for example, as a LIRC-controlled MP3 player, and much more is=20 possible. Though, if you don't use it as such, I guess it is better to make the=20 first client program start it for you. > Fredrik, maybe you may want to follow-up on this idea and work it > out? I just don't see how I could have the time to do it myself. I would be pleased to. I would be honored just to get my name in the=20 LIRC distribution, not to mention the entire program. Fredrik Tolf |
From: Manuel E. S. <ran...@ra...> - 2003-05-07 19:29:05
|
On Sun, May 04, 2003 at 11:48:06PM +0200, Fredrik Tolf wrote: > On Saturday 03 May 2003 21:48, Christoph Bartelmus wrote: > > Hi! > > > > Fredrik Tolf "fr...@do..." wrote: > > [...] > > > > > I've been designing a client program for LIRC - lirccd (lirc > > > client daemon), that features extremely flexible configuration, > > > and a better way to implement other client programs (since lirccd > > > handles all the state information instead of letting > > > liblirc_client do it). > > > > I have already thought about modifying liblirc_client to support a > > client daemon that could manage the state for all aplications. > > liblirc_client would connect to the client daemon using some IPC > > method (pipe, socket, etc.). > > That's precisely what my liblircc does right now. The socket name is > ~/.lircc, and the configuration file's name is ~/.lirccrc. Both of > these are overridable with cmdline options, though. > > > The major point here is that my changes wouldn't change the current > > API and no client program would have to be modified. As the client > > daemon would have to read the config file, liblirc_client also > > won't be bound to the current config file semantics anymore. > > At first, this was my thought as well. Actually, I don't really > remember why I didn't get around to actually implement it. The thing > is, of course, that lirccd does work a bit differently. The idea is > that after the client has connected to the socket, it sends its name > over it to lirccd, and in that way, lirccd can filter the commands to > only send the commands to the client that it's actually intended for. > The greatest advantage is that liblircc only has three functions: the > initializer function, the cleanup function, and the function to read > the next command. There is also a reentrant version of the last one, > so four really. > I don't think that it would actually be a problem for me to implement > a compatibility library, though. It would just be that most functions > would be noops. At first look (very quick one, didn't even look at the code) I would split liblirc_client into a thin library and a daemon in the sense of lirccd, then integrate liblircc with the library and offer lirccd as an alternative for the new daemon. > > I thought of adding a Sha-Bang like line to the config file which > > will tell liblirc_client which client daemon should be invoked: > > > > #! /usr/bin/lirc_clientd > > That is an idea, of course, which I hadn't though of, but seems pretty > smart. It does of course pose some problems since my current config > file format is C-based, though, and cpp doesn't like Sha-Bang lines. > I could, of course, just read the first line before passing it to > cpp. That feels like a pretty ugly hack, though, I must say. I'm sure > I can work it out, though. > > Of course, I would personally recommend that lirccd be started at > login time, because it has quite much value in itself, as well. I use > it, for example, as a LIRC-controlled MP3 player, and much more is > possible. > Though, if you don't use it as such, I guess it is better to make the > first client program start it for you. > > > Fredrik, maybe you may want to follow-up on this idea and work it > > out? I just don't see how I could have the time to do it myself. > > I would be pleased to. I would be honored just to get my name in the > LIRC distribution, not to mention the entire program. This stuff has been in my todo for a long time too. I'll work with you to make it a reality. I'll look at all relevant code and follow up on the issue. Have a nice day Manuel -- --- Manuel Estrada Sainz <ra...@de...> <ra...@bi...> <ra...@us...> ------------------------ <man...@hi...> ------------------- Let us have the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference. |
From: Fredrik T. <fr...@do...> - 2003-05-07 22:39:52
|
On Wednesday 07 May 2003 21:26, Manuel Estrada Sainz wrote: > On Sun, May 04, 2003 at 11:48:06PM +0200, Fredrik Tolf wrote: > > On Saturday 03 May 2003 21:48, Christoph Bartelmus wrote: > > > Hi! > > > > > > Fredrik Tolf "fr...@do..." wrote: > > > [...] > > > > > > > I've been designing a client program for LIRC - lirccd > > > > (lirc client daemon), that features extremely flexible > > > > configuration, and a better way to implement other > > > > client programs (since lirccd handles all the state > > > > information instead of letting liblirc_client do it). > > > > > > I have already thought about modifying liblirc_client to > > > support a client daemon that could manage the state for > > > all aplications. liblirc_client would connect to the > > > client daemon using some IPC method (pipe, socket, etc.). > > > > That's precisely what my liblircc does right now. The socket > > name is ~/.lircc, and the configuration file's name is > > ~/.lirccrc. Both of these are overridable with cmdline > > options, though. > > > > > The major point here is that my changes wouldn't change > > > the current API and no client program would have to be > > > modified. As the client daemon would have to read the > > > config file, liblirc_client also won't be bound to the > > > current config file semantics anymore. > > > > At first, this was my thought as well. Actually, I don't > > really remember why I didn't get around to actually > > implement it. The thing is, of course, that lirccd does work > > a bit differently. The idea is that after the client has > > connected to the socket, it sends its name over it to > > lirccd, and in that way, lirccd can filter the commands to > > only send the commands to the client that it's actually > > intended for. The greatest advantage is that liblircc only > > has three functions: the initializer function, the cleanup > > function, and the function to read the next command. There > > is also a reentrant version of the last one, so four really. > > I don't think that it would actually be a problem for me to > > implement a compatibility library, though. It would just be > > that most functions would be noops. > > At first look (very quick one, didn't even look at the code) > I would split liblirc_client into a thin library and a daemon > in the sense of lirccd, then integrate liblircc with the > library and offer lirccd as an alternative for the new daemon. Indeed, that was precisely my idea of the optimal solution, but=20 currently I don't know enough about the lircrc config file=20 format to do that. It requires some standardization of the=20 interface though. I'll get back to that in the end of this mail. > > > I thought of adding a Sha-Bang like line to the config > > > file which will tell liblirc_client which client daemon > > > should be invoked: > > > > > > #! /usr/bin/lirc_clientd > > > > That is an idea, of course, which I hadn't though of, but > > seems pretty smart. It does of course pose some problems > > since my current config file format is C-based, though, and > > cpp doesn't like Sha-Bang lines. I could, of course, just > > read the first line before passing it to cpp. That feels > > like a pretty ugly hack, though, I must say. I'm sure I can > > work it out, though. > > > > Of course, I would personally recommend that lirccd be > > started at login time, because it has quite much value in > > itself, as well. I use it, for example, as a LIRC-controlled > > MP3 player, and much more is possible. > > Though, if you don't use it as such, I guess it is better to > > make the first client program start it for you. > > > > > Fredrik, maybe you may want to follow-up on this idea and > > > work it out? I just don't see how I could have the time to > > > do it myself. > > > > I would be pleased to. I would be honored just to get my > > name in the LIRC distribution, not to mention the entire > > program. > > This stuff has been in my todo for a long time too. I'll work > with you to make it a reality. > > I'll look at all relevant code and follow up on the issue. Very nice of you! Anyhow, back to the actual stuff. To support multiple daemons, we=20 will of course need a standardized interface, like I mentioned=20 above. My current "protocol" is this: The client (using liblircc)=20 connects to the daemon's socket, sends its name followed by a=20 newline. Then the daemon sends the commands back, one per line,=20 as they arrive. Unless you would want some kind of=20 bi-directional protocol (something RPC-like might be a good=20 feature, but I haven't though about it any closer), I see=20 nothing wrong with keeping it that way. Then we get to the issue of starting the client daemon. The best=20 thing for most people would be to have liblirc_client start it=20 if it isn't already running, I guess. Personally, I don't want=20 to be limited to that, though. My lirccd has many uses apart=20 from being a interface daemon between lircd and the clients, so=20 I start it at system boot. Therefore, I would like to suggest an=20 option (-c or something), which tells the daemon to start in=20 client mode, which would also mean that it will terminate=20 automatically when the last client disconnects from it. Of course, liblirc_client will also have to know which daemon to=20 start. Christoph suggested suggested a Sha-Bang line in .lircrc,=20 and despite all its elegance, I must take a stance against it.=20 Since my program pipes the config file though cpp, cpp will=20 complain about the Sha-Bang line, which in my eyes isn't=20 preferrable. Instead, I would like to suggest that=20 liblirc_client opens .lircrc and reads the first line from it.=20 It then matches that line against a standardized regexp, and=20 uses the first submatch to find the daemon. That way, the line=20 may be commented out in any way that the client daemon author=20 would prefer. I would suggest this regexp: exec: ?([^[:blank:]]+) If it fails to match, the first lirc_clientd found in the PATH is=20 used. This way, users of my lirccd could use a line like this: /* exec: /usr/local/bin/lirccd */ While other daemon can use whatever commenting they feel is=20 appropriate. Also, liblirc_client currently contains many functions that won't=20 be necessary with a client daemon. With the current protocol,=20 liblircc contains exactly the functions that are needed for=20 client programs: lircc_init, lircc_cleanup and lircc_getstr (to=20 get the next command). Therefore, if the protocol isn't going to=20 be changed, I would strongly suggest keeping liblirc_client only=20 for legacy purposes, and provide liblircc for newer clients.=20 liblirc_client would provide noops or whatever might be=20 appropriate for legacy purposes and link the appropriate=20 functions to liblircc, and liblircc would be changed for the=20 actual client daemon interaction. Don't you agree? So in short, my suggestion for the LIRC client initialization=20 routine is this: 1. lircc_init is called with the client's name. 2. lircc_init tries to connect to the client daemon socket, and=20 if it succeeds, it skips to step 7. 3. If the connection fails, lircc_init opens the configuration=20 file ~/.lircrc. 4. It reads the first line, and matches it against the standard=20 regexp. 5. It forks out the client daemon that it got, using the -c=20 option. 6. It waits for the client daemon to daemonize, and then skips=20 back to step 2. 7. lircc_init sends the client's name over the socket, followed=20 by a newline, and returns to the caller. 8. The client reads commands with lircc_getstr or lircc_getstr_r,=20 whichever is appropriate. 9. The client terminates the LIRC connection with lircc_cleanup. 10. If that was the last client disconnecting, the client daemon=20 terminates if it was started with the -c option. What do you think? Any comments? It's enough to satisfy me at=20 least. Fredrik Tolf |
From: Manuel E. S. <ran...@ra...> - 2003-05-16 14:45:08
|
On Thu, May 08, 2003 at 12:38:36AM +0200, Fredrik Tolf wrote: > On Wednesday 07 May 2003 21:26, Manuel Estrada Sainz wrote: > > On Sun, May 04, 2003 at 11:48:06PM +0200, Fredrik Tolf wrote: > > > On Saturday 03 May 2003 21:48, Christoph Bartelmus wrote: [snip] > > At first look (very quick one, didn't even look at the code) > > I would split liblirc_client into a thin library and a daemon > > in the sense of lirccd, then integrate liblircc with the > > library and offer lirccd as an alternative for the new daemon. > > Indeed, that was precisely my idea of the optimal solution, but > currently I don't know enough about the lircrc config file > format to do that. It requires some standardization of the > interface though. The interface should be pretty simple, it should not be that hard to standardize. > > > > I thought of adding a Sha-Bang like line to the config > > > > file which will tell liblirc_client which client daemon > > > > should be invoked: > > > > > > > > #! /usr/bin/lirc_clientd > > > > > > That is an idea, of course, which I hadn't though of, but > > > seems pretty smart. It does of course pose some problems > > > since my current config file format is C-based, though, and > > > cpp doesn't like Sha-Bang lines. I could, of course, just > > > read the first line before passing it to cpp. That feels > > > like a pretty ugly hack, though, I must say. I'm sure I can > > > work it out, though. > > > > > > Of course, I would personally recommend that lirccd be > > > started at login time, because it has quite much value in > > > itself, as well. I use it, for example, as a LIRC-controlled > > > MP3 player, and much more is possible. > > > Though, if you don't use it as such, I guess it is better to > > > make the first client program start it for you. > > > > > > > Fredrik, maybe you may want to follow-up on this idea and > > > > work it out? I just don't see how I could have the time to > > > > do it myself. > > > > > > I would be pleased to. I would be honored just to get my > > > name in the LIRC distribution, not to mention the entire > > > program. > > > > This stuff has been in my todo for a long time too. I'll work > > with you to make it a reality. > > > > I'll look at all relevant code and follow up on the issue. > > Very nice of you! As you see, it is going to take a little time, but I'm on it, I promise :) > Anyhow, back to the actual stuff. To support multiple daemons, we > will of course need a standardized interface, like I mentioned > above. > > My current "protocol" is this: The client (using liblircc) > connects to the daemon's socket, sends its name followed by a > newline. Then the daemon sends the commands back, one per line, > as they arrive. Unless you would want some kind of > bi-directional protocol (something RPC-like might be a good > feature, but I haven't though about it any closer), I see > nothing wrong with keeping it that way. I would add some optional stuff to that: - client connects to the daemon's socket - sends: "name [param1 [param2 [ param3 [...]]]]\n" - the daemon will ignore any param? that it doesn't know about. - the daemon sends back commands with all information about the event: ej: "000000000000102e 03 FULL_SCREEN Hauppauge" setstation prev - In the common case, liblircc/liblirc_client can strip the first four. - the client can send commands back to the daemon one per line: ej: switch_mode xawtv\n - the daemon will ignore any command that it doesn't know about. For the simple case, this is just almost what you have now, but it can easily be extended later. I just made it up, comments are welcome of course. > Then we get to the issue of starting the client daemon. The best > thing for most people would be to have liblirc_client start it > if it isn't already running, I guess. Personally, I don't want > to be limited to that, though. My lirccd has many uses apart > from being a interface daemon between lircd and the clients, so > I start it at system boot. Therefore, I would like to suggest an > option (-c or something), which tells the daemon to start in > client mode, which would also mean that it will terminate > automatically when the last client disconnects from it. Sounds good to me. > Of course, liblirc_client will also have to know which daemon to > start. Christoph suggested suggested a Sha-Bang line in .lircrc, > and despite all its elegance, I must take a stance against it. > Since my program pipes the config file though cpp, cpp will > complain about the Sha-Bang line, which in my eyes isn't > preferrable. Instead, I would like to suggest that > liblirc_client opens .lircrc and reads the first line from it. > It then matches that line against a standardized regexp, and > uses the first submatch to find the daemon. That way, the line > may be commented out in any way that the client daemon author > would prefer. I would suggest this regexp: > exec: ?([^[:blank:]]+) > If it fails to match, the first lirc_clientd found in the PATH is > used. > This way, users of my lirccd could use a line like this: > /* exec: /usr/local/bin/lirccd */ > While other daemon can use whatever commenting they feel is > appropriate. Sounds good too. > Also, liblirc_client currently contains many functions that won't > be necessary with a client daemon. With the current protocol, > liblircc contains exactly the functions that are needed for > client programs: lircc_init, lircc_cleanup and lircc_getstr (to > get the next command). Therefore, if the protocol isn't going to > be changed, I would strongly suggest keeping liblirc_client only > for legacy purposes, and provide liblircc for newer clients. I find that too revolutionary, but we will see as we go along. > liblirc_client would provide noops or whatever might be > appropriate for legacy purposes I don't see so much noops: lirc_init: lirc_deinit: This are essential. lirc_readconfig: lirc_freeconfig: OK, this should be noops. lirc_nextir: lirc_ir2char: They are already tagged obsolete, we can probably just remove them. lirc_nextcode: lirc_code2char: It may not be the perfect interface, but they have to stay for compatibility. I would add to that: lirc_getcmd: strips any extra information and gives plain commands. lirc_getevent: gives the full string of events, maybe even preprocessed in an struct. Now that I think of it, there should be some way for client's to connect directly to lircd skiping the extra daemon. > and link the appropriate functions to liblircc, and liblircc would be > changed for the actual client daemon interaction. Don't you agree? I would rather extend liblirc_client, rather than replace it. > So in short, my suggestion for the LIRC client initialization > routine is this: > 1. lircc_init is called with the client's name. > 2. lircc_init tries to connect to the client daemon socket, and > if it succeeds, it skips to step 7. > 3. If the connection fails, lircc_init opens the configuration > file ~/.lircrc. > 4. It reads the first line, and matches it against the standard > regexp. > 5. It forks out the client daemon that it got, using the -c > option. > 6. It waits for the client daemon to daemonize, and then skips > back to step 2. > 7. lircc_init sends the client's name over the socket, followed > by a newline, and returns to the caller. > 8. The client reads commands with lircc_getstr or lircc_getstr_r, > whichever is appropriate. > 9. The client terminates the LIRC connection with lircc_cleanup. > 10. If that was the last client disconnecting, the client daemon > terminates if it was started with the -c option. Apart from my protocol proposal above and not wanting to replace liblirc_client, I fully agree :) Any comments? Anyway, until I really get my hands dirty with it, I won't be sure of my own opinion :) Have a nice day Manuel -- --- Manuel Estrada Sainz <ra...@de...> <ra...@bi...> <ra...@us...> ------------------------ <man...@hi...> ------------------- Let us have the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference. |
From: Fredrik T. <fr...@do...> - 2003-05-20 17:38:32
|
On Tuesday 20 May 2003 10:45, you wrote: > On Tue, May 20, 2003 at 01:10:09AM +0200, Fredrik Tolf wrote: > > On Friday 16 May 2003 16:43, you wrote: > > > On Thu, May 08, 2003 at 12:38:36AM +0200, Fredrik Tolf=20 wrote: > > > > On Wednesday 07 May 2003 21:26, Manuel Estrada Sainz=20 wrote: > > > > > On Sun, May 04, 2003 at 11:48:06PM +0200, Fredrik Tolf > > > > wrote: > > > > > > On Saturday 03 May 2003 21:48, Christoph Bartelmus > > > > > > wrote: > > [snip] > > > > I would add some optional stuff to that: > > > > > > - client connects to the daemon's socket > > > - sends: "name [param1 [param2 [ param3 [...]]]]\n" > > > =09- the daemon will ignore any param? that it doesn't know > > > about. - the daemon sends back commands with all > > > information about the event: ej: "000000000000102e 03 > > > FULL_SCREEN Hauppauge" setstation prev - In the common > > > case, > > > liblircc/liblirc_client can strip the first four. > > > - the client can send commands back to the daemon one per > > > line: ej: switch_mode xawtv\n > > > =09- the daemon will ignore any command that it doesn't > > > know about. > > > > > > For the simple case, this is just almost what you have > > > now, but it can easily be extended later. > > > > > > I just made it up, comments are welcome of course. > > > > Sounds good to me. Only one thing... for the commands that > > the clients send to the daemon, don't you think that it > > would be better to implement something RPC-like, ie. the > > client blocks until it receives a response (which should, of > > course, come very, very fast)? That way the daemon could > > return if it doesn't support the call, as well as any > > user-defined reply. > > I don't want to make that synchronous, but I guess that there > where too much ignoring :) > > How about adding a tag to client->daemon commands and > allowing async responses? > e.g. > > =09Client says: "03 switch_mode xawtv\n" > =09and later maybe even after some other messages, the daemon > says: "reply 03 done" > > =09The IMAP protocol may be worth taking a look, they do this > =09stuff. I like IMAP, too, but I think that's really overkill here. It's=20 not like the client daemon is going to be multithreaded or=20 something. I do realize that there are uses for it outside=20 multithreading, too, but then again, isn't it overkill in this=20 situation? It would be much easier if we didn't have to keep=20 track of all issued commands. > With this, the protocol doesn't force synchronous behavior, > although the library could block until it gets the answer if > needed. Precisely what I was thinking, too. > And I guess that we could also use this for the first 'init' > line to complain about [param1 [param2 [ param3 [...]]]] > insted of just ignoring unknown: > > =09-> "00 xawtv param1 param2\n" > =09<- "reply 00 param1 ERROR\n" That's not the best solution though. Isn't it much easier, in=20 that case, to simply include a command to set the client name?=20 That way there won't be any special cases around that. It also=20 allows for clients to change their names later, if needed for=20 some reason. Also, do we need quoting? Should we run the entire thing through=20 wordexp() (with WRDE_NOCMD)? One more thing... Maybe the reply command (from the client=20 daemon) shouldn't be named reply. Many programs, eg. MPlayer,=20 already have built-in command sets, and we don't want to limit=20 the namespace, right? I believe lirc_reply would be a better=20 name. I'd like to specify a more HTTP-like answer line from the daemon,=20 ie. first a numerical response, and then a textual=20 interpretation and/or parameters, like this: -> setname xawtv param1 param2 <- 100 1 To indicate that parameter 1 was erroneous. Maybe a=20 human-readable explanation could follow after the required=20 parameters in the response, like "100 1 Invalid state", if, for=20 example, xawtv tried to set an initial state that didn't exist=20 or something like that. [snip]=20 > > > Now that I think of it, there should be some way for > > > client's to connect directly to lircd skiping the extra > > > daemon. > > > > You sure about that? Would that even be using the old > > configuration parser in the library? > > No, the library should only care about the first line of the > config file, to know what daemon to use. > > > If you're just referring to listening to absolute button > > presses from lircd, then shouldn't that just be implemented > > directly in the client, without a library? > > To get absolute button presses, the daemon could just proxy > them. One of those paramX could mean "I want it all". Or maybe > a command could switch between 'filtered' and 'raw' modes. > > I probably shouldn't have said "directly", I just want to > make sure that all functionality is still available to > clients. > > > Or is that just me? > > I am thinking about lircrc_config right now, it needs both to > get absolute button presses and to be able to ask lircd about > remote and button lists. > > And now that there will be an arbitration daemon, it would be > nice to have exclusive access. So you don't trigger anything > while you push the different buttons for configuration. Interesting ideas. I like all of it. I would want to set raw mode=20 as a seperate command, not as part of the initalization=20 parameters. The exclusive access is really interesting, and=20 certainly a really good idea. Now I thought of something else, as well. Maybe the lines coming=20 from the client daemon should all contain a command for the=20 library first. If a command comes from a button press, it could=20 look like "cmd channel 10", if a reply comes from a command, it=20 could be "reply 100 1 Error", and a raw button press (if=20 enabled) could be "raw code rep button remote". That way we=20 wouldn't have to limit the command namespace for the clients,=20 either. It also makes it easy not to make it necessary to pass a=20 client name, since not doing that will simply disable "cmd"=20 commands to be sent from the daemon. What do you think? > > > [snip] > > > > Sounds good enough. I've already started out a little with > > implementing a new liblirc_client from scratch. Correct me > > if I'm wrong, but it shouldn't implement a configuration > > parser at all, right? That's the purpose of having a client > > daemon, after all. Therefore I thought it best to implement > > a new liblirc_client all from scratch. > > I would rather split the current liblirc_client library and > start any of the parts from scratch. But some code will > certainly be new, so if you write it from scratch now, most of > the code will find it's use later. Correct me if I'm wrong, but if the config parser won't be=20 included in liblirc_client, then all code will be new, isn't=20 that right? > > Will a client daemon that provides compliance with the > > current .lircrc format be required? I'm guessing yes, since > > many probably don't want to change their config files. > > You guessed right, but that shouldn't be hard, all that code > is already written within the current liblirc_client library, > just needs splitting. > > > I can't say that I'm feeling much in the mood of writing > > something that I'll never use, though. > > Don't worry, I was planning to do that myself :-) Is that to mean that you intend to go on using the current config=20 file format? As a programmer, you should really look into using=20 my lirccd instead. I promise you, you won't regret it. =3D) Btw., would we need an authentication mechanism, like xauth? Fredrik Tolf |
From: Fredrik T. <fr...@do...> - 2003-05-08 02:07:34
|
It doesn't seem like this message reached the lirc-list for some=20 reason, although it did have the address in the To: field, so I=20 won't snip it. On Thursday 08 May 2003 02:13, Zsolt Rizsanyi wrote: > On Friday 02 May 2003 21.22, Fredrik Tolf wrote: > > I know I've been on you about this before, but please > > consider it. I've been designing a client program for LIRC - > > lirccd (lirc client daemon), that features extremely > > flexible configuration, and a better way to implement other > > client programs (since lirccd handles all the state > > information instead of letting liblirc_client do it). > > Hi Fredrik! > > 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. > > So I really like your project, but one problem with it: the > flexible configuration you regard as a feature can be a > drawback. IMO lirc should be easily configurable through a > GUI, and I don't see signs that your approach to configuration > makes that easy. I do see your pint, but I did try especially to make it rather=20 easy to configure even without programming knowledge. I'll=20 include the config file example #1 from my homepage for this=20 project: bind "Rewind" sendstring("mplayer", "seek -10"); bind "FF" sendstring("mplayer", "seek +10"); bind "Play" exec("gmplayer &"); /* Note that you have to include =09=09=09=09* an ampersand (&) at the end of the =09=09=09=09* command, or lirccd will wait for it =09=09=09=09* to complete. */ While this doesn't necessary fully make sense to someone without=20 programming experience, I'd say that it's certainly not=20 impossible to understand, and especially not to extend. See=20 below as well. > I have actually written lirc support for some apps (QtVision > and one more lirc plugin for Zapping), and the hardest part is > to make it right is graphical configuration. I am aware that there is a glade-based application for=20 configuring the normal .lircrc, and I don't think it would be=20 very hard to extend it to support lirccd configuration as well. > Also I have taken care to make it work out-of-the-box without > doing any configuration (that is to provide a reasonable > default configuration). That of course means that you need to > provide mappings from various keys to the same function eg. to > make FULL_SCREEN and FULLSCREEN do the same since both > keynames are used with various remotes. In that case, you might like lirccd, since it uses regexps to=20 match buttons. You would be able to accomplish the above with=20 this: bind "FULL.*SCREEN" sendstring("appname", "full_screen"); It also includes the actual button name in the variable "button",=20 as well, so this might be appealing to you: bind "[0-9]" sendstring("appname", "channel " + button); These regexps aren't case insensitive, though. Do you think that=20 they should be? > Both the above problems wind down to the fact that: > There is no defined way how to extend an existing > configuration with your app specific one. > Maybe a configuration directory is needed, where the app could > install the default key bindings, and later when the user > changes configuration, then it can update that file without > interfering the bindings of other apps. Indeed. That would be good. I'm piping the config file through=20 cpp before parsing, so maybe there is a solution to that. ~Say=20 that you have a directory ~/.lirccrcd, where you put all=20 extension files with a .ext name suffix, and in the end of the=20 installation, you make the installation mechanism execute=20 something like this: (cd ~; ls .lirccrcd/*.ext >.lirccrcd/exts.h) And then you have an #include ".lirccrcd/exts.h" in the standard=20 lirccd config file. It's a bit hacky, but as I see it, it should=20 work very well. Also, it's easy to change if you want a=20 system-wide extension database instead. > What do you think about this? > Do you think that your client daemon should solve these > problems? If yes, then I will try to work with you to solve > all these problems (if possible). > > 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=20 all KDE programs for LIRC? Thanks for your ideas! Fredrik Tolf |
From: Zsolt R. <riz...@my...> - 2003-05-08 02:11:01
|
On Friday 02 May 2003 21.22, Fredrik Tolf wrote: > I know I've been on you about this before, but please consider it. > I've been designing a client program for LIRC - lirccd (lirc client > daemon), that features extremely flexible configuration, and a better > way to implement other client programs (since lirccd handles all the > state information instead of letting liblirc_client do it). Hi Fredrik! 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. So I really like your project, but one problem with it: the flexible configuration you regard as a feature can be a drawback. IMO lirc should be easily configurable through a GUI, and I don't see signs that your approach to configuration makes that easy. I have actually written lirc support for some apps (QtVision and one more lirc plugin for Zapping), and the hardest part is to make it right is graphical configuration. Also I have taken care to make it work out-of-the-box without doing any configuration (that is to provide a reasonable default configuration). That of course means that you need to provide mappings from various keys to the same function eg. to make FULL_SCREEN and FULLSCREEN do the same since both keynames are used with various remotes. Both the above problems wind down to the fact that: There is no defined way how to extend an existing configuration with your app specific one. Maybe a configuration directory is needed, where the app could install the default key bindings, and later when the user changes configuration, then it can update that file without interfering the bindings of other apps. What do you think about this? Do you think that your client daemon should solve these problems? If yes, then I will try to work with you to solve all these problems (if possible). 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. Regards Zsolt |
From: Zsolt R. <riz...@my...> - 2003-05-08 10:17:50
|
I'm CCing this to Antonio Larrosa Jim=E9nez, since maybe he will be also=20 interessted. Note to him: The first mail regarding this topic can be found at: http://sourceforge.net/mailarchive/forum.php?thread_id=3D2056376&forum_id= =3D5339 On Thursday 08 May 2003 04.07, Fredrik Tolf wrote: > It doesn't seem like this message reached the lirc-list for some > reason, although it did have the address in the To: field, so I > won't snip it. I think it is waiting moderator approval, since I have forgotten to set the= =20 =46rom field of the mail to the one I'm subscribed with. > On Thursday 08 May 2003 02:13, Zsolt Rizsanyi wrote: > > On Friday 02 May 2003 21.22, Fredrik Tolf wrote: > > > I know I've been on you about this before, but please > > > consider it. I've been designing a client program for LIRC - > > > lirccd (lirc client daemon), that features extremely > > > flexible configuration, and a better way to implement other > > > client programs (since lirccd handles all the state > > > information instead of letting liblirc_client do it). > > > > Hi Fredrik! > > > > 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. > > > > So I really like your project, but one problem with it: the > > flexible configuration you regard as a feature can be a > > drawback. IMO lirc should be easily configurable through a > > GUI, and I don't see signs that your approach to configuration > > makes that easy. > > I do see your pint, but I did try especially to make it rather > easy to configure even without programming knowledge. I'll > include the config file example #1 from my homepage for this > project: > > 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. */ > > 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 han= d=20 :) But to write the above config file by hand you need some not so easily=20 attainable knowledge like the names of the buttons, and commands of mplayer. Thats where a graphical program could provide some value, listing all the=20 buttons and all the available commands for various programs, and providing = a=20 way to bind them. > > I have actually written lirc support for some apps (QtVision > > and one more lirc plugin for Zapping), and the hardest part is > > to make it right is graphical configuration. > > I am aware that there is a glade-based application for > configuring the normal .lircrc, and I don't think it would be > very hard to extend it to support lirccd configuration as well. I dont agree. I think it would be pretty hard to do support your config. Of= =20 course it is pretty easy to use only a subset of your configuration and=20 generate a config file, but the real problem is reconfiguration. That is when you have an existing config file, and you want to add or chang= e=20 some bindings. You need to be able the parse config file, and I dont think= =20 that it is trivial to write a program that parses and understands your form= at=20 of configuration. > > Also I have taken care to make it work out-of-the-box without > > doing any configuration (that is to provide a reasonable > > default configuration). That of course means that you need to > > provide mappings from various keys to the same function eg. to > > make FULL_SCREEN and FULLSCREEN do the same since both > > keynames are used with various remotes. > > In that case, you might like lirccd, since it uses regexps to > match buttons. You would be able to accomplish the above with > this: > bind "FULL.*SCREEN" sendstring("appname", "full_screen"); > > 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); Thats pretty nice :) Your configuration format is awesome. I can configure it do anything I want. But I dont think I'm able to write a program that would parse it. Tough you= r=20 lirccd certainly does that ;) > These regexps aren't case insensitive, though. Do you think that > they should be? I think that it would not hurt :) It's not too common to have different=20 buttons with names differing only in case... > > Both the above problems wind down to the fact that: > > There is no defined way how to extend an existing > > configuration with your app specific one. > > Maybe a configuration directory is needed, where the app could > > install the default key bindings, and later when the user > > changes configuration, then it can update that file without > > interfering the bindings of other apps. > > Indeed. That would be good. I'm piping the config file through > cpp before parsing, so maybe there is a solution to that. ~Say > that you have a directory ~/.lirccrcd, where you put all > extension files with a .ext name suffix, and in the end of the > installation, you make the installation mechanism execute > something like this: > (cd ~; ls .lirccrcd/*.ext >.lirccrcd/exts.h) > > And then you have an #include ".lirccrcd/exts.h" in the standard > lirccd config file. It's a bit hacky, but as I see it, it should > work very well. Also, it's easy to change if you want a > system-wide extension database instead. It is a pretty good solution, and I tought that this is possible to do with= =20 your configuration. But I would like some standardization on this. Like those *.ext files should only use a defined subset of your config file= =20 syntax so they would be easy parse and reconfigure. Also the exact directory and the method to update it should be specified at= =20 least in a HOWTO. > > What do you think about this? > > Do you think that your client daemon should solve these > > problems? If yes, then I will try to work with you to solve > > all these problems (if possible). > > > > 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= =2E=20 It is the idea of Antonio Larossa Jimenez. It can be found in KDE cvs under kdenonbeta/finglonger It will work like this: Every (KDE) program which wants lirc input provides= a=20 profile file with all the available actions which can be executed on the=20 program (eg. a tv viewer app would provide actions like fullscreen, chanup,= =20 chandown, ch [num]), and the necessary dcop message needed to send to the=20 program when that action happens. (dcop is a method to send commands to apps from other applications or from = the=20 shell using the kdcop application) Then a Kontrol Center module would allow configuration, where you bind the= =20 buttons of your remote (read from the lirc socket) to the various actions o= f=20 the available programs. With the current plans this configuration would be saved in KDE config file= s=20 and read by a separate KDE Lirc daemon along with the action definitions an= d=20 would send the appropriate dcop messages to when a lirc keypress event=20 arrives. IMHO it would be nice if there would be no need for two separate daemons fo= r=20 KDE and non KDE programs. But for that, all the features planned for KDE should be provided by your=20 lirccd. But of course since I'm not developing neither finglonger nor lirccd you=20 should take all the above as only ideas. I will forward this mail also Antonio Larossa Jimenez to maybe get his idea= s=20 too. Regards Zsolt Rizsanyi |
From: Fredrik T. <fr...@do...> - 2003-05-08 11:50:07
|
On Thursday 08 May 2003 10:38, Zsolt Rizsanyi wrote: > I'm CCing this to Antonio Larrosa Jim=E9nez, since maybe he will > be also interessted. > Note to him: The first mail regarding this topic can be found > at: > http://sourceforge.net/mailarchive/forum.php?thread_id=3D2056376 >&forum_id=3D5339 > > On Thursday 08 May 2003 04.07, Fredrik Tolf wrote: > > It doesn't seem like this message reached the lirc-list for > > some reason, although it did have the address in the To: > > field, so I won't snip it. > > I think it is waiting moderator approval, since I have > forgotten to set the From field of the mail to the one I'm > subscribed with. > > > On Thursday 08 May 2003 02:13, Zsolt Rizsanyi wrote: > > > On Friday 02 May 2003 21.22, Fredrik Tolf wrote: > > > > I know I've been on you about this before, but please > > > > consider it. I've been designing a client program for > > > > LIRC - lirccd (lirc client daemon), that features > > > > extremely flexible configuration, and a better way to > > > > implement other client programs (since lirccd handles > > > > all the state information instead of letting > > > > liblirc_client do it). > > > > > > Hi Fredrik! > > > > > > 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. > > > > > > So I really like your project, but one problem with it: > > > the flexible configuration you regard as a feature can be > > > a drawback. IMO lirc should be easily configurable through > > > a GUI, and I don't see signs that your approach to > > > configuration makes that easy. > > > > I do see your pint, but I did try especially to make it > > rather easy to configure even without programming knowledge. > > I'll include the config file example #1 from my homepage for > > this project: > > > > bind "Rewind" sendstring("mplayer", "seek -10"); > > bind "FF" sendstring("mplayer", "seek +10"); > > bind "Play" exec("gmplayer &"); > > > > 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 > But to write the above config file by hand you need some not > so easily attainable knowledge like the names of the buttons, > and commands of mplayer. Thats where a graphical program could > provide some value, listing all the buttons and all the > available commands for various programs, and providing a way > to bind them. I get your point. I thought you were referring to those migrating=20 from handwriting .lircrc. That goal is a bit harder, I guess. > > > I have actually written lirc support for some apps > > > (QtVision and one more lirc plugin for Zapping), and the > > > hardest part is to make it right is graphical > > > configuration. > > > > I am aware that there is a glade-based application for > > configuring the normal .lircrc, and I don't think it would > > be very hard to extend it to support lirccd configuration as > > well. > > I dont agree. I think it would be pretty hard to do support > your config. Of course it is pretty easy to use only a subset > of your configuration and generate a config file, but the real > problem is reconfiguration. That is when you have an existing > config file, and you want to add or change some bindings. You > need to be able the parse config file, and I dont think that > it is trivial to write a program that parses and understands > your format of configuration. Again, I get your point. I thought as above, thinking only on=20 that very limited syntax subset used to create=20 ".lircrc-compatible" files, so to speak. See below as well. > > > Also I have taken care to make it work out-of-the-box > > > without doing any configuration (that is to provide a > > > reasonable default configuration). That of course means > > > that you need to provide mappings from various keys to the > > > same function eg. to make FULL_SCREEN and FULLSCREEN do > > > the same since both keynames are used with various > > > remotes. > > > > In that case, you might like lirccd, since it uses regexps > > to match buttons. You would be able to accomplish the above > > with this: > > bind "FULL.*SCREEN" sendstring("appname", "full_screen"); > > > > 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); > > Thats pretty nice :) > Your configuration format is awesome. I can configure it do > anything I want. But I dont think I'm able to write a program > that would parse it. Tough your lirccd certainly does that ;) > > > These regexps aren't case insensitive, though. Do you think > > that they should be? > > I think that it would not hurt :) It's not too common to have > different buttons with names differing only in case... Indeed. I'll change that to the next release. Not sure when=20 that's going to happen, though. > > > Both the above problems wind down to the fact that: > > > There is no defined way how to extend an existing > > > configuration with your app specific one. > > > Maybe a configuration directory is needed, where the app > > > could install the default key bindings, and later when the > > > user changes configuration, then it can update that file > > > without interfering the bindings of other apps. > > > > Indeed. That would be good. I'm piping the config file > > through cpp before parsing, so maybe there is a solution to > > that. ~Say that you have a directory ~/.lirccrcd, where you > > put all extension files with a .ext name suffix, and in the > > end of the installation, you make the installation mechanism > > execute something like this: > > (cd ~; ls .lirccrcd/*.ext >.lirccrcd/exts.h) Heh! You can see that I wrote this 4:30 AM. I don't think that=20 there's anyone who didn't get the point, but just to be sure,=20 this is of course what I meant: (cd ~; >.lirccrcd/exts.h; for file in .lirccrcd/*.ext; \ do echo \#include \"$file\" >>.lirccrcd/exts.h; done) > > And then you have an #include ".lirccrcd/exts.h" in the > > standard lirccd config file. It's a bit hacky, but as I see > > it, it should work very well. Also, it's easy to change if > > you want a system-wide extension database instead. > > It is a pretty good solution, and I tought that this is > possible to do with your configuration. > But I would like some standardization on this. > Like those *.ext files should only use a defined subset of > your config file syntax so they would be easy parse and > reconfigure. Precisely. Probably, the lexer/parser can be extracted from=20 lirccd and used in a configuration tool, but the problem, I=20 guess is to present the parsed information in a user-friendly=20 manner. Now, I'm really not an expert on user-friendlyness, but=20 I guess it's possible to create some heuristic that will work,=20 like you said, on a defined subset of the syntax. Would it be OK if I left that to you to define? You seem to have=20 experience in that field, whereas you can see on this syntax=20 just how much I've been working on user-friendlyness. > Also the exact directory and the method to update it should be > specified at least in a HOWTO. Oh, don't get me started on documentation. I guess I could do=20 that in time, but there is tons of docs that could be written on=20 this by now. I don't even have a manpage for the daemon itself,=20 and much could be written about the config syntax, the built-in=20 functions, variable schemes. Then a hacking guide should be=20 provided for creating new extension functions, an extension=20 HOWTO like you mentioned and what not. It's not that I don't=20 like documenting stuff, but with my current userbase of this=20 program, I just don't really feel motivated to do so. > > > 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 Larossa Jimenez. > It can be found in KDE cvs under kdenonbeta/finglonger > 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) So you say? Apart from kmail, I have hardly used KDE at all. I=20 guess DCOP is what KDE uses where GNOME uses ORBit? Not that=20 I've done any GNOME programming, but at least I use it. > 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. > 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. > > 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. > > But of course since I'm not developing neither finglonger nor > lirccd you should take all the above as only ideas. > I will forward this mail also Antonio Larossa Jimenez to maybe > get his ideas too. Indeed. I'm guessing that I'll leave the decision to Antonio=20 whether to use lirccd. I can assure you all, though, that if he=20 would, I would of course work with him to add the necessary=20 functionality to lirccd. It might be a problem that lirccd isn't a KDE program, though,=20 since I don't really think that DCOP functionality would fit in=20 it right now. Maybe it can be redesigned in some way to support=20 this, or support it as a configuration-time option, or possible=20 have a light-weight forwarding program that connects to lirccd=20 as a normal client. I'll leave that for him to decide how he wants it, but I do want=20 lirccd to be usable even without X, because that's the way I'm=20 using it right now. Fredrik Tolf |
From: Antonio L. <la...@kd...> - 2003-05-09 00:41:11
Attachments:
kwintv.flp
finglonger_remote_AverTV_rc
|
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. |
From: Rizsanyi Z. <riz...@my...> - 2003-05-13 17:01:46
|
Hi Antonio! I have seen, that you have resent this letter, because you are not sure if it reached the lirc-list. I can assure you that it reached the list. But you did not got any replies because you did not have any questions :) You have just described how (currently) finglonger works, but had not provided your ideas about the way finglonger and lircc could cooperate. Seemed like you are not really for using lircc as backend of finglonger. Now I consider that it seemed so only because you were in hurry when writing the letter. So I will give my comments ;) On Friday 09 May 2003 00.09, Antonio Larrosa Jiménez wrote: > El Jueves, 8 de Mayo de 2003 10:38, Zsolt Rizsanyi escribió: > > > 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 > 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. To properly configure lircc for the KDE (or maybe other) apps it would use the *.flp files. What do you think about this suggestion? > Note that I'm talking about profiles because that's one of the new things > that finglonger provides. The ability for a button to do something > 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 > change the song played by xmms or noatun if we're in the respective > profile. AFAIK lircc provides that feature too. > > > 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 > would be _really_ simple to script it and also to make a finglonger > profile for it. If someone wants to help me with that, I can provide some > information. I dont think it is a good idea to add dcop interface to non KDE programs. People who want that should use KMplayer (KDE wrapper for mplayer). 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. I think this would be possible, at least for basic mplayer configuration. (Who need more can always edit lircc configuration files by hand) > > > 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. 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) ;) > > > > 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 > 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? Regards Zsolt |
From: Antonio L. <la...@kd...> - 2003-05-13 23:11:46
|
El Tuesday 13 May 2003 18:30, Rizsanyi Zsolt escribi=F3: > Hi Antonio! > Hello Rizsanyi, > I have seen, that you have resent this letter, because you are not sure > if it reached the lirc-list. I can assure you that it reached the list. Aah, ok. It's strange I couldn't find it in the archives, maybe they're not= =20 being updated too frequently. > But you did not got any replies because you did not have any questions > :) LOL > You have just described how (currently) finglonger works, but had not=20 > provided your ideas about the way finglonger and lircc could cooperate. Well, I hoped that we could discuss that after explaining how finglonger=20 works. > 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=20 lirccd (and I hope the config file format can be discussed too :) ) > Now I consider that it seemed so only because you were in hurry when > writing the letter. Thanks for understanding, in fact, I was in a hurry because I had to finish= =20 an application for work for the 21th and today the date has been replaced=20 by the 16th so I'm really busy and I hope you can understand some delays=20 in my answers. > So I will give my comments ;)=20 Great! > On Friday 09 May 2003 00.09, Antonio Larrosa Jim=E9nez wrote: > > El Jueves, 8 de Mayo de 2003 10:38, Zsolt Rizsanyi 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 > > > > * 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 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=20 (lirccd's config file) instead of finglonger's remote file, isn't it ? Note that flp files only contains the interface that applications export to= =20 the world, and the "remote files" contain the actual bindings between the=20 remote buttons and the actions in each profile that should be run. So kcmfinglonger (the kcontrol module) is mainly used to changes _just_ the= =20 "remote files", and only in some cases the profile files (in case the user= =20 would like to make his own profiles to manage several applications without= =20 changing the profile or to define custom actions). That is, each application should distribute a flp file which would be=20 "static", but that is completely independent from any specific remote=20 controls or from button informations. > 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= =20 the current desktop). How does lirccd works when there are multiple users=20 in a system running different applications? Is it owned by the user? or=20 started by root at the system runlevel scripts ?=20 On other areas, how does lirccd support different profiles currently? how=20 does it report the status change? should it emit dcop signals also when=20 changing the status? I ask all that because I planned to do a finglonger=20 applet for kicker's system tray that would display a different icon=20 depending on the state. How would that be possible when using lirccd? I hope you understand that I had a lot of ideas in my mind and I wouldn't=20 like to change them if that means less features. Otoh, if it's possible to= =20 be in a win-win situation, then the better :). > AFAIK lircc provides that feature too. Ah, good. > 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 :) > programs. People who want that should use KMplayer (KDE wrapper for > mplayer). In this case, yes, maybe that's an easier solution for now. > 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=20 files, but defining specialized action methods instead of just DCOP calls=20 and executing applications. > 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=20 support infrared remotes directly. Instead of that, every application=20 should have a generic scripting mechanism (DCOP or other) which finglonger= =20 would use to make the applications do actions. That's one of the main benefits of finglonger, suddenly, _every_ kde=20 application can be controlled from the remote controller, even if they=20 know nothing about lirc. For example, I could download/upload my mail in=20 kmail from the remote, or navigate through a web page in konqueror=20 (following links, moving trough the page, etc.) . > > > > 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= =20 finglonger's kicker applet with the numbers I was pressing in the remote,=20 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) ;) =2E.. Exactly, that was the reason I kept wondering :) Not that it's difficult to do, but it's complicated to find an easy user=20 interface for the user to configure that setting. > > 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. Greetings, =2D- Antonio Larrosa Jimenez KDE developer - la...@kd... http://developer.kde.org/~larrosa/ Better read something in another language than a riddle in your own. |
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 |
From: Joydeep B. <jo...@vs...> - 2003-05-11 05:51:33
|
On Saturday 03 May 2003 12:52am, Fredrik Tolf wrote: > Hi all! > > I know I've been on you about this before, but please consider it. > I've been designing a client program for LIRC - lirccd (lirc client > daemon), that features extremely flexible configuration, and a better > way to implement other client programs (since lirccd handles all the > state information instead of letting liblirc_client do it). Hi Fredrik, mplayer, xine etc have been designed to work with liblirc_client to support LIRC. will those application autodetect lirccd or asked for liblirc_client ? pls let me know. thanks in advanced. |
From: Fredrik T. <fr...@do...> - 2003-05-11 12:46:46
|
On Friday 09 May 2003 23:32, Joydeep Bakshi wrote: > On Saturday 03 May 2003 12:52am, Fredrik Tolf wrote: > > Hi all! > > > > I know I've been on you about this before, but please > > consider it. I've been designing a client program for LIRC - > > lirccd (lirc client daemon), that features extremely > > flexible configuration, and a better way to implement other > > client programs (since lirccd handles all the state > > information instead of letting liblirc_client do it). > > Hi Fredrik, > mplayer, xine etc have been designed to work with > liblirc_client to support LIRC. will those application > autodetect lirccd or asked for liblirc_client ? pls let me > know. Currently, applications only designed to work with liblirc_client=20 will not work with lirccd. I have a patch for MPlayer 0.90 on=20 lirccd's homepage to support liblircc, though. I've just finished another project that has been keeping me busy,=20 though, so today I will start writing a compatibility=20 liblirc_client, so that applications only designed for it will=20 be able to work with lirccd. Fredrik Tolf |