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
diff --git a/kdeui/util/kkeyserver_x11.cpp b/kdeui/util/kkeyserver_x11.cpp
index 5a7d6d8..3e6e36f 100644
--- a/kdeui/util/kkeyserver_x11.cpp
+++ b/kdeui/util/kkeyserver_x11.cpp
@@ -334,6 +334,9 @@ static const TransKey g_rgQtToSymX[] =
#define XF86XK_TopMenu 0x1008FFA2
#define XF86XK_Suspend 0x1008FFA7
#define XF86XK_Hibernate 0x1008FFA8
+#define XF86XK_TouchpadToggle 0x1008FFA9
+#define XF86XK_TouchpadOn 0x1008FFB0
+#define XF86XK_TouchpadOff 0x1008FFB1
// end of XF86keysyms.h
,
{ Qt::Key_Back, XF86XK_Back },
@@ -453,6 +456,9 @@ static const TransKey g_rgQtToSymX[] =
{ Qt::Key_Bluetooth, XF86XK_Bluetooth },
{ Qt::Key_Suspend, XF86XK_Suspend },
{ Qt::Key_Hibernate, XF86XK_Hibernate },
+ { Qt::Key_TouchpadToggle, XF86XK_TouchpadToggle },
+ { Qt::Key_TouchpadOn, XF86XK_TouchpadOn },
+ { Qt::Key_TouchpadOff, XF86XK_TouchpadOff },
{ Qt::Key_Launch2, XF86XK_Launch0 },
{ Qt::Key_Launch3, XF86XK_Launch1 },
{ Qt::Key_Launch4, XF86XK_Launch2 },
