Re: [Development] QPA maintainer

[Sorvig Morten]

+1 from me as well.

Morten

On 17 Dec 2013, at 12:42, Knoll Lars  wrote:

> Hi,
> 
> I’d like to nominate Paul Tvete as the formal maintainer of the QPA
> architecture. He’s the original architect behind it anyway, and I don’t
> think there are many people out there who know it better :)
> 
> Cheers,
> Lars
> 
> ___
> 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] Qt's Leak-on-exit policy

[Sorvig Morten]

On 18 Dec 2013, at 01:22, Thiago Macieira  wrote:
> 
> If it turns out that the failure to destroy is harmless, I'm not sure we 
> should do anything. If it's harmless, that means the extra work required to 
> free the memory is wasted, since it has no benefit to anyone. Just wasted CPU 
> cycles.

An interesting trend on the Apple platforms is not having a clean app shutdown. 
The OS will terminate the process when the user indicates it’s no longer in 
use, for example by switching to another app or closing all the application 
windows.

This suggests two levels of support from Qt:

1) Support a clean shutdown for applications and/or operating systems that 
require this. We go the extra mile to make sure Qt works well with leak 
detecting tools.

2) Support “process terminate” style shutdown for applications that require a 
fast shutdown. This shutdown could be initiated by the OS or by the 
application. The requirements for this lie in the area of the application not 
doing much processing on shutdown (auto-saving settings immediately for 
example), and Qt protecting itself from termination during critical operations 
such as writing QSettings to disk or having a background file transfer in 
progress.

Morten


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

Re: [Development] Maintanance break in CI on Saturday

[Sarajärvi Tony]

Hi all!

IT updated our routers or switches, and this new firmware might be the cause 
for the recent problems we're having. CI can't check anything out from 
Gitorious or Gerrit. IT will revert the firmware at 17:00 EET and see if that 
solves the problem.

Regards,
-Tony

From: development-bounces+tony.sarajarvi=digia@qt-project.org 
[mailto:development-bounces+tony.sarajarvi=digia@qt-project.org] On Behalf 
Of Sarajärvi Tony
Sent: 12. joulukuuta 2013 15:51
To: development@qt-project.org
Subject: [Development] Maintanance break in CI on Saturday

Hi all!

IT will start maintenance work on our CI infrastructure at 9:00 EET. This will 
cause an hour of downtime for our CI as our Jenkins and network test server 
will be moved.

This will cause any build currently running at that point to fail most likely.

After that they will work on different build hosts, causing our OpenSuSE 
capacity to shift down a notch. We will still have a few of them building, but 
if you decide to stage submodules simultaneously on Saturday, you can expect 
some delays on your results :)

Regards,
-Tony

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

[Development] QSettings, OS X

[Samuel Gaist]

Hi,

I recently came across several posts talking about QSettings not working as 
expected on OS X (things not yet reported on the bug tracker). 

On OS X 10.9, it seems that Apple has decided to cache the application 
preferences more aggressively so if one users erases the plist file and 
restarts its application, the preferences are restored because of the cached 
version. The only current solution is to kill cfprefsd. So I wondered if some 
sort of cleanup/"don't load" should be added when reading the first time if the 
plist file doesn't exist ?

While looking at QSettings code, I have found that it uses several platform 
specific helper classes. Wouldn't they better fit in qpa ? if so, I'll be happy 
to move them and in this case should I open a report for that ? Also which 
branch should I target: dev or stable ? 

I also saw that the current implementation doesn't use the mac specialized 
version for parsing configuration files when NativeFormat is used. Would adding 
support for that in QMacSettingsPrivate be a good idea ?

And lastly would a NSUsersDefaults powered helper class be interesting ? (Just 
thinking about it, I didn't implement anything yet)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSettings, OS X

[Liang Qi]

On 18 December 2013 13:41, Samuel Gaist  wrote:

> Hi,
>
> I recently came across several posts talking about QSettings not working
> as expected on OS X (things not yet reported on the bug tracker).
>
> On OS X 10.9, it seems that Apple has decided to cache the application
> preferences more aggressively so if one users erases the plist file and
> restarts its application, the preferences are restored because of the
> cached version. The only current solution is to kill cfprefsd. So I
> wondered if some sort of cleanup/"don't load" should be added when reading
> the first time if the plist file doesn't exist ?
>
> While looking at QSettings code, I have found that it uses several
> platform specific helper classes. Wouldn't they better fit in qpa ? if so,
> I'll be happy to move them and in this case should I open a report for that
> ? Also which branch should I target: dev or stable ?
>
> I also saw that the current implementation doesn't use the mac specialized
> version for parsing configuration files when NativeFormat is used. Would
> adding support for that in QMacSettingsPrivate be a good idea ?
>
> And lastly would a NSUsersDefaults powered helper class be interesting ?
> (Just thinking about it, I didn't implement anything yet)


There is bug report for that,
https://bugreports.qt-project.org/browse/QTBUG-34899

QPA is most for GUI and things depend on GUI. The QPA of Qt Core has not
started yet. If anyone wants to contribute about this topic, go to dev,
obviously.

Regards,
Liang

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

Re: [Development] QPA maintainer

[Paul Olav Tvete]

On Tuesday 17 December 2013 08:52:59 Thiago Macieira wrote:
> On terça-feira, 17 de dezembro de 2013 11:42:56, Knoll Lars wrote:
> > Hi,
> > 
> > I’d like to nominate Paul Tvete as the formal maintainer of the QPA
> > architecture. He’s the original architect behind it anyway, and I don’t
> > think there are many people out there who know it better :)
> 
> +1 from me, there's no one better than him, unless we can convince Tom
> Cooksey to come back :-)

I asked, but unfortunately he doesn't have the time. :)

Thanks for the votes of confidence so far!

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

[Development] QWidget mouse events - different order

[Martin Koller]

I've discovered that with Qt5 I get a different order of mouse events on
a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
double clicking a widget results in Qt4 in:
mousePressEvent 
mouseReleaseEvent 
mouseDoubleClickEvent 
mousePressEvent 
mouseReleaseEvent
but in Qt5 in:
mousePressEvent 
mouseReleaseEvent 
mousePressEvent 
mouseDoubleClickEvent 
mouseReleaseEvent 

I tested with Qt4.8.5 and Qt5.2.
Is this behavioral change intended, undefined, a bug ?
(it results in my app not behaving as before ...)
-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] "The Software shall be used for Good, not Evil" statement in Qt sources

[Lisandro Damián Nicanor Pérez Meyer]

Hi! I would like to now if it's acceptable for the project to have 3rd party 
code with the following statement in 3rd party sources:

"The Software shall be used for Good, not Evil"

At first I thought it wouldn't, but Sune Vuorela pointed me out that it 
*might* be a problem for Digia, so I'm asking here just in case.

The actual source is Source/WebInspectorUI/Scripts/jsmin.py in the qtwebkit's 
submodule.

Kinds regards, Lisandro.

-- 
"Hola, soy su amigo Chespirito. Cuando estaba yo en el vientre de mi madre,
ella sufrió un accidente que la puso al borde de la muerte. El médico le
dijo: -Tendrás que abortar. Y ella respondió: -¿Abortar yo? Jamás.
Es decir, defendió la vida, mi vida. Y gracias a ello estoy aquí."
  Roberto "Chespirito" Gómez Bolaños
  http://es.wikipedia.org/wiki/Chespirito

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] "The Software shall be used for Good, not Evil" statement in Qt sources

[Ziller Eike]

On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> Hi! I would like to now if it's acceptable for the project to have 3rd party 
> code with the following statement in 3rd party sources:
> 
> "The Software shall be used for Good, not Evil”

Does it come with definitions of “good” and “evil” ?

> 
> At first I thought it wouldn't, but Sune Vuorela pointed me out that it 
> *might* be a problem for Digia, so I'm asking here just in case.
> 
> The actual source is Source/WebInspectorUI/Scripts/jsmin.py in the qtwebkit's 
> submodule.
> 
> Kinds regards, Lisandro.
> 
> -- 
> "Hola, soy su amigo Chespirito. Cuando estaba yo en el vientre de mi madre,
> ella sufrió un accidente que la puso al borde de la muerte. El médico le
> dijo: -Tendrás que abortar. Y ella respondió: -¿Abortar yo? Jamás.
> Es decir, defendió la vida, mi vida. Y gracias a ello estoy aquí."
>  Roberto "Chespirito" Gómez Bolaños
>  http://es.wikipedia.org/wiki/Chespirito
> 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
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

Re: [Development] "The Software shall be used for Good, not Evil" statement in Qt sources

[Sune Vuorela]

On 2013-12-18, Ziller Eike  wrote:
>
> On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
>
>> Hi! I would like to now if it's acceptable for the project to have 3rd party 
>> code with the following statement in 3rd party sources:
>> 
>> "The Software shall be used for Good, not Evil”
>
> Does it come with definitions of “good” and “evil” ?

Of course not. See also: Douglas Crockford.

Most linux distributions, as well as google code hosting and others are
treating it as a non-free license.

Oh. and Crockford thinks that eval() in javascript code is evil.

/Sune

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

Re: [Development] "The Software shall be used for Good, not Evil" statement in Qt sources

[Hausmann Simon]

Note that this talks about the _use_ of the software,which is something that no 
user of Qt will ever do. (it's not part of any library and iirc not even the 
build process)


Simon

Fra: Lisandro Damián Nicanor Pérez Meyer
Sendt: 08:36 onsdag 18. desember 2013
Til: development@qt-project.org
Emne: [Development] "The Software shall be used for Good, not Evil" statement 
in Qt sources


Hi! I would like to now if it's acceptable for the project to have 3rd party
code with the following statement in 3rd party sources:

"The Software shall be used for Good, not Evil"

At first I thought it wouldn't, but Sune Vuorela pointed me out that it
*might* be a problem for Digia, so I'm asking here just in case.

The actual source is Source/WebInspectorUI/Scripts/jsmin.py in the qtwebkit's
submodule.

Kinds regards, Lisandro.

--
"Hola, soy su amigo Chespirito. Cuando estaba yo en el vientre de mi madre,
ella sufrió un accidente que la puso al borde de la muerte. El médico le
dijo: -Tendrás que abortar. Y ella respondió: -¿Abortar yo? Jamás.
Es decir, defendió la vida, mi vida. Y gracias a ello estoy aquí."
  Roberto "Chespirito" Gómez Bolaños
  http://es.wikipedia.org/wiki/Chespirito

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "The Software shall be used for Good, not Evil" statement in Qt sources

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 16:46:12, Sune Vuorela wrote:
> On 2013-12-18, Ziller Eike  wrote:
> > On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer 
 wrote:
> >> Hi! I would like to now if it's acceptable for the project to have 3rd
> >> party code with the following statement in 3rd party sources:
> >> 
> >> "The Software shall be used for Good, not Evil”
> > 
> > Does it come with definitions of “good” and “evil” ?
> 
> Of course not. See also: Douglas Crockford.
> 
> Most linux distributions, as well as google code hosting and others are
> treating it as a non-free license.

If only we could get the opinion of a Linux distribution known for being a 
stickler to the free software definitions, to the point of even having their 
own free software guidelines... ;-)

I guess that you brought this up because Debian would have a problem with it. 
I'm going to say that we have a problem with it too, both as open source and 
free software devs and from the commercial point of view. From FOSS point of 
view, we don't limit what you can do with the software; from the commercial 
point of view, some segments of the industry (like defence) might not like it.

-- 
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] "The Software shall be used for Good, not Evil" statement in Qt sources

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 18 December 2013 16:56:23 Hausmann Simon wrote:
> Note that this talks about the _use_ of the software,which is something that
> no user of Qt will ever do. (it's not part of any library and iirc not even
> the build process)

Well, I'm about to test if it's part of the build process or not. Will reply 
later.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] "The Software shall be used for Good, not Evil" statement in Qt sources

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 18 December 2013 09:04:20 Thiago Macieira wrote:
[snip] 
> If only we could get the opinion of a Linux distribution known for being a
> stickler to the free software definitions, to the point of even having their
> own free software guidelines... ;-)

;-)

 
> I guess that you brought this up because Debian would have a problem with
> it.

We do, and also Fedora[0] and Red Hat[1]

[0] 
[1] 

> I'm going to say that we have a problem with it too, both as open
> source and free software devs and from the commercial point of view. From
> FOSS point of view, we don't limit what you can do with the software; from
> the commercial point of view, some segments of the industry (like defence)
> might not like it.

Needless to say that I agree with this.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] Documentation maintainer

[Laszlo Papp]

On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars  wrote:
> Hi,
>
> I’d also like to nominate Topi Reiniö as the overall maintainer of our
> documentation. Topi has been doing an excellent job in handling and
> improving our documentation over the last year, and is IMO the best
> candidate we have for the job.

Hmm, was Jerome not holding this role? I have not seem him stepping
down on this mailing list. What happened to him?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documentation maintainer

[Smith Martin]

No, I think the maintainer was Casper Van Donderan.

martin
 

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Laszlo 
Papp [lp...@kde.org]
Sent: Wednesday, December 18, 2013 7:15 PM
To: Knoll Lars
Cc: Pasion Jerome; development@qt-project.org
Subject: Re: [Development] Documentation maintainer

On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars  wrote:
> Hi,
>
> I’d also like to nominate Topi Reiniö as the overall maintainer of our
> documentation. Topi has been doing an excellent job in handling and
> improving our documentation over the last year, and is IMO the best
> candidate we have for the job.

Hmm, was Jerome not holding this role? I have not seem him stepping
down on this mailing list. What happened to him?
___
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] Documentation maintainer

[Knoll Lars]

Yes, Casper was the maintainer, but he hasn’t done anything since Spring.

Lars

On 18.12.13 19:17, "Smith Martin"  wrote:

>No, I think the maintainer was Casper Van Donderan.
>
>martin
> 
>
>From: development-bounces+martin.smith=digia@qt-project.org
>[development-bounces+martin.smith=digia@qt-project.org] on behalf of
>Laszlo Papp [lp...@kde.org]
>Sent: Wednesday, December 18, 2013 7:15 PM
>To: Knoll Lars
>Cc: Pasion Jerome; development@qt-project.org
>Subject: Re: [Development] Documentation maintainer
>
>On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars  wrote:
>> Hi,
>>
>> I’d also like to nominate Topi Reiniö as the overall maintainer of our
>> documentation. Topi has been doing an excellent job in handling and
>> improving our documentation over the last year, and is IMO the best
>> candidate we have for the job.
>
>Hmm, was Jerome not holding this role? I have not seem him stepping
>down on this mailing list. What happened to him?
>___
>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] Documentation maintainer

[Laszlo Papp]

OK, so not officially, but people were recommending Jerome as the
"ultimate" reviewer for doc changes in the past. I am still interested
in why that is changing now.

On Wed, Dec 18, 2013 at 6:22 PM, Knoll Lars  wrote:
> Yes, Casper was the maintainer, but he hasn’t done anything since Spring.
>
> Lars
>
> On 18.12.13 19:17, "Smith Martin"  wrote:
>
>>No, I think the maintainer was Casper Van Donderan.
>>
>>martin
>>
>>
>>From: development-bounces+martin.smith=digia@qt-project.org
>>[development-bounces+martin.smith=digia@qt-project.org] on behalf of
>>Laszlo Papp [lp...@kde.org]
>>Sent: Wednesday, December 18, 2013 7:15 PM
>>To: Knoll Lars
>>Cc: Pasion Jerome; development@qt-project.org
>>Subject: Re: [Development] Documentation maintainer
>>
>>On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars  wrote:
>>> Hi,
>>>
>>> I’d also like to nominate Topi Reiniö as the overall maintainer of our
>>> documentation. Topi has been doing an excellent job in handling and
>>> improving our documentation over the last year, and is IMO the best
>>> candidate we have for the job.
>>
>>Hmm, was Jerome not holding this role? I have not seem him stepping
>>down on this mailing list. What happened to him?
>>___
>>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] Documentation maintainer

[Smith Martin]

I don't know about "ultimate," but he is certainly an excellent reviewer, so 
that hasn't changed.

martin

From: lp...@archlinux.us [lp...@archlinux.us] on behalf of Laszlo Papp 
[lp...@kde.org]
Sent: Wednesday, December 18, 2013 7:27 PM
To: Knoll Lars
Cc: Smith Martin; Pasion Jerome; development@qt-project.org
Subject: Re: [Development] Documentation maintainer

OK, so not officially, but people were recommending Jerome as the
"ultimate" reviewer for doc changes in the past. I am still interested
in why that is changing now.

On Wed, Dec 18, 2013 at 6:22 PM, Knoll Lars  wrote:
> Yes, Casper was the maintainer, but he hasn’t done anything since Spring.
>
> Lars
>
> On 18.12.13 19:17, "Smith Martin"  wrote:
>
>>No, I think the maintainer was Casper Van Donderan.
>>
>>martin
>>
>>
>>From: development-bounces+martin.smith=digia@qt-project.org
>>[development-bounces+martin.smith=digia@qt-project.org] on behalf of
>>Laszlo Papp [lp...@kde.org]
>>Sent: Wednesday, December 18, 2013 7:15 PM
>>To: Knoll Lars
>>Cc: Pasion Jerome; development@qt-project.org
>>Subject: Re: [Development] Documentation maintainer
>>
>>On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars  wrote:
>>> Hi,
>>>
>>> I’d also like to nominate Topi Reiniö as the overall maintainer of our
>>> documentation. Topi has been doing an excellent job in handling and
>>> improving our documentation over the last year, and is IMO the best
>>> candidate we have for the job.
>>
>>Hmm, was Jerome not holding this role? I have not seem him stepping
>>down on this mailing list. What happened to him?
>>___
>>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] QWidget mouse events - different order

[Rick Stockton]

On 12/18/2013 07:16 AM, Martin Koller wrote:
> I've discovered that with Qt5 I get a different order of mouse events on
> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
> double clicking a widget results in Qt4 in:
> mousePressEvent 
> mouseReleaseEvent 
> mouseDoubleClickEvent 
> mousePressEvent 
> mouseReleaseEvent
> but in Qt5 in:
> mousePressEvent 
> mouseReleaseEvent 
> mousePressEvent 
> mouseDoubleClickEvent 
> mouseReleaseEvent 
>
> I tested with Qt4.8.5 and Qt5.2.
> Is this behavioral change intended, undefined, a bug ?
> (it results in my app not behaving as before ...)
Martin, IIRC, this was an intended change within the platform-specific
code, and results from changes which I wrote during pre-5.0 / pre-5.1
time frames. (Varied by patform - l5.0 for XCB and defunct Xlib, 5.1 for
OSX,and Wayland,  and so on.)

Explanation of current behavior:
We receive the second click and "push" it immediately (the physical
action), and then determine that the very short time delay constituted a
LOGICAL double-click at the same instant, and we push that event
second. This order allows programs to use the evt preceding the final
Release ("Press " versus "DoubleClick") as the UI "action" to perform. I
understand QT's traditional implementations (in user programs) to take
actions following the "Release" event, rather than than the "Press".

IMO, the new behavior is "more" logical, and allows programming to use
the type-of-press IMMEDIATELY preceding Press/DoubleClick type.  But it
is definitely not compatible with Qt4, and (as you see) forces some
programs which implement code for mouseDoubleClickEvent to create
alternate event handler code for the Qt 3/4 versus Qt5 (and future).
- - - - -
The order of events in Qt5.x QML and Widget Apps must be identical, of
course. So, if we need QML to behave exactly is it currently does, then
Widgets should stay as they are (in Qt5), and this becomes a
documentation bug. Programs which depend on touch "Mouse emulation"
behaviors might also be effected by new code attempting to switching back.

KDE Readers: Has anyone noticed this change, and do you need it to be
have as before?

Should I Leave it as it now behaves (create documentation of the
change), or set it back to Qt4 behavior (which I personally don't like)?

-- 
GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A

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

Re: [Development] QWidget mouse events - different order

[Rayner Pupo Gómez]

> I've discovered that with Qt5 I get a different order of mouse events on
> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
> double clicking a widget results in Qt4 in:
> mousePressEvent 
> mouseReleaseEvent 
> mouseDoubleClickEvent 
> mousePressEvent 
> mouseReleaseEvent
> but in Qt5 in:
> mousePressEvent 
> mouseReleaseEvent 
> mousePressEvent 
> mouseDoubleClickEvent 
> mouseReleaseEvent 
> I tested with Qt4.8.5 and Qt5.2.
> Is this behavioral change intended, undefined, a bug ?
> (it results in my app not behaving as before ...)
> -- 

I think it's a mistake to rely on the order of this kind of events, there are 
fired asynchronously, your logic cant depend on this

III Escuela Internacional de Invierno en la UCI del 17 al 28 de febrero del 
2014. Ver www.uci.cu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QWidget mouse events - different order

[Andreas Aardal Hanssen]

On 18 Dec 2013, at 22:07, Rayner Pupo Gómez  wrote:

>> I've discovered that with Qt5 I get a different order of mouse events on
>> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
>> double clicking a widget results in Qt4 in:
>> mousePressEvent 
>> mouseReleaseEvent 
>> mouseDoubleClickEvent 
>> mousePressEvent 
>> mouseReleaseEvent
>> but in Qt5 in:
>> mousePressEvent 
>> mouseReleaseEvent 
>> mousePressEvent 
>> mouseDoubleClickEvent 
>> mouseReleaseEvent 
>> I tested with Qt4.8.5 and Qt5.2.
>> Is this behavioral change intended, undefined, a bug ?
>> (it results in my app not behaving as before ...)
>> -- 
> 
> I think it's a mistake to rely on the order of this kind of events, there are 
> fired asynchronously, your logic cant depend on this

Wrong! The order is very essential and can and must be relied on.

The behaviour in Qt 5 is questionable. I believe the double-click must come 
first to be able to distinguish from two presses.

I also wonder if it’s accurate / true that Qt 4 sends the second press after 
the double-click. AFAIR:

Press
Release
DoubleClick
Release

Is the right events for double-clicking.

Andreas

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

Re: [Development] "The Software shall be used for Good, not Evil" statement in Qt sources

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 18 December 2013 14:32:41 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Wednesday 18 December 2013 16:56:23 Hausmann Simon wrote:
> > Note that this talks about the _use_ of the software,which is something
> > that no user of Qt will ever do. (it's not part of any library and iirc
> > not even the build process)
> 
> Well, I'm about to test if it's part of the build process or not. Will reply
> later.

Confirmed, not part of the build process. I'll just repacka the tarball 
without it then.

Kinds regards, Lisandro.

-- 
On the side of the software box, in the "System Requirements" section,
it said "Requires Windows 95 or better". So I installed Linux.
  Anonymous.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] "The Software shall be used for Good, not Evil" statement in Qt sources

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 20:45:35, Lisandro Damián Nicanor 
Pérez Meyer wrote:
> On Wednesday 18 December 2013 14:32:41 Lisandro Damián Nicanor Pérez Meyer
> 
> wrote:
> > On Wednesday 18 December 2013 16:56:23 Hausmann Simon wrote:
> > > Note that this talks about the _use_ of the software,which is something
> > > that no user of Qt will ever do. (it's not part of any library and iirc
> > > not even the build process)
> > 
> > Well, I'm about to test if it's part of the build process or not. Will
> > reply later.
> 
> Confirmed, not part of the build process. I'll just repacka the tarball
> without it then.

We should remove from our sources.

qtwebkit/Source/WebInspectorUI/Scripts/jsmin.py

-- 
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] Qt's Leak-on-exit policy

[Andreas Hartmetz]

On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> On 18 Dec 2013, at 01:22, Thiago Macieira  wrote:
> > If it turns out that the failure to destroy is harmless, I'm not sure we
> > should do anything. If it's harmless, that means the extra work required
> > to
> > free the memory is wasted, since it has no benefit to anyone. Just wasted
> > CPU cycles.
> 
> An interesting trend on the Apple platforms is not having a clean app
> shutdown. The OS will terminate the process when the user indicates it’s no
> longer in use, for example by switching to another app or closing all the
> application windows.
> 
> This suggests two levels of support from Qt:
> 
> 1) Support a clean shutdown for applications and/or operating systems that
> require this. We go the extra mile to make sure Qt works well with leak
> detecting tools.
> 
> 2) Support “process terminate” style shutdown for applications that require
> a fast shutdown. This shutdown could be initiated by the OS or by the
> application. The requirements for this lie in the area of the application
> not doing much processing on shutdown (auto-saving settings immediately for
> example), and Qt protecting itself from termination during critical
> operations such as writing QSettings to disk or having a background file
> transfer in progress.
> 
Hello.
This is not supposed to be a serious contribution to the discussion.
This is about an unworkable but fun idea.

2) reminds me of a crazy idea I've had once... freeing memory (not
object destruction!) at application exit really serves no other purpose
than making leak checkers happy. Not saying that this isn't an
important goal, btw. So shutdown could be accelerated by putting
free() into a special shutdown mode that just immediately returns.
Of course there would be a conditional branch somewhere, unless you
modified the GOT entry for free() or something. That would add a
runtime overhead, which is worse than slightly slower shutdown.

I don't even know how much time is spent in free() at shutdown, and
faster shutdown isn't a very important goal anyway.
Instantaneous shutdown (see 2)) seems more useful in practice.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt's Leak-on-exit policy

[Alex Montgomery]

Hello,

I think Thiago made a great point when he said, "Objects not properly
destroyed at shutdown could be an indication of something else wrong". The
thing that scares me most about the philosophy that we don't have to delete
reachable dynamically allocated objects is that those objects never have
their destructors called, and those destructors might do important things
besides freeing memory. I personally still believe that Qt as a whole
should strive to not have any on-exit leaks, because that breaks the
implicit agreement we share as object-oriented programmers. Destructors are
designed to be called.

That being said, I like Sorvig's ideas about supporting both the needs of
leak checkers and the needs of near-instant shutdown, if that is at all
possible.

Regards,
Alex


On Wed, Dec 18, 2013 at 4:17 PM, Andreas Hartmetz wrote:

> On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> > On 18 Dec 2013, at 01:22, Thiago Macieira 
> wrote:
> > > If it turns out that the failure to destroy is harmless, I'm not sure
> we
> > > should do anything. If it's harmless, that means the extra work
> required
> > > to
> > > free the memory is wasted, since it has no benefit to anyone. Just
> wasted
> > > CPU cycles.
> >
> > An interesting trend on the Apple platforms is not having a clean app
> > shutdown. The OS will terminate the process when the user indicates it’s
> no
> > longer in use, for example by switching to another app or closing all the
> > application windows.
> >
> > This suggests two levels of support from Qt:
> >
> > 1) Support a clean shutdown for applications and/or operating systems
> that
> > require this. We go the extra mile to make sure Qt works well with leak
> > detecting tools.
> >
> > 2) Support “process terminate” style shutdown for applications that
> require
> > a fast shutdown. This shutdown could be initiated by the OS or by the
> > application. The requirements for this lie in the area of the application
> > not doing much processing on shutdown (auto-saving settings immediately
> for
> > example), and Qt protecting itself from termination during critical
> > operations such as writing QSettings to disk or having a background file
> > transfer in progress.
> >
> Hello.
> This is not supposed to be a serious contribution to the discussion.
> This is about an unworkable but fun idea.
>
> 2) reminds me of a crazy idea I've had once... freeing memory (not
> object destruction!) at application exit really serves no other purpose
> than making leak checkers happy. Not saying that this isn't an
> important goal, btw. So shutdown could be accelerated by putting
> free() into a special shutdown mode that just immediately returns.
> Of course there would be a conditional branch somewhere, unless you
> modified the GOT entry for free() or something. That would add a
> runtime overhead, which is worse than slightly slower shutdown.
>
> I don't even know how much time is spent in free() at shutdown, and
> faster shutdown isn't a very important goal anyway.
> Instantaneous shutdown (see 2)) seems more useful in practice.
> ___
> 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] Qt's Leak-on-exit policy

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 16:41:08, Alex Montgomery wrote:
> I think Thiago made a great point when he said, "Objects not properly
> destroyed at shutdown could be an indication of something else wrong". The
> thing that scares me most about the philosophy that we don't have to delete
> reachable dynamically allocated objects is that those objects never have
> their destructors called, and those destructors might do important things
> besides freeing memory. I personally still believe that Qt as a whole
> should strive to not have any on-exit leaks, because that breaks the
> implicit agreement we share as object-oriented programmers. Destructors are
> designed to be called.

Note I said we should always investigate. But if the result of the 
investigation is that it's harmless, I said I didn't know if we should fix 
things.

I like Andreas's proposal. It would be the best of both worlds.

But it's unworkable. At which point should free() become no-op? Just after 
main() returns or exit() starts executing? Well, the application can continue 
running for a long time after that happens, so not actually freeing memory 
could leak to it blowing up.

The best solution might be a leak suppression information to valgrind, or use 
VALGRIND_FREELIKE_BLOCK.
-- 
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] Qt's Leak-on-exit policy

[Alex Montgomery]

I especially like the idea of creating an ignore list for valgrind if we
could use it for unit tests. Then at least people would have to be
conscious about the memory leaks they create and add them to the valgrind
ignore list if they are intentional.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] #pragma or xxx_s functions

[Nicolás Alvarez]

2013/12/18 Kurt Pattyn :
> For a lot of the standard C functions, Microsoft has implemented "safe" 
> versions.
> Functions like sprintf, scanf, strcpy, aso have "safe" counterparts with an 
> _s suffix: sprintf_s, scanf_s, aso
> When the "non-safe" functions are used, the Microsoft compiler generates a 
> warning that these functions should be replaced by their "safe" counterparts.
> There are 3 ways to get rid of these warnings:
> 1. replacing those functions,
> 2. using a #pragma
> 3. using a compiler flag
>
> What is the recommended way to get rid of these warnings in the Qt sources?
>
> I solved these warnings by replacing the calls with the safe versions, but 
> the patch was rejected because it was recommended to use #pragmas.
> Before proceeding and going through the sources again, I would like to know 
> the recommended practice within Qt.

The so-called safe functions with the _s are Microsoft extensions and
don't exist in other platforms. Changing to the "recommended" "safe"
functions makes the code only compile and work on Windows.

I don't know how Qt handles this, but in other projects the solution
I've seen is to just define _CRT_SECURE_NO_WARNINGS globally.

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

Re: [Development] Qt's Leak-on-exit policy

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 17:03:56, Alex Montgomery wrote:
> I especially like the idea of creating an ignore list for valgrind if we
> could use it for unit tests. Then at least people would have to be
> conscious about the memory leaks they create and add them to the valgrind
> ignore list if they are intentional.

Hardcoding them in the binary via VALGRIND_FREELIKE_BLOCK might be even 
better.

The only problem I have with valgrind hardcoded info is that they still cost 
execution. This is what VALGRIND_FREELIKE_BLOCK expands to:

movq$4866, -56(%rsp)
leaq-56(%rsp), %rax
movq%rdi, -48(%rsp)
xorl%edx, %edx
movq%rsi, -40(%rsp)
movq$0, -32(%rsp)
movq$0, -24(%rsp)
movq$0, -16(%rsp)
#APP
# 1 "" 1
rolq $3,  %rdi ; rolq $13, %rdi
rolq $61, %rdi ; rolq $51, %rdi
xchgq %rbx,%rbx
# 0 "" 2
#NO_APP

So we can't leave those on for release builds.

Then again, from past experience, release builds are unvalgrindable anyway due 
to the compiler being smarter than valgrind (GCC replaces strlen() calls with 
an inline version that can safely read past the end of the string).

-- 
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] #pragma or xxx_s functions

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 23:05:28, Nicolás Alvarez wrote:
> 2013/12/18 Kurt Pattyn :
> > For a lot of the standard C functions, Microsoft has implemented "safe"
> > versions. Functions like sprintf, scanf, strcpy, aso have "safe"
> > counterparts with an _s suffix: sprintf_s, scanf_s, aso When the
> > "non-safe" functions are used, the Microsoft compiler generates a warning
> > that these functions should be replaced by their "safe" counterparts.
> > There are 3 ways to get rid of these warnings:
> > 1. replacing those functions,
> > 2. using a #pragma
> > 3. using a compiler flag
> > 
> > What is the recommended way to get rid of these warnings in the Qt
> > sources?
> > 
> > I solved these warnings by replacing the calls with the safe versions, but
> > the patch was rejected because it was recommended to use #pragmas. Before
> > proceeding and going through the sources again, I would like to know the
> > recommended practice within Qt.
> The so-called safe functions with the _s are Microsoft extensions and
> don't exist in other platforms. Changing to the "recommended" "safe"
> functions makes the code only compile and work on Windows.
> 
> I don't know how Qt handles this, but in other projects the solution
> I've seen is to just define _CRT_SECURE_NO_WARNINGS globally.

I especially like memcpy_s, which takes an extra argument which is most often 
the exact same value you were already passing anyway[1]. Too bad they didn't 
make memcmp_s, that would have been funny, returning EDOOFUS if you passed the 
wrong args :-)

[1] http://msdn.microsoft.com/en-us/library/wes2t00f.aspx
[2] http://fxr.watson.org/fxr/ident?i=EDOOFUS
  See also the suggested replacements at [3], of which I like EEK best
[3] 
https://groups.google.com/forum/?hl=en#!msg/fa.freebsd.hackers/V7cWmQeWVfg/IIjCCbdz4BEJ

-- 
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] QWidget mouse events - different order

[Nicolás Alvarez]

2013/12/18 Andreas Aardal Hanssen :
> On 18 Dec 2013, at 22:07, Rayner Pupo Gómez  wrote:
>
>>> I've discovered that with Qt5 I get a different order of mouse events on
>>> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
>>> double clicking a widget results in Qt4 in:
>>> mousePressEvent
>>> mouseReleaseEvent
>>> mouseDoubleClickEvent
>>> mousePressEvent
>>> mouseReleaseEvent
>>> but in Qt5 in:
>>> mousePressEvent
>>> mouseReleaseEvent
>>> mousePressEvent
>>> mouseDoubleClickEvent
>>> mouseReleaseEvent
>>> I tested with Qt4.8.5 and Qt5.2.
>>> Is this behavioral change intended, undefined, a bug ?
>>> (it results in my app not behaving as before ...)
>>> --
>>
>> I think it's a mistake to rely on the order of this kind of events, there are
>> fired asynchronously, your logic cant depend on this
>
> Wrong! The order is very essential and can and must be relied on.
>
> The behaviour in Qt 5 is questionable. I believe the double-click must come 
> first to be able to distinguish from two presses.
>
> I also wonder if it’s accurate / true that Qt 4 sends the second press after 
> the double-click. AFAIR:
>
> Press
> Release
> DoubleClick
> Release
>
> Is the right events for double-clicking.

That would break many use cases, such as QSpinBox, which performs an
action on every press (not release) and doesn't care about double
click events.

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

Re: [Development] #pragma or xxx_s functions

[Kurt Pattyn]

> On 19 Dec 2013, at 02:05, Nicolás Alvarez  wrote:
> 
> 2013/12/18 Kurt Pattyn :
>> For a lot of the standard C functions, Microsoft has implemented "safe" 
>> versions.
>> Functions like sprintf, scanf, strcpy, aso have "safe" counterparts with an 
>> _s suffix: sprintf_s, scanf_s, aso
>> When the "non-safe" functions are used, the Microsoft compiler generates a 
>> warning that these functions should be replaced by their "safe" counterparts.
>> There are 3 ways to get rid of these warnings:
>> 1. replacing those functions,
>> 2. using a #pragma
>> 3. using a compiler flag
>> 
>> What is the recommended way to get rid of these warnings in the Qt sources?
>> 
>> I solved these warnings by replacing the calls with the safe versions, but 
>> the patch was rejected because it was recommended to use #pragmas.
>> Before proceeding and going through the sources again, I would like to know 
>> the recommended practice within Qt.
> 
> The so-called safe functions with the _s are Microsoft extensions and
> don't exist in other platforms. Changing to the "recommended" "safe"
> functions makes the code only compile and work on Windows.

Yes, I am aware of that. Those functions are put within #ifdef statements.
> 
> I don't know how Qt handles this, but in other projects the solution
> I've seen is to just define _CRT_SECURE_NO_WARNINGS globally.
Qt uses qXXX() functions for a lot of those function: qstrcpy, qstrcmp, aso. 
Those functions expand to the "safe" counterparts when using MSVC. Some 
functions like strerror() cannot be simply replaced by such a wrapper, because 
their signature is too different.
Defining _CRT_SECURE_NO_WARNINGS is an option as far as only the private code 
would be affected, but this cannot be guaranteed. If an "unsecure" method is 
used in a public file, users of the API don't have the option to detect those 
warnings.

In some regulatory markets, people can be forced to actually do something about 
those warnings, and not just hide them. After all, if Microsoft says it's 
unsafe, then it must be really unsafe, isn't it ;-) In the regulatory case, 
people need to patch Qt by removing all suppressions and fix the warnings (and 
that's a huge undertaking).

That's why I want to know what the 'official' statement is from the Qt 
community regarding this issue. I replaced the "unsecure" functions with their 
"secure" counterparts, but that patch was rejected. Now, before going through 
the code again, I want to be sure that I am doing it right this time.
> 
> -- 
> Nicolás
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development