[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 
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 mailto:andy.s...@theqtcompany.com>>
Cc: Mark De Wit 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 
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 
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 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 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

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 
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 mailto:mark.de...@iesve.com>>; 
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] [Cobham] QT Bug 43454

[Shaw Andy]

I'm unable to do anything more about the issue at least, I was able to pinpoint 
the cause but I don't know how to fix it correctly so it is certainly out of my 
hands. I'd be happy to help out however I can to getting this fixed though.

Regards,
Andy

From: development-bounces+andy.shaw=theqtcompany@qt-project.org 
[mailto:development-bounces+andy.shaw=theqtcompany@qt-project.org] On 
Behalf Of James Turner
Sent: 5. oktober 2015 18:16
To: Alex Coleman; Giuseppe D'Angelo; David Faure
Cc: cob...@mail.kdab.com
Subject: Re: [Development] [Cobham] QT Bug 43454


On 2 Oct 2015, at 05:48, Coleman, Alex 
mailto:alex.cole...@cobham.com>> wrote:

Is anyone aware of the issue in https://bugreports.qt.io/browse/QTBUG-43454? 
Given your infinite power over the guys from Digia (and the upcoming world 
summit) is there any chance you could get us some information on it please. I 
*think* it is causing us some difficulties at the moment and it doesn't seem 
like there's much we can do our end.

As always any info would be much appreciated.

Peppe posted a comment about a system-level change (configuration), I don't 
know how workable and/or laughable that seems to you.

We could patch Qt to roll-back the QSettings change, but that's really making 
the issue less common, not in any way addressing the problem. Ossi's proposed 
fix (which he deems 'simple', but not simple enough that he will implement it) 
seems clunky to me.

Peppe, any chance you can track down Andy Shaw + Thiago at QtWS and provoke 
some movement on this?

Kind regards,
James

___
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  .. This will install everything relative to 
> >  (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

Re: [Development] Missing documentation

[Shaw Andy]

> The following functions/types need documenting. (This list excludes
> constructors, destructors, and operators). Could those who are

[snip]

How was this list created? Because it seems that although some are actually 
missing it also contains ones that aren't, e.g. QSqlTableModel::record().

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

[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] 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 
mailto: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 
mailto: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.com
 Software Architect - Intel Open Source Technology Center
___
Development mailing list
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.com
Email: 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.0&stepId=8&width=full&height=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]

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.com<mailto:tony.saraja...@digia.com>
Mobile: +358 050 482 1416
http://qt.digia.com
| Blog<http://blog.digia.com/> | Twitter<https://twitter.com/digiaonline> | 
LinkedIn<http://www.linkedin.com/company/5119> | 
YouTube<http://www.youtube.com/digiaonline> | 
Facebook<http://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]

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.com<mailto:tony.saraja...@digia.com>
Mobile: +358 050 482 1416
http://qt.digia.com
| Blog<http://blog.digia.com/> | Twitter<https://twitter.com/digiaonline> | 
LinkedIn<http://www.linkedin.com/company/5119> | 
YouTube<http://www.youtube.com/digiaonline> | 
Facebook<http://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]

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.com
Mobile: +358 050 482 1416
http://qt.digia.com
| Blog | Twitter | 
LinkedIn | 
YouTube | 
Facebook |
--
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] 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] 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] 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.com
Mobile: +47 95005389
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qt
Qt Twitter: 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

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

[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] Qt 5.1 feature set and freeze date

[Shaw Andy]

[snip]

> * Friday 15. March: Feature freeze. Merge from dev to stable.

What will happen to Qt 5.0.x at this point, does it mean we do not plan to do 
any further 5.0.x releases after Qt 5.1.0 is out in April? Or will we have a 
5.0 branch for the changes that simply have to be done in 5.0.x, for instance 
security fixes and so on.

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

> -Original Message-
> From: development-bounces+andy.shaw=digia@qt-project.org
> [mailto:development-bounces+andy.shaw=digia@qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: 14. januar 2013 16:52
> To: development@qt-project.org
> Subject: Re: [Development] ICU and Windows
> 
> On segunda-feira, 14 de janeiro de 2013 13.02.46, Shaw Andy wrote:
> > 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?
> 
> I think it's too late for 5.0.1. We could do it for 5.0.2, but I'll insist
> that we don't change anything for 5.0.x, unless it is proven that we are doing
> things wrong.
> 
> Let's do the import into 3rdparty for 5.1.0 then, if that's the solution we
> agree upon. And Pau is right: if we need to access the C++ API to get enough
> information for some of our APIs, we'll need to build ourselves for MinGW
> anyway.

Ok, if we have it as a goal to fix in Qt 5.1.0 then I can live with that as it 
is less disruption in any case.

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

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] ICU and Windows

[Shaw Andy]

> I'm no expert on the various build and link issues, but in trying to write the
> new ICU backend for QLocale which would make ICU a hard requirement in
> the
> future I've started running into problems which may affect your choice of
> solution.
> 
> For those interested, I have working code for ICU-based number and date
> formatter classes at:
>   http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale-
> icu
> 
> Up to now I've been using the ICU C api due to ICU not providing a binary
> compatibility guarantee on their C++ api between major versions.  This C api
> is a simplified wrapper around the C++ implementation.  This works fine for
> the most commonly used functions like number and date formatting, but the
> C
> api is completely inadequate for using the calendar and time zone functions,
> which are a primary reason for switching to ICU.  For example, you can't even
> find out what the current time zone is via the C api, let alone create and
> query a custom timezone in an efficient way.
> 
> I'm trying to find a way around this with just the C api, but right now the
> easiest solution does appear to be using the C++ api and somehow dealing
> with
> the binary compatibility problem.  Could we make that work?
> 
> On Linux, I have heard that some/many distro's automatically rebuild all
> packages depending on ICU whenever the ICU major version changes due to
> its
> bad reputation.  Could we simply just state that it is a requirement to
> rebuild Qt if the ICU major version on a system is changed?
> 
> On Mac, because OSX doesn't ship with the ICU headers installed, my
> understanding is we currently require people to install ICU via MacPorts or
> HomeBrew and build against that instead of the system ICU libraries.  I don't
> see that as a long-term solution when we start requiring ICU as it's not very
> portable or reliable as to the version used.  The alternative is to manually
> install the headers from opensource.apple.com and use the system library
> (how
> I'm currently building), but I've heard there's been issues in the past with
> published headers not actually matching?  The best option is probably not to
> use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually
> just a thin wrapper around ICU and for localization at least is complete for
> our current purposes.  However, I'm not sure this is an option for the other
> proposed uses of ICU, such as code tables.
> 
> On Windows, well it almost seems we have to require people to either build
> their own ICU and keep it in sync with Qt, or we have to start providing it
> ourselves.
> 
> Perhaps the best solution is going to be including ICU in 3rdparty:
> * On Linux always build with 3rdparty ICU, unless the distro/dev chooses to
> use their system library and accepts the need to rebuild Qt with a major
> version change.
> * On Windows always build with the 3rdparty ICU, unless the dev wants to
> use
> their own and takes responsibility for maintaining compatibility
> * On Mac don't use ICU for QLocale, but use the native api instead, only build
> 3rdparty ICU if other features are enabled that need it. Alternatively trust
> the opensource.apple.com headers and use the system library.
> 
> One plus point to shipping in 3rdparty is that we can use a more modern
> version than the ICU 4.0 we're currently stuck with due to Snow Leopard
> support. The big minus is ICU is big and possibly icky to build.

What you are trying to do would not be affected at all in anyway by either 
solution, all I want to ensure is that the ICU libraries are built with -MD 
when used with the release version of Qt and -MDd when used with the debug 
version of Qt.  It doesn't effect the API of ICU at all in any way.  I only 
suggested that we bundle the source with Qt as it would make it easier to 
ensure that this took place and it seems that you would also benefit from 
bundling as well :)

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

[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] 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] Frameworks on Mac?

[Shaw Andy]

> When I was doing the lib renaming, I thought we had concluded that
> frameworks
> on Mac were not going to be supported anymore.
> 
> Imagine my surprise when I finish my first successful build on Mac and
> discover
> that frameworks are the default...
> 
> I guess we should change, right? I'm not asking to remove the ability to
> create frameworks, but just change the default to not building frameworks.

Since I can't keep up with everything I must have missed the discussion so I 
don't know if this will have already been covered, but isn't the standard 
approach for libraries as far as Mac is concerned to use frameworks?  If we are 
changing from frameworks as the default to shared libraries then will 
macdeployqt continue to work?

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

> -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] What's with bugreports.qt-project.org?

[Shaw Andy]

> 26.09.2012, в 14:15, Konstantin Tokarev  написал(а):
> 
> 26.09.2012, 11:09, "Иван Комиссаров" :
> >> 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] Removing Wacom support in Qt5

[Shaw Andy]

> On 10 September 2012 12:58, Shaw Andy  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

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

[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] QTBUG-23489: Implement the new regular expression classes using PCRE

[Shaw Andy]

On 2/22/12 9:48 PM, "Thiago Macieira"  wrote:

>On quarta-feira, 22 de fevereiro de 2012 17.11.17, lars.kn...@nokia.com
>wrote:
>> Hi,
>> 
>> this is the first mail where I'd like to go through the remaining
>>features
>> for Qt 5.0.
>> 
>> I know that this bug is blocked by not having PCRE in 3rdparty/. But how
>> is the status apart from this? Thiago, simply tell me if you feel
>> comfortable with the code and I'll do final review and approval. If it
>> doesn't break BC and is standalone from other code in qtcore, it can go
>> into master, otherwise I'd prefer it to go into api_changes.
>
>I'm comfortable with the code as-is. Peppe has already submitted a couple
>of 
>changes on top, which fix issues he's already found. Arguably, they could
>be 
>squashed together, but I don't think that matters.
>
>The one remaining issue is the use of mutex-protected data. But I think
>we've 
>got the proper fix in already. We'll only know more once people start
>using it.
>
>> There's another related issue to this bug: What do we do with the old
>> QRegExp? I've gripped through our code and removing it is a larger
>> surgical operation.
>
>Indeed. I really have no clue how hard this would be.
>
>The uses of QRegExp in qtbase and my proposals would be:
>
> - qmake: lots of use, keep it by copying qregexp.cpp into qmake

Since I understand that the code would still be available in a separate
library anyway, then there is no need to copy the file, qmake pulls in the
files it needs directly from the current location so it could just
continue to do the same without having to copy the qregexp.cpp
specifically.

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

Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)

[Shaw Andy]

On 12/16/11 1:18 PM, "Olivier Goffart"  wrote:

>On Friday 16 December 2011 12:48:32 Thiago Macieira wrote:
>> On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote:
>> > One idea is to have an automated process that propose the changes to
>> > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes
>> > of what has been done to update the Qt5 sha1, e.g.
>> > http://codereview.qt-project.org/11239), but at this stage is just an
>> > idea.
>> I still prefer merges, the Qt 4 way. This is something we'll need to
>>figure
>> out by the time we branch 5.0 from 5.1.
>
>The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the
>way 
>it worked in Qt 4 in order to work with gerrit. (the merge need to go
>through 
>the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1
>meaning 
>they need followup commit.)  In Qt 4 it worked because the CI system was
>merging branches, and there was the qt-4.8-from-4.7 branch that as merged
>by 
>CI.  But gerrit do not play well with branches (yet?).
>
>
>But the more imediate problem is the problem to ensure that bugfixes in
>4.8 
>also get submited in Qt 5.
>There, merging is not possible as the repository are different, one must
>cherry pick.
>There are cases were a commit make no sens in Qt5 (symbian code for
>example)
>But in most case, changes should go in Qt5
>The commit should first be submitted to gerrit and get proper review
>there. 
>Then, once they passed the CI system in Qt5, they can be cherry-picked in
>Qt 
>4.8.  
>The rationale was that gerrit is the appropriate tool for the review, so
>the 
>commit can grow there. Then, once ready, be integrated.

While I agree that gerrit is the proper system to get a review now.  I
disagree with the process being that it goes into Qt 5 and then
backported, the fact it passed in Qt 5 is not a guarantee that the fix is
going to be the right one in Qt 4.8 anyway as it may need to be redone and
thus a fresh review etc needs to happen.  So wouldn't it be better to do
it the other way around which to me makes more logical sense.  Do it in Qt
4.8 and then move it to Qt 5.

Andy

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