ktouchpadenabler moved to kdereview

[Lamarque V. Souza]

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 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.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120104/482656ee/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-4.6.2-add_touchpad_toggle_on_off_keycodes.patch
Type: text/x-patch
Size: 1084 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120104/482656ee/attachment.bin>