[Development] Auto-assignment in JIRA

[Shaw Andy]

I was creating another bug report earlier today in JIRA and I noticed that it 
was assigning to someone who didn't seem to be right for the component at all 
since I don't believe they are the maintainer for it and I recalled that this 
is not the first time I've noticed that the auto-assigner is clearly incorrect 
and therefore it could end up in some sort of limbo.

I know that anyone can pick up a bug report not actively being worked on so it 
doesn't have much meaning in that regard, but is there an actual benefit to 
having the auto-assigner set? Are the maintainers actively utilizing this or 
would it be best that all new bugs are unassigned by default and then someone 
picks them up when they are going to actively work on it? 

I don't have an agenda (aside from the auto-assignment being correct if this is 
the work flow we want) either way on this but I am curious as to whether it is 
useful or not. Therefore if it is useful then we can at least clean it up a bit 
so it is assigning correctly (either to the maintainer or to unassigned).

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Shaw Andy]

It wasn’t meant to be seen as a viable solution for rendering from QtWebEngine 
at least, but more for if you were already rending to a QPrinter with QPainter. 
If you use drawText() and so forth then that should work with QPdfWriter in a 
way that makes the text be rendered as text in the PDF. If this is not 
happening then please report it as it should be handled correctly in that 
instance.

Andy

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 4. desember 2015 15:07
To: Mark De Wit
Cc: Shaw Andy; development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 4, 2015, at 7:53 AM, Mark De Wit 
<mark.de...@iesve.com<mailto:mark.de...@iesve.com>> wrote:

>We tried this solution already in combination with WebEngine.  It draws a 
>bitmap of the current view into the PDF.  Even text gets rendered as bitmaps, 
>it is a far cry from supporting our multi-page HTML documents.

I may have tried QPdfWriter once as well and had issues with sizing and 
scaling.  I know I spent a *lot* of time with cross-platform PDF generation 
development.

Rendering PDF report text as bitmaps would not be acceptable to my customers 
either.

Not good news for developers that must create PDFs on iOS.

-Ed


Mark

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 04 December 2015 13:31
To: Shaw Andy <andy.s...@theqtcompany.com<mailto:andy.s...@theqtcompany.com>>
Cc: Mark De Wit <mark.de...@iesve.com<mailto:mark.de...@iesve.com>>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 3, 2015, at 8:31 AM, Shaw Andy 
<andy.s...@theqtcompany.com<mailto:andy.s...@theqtcompany.com>> wrote:

>There is QPdfWriter at least which is a paint device, so you could use that 
>for generating PDFs as that is available iOS from what I can see.

I *really* need to spend some time browsing All 
Classes<http://doc.qt.io/qt-5/classes.html>  !

http://doc.qt.io/qt-5/classes.html

Thanks again Andy!

-Ed




Andy

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Edward Sutton
Sent: 3. desember 2015 15:09
To: Mark De Wit
Cc: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries

Will Qt 5.6 have alternative methods to export HTML to PDF that support major 
platforms of Android, iOS, Linux, OS X, and Windows?

On iOS a Qt developer must resort to native code to generate PDF files.

Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported 
on iOS.  While iOS can create and displays PDF’s just fine, iOS has no printer 
support.


In the future, Is it possible the PDF creation dependency could be separated 
from QPrinter?  So that Qt PDF generation would have better cross-platform 
support?



QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on 
iOS

printer.setOutputFormat(QPrinter::PdfFormat);

printer.setOutputFileName(pdfFileName);

drawReport(printer);

m_painter.end();


Without understanding internals of PDF file creation, it feels like PDF 
creation should not be dependent on QPrinter?

-Ed


On Dec 3, 2015, at 7:37 AM, Mark De Wit 
<mark.de...@iesve.com<mailto:mark.de...@iesve.com>> wrote:

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I’m happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit <mark.de...@iesve.com<mailto:mark.de...@iesve.com>>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enoug

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Shaw Andy]

There is QPdfWriter at least which is a paint device, so you could use that for 
generating PDFs as that is available iOS from what I can see.

Andy

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Edward Sutton
Sent: 3. desember 2015 15:09
To: Mark De Wit
Cc: development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries

Will Qt 5.6 have alternative methods to export HTML to PDF that support major 
platforms of Android, iOS, Linux, OS X, and Windows?

On iOS a Qt developer must resort to native code to generate PDF files.

Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported 
on iOS.  While iOS can create and displays PDF’s just fine, iOS has no printer 
support.


In the future, Is it possible the PDF creation dependency could be separated 
from QPrinter?  So that Qt PDF generation would have better cross-platform 
support?



QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on 
iOS

printer.setOutputFormat(QPrinter::PdfFormat);

printer.setOutputFileName(pdfFileName);

drawReport(printer);

m_painter.end();


Without understanding internals of PDF file creation, it feels like PDF 
creation should not be dependent on QPrinter?

-Ed


On Dec 3, 2015, at 7:37 AM, Mark De Wit 
> wrote:

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I’m happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit >; 
development@qt-project.org
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QString behavior change

[Shaw Andy]

   What are the chances that such a change can be accepted ? (i mean, i can
   submit such a patch, but that would mean breaking a *lot* of code).
 
  QOptional does not exist yet and for very good reasons.
 
  QVariant is already in use, so I don't think you'd be sending a patch to use
  QVariant.
 
  What are you proposing to send?
 
 Changing QtSql so that :
 - null QString are binded to SQL '' (same as empty string)
 - to bind to NULL you thus require a null QVariant (same as for null
 int), that require no change
 
 I don’t expect such a change to be accepted before at least Qt6, but i’d
 be happy to hear i’m wrong.

Speaking from my perspective as I have done a fair bit with QtSql in the past, 
I highly doubt that this change could be done before Qt 6, there is a risk that 
it will break existing applications and silently so too therefore it would be a 
risk whenever it would be done. Ergo it would be best that it is done in Qt 6 
IMO. Though I am not the maintainer of the module so naturally it is not my 
call.

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

Re: [Development] Removing win32-msvc2005 for 5.5?

[Shaw Andy]

 As the subject says, ok to do it?
 
 Note that this does *NOT* apply to wince60*-msvc2005 mkspecs.
 
 If there are no objections, we'll do it in one week.

I think it is certainly safe to remove it, it hasn't been supported in a long 
time and I doubt it even works.

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

Re: [Development] Qt::WA_PaintOnScreen Changes

[Shaw Andy]

  I am porting an application to Qt5/KF5 and was surprised to see the
  main widget of the application was showing all black. There are
  screenshots of the original version and the buggy version[1] online. I
  removed
 
  setAttribute( Qt::WA_PaintOnScreen, true );
 
  on that widget and the widget was rendering fine again. I would like
  to know if that was a good idea and what are the implications or if
  this is a bug in Qt.
 
 This seems odd. I'm not certain what would cause this, but it shouldn't be
 like that. Can you create a bugreport and provide a small example that
 reproduces this.

If you were using WA_PaintOnScreen then you also need to ensure you reimplement 
paintEngine() to return 0. Had you done that at all?

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

Re: [Development] configure -developer-build --prefix=$PWD/qtbase

[Shaw Andy]

 Em qua 26 mar 2014, às 08:21:20, Alan Ezust escreveu:
  Does anyone understand what the difference is between a qt that is
  configured like this:  ./configure -developer-build versus a Qt that is
  configured like this: configure -developer-build --prefix=$PWD/qtbase
 
   according to ./configure --help, it says this:
  -prefix dir .. This will install everything relative to dir
   (default /usr/local/Qt-5.3.0, $PWD if
  -developer-build is active)
 
 Unfortunately, both are correct.
 
 If you run the top-level configure and you want a no-install build, you need 
 to
 pass -prefix=$PWD/qtbase. If you run the qtbase configure, you pass -
 prefix=$PWD.
 
 When you run configure -help, you always get the help output from the qtbase
 configure. That's why it says $PWD instead of $PWD/qtbase.

[snip]

Maybe it would be best to actually expand $PWD in the help output to state 
where it would actually end up so there is no confusion?

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

Re: [Development] Problems pushing changes to Gerrit

[Shaw Andy]

 Gerrit seems to reject some of my changes with this error:
 
   $ git push ssh://mandri...@codereview.qt-project.org/qt/qt HEAD:refs/for/4.8
   error: error: invalid protocol: wanted 'old new ref'
   fatal: internal server error
   fatal: The remote end hung up unexpectedly
   Counting objects: 30, done.
   Compressing objects: 100% (6/6), done.
   error: pack-objects died of signal 13
   error: failed to push some refs to 'ssh://mandri...@codereview.qt-
 project.org/qt/qt'
 
 For example, today I successfully pushed a change to qtmultimedia, but failed 
 to
 push a change to qt4. Some weeks ago I got a similar problem with qtwebkit,
 but
 resolved this by pushing from a different machine. Now I get this error from 
 two
 different machines (with different SSH keys), one running Ubuntu and one
 running
 Debian GNU/Linux.
 
 Retrying from a fresh Git tree, adding different port numbers or URI schemes
 does not help.
 
 Does anybody know what may cause this behavior?

You seem to be missing the port, if you add:

 :29418

After the address so it is:

git push ssh://mandri...@codereview.qt-project.org:29418/qt/qt HEAD:refs/for/4.8

then does this solve the problem?

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

Re: [Development] Harmonizing the Qt 5.x Documentation

[Shaw Andy]

 Em ter 11 mar 2014, às 17:17:46, Andre Somers escreveu:
  I seriously don't see the benefit of this harmonization. When I look
  at the docs for a class, I often just look for method names that seem to
  do what I need. That usually works very with Qt. Now, I will need to go
  check for every method if it actually exists in the version of Qt I'm
  on, by looking for a since tag. How is that helping me to become more
  productive?
 
 If you want to be productive with the exact docs for the version you're using
 and full, indexed text search, you should use Qt Assistant or the integrated
 Help in Qt Creator.

And as Jerome pointed out, the Qt 5.0 and 5.1 docs will be on doc.qt.digia.com 
too so they won't be completely gone from the web. I am all for the idea and I 
am having to look up the older documentation for various reasons all the time.

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

Re: [Development] CI Broken for 4.8

[Shaw Andy]

I was informed earlier in the week that it was known and being investigated, 
there was a problem with the Mac OS X 10.6 machine but I was also under the 
impression that it would be fixed already by now so I don't know what is 
happening with it at the moment.

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Richard Moore
Sent: 06 March 2014 11:09
To: development@qt-project.org
Subject: [Development] CI Broken for 4.8

Hi,

CI appears to be broken for 4.8, for example the following changes (separate CI 
runs) have failed on the same tests even though one is just a doc fix:

https://codereview.qt-project.org/#change,79247
https://codereview.qt-project.org/#change,78289

It appears to the macos node that is stuck. Last integration was Tuesday, 
February 25, 2014 21:47:56.

Anyone able to look into this?

Rich.

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

[Development] Question about deferred delete handling in sendPostedEvents

[Shaw Andy]

Hi,

I was looking at a problem regarding deferred deletes causing a crash inside 
nested loops and it was pointed out that in QCoreApplication::setPostedEvents() 
there is some code there that determines whether it is safe to delete the 
object or not. From my understanding it will only delete an object if the loop 
level that it was called from is greater than the current one. However it seems 
that if the loop level is 0 (i.e. main event loop I guess) and the current one 
is higher than 0 it deletes anyway, is this the correct intention? Does anyone 
know why this is safe if so?

For reference the code is this bit specifically:

const bool allowDeferredDelete =
(loopLevel  data-loopLevel
 || (!loopLevel  data-loopLevel  0)
 || (event_type == QEvent::DeferredDelete
  loopLevel == data-loopLevel));

Where loopLevel is 0 but data-loopLevel is greater than 0.

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

Re: [Development] Question about deferred delete handling in sendPostedEvents

[Shaw Andy]

  I was looking at a problem regarding deferred deletes causing a crash inside
  nested loops and it was pointed out that in
  QCoreApplication::setPostedEvents() there is some code there that
  determines whether it is safe to delete the object or not. From my
  understanding it will only delete an object if the loop level that it was
  called from is greater than the current one. However it seems that if the
  loop level is 0 (i.e. main event loop I guess) and the current one is
  higher than 0 it deletes anyway, is this the correct intention? Does anyone
  know why this is safe if so?
 
  For reference the code is this bit specifically:
 
  const bool allowDeferredDelete =
  (loopLevel  data-loopLevel
 
   || (!loopLevel  data-loopLevel  0)
   || (event_type == QEvent::DeferredDelete
 
loopLevel == data-loopLevel));
 
  Where loopLevel is 0 but data-loopLevel is greater than 0.
 
 Loop level equal to 0 means the object was deleteLater'ed in main(), before
 exec(). That is, when no event loop was started. That means any event loop
 level can delete it.
 
 Otherwise, the object is only deleted if you're running a loop with equal or
 *lower* nesting level than when it was deleteLater'ed.

Aha, this does make a lot of sense, thanks this is very useful to know :)

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

Re: [Development] Plans for printing in 5.3 onwards

[Shaw Andy]

 * Keep the patches switching to the new platform plugin code in reserve to
 either switch for 5.3 if testing proves the plugin is stable enough, or more
 likely to use in 5.4 if not.

I like this idea at least, because this enables the reviews to keep going and 
we can keep testing until we are certain it is all good. Takes the pressure off 
somewhat then.

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

Re: [Development] Plans for printing in 5.3 onwards

[Shaw Andy]

  I’ve now gone through all changes. The set looks pretty good overall, and
  testing on Linux showed no regressions compared to 5.2.
 
  One correction here: The paperRect as shown in the preview of the dialogs
  manual test shows some slightly different results, that look like a
  rounding issue. Not sure whether that’s a problem that should be fixed or
  not, but you should have a look.
 
  
  IMO, you can go ahead and stage the first set of changes that are mainly
  cleanups.
  
  There are quite a few comments on the changes adding the new public API.
  Nothing major, but it would be good if you could go through the series and
  fix patches according to the comments. There’s also a compile error with
  QPageMargins that somehow is not catched on Linux (no idea why not).
  
  Friedemann said that there were still issues with printing on Windows (see
  comments on https://codereview.qt-project.org/#change,76913).
  
  Could you have a look at these things and update the patch set?
 
 I've also gone through some of the changes and ran the tests on the full set 
 on
 Mac, I put in the comments I had so far. It generally looks good but once the
 dust settles on the ones needing changes I'll do a proper test of the 
 functionality
 on Mac as well to check that actual printing works fine too. I have some 
 things
 in mind to check as I've dealt with enough printing problems the past year to 
 last
 me a life time ;)

Since the feature freeze is on the 14th I have been eagerly awaiting the 
changes that have been indicated already have been done so I can carry on 
testing. Have I missed some updates or something? I am concerned because I know 
how many people use the printing and we need to try and get these changes 
tested and fixed where necessary in good time for the final so the transition 
is not really noticed by the users. So is there any update on these patches or 
should we consider waiting until Qt 5.4 to ensure they are all ready correctly?

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

Re: [Development] Plans for printing in 5.3 onwards

[Shaw Andy]

 I’ve now gone through all changes. The set looks pretty good overall, and
 testing on Linux showed no regressions compared to 5.2.
 
 One correction here: The paperRect as shown in the preview of the dialogs
 manual test shows some slightly different results, that look like a
 rounding issue. Not sure whether that’s a problem that should be fixed or
 not, but you should have a look.
 
 
 IMO, you can go ahead and stage the first set of changes that are mainly
 cleanups.
 
 There are quite a few comments on the changes adding the new public API.
 Nothing major, but it would be good if you could go through the series and
 fix patches according to the comments. There’s also a compile error with
 QPageMargins that somehow is not catched on Linux (no idea why not).
 
 Friedemann said that there were still issues with printing on Windows (see
 comments on https://codereview.qt-project.org/#change,76913).
 
 Could you have a look at these things and update the patch set?

I've also gone through some of the changes and ran the tests on the full set on 
Mac, I put in the comments I had so far. It generally looks good but once the 
dust settles on the ones needing changes I'll do a proper test of the 
functionality on Mac as well to check that actual printing works fine too. I 
have some things in mind to check as I've dealt with enough printing problems 
the past year to last me a life time ;)

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

Re: [Development] Dropping XP?

[Shaw Andy]

 FWIW, Browser stats fun:
 Bar chart last 30 days:
 http://gs.statcounter.com/#os-ww-monthly-201312-201312-bar
 (Windows XP still has 18.52%)
 
 Trend chart:
 http://gs.statcounter.com/#os-ww-monthly-200808-201311
 Of course - it's declining. The decline seems actually to flatten out.
 
 
 I think most developers will be fine if Windows XP is dropped.
 They can always use Qt 5.2 if they ever need to target Windows XP.

In all reality though are we doing anything to assure Windows XP actually works 
or is it a case of we expect it to work? We could always indicate that it's not 
tested but if someone cares to do the patches etc then they could be accepted. 
Doesn't cost us anything then if you ask me.

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

Re: [Development] Qt 5.2 header diff: QtWidgets

[Shaw Andy]

IIRC it wasn't even compiled into the QtWidgets library, although the 
documentation and everything existed, those symbols were never in Qt. Morten 
can say 100% at least but that is my understanding and recollection at least.

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Jake Petroules
Sent: 5. november 2013 19:10
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] Qt 5.2 header diff: QtWidgets

On Nov 5, 2013, at 12:55 PM, Thiago Macieira 
thiago.macie...@intel.commailto:thiago.macie...@intel.com wrote:


On terça-feira, 5 de novembro de 2013 12:39:55, Jake Petroules wrote:

On Nov 5, 2013, at 12:22 PM, Marc Mutz 
marc.m...@kdab.commailto:marc.m...@kdab.com wrote:

But can be overloaded on the new types, right.

Does this 100% NEED to be reverted? It wasn't even functional until 5.2
IIRC.

I really hope this does not have to wait until 6.0, it was a great
improvement in usability.

We didn't say revert. But we need to restore BC.

Unless, of course, you tell us that no one could possibly have been using this
because it was so broken.
--
Thiago Macieira - thiago.macieira (AT) intel.comhttp://intel.com
 Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.orgmailto:Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Morten merged the port of QMacCocoaViewContainer and QMacNativeWidget to dev on 
23 Sept.

Prior to that it was unusable.
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.comhttp://www.petroules.com
Email: jake.petrou...@petroules.commailto:jake.petrou...@petroules.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending Jira changes

[Shaw Andy]

 I looked into the desired workflow changes for Jira (as discussed on this 
 list)
 and am doing some general cleanups which I would like to bring up at this
 point. The more invasive bulk changes will happen on Monday while others
 have already happened. Please note that this may temporarily reduce the
 responsiveness of the system.
 
 1.) I merged the Resolved, Closed and Verified states into a single state and
 added a shortcut from Open to Closed. I also took the liberty of renaming
 some of the transitions based on perceived usability and partly due to
 system requirements. The new workflow is as follows:
 
 https://bugreports.qt-
 project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowNa
 me=Qt%20Bug%20Tracking%20v2.0stepId=8width=fullheight=full
 
 Every Suggestion, Bug and Task issue will get this update. Any issue that is
 currently Resolved, Verified or Closed will be transitioned to the Closed
 state.
 
 If you have any concerns about the modified workflow please raise them
 now.
 
 2.) The QTJIRA project had a very inappropriate workflow and permission set.
 It was updated to carry the new Qt Bug workflow already. From now on it has
 the same setup as every other project. The only difference is that the project
 will not carry the OG Approvers group. Practically this means that you can
 expect the project permissions to behave such as if you don't have approver
 rights (if you have them). The project is again actively managed by jira 
 admins
 now. Please use it if required.
 
 3.) We had a lot of dead projects in Jira. While no project was deleted they
 have been put into storage. Some projects will no longer be visible and
 others will be read-only. The assumption is that we may still want to refer to
 the read-only projects later on whereas the invisible ones are truly dead. 
 This
 affects the following projects:
 
 Read-Only:
 - Qt on Raspberry Pi
 - Qt Quick Components
 - Qt Solutions
 - Qt Webkit
 - Qt Mobility

Qt Solutions isn't strictly speaking dead, there are still some components 
worked on, could this be made read-write again? :)

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

Re: [Development] Builds failing due to android host

[Shaw Andy]

That doesn't make it a valid thing to still do, testing or not. I am not sure 
what others think but do we want to still do upgrades to things on CI this late 
into a release process?

Andy

From: Sarajärvi Tony
Sent: 22. mai 2013 10:54
To: Shaw Andy; development@qt-project.org
Subject: RE: Builds failing due to android host

We have always something coming ;) And we didn't realize that this could cause 
problems. We got a request to update the tool chain and we just did as 
requested. We should have tested this on the dev side, but we don't have the 
luxury of time on our side. From now on, we don't upgrade or update anything 
before verifying on the dev side.

-Tony

From: Shaw Andy
Sent: 22. toukokuuta 2013 11:32
To: Sarajärvi Tony; development@qt-project.org
Subject: RE: Builds failing due to android host

Maybe I missed something, but why are upgrades like this being done in the 
middle of a release cycle? With Qt 5.1 final due in not too long then shouldn't 
these kind of upgrades wait until after the final release in order to avoid 
this sort of thing being a problem for the release?

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Sarajärvi Tony
Sent: 22. mai 2013 10:27
To: development@qt-project.org
Subject: Re: [Development] Builds failing due to android host

Updating the NDK began causing new and new problems, so Android builds are 
marked as 'forcesuccess' for the time being.

Regards,
-Tony

From: Sarajärvi Tony
Sent: 21. toukokuuta 2013 13:07
To: development@qt-project.org
Subject: Builds failing due to android host

Hi

If your build failed due to this message Can not detect the android host. 
Please use -android-ndk-host option to specify one you can just safely restage 
it. We made changes to our Puppet configuration regarding Androids, and yes, 
the CI team caused this fail.

We have a small known problem with Puppet, that currently running builds don't 
prevent Puppet from running.
Due to this, Puppet could potentially remove compile tools from under the 
build. Also, when a build finishes, it reboots the machine. This reboot kills 
the Puppet process and everything it was doing currently. This is most likely 
what happened to Android tools. They were being upgraded to 64 bit tools, and 
on some machines Puppet was killed during this process.

It will automatically retry in 90 minutes (which is Puppet's current timeout). 
Thus at some point it will fix itself.

We have a change for this already inbound so that Puppet doesn't do this, but 
it's been incoming since February, so don't hold your breath ;)

-Tony




Tony Sarajärvi
Senior Software Designer
Digia, Qt

Digia Plc
Elektroniikkatie 10
FI-90590 Oulu

Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com
Mobile: +358 050 482 1416
http://qt.digia.com
| Bloghttp://blog.digia.com/ | Twitterhttps://twitter.com/digiaonline | 
LinkedInhttp://www.linkedin.com/company/5119 | 
YouTubehttp://www.youtube.com/digiaonline | 
Facebookhttp://www.facebook.com/digiaonline |
--
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.
--

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

Re: [Development] Builds failing due to android host

[Shaw Andy]

I grant you that we are always releasing something, but in this instance I was 
referring to the fact that 5.1 beta is already out, with the final due in just 
a few weeks and time is running short because of the timing of that then it 
might be best to hold off on doing some upgrades until a generally more safer 
time. As such now the merge from stable to release as to wait because of the CI 
trouble, which puts more pressure on the actual schedule.

Andy

From: Sarajärvi Tony
Sent: 22. mai 2013 11:45
To: Shaw Andy; development@qt-project.org
Subject: RE: Builds failing due to android host

Do we ever have a situation that something is not late into a release 
process? If it's not 5.1, it's 5.1.1, or 5.2 beta, or 5.2 RC, or 5.2.1...  not 
to mention our 4.x builds :)

-Tony

From: Shaw Andy
Sent: 22. toukokuuta 2013 12:42
To: Sarajärvi Tony; development@qt-project.org
Subject: RE: Builds failing due to android host

That doesn't make it a valid thing to still do, testing or not. I am not sure 
what others think but do we want to still do upgrades to things on CI this late 
into a release process?

Andy

From: Sarajärvi Tony
Sent: 22. mai 2013 10:54
To: Shaw Andy; development@qt-project.org
Subject: RE: Builds failing due to android host

We have always something coming ;) And we didn't realize that this could cause 
problems. We got a request to update the tool chain and we just did as 
requested. We should have tested this on the dev side, but we don't have the 
luxury of time on our side. From now on, we don't upgrade or update anything 
before verifying on the dev side.

-Tony

From: Shaw Andy
Sent: 22. toukokuuta 2013 11:32
To: Sarajärvi Tony; development@qt-project.org
Subject: RE: Builds failing due to android host

Maybe I missed something, but why are upgrades like this being done in the 
middle of a release cycle? With Qt 5.1 final due in not too long then shouldn't 
these kind of upgrades wait until after the final release in order to avoid 
this sort of thing being a problem for the release?

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Sarajärvi Tony
Sent: 22. mai 2013 10:27
To: development@qt-project.org
Subject: Re: [Development] Builds failing due to android host

Updating the NDK began causing new and new problems, so Android builds are 
marked as 'forcesuccess' for the time being.

Regards,
-Tony

From: Sarajärvi Tony
Sent: 21. toukokuuta 2013 13:07
To: development@qt-project.org
Subject: Builds failing due to android host

Hi

If your build failed due to this message Can not detect the android host. 
Please use -android-ndk-host option to specify one you can just safely restage 
it. We made changes to our Puppet configuration regarding Androids, and yes, 
the CI team caused this fail.

We have a small known problem with Puppet, that currently running builds don't 
prevent Puppet from running.
Due to this, Puppet could potentially remove compile tools from under the 
build. Also, when a build finishes, it reboots the machine. This reboot kills 
the Puppet process and everything it was doing currently. This is most likely 
what happened to Android tools. They were being upgraded to 64 bit tools, and 
on some machines Puppet was killed during this process.

It will automatically retry in 90 minutes (which is Puppet's current timeout). 
Thus at some point it will fix itself.

We have a change for this already inbound so that Puppet doesn't do this, but 
it's been incoming since February, so don't hold your breath ;)

-Tony




Tony Sarajärvi
Senior Software Designer
Digia, Qt

Digia Plc
Elektroniikkatie 10
FI-90590 Oulu

Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com
Mobile: +358 050 482 1416
http://qt.digia.com
| Bloghttp://blog.digia.com/ | Twitterhttps://twitter.com/digiaonline | 
LinkedInhttp://www.linkedin.com/company/5119 | 
YouTubehttp://www.youtube.com/digiaonline | 
Facebookhttp://www.facebook.com/digiaonline |
--
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.
--

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

Re: [Development] Question about the missing projects in qt-solutions

[Shaw Andy]

I know the background for this pretty well since I was involved with the 
original transfer of the solution code from TT to Nokia. Basically the code was 
not transferred to Digia at all and it was not initially made publically 
available either when the code was released under the BSD license when Nokia 
had control of it. So the code itself isn't available anymore to put into 
gitorious unfortunately. There is nothing that can be done about this anymore I 
am afraid unless Nokia still has a copy somewhere and chooses to make it 
available then nothing can be done.

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of Qi 
Liang
Sent: 24. april 2013 12:05
To: development@qt-project.org; Knoll Lars
Subject: [Development] Question about the missing projects in qt-solutions

Hi, all,

Some friends in Chinese local qt forum started to talk about this issue.

Current qt-solutions repo:
https://codereview.qt-project.org/#admin,project,qt-solutions/qt-solutions,info
http://qt.gitorious.org/qt-solutions/qt-solutions/

But there are only 9 in total.

Based on the documentation, (someone mirrored the qt solutions for qt 4), it 
should be about 38.
http://docs.huihoo.com/qt/solutions/4/

And digia still has the docs, but missing the main page for the directory, like
http://doc.qt.digia.com/solutions/4/qtmmlwidget/index.html

I guess nokia transfered all qt solutions to digia. Lars, could you confirm 
that?

If so, could we put them back to qt-solutions repo?

Regards,
Liang

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

Re: [Development] Spring-cleaning the Gerrit dashboards, again

[Shaw Andy]

 On Wed, Mar 20, 2013 at 11:31:17AM -0700, Thiago Macieira wrote:
  Can we please agree on cleaning the dashboards up? Or, if we've
  agreed, can we do it?
 
 i think there was consensus to do it.
 however, it depends on
 https://bugreports.qt-project.org/browse/QTQAINFRA-598 to find
 acceptance, and the work to upgrade to a new gerrit version and do
 further improvements has started only now.
 
 however, this does in no way affect the fact that there are still a lot
 of changes pending which actually *are* dead, not deferred.
 so i'd like to urge everyone again to take a honest look at their
 changes, and also at the changes of drive-by contributors who were
 never seen again (which, btw, i should do, too ^^).

Is there a group or an individual willing to abandon changes on our behalf if 
the person who submitted is no longer responding to updates in the meantime? I 
have a couple such changes in my review thing but I don't want to bother people 
with it as I can imagine it's a tedious process to have to go in and abandon 
someone else's changes.

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

Re: [Development] Fixing file dialog performance on Windows

[Shaw Andy]

 The file dialog takes up to 30 seconds to be usable if we're listing
 files on a USB or remote share with 10k files.
 
 
 The bottlenecks are QFileIconProvider::icon(const QFileInfo info) and
 QFileInfo::isSymLink().
 
 
 I solved the icon problem by looking them up in the registry, by
 extension, and caching them.

I assume that for executables you look it up directly or is that stored in the 
registry too?

 For the isSymLink() issue, I discussed with fkleint and rittk and we
 kind of agree that we should simply check if the file extension is
 .lnk, instead of calling GetFileAttributesEx.
 
 
 The Windows native file dialog does not resolve NTFS symlinks, only
 .lnk, so we would be consistent with it.
 
 
 Any objection?

None from me at least, I will be glad to see this issue get resolved after all 
this time :)

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

Re: [Development] Starting preparations for Qt 5.1

[Shaw Andy]

 Making of Qt 5.1 minor release will soon start:
 
 - Plan is to move 'dev' into 'stable' branch on March 19th.
 
 - After March 19th any changes that are required to get in for 5.1
   need to be pushed into 'stable' branch. So if your needed changes don't
 make it today,
   please wait after the merge is done and re-target it.
 
 - I haven't planed to create any branch yet for commits already in 'stable' 
 and
 not in 'release'. So speak up if this is needed.
 
 - If we decide to do 5.0.3, it could be done from the 'release' branch.

Considering that people have been developing on stable on the basis that it is 
in fact 5.0.x, I think we should at least make sure that those changes end up 
somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose 
those changes because we merged, could a read only branch be created from the 
current stable and then merge that into release should a 5.0.3 release happen? 
So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 
release.

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

Re: [Development] [QA] Suggestion -- Bug Reports' Assignment

[Shaw Andy]

I would expect that the workflow is that if a report is set to be In progress 
then this is the indication that someone is actually working on the report, if 
we start using the assigner for this indication then it sounds like it will 
complicate matters even further. Also, if a P1 is created and it is unassigned, 
who is responsible for ensuring that gets picked up and processed?

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Motyka Rafal
Sent: 12. mars 2013 14:28
To: development@qt-project.org
Subject: [Development] [QA] Suggestion -- Bug Reports' Assignment

Hello,

I want to express another suggestions for bug management:
- A newly opened bug report shouldn't be automatically assigned to anyone.
- Logged-in users should be able to assign bug reports to themselves.

Assigned = 'someone works or is going to work on the item'
Unassigned = 'nobody works on the item'

Please feel free to comment on this.
If there are no serious objections, this change will be introduced soon. The 
impact of the change will be evaluated.

Best regards,

/Rafal




Rafal Motyka
QE Engineer
Digia, Qt



Email: rafal.mot...@digia.commailto:forename.surn...@digia.com
Mobile: +47 95005389
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qthttp://www.facebook.com/qt
Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial
--

PRIVACY AND CONFIDENTIALITY NOTICE

This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.

-


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

Re: [Development] Setting the priority of bug reports created the Qt Support team

[Shaw Andy]

 Before the transition to Qt being developed in the open via open governance,
 the Qt Support team back in Trolltech and later Nokia, would prioritize the
 bugs that were created, or at least handled, by them. Typically these would
 be bugs that were brought to our attention by commercial customers using
 Qt. As we know the bug fairly well at this point, and have an understanding
 of the impact it has on applications, then we were in a position to set a
 reasonable priority setting. Since the move to develop in the open via open
 governance, this has not been kept up, as it was back then not desired  that
 the Qt Support team would continue this practice.
 
 What I would like to suggest that we do now is bring back this practice, so
 that the Qt Support team will set a priority on the bugs that it creates or
 handles, so that it makes things easier for the maintainers to actually see
 what issues are potentially a higher priority than the others. And in the case
 of the high priority issues, it will draw attention to them faster rather than
 them being picked up later on in the process. I have also discussed this with
 the developers inside Digia, and they see a need for getting help when
 triaging the bugs, so having the Qt Support team set a priority here would at
 least go some way to helping with that. Of course any priority set by the Qt
 Support team is intended to be a guideline, the maintainer would still be at
 liberty to change it if they disagree.
 
 Is there any comments, thoughts or concerns about this proposal? If I don't
 hear any objections, then we will move ahead with this starting within the
 next week.

I know that there are still side discussions related to this, but there were no 
objections to the support team in Digia at least prioritizing the issues they 
create so we will start doing this as of today.

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

Re: [Development] Preparing Qt 5.0.2 release

[Shaw Andy]

 Merge from stable to release branch is now done.
 Changes that are intended to get in for Qt 5.0.2 need to be pushed into
 release branch.

Now that the merge has done, doesn't this in effect mean that stable is now in 
reality Qt 5.1.0 based as dev will be merged to stable on 15th March? If that 
is the case, then shouldn't this be made clearer somewhere so it is pointed out 
that there is no plan for a Qt 5.0.3 release currently?

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

[Development] Setting the priority of bug reports created the Qt Support team

[Shaw Andy]

Hi,

Before the transition to Qt being developed in the open via open governance, 
the Qt Support team back in Trolltech and later Nokia, would prioritize the 
bugs that were created, or at least handled, by them. Typically these would be 
bugs that were brought to our attention by commercial customers using Qt. As we 
know the bug fairly well at this point, and have an understanding of the impact 
it has on applications, then we were in a position to set a reasonable priority 
setting. Since the move to develop in the open via open governance, this has 
not been kept up, as it was back then not desired  that the Qt Support team 
would continue this practice.

What I would like to suggest that we do now is bring back this practice, so 
that the Qt Support team will set a priority on the bugs that it creates or 
handles, so that it makes things easier for the maintainers to actually see 
what issues are potentially a higher priority than the others. And in the case 
of the high priority issues, it will draw attention to them faster rather than 
them being picked up later on in the process. I have also discussed this with 
the developers inside Digia, and they see a need for getting help when triaging 
the bugs, so having the Qt Support team set a priority here would at least go 
some way to helping with that. Of course any priority set by the Qt Support 
team is intended to be a guideline, the maintainer would still be at liberty to 
change it if they disagree.

Is there any comments, thoughts or concerns about this proposal? If I don't 
hear any objections, then we will move ahead with this starting within the next 
week.

Regards,
Andy
--
Andy Shaw,
Head of Qt Support,
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting the priority of bug reports created the Qt Support team

[Shaw Andy]

[snip]

  What I would like to suggest that we do now is bring back this practice, so
 that the Qt Support team will set a priority on the bugs that it creates or
 handles, so that it makes things easier for the maintainers to actually see
 what issues are potentially a higher priority than the others. And in the case
 of the high priority issues, it will draw attention to them faster rather than
 them being picked up later on in the process. I have also discussed this with
 the developers inside Digia, and they see a need for getting help when
 triaging the bugs, so having the Qt Support team set a priority here would at
 least go some way to helping with that. Of course any priority set by the Qt
 Support team is intended to be a guideline, the maintainer would still be at
 liberty to change it if they disagree.
 
 I assume you mean that any approver would still be at liberty to edit
 the priority if they disagree, basically that there's nothing special
 about the priority just because it was set by Qt Support.

Yes, that is my intention, it should only be seen as a guide based on the 
person who triaged the issue since the person creating it would have verified 
the bug before having created it in this case. But if an approver disagrees 
then that is up to them and therefore it can be changed as appropriate.

 Then there's just the theoretical problem of non-approvers setting bug
 priorities, which is that most people think their bugs are top
 priority. I'm pretty sure the Qt Support team is sensible enough that
 they don't do that, so I think it would be helpful for them to be
 setting (initial) priorities.
 
 It would be nice to expand the concept to something more general, like
 a 'trusted triagers' status, but that can come as a later step.

I agree, long term having such a group would be good because there will always 
be untriaged bugs that come in from other sources currently.

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

Re: [Development] Closing Jira Bugs

[Shaw Andy]

 Op 30-1-2013 19:34, Robin Burchell schreef:
  On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada
  s...@sansano.inf.utfsm.cl wrote:
  How many changes do you need to close a jira task ? one, two, more, who
  knows ?
  The person submitting the change.
 
  The way I've seen this done various other places is to stop trying to
  overload all bugtracker metadata into a single keyword (Task-number)
  and instead split out the precise meanings (Fixes actually fixes it,
  Addresses works towards, but does not close - for instance).
 Yep, I have seen that work rather well, on Assembla for instance. The
 bugtracker gets a nice comment attached with a link to change
 automagically, and if the magic keyword is used together with the bug
 number, the status is modified automatically.
 
 I guess the trick for Qt would be though to make sure that the status is
 only changed (to fixed) if the fix is merged in a branch that will
 actually be released. Other commits with such a tag may get rejected
 through Gerrit, or fail to integrate somehow, and that should not lead
 to issues falsely reported as fixed in Jira of course.

Just to muddy the waters here, but would it be possible to make sure it only 
does this when the patch integrates?  What happens if the bug is reopened 
because it turns out to be still be an issue?

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

Re: [Development] abandoning stale changes on gerrit

[Shaw Andy]

 5.0 is out and the 5.1 feature freeze isn't that far off any more.
 seems like the best time for some serious house cleaning.
 therefore i'd like to urge everyone to give their pending changes which
 haven't seen activity for a long time a honest look.
 please explicitly mark the ones you still want to work on by adding a
 comment. everything which has no indication of (planned) activity in a
 few weeks will be abandoned by administrative action.
 if you are an ex-troll/-nokian, please also check the dashboard of your
 alter ego.
 if you are a maintainer, give identified drive-by contributors a ping.
 i'd also like to encourage everyone to adopt orphaned changes they have
 an interest in.

Wouldn't it be best to put a specific date on when the administrative action 
will take place?  Rather than leaving it arbitrary, so people have time to look 
at this.

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

Re: [Development] QtMultimedia BIC / header cleanliness issue

[Shaw Andy]

 On Tuesday, January 22, 2013 11:40:23 AM Oswald Buddenhagen wrote:
  On Mon, Jan 21, 2013 at 08:14:03AM -0800, Thiago Macieira wrote:
   On segunda-feira, 21 de janeiro de 2013 15.33.59, Knoll Lars wrote:
Finally reading up on some old emails…
   
I'd say we add the virtual destructors. Better to deal with the fallout
now
then in the future.
  
   And rename the libraries to libQt5Multimedia.so.6 ?
 
  imo no. just pretend that it never happened.
  at this point there aren't many packages which are considered stable,
  and even fewer packages which depend on this module. other users won't
  be affected by this change to any noteworthy degree.
  however, make sure this gets into 5.0.1, which means bugging the release
  team at this point, very soon.
 
 That seems most reasonable to me. It's not perfect-by-the-book, but I also
 don't think anyone would notice it given the release just in december.
 (famous
 last words!)

I don't think it should be done silently at all, I'm not exactly for the idea 
of even breaking BC but I can accept an exception this early in the Qt 5.x 
series if there is no other way and it is critical to be done.  But this should 
be clear in the changelog and release notes that it was done, better to be open 
about it than to hope no-one notices.

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

Re: [Development] How and when recent 4.8 docs will be published on http://qt-project.org/doc/qt-4.8

[Shaw Andy]

 On 17/01/13 14:51, Giuseppe D'Angelo wrote:
  http://doc-snapshot.qt-project.org/4.8/qsettings.html is instead
  recreated nightly or so, so you'll see the note added in that commit.
 
 Aha! Ok... How should one know that the docs on
 http://qt-project.org/doc/qt-4.8/ are from 4.8.4? In the older days the
 html templates used to have a footer with the release number. This
 footer war not retained when the new style was applied.
 
 Should I file a bug for this to keep this on the radar?
 
 Btw, Google seems to not like http://qt-project.org/doc/qt-4.8/
 
 The first hit in search for QSettings returns this page:
 
 http://doc.qt.digia.com/qt/qsettings.html

This is likely because this is what was transferred from Nokia and therefore it 
is actually a copy of what Nokia had and that is where it is redirected to now.
 
 The URL http://doc-snapshot.qt-project.org/4.8/qsettings.html is not
 even on the top 100. I think there is something wrong that web pages.

Part of the reason is because nothing links those pages, I don't know if they 
are indexed or not but they are changing all the time which might make it hard 
but personally I would prefer the release docs to be first rather than the 
snapshot ones.

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

Re: [Development] ICU and Windows

[Shaw Andy]

To get things back on track, I think we have a case for either way saying that 
we could ignore it as since as long as it's done the correct way then it should 
be fine.  But there is also a case for doing the right thing as far as what is 
recommended by Microsoft in this case especially since we are in the position 
to actually get it right.  So far I haven't seen a reason why we shouldn't 
ensure we use the appropriate runtime libraries to ensure they do not get mixed 
on Windows.

Therefore I would like to propose that for 5.0.1 we simply modify the pro file 
so that it expects a d after the library name for the debug version and the 
release one stays as it is.  What we could do to make it more robust is connect 
it into configure so it checks if it exists and if it does not fall back onto 
the release version (and give a warning) so it will continue to build as before.

Then in 5.1.0 we put ICU into the 3rdparty directory and then we have more 
control over it and build it ourselves as it seems that this would give us more 
benefits long term from what John Layt said in a previous mail.

How does this sound, is there anything that would mean that this is not a good 
thing to do?

Andy

From: development-bounces+andy.shaw=digia@qt-project.org 
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of 
Pau Garcia i Quiles
Sent: 14. januar 2013 13:55
To: Konstantin Tokarev
Cc: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] ICU and Windows


On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev 
annu...@yandex.rumailto:annu...@yandex.ru wrote:

 On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
 Which is not always that easy... if a library function returns, say, an
 simple std::string *by value*, then who will destroy the allocated memory?
 It's really too easy to break something, somwhere, causing a random crash
 almost impossible to reproduce reliably.

 The ICU C API does not use std::string: it was meant to be used from C code.
 It's quite easy to avoid std::string in that case.

 But as John said a few mails ago, it seems the C is not enough to implement 
 all the required features.
ICU provides C++ API but it does not use std::string. It operates on char * or 
UnicodeString objects.


std::string is just one case, the C++ API does allocate other objects and I'm 
sure that was what Yves (and me) wanted to highlight

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] ICU and Windows

[Shaw Andy]

As I was investigating a different problem I came across a bigger issue 
regarding ICU on Windows.  The problem is that when ICU is linked against on 
Windows it links against the same copy of the library even if it is building 
for release which causes a problem with C runtime libraries on Windows if you 
use MSVC.

For those who are not aware of the issue here whenever you link an application 
or library on Windows with MSVC then it will use a setting for the C runtime 
libraries, Qt defaults to using the release version for release builds (-MD) 
and the debug version for debug builds (-MDd).  And provided the same one is 
used for all the libraries linked against and the application then everything 
is fine.  However if they were to be mixed then it opens up the potential for 
memory corruption to occur as it ends up with two memory heaps in use by the 
application.

Unfortunately this is what is happening now if ICU is linked in, ICU will 
always use the release version so if Qt is built in debug mode then it will end 
up mixing the C runtime libraries.

Since ICU doesn't provide the debug version of the libraries in their binary 
packages then this means that either the user has to build them themselves 
(which means modifying the target as well since the output for debug and 
release defaults to be the same in their project files) or we should consider 
adding them to the 3rdparty section (like we do for libegl and so on) so we can 
control the situation better.

Either way I feel that this needs to be fixed ASAP because we could end up 
seeing bug reports that are in effect caused by this and end up creating more 
noise as a result.   A short term option (and potentially permanent) would be 
to link against a different version of the ICU libraries and point out that if 
they want to use Qt in debug they would need to build ICU themselves and make 
the relevant modifications to the output library names.

Regards,
Andy
--
Andy Shaw
Head of Support,
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ICU and Windows

[Shaw Andy]

 On sexta-feira, 11 de janeiro de 2013 13.32.35, Shaw Andy wrote:
  Unfortunately this is what is happening now if ICU is linked in, ICU will
  always use the release version so if Qt is built in debug mode then it will
  end up mixing the C runtime libraries.
 
 
  Either way I feel that this needs to be fixed ASAP because we could end up
  seeing bug reports that are in effect caused by this and end up creating
  more noise as a result.   A short term option (and potentially permanent)
  would be to link against a different version of the ICU libraries and point
  out that if they want to use Qt in debug they would need to build ICU
  themselves and make the relevant modifications to the output library
 names.
 
 As far as I know, mixing C++ (not C!) runtime libraries is permitted, provided
 that certain care is taken, especially that the runtime that allocated memory
 must be the one to free it.
 
 I think we are taking such care (we don't free any memory allocated by ICU).
 
 So what exactly is the problem we need to solve? Has anyone noticed a crash,
 a
 warning from the C++ runtime, etc.? Is there a latent issue we just haven't
 hit?

Usually with this sort of thing it does not crash right away, you usually get a 
crash later on that looks strange and gets blamed on memory corruption, I have 
seen a crash that only happened in a prebuilt version of Qt which did not 
happen in my own build of Qt 5 which basically was an unhandled exception but I 
couldn't see what caused the exception since the stack trace did not give 
anything useful.  The very same example when running on a source build of Qt 
worked fine.  For reference the example was the browser one in the 
webkitwidgets examples directory crashing in the commercial 2010 binary 
package, it crashed every time it started up and it is because of that why I 
saw the mixing of the runtimes.

Microsoft in the past has also said that you should keep the -MD(d)/-MT(d) 
setting consistent so it is the same across all libraries and applications, and 
I have personally seen the result of this sort of thing happening which is why 
I have always recommended that everything is kept consistent to prevent this 
sort of thing from being a problem.  Granted it might be the case that we are 
generally very careful about it and we never really hit the problem, but 
wouldn't it be better to err on the side of caution and link against a debug 
version of ICU for the debug build of Qt?  If people want to override it then 
we could make that easy to do but personally I think we should at least be 
setup to do what would be the recommended thing to prevent any undue problems.

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

Re: [Development] ICU and Windows

[Shaw Andy]

 [...]
 
  Microsoft in the past has also said that you should keep the -MD(d)/-MT(d)
  setting consistent so it is the same across all libraries and applications,
 
 [...]
 
 Which is cool, if you can manage it. But it's far from what happens in the
 real world.
 
 In the real world you have foreign libraries to load, doesn't matter if these
 are stock libraries provided from Microsoft, from 3rd parties or even
 yourself. It is not uncommon to have all kinds of memory managers mixed in
 one
 application (some windows libraries still use MSVC6's runtime as dll).

[snip]

Granted it is tricky to ensure it happens in the real world, but we are in the 
position to ensure that we do in fact do the right thing in this case then 
shouldn't we actually do so?

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

Re: [Development] RFC: What constitutes a non-destabilising bug-fix?

[Shaw Andy]

 -Original Message-
 From: development-bounces+andy.shaw=digia@qt-project.org
 [mailto:development-bounces+andy.shaw=digia@qt-project.org] On
 Behalf Of Marc Mutz
 Sent: 9. desember 2012 14:23
 To: development@qt-project.org
 Subject: Re: [Development] RFC: What constitutes a non-destabilising bug-
 fix?
 
 On Saturday December 8 2012, Thiago Macieira wrote:
 [...]
  We'll create the releases branch for the RC2 then.
 
 Ok, trying to summarise, I understand it this way:
 
 1. release-critical fixes are submitted and merged to 'stable' now,
'release' later, when it exists.
No-brainer fixes are also welcome.
 2. bug-fixes that don't violate string or BC freezes are submitted,
but NOT merged, against stable.
They will be merged once RC2 is tagged and 'release' is branched off.
Maintainers and other reviewers can redirect a fix to 'dev' instead,
but all fixes that don't require string or BiC changes should initially be
submitted to 'stable'.
[Personally, I'd add that if a fix goes to 'dev' instead of 'stable',
then the commit message should say why.]

[snip]

I don't agree that all bug fixes should go into stable, judgement should 
certainly be made, but we can't just put all bug fixes blindly into stable 
otherwise it will probably end up as being far from stable.  There are times 
when it would be better for a bug fix to go into dev instead of stable because 
it may give a much too obvious behavior change for example.

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

Re: [Development] Summary of renaming changes

[Shaw Andy]

 looks like there's quite some discussion about Thiago's proposal. Let's see if
 we can get at least agreement on most of the changes and then focus on the
 parts that are controversial.
 
 Going through the list below, most of the changes will not affect anybody in a
 big way.
 
 
 On Oct 18, 2012, at 5:30 PM, Thiago Macieira thiago.macie...@intel.com
 wrote:
 
  After all of my patches are integrated, here are the changes that will
 happen:
 
  - bin:
  The following tools have been renamed:
  qmake   - qmake5
 
 This one is visible to the developer.

This is the one that's going to be hard for people to swallow the most 
especially on Windows as there the whole setup is straightforward as you just 
ensure you have the one version of Qt in your path and thus it will point to 
the right one.  I've been doing this for a long time as do a number of people I 
have communicated with in the past even within the Qt 4.x range because one 
version of qmake is strictly speaking not compatible with the other even from 
4.8.1 to 4.8.2 because it has hard-coded paths in it.  So you could still end 
up picking up the wrong version anyway and subsequently end up compiling and 
linking against the wrong version of Qt but generally at that level it is not a 
big problem at least.

Is there no way we could compromise on this?  For instance by adding a symlink 
or something like that so that if someone types qmake it will invoke qmake5, 
that way if the distributors don't want that they can just remove it and then 
everyone is happy, the docs would refer to qmake5 and there is a solution there 
to help people transition over.  Granted I know that people could just add this 
themselves, but I get the feeling that I will be hearing a lot about this 
otherwise.

[snip]

  lconvert- lconvert5
  lrelease- lrelease5
  lupdate - lupdate5

 These tools are in-between, as they IMO get called both by build systems as
 well as by developers directly. But if they are not compatible with Qt 4, we
 can't really have the same name unfortunately.

For these I have the same problem as I do with qmake because they are invoked 
by the user directly too and thus the same suggestion about having a symlink 
stands in this case for me too.

[snip]

Maybe we should open this up for more feedback on a blog post perhaps?   A lot 
of the people would be using it aren't necessarily going to see the change here 
and therefore they may have some good comments on it.

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

Re: [Development] Nominating Andy Shaw for Approver

[Shaw Andy]

 On Oct 15, 2012, at 9:39 AM, Mark Brand mabr...@mabrand.nl
  wrote:
 
  João Abecasis wrote:
  Hi,
 
  I'd like to nominate Andy Shaw for Approver status. Andy's history
  with Qt is longer than my own, having catered to commercial customers
  in Trolltech, Nokia and Digia. Looking over the main repositories, I
  count 150 commits in the 4.x public timeline. 31 so far in Qt 5's
  qtbase -- I did not look into other modules, but I'm sure I'd find
  commits from him scattered all over the place.
 
  It looks like the waiting period has passed.
 
 Indeed. Congratulations Andy!

Thanks everyone!

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

Re: [Development] What's with bugreports.qt-project.org?

[Shaw Andy]

 26.09.2012, в 14:15, Konstantin Tokarev annu...@yandex.ru написал(а):
 
 26.09.2012, 11:09, Иван Комиссаров abba...@gmail.com:
  I would like to ask a question - what's with Qt Jira? Does any people 
  really
 look at it and fix bugs? For the past 2 years, situation get worse and worse -
 3-4 years ago bugs were fixed rather rapid. Nowadays it seems noone even
 looking at Jira. I have 14 unresolved bugs (also i watch 16 more reports), 
 only
 3 of my bugs has assignees; only 5 has priorities. Should i say that newest
 prioritised bug is 1.2 years old?
 
  Feel free to submit patches or buy support.
 
 I do, but sometimes i don't have enough time/knowledge to fix something
 (for example, Cocoa bugs/crashes). Isn't this crash https://bugreports.qt-
 project.org/browse/QTBUG-16274 important? Unfortunately, i can't fix it
 myself... I tried to find someone at irc channel who can help me with cocoa
 issues, but nobody volunteered too.
 
 And i'm not sure that buying support will provide any help except endless
 mailing with support and their answers we will do that soon. Yes, Digia site
 says they will fix my bugs, but i doubt this. From my point of view, it seems
 everybody is busy with Qt5 and fixing bugs is a low priority in Qt...

I am just going to specifically refer to this part in my capacity as Head of 
Support at Digia.  But the support team (myself included) do strive to fix bugs 
or provide workarounds, we have a good track record in this respect.  It is as 
a result of customers reporting bugs to us that we are able to fix some bugs 
sooner than it may happen by going via the bug tracker at 
bugreports.qt-project.org.  This is because the support team's priorities are 
for the customers first so we deal with what they are bringing to our 
attention.  Granted not everything is fixed, but I can assure you that it does 
make a difference to be a customer and report things to us.

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

Re: [Development] What's with bugreports.qt-project.org?

[Shaw Andy]

 -Original Message-
 From: Stephen Chu [mailto:step...@ju-ju.com]
 Sent: 26. september 2012 15:55
 To: Shaw Andy
 Cc: Иван Комиссаров; Konstantin Tokarev; development
 Subject: Re: [Development] What's with bugreports.qt-project.org?
 
 On 9/26/12 6:44 AM, Shaw Andy wrote:
  I am just going to specifically refer to this part in my capacity as
  Head of Support at Digia.  But the support team (myself included) do
  strive to fix bugs or provide workarounds, we have a good track
  record in this respect.  It is as a result of customers reporting
  bugs to us that we are able to fix some bugs sooner than it may
  happen by going via the bug tracker at bugreports.qt-project.org.
  This is because the support team's priorities are for the customers
  first so we deal with what they are bringing to our attention.
  Granted not everything is fixed, but I can assure you that it does
  make a difference to be a customer and report things to us.
 
 
 I am a bit curious on the fixes by Digia for the paying customers. Do
 those fixes go to the LGPL sources? Or do they remain privileges of
 Digia's customers?

Where ever possible the fixes are contributed back to the qt-project, we don't 
put them in the commercial only release.  In some cases the fix is not 
sufficient enough (for one reason or another) to go into the qt-project but it 
is sufficient enough for the customer at least to keep the patch around so that 
they can continue to use it for the releases they have access to.

But generally speaking if we can contribute the patch back then we do so.

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

Re: [Development] Removing Wacom support in Qt5

[Shaw Andy]

 On domingo, 9 de setembro de 2012 13.25.29, Boudewijn Rempt wrote:
  The solution for a bug can never be to wilfully break existing applications!
  What can I as an application developer depend on if that's deemed
  acceptable? Yeah, we had a feature, and yeah, people depend on it, but
 we
  don't give a damn. --- that's the message. And no matter how you dress it
  up with inevitability and force majeure and whatever, that doesn't change
  the message that Qt cannot be depended upon by application developers.
 
 If it will make you sleep better at night, then it's a bug.
 
 A bug means that it's unintentional and we'll correct the situation in a
 future release. So you can depend on Qt: we will make things work and keep
 them working.
 
 We just can't promise when that will be. And except when they break.

I skimmed through the thread as I was away for a few days and missed this 
unfold so I wanted to throw in my thoughts on the subject as it relates to 
something I have done in the past.

To clarify, I did the patch that everyone is referring to, I actually did it in 
my Nokia days when I had access to the tablet and passed it on to someone after 
I joined Digia.  It is a hack because I had to try and get around the mouse 
position problem, I tried then to figure out how to do it properly so it could 
be submitted at the time but was unable to do so.  Since I guess the tablet is 
going to end up back in Digia hands (assuming someone knows where it is in the 
Oslo office) I am willing to look at this again but would prefer someone who 
could help on this side of things as my knowledge of the tablet side is limited 
at best and I couldn't find out where the information needed was actually being 
stored.  If I could get that information I think I could solve the rest.  Again 
assuming the tablet is still around and usable somewhere :)

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

Re: [Development] Removing Wacom support in Qt5

[Shaw Andy]

 On 10 September 2012 12:58, Shaw Andy andy.s...@digia.com wrote:
 
  To clarify, I did the patch that everyone is referring to, I actually did 
  it in my
 Nokia days when I had access to the tablet and passed it on to someone after
 I joined Digia.  It is a hack because I had to try and get around the mouse
 position problem, I tried then to figure out how to do it properly so it could
 be submitted at the time but was unable to do so.  Since I guess the tablet is
 going to end up back in Digia hands (assuming someone knows where it is in
 the Oslo office) I am willing to look at this again but would prefer someone
 who could help on this side of things as my knowledge of the tablet side is
 limited at best and I couldn't find out where the information needed was
 actually being stored.  If I could get that information I think I could solve 
 the
 rest.  Again assuming the tablet is still around and usable somewhere :)
 
 I grabbed the Intuos 3, it's still around.  And I can reproduce the
 bug that with Qt 4.x apps (even the latest Creator released) it's not
 usually possible to interact with most QWidgets using the Wacom mouse.
  (The stylus has gone missing for the moment but I think we will find
 it, and I also have an old Cintiq at home so maybe the stylus is
 compatible).  Whereas with Qt 5, Thiago's explanation makes sense, it
 works OK as a simple mouse because there is no specific support for
 it.
 
 So now I'm trying to understand how it worked in Qt 4 and what the
 right way forward ought to be.  I see that there are two choices:
 wintab32.dll which is provided by Wacom, that is what Qt 4 links
 against; and the RealTimeStylus class provided in the Windows SDK,
 which in theory ought to be more portable to other types of tablet
 PCs.  So I wonder if there is any reason we shouldn't use that for Qt
 5?  Of course it may be a dumb question if too many features are
 missing (we have 2-axis pressure, 2-axis tilt and rotation, so I hope
 most of the data is there in the MS events, when the device reports
 it?)  There is a commercial program called ArtRage which apparently
 uses either or both drivers (you can choose them in the app settings).
  Users report that wintab doesn't provide gesture support, and the
 reports are mixed about whether RTS provides pressure.

Based on my recollection as it is about 2 years ago since I did that patch and 
last looked at this, I believe it is all being sent as Windows messages, but I 
think you do need to use wintab32.dll for it and not the RealTimeStylus as I 
think that is potentially for the Windows Tablet PC which is not quite the same 
I believe.  But it warrants investigation in case it is usable.

 It's interesting that the first example I tried from Wacom confines
 the mouse to the window.  Probably not what we want Qt doing by
 default, so maybe that's the reason we needed a full-screen invisible
 window?  Just guessing.
 
 I'm not normally a Windows guy, so if you know how to really fix this,
 maybe you will get it done faster than I will.  I just figured maybe I
 should have a quick look to see how feasible it is to fix this bug.

I think it is feasible with my patch which I think worked quite well with the 
execption of how I had to get the event position, if we can figure out how to 
solve that it would go a long way to getting it working in 4.8.  But that 
doesn't solve the Qt 5 issue, I have not really looked at that side of things 
yet and not even sure when I would get time, but if we can get the 4.8 side 
working that would ultimately help things.

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

[Development] Having a reserved value for the platform enums was RE: Binary incompatible changes to Qt 4.8

[Shaw Andy]

[snip]

 The warning needs to go away, at least, provided that Qt *is* tested on
 Windows 8. Whether we add the enum or not, that's a bit orthogonal.
 
 Yes, the warning needs to be fixed.
 
 But I don't have any problems with adding the new enum in a patch level
 release. The only thing it can break is that your code won't compile
 against 4.8.1 anymore if you use it. This is really one of these cases
 where we should make a small exception to our rule of not adding any API
 to a patch level release.
 
 Please go ahead and back port the change to 4.8.

Since this could easily be a problem again in the future should we consider 
having a reserved value for the Windows and Mac platform version enums?  That 
way should it be decided that we want to add support for a new version of a 
platform in a maintenance release we could easily utilize the reserved one and 
then bump up the reserved one in the next minor release. 

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

Re: [Development] QLocale work

[Shaw Andy]

On 1/19/12 4:15 AM, Thiago Macieira thiago.macie...@intel.com wrote:

On Wednesday, 18 de January de 2012 21.24.36, Shaw Andy wrote:
 For what it is worth I also agree that it should be changed, having
 recently having to deal with the QDoubleValidator problem when it came
to
 this became a right pain so making it only use the C locale unless
 explicitly told otherwise would be fine by me

Note we're suggesting that UI components and widgets should default to
the 
system locale, not the C locale. But they should have a setLocale for
changing 
if necessary.

Either way, as long as it's explicitly one and not checking the other I
don't mind, it's when it was trying to accomodate the both that it got
confusing to me :)

Andy

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

Re: [Development] QLocale work

[Shaw Andy]

On 1/18/12 2:21 PM, lars.kn...@nokia.com lars.kn...@nokia.com wrote:

We need to avoid the problem of printf / scanf that use different decimal
conventions depending on the user locale. That means the naive
implementation 
will be unable to parse the data it generated under a different locale
settings.

This is a slightly behaviour-incompatible change, but one I feel is
justified: 
reading / parsing of data with comma as a decimal separator was already
broken, so we don't break it further; generating of data without
thousands 
separators and with dots instead of commas for decimals is a minor
inconvenience.

Yes, I'm all for changing this to use the C locale. Let's simply document
it.

For what it is worth I also agree that it should be changed, having
recently having to deal with the QDoubleValidator problem when it came to
this became a right pain so making it only use the C locale unless
explicitly told otherwise would be fine by me :)

Andy

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