Discussion:
Some parts of LibQxt in Qt
Mark
2011-09-27 07:58:14 UTC
Permalink
Hi,

I recently discovered LibQxt because i was looking for some way to have
global key shortcuts without the need of the window being active. LibQxt
has QxtGlobalShortcut for that and i think that should be functionality in
Qt only a bit differently. Qt has QSchortcut which works just fine, but it
needs to have another enum value for the setContext function for system wide
shortcuts, right now there is :
http://doc.qt.nokia.com/latest/qt.html#ShortcutContext-enum For example add
one with the name Qt::SystemShortcut and when that's set you should get the
same behavior as you would get when using QxtGlobalShortcut.

Besides QxtGlobalShortcut there is more in LibQxt, like QxtJSON and
QxtSmtp, that would be really convenient to have in Qt without 3rd party
plugins. Perhaps a few others as well?
Note: How is it even possible in Todays Qt that we do have QML with json
things in it, but no way to use it from C++..? Or did i miss something
somewhere?

Do those interesting parts of LibQxt make any chance of getting in Qt?

Kind regards,
Mark
Thiago Macieira
2011-09-27 08:40:16 UTC
Permalink
Post by Mark
I recently discovered LibQxt because i was looking for some way to have
global key shortcuts without the need of the window being active. LibQxt
has QxtGlobalShortcut for that and i think that should be functionality in
Qt only a bit differently. Qt has QSchortcut which works just fine, but it
needs to have another enum value for the setContext function for system wide
http://doc.qt.nokia.com/latest/qt.html#ShortcutContext-enum For example add
one with the name Qt::SystemShortcut and when that's set you should get the
same behavior as you would get when using QxtGlobalShortcut.
As I explained before, global shortcuts are slightly more complicated because
you may not get the shortcut you asked for if another application already has
it. Though technically speaking, even normal shortcuts could be taken by
global shortcuts, like Ctrl+F1 or Ctrl+1.

I think we should have a global shortcut API in Qt. The Qxt codebase might
work well as a baseline, but someone needs to research a bit more how to
integrate with the KDE global shortcut manager. Another task for the platform
plugin, probably.
Post by Mark
Besides QxtGlobalShortcut there is more in LibQxt, like QxtJSON and
QxtSmtp, that would be really convenient to have in Qt without 3rd party
plugins. Perhaps a few others as well?
SMTP support could be provided as an addon until we get a good idea how common
the use is. If we find out it's used often, it can move to QtNetwork.

JSON support is provided by many different implementations already. I don't
think we can choose one right now. So we should simply list all the available
ones and apply the Darwin principle: standardise on the one that survives.

Another technology I see very often needed is serial port support. I think
there's only one implementation easily available for Qt, so it's a no brainer
which one to choose.

Is there anyone working on USB support?
Post by Mark
Note: How is it even possible in Todays Qt that we do have QML with json
things in it, but no way to use it from C++..? Or did i miss something
somewhere?
Do those interesting parts of LibQxt make any chance of getting in Qt?
Yes, but only if someone does the effort and the licensing is compatible.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Oswald Buddenhagen
2011-09-27 11:47:04 UTC
Permalink
Post by Thiago Macieira
Is there anyone working on USB support?
there is quite a lot of relevant code in qtcreator.

well, actually, there is quite a lot of relevant code for a lot of
things in qtcreator, some of it is even "librarized" to some degree
already. "harvesting" it for qt would just need someone with the
inclination to do so.
Thiago Macieira
2011-09-27 11:57:56 UTC
Permalink
Post by Oswald Buddenhagen
Post by Thiago Macieira
Is there anyone working on USB support?
there is quite a lot of relevant code in qtcreator.
well, actually, there is quite a lot of relevant code for a lot of
things in qtcreator, some of it is even "librarized" to some degree
already. "harvesting" it for qt would just need someone with the
inclination to do so.
I've been calling for that for some time. If Creator devs needed to create
some interesting widgets, maybe other people need them too.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Girish Ramakrishnan
2011-09-27 13:20:17 UTC
Permalink
Hi,
Post by Thiago Macieira
JSON support is provided by many different implementations already. I don't
think we can choose one right now. So we should simply list all the available
ones and apply the Darwin principle: standardise on the one that survives.
Here's one I wrote based on QLALR and it's way faster than the (very
popular) qjson (benchmarks are in the repo):
http://gitorious.org/qjsonparser/qjsonparser.

Does V8 have it's own json parser that we can use?

Unrelated question: is there a XPath/XQuery equivalent in the JSON world?

Girish
Thiago Macieira
2011-09-27 13:46:59 UTC
Permalink
Post by Girish Ramakrishnan
Hi,
Post by Thiago Macieira
JSON support is provided by many different implementations already. I don't
think we can choose one right now. So we should simply list all the
available ones and apply the Darwin principle: standardise on the one
that survives.
Here's one I wrote based on QLALR and it's way faster than the (very
http://gitorious.org/qjsonparser/qjsonparser.
Does V8 have it's own json parser that we can use?
That's why I said we have 5 different JSON parsers today and Darwin should
determine which one we'll pick.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Mark
2011-09-27 18:22:02 UTC
Permalink
Post by Thiago Macieira
Post by Girish Ramakrishnan
Hi,
Post by Thiago Macieira
JSON support is provided by many different implementations already. I don't
think we can choose one right now. So we should simply list all the
available ones and apply the Darwin principle: standardise on the one
that survives.
Here's one I wrote based on QLALR and it's way faster than the (very
http://gitorious.org/qjsonparser/qjsonparser.
Does V8 have it's own json parser that we can use?
That's why I said we have 5 different JSON parsers today and Darwin should
determine which one we'll pick.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
About V8, Qt is gonna use that right? I'm guessing V8 has it's own uber fast
json parser so why not make a qt layer for that..? Seems like that gives no
duplication and json in c++, everyone happy :)

What is gonna happen with the global shortcut thing i mentioned earlier? Is
someone gonna make a qt implementation for that or adjust the libqxt classes
so they can be used..? Or something else?
Petr Vanek
2011-09-27 18:48:16 UTC
Permalink
What is gonna happen with the global shortcut thing i mentioned earlier? Is someone gonna make a qt implementation for that or adjust the libqxt classes so they can be used..? Or something else?
personally I'd like to see this feature for sure.

but there are 2 things to solve:

- license of qxt code, but maybe qxt guys can relicense it to be used in the official qt5

- as Thiago mentioned - he wants to support all available "subsystems". There is no problem on mac and windows. But there are more wrappers around X11 (for KDE, GNOME, LXDE probably, etc.). And Thiago wants to provide "connectors" to all those subsystems... which is insane for coding (from my point of view) - event when all those subsystems use X11 internally (guessing so) so the "already registered shorcut" error state is available anyway. But maybe Thiago has different usecases on his mind.

petr
Thiago Macieira
2011-09-27 19:53:51 UTC
Permalink
Post by Petr Vanek
- as Thiago mentioned - he wants to support all available "subsystems".
There is no problem on mac and windows. But there are more wrappers around
X11 (for KDE, GNOME, LXDE probably, etc.). And Thiago wants to provide
"connectors" to all those subsystems... which is insane for coding (from my
point of view) - event when all those subsystems use X11 internally
(guessing so) so the "already registered shorcut" error state is available
anyway. But maybe Thiago has different usecases on his mind.
I've been discussing with Wayland developers and the subject of global
shortcuts came up. There's no protocol for this yet, but it definitely falls
into the WMs discretion of whether a shortcut is accepted or not.

Anyway, this shows that the global shortcut handling might need to go through
the Windowing System plugin (the lighthouse plugin) or the desktop plugin.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Mark
2011-09-27 20:22:55 UTC
Permalink
Post by Thiago Macieira
Post by Petr Vanek
- as Thiago mentioned - he wants to support all available "subsystems".
There is no problem on mac and windows. But there are more wrappers around
X11 (for KDE, GNOME, LXDE probably, etc.). And Thiago wants to provide
"connectors" to all those subsystems... which is insane for coding (from my
point of view) - event when all those subsystems use X11 internally
(guessing so) so the "already registered shorcut" error state is available
anyway. But maybe Thiago has different usecases on his mind.
I've been discussing with Wayland developers and the subject of global
shortcuts came up. There's no protocol for this yet, but it definitely falls
into the WMs discretion of whether a shortcut is accepted or not.
Anyway, this shows that the global shortcut handling might need to go through
the Windowing System plugin (the lighthouse plugin) or the desktop plugin.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Is this still on time to even get in lighthouse for Qt 5?
Since i'm guessing some api's need to change for this? Not sure though since
i haven't seen anything in lighthouse yet, only read about it a couple
times. But how is this supposed to work anyway, do all key events go through
lighthouse in Qt5?
Girish Ramakrishnan
2011-09-27 20:35:27 UTC
Permalink
Hi Mark,
Post by Mark
Is this still on time to even get in lighthouse for Qt 5?
Since i'm guessing some api's need to change for this? Not sure though since
i haven't seen anything in lighthouse yet, only read about it a couple
times. But how is this supposed to work anyway, do all key events go through
lighthouse in Qt5?
The lighthouse api won't keep binary or source compatibility across
minor releases.

Girish
Girish Ramakrishnan
2011-09-27 20:41:40 UTC
Permalink
Hi,
I hit send too early

On Wed, Sep 28, 2011 at 2:05 AM, Girish Ramakrishnan
Post by Girish Ramakrishnan
Hi Mark,
Post by Mark
Is this still on time to even get in lighthouse for Qt 5?
Since i'm guessing some api's need to change for this? Not sure though since
i haven't seen anything in lighthouse yet, only read about it a couple
times. But how is this supposed to work anyway, do all key events go through
lighthouse in Qt5?
The lighthouse api won't (or rather doesn't promise to) keep binary or
source compatibility across minor releases. So, changes to lighthouse
can get in anytime in Qt5 lifespan.

Girish
Thiago Macieira
2011-09-27 20:53:11 UTC
Permalink
Post by Mark
Is this still on time to even get in lighthouse for Qt 5?
Since i'm guessing some api's need to change for this? Not sure though since
i haven't seen anything in lighthouse yet, only read about it a couple
times. But how is this supposed to work anyway, do all key events go
through lighthouse in Qt5?
Qt 5.0 is not feature frozen yet, so I don't see why it wouldn't be accepted.

All regular key events come from the windowing system and that's lighthouse.
Global shortcuts could come through another channel (e.g., D-Bus).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
l***@nokia.com
2011-09-28 08:20:38 UTC
Permalink
Post by Thiago Macieira
Post by Mark
Is this still on time to even get in lighthouse for Qt 5?
Since i'm guessing some api's need to change for this? Not sure though since
i haven't seen anything in lighthouse yet, only read about it a couple
times. But how is this supposed to work anyway, do all key events go
through lighthouse in Qt5?
Qt 5.0 is not feature frozen yet, so I don't see why it wouldn't be accepted.
All regular key events come from the windowing system and that's lighthouse.
Global shortcuts could come through another channel (e.g., D-Bus).
Happy to add it to the lighthouse plugin if someone comes up with a
proposal. The API required for this should be rather simple. Basically
something to register global shortcuts and a signal when one of them gets
triggered.

Only other issue is that shortcut handling (QShortCut) is currently in
QtWidgets, not QtGui. The problem here is that someone needs to
disentangle the class from QAction and other classes that should stay in
widgets.

Cheers,
Lars
Thiago Macieira
2011-09-28 08:45:56 UTC
Permalink
Post by l***@nokia.com
Happy to add it to the lighthouse plugin if someone comes up with a
proposal. The API required for this should be rather simple. Basically
something to register global shortcuts and a signal when one of them gets
triggered.
I'm sure it's simple, but maybe not that simple. The API needs to deal with
the case that you ask for a shortcut but you don't get it because either the
system denied you access to it or because something else already is using it.
In order to implement shortcut editing dialogs, there should also be an API to
query whether a given combination is available or already taken.

What's more, Wayland still has no global shortcut API (I talked to the
maintainer yesterday to confirm this), so it would be nice if people got
involved in the project to start discussing how to standardise this.
Post by l***@nokia.com
Only other issue is that shortcut handling (QShortCut) is currently in
QtWidgets, not QtGui. The problem here is that someone needs to
disentangle the class from QAction and other classes that should stay in
widgets.
Long ago, when we started talking about gestures, I had a dream about having a
semantic level above the raw events. Touch events, mouse events, keyboard
events, tablet events, etc., are raw: they convey what action the user did,
but not what the user meant to do. There should be an interpretation layer
that is capable of interpreting multiple event sources over time and give a
resulting semantic. For example, imagine the case of zooming: it can be a key
press (ZoomIn key), Ctrl+Mouse Button 4 (Ctrl+WheelUp) or a two-finger pinch.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Stefan Majewsky
2011-09-28 09:05:33 UTC
Permalink
Post by Thiago Macieira
Long ago, when we started talking about gestures, I had a dream about having a
semantic level above the raw events. Touch events, mouse events, keyboard
events, tablet events, etc., are raw: they convey what action the user did,
but not what the user meant to do. There should be an interpretation layer
that is capable of interpreting multiple event sources over time and give a
resulting semantic. For example, imagine the case of zooming: it can be a key
press (ZoomIn key), Ctrl+Mouse Button 4 (Ctrl+WheelUp) or a two-finger pinch.
I'd like that very much, too. I'm doing something like this already:
If you're on KDE, fire up Palapeli (the jigsaw puzzle game) and look
at the settings dialog. Similar to how KDE apps have a standard dialog
to reconfigure QAction::shortcut()s, this has a dialog to reconfigure
which mouse buttons trigger which actions. (Extra problem here is that
multiple actions may have the same mouse button. The actual action is
then chosen depending on context, e.g. whether the mouse cursor is
hovering the puzzle table or a puzzle piece.)

Greetings
Stefan
l***@nokia.com
2011-09-28 10:47:16 UTC
Permalink
Post by Thiago Macieira
Post by l***@nokia.com
Happy to add it to the lighthouse plugin if someone comes up with a
proposal. The API required for this should be rather simple. Basically
something to register global shortcuts and a signal when one of them gets
triggered.
I'm sure it's simple, but maybe not that simple. The API needs to deal with
the case that you ask for a shortcut but you don't get it because either the
system denied you access to it or because something else already is using it.
In order to implement shortcut editing dialogs, there should also be an API to
query whether a given combination is available or already taken.
Yes, I was oversimplifying a bit :)
Post by Thiago Macieira
What's more, Wayland still has no global shortcut API (I talked to the
maintainer yesterday to confirm this), so it would be nice if people got
involved in the project to start discussing how to standardise this.
I don't think that has to stop us from doing an API for Lighthouse. We
have X11, Win and Mac to test and validate the API against.

That being said, it'd be good if Wayland will get this at some point.
Post by Thiago Macieira
Post by l***@nokia.com
Only other issue is that shortcut handling (QShortCut) is currently in
QtWidgets, not QtGui. The problem here is that someone needs to
disentangle the class from QAction and other classes that should stay in
widgets.
Long ago, when we started talking about gestures, I had a dream about having a
semantic level above the raw events. Touch events, mouse events, keyboard
events, tablet events, etc., are raw: they convey what action the user did,
but not what the user meant to do. There should be an interpretation layer
that is capable of interpreting multiple event sources over time and give a
resulting semantic. For example, imagine the case of zooming: it can be a key
press (ZoomIn key), Ctrl+Mouse Button 4 (Ctrl+WheelUp) or a two-finger pinch.
Yes, it would be nice to get to this, but it is a can of worms to open :)

While it'd be great if someone starts looking into it, I don't think we
should aim at having something in 5.0.

Cheers,
Lars
Post by Thiago Macieira
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Mark
2011-09-28 20:11:03 UTC
Permalink
Post by l***@nokia.com
Post by Thiago Macieira
Post by l***@nokia.com
Happy to add it to the lighthouse plugin if someone comes up with a
proposal. The API required for this should be rather simple. Basically
something to register global shortcuts and a signal when one of them gets
triggered.
I'm sure it's simple, but maybe not that simple. The API needs to deal with
the case that you ask for a shortcut but you don't get it because either the
system denied you access to it or because something else already is using it.
In order to implement shortcut editing dialogs, there should also be an API to
query whether a given combination is available or already taken.
Yes, I was oversimplifying a bit :)
Post by Thiago Macieira
What's more, Wayland still has no global shortcut API (I talked to the
maintainer yesterday to confirm this), so it would be nice if people got
involved in the project to start discussing how to standardise this.
I don't think that has to stop us from doing an API for Lighthouse. We
have X11, Win and Mac to test and validate the API against.
That being said, it'd be good if Wayland will get this at some point.
Post by Thiago Macieira
Post by l***@nokia.com
Only other issue is that shortcut handling (QShortCut) is currently in
QtWidgets, not QtGui. The problem here is that someone needs to
disentangle the class from QAction and other classes that should stay in
widgets.
Long ago, when we started talking about gestures, I had a dream about having a
semantic level above the raw events. Touch events, mouse events, keyboard
events, tablet events, etc., are raw: they convey what action the user did,
but not what the user meant to do. There should be an interpretation layer
that is capable of interpreting multiple event sources over time and give a
resulting semantic. For example, imagine the case of zooming: it can be a key
press (ZoomIn key), Ctrl+Mouse Button 4 (Ctrl+WheelUp) or a two-finger pinch.
Yes, it would be nice to get to this, but it is a can of worms to open :)
While it'd be great if someone starts looking into it, I don't think we
should aim at having something in 5.0.
Cheers,
Lars
I tried to contact the LibQxt devs on their mailing lists but mails bounce
-_- I will give IRC a try tomorrow..
But implementing the global shortcut probably doesn't involve copying
anything from them anyway.

Mark
2011-09-27 20:16:44 UTC
Permalink
Post by Petr Vanek
Post by Mark
What is gonna happen with the global shortcut thing i mentioned earlier?
Is someone gonna make a qt implementation for that or adjust the libqxt
classes so they can be used..? Or something else?
Post by Petr Vanek
personally I'd like to see this feature for sure.
- license of qxt code, but maybe qxt guys can relicense it to be used in the official qt5
- as Thiago mentioned - he wants to support all available "subsystems".
There is no problem on mac and windows. But there are more wrappers around
X11 (for KDE, GNOME, LXDE probably, etc.). And Thiago wants to provide
"connectors" to all those subsystems... which is insane for coding (from my
point of view) - event when all those subsystems use X11 internally
(guessing so) so the "already registered shorcut" error state is available
anyway. But maybe Thiago has different usecases on his mind.
Post by Petr Vanek
petr
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
I will try to contact the qxt folks and point them to this discussion.
Loading...