El Dimecres, 4 de gener de 2012, a les 20:15:27, Thomas Lübking va escriure: > Am 04.01.2012, 18:51 Uhr, schrieb Albert Astals Cid <aa...@kde.org>: > > I don't really see any point in doing that, nothing can be shared > > between them > > and the existing ktouchpadenabler so instead of one simple codebase (166 > > lines > > with 20 of headers) you end up adding more complexity to existing > > programs > > (probably integrating the code in the existing programs would be more > > than 166 > > lines). > > I guess what Christoph meant was to avoid having another XSelect daemon.
It's not another daemon, it's a kded module. > I've not seen the code (and deleted the original mail in case it's linked > there - winkwink) Do i need to say that ktouchpadenabler is in kde:ktouchpadenabler? > but my approach would be to have a tool to be invoked > when "something" happens, rather than adding yet another keyboard event > listening daemon bound to a very specific event. That'd mean doing udev stuff and the like probably, i'll pass on that. > Actually I've a setup a udev rule to simply "fix" things whenever I > un/plug a mouse (not sure what or where that particular key is) That has nothing to do with what ktouchpadenabler does. Albert > > Cheers, > Thomas