Re: [Qt5-feedback] Regular expression libraries for QRegExp
Could Re2 be a good candidate? RE2 supports submatch extraction, but not backreferences. If you absolutely need backreferences and generalized assertions, then RE2 is not for you I find nice that it uses DFA, so it guaranties that the execution time is constant. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
Hi, On Thu, Oct 13, 2011 at 12:22 PM, Simon Hausmann simon.hausm...@nokia.com wrote: Would it make sense to do the same for Qt 5 development? Perhaps. At the least, it might also be nice practice to give a heads up (on this, or another ML) so that people are aware of changes which are probably going to break things or require action from other people - preferably before they happen. BR, Robin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thursday, 13 de October de 2011 12:22:39 Simon Hausmann wrote: Hey, There are plenty of source incompatible changes going into the Qt 5 modules. This can make development of depending modules difficult. I recall that the KDE 4 development cycle had similar issues, and I have vague memories of this being mitigated with a simple procedure: Source incompatible changes were pushed only once a week (on Mondays?). Would it make sense to do the same for Qt 5 development? +1 on Binary Incompatible Mondays. This is especially important for changes in the tool classes, which affect just about everything. However, that assumes that your BIC change passes through Gerrit and CI on time. -- 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 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thu, Oct 13, 2011 at 4:09 PM, Robin Burchell robin...@viroteck.net wrote: Hi, On Thu, Oct 13, 2011 at 12:22 PM, Simon Hausmann simon.hausm...@nokia.com wrote: Would it make sense to do the same for Qt 5 development? Perhaps. At the least, it might also be nice practice to give a heads up (on this, or another ML) so that people are aware of changes which are probably going to break things or require action from other people - preferably before they happen. +1 for a heads up on source incompatible changes on this ML. Girish ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thu, Oct 13, 2011 at 1:37 PM, Simon Hausmann simon.hausm...@nokia.com wrote: However, that assumes that your BIC change passes through Gerrit and CI on time. Right. So staging on Monday will sually also result in them being integrated on Monday. The turnarounds aren't too bad right now. But yeah, if the window is missed, then it sucks having to wait another week. You could always make it Friday instead of Monday. That gives you the whole weekend. BR, Robin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thursday 13 October 2011 12:22:39 Simon Hausmann wrote: Hey, There are plenty of source incompatible changes going into the Qt 5 modules. This can make development of depending modules difficult. I recall that the KDE 4 development cycle had similar issues, and I have vague memories of this being mitigated with a simple procedure: Source incompatible changes were pushed only once a week (on Mondays?). Would it make sense to do the same for Qt 5 development? I think the situation is different now than with KDE4: use of git instead of svn, Qt being more modular, CI system, ... With the CI system it is almost impossible to know in advance when a change will get integrated. In the implementation i know (from few month ago), the tests are only run when one clicks Integrates, which means the source incompatible changes will only be run on monday and are likely to fail because changes being batched up. (Source incompatible changes are usually dependences for others changes that also have to wait) Not to count the problem with conflicts that will happen Hopefully now, there is not many source incompatible changes. (+1 for review on the list, i think it was part of lars's statement that all source incompatible changes must have proper review) Anyway, the goal of the modularisation was that module would envolve separately. Then, if it is a problem for modules, the solution is that modules depends on a sha1 of qtbase from the previous monday. (Only update qtbase every monday. in qt5.git) And this also help with binary compatibility. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Xlib support dropped?
Hi! Commit 52acc24cdf9e disabled the possibility to perform Linux builds based on the Xlib QPA plugin. Excuse my ignorance in case I missed earlier hints on dropping it. The code is still there and compiles. Is it non-functional? Harri. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On 10/13/2011 03:28 PM, ext Harri Porten wrote: Hi! Commit 52acc24cdf9e disabled the possibility to perform Linux builds based on the Xlib QPA plugin. Excuse my ignorance in case I missed earlier hints on dropping it. The code is still there and compiles. Is it non-functional? Harri. Nope, it simply means that you explicitly have to pass both -no-xcb and -no-wayland to configure if you don't want those plugins. But we're planning to make the xcb plugin the officially supported platform plugin on X11, the xlib plugin is mainly there for reference (it's not as full-featured as the xcb plugin). -- Samuel ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On Thu, 13 Oct 2011, Samuel Rødal wrote: Nope, it simply means that you explicitly have to pass both -no-xcb and -no-wayland to configure if you don't want those plugins. Then the error message should be rephrased as it said: Doing this will produce a Qt that cannot run GUI applications. But we're planning to make the xcb plugin the officially supported platform plugin on X11, the xlib plugin is mainly there for reference (it's not as full-featured as the xcb plugin). What's the state of xcb on Solaris and AIX? Harri.___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On Thursday 13 October 2011 15:47:49 Harri Porten wrote: On Thu, 13 Oct 2011, Samuel Rødal wrote: But we're planning to make the xcb plugin the officially supported platform plugin on X11, the xlib plugin is mainly there for reference (it's not as full-featured as the xcb plugin). What's the state of xcb on Solaris and AIX? I understood that neither Solaris or AIX would be officially supported platforms ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
Hi,
a consequence of the merging of the refactor branch is that all Q_WS_XX defines
other than Q_WS_QPA are no longer defined on any platform.
Any code #ifdefed Q_WS_XX (or Q_OS_SYMBIAN) is now basically dead and should
be carefully removed; only the code #ifdefed Q_WS_QPA should be left intact
and no longer be enclosed in #if (see for example qtbase: I2ac33765: Remove
Q_WS_ and Q_OS_SYMBIAN which should appear soon after testing/integrating).
I will try to follow that through in qtbase/src and hopefully finally get rid
of the need build with -qpa.
As for the other modules and the qtbase tests, I would like to ask the
respective maintainers to step up (priority is entirely up to you, but I think
any gain in code clarity and speed-up of the compiling/testing cycle
due to reduced code size is worth the effort).
I am not touching the tests since there a few places where it is not entirely
trivial; there is code like
#ifdef Q_WS_X11
sleep(10) // wait for X11 WM
#endif.
This needs to be done on a case by case base. There is currently no way to
query the platform name/type from Qt. Should such a need arise, please talk to
the Lighthouse experts on how best do this.
The process can be semi-automated by running the attached program (a
bastardized version of a preprocesssor from Qt Creator), which takes file names
on the command line. It handles some #ifdefs it knows and prompts you for the
complicated cases like
#if defined(Q_WS_WIN) !defined(QT_NO_FREETYPE) || defined(Q_NO_PRINTER)
whether they evaluate to true/false or should be left intact.
Regards,
Friedemann
--
Friedemann Kleint
Nokia, Qt Development Frameworks
/**
**
** This file is part of Qt Creator
**
** Copyright (c) 2010 Nokia Corporation and/or its subsidiary(-ies).
**
** Contact: Nokia Corporation (qt-i...@nokia.com)
**
** Commercial Usage
**
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Nokia.
**
** GNU Lesser General Public License Usage
**
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 2.1 as published by the Free Software
** Foundation and appearing in the file LICENSE.LGPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU Lesser General Public License version 2.1 requirements
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** If you are unsure which license is appropriate for your use, please
** contact the sales department at http://qt.nokia.com/contact.
**
**/
#include QtCore/QCoreApplication
#include QtCore/QString
#include QtCore/QStringList
#include QtCore/QScopedPointer
#include QtCore/QFile
#include QtCore/QStack
#include QtCore/QPair
#include QtCore/QRegExp
#include QtCore/QDebug
#include QtCore/QDir
#include QtCore/QTemporaryFile
#include stdio.h
#include stdlib.h
enum { debug = 0 };
// Preprocessor: Conditional section
enum PreprocessorSection {
IfSection,
IfdefSection,
IfndefSection,
ElsifSection,
ElseSection,
EndifSection,
OtherSection
};
// Preprocessor: Section stack containing nested '@if' sections
struct PreprocessStackEntry {
PreprocessStackEntry(PreprocessorSection section = OtherSection,
bool parentEnabled = true,
bool condition = false,
bool anyIfClauseMatched = false,
bool wsExpression = false);
PreprocessorSection section;
bool parentEnabled;
bool condition;
bool anyIfClauseMatched;
bool wsExpression;
};
PreprocessStackEntry::PreprocessStackEntry(PreprocessorSection s,
bool p, bool c, bool a, bool w) :
section(s), parentEnabled(p), condition(c), anyIfClauseMatched(a),wsExpression(w)
{
}
class PreprocessContext {
public:
PreprocessContext();
unsigned process(QIODevice in, QIODevice out, QIODevice *inputLog, QString *errorMessage);
private:
void reset();
PreprocessorSection preprocessorLine(const QString in, QString *ifExpression) const;
mutable QRegExp m_ifPattern;
mutable QRegExp m_ifdefPattern;
mutable QRegExp m_ifndefPattern;
mutable QRegExp m_elsifPattern;
const QRegExp m_elsePattern;
const QRegExp m_endifPattern;
QStackPreprocessStackEntry m_sectionStack;
};
PreprocessContext::PreprocessContext() :
// Cut out expression for 'if/elsif '
m_ifPattern(QLatin1String(^\\s*#\\s*if\\s+(.*)$)),
m_ifdefPattern(QLatin1String(^\\s*#\\s*ifdef\\s+(.*)$)),
m_ifndefPattern(QLatin1String(^\\s*#\\s*ifndef\\s+(.*)$)),
Re: [Qt5-feedback] source incompatible changes
On Thursday, 13 de October de 2011 14:00:45 Jedrzej Nowacki wrote: Do we really have so many source incompatible changes? For Qt5 source compatiblity suposed to be kept as much as it make sense. So if you hit this kind of changes daily then something goes really wrong. Simon's email talked about source-incompatible changes, but I think he was referring to binary-incompatible changes. That's how I interpreted it when I replied. -- 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 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On Thursday, 13 de October de 2011 15:51:31 Olivier Goffart wrote: On Thursday 13 October 2011 15:47:49 Harri Porten wrote: On Thu, 13 Oct 2011, Samuel Rødal wrote: But we're planning to make the xcb plugin the officially supported platform plugin on X11, the xlib plugin is mainly there for reference (it's not as full-featured as the xcb plugin). What's the state of xcb on Solaris and AIX? I understood that neither Solaris or AIX would be officially supported platforms That's not exactly right. They will not be reference platforms. Official support for them requires someone supporting them officially. But it's not excluded outright. -- 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 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
On Thursday, 13 de October de 2011 16:39:20 Friedemann Kleint wrote: This needs to be done on a case by case base. There is currently no way to query the platform name/type from Qt. Should such a need arise, please talk to the Lighthouse experts on how best do this. That was already discussed and we agreed we need to know at run-time which plugin was loaded. The process can be semi-automated by running the attached program (a bastardized version of a preprocesssor from Qt Creator), which takes file names on the command line. It handles some #ifdefs it knows and prompts you for the complicated cases like #if defined(Q_WS_WIN) !defined(QT_NO_FREETYPE) || defined(Q_NO_PRINTER) whether they evaluate to true/false or should be left intact. You can probably change Q_WS_WIN to Q_OS_WIN. X11-on-Windows was never supported. -- 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 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Regular expression libraries for QRegExp
I was trying to collect all technical comments about the engines in the page [1] linked by Robin (my fault, I posted that in the wrong thread), but I won't have a stable Internet connection for another week... Either way: RE2 [2] has no lookhead/lookbehind assertions, which was one of the issues to be solved [3] by a proposed engine (and to be honest even QRegExp in Qt4 supports lookaheads, and I don't see any reason to *drop* features instead of gaining new ones). [1] http://developer.qt.nokia.com/wiki/Regexp_engine_in_Qt5 [2] http://code.google.com/p/re2/wiki/Syntax [3] Cf. http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-September/001054.html Cheers, -- Giuseppe D'Angelo ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
#if defined(Q_WS_WIN) !defined(QT_NO_FREETYPE) || defined(Q_NO_PRINTER) whether they evaluate to true/false or should be left intact. You can probably change Q_WS_WIN to Q_OS_WIN. X11-on-Windows was never supported. Q_WS_WIN, Q_WS_MAC and Q_WS_S60 have all been misused where the Q_OS_ macro should have been used. So you* need to check all cases carefully before removing code. *Ideally somebody who knows the OS in question - I wouldn't trust myself to evaluate MAC code for example. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
On Thu, 13 Oct 2011, Friedemann Kleint wrote: a consequence of the merging of the refactor branch is that all Q_WS_XX defines other than Q_WS_QPA are no longer defined on any platform. Will still be defined in a compatibility mode? Alternatively, they could maybe be set to something that triggers a compile error? As an example of the possible impact of such a change I quickly grepped Qt 4's designer source code. 23 occurrences of Q_WS_* usage inside a piece of code written by cross-platform programming experts using the best cross-platform toolkit out there. While I understand the technical reasoning behind such a change I doubt the significance of problems caused by those macros still being set until Qt 6. Harri. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
I was indeed referring to source incompatible changes. I don't mind binary incompatible ones :) Simon From: qt5-feedback-bounces+simon.hausmann=nokia@qt.nokia.com [qt5-feedback-bounces+simon.hausmann=nokia@qt.nokia.com] on behalf of ext Thiago Macieira [thi...@kde.org] Sent: Thursday, October 13, 2011 16:47 To: qt5-feedback@qt.nokia.com Subject: Re: [Qt5-feedback] source incompatible changes On Thursday, 13 de October de 2011 14:00:45 Jedrzej Nowacki wrote: Do we really have so many source incompatible changes? For Qt5 source compatiblity suposed to be kept as much as it make sense. So if you hit this kind of changes daily then something goes really wrong. Simon's email talked about source-incompatible changes, but I think he was referring to binary-incompatible changes. That's how I interpreted it when I replied. -- 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 ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
You could do something like this: #ifdef QT4_SUPPORT #ifdef Q_OS_WIN #define Q_WS_WIN #endif #ifdef Q_OS_MAC #define Q_WS_MAC #endif #endif But there's nothing sensible to be done for Q_WS_X11, Q_WS_QWS etc where there always were multiple window systems on the same OS. Certainly assuming Q_WS_X11 should be defined for Q_OS_LINUX is incorrect. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
13.10.2011, 20:48, shane.kea...@accenture.com: You could do something like this: #ifdef QT4_SUPPORT #ifdef Q_OS_WIN #define Q_WS_WIN #endif #ifdef Q_OS_MAC #define Q_WS_MAC #endif #endif Actually, it's possible to build and use X11 version of Qt on Mac... -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Getting rid of Q_WS_XX in Qt 5 code
On Thu, Oct 13, 2011 at 2:24 PM, Konstantin Tokarev annu...@yandex.ru wrote: 13.10.2011, 20:48, shane.kea...@accenture.com: You could do something like this: #ifdef QT4_SUPPORT #ifdef Q_OS_WIN #define Q_WS_WIN #endif #ifdef Q_OS_MAC #define Q_WS_MAC #endif #endif Actually, it's possible to build and use X11 version of Qt on Mac... But do we really want that? -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thursday 13 October 2011, Jedrzej Nowacki wrote: ... Hi, Do we really have so many source incompatible changes? For Qt5 source compatiblity suposed to be kept as much as it make sense. So if you hit this kind of changes daily then something goes really wrong. Yes, I can remember that a 100% source compatibility was promised (where this excluded changes which can be done automatically using a porting script). Alex ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On 10/13/2011 11:47 PM, ext Harri Porten wrote: On Thu, 13 Oct 2011, Samuel Rødal wrote: Nope, it simply means that you explicitly have to pass both -no-xcb and -no-wayland to configure if you don't want those plugins. Then the error message should be rephrased as it said: Doing this will produce a Qt that cannot run GUI applications. qtbase/src/plugins/platorms/platforms.pro does not attempt to build anything other than xcb so if you run configure; make; make install you'll have a build that can't use GUI apps. When configure allows you to enable other qpa platform plugins then this message will be changed. -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On 10/14/2011 10:46 AM, ext Lincoln Ramsay wrote: On 10/13/2011 11:47 PM, ext Harri Porten wrote: On Thu, 13 Oct 2011, Samuel Rødal wrote: Nope, it simply means that you explicitly have to pass both -no-xcb and -no-wayland to configure if you don't want those plugins. Then the error message should be rephrased as it said: Doing this will produce a Qt that cannot run GUI applications. qtbase/src/plugins/platorms/platforms.pro does not attempt to build anything other than xcb so if you run configure; make; make install you'll have a build that can't use GUI apps. And for reference, the bug that cause this fix to be made is here: https://bugreports.qt.nokia.com/browse/QTBUG-21486 I realize that you can build the X11 platform plugin after you've built Qt and if you do this, you'll be able to run GUI apps again but the extra steps required for this won't be obvious to the average user who doesn't have the xcb dependencies installed. When configure allows you to enable other qpa platform plugins then this message will be changed. The bug report for this is here: https://bugreports.qt.nokia.com/browse/QTBUG-21881 -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Keyboard integration for EGLFS platform plugin
Hey, I'm somewhat new to development on Qt itself, and am seeking comments/suggestions for my attempts at getting basic Linux keyboard support working with the eglfs platform plugin in Qt5. My specific interests are in anyone pointing out any taboos I've committed, especially changes that will need to be made before any merge request is performed. I've setup a temporary repo with my modified plugin here: https://gitorious.org/qt5-eglfs/qt5-eglfs A summary of what I've done: I took the generic linuxinput plugin removed in many commits ago that included keyboard support for QWS and modified it to work without QWS Screen and such. This involved moving the driver itself into the eglfs platform plugin so I was able to control which QWindow to send keyboard events to -- I researched extensively for a method of keeping the two separate, but found nothing helpful. I've added two additional classes: QEglFSUDevMonitor This class parses all connected devices via udev, and determines if any are a keyboard. If they are, it emits a keyboardAdded(QString devnode) signal, with devnode being something like /dev/input/event2 After the main event loop begins, it gets set to a monitor mode where it watches udev for device added/removed messages. It then sends additional keyboardAdded() and keyboardRemoved() signals out. QEglFSConnection This class has an instance of QEglFSUDevMonitor, and handles its signals. When a keyboard is added, it creates a QLinuxInputKeyboardHandler for the device. Whena keyboard is removed, it deletes the object. In QEglFSIntegration, a QEglsFSConnection is created. When the main event loop is started, and a QWindow is created for the platform plugin, it passes it to QEglFSConnection and starts their event-loop based functionality (watching a socket via QSocketNotifier). Presently, it supports hotplugging keyboards, and works well in my limited testing. It lacks capslock support (which was noted in the QWS keyboard implementation), which will need to be fixed, and it fails to turn off console echo. There are likely additional bugs, and if anyone notices them, I'd be very interested to hear it :) Jeffrey Malone ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
