[Development] multiple pointers with Wayland Platform?
BACKGROUND: I saw that one of the Wayland Devs has eventually reached the same Design I already chose for Mouse Buttons in Qt- but his update copies the entire "button translation" code block from X11's within X11's evdev (Driver), which translates "button" keycodes from the evdev module (in the kernel). The current Wayland code supports Three ranges of pointer device 'buttons' keycodes coming from the evdev module. Each is 16 bits wide: The generic 'BTN_0... BTN_1... BTN_2' range Starts at 0x100. The mouse 'BNT_MOUSE' range begins with alias 'BTN_LEFT' at 0x110. And the 'BTN_JOYSTICK' range begins with alias 'BTN_TRIGGER' at 0x120. but, there's another range which might be of concern in Qt5: Beginning with 'BTN_TOOL_PEN' = 0x140, there is another range containing a bunch of entries. The #define statements include: BTN_TOOL_RUBBER 0x141;BTN_TOOL_BRUSH 0x142; BTN_TOOL_PENCIL 0x143; BTN_TOOL_AIRBRUSH 0x144; and others named FINGER, MOUSE, LENS, TOUCH, STYLUS, STYLUS2, DOUBLETAP, TRIPLETAP, and QUADTAP. - - - - - - QUESTION: After it becomes possible to Build the Qt5.0.0. Wayland Platform Plugin and Compositor against current Wayland code, should I assign these alternate button ranges to the SAME Qt::MouseButton values? If I do that, it wouldn't matter whether your 'Pointer Device' resulted in a BTN_JOYSTICK, or BTN_0, or BTN_LEFT Wayland event ---> we'd map them all as a case of Qt::LeftButton. Or should I be thinking in terms of separate event types for the "Pen" range, the "Joystick" range, and the "Generic" device ranges? Right now, I'm imagining that "Pen" might be handled as a unique type of device, while the other 3 can all be mapped as 'THE' mouse-like MouseButton() primary pointer device whenever it shows up. But if you all plan for Qt5 to distinguish between a 'Joystick device' and a 'Mouse device', or to support multiple pointer/pen devices concurrently, then I'll need to keep them separated at this event interface. As always, I'll thank you for your advice: Thanks! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [ANNOUNCE] two new git helper scripts
moin, as you should now, we have this exceedingly useful collection of git scripts at https://qt.gitorious.org/qt-labs/devscripts this collection gained two new little helpers: - git split-ws splits out the whitespace-only changes from a commit (the thing the sanity bot always complains about). after running this command you can use git gui (to selectively re-apply changes where the script went wrong), stash, commit or simply discard the changes (whitespace-only cleanup is frowned upon anyway, unless the code is basically unreadable/uneditable). - git qt-cherry-pick picks commits between the monolithic qt4 repository and the modular qt5 repositories. it rewrites paths to avoid spurious merge conflicts (git's move detection isn't too helpful when it comes to cherry-picks) and contains some policy to find the targets easier. it's strongly recommended to have linked object stores between the repositories to enable 3-way merges. the script isn't as clever as it could be - in particular, it could automatically split the commits into pieces for the right repositories. perl hackers with some spare time are most welcome. you also want to keep the repo reasonably current to keep your local post-commit hook's idea of policy violations in sync with the sanity bot. nokians should continue using devtools/shell, which is kept in sync. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On 11/18/11 11:59 AM, "ext David Faure" wrote: >On Friday 18 November 2011 11:32:09 Olivier Goffart wrote: >> On Friday 18 November 2011 05:01:44 Jason A. Donenfeld wrote: >> > A general [static] recursive remove directory function belongs in >>QDir. >> > >> > A member recursive remove *this* particular *temporary* directory >> > function belongs in QTemporaryDir. >> > >> > Putting a generalized recursive remove directory function into >> > QTemporaryDir makes no organizational sense. > >Did you read the argumentation at >http://developer.qt.nokia.com/forums/viewthread/9860/ >? > >One good reason for having it there, is that there are tons of different >ways >to handle errors. And the way that it picked by QTemporaryDir::removeDir >is to >keep going as much as possible. > >When removing a user's directory, maybe you want to stop at the first >error, >instead. Or to pop up a dialog about the error and offer >continue/abort/skip/etc. > >So for the one particular implementation of "remove as much as possible >in >order to free space in /tmp", having it in QTemporaryDir makes sense. > >> I agree with that, IMHO it belongs to QDir. >> >> About the fact that the function is dangerous, yes it is, but it is >> something developers want to do anyway, and not only with temporary >> directories. > >I agree that "dangerous" is not a valid argument, QFile::remove is >dangerous >too. But error handling is a valid argument. > >The alternative is to have QDir::removeRecursive(StopOnError | >ContinueOnError) of course. I'd be fine with that. But apparently we >still >need to convince Lars that it's ok :) Something like that sounds ok. Certainly better then having the thing in QTempDir. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On 11/18/11 11:32 AM, "ext Olivier Goffart" wrote: >On Friday 18 November 2011 05:01:44 Jason A. Donenfeld wrote: >> A general [static] recursive remove directory function belongs in QDir. >> >> A member recursive remove *this* particular *temporary* directory >>function >> belongs in QTemporaryDir. >> >> Putting a generalized recursive remove directory function into >> QTemporaryDir makes no organizational sense. > > >I agree with that, IMHO it belongs to QDir. Yes, one of my problems with it was that it does clearly not belong into QTemporaryDir, but QDir. > >About the fact that the function is dangerous, yes it is, but it is >something >developers want to do anyway, and not only with temporary directories. Agree, it can be solved by documentation and giving it a name that makes it obvious. QDir::removeAllDirsandFilesRecursive() for example. So my proposal would be to remove it from QTemporaryDir, and then have another merge request adding this as API to QDir. Cheers, Lars > > >> $0.02 > >0.02€ > >-- >Olivier >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On Friday 18 November 2011 11:32:09 Olivier Goffart wrote: > On Friday 18 November 2011 05:01:44 Jason A. Donenfeld wrote: > > A general [static] recursive remove directory function belongs in QDir. > > > > A member recursive remove *this* particular *temporary* directory > > function belongs in QTemporaryDir. > > > > Putting a generalized recursive remove directory function into > > QTemporaryDir makes no organizational sense. Did you read the argumentation at http://developer.qt.nokia.com/forums/viewthread/9860/ ? One good reason for having it there, is that there are tons of different ways to handle errors. And the way that it picked by QTemporaryDir::removeDir is to keep going as much as possible. When removing a user's directory, maybe you want to stop at the first error, instead. Or to pop up a dialog about the error and offer continue/abort/skip/etc. So for the one particular implementation of "remove as much as possible in order to free space in /tmp", having it in QTemporaryDir makes sense. > I agree with that, IMHO it belongs to QDir. > > About the fact that the function is dangerous, yes it is, but it is > something developers want to do anyway, and not only with temporary > directories. I agree that "dangerous" is not a valid argument, QFile::remove is dangerous too. But error handling is a valid argument. The alternative is to have QDir::removeRecursive(StopOnError | ContinueOnError) of course. I'd be fine with that. But apparently we still need to convince Lars that it's ok :) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing Richard Moore as approver
On Thu, Nov 17, 2011 at 09:08:56PM +, ext Richard Moore wrote: > What has actually been more annoying is the lack of the ability to > mark bugs as closed in JIRA, and otherwise change the state of bugs. > this is currently being worked on. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On Friday 18 November 2011 05:01:44 Jason A. Donenfeld wrote: > A general [static] recursive remove directory function belongs in QDir. > > A member recursive remove *this* particular *temporary* directory function > belongs in QTemporaryDir. > > Putting a generalized recursive remove directory function into > QTemporaryDir makes no organizational sense. I agree with that, IMHO it belongs to QDir. About the fact that the function is dangerous, yes it is, but it is something developers want to do anyway, and not only with temporary directories. > $0.02 0.02€ -- Olivier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
A general [static] recursive remove directory function belongs in QDir. A member recursive remove *this* particular *temporary* directory function belongs in QTemporaryDir. Putting a generalized recursive remove directory function into QTemporaryDir makes no organizational sense. $0.02 - Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for quick fix deployment (13:30 CET)
On 11/18/11 9:12 AM, "ext marius.storm-ol...@nokia.com" wrote: >On 11/18/11 8:03 AM, "Rohan McGovern" wrote: > >>marius.storm-ol...@nokia.com said: >>> On 11/17/11 1:12 PM, "ext marius.storm-ol...@nokia.com" >>> wrote: >>> >>> >Hi, >>> > >>> >Gerrit will go down at 13:30 CET today, for deployment of fixes for >>>the >>> >following issues: >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-270 >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-335 >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-347 >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-350 >>> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-352 >>> > >>> >It should only take a few minutes to deploy and restart the service, >>> >should nothing unexpected happen. >>> > >>> >I'll will send out a follow-up once the service is back up. >>> >>> Deployment was successful, thank you for your patience. >>> >> >>Unfortunately the new version appears to have some quite annoying bug >>which is "damaging" the history of our repositories: >>https://bugreports.qt.nokia.com/browse/QTQAINFRA-389 >> >>If you have a look at http://qt.gitorious.org/qt/qtbase/commits/master >>for example you can see that all of today's changes look like they've >>been applied twice. >> > >Ouch! We'll do a roll-back of the deployment as soon as the right people >are in. > >Sorry for the inconvenience! We have now successfully rolled back to the previous version of Gerrit. Hopefully we'll get that issue solved soon, and can re-roll the deployment of the original fixes. Thank you for your patience! -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for quick fix deployment (13:30 CET)
On 11/18/11 8:03 AM, "Rohan McGovern" wrote: >marius.storm-ol...@nokia.com said: >> On 11/17/11 1:12 PM, "ext marius.storm-ol...@nokia.com" >> wrote: >> >> >Hi, >> > >> >Gerrit will go down at 13:30 CET today, for deployment of fixes for the >> >following issues: >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-270 >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-335 >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-347 >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-350 >> >https://bugreports.qt.nokia.com/browse/QTQAINFRA-352 >> > >> >It should only take a few minutes to deploy and restart the service, >> >should nothing unexpected happen. >> > >> >I'll will send out a follow-up once the service is back up. >> >> Deployment was successful, thank you for your patience. >> > >Unfortunately the new version appears to have some quite annoying bug >which is "damaging" the history of our repositories: >https://bugreports.qt.nokia.com/browse/QTQAINFRA-389 > >If you have a look at http://qt.gitorious.org/qt/qtbase/commits/master >for example you can see that all of today's changes look like they've >been applied twice. > Ouch! We'll do a roll-back of the deployment as soon as the right people are in. Sorry for the inconvenience! -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
