ktouchpadenabler moved to kdereview

[Albert Astals Cid]

El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va 
escriure:
> Em Wednesday 04 January 2012, Albert Astals Cid escreveu:
> > El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure:
> > > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote:
> > > > El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck
> > > > va
> > 
> > escriure:
> > > > > On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote:
> > > > > > My little kded daemon that listens to
> > > > > > XF86XK_TouchpadToggle and
> > > > > > enables disables the touchpad accordingly has been moved
> > > > > > to
> > > > > > kdereview.
> > > > > > 
> > > > > > My plan is moving it to extragear, not really sure if
> > > > > > -base or
> > > > > > -utils.
> > > > > > 
> > > > > > The code doesn't have a kcm or any kind of configuration
> > > > > > since
> > > > > > it
> > > > > > is designed to "just work".
> > > > > > 
> > > > > > I'd appreciate any review or suggestion over it.
> > > > > 
> > > > > I cannot test it because I have no touchpad, but if it is
> > > > > supposed
> > > > > to
> > > > > "just work" without any UI, I suggest to just add it to
> > > > > "khotkeys"
> > > > > or
> > > > > "kaccel" daemon (whichever of them is used for global
> > > > > shortcuts), so that we do not filter global X11 keyboard
> > > > > events twice.
> > > > 
> > > > 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).
> > > 
> > > IMHO this isn't about the number of lines of code, but about the
> > > runtime performance (how many process to wake up when pressing a
> > > key).> 
> > khotkeys is already a kded module, so there won't be no more processes
> > waking up now than before by adding a new kded module.
> > 
> > > kglobalaccel seems quite suitable indeed, no?
> > 
> > It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd
> > need to introduce a big "ignore all the workflow of kglobalaccel for
> > this special key" since kglobalaccel only understands Qt keys (see
> > KGlobalAccelImpl::grabKey).
> 
> 	In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt-
> and.html) you said your patch against Qt was accepted. I thought your patch
> would add XF86XK_TouchpadToggle support to Qt and then there would be no
> need for this kded module. If we patch Qt we could add the support for a
> key as one #define and one enumerate per key in
> kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also
> created the patch for that, it works for me. I have never sent my patch to
> Qt because the upstream bug
> (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for
> almost two years now, nobody seems to care about the bug.

My patch patch was accepted in Qt5, noone is going to accept stuff like that 
for Qt 4.8. As far as i can see my patch already includes your changes.

Albert

> 
> 	My question is: since you know how to send patches to Qt's repository
> wouldn't be better just send my patch upstream (it is here
> https://bugs.kde.org/show_bug.cgi?id=182672) and just apply my second patch
> to kdelibs? My second patch is attached.