Re: [Development] Question about modifiers in key events

[Oliver Wolff]

On 14/01/2014 08:26, Oliver Wolff wrote:

Hi,

I am trying to fix 
https://bugreports.qt-project.org/browse/QTBUG-35632 and while
doing so I noticed that this use case is broken on Linux, Windows and 
Mac. Running
the code from my last comment I get different results depending on the 
platform. When

it is run on Linux or Windows I get:
Event: true false false

Application: false false false


while Mac gives:
Event: false false false

Application: false false false


At least on Windows and Linux (xcb) there seems to be logic involved 
which removes
the modifier if the key pressed was a modifier key itself (so if 
Qt::Key_Control is pressed
Qt::ControlModifier is removed from the modifiers). This is done in 
qwindowskeymapper
line 863ff on Windows. I could not find the place where it is done in 
xcb but checking the
code from the bug gives the same result as on Windows. The event's 
modifiers are then

assigned to QGuiApplication's modifier_buttons (which is used for
QApplication::keyboardModifiers() from the bugreport), which is why 
that shows wrong results.
QEvent::modifiers (qevent.cpp line 1026ff) readds the modifier so that 
this gives correct results

at least on Linux and Windows.

My question is which would be the "right way" to fix this behaviour. 
My initial idea was to remove
the logic that removes the modifier from Windows and XCB and adapt 
QEvent::modifiers accordingly
so that the modifiers are not removed and added in various places. 
Unfortunately I do not know, which
behaviour/use case would be broken by that as auto test coverage seems 
to be not existent in that area
(which I would like to change as well, but...). Another option would 
be to add the logic that readds the
modifier (the one from QEvent::modifers) to QGuiApplicationPrivate, 
but that would be another place
that "plays around with the modifiers". Also this logic would have to 
be put in use in several places there

(processKeyEvent, processMouseEvent, processTabletEvent, etc).


Of course it does not have to be added to several places, as only key 
events can remove modifiers depending
on the key pressed. But the question about the best way to fix it still 
stands :)




Does anyone have an idea, why modifiers are removed/added in various 
places and which use case might
be broken when I touch something there? Thiscode seems to be fragile, 
as changes seem to cause regressions
as we have seen over the last few patches to the windows 
implementation. Any preferred way of fixing this?


Cheers,
Olli


___
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

[Development] Question about modifiers in key events

[Oliver Wolff]

Hi,

I am trying to fix https://bugreports.qt-project.org/browse/QTBUG-35632 
and while
doing so I noticed that this use case is broken on Linux, Windows and 
Mac. Running
the code from my last comment I get different results depending on the 
platform. When

it is run on Linux or Windows I get:
Event: true false false

Application: false false false


while Mac gives:
Event: false false false

Application: false false false


At least on Windows and Linux (xcb) there seems to be logic involved 
which removes
the modifier if the key pressed was a modifier key itself (so if 
Qt::Key_Control is pressed
Qt::ControlModifier is removed from the modifiers). This is done in 
qwindowskeymapper
line 863ff on Windows. I could not find the place where it is done in 
xcb but checking the
code from the bug gives the same result as on Windows. The event's 
modifiers are then

assigned to QGuiApplication's modifier_buttons (which is used for
QApplication::keyboardModifiers() from the bugreport), which is why that 
shows wrong results.
QEvent::modifiers (qevent.cpp line 1026ff) readds the modifier so that 
this gives correct results

at least on Linux and Windows.

My question is which would be the "right way" to fix this behaviour. My 
initial idea was to remove
the logic that removes the modifier from Windows and XCB and adapt 
QEvent::modifiers accordingly
so that the modifiers are not removed and added in various places. 
Unfortunately I do not know, which
behaviour/use case would be broken by that as auto test coverage seems 
to be not existent in that area
(which I would like to change as well, but...). Another option would be 
to add the logic that readds the
modifier (the one from QEvent::modifers) to QGuiApplicationPrivate, but 
that would be another place
that "plays around with the modifiers". Also this logic would have to be 
put in use in several places there

(processKeyEvent, processMouseEvent, processTabletEvent, etc).

Does anyone have an idea, why modifiers are removed/added in various 
places and which use case might
be broken when I touch something there? Thiscode seems to be fragile, as 
changes seem to cause regressions
as we have seen over the last few patches to the windows implementation. 
Any preferred way of fixing this?


Cheers,
Olli
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Qt 5.2.1 - merge stable into release

[Paaso Matti]

Hi,

All merges are now done, so all changes required for Qt 5.2.1 need
to be pushed to the 'release' branch from now on.


Only changes fixing P0 or P1 (and really important P2) can be pushed

directly to the release branch.

Changes in the release branch need to be reviewed as usual, but only the
release team  can
stage them.

Staging once a day -every morning- works quite well, so I'd
propose the same now.

Changes in the current 'stable' branch will be part of a future Qt release.

Cheers,
--
Matti Paaso
Digia, Qt


From: Paaso Matti
Sent: 13. tammikuuta 2014 13:04
To: Paaso Matti; development@qt-project.org
Cc: releas...@qt-project.org
Subject: RE: HEADS UP: Qt 5.2.1 - merge stable into release

Hi,

Just a reminder: stable->release merge is ongoing. Still waiting for last 
staged changed to be integrated, and after that we can proceed with the merge.
There seems to be some changes in stable which are not staged, so those changes 
has to be submitted into release -branch if change needs to be in 5.2.1.

BR,
Matti Paaso



From: development-bounces+matti.paaso=digia@qt-project.org 
[mailto:development-bounces+matti.paaso=digia@qt-project.org] On Behalf Of 
Paaso Matti
Sent: 3. tammikuuta 2014 15:36
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] HEADS UP: Qt 5.2.1 - merge stable into release

Hi,

We are about to start the "Qt 5.2.1" release as agreed in [1], which means that:

- We plan to do a fast-forward merge from 'stable' into 'release' branch
on Jan 13th.

- After Jan 13th any changes that are required for 5.2.1 need to be
pushed to the 'release' branch. So if your changes are not in by that
day, please wait until the merge is done and re-target them to the
'release' branch.

The repositories that will be part of the Qt 5.2.1 release merge are:

- qt5
- qtactiveqt
- qtandroidextras
- qtbase
- qtconnectivity
- qtdeclarative
- qtdoc
- qtgraphicaleffects
- qtimageformats
- qtlocation
- qtmacextras
- qtmultimedia
- qtquick1
- qtquickcontrols
- qtscript
- qtsensors
- qtserialport
- qtsvg
- qttools
- qttranslations
- qtwebkit
- qtwebkit-examples
- qtwinextras
- qtxmlpatterns
- qtx11extras

[1]: http://lists.qt-project.org/pipermail/releasing/2013-December/001557.html

Cheers,
--
Matti Paaso
SW Engineer - Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FYI: personal namspaces available on gerrit, aka where to put backups

[Sergio Ahumada]

On 14/01/14 06:10, Hausmann Simon wrote:
>
> I use personal name spaces on gerrit frequently, works great for me.
>

then everything is there to configure and use this feature

http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html#_project_access_control_lists

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FYI: personal namspaces available on gerrit, aka where to put backups

[Hausmann Simon]

I use personal name spaces on gerrit frequently, works great for me.

Simon
Fra: Thiago Macieira
Sendt: 00:16 tirsdag 14. januar 2014
Til: development@qt-project.org
Emne: Re: [Development] FYI: personal namspaces available on gerrit, aka where 
to put backups


On segunda-feira, 13 de janeiro de 2014 23:57:52, Sergio Ahumada wrote:
> http://code.google.com/p/gerrit/issues/detail?id=1008
>
> but as far as I know, the above refs/personal/$user/ never worked well
> for us (or at least I am not aware of anybody using it atm)

I did one push there.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Does isGrayscale() can tell whether a color image can safely be converted to a grayscale image?

[iMath]

In the Image Formats part of QImage doc says
"
The allGray() and isGrayscale() functions tell whether a color image can safely 
be converted to a grayscale image.
"
but in the doc of there 2 functions indicate they're used to decide whether an 
image is grayscale image ,not mentioned they could be used to tell whether a 
color image can safely be converted to a grayscale image.


what about your opinion ?___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FYI: personal namspaces available on gerrit, aka where to put backups

[Thiago Macieira]

On segunda-feira, 13 de janeiro de 2014 23:57:52, Sergio Ahumada wrote:
> http://code.google.com/p/gerrit/issues/detail?id=1008
> 
> but as far as I know, the above refs/personal/$user/ never worked well 
> for us (or at least I am not aware of anybody using it atm)

I did one push there.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FYI: personal namspaces available on gerrit, aka where to put backups

[Sergio Ahumada]

On 13/01/14 23:39, Thiago Macieira wrote:
> On sexta-feira, 15 de fevereiro de 2013 16:28:02, Oswald Buddenhagen wrote:
>> moin,
>>
>> another one from the "could have done this much earlier" ...
>>
>> everyone has a personal namespace under refs/personal/$user/ in every
>> repository hosted on our gerrit. it's possible to create arbitrary
>> branch hierarchies in there. note that the branches are readable by
>> everyone, but writable only by the owner.
>>
>> the easiest way to access it is using the qt/qtrepotools/bin/git-ppush
>> script (docs and examples embedded). otherwise you may need to read up
>> on git refs. ;)
>>
>> this is meant primarily as a backup location for work in progress which
>> you don't want to bother anyone with yet (i.e., being nice to those who
>> have gerrit watches configured. also, you may want to keep your own
>> dashboard clean).
>>
>> this is roughly equivalent to private clones on gitorious, except that
>> it lives on our own gerrit. you'll notice how much this is worth when
>> you push a rebase of a long-stale branch (i.e., lots of new upstream
>> commits since you forked).
>
> Do you know if this is feature is upstream in Gerrit? I'm trying to get the
> same thing working in the Tizen Gerrit and all references I find to this
> feature loop back to us.
>

http://code.google.com/p/gerrit/issues/detail?id=1008

but as far as I know, the above refs/personal/$user/ never worked well 
for us (or at least I am not aware of anybody using it atm)

--
Sergio Ahumada

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FYI: personal namspaces available on gerrit, aka where to put backups

[Thiago Macieira]

On sexta-feira, 15 de fevereiro de 2013 16:28:02, Oswald Buddenhagen wrote:
> moin,
> 
> another one from the "could have done this much earlier" ...
> 
> everyone has a personal namespace under refs/personal/$user/ in every
> repository hosted on our gerrit. it's possible to create arbitrary
> branch hierarchies in there. note that the branches are readable by
> everyone, but writable only by the owner.
> 
> the easiest way to access it is using the qt/qtrepotools/bin/git-ppush
> script (docs and examples embedded). otherwise you may need to read up
> on git refs. ;)
> 
> this is meant primarily as a backup location for work in progress which
> you don't want to bother anyone with yet (i.e., being nice to those who
> have gerrit watches configured. also, you may want to keep your own
> dashboard clean).
> 
> this is roughly equivalent to private clones on gitorious, except that
> it lives on our own gerrit. you'll notice how much this is worth when
> you push a rebase of a long-stale branch (i.e., lots of new upstream
> commits since you forked).

Do you know if this is feature is upstream in Gerrit? I'm trying to get the 
same thing working in the Tizen Gerrit and all references I find to this 
feature loop back to us.

I've been assigned https://bugs.tizen.org/jira/browse/TINF-429
-- 
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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Thiago Macieira]

On segunda-feira, 13 de janeiro de 2014 21:48:22, Kevin Krammer wrote:
> The alternative to platform plugins is to put all those IPC basics into
> QtCore  itself, like what was done for PPS. I.e. moving parts of QtDBus
> into QtCore.

We could do that, though I'd rather not. The basics for kdbus will be quite 
big, since we'll do it without help from a system library.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Please review my submissions

[Thiago Macieira]

The following changes have been unreviewed for some time, even after my ping 
of 10 days ago:

https://codereview.qt-project.org/73060 Centralize support for QBasicAtomic 
for ints and longs
https://codereview.qt-project.org/73062 Replace the type-based 
QAtomicIntegerTraits with a size-based one
https://codereview.qt-project.org/73187 Add support for 16- and 64-bit atomics 
with MSVC
https://codereview.qt-project.org/43290 Add a testAndSet overload to the 
atomics that returns the current value

The changes above are in QtCore and I can still maintainer-approve them (which 
I will do in 72 hours if there are no further -1 or -2).

The following change also requires review but falls outside QtCore, so I 
cannot maintainer-approve them:

https://codereview.qt-project.org/73509
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Kevin Krammer]

On Monday, 2014-01-13, 12:37:54, Thiago Macieira wrote:
> On segunda-feira, 13 de janeiro de 2014 21:28:05, Kevin Krammer wrote:
> > D-Bus simply is *the* system integration technology on Linux, QtCore will
> > need  to be able to do D-Bus at runtime.
> 
> That will always require plugins.

Yes, but QPA is a plugin based system already anyway.

We've seen the same need with PPS on QNX. The system's main IPC system just 
needs to be available to code in QtCore if the system's integration "API" is 
based on IPC.

The alternative to platform plugins is to put all those IPC basics into QtCore 
itself, like what was done for PPS. I.e. moving parts of QtDBus into QtCore.

Cheers,
Kevin

-- 
Kevin Krammer | kevin.kram...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Thiago Macieira]

On segunda-feira, 13 de janeiro de 2014 21:28:05, Kevin Krammer wrote:
> D-Bus simply is *the* system integration technology on Linux, QtCore will
> need  to be able to do D-Bus at runtime.

That will always require plugins.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Kevin Krammer]

On Monday, 2014-01-13, 22:00:53, abba...@gmail.com wrote:
> 1) well, it can go to qt base, but what module? We can't add mount and
> monitor to qtcore, because Linux implementation will require dbus. 

I think this will come up again and again until there is a QPA like platform 
adapter on the QtCore level.

D-Bus simply is *the* system integration technology on Linux, QtCore will need 
to be able to do D-Bus at runtime.

Cheers,
Kevin

-- 
Kevin Krammer | kevin.kram...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt5, Widget move events, and the bug that won't die

[Alex Montgomery]

Hello,

I understand that Widgets are considered "complete" in Qt5, and no new
features are going to be added, but it's seeming more and more like the
actual position of developers is that Widgets are fully deprecated.

For at least five months Digia and others have known that one of the
fundamental Widget events, QMoveEvent, has been broken in Qt5. This is
confirmed on all major platforms, and has been reported as a "known issue"
for several releases, but is getting no love from developers. Here's the
bug:
https://bugreports.qt-project.org/browse/QTBUG-32590

The only reason I can see for this bug to languish as long as it has is
that there is some disagreement over which of the duplicate move events is
the "correct" one; either the first one that agrees with QWidget::pos (as
it worked in Qt4) or the second one that seems to agree with the
documentation.

I would really appreciate it if people could weigh-in on which move event
we should cull (I think we can all agree that at least one of them is
wrong!) and maybe we can make progress on this bug. It's hard to convince
anyone to upgrade to Qt5 when it breaks core features of Qt4. I love the
direction of Qt5, but we all know that there are a lot of Widgets-based
projects in existence, and it's embarrassing that Qt5 is ignoring such a
fundamental bug in that API.

Regards,
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Konstantin Ritt]

2014/1/13 David Faure 

> On Monday, January 13, 2014 10:32:12 PM abba...@gmail.com wrote:
> > I think, "mount" requires root privileges, doesn't it?
>
> Not if the entry is present in fstab, with the option user or users.
>
>
Still, what about volumes (|un)mounting of which requires higher privileges
than the user has? Should we ever care about them? /* IMO, we shouldn't. */


Regards,
Konstantin


> --
> David Faure | david.fa...@kdab.com | Managing Director KDAB France
> 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] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Sune Vuorela]

On 2014-01-13, David Faure  wrote:
> Mounting can still be done with `mount`, no?

Only in rare cases. Normally on linux from a user app you would call out
to udisks, who would connect to polkit and have polkit maybe query you
and other magic.

> Notifications mean listening to dbus signals though, indeed. Tricky.
> Maybe by using libdbus directly, but this contradicts the long term plan of 
> not using libdbus in QtDBus (AFAIK).

In order to not do it half-assed and in a way that only works for your
app run as root, you do need dbus on linux. I don't know how it is done
on windows and mac.

Though mounting/unmounting drives is in general not something I would
expect an application to do, but rather something that happens in the
workspace, be it Windows, Gnome or OSX.

For the specific case of mounting stuff from the file dialog, maybe it
should be even easier to call out to a system file dialog, like the
QFileDialog::getSomething function does. If that can be done somehow,
then I only think we have the 'dedicated system information / system
manipulation apps' left, and I'm not sure that I think that it is a
usecase that Qt should try to solve in qtbase, but rather keep it around
as an extra addon.

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[David Faure]

On Monday, January 13, 2014 10:32:12 PM abba...@gmail.com wrote:
> I think, "mount" requires root privileges, doesn't it?

Not if the entry is present in fstab, with the option user or users.

-- 
David Faure | david.fa...@kdab.com | Managing Director KDAB France
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] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[abbapoh]

I think, "mount" requires root privileges, doesn't it?

Not sure about libudev, maybe it can be used from userspace...

Иван Комиссаров

> 13 янв. 2014 г., в 22:17, David Faure  написал(а):
> 
> On Monday 13 January 2014 18:04:24 Tony Van Eerd wrote:
>>> 1) well, it can go to qt base, but what module? We can't add mount and
>>> monitor to qtcore, because Linux implementation will require dbus.
>> 
>> I'm not familiar with the details there, can you briefly explain why dbus is
>> necessary and why it is a bad thing for qtcore?
> 
> QtCore can't link to QtDBus, since QtDBus links to QtCore.
> 
> Mounting can still be done with `mount`, no?
> Notifications mean listening to dbus signals though, indeed. Tricky.
> Maybe by using libdbus directly, but this contradicts the long term plan of 
> not using libdbus in QtDBus (AFAIK).
> 
> -- 
> David Faure | david.fa...@kdab.com | Managing Director KDAB France
> 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] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[David Faure]

On Monday 13 January 2014 18:04:24 Tony Van Eerd wrote:
> > 1) well, it can go to qt base, but what module? We can't add mount and
> > monitor to qtcore, because Linux implementation will require dbus.
> 
> I'm not familiar with the details there, can you briefly explain why dbus is
> necessary and why it is a bad thing for qtcore?

QtCore can't link to QtDBus, since QtDBus links to QtCore.

Mounting can still be done with `mount`, no?
Notifications mean listening to dbus signals though, indeed. Tricky.
Maybe by using libdbus directly, but this contradicts the long term plan of 
not using libdbus in QtDBus (AFAIK).

-- 
David Faure | david.fa...@kdab.com | Managing Director KDAB France
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] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Thiago Macieira]

On segunda-feira, 13 de janeiro de 2014 18:04:24, Tony Van Eerd wrote:
> > 1) well, it can go to qt base, but what module? We can't add mount and
> > monitor to qtcore, because Linux implementation will require dbus.
> 
> I'm not familiar with the details there, can you briefly explain why dbus is
> necessary and why it is a bad thing for qtcore?

To get the right information from udev, you need to either use its lib or to 
listen via D-Bus. Using D-Bus from QtCore creates a dependency reversal due to 
QtDBus.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Tony Van Eerd]

> 
> 1) well, it can go to qt base, but what module? We can't add mount and
> monitor to qtcore, because Linux implementation will require dbus.

I'm not familiar with the details there, can you briefly explain why dbus is 
necessary and why it is a bad thing for qtcore?


> 2) separate, see above. Drive info should belong to qt core, IMHO.
> 
> Иван Комиссаров
> 
> >
> > To decide:
> > - does it all into qtbase (ie yes!)
> > - do we want QDrive and QDriveInfo separate or together as one class
> > - naming - ie use the same naming throughout
> >
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[abbapoh]

1) well, it can go to qt base, but what module? We can't add mount and monitor 
to qtcore, because Linux implementation will require dbus.
2) separate, see above. Drive info should belong to qt core, IMHO.

Иван Комиссаров

13 янв. 2014 г., в 21:53, Tony Van Eerd  написал(а):

>> 
>>> On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote:
>>> 
>>> Here are the QDrive APIs that Tony mentioned below:
>>> https://codereview.qt-project.org/#change,75336,patchset=1
>> 
>> Cool.
>> 
>> But I think maybe we should get the C++ APIs into qtbase, so that
>> QtQuick.Controls.FileDialog doesn't depend on qtsystems.  So does that
>> mean we need the watchers added on top of https://codereview.qt-
>> project.org/#change,73945 ?
> 
> Yes.
> 
> To decide:
> - does it all into qtbase (ie yes!)
> - do we want QDrive and QDriveInfo separate or together as one class
> - naming - ie use the same naming throughout
> 
> -
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute non-public 
> information. Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in error, 
> please immediately reply to the sender and delete this information from your 
> system. Use, dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Tony Van Eerd]

> 
> On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote:
> 
> > Here are the QDrive APIs that Tony mentioned below:
> > https://codereview.qt-project.org/#change,75336,patchset=1
> 
> Cool.
> 
> But I think maybe we should get the C++ APIs into qtbase, so that
> QtQuick.Controls.FileDialog doesn't depend on qtsystems.  So does that
> mean we need the watchers added on top of https://codereview.qt-
> project.org/#change,73945 ?

Yes.

To decide:
- does it all into qtbase (ie yes!)
- do we want QDrive and QDriveInfo separate or together as one class
- naming - ie use the same naming throughout

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Rutledge Shawn]

On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote:

> Here are the QDrive APIs that Tony mentioned below:
> https://codereview.qt-project.org/#change,75336,patchset=1

Cool.

But I think maybe we should get the C++ APIs into qtbase, so that 
QtQuick.Controls.FileDialog doesn't depend on qtsystems.  So does that mean we 
need the watchers added on top of 
https://codereview.qt-project.org/#change,73945 ?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Open Source Survey - http://goo.gl/5bwR9t

[Michael Kaserer]

Hi everybody,

We are two students currently working on a research project regarding 
motivation for contributing to Open Source projects. You can help us by filling 
out the following web-survey, it only takes max. 2 minutes!

This is the link: http://goo.gl/5bwR9t

Thanks!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Development Digest, Vol 28, Issue 32

[Kurt Pattyn]

I had some changes but unit tests are failing with
FAIL!  : tst_QTcpServer::linkLocal(WithoutProxy) 
'socket->waitForConnected(5000)' returned FALSE. ()
 Loc: [../tst_qtcpserver.cpp(929)]

Is there a problem with the test servers?

see: https://codereview.qt-project.org/#change,73476 and
https://codereview.qt-project.org/#change,73486

These are 2 unrelated changes, but the unit tests fail at the same place.

Best regards,

Kurt


On 13 Jan 2014, at 15:07, development-requ...@qt-project.org wrote:

> From: Paaso Matti 
> Subject: Re: [Development] HEADS UP: Qt 5.2.1 - merge stable into release
> Date: 13 Jan 2014 12:03:56 GMT+1
> To: Paaso Matti , "development@qt-project.org" 
> 
> Cc: "releas...@qt-project.org" 
> 
> 
> Hi,
>  
> Just a reminder: stable->release merge is ongoing. Still waiting for last 
> staged changed to be integrated, and after that we can proceed with the merge.
> There seems to be some changes in stable which are not staged, so those 
> changes has to be submitted into release –branch if change needs to be in 
> 5.2.1.
> BR,
> Matti Paaso

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Convenient script for contributors: git gpush

[Daniel Teske]

Hi,

a long time ago Marius Storm-Olsen wrote a nice convenience tool to ease 
pushing to gerrit. As probably most are unaware of that tool, I'll just resend 
his original annoucement.

--
Hi,

I've just pushed a convenience script to the qtrepotools repository, 
which makes it easier to push patch-sets with reviewers added.

If you ensure that you have /qtrepotools/bin in your path, you can 
simply do
 git gpush + + = =

This pushes HEAD to the remote 'gerrit' to the remote branch which HEAD 
is tracking, and ensures that reviewer1 and reviewer2 are added as 
reviewers to every commit pushed.

The script handles aliases, and I've added a few IRC nicks to the alias 
list already. Contributions welcome for missing IRC aliases.
Note that you can add your own local aliases too simply by
 git config --global gpush.alias. 

Examples:
   (note that $TRB below means the tracking remote branch, most
often 'master', if you are not working on some special branch.)

   git gpush
   # Pushes HEAD:refs/for/$TRB to 'gerrit', without any reviewers

   git gpush +mariuso =thiago
   # Pushes HEAD:refs/for/$TRB to 'gerrit', adding me as a reviewer
   # and sends Thiago a CC mail.

   git gpush :refs/for/buildsystem
   # Pushes HEAD:refs/for/buildsystem to 'gerrit', no reviewers

   git gpush myremote +mstormo
   # Pushes HEAD:refs/for/$TRB to 'myremote', adding me as a reviewer

   git gpush some-branch: +stormols
   # Pushes some-branch:refs/for/$TRB to 'gerrit', adding me as
   # a reviewer

   git gpush -n -v +mariusso +thiago
   # Does a verbose dry-run of the push, showing alias resolving
   # and the final 'git push' command used (comma-separated arguments)

which produces an output like:
  mariusso = stormols
  thiago = thiago-intel
+git,push,-n,-v,--receive-pack=git receive-pack --reviewer=stormols 
--reviewer=thiago-intel,gerrit,HEAD:refs/for/master
Pushing to ssh://storm...@codereview.qt-project.org:29418/qt/qtrepotools
To ssh://storm...@codereview.qt-project.org:29418/qt/qtrepotools
  * [new branch]  HEAD -> refs/for/master

--

Usage:
 git gpush [opts] [remote] [[sha1/ref-from]:[ref-to]] [+] 
[=] [-- ]

 Pushes changes to Gerrit and adds reviewers and CC to the patch
 sets

Description:
 This script is used to push patch sets to Gerrit, and at the same
 time add reviewers and CCs to the patch sets pushed.

 You can use email addresses, Gerrit usernames or aliases for the
 name of the reviewers/CCs. Aliases are read from the
 .git-gpush-aliases
 located next to the script, then from the git config which may
 have aliases set either locally in the current repository,
 globally (in your ~/.gitconfig), or system-wide.

 You can and alias in your global git config like this:
 git config --global gpush.alias. 
 and if you only want it local in the current repository, just drop
 the --global option.

 If no sha1 or ref-from is specified or configured, 'HEAD' is used.
 You may configure a ref-from like this
 git config gpush.ref-from 

 If no ref-to is specified or configured, the remote tracking
 branch for 'ref-from' is used as
 'refs/for/'.
 You may configure a ref-to like this
 git config gpush.ref-to 

 If no remote is specified or configured, 'gerrit' is used. You may
 configure a remote like this:
 git config gpush.remote 

 If all the options above have been populated, the remainder
 options are passed on directly to the normal 'git push' command.
 If you want to avoid specifying all options first, any options
 specified after a '--' are also passed on directly to the
 underlying 'git push' command.

Options:
 -v, --verbose
 Shows the alias resolving, and final 'git push' command as a
 comma-separated list of arguments.

 -n, --dry-run
 Do everything except actually send the updates.
 Can be combined with --verbose to see the final command gpush
 will run.

 --aliases
 Reports all registered aliases.

Copyright:
 Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies).
 Contact: http://www.qt-project.org/

License:
 You may use this file under the terms of the 3-clause BSD license.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Debugging into Qt binaries

[Qi Liang]

This issue is valid since Qt 5.0.0... More details in
https://bugreports.qt-project.org/browse/QTBUG-31724

My "temporary" solution is build my qt libs with "-developer -debug 
-no-framework", it works fine both with creator and xcode.

Regards,
Liang


From: Kuba Ober
Sent: Monday, January 13, 2014 2:54 PM
To: 
Subject: Re: [Development] Debugging into Qt binaries

On Jan 12, 2014, at 7:16 AM, Mike Krus  wrote:

> as far as I know, debug builds on OSX are not redistributable because they 
> directly reference the location of the source files.
> So you need to do your own build and keep the source files in the same place.

Both gdb and lldb offers a way of substituting source paths, so it should be 
possible to substitute a path from the build box with a local path at the time 
of debugging. Qt Creator could do this automagically.

(gdb) set pathname-substitutions /buildbot/path /my/path
(lldb) settings set target.source-map /buildbot/path /my/path

> I’ve found Qt itself debugging on the Mac with Creator to be very slow (takes 
> ages to start up for instance). So I only do it on occasion. I’ve defined 
> DYLD_IMAGE_SUFFIX (as _debug) in my runtime settings and simple rename it to 
> XDYLD_IMAGE_SUFFIX when I don’t want the Qt debugging.

I think recent Qt Creator has a simple checkbox to do it for you.

Cheers, Kuba
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Debugging into Qt binaries

[Kuba Ober]

On Jan 12, 2014, at 7:16 AM, Mike Krus  wrote:

> as far as I know, debug builds on OSX are not redistributable because they 
> directly reference the location of the source files.
> So you need to do your own build and keep the source files in the same place.

Both gdb and lldb offers a way of substituting source paths, so it should be 
possible to substitute a path from the build box with a local path at the time 
of debugging. Qt Creator could do this automagically.

(gdb) set pathname-substitutions /buildbot/path /my/path
(lldb) settings set target.source-map /buildbot/path /my/path

> I’ve found Qt itself debugging on the Mac with Creator to be very slow (takes 
> ages to start up for instance). So I only do it on occasion. I’ve defined 
> DYLD_IMAGE_SUFFIX (as _debug) in my runtime settings and simple rename it to 
> XDYLD_IMAGE_SUFFIX when I don’t want the Qt debugging.

I think recent Qt Creator has a simple checkbox to do it for you.

Cheers, Kuba
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] src/plugins/platforms/eglfs compilation error

[David Faure]

On Monday 30 December 2013 19:26:58 Thiago Macieira wrote:
> On segunda-feira, 30 de dezembro de 2013 21:20:06, David Faure wrote:
> > Xlib.h is included by
> > src/3rdparty/angle/include/EGL/eglplatform.h
> > 
> > I do have /usr/include/EGL/egl.h btw.
> 
> What provides it? 

Mesa-libEGL-devel-9.0.2-34.24.1.x86_64

> I'm guessing you have a non-Mesa GL driver then.

Doesn't seem so.

But I forced a regeneration of the include subdir and the issue seems to have 
gone away.

Apparently QTDIR/include/EGL/ doesn't get generated by syncqt.pl anymore -- 
which is good. Problem solved.

-- 
David Faure | david.fa...@kdab.com | Managing Director KDAB France
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] HEADS UP: Qt 5.2.1 - merge stable into release

[Paaso Matti]

Hi,

Just a reminder: stable->release merge is ongoing. Still waiting for last 
staged changed to be integrated, and after that we can proceed with the merge.
There seems to be some changes in stable which are not staged, so those changes 
has to be submitted into release -branch if change needs to be in 5.2.1.
BR,
Matti Paaso



From: development-bounces+matti.paaso=digia@qt-project.org 
[mailto:development-bounces+matti.paaso=digia@qt-project.org] On Behalf Of 
Paaso Matti
Sent: 3. tammikuuta 2014 15:36
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] HEADS UP: Qt 5.2.1 - merge stable into release

Hi,

We are about to start the "Qt 5.2.1" release as agreed in [1], which means that:

- We plan to do a fast-forward merge from 'stable' into 'release' branch
on Jan 13th.

- After Jan 13th any changes that are required for 5.2.1 need to be
pushed to the 'release' branch. So if your changes are not in by that
day, please wait until the merge is done and re-target them to the
'release' branch.

The repositories that will be part of the Qt 5.2.1 release merge are:

- qt5
- qtactiveqt
- qtandroidextras
- qtbase
- qtconnectivity
- qtdeclarative
- qtdoc
- qtgraphicaleffects
- qtimageformats
- qtlocation
- qtmacextras
- qtmultimedia
- qtquick1
- qtquickcontrols
- qtscript
- qtsensors
- qtserialport
- qtsvg
- qttools
- qttranslations
- qtwebkit
- qtwebkit-examples
- qtwinextras
- qtxmlpatterns
- qtx11extras

[1]: http://lists.qt-project.org/pipermail/releasing/2013-December/001557.html

Cheers,
--
Matti Paaso
SW Engineer - Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.2.1 Release

[Heikkinen Jani]

Hi all,

We are planning to have Qt 5.2.1 release pretty soon. Merge from stable to 
release is planned to be done today (as Matti informed about week ago, see 
http://lists.qt-project.org/pipermail/development/2014-January/014882.html ) 
and release will be done soon after that. Target is to get RC out as soon as 
possible and that's why we need to understand if there is some issues which 
must be fixed before Qt 5.2.1. There is metabug for that: 
https://bugreports.qt-project.org/browse/QTBUG-35562

There is already some issues linked in that metabug but please tell me if some 
mandatory issue for Qt5.2.1 is still missing...

Br,
Jani

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Debugging into Qt binaries

[Ziller Eike]

On Jan 11, 2014, at 5:55 AM, Kuba Ober  wrote:

> On Jan 10, 2014, at 6:07 AM, Ziller Eike  wrote:
> 
>> On Jan 9, 2014, at 6:05 PM, Kuba Ober  wrote:
>> 
>>> I’m trying to figure out the most constructive way of ensuring that an OS X 
>>> build of Qt, installed with the source code, can be actually debugged by 
>>> stepping into the C++ source code in the Qt library. So far I can only step 
>>> into disassembly. This doesn't work out of the box on a fresh install of Qt 
>>> 5.2, and it really has never worked with Qt 5 builds. I never got it 
>>> working for a Qt 4 build either.
> […]
>> 
>> Please see my comment on QTBUG-28496:
>> 
>> basically to solve this completely, including debugging into Qt code, we 
>> need to
>>  • make sure we package the debugging symbols (dsymutil, or maybe 
>> there's a compiler flag that does that during link-time?)
>>  • think about if the debugging symbols should be in a separate 
>> component, it will make the package significantly larger I guess (like Qt 
>> libraries 4.8.4 for Mac (185 MB) and debug libraries (480 MB))
>>  • make it actually find the Qt sources. I've no clue at the moment how 
>> to achieve that with apple's gdb, or if we can patch the debug info in the 
>> dsym at install time
>> 
> 
> Eike, this is very helpful! So far I’ve simply rebuilt Qt locally and are 
> using that for debugging. Is the build script used to build a Qt distribution 
> package available, and if so, where? 
> 
> Thanks, Kuba Ober

The scripts used to build Qt are on gerrit 
(https://codereview.qt-project.org/#admin,project,qtsdk/qtsdk,info), and on 
gitorious here https://qt.gitorious.org/qtsdk/qtsdk .
All starts with packaging-tools/build_wrapper.py in there, e.g. 
handle_qt_release_build()

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development