From tcanabrava at kde.org  Sun Jan  1 10:35:23 2017
From: tcanabrava at kde.org (Tomaz Canabrava)
Date: Sun, 1 Jan 2017 10:35:23 +0100
Subject: [Development] Qt Configuration Generation from Schema
Message-ID: <CACk01_zU0HTminw7GTTe3HQR8KdqNiyRqbZ1+xO28sXTuXVq8A@mail.gmail.com>

Greetings,

A *long* time ago I started trying to create a replacement for QSettings in
json, but if failed for the following reasons:

- Different Views on what it should accomplish - I envisioned the JSON as a
meta-language for generating the C++ code for the QSettings, while others
tougth I was using JSON as the settings definitions on disk

- Json has no notion of int / floating point, everything is floating point,
and so on the json file I had to add an entry for the type of the setting
for every setting, making that option quite verbose.

- Json is not the default configuration file for windows / mac / android /
ios, while usual unix has no default, that's a stopper per see, as some
projects should use the default on each system.

So I tried a different approach this time, creating a qml-like sintax for
the configuration file, a pre-processor that generates C++ code for
QSettings and it's easily used with Widgets / QML code,

It looks a bit like KConfigXT without the extras and written in something
less verbose than XML, and imo my approach  also generates a better c++
class chain than KConfigXT (on KConfigXT all the preferences members are
"global" from within the main Preferences class, while on my they are
agreggated in subclasses).

It also provides a signal / slot for each setting, so a change on any
setting will change the QML component that interacts with it:

preferences.conf file:

#include <QColor>

Preferences {
     Window {
         QColor color  = "#FF0000"
     }
}

QML usage:

Rectangle {
     backgroundColor : preferences.window.color
}

onSomething {
    preferences.window.color = "black"
}

C++ usage:

#include "genreated_preferences.h"

Preferences::self()->load();

connect(Preferences::window(), &Window::colorChanged, [=](const QColor& c)
{ setBackgroundColor(c});

Preferences::self()->window()->setColor( QColor("#010101") );

Preference::self()->sync();

the current code works (as in generates the correct c++ classes), there's
plenty of unittests with examples on how to write the configuration files,
and I tested all the compiled files against a simple application to be sure
there are no obvious bugs.

This was my first try at a C++ project that didn't used Qt so if there's
anything wrong there I'll fix, and please don't hit the developer :)

code currently is in https://github.com/tcanabrava/configuration-parser

If this is something that qt has interest on integrating I'll gladly change
everything on the project necessarely for that.

Regards,
Tomaz Canabrava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170101/5e40a570/attachment.html>

From lars.knoll at qt.io  Mon Jan  2 10:21:25 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Mon, 2 Jan 2017 09:21:25 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2TaCGY9ukcOypV=AhhLo4Gyb_6116U=fCzHVV3ezObSmQ@mail.gmail.com>
	<2346670.jH9ROVz64T@tjmaciei-mobl1> <1763102.EpZHfqpFKn@port-fma>
	<CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
Message-ID: <8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>

I wonder whether we can't keep handling of different calendars completely outside of QDate. Something similar to what we've done with QString/QLocale. So QDate would continue unchanged and only support the standard Gregorian calendar. In addition, we have a QCalendar class, that can be constructed with a different calendar system, and can then return 'localized' date strings, days, months and years for this calendar system.

Something like:

QDate date;
QCalendar c(QCalendar::Hebrew);
QString hebrewDateString = c.toString(date);
int hebrewYear = c.year(date);

Maybe one could even integrate this into QLocale, that already provides support for localized month and day names?

Cheers,
Lars



On 19/12/16 14:18, "Development on behalf of Soroush Rabiei" <development-bounces+lars.knoll=qt.io at qt-project.org on behalf of soroush.rabiei at gmail.com> wrote:

    
    Can you elaborate on the reasons that prevent any change of that kind in
    QDate? Maybe they can be worked around?
    
    
    
    
    
    According to https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts Adding a member to struct
     or class is not possible without breaking ABI. On the other hand https://wiki.qt.io/Qt-Version-Compatibility suggests that Qt minor releases are backwards binary and source compatible. So there is no
     chance of touching QDate in Qt5 series.
    
    
    I'm working on a solution to provide calendar functionality without breaking ABI, while considering possibilities for Qt6 (keep minimum effort for converting current, temporary solution to futures Qt6 one). This may fail of course, There are too many details
     that need to be discussed. How we are supposed to change underlying calendar without adding information to QDate? Can we add arguments to all methods with a default value? Something like:
    
    
    
    
        QDate d;
        qDebug() << d.year();               // prints 2016
        qDebug() << d.year(QCalendar::Jalali); // prints 1395
    
    
    
    And then force relevant widgets/views to show/edit date and time on a specific calendar system:
    
    
        QDateEdit de;
        de.setDate(d);
        de.setCalendarSystem(QCalendar::Hebrew); // Is this possible?
    
    
    
    
    
    


From joerg.bornemann at qt.io  Mon Jan  2 10:53:15 2017
From: joerg.bornemann at qt.io (Joerg Bornemann)
Date: Mon, 2 Jan 2017 10:53:15 +0100
Subject: [Development] Fwd: Compiling QtWebEngine
In-Reply-To: <CADv1+c1Whzw9UxfKb1ZVb+D_055GVjxdgAA=dotY9ep1Jdr3_Q@mail.gmail.com>
References: <CADv1+c2_vOzA8Fr-C=Uah8yLFLAzCQRoXSBYiDjc_k8v=jeATQ@mail.gmail.com>
	<CADv1+c1Whzw9UxfKb1ZVb+D_055GVjxdgAA=dotY9ep1Jdr3_Q@mail.gmail.com>
Message-ID: <548025ad-71c8-1b3e-8297-d4c4ace46c59@qt.io>

On 29/12/2016 08:32, Berkay Elbir wrote:

> D:\3rdParty\jom_1_1_0\jom.exe module-qtwebengine

You need at least jom 1.1.1 for building QtWebEngine in parrallel due to 
the .NOTPARALLEL support that was added in that particular version.
Otherwise the webengine build will try to build debug and release in 
parallel in the same directory which is bound to fail.


Cheers,

Joerg


From jani.heikkinen at qt.io  Mon Jan  2 11:26:29 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Mon, 2 Jan 2017 10:26:29 +0000
Subject: [Development] Qt 5.9 feature freeze
Message-ID: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>

Hi all,

Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to finalize all new features for Qt 5.9

Let's this time make sure we will keep the schedule (see https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight with ff. So if you already now see that some feature won't be ready early enough please postpone it to 5.10 instead.

Make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze)

br,
Jani Heikkinen
Release Manager








From frederic.marchal at wowtechnology.com  Mon Jan  2 12:01:49 2017
From: frederic.marchal at wowtechnology.com (=?ISO-8859-1?Q?Fr=E9d=E9ric?= Marchal)
Date: Mon, 02 Jan 2017 12:01:49 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
Message-ID: <29088300.rDUCxivhrG@port-fma>

On Monday 02 January 2017 09:21:25 Lars Knoll wrote:
> I wonder whether we can't keep handling of different calendars completely
> outside of QDate. Something similar to what we've done with
> QString/QLocale. So QDate would continue unchanged and only support the
> standard Gregorian calendar. In addition, we have a QCalendar class, that
> can be constructed with a different calendar system, and can then return
> 'localized' date strings, days, months and years for this calendar system.
> 
> Something like:
> 
> QDate date;
> QCalendar c(QCalendar::Hebrew);
> QString hebrewDateString = c.toString(date);
> int hebrewYear = c.year(date);
> 
> Maybe one could even integrate this into QLocale, that already provides
> support for localized month and day names?

There is more to it than converting a date to a string:

* Add N days to a date.
* Find the number of days in a month.
* Compare two dates.
* Count the number of days between two dates.

For instance a program wishing a happy new year to its users should do it with 
as little modifications as possible.

Using a plain QDate would have been the easiest way to reach more users 
because it doesn't require to replace lots of QDate with a new, very similar, 
class. As it is not possible to change QDate for now, Soroush is looking for a 
temporary solution that would bridge the gap until Qt6 is out.

BTW, happy new year to those using the Gregorian calendar :-)

Frederic



From lars.knoll at qt.io  Mon Jan  2 12:39:58 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Mon, 2 Jan 2017 11:39:58 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <29088300.rDUCxivhrG@port-fma>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma>
Message-ID: <FF3422F2-66BD-4A5C-93E7-0771AFBB895B@qt.io>

Sure, that there’s more to do than just the examples I listed. Still, design wise it might be a good idea to have this functionality in a class separate from QDate. We’ve done the same design decision for QString (having no locale specific functionality in QString), and this worked out rather nicely. So I would encourage you to have a look whether and how a similar design could be done for calendar system support.

Cheers,
Lars

On 02/01/17 12:01, "Frédéric Marchal" <frederic.marchal at wowtechnology.com> wrote:

    On Monday 02 January 2017 09:21:25 Lars Knoll wrote:
    > I wonder whether we can't keep handling of different calendars completely
    > outside of QDate. Something similar to what we've done with
    > QString/QLocale. So QDate would continue unchanged and only support the
    > standard Gregorian calendar. In addition, we have a QCalendar class, that
    > can be constructed with a different calendar system, and can then return
    > 'localized' date strings, days, months and years for this calendar system.
    > 
    > Something like:
    > 
    > QDate date;
    > QCalendar c(QCalendar::Hebrew);
    > QString hebrewDateString = c.toString(date);
    > int hebrewYear = c.year(date);
    > 
    > Maybe one could even integrate this into QLocale, that already provides
    > support for localized month and day names?
    
    There is more to it than converting a date to a string:
    
    * Add N days to a date.
    * Find the number of days in a month.
    * Compare two dates.
    * Count the number of days between two dates.
    
    For instance a program wishing a happy new year to its users should do it with 
    as little modifications as possible.
    
    Using a plain QDate would have been the easiest way to reach more users 
    because it doesn't require to replace lots of QDate with a new, very similar, 
    class. As it is not possible to change QDate for now, Soroush is looking for a 
    temporary solution that would bridge the gap until Qt6 is out.
    
    BTW, happy new year to those using the Gregorian calendar :-)
    
    Frederic
    
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development
    


From alexander.blasche at qt.io  Mon Jan  2 13:27:17 2017
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Mon, 2 Jan 2017 12:27:17 +0000
Subject: [Development] Nominating Konstantin Tokarev for Approver status
In-Reply-To: <201612051323.45933.kde@carewolf.com>
References: <201612051323.45933.kde@carewolf.com>
Message-ID: <AM4PR0201MB216475C28B50172E274F9058E76F0@AM4PR0201MB2164.eurprd02.prod.outlook.com>

Congratulations to Konstantin. Your rights have been adjusted.

--
Alex



________________________________________
From: Development <development-bounces+alexander.blasche=qt.io at qt-project.org> on behalf of Allan Sandfeld Jensen <kde at carewolf.com>
Sent: Monday, 5 December 2016 1:23:45 PM
To: development at qt-project.org
Subject: [Development] Nominating Konstantin Tokarev for Approver status

Hi all,

I just noticed Konstantin Tokarev who has been doing most of the development,
and practical maintenance of QtWebKit after it moved into "removed" state is
still missing reviewer status. I suggest we correct this.

Besides his work in the official qtwebkit branch, he also doing the QtWebKit-
NG project trying to make a new updated QtWebKit module with a recent upstream
WebKit.

Here are his recent merged commits:
https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merged,n,z

And reviews:
https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z

Best regards
`Allan
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From annulen at yandex.ru  Mon Jan  2 13:28:42 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 02 Jan 2017 15:28:42 +0300
Subject: [Development] Nominating Konstantin Tokarev for Approver status
In-Reply-To: <AM4PR0201MB216475C28B50172E274F9058E76F0@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <201612051323.45933.kde@carewolf.com>
	<AM4PR0201MB216475C28B50172E274F9058E76F0@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <6445361483360122@web20h.yandex.ru>



02.01.2017, 15:27, "Alexander Blasche" <alexander.blasche at qt.io>:
> Congratulations to Konstantin. Your rights have been adjusted.

Thank you!

>
> --
> Alex
>
> ________________________________________
> From: Development <development-bounces+alexander.blasche=qt.io at qt-project.org> on behalf of Allan Sandfeld Jensen <kde at carewolf.com>
> Sent: Monday, 5 December 2016 1:23:45 PM
> To: development at qt-project.org
> Subject: [Development] Nominating Konstantin Tokarev for Approver status
>
> Hi all,
>
> I just noticed Konstantin Tokarev who has been doing most of the development,
> and practical maintenance of QtWebKit after it moved into "removed" state is
> still missing reviewer status. I suggest we correct this.
>
> Besides his work in the official qtwebkit branch, he also doing the QtWebKit-
> NG project trying to make a new updated QtWebKit module with a recent upstream
> WebKit.
>
> Here are his recent merged commits:
> https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merged,n,z
>
> And reviews:
> https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z
>
> Best regards
> `Allan
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From sergio.martins at kdab.com  Mon Jan  2 13:44:44 2017
From: sergio.martins at kdab.com (Sergio Martins)
Date: Mon, 02 Jan 2017 12:44:44 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <29088300.rDUCxivhrG@port-fma>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma>
Message-ID: <7ef432f587a6e24cbcc1ae6a86df86e7@kdab.com>

On 2017-01-02 11:01, Frédéric Marchal wrote:
(...)
> There is more to it than converting a date to a string:
> 
> * Add N days to a date.
> * Find the number of days in a month.
> * Compare two dates.
> * Count the number of days between two dates.

Hi,


Have you seen KCalendarSystem ? 
https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCalendarSystem.html
It can do all the above and doesn't require disruptive changes such as 
modifying QDate.
It's also stable and well tested, as it's been used in Kontact for many 
years.


Regards,
-- 
Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts


From thiago.macieira at intel.com  Mon Jan  2 14:29:18 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 02 Jan 2017 11:29:18 -0200
Subject: [Development] Calendar Systems proposal
In-Reply-To: <29088300.rDUCxivhrG@port-fma>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma>
Message-ID: <5648737.pvz8ZeChiJ@tjmaciei-mobl1>

On segunda-feira, 2 de janeiro de 2017 12:01:49 BRST Frédéric Marchal wrote:
> There is more to it than converting a date to a string:
> 
> * Add N days to a date.
> * Find the number of days in a month.
> * Compare two dates.
> * Count the number of days between two dates.

All but the second one are possible already with QDate, since they don't 
depend on the calendaring system in use.

> For instance a program wishing a happy new year to its users should do it
> with as little modifications as possible.
> 
> Using a plain QDate would have been the easiest way to reach more users
> because it doesn't require to replace lots of QDate with a new, very
> similar, class. As it is not possible to change QDate for now, Soroush is
> looking for a temporary solution that would bridge the gap until Qt6 is
> out.

I don't think I'll ever allow making those deep changes to QDate. Just like 
QString being able to format numbers in one particular locale (the "C" 
locale), we ought to support the C locale's calendaring system in QDate too. 
If nothing else, because people are using that code right now and have been 
for 20 years.

> BTW, happy new year to those using the Gregorian calendar :-)

Happy Gregorian New Year. 15 days until the Julian New Year.

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



From philippeb8 at gmail.com  Mon Jan  2 22:50:40 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Mon, 2 Jan 2017 16:50:40 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>

On 12/29/2016 04:14 AM, Simon Hausmann wrote:
> Hi,

Sorry for the delay...

First I would like to point out this popular Javascript test runs 1.5 
faster using Qt over WebKit:

- ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
http://www.themaninblue.com/experiment/AnimationBenchmark/html/

- ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
http://finitetheory.com/personal/phil/JSBenchmark.tar.gz

- I am still waiting for the QtQuickCompiler request to be fulfilled but 
anybody who has it already is welcome to try it out and please let us 
know the results.

Anyway good job Qt, that's a good start!

> I don't doubt that root_ptr can be used at all. What I'm curious about
> is what your thoughts are on how it could perform, how you would map its
> strengths to the allocation patterns of QML binding evaluations and
> general ECMAScript code.

I am guessing you are referring to QML property bindings here which can 
easily be cyclic.  So these properties will easily be detected by the 
destructor of root_ptr:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/root_ptr.hpp#L426

The idea is to keep one root_ptr per container (or instantiation of an 
object with a list of children) and each property of this object is 
guaranteed to be deleted when the object is destroyed.  So that's the 
main strength and the same goes for entire Javascript pages where its 
memory allocations are guaranteed to vanish on destruction.

Moreover the relation root_ptr (parent pointer) -> node_ptr (children 
pointer) is fine.  There is one drawback in the relation root_ptr -> 
root_ptr where no cyclic detection mechanism is in place.  I believe it 
is possible to add one there but I don't think it is worth the efforts.

Therefore if you have cycles mostly in property bindings then a root_ptr 
per object and node_ptrs for its children will be fine.  The node_ptrs 
can point to other sub objects having a root_ptr each (a child pointer 
can point to a parent).  The rest of the code written in QML is 
structured like a tree as far as I know and no cycles can be present there.

Thus we just need to confirm what I am saying is right; that QML / 
Javascript cycles are present only in property bindings.


Thanks and Happy New Year,
-Phil

> For the record: Any animation code that _doesn't_ use QML Animators does
> indeed run in the same thread as the STW garbage collector and is
> therefore subject to its non-deterministic behavior (from the animation
> PoV). QML Animators on the other hand are run entirely in the render
> thread and are not affected by any pauses in the gui thread, whether it
> is caused by long running scripts, the garbage collector or
> blocking disk I/O. If with today's release you want to have guaranteed
> lag-free animations, then the use of animators over NumberAnimation,
> etc. is required. That is why it _is_ possible to run smooth animations
> with the scene graph and QML on crazy high resolution displays at
> minimal CPU usage.
>
>
> That said, it is our expressed goal to improve the garbage collector to
> interrupt the GUI thread as little as possible, because not everything
> can (and should) be solved with animators. Scrolling in a listview,
> delegate re-use, property re-bindings, etc. are things that still have
> to run in under 16 ms. So without any doubt there is work to do ��
>
>
> Simon
>
> ------------------------------------------------------------------------
> *From:* Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of
> Phil Bouchard <philippeb8 at gmail.com>
> *Sent:* Wednesday, December 28, 2016 2:44:24 PM
> *To:* development at qt-project.org
> *Subject:* Re: [Development] Proposal for "container-oriented
> deterministic memory manager"
>
> On 12/28/2016 08:36 AM, Simon Hausmann wrote:
>> Hi,
>>
>> building on the suggestion: do you have any thoughts about how your
>> allocator could be used instead of a garbage collector in an ecmascript
>> implementation?
>
> I'll have to look into the details of the ECMAScript but root_ptr can
> handle neural networks so I'm not sure why it should fail with ECMAScripts.
>
> I won't be able to reply during the day today but I can study specific
> cases this week.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>




From tuukka.turunen at qt.io  Tue Jan  3 09:02:21 2017
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Tue, 3 Jan 2017 08:02:21 +0000
Subject: [Development] Proposal to adjust release candidate process
In-Reply-To: <VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<9505450.rLpQF0vOJZ@tjmaciei-mobl1>
	<VI1PR02MB1006A7873B41B446B41DAE208C950@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<2265621.Hc078j5Qty@tjmaciei-mobl1>
	<VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>


Hi,

Perhaps it is best to talk with marketing about the name of the "release done immediately after branching to the .0 release branch". Reading the discussion, it seems that other than the name we are well aligned.

Our current process has "Release candidate" 2 weeks prior to the Final release (see: https://wiki.qt.io/Qt5Releasing).

If we now have the beta2/preview/othername release 4 weeks before the final, our schedule is the following:

Phase                                              Timing
Feature freeze                            T-17 weeks
Alpha release                              T-13 weeks
Beta release                                 T-8 weeks
Soft string freeze                       T-6 weeks
Hard string freeze                     T-5 weeks
Beta2/Preview/XYZ                  T-4 weeks
Final release                                T

In addition to the main phases, there will be snapshots regularly for testing. During the final weeks before the release these snapshots are then considered as possible final release unless testing reveals a need to change something. This part is unchanged.

The main benefit for the change is providing a very close to final package for users to test earlier. During the 4 weeks after Beta there is always a lot of improvements, but after branching to the release branch we should focus only for the high-priority error corrections and polishing the documentation (if not already done earlier).

PS. I would like to shorten the overall duration of the release creation to 12 weeks from FF to final. I think that being more strict about the FF and by having all the needed configurations done early enough, we should be able to cut the time between FF and Alpha as well as between Alpha and Beta. But that is something we can discuss later.

Yours,

                             Tuukka


From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: perjantaina 23. joulukuuta 2016 19.02
To: Thiago Macieira <thiago.macieira at intel.com>; development at qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process




Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>
Sent: Friday, December 23, 2016 4:42:12 PM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate process

Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of patches going in is IMO related
> to the probably of introducing regressions. The process around the release
> branch, as opposed to the "minor branch", as proven to be a useful
> mechanism for reducing the churn and making people ask themselves: Do I
> really want this change in this release or can it wait?
>
> So from what I think is one metric of quality (not the only one of course),
> the naming of release candidate is more meaningful.

How about this, then? We release beta2 from the 5.n branch right before the
5.n.0 branch is created (or finally branches off). It accomplishes the same
thing that Tuukka wanted: a release containing the code that is in the 5.n.0
branch at the moment it is created, not a few weeks after with some round of
work.

And I really mean "the code that is in the 5.n.0 branch". Since the two
branches at the same at that point, it's only a semantic difference which one
we created the beta2 release from.

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

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170103/f001202c/attachment.html>

From alan.ezust at gmail.com  Tue Jan  3 17:48:43 2017
From: alan.ezust at gmail.com (Alan Ezust)
Date: Tue, 3 Jan 2017 08:48:43 -0800
Subject: [Development] [Announce] Qt VS Tools (Beta) released
In-Reply-To: <mailman.1127.1470920810.23668.announce@qt-project.org>
References: <mailman.1127.1470920810.23668.announce@qt-project.org>
Message-ID: <CALy5K9qUKkwh+FArW0rAehUKcGTs=QpB+DnCKXaXpoybqq27Lg@mail.gmail.com>

I just installed VS2013 and now i want to install the vs2013 addin, but the
very first link from that article
http://doc.qt.io/vs-addin/index.html
is 404 not found.

Can someone please fix that link so it works again?

thanks!
--Alan


On Thu, Aug 11, 2016 at 6:06 AM, List for announcements regarding Qt
releases and development <announce at qt-project.org> wrote:

> We are pleased to announce the release of the Qt VS Tools (Beta)!
>
> http://blog.qt.io/blog/2016/08/11/from-visual-studio-add-
> in-to-qt-vs-tools-beta/
>
> Br,
> --
> Alessandro Portale
> Senior Manager, R&D
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> alessandro.portale at qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> _______________________________________________
> Announce mailing list
> Announce at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/announce
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170103/21c9c088/attachment.html>

From Maurice.Kalinowski at qt.io  Wed Jan  4 08:44:31 2017
From: Maurice.Kalinowski at qt.io (Maurice Kalinowski)
Date: Wed, 4 Jan 2017 07:44:31 +0000
Subject: [Development] [Announce] Qt VS Tools (Beta) released
In-Reply-To: <CALy5K9qUKkwh+FArW0rAehUKcGTs=QpB+DnCKXaXpoybqq27Lg@mail.gmail.com>
References: <mailman.1127.1470920810.23668.announce@qt-project.org>
	<CALy5K9qUKkwh+FArW0rAehUKcGTs=QpB+DnCKXaXpoybqq27Lg@mail.gmail.com>
Message-ID: <VI1PR0202MB28450C16506BD47DFF1747F795610@VI1PR0202MB2845.eurprd02.prod.outlook.com>

Done.

Maurice


From: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Alan Ezust
Sent: Tuesday, January 3, 2017 5:49 PM
To: development at qt-project.org; Alessandro Portale <Alessandro.Portale at qt.io>
Subject: Re: [Development] [Announce] Qt VS Tools (Beta) released

I just installed VS2013 and now i want to install the vs2013 addin, but the very first link from that article
http://doc.qt.io/vs-addin/index.html
is 404 not found.
Can someone please fix that link so it works again?
thanks!
--Alan

On Thu, Aug 11, 2016 at 6:06 AM, List for announcements regarding Qt releases and development <announce at qt-project.org<mailto:announce at qt-project.org>> wrote:
We are pleased to announce the release of the Qt VS Tools (Beta)!

http://blog.qt.io/blog/2016/08/11/from-visual-studio-add-in-to-qt-vs-tools-beta/

Br,
--
Alessandro Portale
Senior Manager, R&D

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
alessandro.portale at qt.io<mailto:alessandro.portale at qt.io>
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
_______________________________________________
Announce mailing list
Announce at qt-project.org<mailto:Announce at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/announce
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170104/3c9ac210/attachment.html>

From tero.kojo at qt.io  Wed Jan  4 09:31:16 2017
From: tero.kojo at qt.io (Tero Kojo)
Date: Wed, 4 Jan 2017 08:31:16 +0000
Subject: [Development] Proposal to adjust release candidate process
In-Reply-To: <AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<9505450.rLpQF0vOJZ@tjmaciei-mobl1>
	<VI1PR02MB1006A7873B41B446B41DAE208C950@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<2265621.Hc078j5Qty@tjmaciei-mobl1>
	<VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <AM2PR02MB0707DA2B0FFC78C4F8CB5ED0F4610@AM2PR02MB0707.eurprd02.prod.outlook.com>

Hi,

As someone living quite close to marketing.

A couple of questions.

1.       As the T-4 release is essentially from the start of the 5.n.0 branch, are only fixes allowed there? (no new content, unless for some really weird reason)

2.       Is it possible that the T-4 release could be so good that it would be released? (i.e. no major bugs)

If I understand correctly the answers are 1. yes, and 2. in reality no.

And as we live with the "alpha, beta, RC" - terminology then call it beta 2 (or second beta, in writing the sentence "We are releasing the second beta of Qt 5.n" looks better).
Inventing new names makes little sense, and it isn't an RC if we can't ship it.
Let's not invent new words, or borrow words from other release cycle styles, that just makes for confusion.

Tero

From: Development [mailto:development-bounces+tero.kojo=qt.io at qt-project.org] On Behalf Of Tuukka Turunen
Sent: tiistai 3. tammikuuta 2017 10.02
To: Simon Hausmann <Simon.Hausmann at qt.io>; Thiago Macieira <thiago.macieira at intel.com>; development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process


Hi,

Perhaps it is best to talk with marketing about the name of the "release done immediately after branching to the .0 release branch". Reading the discussion, it seems that other than the name we are well aligned.

Our current process has "Release candidate" 2 weeks prior to the Final release (see: https://wiki.qt.io/Qt5Releasing).

If we now have the beta2/preview/othername release 4 weeks before the final, our schedule is the following:

Phase                                              Timing
Feature freeze                            T-17 weeks
Alpha release                              T-13 weeks
Beta release                                 T-8 weeks
Soft string freeze                       T-6 weeks
Hard string freeze                     T-5 weeks
Beta2/Preview/XYZ                  T-4 weeks
Final release                                T

In addition to the main phases, there will be snapshots regularly for testing. During the final weeks before the release these snapshots are then considered as possible final release unless testing reveals a need to change something. This part is unchanged.

The main benefit for the change is providing a very close to final package for users to test earlier. During the 4 weeks after Beta there is always a lot of improvements, but after branching to the release branch we should focus only for the high-priority error corrections and polishing the documentation (if not already done earlier).

PS. I would like to shorten the overall duration of the release creation to 12 weeks from FF to final. I think that being more strict about the FF and by having all the needed configurations done early enough, we should be able to cut the time between FF and Alpha as well as between Alpha and Beta. But that is something we can discuss later.

Yours,

                             Tuukka


From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: perjantaina 23. joulukuuta 2016 19.02
To: Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate process




Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>
Sent: Friday, December 23, 2016 4:42:12 PM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate process

Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of patches going in is IMO related
> to the probably of introducing regressions. The process around the release
> branch, as opposed to the "minor branch", as proven to be a useful
> mechanism for reducing the churn and making people ask themselves: Do I
> really want this change in this release or can it wait?
>
> So from what I think is one metric of quality (not the only one of course),
> the naming of release candidate is more meaningful.

How about this, then? We release beta2 from the 5.n branch right before the
5.n.0 branch is created (or finally branches off). It accomplishes the same
thing that Tuukka wanted: a release containing the code that is in the 5.n.0
branch at the moment it is created, not a few weeks after with some round of
work.

And I really mean "the code that is in the 5.n.0 branch". Since the two
branches at the same at that point, it's only a semantic difference which one
we created the beta2 release from.

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

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170104/0c08962e/attachment.html>

From Friedemann.Kleint at qt.io  Wed Jan  4 09:37:25 2017
From: Friedemann.Kleint at qt.io (Friedemann Kleint)
Date: Wed, 4 Jan 2017 09:37:25 +0100
Subject: [Development] QUIP for choosing a branch
Message-ID: <0c8004b8-d565-8f8e-58a3-1bcb4ab9a5c5@qt.io>

Hi,

as a result of the QtCon 2016 discussion on Managing Qt's Branches ( 
http://wiki.qt.io/QtCS2016_Managing_Qt_Branches ), we would like to 
provide some guidelines on which branch to choose for a change. Please 
find attached a QUIP which is available for review at 
https://codereview.qt-project.org/#/c/178906/ .

Regards, Friedemann

-- 
Friedemann Kleint
The Qt Company GmbH

-------------- next part --------------
QUIP: 5
Title: Choosing a Branch
Version: $Revision$
Last-Modified: $Date$
Author: Jędrzej Nowacki, Friedemann Kleint
Status: Draft
Type: Process
Created: 2016-12-05

========================================
 Choosing a Branch
========================================

Motivation
----------

This QUIP aims to provide some guidelines on what branch to choose for a
change. It originated from the
`QtCS2016 Managing Qt Branches <http://wiki.qt.io/QtCS2016_Managing_Qt_Branches>`_
session.

Goal of the LTS branches (5.6 at the time of writing)
-----------------------------------------------------

- Support slower moving OSes
- Fix bugs in applications that were already shipped bundling the LTS and
  continue to build against the LTS
- Have a low regression risk
- Add new minor platforms (if and only if changes are minimal like
  win8 => win8.1)
- Documentation clarifications

We divide the LTS into 3 periods (assuming cherry-pick contribution model):

- 5.6.0 *relaxed*: We assume that people still develop applications with the
  LTS or they are porting to it, so they are more willing to take a risk of
  regressions or general brokenness in Qt.
- 5.6.x *strict* At that point applications should be working with the LTS or
  be shipped. It is not allowed to break existing bug workarounds, even if the
  bug is fixed. For people using the LTS release, there is no real gain in
  rewriting working code.
- 5.6.y *very strict* 2 years after the .0 release, we believe that there are
  no more P1, P0.

where x = 1 year from .0 release and y = 2 years from .0 release

Goal of the stable branches (5.x)
---------------------------------

- Bug fixes
- Performance fixes
- Documentation fixes
- As a special case, pre-release stabilization of the dev branch

Goal of the dev branch:
-----------------------

- New feature development
- Major refactoring
- Risky changes, requiring longer testing period (moc, qmake...)
- Completely new platforms (WinRT)

Approach
--------

The table below lists typical code changes and points to which branch the
change should be pushed. In all cases, we need to estimate impact of the
change. For example, a fix for a performance problem may end-up in a different
branch depending on: how many users are affected, how big is the improvement
and what is the risk of regressions. The table shows the most stable branch,
for every case. If a change is risky or it has lower impact, then it should
be placed in a less stable branch.

+----------------------------+---------+--------+-------------+--------+-----+---------------------+
|                            |            LTS                 |        |     |                     |
|                            +---------+--------+-------------+ Stable | Dev | Notes               |
| Issue                      | Relaxed | Strict | Very Strict |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Security                   |     x   |    x   |    x        |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| 3rd party update           |     x   |    x   |    x        |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Test improvement           |     x   |    x   |    x        |   x    |     |                     |
| (reduce flakiness)         |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Adapt to minor OS/         |     x   |    x   |    x        |   x    |     |                     |
| Compiler updates           |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Memory leak                |     x   |    x   |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Fix to feature added       |     x   |    x   |             |   x    |     |                     |
| in LTS                     |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Undefined behavior         |     x   |    x   |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Something that makes       |     x   |    x   |             |   x    |     |                     |
| existing apps unstable     |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Performance: significant   |     x   |    x   |    x        |   x    |     |                     |
| fix improving O()          |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Performance: Other fix     |     x   |        |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Documentation: small fixes |     x   |    x   |    x        |   x    |     |                     |
| (links, typos, warnings)   |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Documentation: refactoring |     x   |        |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Crash                |     x   |    x   |    x        |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Hard to reproduce    |     x   |    x   |             |   x    |     |                     |
| crash                      |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Regression           |     x   |    x   |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Hard-to reproduce    |         |        |             |   x    |     |                     |
| regression noticed some    |         |        |             |        |     |                     |
| time after release         |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Malfunctions         |         |        |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Bugs: Graphical glitches   |         |        |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| New modules                |         |        |             |        |  x  |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| New features               |         |        |             |        |  x  |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Refactoring: tests         |         |        |             |   x    |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Refactoring: code          |         |        |             |        |  x  |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Enabling new compiler      |         |        |             |        |  x  |                     |
| features                   |         |        |             |        |     |                     |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+
| Using new C++              |         |        |             |        |  x  | That includes       |
| features                   |         |        |             |        |     | mass updates        |
+----------------------------+---------+--------+-------------+--------+-----+---------------------+


References
----------

- `Branch Guidelines <http://wiki.qt.io/Branch_Guidelines>`_
- `JIRA-Priorities <https://wiki.qt.io/JIRA-Priorities>`_

From edward.welbourne at qt.io  Wed Jan  4 15:43:57 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 4 Jan 2017 14:43:57 +0000
Subject: [Development] [Releasing] Qt 5.8.0 API review
In-Reply-To: <HE1PR0202MB26839A43AA25181151BFB60187A70@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <AM5PR0202MB25157A3915EBB851898C15299DE60@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683A067CBA4D81EB515159087FB0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515C3629A0C4ED2D8AC81269DFA0@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<HE1PR0202MB26833160507997A361E840E487FE0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<AM5PR0202MB25156AD4A7132AF17E88CE0A9DFE0@AM5PR0202MB2515.eurprd02.prod.outlook.com>,
	<nr9geo$3v1$1@blaine.gmane.org>,
	<AM5PR0202MB2515C27395BDCBABC0E9EE5F9DF10@AM5PR0202MB2515.eurprd02.prod.outlook.com>,
	<AM5PR0202MB2515C1190464BD510249FC4F9DF10@AM5PR0202MB2515.eurprd02.prod.outlook.com>,
	<AM5PR0202MB2676B93DCA0A04BD343B0F9587F10@AM5PR0202MB2676.eurprd02.prod.outlook.com>,
	<HE1PR0202MB26839A43AA25181151BFB60187A70@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0202MB2683556CB63CA02D4D131AC187610@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Back on the 7th of November 2016 I announced:
> With the 5.8.0 release now close at hand, I've updated the API reviews:

I've now updated these for the actual 5.8.0 branch (fetched this morning):

https://codereview.qt-project.org/170634 - qtbase
https://codereview.qt-project.org/170635 - qtdeclarative
https://codereview.qt-project.org/170636 - qtactiveqt
https://codereview.qt-project.org/170637 - qtmultimedia
https://codereview.qt-project.org/170640 - qtconnectivity
https://codereview.qt-project.org/170641 - qtwayland
https://codereview.qt-project.org/170642 - qt3d
https://codereview.qt-project.org/170643 - qtserialbus
https://codereview.qt-project.org/170644 - qtserialport
https://codereview.qt-project.org/170645 - qtandroidextras
https://codereview.qt-project.org/170646 - qtwebsockets
https://codereview.qt-project.org/170647 - qtwebengine
https://codereview.qt-project.org/170648 - qtcanvas3d
https://codereview.qt-project.org/170649 - qtcharts
https://codereview.qt-project.org/170650 - qtdatavis3d
https://codereview.qt-project.org/170652 - qtscxml
https://codereview.qt-project.org/176059 - qtquickcontrols2

> Note that, although Gerrit thinks of these as proposals to change 5.8,
> they are actually commits based on tag v5.7.0 showing what's changed in
5.8.0's
> API, with lots of boring bits filtered out.

As before, it would be nice if some of these did in fact get reviewed -
and J-P Nurmi gets the prize for having done that before I even sent
this - indeed, within a minute of the new push :-)

Gerrit should make it easy to compare the new patch set to the previous,
which should make review easy - if your module hasn't changed too
drastically since the previous review in early November ...

	Eddy.


From edward.welbourne at qt.io  Wed Jan  4 16:03:57 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 4 Jan 2017 15:03:57 +0000
Subject: [Development] Proposal to adjust release candidate process
In-Reply-To: <AM2PR02MB0707DA2B0FFC78C4F8CB5ED0F4610@AM2PR02MB0707.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<9505450.rLpQF0vOJZ@tjmaciei-mobl1>
	<VI1PR02MB1006A7873B41B446B41DAE208C950@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<2265621.Hc078j5Qty@tjmaciei-mobl1>
	<VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>,
	<AM2PR02MB0707DA2B0FFC78C4F8CB5ED0F4610@AM2PR02MB0707.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0202MB268310AC9ABA775756C98C3E87610@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Since general churn while "stabilising" is a central part of the
discussion, let's take a look at the change, since my early November API
review push, in just the not-obviously-boring[*] changes to API-related
headers. ([*] If you can see any changes in the reviews that a dumb
script could be taught to recognise as boring, please do bring them to
my attention.)  These are the results of git diff | wc between
November's patch sets and today's:

                   lines   words   characters
* qtbase            1696    7245   70274
* qtscxml            486    1455   19930
* qtwayland          451    1391   16252
* qtmultimedia       415    1103   14480
* qt3d                91     320    3263
* qtwebengine         41     181    1433
* qtconnectivity      33     158    1227
* qtdeclarative       32     108    1389
* qtquickcontrols2    20     125     786
* qtandroidextras     18     117     728
* qtactiveqt          18     106     663
* qtcanvas3d          18      98     621
* qtcharts            18      89     594
* qtdatavis3d         13      32     476
* qtwebsockets        13      32     225
* qtserialport        12      31     243

(with apologies to those whose mailers are too clever about spacing).
Some of that is git diff's own over-head, of course; so most modules are
quite sensible - but those first four, especially qtbase, should surely
give folk pause for thought.  It has been two months, but then again
this is a limited API-related diff to begin with.

Anyway - interpret how you will, here's some data,

	Eddy.


From frederik.gladhorn at qt.io  Wed Jan  4 16:25:52 2017
From: frederik.gladhorn at qt.io (Frederik Gladhorn)
Date: Wed, 04 Jan 2017 16:25:52 +0100
Subject: [Development] Proposal to adjust release candidate process
In-Reply-To: <AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <1618333.CLuHQRrLkn@frederik-thinkcentre-m93p>

On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote:
> Hi,
> 
> Perhaps it is best to talk with marketing about the name of the "release
> done immediately after branching to the .0 release branch". Reading the
> discussion, it seems that other than the name we are well aligned.

I'd try to follow standards, this is supposed to be primarily understood by 
developers. semver is the most sensible thing I know of when it comes to 
versions. #11 is pretty sensible:
http://semver.org/#spec-item-11

I'll just copy their example and would like us to follow it:
Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-
beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.


I agree with Robin in that we should make it easier to test, so for me the 
priority would be to get nightly builds out there and make it easy to install 
them through the online installer. Currently there is no sensible way for the 
community to help out since all the code and procedures are internal. We're 
cleaning many things up (one problem that The Qt Company has is that we have 
not stream-lined releasing and packaging the different products enough, Qt for 
Application Development and Device Creation for example are not packaged 
completely the same way...).

Cheers,
Frederik


> 
> Our current process has "Release candidate" 2 weeks prior to the Final
> release (see: https://wiki.qt.io/Qt5Releasing).
> 
> If we now have the beta2/preview/othername release 4 weeks before the final,
> our schedule is the following:
> 
> Phase                                              Timing
> Feature freeze                            T-17 weeks
> Alpha release                              T-13 weeks
> Beta release                                 T-8 weeks
> Soft string freeze                       T-6 weeks
> Hard string freeze                     T-5 weeks
> Beta2/Preview/XYZ                  T-4 weeks
> Final release                                T
> 
> In addition to the main phases, there will be snapshots regularly for
> testing. During the final weeks before the release these snapshots are then
> considered as possible final release unless testing reveals a need to
> change something. This part is unchanged.
> 
> The main benefit for the change is providing a very close to final package
> for users to test earlier. During the 4 weeks after Beta there is always a
> lot of improvements, but after branching to the release branch we should
> focus only for the high-priority error corrections and polishing the
> documentation (if not already done earlier).
> 
> PS. I would like to shorten the overall duration of the release creation to
> 12 weeks from FF to final. I think that being more strict about the FF and
> by having all the needed configurations done early enough, we should be
> able to cut the time between FF and Alpha as well as between Alpha and
> Beta. But that is something we can discuss later.
> 
> Yours,
> 
>                              Tuukka
> 
> 
> From: Development
> [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf
> Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02
> To: Thiago Macieira <thiago.macieira at intel.com>; development at qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> 
> 
> 
> Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case
> the branch makes no difference and beta is a better name.
> 
> 
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Thiago Macieira
> <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> Sent: Friday,
> December 23, 2016 4:42:12 PM
> To: development at qt-project.org<mailto:development at qt-project.org>
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
> 
> escreveu:
> > I find that the branch is relevant in this context, as it relates to the
> > amount of patches going in. The amount of patches going in is IMO related
> > to the probably of introducing regressions. The process around the release
> > branch, as opposed to the "minor branch", as proven to be a useful
> > mechanism for reducing the churn and making people ask themselves: Do I
> > really want this change in this release or can it wait?
> > 
> > So from what I think is one metric of quality (not the only one of
> > course),
> > the naming of release candidate is more meaningful.
> 
> How about this, then? We release beta2 from the 5.n branch right before the
> 5.n.0 branch is created (or finally branches off). It accomplishes the same
> thing that Tuukka wanted: a release containing the code that is in the 5.n.0
> branch at the moment it is created, not a few weeks after with some round
> of work.
> 
> And I really mean "the code that is in the 5.n.0 branch". Since the two
> branches at the same at that point, it's only a semantic difference which
> one we created the beta2 release from.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development




From philippeb8 at gmail.com  Thu Jan  5 01:46:10 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Wed, 4 Jan 2017 19:46:10 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
Message-ID: <o4k50e$11q$1@blaine.gmane.org>

On 01/02/2017 04:50 PM, Phil Bouchard wrote:
> On 12/29/2016 04:14 AM, Simon Hausmann wrote:
>> Hi,
>
> Sorry for the delay...
>
> First I would like to point out this popular Javascript test runs 1.5
> faster using Qt over WebKit:
>
> - ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
> http://www.themaninblue.com/experiment/AnimationBenchmark/html/
>
> - ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
> http://finitetheory.com/personal/phil/JSBenchmark.tar.gz
>
> - I am still waiting for the QtQuickCompiler request to be fulfilled but
> anybody who has it already is welcome to try it out and please let us
> know the results.

For the record I was able to benchmark the QtQuickCompiler on a x86 @ 
3.4 GHz and I get: ~250 FPS and without the QtQuickCompiler I get 
something similar; which means this is pretty much the maximum speed 
that test can get.



From annulen at yandex.ru  Thu Jan  5 12:02:56 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 05 Jan 2017 14:02:56 +0300
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <o4k50e$11q$1@blaine.gmane.org>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org>
Message-ID: <6788751483614176@web18j.yandex.ru>



05.01.2017, 03:46, "Phil Bouchard" <philippeb8 at gmail.com>:
> On 01/02/2017 04:50 PM, Phil Bouchard wrote:
>>  On 12/29/2016 04:14 AM, Simon Hausmann wrote:
>>>  Hi,
>>
>>  Sorry for the delay...
>>
>>  First I would like to point out this popular Javascript test runs 1.5
>>  faster using Qt over WebKit:
>>
>>  - ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
>>  http://www.themaninblue.com/experiment/AnimationBenchmark/html/
>>
>>  - ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
>>  http://finitetheory.com/personal/phil/JSBenchmark.tar.gz
>>
>>  - I am still waiting for the QtQuickCompiler request to be fulfilled but
>>  anybody who has it already is welcome to try it out and please let us
>>  know the results.
>
> For the record I was able to benchmark the QtQuickCompiler on a x86 @
> 3.4 GHz and I get: ~250 FPS and without the QtQuickCompiler I get
> something similar; which means this is pretty much the maximum speed
> that test can get.

AFAIU QtQuickCompiler has nothing to do with memory management, its main purpose is reduction of start up time and obfuscation of sources.

Note that measuring FPS above screen refresh rate (usually 60) does not make a lot of sense, as underlying graphics systems may not preserve it (and if vsync is enabled, screen refresh rate is a hard upper bound).

>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From philippeb8 at gmail.com  Thu Jan  5 13:26:52 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Thu, 5 Jan 2017 07:26:52 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <6788751483614176@web18j.yandex.ru>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
Message-ID: <8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>

On 01/05/2017 06:02 AM, Konstantin Tokarev wrote:
>
>
> 05.01.2017, 03:46, "Phil Bouchard" <philippeb8 at gmail.com>:
>> On 01/02/2017 04:50 PM, Phil Bouchard wrote:
>>>  On 12/29/2016 04:14 AM, Simon Hausmann wrote:
>>>>  Hi,
>>>
>>>  Sorry for the delay...
>>>
>>>  First I would like to point out this popular Javascript test runs 1.5
>>>  faster using Qt over WebKit:
>>>
>>>  - ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
>>>  http://www.themaninblue.com/experiment/AnimationBenchmark/html/
>>>
>>>  - ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
>>>  http://finitetheory.com/personal/phil/JSBenchmark.tar.gz
>>>
>>>  - I am still waiting for the QtQuickCompiler request to be fulfilled but
>>>  anybody who has it already is welcome to try it out and please let us
>>>  know the results.
>>
>> For the record I was able to benchmark the QtQuickCompiler on a x86 @
>> 3.4 GHz and I get: ~250 FPS and without the QtQuickCompiler I get
>> something similar; which means this is pretty much the maximum speed
>> that test can get.
>
> AFAIU QtQuickCompiler has nothing to do with memory management, its main purpose is reduction of start up time and obfuscation of sources.

Ok I assumed that execution time would be affected because the code is 
compiled.

> Note that measuring FPS above screen refresh rate (usually 60) does not make a lot of sense, as underlying graphics systems may not preserve it (and if vsync is enabled, screen refresh rate is a hard upper bound).

You're right but I just wanted to have numbers.

Simon was mentioning that it would be preferable having root_ptr with an 
underlying mechanism to select memory pools based on the type allocated 
or the frequency of the allocation made.  I don't see how it could be 
further optimized.

Does anybody have better memory management benchmarks I could focus on?


Thanks a lot,
-Phil



From thiago.macieira at intel.com  Thu Jan  5 14:57:54 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 05 Jan 2017 07:57:54 -0600
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
Message-ID: <1652549.NNQErPq7BW@tjmaciei-mobl1>

Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard 
escreveu:
> > AFAIU QtQuickCompiler has nothing to do with memory management, its main
> > purpose is reduction of start up time and obfuscation of sources.
>
> Ok I assumed that execution time would be affected because the code is
> compiled.

The code is compiled anyway. The difference is only *when* it is compiled: at 
release time of your application or when your user launches it (JIT).

JIT = Just Too Late (because it will start compiling the moment you need it)

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



From tor.arne.vestbo at qt.io  Thu Jan  5 16:45:34 2017
From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=)
Date: Thu, 5 Jan 2017 16:45:34 +0100
Subject: [Development] Proposal to adjust release candidate process
In-Reply-To: <1618333.CLuHQRrLkn@frederik-thinkcentre-m93p>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<VI1PR02MB10066D2EDF31396B4D62ED178C950@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<AM4PR0202MB2948F5552B1CB27E6BF9C49F8F6E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<1618333.CLuHQRrLkn@frederik-thinkcentre-m93p>
Message-ID: <81adaf08-2cd8-befa-d327-b8165f35d48d@qt.io>



On 04/01/2017 16:25, Frederik Gladhorn wrote:
> On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote:
>> Hi,
>>
>> Perhaps it is best to talk with marketing about the name of the "release
>> done immediately after branching to the .0 release branch". Reading the
>> discussion, it seems that other than the name we are well aligned.
>
> I'd try to follow standards, this is supposed to be primarily understood by
> developers. semver is the most sensible thing I know of when it comes to
> versions. #11 is pretty sensible:
> http://semver.org/#spec-item-11

Yes a thousand times yes.

tor arne



From edward.welbourne at qt.io  Thu Jan  5 17:12:16 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Thu, 5 Jan 2017 16:12:16 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma>,<5648737.pvz8ZeChiJ@tjmaciei-mobl1>
Message-ID: <HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Well, I've missed a long and lively discussion while I was away.  I've
now caught up with e-mail, digested the thread and done some (but by no
means enough) background reading; that's left me with some jumbled
notes.  This shall be long - let's start with the thread (and fit some
of those notes into answering it):

Soroush Rabiei:
>>>>>>>>>>> Please tell me more about your idea when you're back.

Take KCalendarSystem [0], replace its uses of QDate with a Julian day
number (as int [1]), tidy up a bit and have relevant Q(Date|Time)+
methods take one of these as an optional parameter (default: Gregorian)
that configures what they mean by things like year, month, week and day
within any of these.

[0] https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCalendarSystem.html

[1] I notice that QDate uses a qint64 for Julian day, which is overkill;
a 32-bit integral type lets us have 5,879,610 years each side of our
epoch, which is ample, IMO.  KCalendarSystem seems to agree.  QDate
can't change that for its data member, nor do I propose to change its
method signatures, but I see no reason for the calendar system to use
anything bigger than int for Julian dates.

Of course, BC/SC reasons mean "optional parameter" won't (until maybe Qt
6) be an added parameter (with a default) at the ends of existing
methods but a (probably first and non-optional) parameter of overloads
of the existing methods.  Or something like that.

>>>>>>>>>>> I suppose adding new calendars by users, requires
>>>>>>>>>>> subclassing QDate?

A user calendar would be implemented by sub-classing the calendar system
virtual base class.  Instances of that would be passed to methods of
(stock) QDate to over-ride its default use of Gregorian.

>>>>>>>>>>> Or maybe somehow extend the enum that contains calendar
>>>>>>>>>>> systems[?].

An enum can only support the calendar systems for which Qt contains
code.  There shall always be calendars we don't support: it would be
best to ensure users can get support for that, one way or another.  An
app-developer with enough users who want a particular calendar system
should be able to add support for it without waiting for us to care
about that calendar system.

>>>>>>>>>>> I think adding the information on which calendar system is
>>>>>>>>>>> current date is on, can be added as a member (handlre/enum)
>>>>>>>>>>> to QDate.

{Backwards,Source} Compatibility (BC/SC, above) issues preclude that.

Sune Vuorela:
>>>>>>>>>> I think you need to touch quite some of the 'inner bits' of
>>>>>>>>>> date / time

That's fine - messing with internals is OK, it's public A[BP]Is that
can't be changed - except by adding methods.  Most of what I envisage us
changing for this would be turning some existing static functions in the
code into methods of a QGregorianCalendarSystem class, that implements
a generic QCalendarSystem API.

>>>>>>>>>> my two missing pet features:
>>>>>>>>>>  - Partial dates

I'm quite sure these don't belong in Q(Date|Time)+, for all that I can
see their value in calendar (and similar) apps.  There might be a case
for a recurrent event class, that supports all the funky things for
repeating calendar entries - e.g. the first Sunday following a full Moon
which falls on or after the Spring equinox, optionally with "full moon"
and/or "equinox" defined by some arbitrary set of rules rather than by
actual astronomical reality [2] - which would surely include partial
dates.  I encourage you to think about designing that and would be happy
to review any contribution that results ;^>

[2] https://en.wikipedia.org/wiki/Computus
I did not just make that up.

>>>>>>>>>>  - Date/time intervals/delta's.

Those I can see a better case for: they could be handled by operator-()
methods (with returns measured in the given units) of QDate (days),
QTime (milliseconds), QDateTime (milliseconds, 64-bit).  No operator+;
use addDays(), addSeconds(), &c.

>>>>>>>>>> (by date/time deltas, I e.g. I started working somewhere on
>>>>>>>>>> november 1st 2014. and stopped january 3rd 2015. How long did
>>>>>>>>>> I work there)

Quite.  Note, however, that KCalendarSystem::dateDifference() raises a
valid point for broken-down difference in days, months, years - which
need not equate to a simple number of days. [2016-03-01] - [2016-02-01]
is 29 days but the dateDifference is 1 month; while the same in 2017 is
28 days but still 1 month; and [2017-02-01] - [2016-02-01] is one year,
the same as [2017-05-01] - [2016-05-01], but the former is 366 days and
the latter is 365 days.  Other calendar systems shall doubtless give
more such subtleties.

André Somers
>>>>>>>>> If memory serves me right: When, years ago, I tried to get the
>>>>>>>>> latter in, the work was a bit blocked because somebody else
>>>>>>>>> what working on... calendar support. :-)

If you can find either your patches for diff or their patches for
calendar support, I'm sure they'd be useful input to the present effort.

Ch'Gans (a.k.a. Chris):
>>>>>>>> Boost have them all: date/time, calendar, time zone, time
>>>>>>>> period and time duration
>>>>>>>> Date/Time is a very tricky subject, why not rely on boost
>>>>>>>> implementation?
>>>>>>>>
>>>>>>>> http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html

The documentation is a bit thin - leaving me guessing at rather more
than I should need to - but my impression is that this isn't actually as
good as what we have, although it does have some (inadequately
described) handling of alternative calendars.  I'm fairly sure we can do
better.

Thiago
>>>>>>> I don't expect the calendaring system to require any changes to
>>>>>>> QDate internals. It stores a Julian day, that's all.

The QDate data object's internals won't need to change, no; but the code
it presently uses to map between its internal Julian day and years,
months, etc. is all Gregorian and would need rearranged.

Soroush:
>>>>>> QDate knows how many days are in a month, what are month names
>>>>>> (in case locale is not present), how to find leap years, and how
>>>>>> to convert a JulianDay to year, month and day in Gregorian
>>>>>> calendar.

... all of which should clearly move to the Gregorian calendar class
that'll still be used by default to do these jobs; but we can have
methods accept another calendar object instead.

Thiago:
>>>>> QDate will continue to support Gregorian day, month, year, as well
>>>>> as ISO weeks.

... *by default* - but we should be able to have it support some other
calendar's day, month, year and weeks by supplying other calendar
objects to suitable overloads of methods.

Frédéric Marchal:
>>>> As a developer, I don't want to know about the gory details of date
>>>> computation with calendars I have never heard of. Adding "one
>>>> month" to a date should use the same code whatever the underlying
>>>> calendar is.

The calendar wouldn't be "underlying" in what I'm suggesting: client
code (e.g. a calendar app) would need a calendar-system object to pass
in to QDate's methods.  We can't have QDate remember which calendar to
use (ABI change); in any case, I'm fairly sure I don't want it to - as I
do also want to be able to ask about the Gregorian date of the start of
Ramadan (for example), which will mean creating a QDate with one
calendar system and using another to query it.  The QDate shall remain
just a Julian day packaged with some suitable methods, some of which
shall know how to interact with calendar systems.

>>>> The correct calendar to use should be a simple configuration
>>>> parameter

How the app built on Qt picks its calendar system is for the app to
decide.  If the app has a config enum that tells it which
Q*CalendarSystem to instantiate, that's fine by me: but I do also want
apps to be able to support calendar systems that aren't mass-market
enough that it makes sense for *us* to support them.

The nice thing about an instance-based approach is that an app can even
support loading a user-selected plugin that supports an API that lets
the app extract a calendar-system object that describes the calendar the
user actually wants to use - all without the app developer (or us)
having to know the details of that calendar system, merely how to load
the object for it.  Then the long tail of users with arcane calendars
can be catered to without us (or the app developer) having to ever see
(much less write, maintain or debug) the code that implements it.  One
member of the community that uses that calendar system shall need to
write the plugin (or whatever) and then all apps that know how to load
that plugin can support those users to their satisfaction.  We could
just support the more widely-used calendar systems.

Soroush:
>>>> Can we add arguments to all methods with a default value? Something
>>>> like:
>>>>
>>>>     QDate d;
>>>>     qDebug() << d.year();               // prints 2016
>>>>     qDebug() << d.year(QCalendar::Jalali); // prints 1395

That's what I have in mind, only with a QJalaliCalendar() instance in
place of your enum.

>>>> And then force relevant widgets/views to show/edit date and time on
>>>> a specific calendar system:
>>>>
>>>>     QDateEdit de;
>>>>     de.setDate(d);
>>>>     de.setCalendarSystem(QCalendar::Hebrew); // Is this possible?

That's trickier, as it would change QDateEdit's ABI.  Changing QDateEdit
to support other calendar systems would likely involve a major re-write.
However, a calendar-system-aware QDate might help you write your own
CalendarAwareDateEdit widget, based on QDateEdit.  It might then replace
QDateEdit in Qt6.

Lars Knoll:
>>>> I wonder whether we can't keep handling of different calendars
>>>> completely outside of QDate. Something similar to what we've done
>>>> with QString/QLocale. So QDate would continue unchanged and only
>>>> support the standard Gregorian calendar. In addition, we have a
>>>> QCalendar class, that can be constructed with a different calendar
>>>> system, and can then return 'localized' date strings, days, months
>>>> and years for this calendar system.

That would be another option (and it would approximately just upstream
KCalendarSystem); but I actually think the plan I sketch above can work
and will be more natural.  When it comes down to it, QDate really is
just a Julian day number and everything it does for the Gregorian
calendar is well-enough separated that I believe we can split it out.

>>>> Something like:
>>>>
>>>> QDate date;
>>>> QCalendar c(QCalendar::Hebrew);
>>>> QString hebrewDateString = c.toString(date);
>>>> int hebrewYear = c.year(date);

What I have in mind would look like: <code>

Type func(const QDate &date, const QCalendarSystem &calendar)
{
    QString text = date.toString(calendar);
    int year = date.year(calendar);
    ...
}

Type val = func(QDate(QJalaliCalendar(), 1395, 7, 15), QHebrewCalendar());

</code> (and I have no idea what I just did), except that the naked
instantiations would, in real application code, almost always be
replaced by forwarding const QCalendarSystem & values obtained from
elsewhere.

A calendar app can then have several panels or views, each with an
independent choice of calendar system; it the user drags a date from one
to another, it's just a Julian day so transfers safely but gets
displayed utterly differently after the transfer; all the same, the
events on the day get carried over just fine.  Or I can drag an event
from one to another; the event remembers its day, so lands in the right
place, for all that this is displayed differently.  The user can change
the calendar system in use by a view; all the entries change their
appearance but the underlying QDate objects stay the same.

>>>> Maybe one could even integrate this into QLocale, that already
>>>> provides support for localized month and day names?

QCalendarSystem or the QDate code using it is clearly going to need to
interact with QLocale, if only to get localised names of months and
week-days.  That probably won't happen by translating "February" or
"Wednesday" though; there may be no clean match between the months and
days of the other calendar and those of the European calendars.

However, calendar system is separate from locale; see the last paragraph
of my earlier mail and Soroush's response to it.

Frédéric Marchal
>>> There is more to it than converting a date to a string:
>>>
>>> * Add N days to a date.

That one's easy, because QDate is just a Julian day; increment it by N.
The part needing work is addMonths(const QCalendarSystem&, int) and
addYears(const QCalendarSystem &, int).  Eminently feasible.

>>> * Find the number of days in a month.

Not something we presently do for Gregorian; but not an unreasonable
thing to consider adding to the QDate (and QDateTime) API:

  int daysInMonth(const QCalendarSystem &cs = QGregorianCalendarSystem());

>>> * Compare two dates.

No need to change, just compare Julian day numbers.

>>> * Count the number of days between two dates.

Difference between Julian day numbers, easy.  More fun, but eminently
do-able, is the equivalent of KCalendarSystem::dateDifference().

>>> For instance a program wishing a happy new year to its users should
>>> do it with as little modifications as possible.

Yes; and I think that's feasible.

>>> Using a plain QDate would have been the easiest way to reach more
>>> users because it doesn't require to replace lots of QDate with a
>>> new, very similar, class. As it is not possible to change QDate for
>>> now, Soroush is looking for a temporary solution that would bridge
>>> the gap until Qt6 is out.

I think what I have in mind will manage this without needing to wait for
Qt6 (although we might want to clean up at Qt6).

Lars Knoll:
>> it might be a good idea to have this functionality in a class
>> separate from QDate. We’ve done the same design decision for QString
>> (having no locale specific functionality in QString), and this worked
>> out rather nicely. So I would encourage you to have a look whether
>> and how a similar design could be done for calendar system support.

QDate already has (Gregorian-based) methods entangling it with notions
of year, month, week and day within each; this is intrinsically
calendar-system-specific.  Aside from that it's just a Julian day,
stored in an oversized data-type (qint64, where int would suffice); so
there's nothing there except the bits that we'd need to remove to do the
equivalent of taking QLocale out of QString.

Sérgio Martins very helpfully linked to KCalendarSystem - thank you.
One of the things we should clearly aim for is to make it easy for
KCalendarSystem to (when its developers care to and can find the time,
with no pressure to do so) adapt to use QCalendarSystem and the adapted
QDate.  TODO: I also need to find and talk to its maintainers.

Thiago:
> Just like QString being able to format numbers in one particular
> locale (the "C" locale), we ought to support the C locale's
> calendaring system in QDate too.

I entirely agree that we should continue to support Gregorian by
default.  I think it makes sense, though, to have QDate work with other
calendaring systems.  Even if QCalendarSystem sits outside QDate and
does all the work for itself, then - with a putative

  QGregorianCalendarSystem greg;
  QDate date;

in scope - date.method(args) shall in many cases be equivalent to
greg.method(date.toJulianDay(), args) and QDate(args) to
QDate::fromJulianDay(greg.julianDay(args)).  It seems needlessly
limiting, to support for other calendar systems, not to also let these
be expressed in QDate as date.method(greg, args) and QDate(greg, args),
respectively, so that we can replace greg with another calendar system
object and save clients some tedious boilerplate.

I think my main reason for wanting this is that, without it, code that
supports non-Gregorian calendars shall have essentially no use for QDate
- its only use would be to extract its .toJulianDate(), do real work
with that, then QDate::fromJulianDate() back in order to interact with
the rest of Qt.  It would then make more sense for such code so simply
discard QDate and just use a Julian day instead - the need to convert
to/from QDate in order to interact with Qt would just be a hindrance,
rather than a help.

QDate should make it easy for app developers to add support for other
calendar systems, with minimal re-writing, rather than seducing them
into writing Gregorian-specific code that they would have to throw away
entirely in order to add that support.

... and that's me caught up with the thread.

Issue: Q(Date|Time)+ think day-changes happen at midnight.  Some
calendar systems think they happen at sunset or sunrise; these are both
rather tricky, as their time depends on date and latitude [3] - and I'm
not sure what they do about days when the sun doesn't set or rise at
all.  I don't see any hint of coping with this in KCalendarSystem and
I'm fairly sure I don't want to solve that problem, so I think we stick
with midnight and leave apps using the result to fix up after the fact
if they really care.  Indeed, what *is* common practice in The Middle
East, as regards how evenings get handled - as the tail of one day or
the start of the next ?  Has secular society shifted the day boundary to
midnight in practice ?

[3] also geography, altitude and even local climactic complications:
    https://en.wikipedia.org/wiki/Novaya_Zemlya_effect

Kindred issue with the ancient Julian calendar: before some time
mediaeval, when year transitions got moved to a month boundary, the day
after (somewhen like) March 14th of one year would be March 15th of the
*next* year.  (March is month 1: that's why Sept = 7, Oct = 8, Nov = 9
and Dec = 10 are the embers of the year, whose month numbers are now two
more than what their names claim.)

That one probably can be handled, but it's the sort of mess I'd rather
not implement myself, so I want an API that lets the app, or a plugin
it's loaded, supply the calendar system object to handle it.  Some
calendar systems matter a lot to those that care about them but are
nowhere near mass-market enough that it makes any sense for us to plan
on implementing them all.  There are a few widely-used calendars and a
long tail of more obscure ones: we need an architecture which lets
client code cater to the ones that we aren't about to handle natively.

KCalendarSystem's daysIn{Year,Month,Week} are sensible methods for the
calendar system class, albeit taking a Julian day rather than a QDate
(which is equivalent).  Various other methods that take or return QDate
would replace it with a Julian day; QDate would then use these in place
of its present hard-coded Gregorian code.

	Eddy.


From cfeck at kde.org  Thu Jan  5 18:19:35 2017
From: cfeck at kde.org (Christoph Feck)
Date: Thu, 5 Jan 2017 18:19:35 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma> <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <1c8df8bd-4ac0-84fd-18a9-04b5f27d3168@kde.org>

On 05.01.2017 17:12, Edward Welbourne wrote:
> Sérgio Martins very helpfully linked to KCalendarSystem - thank you.
> One of the things we should clearly aim for is to make it easy for
> KCalendarSystem to (when its developers care to and can find the time,
> with no pressure to do so) adapt to use QCalendarSystem and the adapted
> QDate.  TODO: I also need to find and talk to its maintainers.

Maintainer for KCalenderSystem was John Layt.



From Simon.Hausmann at qt.io  Thu Jan  5 20:50:52 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Thu, 5 Jan 2017 19:50:52 +0000
Subject: [Development] State of dev branch in CI
Message-ID: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>


Hi,

I wanted to give a quick update on the state of the dev branch in the CI:

Currently any changes to any module outside of qtbase targeting the dev branch will fail to pass the build stage in the CI.

Recently RHEL 7.2 was added to dev. When that was tested - back in fall last year - all was fine. Then some configure options of qtbase were changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer story but basically because of our binary packages). Earlier this week the change in the CI to add RHEL 7.2 to dev was taken into production and immediately broke the build of all modules in dev because -qt-pcre was not a valid configure parameter anymore and without qtbase nothing else builds. As a consequence the CI changes were reverted.

Meanwhile the qtbase configure parameters were fixed and support for -qt-pcre was restored. Today the CI changes were taken in again and qtbase in the dev branch compiles on RHEL 7.2.

Unfortunately all other modules are built against qtbase from qt5.git, which doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other than qtbase are broken in dev.

An update of qt5.git with a newer qtbase is scheduled, but unfortunately it won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .

There are different options for solving this. One would be to revert the CI change. Another would be to fix the above bug and get the qt5 change through.


The right solution to prevent these types of situations in the future is to have these platform configs inside qt5.git, not in the CI. Unfortunately that is not a priority yet.



Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170105/d44f0d48/attachment.html>

From apoenitz at t-online.de  Thu Jan  5 21:09:26 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Thu, 5 Jan 2017 21:09:26 +0100
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <1652549.NNQErPq7BW@tjmaciei-mobl1>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<1652549.NNQErPq7BW@tjmaciei-mobl1>
Message-ID: <20170105200926.GA2462@klara.mpi.htwm.de>

On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote:
> Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard 
> escreveu:
> > > AFAIU QtQuickCompiler has nothing to do with memory management, its main
> > > purpose is reduction of start up time and obfuscation of sources.
> >
> > Ok I assumed that execution time would be affected because the code is
> > compiled.
> 
> The code is compiled anyway. The difference is only *when* it is compiled: at 
> release time of your application or when your user launches it (JIT).

It's not the only difference. A JIT compiler has typically not the same
scope/abilities/optimization opportunities as a real compiler, not to mention
deficiencies in a language that has 'double' as only numeric type.

So "compiler" and "compiler" are apples and oranges in this case.
 
> JIT = Just Too Late (because it will start compiling the moment you need it)

Correct.

And done on each and every (often under-powered) device out there, if not even
done on each and every application start, instand once when preparing binary
packages.

*sigh*

Andre'


From philippeb8 at gmail.com  Fri Jan  6 00:05:32 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Thu, 5 Jan 2017 18:05:32 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <20170105200926.GA2462@klara.mpi.htwm.de>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<1652549.NNQErPq7BW@tjmaciei-mobl1>
	<20170105200926.GA2462@klara.mpi.htwm.de>
Message-ID: <o4mjfo$7qg$1@blaine.gmane.org>

On 01/05/2017 03:09 PM, André Pönitz wrote:
> On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote:
>> Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard
>> escreveu:
>>>> AFAIU QtQuickCompiler has nothing to do with memory management, its main
>>>> purpose is reduction of start up time and obfuscation of sources.
>>>
>>> Ok I assumed that execution time would be affected because the code is
>>> compiled.
>>
>> The code is compiled anyway. The difference is only *when* it is compiled: at
>> release time of your application or when your user launches it (JIT).
>
> It's not the only difference. A JIT compiler has typically not the same
> scope/abilities/optimization opportunities as a real compiler, not to mention
> deficiencies in a language that has 'double' as only numeric type.
>
> So "compiler" and "compiler" are apples and oranges in this case.

Right, g++ is much more portable than JIT.

>> JIT = Just Too Late (because it will start compiling the moment you need it)
>
> Correct.
>
> And done on each and every (often under-powered) device out there, if not even
> done on each and every application start, instand once when preparing binary
> packages.

In Brave New World we would have the QtQuickCompiler running on the fly, 
followed by g++ and the browser could "dlopen" the generated library.  I 
don't see any better solution than this.



From philippeb8 at gmail.com  Fri Jan  6 00:44:01 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Thu, 5 Jan 2017 18:44:01 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
Message-ID: <5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>

On 01/05/2017 07:26 AM, Phil Bouchard wrote:
>
> Simon was mentioning that it would be preferable having root_ptr with an
> underlying mechanism to select memory pools based on the type allocated
> or the frequency of the allocation made.  I don't see how it could be
> further optimized.

After reading the following optimized memory pool documentation:
https://github.com/cacay/MemoryPool

I just realized how obvious it is.  You just add some timer to determine 
the frequency, you measure the speed of the allocation requests and you 
"adapt" the memory chunks you allocate that will be later subdivided 
into the sizeof the type of the object.  All of this type-oriented.

So if you allocate 1,000,000 integers a second then larger memory blocks 
of sizeof(int) * 1000000 * CONSTANT will be allocated at once.

I am cross-posting this message with the Boost mailing list because it 
is so evident.


-Phil



From annulen at yandex.ru  Fri Jan  6 11:06:56 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 06 Jan 2017 13:06:56 +0300
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <o4mjfo$7qg$1@blaine.gmane.org>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<1652549.NNQErPq7BW@tjmaciei-mobl1>
	<20170105200926.GA2462@klara.mpi.htwm.de>
	<o4mjfo$7qg$1@blaine.gmane.org>
Message-ID: <8366351483697216@web29h.yandex.ru>



06.01.2017, 02:06, "Phil Bouchard" <philippeb8 at gmail.com>:
> On 01/05/2017 03:09 PM, André Pönitz wrote:
>>  On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote:
>>>  Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard
>>>  escreveu:
>>>>>  AFAIU QtQuickCompiler has nothing to do with memory management, its main
>>>>>  purpose is reduction of start up time and obfuscation of sources.
>>>>
>>>>  Ok I assumed that execution time would be affected because the code is
>>>>  compiled.
>>>
>>>  The code is compiled anyway. The difference is only *when* it is compiled: at
>>>  release time of your application or when your user launches it (JIT).
>>
>>  It's not the only difference. A JIT compiler has typically not the same
>>  scope/abilities/optimization opportunities as a real compiler, not to mention
>>  deficiencies in a language that has 'double' as only numeric type.
>>
>>  So "compiler" and "compiler" are apples and oranges in this case.
>
> Right, g++ is much more portable than JIT.
>
>>>  JIT = Just Too Late (because it will start compiling the moment you need it)
>>
>>  Correct.
>>
>>  And done on each and every (often under-powered) device out there, if not even
>>  done on each and every application start, instand once when preparing binary
>>  packages.
>
> In Brave New World we would have the QtQuickCompiler running on the fly,
> followed by g++ and the browser could "dlopen" the generated library. I
> don't see any better solution than this.

This does not make any sense, as QtQuickCompiler does exactly the same thing at compile time as regular Qml/JS parser does at run time

>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From annulen at yandex.ru  Fri Jan  6 11:14:31 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 06 Jan 2017 13:14:31 +0300
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <20170105200926.GA2462@klara.mpi.htwm.de>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<1652549.NNQErPq7BW@tjmaciei-mobl1>
	<20170105200926.GA2462@klara.mpi.htwm.de>
Message-ID: <7851781483697671@web29j.yandex.ru>



05.01.2017, 23:06, "André Pönitz" <apoenitz at t-online.de>:
> On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote:
>>  Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard
>>  escreveu:
>>  > > AFAIU QtQuickCompiler has nothing to do with memory management, its main
>>  > > purpose is reduction of start up time and obfuscation of sources.
>>  >
>>  > Ok I assumed that execution time would be affected because the code is
>>  > compiled.
>>
>>  The code is compiled anyway. The difference is only *when* it is compiled: at
>>  release time of your application or when your user launches it (JIT).
>
> It's not the only difference. A JIT compiler has typically not the same
> scope/abilities/optimization opportunities as a real compiler, not to mention
> deficiencies in a language that has 'double' as only numeric type.

Yes, JIT compiler has much more optimization opportunities in case of dynamically typed language than "real" compiler. It sees what types are actually passed as function arguments so can produce optimal fast paths, while static compiler would have to generate only type-unaware code or guess types.

>
> So "compiler" and "compiler" are apples and oranges in this case.
>
>>  JIT = Just Too Late (because it will start compiling the moment you need it)
>
> Correct.
>
> And done on each and every (often under-powered) device out there, if not even
> done on each and every application start, instand once when preparing binary
> packages.
>
> *sigh*
>
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Fri Jan  6 15:09:49 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 06 Jan 2017 06:09:49 -0800
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <8366351483697216@web29h.yandex.ru>
References: <o3nf12$c5a$1@blaine.gmane.org> <o4mjfo$7qg$1@blaine.gmane.org>
	<8366351483697216@web29h.yandex.ru>
Message-ID: <3740702.6bokrKC9lJ@tjmaciei-mobl1>

Em sexta-feira, 6 de janeiro de 2017, às 13:06:56 PST, Konstantin Tokarev 
escreveu:
> > In Brave New World we would have the QtQuickCompiler running on the fly,
> > followed by g++ and the browser could "dlopen" the generated library. I
> > don't see any better solution than this.
> 
> This does not make any sense, as QtQuickCompiler does exactly the same thing
> at compile time as regular Qml/JS parser does at run time

André is questioning our choice of using a dynamic language in the first place.

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



From apoenitz at t-online.de  Fri Jan  6 20:45:55 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Fri, 6 Jan 2017 20:45:55 +0100
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <7851781483697671@web29j.yandex.ru>
References: <o3nf12$c5a$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<1652549.NNQErPq7BW@tjmaciei-mobl1>
	<20170105200926.GA2462@klara.mpi.htwm.de>
	<7851781483697671@web29j.yandex.ru>
Message-ID: <20170106194555.GA3219@klara.mpi.htwm.de>

On Fri, Jan 06, 2017 at 01:14:31PM +0300, Konstantin Tokarev wrote:
> 
> 
> 05.01.2017, 23:06, "André Pönitz" <apoenitz at t-online.de>:
> > On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote:
> >>  Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil
> >> Bouchard  escreveu:  > > AFAIU QtQuickCompiler has nothing to do
> >> with memory management, its main  > > purpose is reduction of start
> >> up time and obfuscation of sources.   >  > Ok I assumed that
> >> execution time would be affected because the code is  > compiled.
> >>
> >>  The code is compiled anyway. The difference is only *when* it is
> >> compiled: at  release time of your application or when your user
> >> launches it (JIT).
> >
> > It's not the only difference. A JIT compiler has typically not the
> > same scope/abilities/optimization opportunities as a real compiler,
> > not to mention deficiencies in a language that has 'double' as only
> > numeric type.
> 
> Yes, JIT compiler has much more optimization opportunities in case of
> dynamically typed language than "real" compiler.

The point is that deciding to use a dynamically typed language in
performance sensitive environments already paints you into a corner.

Whether it's faster to jump from the 20th floor or from the 40th
does not make a conceptual difference if your goal is to survive.

Andre'


From philippeb8 at gmail.com  Sat Jan  7 01:17:55 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Fri, 6 Jan 2017 19:17:55 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
Message-ID: <24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>

On 01/05/2017 06:44 PM, Phil Bouchard wrote:
> On 01/05/2017 07:26 AM, Phil Bouchard wrote:
>>
>> Simon was mentioning that it would be preferable having root_ptr with an
>> underlying mechanism to select memory pools based on the type allocated
>> or the frequency of the allocation made.  I don't see how it could be
>> further optimized.
>
> After reading the following optimized memory pool documentation:
> https://github.com/cacay/MemoryPool
>
> I just realized how obvious it is.  You just add some timer to determine
> the frequency, you measure the speed of the allocation requests and you
> "adapt" the memory chunks you allocate that will be later subdivided
> into the sizeof the type of the object.  All of this type-oriented.
>
> So if you allocate 1,000,000 integers a second then larger memory blocks
> of sizeof(int) * 1000000 * CONSTANT will be allocated at once.
>
> I am cross-posting this message with the Boost mailing list because it
> is so evident.

Just to conclude I did try the attached benchmark and I get the 
following on a x86_64 @ 2.40 GHz:

0: 61331143.40263957 allocations / second
1: 63644162.93924019 allocations / second
2: 177628727.5388474 allocations / second
3: 179850939.5413082 allocations / second
1 / 0: 103.7713621632905% boost
2 / 1: 101.2510431354494% boost

So the fast_pool_allocator is already pretty fast and I can only get a 
1% speed boost by allocating big memory blocks.  So it doesn't look like 
there is any way to make the fast_pool_allocator any faster.


Regards,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 1561 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170106/949ffaa1/attachment.cpp>

From philippeb8 at gmail.com  Sat Jan  7 02:05:06 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Fri, 6 Jan 2017 20:05:06 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
Message-ID: <6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>

On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>
> Just to conclude I did try the attached benchmark and I get the
> following on a x86_64 @ 2.40 GHz:
>
> 0: 61331143.40263957 allocations / second
> 1: 63644162.93924019 allocations / second
> 2: 177628727.5388474 allocations / second
> 3: 179850939.5413082 allocations / second
> 1 / 0: 103.7713621632905% boost
> 2 / 1: 101.2510431354494% boost
>
> So the fast_pool_allocator is already pretty fast and I can only get a
> 1% speed boost by allocating big memory blocks.  So it doesn't look like
> there is any way to make the fast_pool_allocator any faster.

Correction: I get a 11% speed boost with the -O3 flag:

0: 60387275.67636769 allocations / second
1: 63133704.55951615 allocations / second
2: 169169529.8609596 allocations / second
3: 188535531.4062488 allocations / second
1 / 0: 104.5480258090584% boost
2 / 1: 111.447688931456% boost

So I am not sure if this is worth the trouble.



From philippeb8 at gmail.com  Sat Jan  7 04:37:08 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Fri, 6 Jan 2017 22:37:08 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
Message-ID: <761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>

On 01/06/2017 08:05 PM, Phil Bouchard wrote:
> On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>>
>> Just to conclude I did try the attached benchmark and I get the
>> following on a x86_64 @ 2.40 GHz:
>>
>> 0: 61331143.40263957 allocations / second
>> 1: 63644162.93924019 allocations / second
>> 2: 177628727.5388474 allocations / second
>> 3: 179850939.5413082 allocations / second
>> 1 / 0: 103.7713621632905% boost
>> 2 / 1: 101.2510431354494% boost
>>
>> So the fast_pool_allocator is already pretty fast and I can only get a
>> 1% speed boost by allocating big memory blocks.  So it doesn't look like
>> there is any way to make the fast_pool_allocator any faster.
>
> Correction: I get a 11% speed boost with the -O3 flag:
>
> 0: 60387275.67636769 allocations / second
> 1: 63133704.55951615 allocations / second
> 2: 169169529.8609596 allocations / second
> 3: 188535531.4062488 allocations / second
> 1 / 0: 104.5480258090584% boost
> 2 / 1: 111.447688931456% boost
>
> So I am not sure if this is worth the trouble.

Did you know the optimized boost::fast_pool_allocator is 305% times 
faster than the regular one?

0: 61407861.18875794 allocations / second
1: 62565419.96725326 allocations / second
2: 175311265.1512761 allocations / second
3: 187319938.708916 allocations / second
1 / 0: 101.8850335381934% boost
2 / 1: 106.8499155187076% boost
3 / 0: 305.0422781101666% boost

Is Qt using a similar pool allocator?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 1645 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170106/c1679bd2/attachment.cpp>

From soroush.rabiei at gmail.com  Sat Jan  7 08:51:39 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Sat, 7 Jan 2017 11:21:39 +0330
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma> <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>

Greetings all, and happy new year


> Issue: Q(Date|Time)+ think day-changes happen at midnight.  Some
>
calendar systems think they happen at sunset or sunrise; these are both
> rather tricky, as their time depends on date and latitude [3] - and I'm
> not sure what they do about days when the sun doesn't set or rise at
> all.  I don't see any hint of coping with this in KCalendarSystem and
> I'm fairly sure I don't want to solve that problem, so I think we stick
> with midnight and leave apps using the result to fix up after the fact
> if they really care.  Indeed, what *is* common practice in The Middle
> East, as regards how evenings get handled - as the tail of one day or
> the start of the next ?  Has secular society shifted the day boundary to
> midnight in practice ?
>

Indeed they do the simplification needed to adopt modern lifestyle. As far
as I know, modern lunar calendars being used in ME as official calendars,
have loads of simplifications applied compared to the original calendars.
The start of a month in Islamic calendar in Fiqh (regional calendar) is
based on observing new moon (by unaided eye) in the sky. That's why Saudi
Arabia sometimes celebrate end of Ramadan one day after Turkey, and one day
before Iran. That's why number of days differ from a year to another.
Though, the start of the day is 00:00 in modern calendars. And number of
days in months are fixed.

Anyway, the only country using lunar calendar (Saudi Arabia) just switched
to solar system (Gregorian). But we have to support Islamic calendar
(modern version) of course.

My current implementation looks like KCalendarSystem with some differences.
Calendar classes are subclassed from QAbstractCalendar, and have to
implement several methods. I tried to make this class as generic as
possible, there is no assumption on month days and number of months. I just
finished adding new methods to QDate and it's working for Jalali Calendar.

QDate d = QDate::currentDate();
int gyear1 = d.year();  // 2017
int gyear2 = d.year(QGregorianCalendar);  // 2017
int jyear1 = d.year(QJalaliCalendar()); // 1395
int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395

I didn't touch Gregorian calculations in QDate, just added more functions.
Does removing static members count as an ABI change? I'm planning to move
all the math out of QDate into QGregorianCalendar.

About calendaring widgets, The widget obviously needs to keep information
on what calendar system it uses. I think it's possible to add members to
private API classes? After all it's **private** and there's only a pointer
to private API class in main class. So it would be A[BP]I compatible I
suppose. And also we need to add some functions to main class:

    void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString?
    QAbstractCalendar* QDateEdit::calendar() const; // meh...

There is another issue: How do we add calendar localization to QLocale?

Cheers,
Soroush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170107/30d56ee8/attachment.html>

From Simon.Hausmann at qt.io  Sat Jan  7 11:18:22 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sat, 7 Jan 2017 10:18:22 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


Brief "update": dev is still blocked.


The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be due to the removal of macOS 10.9 support, while the CI still builds with 10.9.


We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre fix.


A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the 10.9 drop until the CI "supports" it was rejected.


So either


    (a) the temporary reversal gets approved instead of rejected. Then over the remaining weekend we could try to get a qt5.git update through with the pcre fix to unblock dev.


or


    (b) the CI removes 10.9 support and moves the features the 10.9 tests (namespace, etc.) over to another macOS build. Then we could get a qt5.git update through that includes the pcre fix.


Differently put, there are two things blocking Qt dev branch development outside of qtbase:


    (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or alternatively RHEL 7.2 temporary reversal in the CI.


    (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to proceed) or CI changes as mentioned in (b).




Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Thursday, January 5, 2017 8:50:52 PM
To: development
Subject: [Development] State of dev branch in CI


Hi,

I wanted to give a quick update on the state of the dev branch in the CI:

Currently any changes to any module outside of qtbase targeting the dev branch will fail to pass the build stage in the CI.

Recently RHEL 7.2 was added to dev. When that was tested - back in fall last year - all was fine. Then some configure options of qtbase were changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer story but basically because of our binary packages). Earlier this week the change in the CI to add RHEL 7.2 to dev was taken into production and immediately broke the build of all modules in dev because -qt-pcre was not a valid configure parameter anymore and without qtbase nothing else builds. As a consequence the CI changes were reverted.

Meanwhile the qtbase configure parameters were fixed and support for -qt-pcre was restored. Today the CI changes were taken in again and qtbase in the dev branch compiles on RHEL 7.2.

Unfortunately all other modules are built against qtbase from qt5.git, which doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other than qtbase are broken in dev.

An update of qt5.git with a newer qtbase is scheduled, but unfortunately it won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .

There are different options for solving this. One would be to revert the CI change. Another would be to fix the above bug and get the qt5 change through.


The right solution to prevent these types of situations in the future is to have these platform configs inside qt5.git, not in the CI. Unfortunately that is not a priority yet.



Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170107/34822024/attachment.html>

From philippeb8 at gmail.com  Sat Jan  7 18:11:48 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Sat, 7 Jan 2017 12:11:48 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
	<761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
Message-ID: <o4r7gg$5o6$1@blaine.gmane.org>

On 01/06/2017 10:37 PM, Phil Bouchard wrote:
> On 01/06/2017 08:05 PM, Phil Bouchard wrote:
>> On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>>>
>>> Just to conclude I did try the attached benchmark and I get the
>>> following on a x86_64 @ 2.40 GHz:
>>>
>>> 0: 61331143.40263957 allocations / second
>>> 1: 63644162.93924019 allocations / second
>>> 2: 177628727.5388474 allocations / second
>>> 3: 179850939.5413082 allocations / second
>>> 1 / 0: 103.7713621632905% boost
>>> 2 / 1: 101.2510431354494% boost
>>>
>>> So the fast_pool_allocator is already pretty fast and I can only get a
>>> 1% speed boost by allocating big memory blocks.  So it doesn't look like
>>> there is any way to make the fast_pool_allocator any faster.
>>
>> Correction: I get a 11% speed boost with the -O3 flag:
>>
>> 0: 60387275.67636769 allocations / second
>> 1: 63133704.55951615 allocations / second
>> 2: 169169529.8609596 allocations / second
>> 3: 188535531.4062488 allocations / second
>> 1 / 0: 104.5480258090584% boost
>> 2 / 1: 111.447688931456% boost
>>
>> So I am not sure if this is worth the trouble.
>
> Did you know the optimized boost::fast_pool_allocator is 305% times
> faster than the regular one?
>
> 0: 61407861.18875794 allocations / second
> 1: 62565419.96725326 allocations / second
> 2: 175311265.1512761 allocations / second
> 3: 187319938.708916 allocations / second
> 1 / 0: 101.8850335381934% boost
> 2 / 1: 106.8499155187076% boost
> 3 / 0: 305.0422781101666% boost
>
> Is Qt using a similar pool allocator?

This means the optimized boost::fast_allocator is 470% times faster than 
the system "operator new":

0: 37334468.30116969 allocations / second (operator new)
1: 58554420.18534816 allocations / second (boost::pool_allocator)
2: 60072218.82146717 allocations / second (boost::pool_allocator)
3: 164895686.9884111 allocations / second (boost::fast_pool_allocator)
4: 175697519.1510296 allocations / second (boost::fast_pool_allocator)
2 / 1: 102.5921162421463% boost
4 / 3: 106.550706304027% boost
4 / 0: 470.6040480708413% boost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 1802 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170107/907b4261/attachment.cpp>

From philippeb8 at gmail.com  Sat Jan  7 18:58:32 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Sat, 7 Jan 2017 12:58:32 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <o4r7gg$5o6$1@blaine.gmane.org>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
	<761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
	<o4r7gg$5o6$1@blaine.gmane.org>
Message-ID: <o4ra83$tnd$1@blaine.gmane.org>

On 01/07/2017 12:11 PM, Phil Bouchard wrote:
> On 01/06/2017 10:37 PM, Phil Bouchard wrote:
>> On 01/06/2017 08:05 PM, Phil Bouchard wrote:
>>> On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>>>>
>>>> Just to conclude I did try the attached benchmark and I get the
>>>> following on a x86_64 @ 2.40 GHz:
>>>>
>>>> 0: 61331143.40263957 allocations / second
>>>> 1: 63644162.93924019 allocations / second
>>>> 2: 177628727.5388474 allocations / second
>>>> 3: 179850939.5413082 allocations / second
>>>> 1 / 0: 103.7713621632905% boost
>>>> 2 / 1: 101.2510431354494% boost
>>>>
>>>> So the fast_pool_allocator is already pretty fast and I can only get a
>>>> 1% speed boost by allocating big memory blocks.  So it doesn't look
>>>> like
>>>> there is any way to make the fast_pool_allocator any faster.
>>>
>>> Correction: I get a 11% speed boost with the -O3 flag:
>>>
>>> 0: 60387275.67636769 allocations / second
>>> 1: 63133704.55951615 allocations / second
>>> 2: 169169529.8609596 allocations / second
>>> 3: 188535531.4062488 allocations / second
>>> 1 / 0: 104.5480258090584% boost
>>> 2 / 1: 111.447688931456% boost
>>>
>>> So I am not sure if this is worth the trouble.
>>
>> Did you know the optimized boost::fast_pool_allocator is 305% times
>> faster than the regular one?
>>
>> 0: 61407861.18875794 allocations / second
>> 1: 62565419.96725326 allocations / second
>> 2: 175311265.1512761 allocations / second
>> 3: 187319938.708916 allocations / second
>> 1 / 0: 101.8850335381934% boost
>> 2 / 1: 106.8499155187076% boost
>> 3 / 0: 305.0422781101666% boost
>>
>> Is Qt using a similar pool allocator?
>
> This means the optimized boost::fast_allocator is 470% times faster than
> the system "operator new":
>
> 0: 37334468.30116969 allocations / second (operator new)
> 1: 58554420.18534816 allocations / second (boost::pool_allocator)
> 2: 60072218.82146717 allocations / second (boost::pool_allocator)
> 3: 164895686.9884111 allocations / second (boost::fast_pool_allocator)
> 4: 175697519.1510296 allocations / second (boost::fast_pool_allocator)
> 2 / 1: 102.5921162421463% boost
> 4 / 3: 106.550706304027% boost
> 4 / 0: 470.6040480708413% boost

I just tried the "jemalloc" library and I get a 2576228000% speed boost 
compared to operator new:

0: 38816440.15979952 allocations / second
1: 62188319.91413037 allocations / second
2: 63819182.38692677 allocations / second
3: 174727730.5139267 allocations / second
4: 186025745.9632413 allocations / second
5: 1000000000000000 allocations / second
5 / 0: 2576228000% boost
5 / 1: 1608019000% boost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 2121 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170107/2896bb70/attachment.cpp>

From annulen at yandex.ru  Sat Jan  7 19:04:57 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sat, 07 Jan 2017 21:04:57 +0300
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <o4ra83$tnd$1@blaine.gmane.org>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
	<761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
	<o4r7gg$5o6$1@blaine.gmane.org> <o4ra83$tnd$1@blaine.gmane.org>
Message-ID: <1488741483812297@web5g.yandex.ru>

Oh, looks like you are going to learn about lots of other wonderful memory allocators soon. There is no real need to keep us informed about each of them (I guess most of interested folks are already well-aware of them), but please make sure you've studied prior art thoroughly before designing your own things.

07.01.2017, 20:59, "Phil Bouchard" <philippeb8 at gmail.com>:
> On 01/07/2017 12:11 PM, Phil Bouchard wrote:
>>  On 01/06/2017 10:37 PM, Phil Bouchard wrote:
>>>  On 01/06/2017 08:05 PM, Phil Bouchard wrote:
>>>>  On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>>>>>  Just to conclude I did try the attached benchmark and I get the
>>>>>  following on a x86_64 @ 2.40 GHz:
>>>>>
>>>>>  0: 61331143.40263957 allocations / second
>>>>>  1: 63644162.93924019 allocations / second
>>>>>  2: 177628727.5388474 allocations / second
>>>>>  3: 179850939.5413082 allocations / second
>>>>>  1 / 0: 103.7713621632905% boost
>>>>>  2 / 1: 101.2510431354494% boost
>>>>>
>>>>>  So the fast_pool_allocator is already pretty fast and I can only get a
>>>>>  1% speed boost by allocating big memory blocks. So it doesn't look
>>>>>  like
>>>>>  there is any way to make the fast_pool_allocator any faster.
>>>>
>>>>  Correction: I get a 11% speed boost with the -O3 flag:
>>>>
>>>>  0: 60387275.67636769 allocations / second
>>>>  1: 63133704.55951615 allocations / second
>>>>  2: 169169529.8609596 allocations / second
>>>>  3: 188535531.4062488 allocations / second
>>>>  1 / 0: 104.5480258090584% boost
>>>>  2 / 1: 111.447688931456% boost
>>>>
>>>>  So I am not sure if this is worth the trouble.
>>>
>>>  Did you know the optimized boost::fast_pool_allocator is 305% times
>>>  faster than the regular one?
>>>
>>>  0: 61407861.18875794 allocations / second
>>>  1: 62565419.96725326 allocations / second
>>>  2: 175311265.1512761 allocations / second
>>>  3: 187319938.708916 allocations / second
>>>  1 / 0: 101.8850335381934% boost
>>>  2 / 1: 106.8499155187076% boost
>>>  3 / 0: 305.0422781101666% boost
>>>
>>>  Is Qt using a similar pool allocator?
>>
>>  This means the optimized boost::fast_allocator is 470% times faster than
>>  the system "operator new":
>>
>>  0: 37334468.30116969 allocations / second (operator new)
>>  1: 58554420.18534816 allocations / second (boost::pool_allocator)
>>  2: 60072218.82146717 allocations / second (boost::pool_allocator)
>>  3: 164895686.9884111 allocations / second (boost::fast_pool_allocator)
>>  4: 175697519.1510296 allocations / second (boost::fast_pool_allocator)
>>  2 / 1: 102.5921162421463% boost
>>  4 / 3: 106.550706304027% boost
>>  4 / 0: 470.6040480708413% boost
>
> I just tried the "jemalloc" library and I get a 2576228000% speed boost
> compared to operator new:
>
> 0: 38816440.15979952 allocations / second
> 1: 62188319.91413037 allocations / second
> 2: 63819182.38692677 allocations / second
> 3: 174727730.5139267 allocations / second
> 4: 186025745.9632413 allocations / second
> 5: 1000000000000000 allocations / second
> 5 / 0: 2576228000% boost
> 5 / 1: 1608019000% boost
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From philippeb8 at gmail.com  Sat Jan  7 19:16:38 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Sat, 7 Jan 2017 13:16:38 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <1488741483812297@web5g.yandex.ru>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
	<761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
	<o4r7gg$5o6$1@blaine.gmane.org> <o4ra83$tnd$1@blaine.gmane.org>
	<1488741483812297@web5g.yandex.ru>
Message-ID: <o4rba2$q44$1@blaine.gmane.org>

On 01/07/2017 01:04 PM, Konstantin Tokarev wrote:
> Oh, looks like you are going to learn about lots of other wonderful memory allocators soon. There is no real need to keep us informed about each of them (I guess most of interested folks are already well-aware of them), but please make sure you've studied prior art thoroughly before designing your own things.

Ok but it's fairly easy to write a standard C++ wrapper class around 
this library and let root_ptr make use of it, killing 2 birds with one 
stone.

> 07.01.2017, 20:59, "Phil Bouchard" <philippeb8 at gmail.com>:
>> On 01/07/2017 12:11 PM, Phil Bouchard wrote:
>>
>> I just tried the "jemalloc" library and I get a 2576228000% speed boost
>> compared to operator new:
>>
>> 0: 38816440.15979952 allocations / second
>> 1: 62188319.91413037 allocations / second
>> 2: 63819182.38692677 allocations / second
>> 3: 174727730.5139267 allocations / second
>> 4: 186025745.9632413 allocations / second
>> 5: 1000000000000000 allocations / second
>> 5 / 0: 2576228000% boost
>> 5 / 1: 1608019000% boost
>> ,
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>




From philippeb8 at gmail.com  Sun Jan  8 02:23:57 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Sat, 7 Jan 2017 20:23:57 -0500
Subject: [Development] Proposal for "container-oriented deterministic
 memory manager"
In-Reply-To: <o4ra83$tnd$1@blaine.gmane.org>
References: <o3nf12$c5a$1@blaine.gmane.org>
	<CAHF0tEc3+2hWH7rTD0nKBL0oz6h0Hp5yuHspsP59cnds+wsH+A@mail.gmail.com>
	<o40blo$9l7$1@blaine.gmane.org> <2457362.z1HspnihMx@tjmaciei-mobl1>
	<o40ebu$hk0$1@blaine.gmane.org>
	<VI1PR02MB10065C4727CEE7E2F65064D58C680@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<o40fjj$9ki$1@blaine.gmane.org>
	<VI1PR02MB1006094852303E8BECF615A68C6B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<9daf085b-f365-f3a7-d3c2-9e19dfe3fe0d@gmail.com>
	<o4k50e$11q$1@blaine.gmane.org> <6788751483614176@web18j.yandex.ru>
	<8e2dd0c8-1d8b-e06c-edf0-99951a810bfc@gmail.com>
	<5d5cba42-7371-1ebb-082a-081171204af1@gmail.com>
	<24f08150-b680-a2a8-1c7b-e426bedebd2d@gmail.com>
	<6b5e1fd3-af67-f5c9-f84f-8f09cbd912e2@gmail.com>
	<761cedd3-bbee-0421-457b-66583335e2b0@gmail.com>
	<o4r7gg$5o6$1@blaine.gmane.org> <o4ra83$tnd$1@blaine.gmane.org>
Message-ID: <o4s4b8$51i$1@blaine.gmane.org>

On 01/07/2017 12:58 PM, Phil Bouchard wrote:
> On 01/07/2017 12:11 PM, Phil Bouchard wrote:
>> On 01/06/2017 10:37 PM, Phil Bouchard wrote:
>>> On 01/06/2017 08:05 PM, Phil Bouchard wrote:
>>>> On 01/06/2017 07:17 PM, Phil Bouchard wrote:
>>>>>
>>>>> Just to conclude I did try the attached benchmark and I get the
>>>>> following on a x86_64 @ 2.40 GHz:
>>>>>
>>>>> 0: 61331143.40263957 allocations / second
>>>>> 1: 63644162.93924019 allocations / second
>>>>> 2: 177628727.5388474 allocations / second
>>>>> 3: 179850939.5413082 allocations / second
>>>>> 1 / 0: 103.7713621632905% boost
>>>>> 2 / 1: 101.2510431354494% boost
>>>>>
>>>>> So the fast_pool_allocator is already pretty fast and I can only get a
>>>>> 1% speed boost by allocating big memory blocks.  So it doesn't look
>>>>> like
>>>>> there is any way to make the fast_pool_allocator any faster.
>>>>
>>>> Correction: I get a 11% speed boost with the -O3 flag:
>>>>
>>>> 0: 60387275.67636769 allocations / second
>>>> 1: 63133704.55951615 allocations / second
>>>> 2: 169169529.8609596 allocations / second
>>>> 3: 188535531.4062488 allocations / second
>>>> 1 / 0: 104.5480258090584% boost
>>>> 2 / 1: 111.447688931456% boost
>>>>
>>>> So I am not sure if this is worth the trouble.
>>>
>>> Did you know the optimized boost::fast_pool_allocator is 305% times
>>> faster than the regular one?
>>>
>>> 0: 61407861.18875794 allocations / second
>>> 1: 62565419.96725326 allocations / second
>>> 2: 175311265.1512761 allocations / second
>>> 3: 187319938.708916 allocations / second
>>> 1 / 0: 101.8850335381934% boost
>>> 2 / 1: 106.8499155187076% boost
>>> 3 / 0: 305.0422781101666% boost
>>>
>>> Is Qt using a similar pool allocator?
>>
>> This means the optimized boost::fast_allocator is 470% times faster than
>> the system "operator new":
>>
>> 0: 37334468.30116969 allocations / second (operator new)
>> 1: 58554420.18534816 allocations / second (boost::pool_allocator)
>> 2: 60072218.82146717 allocations / second (boost::pool_allocator)
>> 3: 164895686.9884111 allocations / second (boost::fast_pool_allocator)
>> 4: 175697519.1510296 allocations / second (boost::fast_pool_allocator)
>> 2 / 1: 102.5921162421463% boost
>> 4 / 3: 106.550706304027% boost
>> 4 / 0: 470.6040480708413% boost
>
> I just tried the "jemalloc" library and I get a 2576228000% speed boost
> compared to operator new:
>
> 0: 38816440.15979952 allocations / second
> 1: 62188319.91413037 allocations / second
> 2: 63819182.38692677 allocations / second
> 3: 174727730.5139267 allocations / second
> 4: 186025745.9632413 allocations / second
> 5: 1000000000000000 allocations / second
> 5 / 0: 2576228000% boost
> 5 / 1: 1608019000% boost

Sorry, false alarm.  I think I was misusing jemalloc.  Now 
boost::fast_pool_allocator is the winner with a 332% speed boost 
compared to the normal boost::pool_allocator:

0: inf allocations / second (no allocation)
1: 54435751.65974607 allocations / second (jemalloc)
2: 77056206.33802707 allocations / second (boost::pool_allocator)
3: 80152739.05955189 allocations / second (boost::pool_allocator)
4: 236036104.0824805 allocations / second (boost::fast_pool_allocator)
5: 256307733.3169296 allocations / second (boost::fast_pool_allocator)
5 / 2: 332.6243861429787% boost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 3919 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170107/49d53208/attachment.cpp>

From samuel.gaist at edeltech.ch  Sun Jan  8 23:43:35 2017
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Sun, 8 Jan 2017 23:43:35 +0100
Subject: [Development] Jira action buttons
Message-ID: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>

Hi,

Is there any rule/filter that are applied on the bug reports related to the actions made available ?

For example:

https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign, More

https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not enough info, Accept, Close

I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently because for both of them I only get the reduced set of buttons.


Thanks
Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170108/d50b8a8c/attachment.sig>

From alexander.blasche at qt.io  Mon Jan  9 09:21:52 2017
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Mon, 9 Jan 2017 08:21:52 +0000
Subject: [Development] Jira action buttons
In-Reply-To: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
References: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
Message-ID: <AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Samuel Gaist
> Sent: Sunday, 8 January 2017 23:44

> Is there any rule/filter that are applied on the bug reports related to the actions
> made available ?
> 
> For example:
> 
> https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign,
> More
> 
> https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not
> enough info, Accept, Close
> 
> I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate
> of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently
> because for both of them I only get the reduced set of buttons.

This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992.

--
Alex

From samuel.gaist at edeltech.ch  Mon Jan  9 09:27:11 2017
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Mon, 9 Jan 2017 09:27:11 +0100
Subject: [Development] Jira action buttons
In-Reply-To: <AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
	<AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <5159CC13-9E8A-4D67-B2AB-A290B21435E0@edeltech.ch>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170109/d135c5be/attachment.html>

From sean.harmer at kdab.com  Mon Jan  9 09:28:18 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 9 Jan 2017 08:28:18 +0000
Subject: [Development] Jira action buttons
In-Reply-To: <AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
	<AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <eed97c6f-9d3a-abcb-508b-03e4d561cafc@kdab.com>



On 09/01/2017 08:21, Alexander Blasche wrote:
> Hi,
>
>> -----Original Message-----
>> From: Development [mailto:development-
>> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Samuel Gaist
>> Sent: Sunday, 8 January 2017 23:44
>
>> Is there any rule/filter that are applied on the bug reports related to the actions
>> made available ?
>>
>> For example:
>>
>> https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign,
>> More
>>
>> https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not
>> enough info, Accept, Close
>>
>> I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate
>> of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently
>> because for both of them I only get the reduced set of buttons.
>
> This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992.

Hi Alex,

could you do the same for

https://bugreports.qt.io/browse/QTBUG-55824

and

https://bugreports.qt.io/browse/QTBUG-55825

please? I only have a reduced set of actions available.

Thanks,

Sean

>
> --
> Alex
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From edward.welbourne at qt.io  Mon Jan  9 13:43:42 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Mon, 9 Jan 2017 12:43:42 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>	<29088300.rDUCxivhrG@port-fma>
	<5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
Message-ID: <HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>

I observed:
>> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has
>> secular society shifted the day boundary to midnight in practice ?

Soroush replied:
> Indeed they do the simplification needed to adopt modern lifestyle.

OK, good - then we have an excuse to keep the simple model !

> As far as I know, modern lunar calendars being used in ME as official
> calendars, have loads of simplifications applied compared to the
> original calendars. The start of a month in Islamic calendar in Fiqh
> (regional calendar) is based on observing new moon (by unaided eye) in
> the sky. That's why Saudi Arabia sometimes celebrate end of Ramadan
> one day after Turkey, and one day before Iran. That's why number of
> days differ from a year to another.

All of which argues for us to support the simplified official version,
while making it possible for apps and user-communities to add in their
own implementations taking account of local quirks.

> Though, the start of the day is 00:00 in modern calendars. And number
> of days in months are fixed.

That, at least, is reassuring ;-)

> Anyway, the only country using lunar calendar (Saudi Arabia) just
> switched to solar system (Gregorian). But we have to support Islamic
> calendar (modern version) of course.

Indeed - even if it's not the official state calendar, there are folk
still using it who shall want their software to respect that.  We can
make that *possible*, even where we aren't going to do all of the
work ourselves ...

> My current implementation looks like KCalendarSystem with some
> differences. Calendar classes are subclassed from QAbstractCalendar,
> and have to implement several methods. I tried to make this class as
> generic as possible, there is no assumption on month days and number
> of months.

Sounds promising.  If you can push it to gerrit as a work in progress
(start the subject line of the commit message with "WIP: " and the
system shall know what you mean; you can also push to refs/drafts/dev to
make it a draft review, until you eventually push to refs/for/dev to
turn it into a "real" review), I'll take a look at it and we can discuss
more there (taking traffic off this list).

I was tidying up in our Wiki after wearing out my brain on Friday and
stumbled upon [0], a 2011 write-up of relevant ideas - written by John
Layt, who is the author of KCalendarSystem.  (Speaking of: if anyone is
in touch with him and can reach him other than via his @KDE e-mail,
which I've pinged, please do bring this discussion to his attention.)
It may be a source of some fruitful insights.

[0] https://wiki.qt.io/Qt-contributors-summit-2011-QDateTime

> I just finished adding new methods to QDate and it's working for
> Jalali Calendar.
>
> QDate d = QDate::currentDate();
> int gyear1 = d.year();  // 2017
> int gyear2 = d.year(QGregorianCalendar);  // 2017
> int jyear1 = d.year(QJalaliCalendar()); // 1395
> int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395

Nice.  I interpolate a missing () on the end of QGregorianCalendar().

> I didn't touch Gregorian calculations in QDate, just added more
> functions. Does removing static members count as an ABI change? I'm
> planning to move all the math out of QDate into QGregorianCalendar.

A static function is invisible to anything outside its own compilation
unit, so turning assorted static functions in qdatetime.cpp into methods
of QGregorianCalendar is entirely feasible.  You can even mess with
QDateTimePrivate - see the warning comment in qdatetime_p.h ;^>

Static members of a public class, however, have to stay (I suppose).
Not that you have to continue *using* them, if something else makes them
redundant ...

> About calendaring widgets, The widget obviously needs to keep
> information on what calendar system it uses. I think it's possible to
> add members to private API classes? After all it's **private** and
> there's only a pointer to private API class in main class. So it would
> be A[BP]I compatible I suppose.

Check for that warning comment, or a header-name ending _p.h - you can
get away with plenty of change there.

> And also we need to add some functions to main class:
>
>     void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString?
>     QAbstractCalendar* QDateEdit::calendar() const; // meh...

Those make sense.  Definitely pass QAbstractCalendar * to the setter;
otherwise, client code can't supply a custom calendar that's not known
to our abstract base class's method.  The advantage of an overload
taking QString is minor - it'll package a call to fromName - and I fear
it would add confusions, with folk expecting too much of it, or a
matching getter returning QString.

Please keep QDateEdit changes in a separate commit from QDateTime
changes; ideally, even separate the creation of QCalendarSystem's base
class (at least) from re-working QDateTime to break out
QGregorianCalendar.

> There is another issue: How do we add calendar localization to QLocale?

I don't know.  However, [1] may offer some insight; albeit [2] is
similar and says the plan outlined there was abandoned - two more finds
from Friday evening.  The latter links to a blog post, by John, from
2012 - as a hint to how old these are.

[1] https://wiki.qt.io/Locale_Support_in_Qt_5#QCalendar
[2] https://wiki.qt.io/Qt_5_ICU

	Eddy.


From bstottle at ford.com  Mon Jan  9 15:50:52 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Mon, 9 Jan 2017 14:50:52 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
Message-ID: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>

As the maintainer for the Qt Remote Objects (QtRO) playground project, I would like to officially request moving it from a playground project to a Qt project.  For now (Qt 5.9), I’d like to keep it as a Tech Preview, as there are some elements of the API we would still like to extend, and we’d certainly like to protect for changes based on additional feedback.

In a nutshell, Qt Remote Objects takes the mechanisms that Qt already provides for multithreaded processing (Queued connections, marshaling arguments) and extends them to allow QObjects to work across process and/or device boundaries.  It does this by allowing a Source object (with a full implementation of the Qt Properties, Signals and Slots) to be shared on the QtRO bus.  Replica versions of this object can be acquired, where QtRO handles sending any changes to the Source to all Replicas.  I think of the Replicas as “latent copies” of the original object.  This seems like a great extension to Qt, and based on discussions at the last Qt World Summit, one that is makes sense to have as an official Qt module.

From a maturity standpoint, it has been running as a playground project for several years now.  We have several platforms checked via our own CI, but would like to get coverage on all supported platforms and will certainly address any issues found.  Giuseppe D’Angelo was kind enough to add QtRO to the Qt LTS Coverity scans, and except for several issues tied to a copy of moc, it is in good shape.  It supports qmake docs, although the docs need some care and feeding (this is ok for a Tech Preview as I understand it).

If this request is well received, I do have one sub-request.  According to http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt, “the playground name needs to be changed to a descriptive Qt module or tool name.”  The current name is qtremoteobjects.  Are there issues keeping this name?

Thanks for your consideration,
Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170109/149cf863/attachment.html>

From oswald.buddenhagen at qt.io  Mon Jan  9 16:54:40 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Mon, 9 Jan 2017 16:54:40 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
Message-ID: <20170109155440.GB5981@troll08>

On Mon, Jan 09, 2017 at 02:50:52PM +0000, Stottlemyer, Brett (B.S.) wrote:
> As the maintainer for the Qt Remote Objects (QtRO) playground project,
> I would like to officially request moving it from a playground project
> to a Qt project. 
>
i had a quick look at the repo:
- there is still copy of moc's c++ parser in there. not much to do about
  it at this point, except that repc is mostly redundant with moc to
  start with.
  - why not make it an output mode of moc? or at least, it would seem
    sensible to make moc output an intermediate json file with the meta
    info it extracted, and still leave the code generation to repc -
    that would remove the double parsing, and always ensure consistency.
  - i see that repc creates qdatastream operators for q_enums & co. -
    that *really* seems like generic moc stuff.
  - please verify that improvements to moc and the meta type system have
    not obsoleted some repc functionality in the first place.
- was that promised discussion vs. qtsystems actually ever had?
- formalities:
  - lots of build system hacks for obsolete qt versions
  - lagging in coding style practice (replace foreach, other c++11
    stuff)


From bstottle at ford.com  Tue Jan 10 02:42:12 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Tue, 10 Jan 2017 01:42:12 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170109155440.GB5981@troll08>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170109155440.GB5981@troll08>
Message-ID: <F14A053F-6F74-4093-8003-89F4CDFD017E@ford.com>

On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:



>i had a quick look at the repo:
>- there is still copy of moc's c++ parser in there. not much to do about
>  it at this point, except that repc is mostly redundant with moc to
>  start with.

This is a direction I hadn’t really considered.  I don’t like duplicating
moc code, but my thought was to put repc into qtbase (if that would be
accepted.  Thiago?) and keep the rest of QtRO in a separate repository.

The primary job of repc is to generate QObject code, and the mkspecs add
those automatically for moc processing.  I.e, it takes the API definition,
in .rep format, and generates an asymmetric pair of files, one for the
Source and one for the Replica.

The processing of QObject code by repc to generate the .rep input file
format was added afterwards.  It allows existing Qt header files to be
used with QtRO with compile time checks.  We don’t use that feature much
internally, but others are.

>  - why not make it an output mode of moc? or at least, it would seem
>    sensible to make moc output an intermediate json file with the meta
>    info it extracted, and still leave the code generation to repc -
>    that would remove the double parsing, and always ensure consistency.

If you are willing to take the .rep format as a moc input (?) this might
work.  If your thought is to take a QObject header file as input, I’m not
sure it does.  As a concrete example, Q_PROPERTY on the Source side can be
CONSTANT, but on the Replica side it can’t (it can have a default value
which is then updated when the connection to the Source is established.)
This asymmetry seems like it would be very confusing if it was output by
moc.

>  - i see that repc creates qdatastream operators for q_enums & co. -
>    that *really* seems like generic moc stuff.

Only in certain cases.  It lets moc handle this if possible.  I’ll have to
look at this again, the intent was to let moc do as much as possible.

>  - please verify that improvements to moc and the meta type system have
>    not obsoleted some repc functionality in the first place.

Pretty sure that for the primary use case they don’t, but if you can point
me to specific enhancements to look at, that would be appreciated.

>- was that promised discussion vs. qtsystems actually ever had?

No, but I don’t remember promising to have the discussion.  I know there
was a proposal to look for commonality with web sockets.  That didn’t
happen either.  Are these blockers?

>- formalities:
>  - lots of build system hacks for obsolete qt versions

To be honest, Ossi, you see stuff instantly that I need to study in the
build system.  We can keep working on it, but patches would be welcomed.

>  - lagging in coding style practice (replace foreach, other c++11
>    stuff)

Yes, we have been on LTS, so there are necessary changes for 5.7+.  Are
these needed before feature freeze?  Or can they be addressed as we move
to 5.9?

Overall, I can’t quite tell from your response which items are nice to
have, need to have (by feature freeze) or need to have (by 5.9 release).
I’d appreciate clarification.

Thanks, and thanks for the review,
Brett

From daniel.pfeifer at mailbox.org  Tue Jan 10 10:26:25 2017
From: daniel.pfeifer at mailbox.org (Daniel Pfeifer)
Date: Tue, 10 Jan 2017 10:26:25 +0100 (CET)
Subject: [Development] Cloning version 5.6.2
Message-ID: <1330370654.16899.1484040385303@office.mailbox.org>

Hi,

Up until one month ago, the following worked to clone version 5.6.2:

> git clone --branch v5.6.2 git://code.qt.io/qt/qt5.git .
> ./init-repository --module-subset=essential,qtconnectivity,qtlocation,qtserialbus,qtserialport

It now fails with the following output:

```
+ git clone --branch 5.6.2 git://code.qt.io/qt/qtbase.git qtbase
Cloning into 'qtbase'...
fatal: Remote branch 5.6.2 not found in upstream origin
git clone --branch 5.6.2 git://code.qt.io/qt/qtbase.git qtbase exited with status 32768 at ./init-repository line 195.
	Qt::InitRepository::exe(Qt::InitRepository=HASH(0x229ac18), "git", "clone", "--branch", "5.6.2", "git://code.qt.io/qt/qtbase.git", "qtbase") called at ./init-repository line 486
	Qt::InitRepository::git_clone_one_submodule(Qt::InitRepository=HASH(0x229ac18), "qtbase", "qt/qtbase.git", "5.6.2") called at ./init-repository line 392
	Qt::InitRepository::git_clone_all_submodules(Qt::InitRepository=HASH(0x229ac18), "qt/qt5", 0, "essential", "qtconnectivity", "qtlocation", "qtserialbus", "qtserialport") called at ./init-repository line 596
	Qt::InitRepository::run(Qt::InitRepository=HASH(0x229ac18)) called at ./init-repository line 607
```

If I pass `--branch v5.6.2` to `init-repository`, I get the same error.

If I call `git reset --hard 71ed40b0ace06eaa54ec41b2ad622911a94643be`, just
before calling `init-repository` (without branch), the submodules are cloned
with `--no-checkout`, effectively giving me the top development versions.

If I call `git reset --hard 71ed40b0ace06eaa54ec41b2ad622911a94643be` and then
call `init-repository` with the branch option, the submodules are cloned
with `--branch 5.6`, effectively giving me the top development of the 5.6
branch.

How can I get the exact tagged version v5.6.2?

cheers, Daniel


From sean.harmer at kdab.com  Tue Jan 10 10:45:07 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 10 Jan 2017 09:45:07 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <1615629.r76N4iF3NL@cartman>

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
> 
> 
> Brief "update": dev is still blocked.
> 
> 
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
> 
> 
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
> 
> 
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
> 
> 
> So either
> 
> 
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
> 
> 
> or
> 
> 
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
> 
> 
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
> 
> 
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
> 
> 
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
> 
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> I wanted to give a quick update on the state of the dev branch in the CI:
> 
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
> 
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
> 
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
> 
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
> 
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
> 
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
> 
> 
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
> 
> 
> 
> Simon

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From Simon.Hausmann at qt.io  Tue Jan 10 10:49:29 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 10 Jan 2017 09:49:29 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <1615629.r76N4iF3NL@cartman>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<1615629.r76N4iF3NL@cartman>
Message-ID: <VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


as far as I can tell this is not resolved yet. It appears that the macOS 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed up.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Tuesday, January 10, 2017 10:45:07 AM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
>
>
> Brief "update": dev is still blocked.
>
>
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
>
>
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
>
>
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
>
>
> So either
>
>
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
>
>
> or
>
>
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
>
>
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
>
>
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
>
>
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
>
>
>
>
> Simon
>
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
>
>
> Hi,
>
> I wanted to give a quick update on the state of the dev branch in the CI:
>
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
>
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
>
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
>
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
>
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
>
>
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
>
>
>
> Simon

--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/c339eaed/attachment.html>

From Simon.Hausmann at qt.io  Tue Jan 10 11:42:33 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 10 Jan 2017 10:42:33 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<1615629.r76N4iF3NL@cartman>,
	<VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB1006A50C1D50E57CF7C12E228C670@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


I just had another chat with Liang about this situation. We can't get a newer qtbase into qt5.git because tests in declarative fail, some of it also due to a newer qtbase (and the qurl changes). So the path we would propose is


    (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that brought us here.

    (2) We either get fixes or blacklist-additions into the corresponding modules, WHILE the rest of development of modules in Qt outside qtbase with the dev branch can resume.

    (3) RHEL 7.2 is re-added to the CI when it passes tests.


We need agreement and help from the CI team to do that.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Tuesday, January 10, 2017 10:49:29 AM
To: Sean Harmer; development at qt-project.org
Subject: Re: [Development] State of dev branch in CI


Hi,


as far as I can tell this is not resolved yet. It appears that the macOS 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed up.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Tuesday, January 10, 2017 10:45:07 AM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
>
>
> Brief "update": dev is still blocked.
>
>
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
>
>
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
>
>
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
>
>
> So either
>
>
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
>
>
> or
>
>
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
>
>
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
>
>
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
>
>
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
>
>
>
>
> Simon
>
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
>
>
> Hi,
>
> I wanted to give a quick update on the state of the dev branch in the CI:
>
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
>
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
>
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
>
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
>
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
>
>
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
>
>
>
> Simon

--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/c6539b19/attachment.html>

From tony.sarajarvi at qt.io  Tue Jan 10 12:31:10 2017
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Tue, 10 Jan 2017 11:31:10 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB1006A50C1D50E57CF7C12E228C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<1615629.r76N4iF3NL@cartman>,
	<VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB1006A50C1D50E57CF7C12E228C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi,

Sounds good to me. I'll proceed with that.
Funny that the only platform we've managed to get in during the last half a year or year is immediately causing problems so that we have to remove it ;)

-Tony

From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: Tuesday, January 10, 2017 12:43 PM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI


Hi,



I just had another chat with Liang about this situation. We can't get a newer qtbase into qt5.git because tests in declarative fail, some of it also due to a newer qtbase (and the qurl changes). So the path we would propose is



    (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that brought us here.

    (2) We either get fixes or blacklist-additions into the corresponding modules, WHILE the rest of development of modules in Qt outside qtbase with the dev branch can resume.

    (3) RHEL 7.2 is re-added to the CI when it passes tests.



We need agreement and help from the CI team to do that.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>
Sent: Tuesday, January 10, 2017 10:49:29 AM
To: Sean Harmer; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI


Hi,



as far as I can tell this is not resolved yet. It appears that the macOS 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed up.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>>
Sent: Tuesday, January 10, 2017 10:45:07 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
>
>
> Brief "update": dev is still blocked.
>
>
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
>
>
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
>
>
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
>
>
> So either
>
>
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
>
>
> or
>
>
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
>
>
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
>
>
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
>
>
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
>
>
>
>
> Simon
>
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
>
>
> Hi,
>
> I wanted to give a quick update on the state of the dev branch in the CI:
>
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
>
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
>
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
>
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
>
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
>
>
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
>
>
>
> Simon

--
Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/ddaa64d7/attachment.html>

From Simon.Hausmann at qt.io  Tue Jan 10 12:37:56 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 10 Jan 2017 11:37:56 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<1615629.r76N4iF3NL@cartman>,
	<VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB1006A50C1D50E57CF7C12E228C670@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB10064BA5091D8F07D409BF178C670@VI1PR02MB1006.eurprd02.prod.outlook.com>


Thanks.


Regarding RHEL 7.2 I think there were or are two mistakes:


    (1) When it was added to 5.8 I understand that there was a waiting period until some related fixes propagated to dev, before it could be added there. Between _that_ point in time and now, several months passed. This would less likely have happened if it had been followed up quickly, i.e. monitor and push the fixes through into dev and right after that add RHEL 7.2 to dev.


    (2) I really wish the placement of the configuration files for the platforms being moved to qt5.git had a high priority, because it prevents situations like these where the R&D organization, the project, contributors and partners in the ecosystem are blocked from work for several days. As such a configuration change went into the CI last Thursday and the problem was noticed last Thursday, the change _remained_ in there until now we have confirmation that it is going to get reverted. If this had been part of qt5.git the change would not go live until all the issues are fixed, while nobody else is blocked in their work.



Simon

________________________________
From: Tony Sarajärvi
Sent: Tuesday, January 10, 2017 12:31:10 PM
To: Simon Hausmann; development at qt-project.org
Subject: RE: [Development] State of dev branch in CI

Hi,

Sounds good to me. I’ll proceed with that.
Funny that the only platform we’ve managed to get in during the last half a year or year is immediately causing problems so that we have to remove it ;)

-Tony

From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: Tuesday, January 10, 2017 12:43 PM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI


Hi,



I just had another chat with Liang about this situation. We can't get a newer qtbase into qt5.git because tests in declarative fail, some of it also due to a newer qtbase (and the qurl changes). So the path we would propose is



    (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that brought us here.

    (2) We either get fixes or blacklist-additions into the corresponding modules, WHILE the rest of development of modules in Qt outside qtbase with the dev branch can resume.

    (3) RHEL 7.2 is re-added to the CI when it passes tests.



We need agreement and help from the CI team to do that.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>
Sent: Tuesday, January 10, 2017 10:49:29 AM
To: Sean Harmer; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI


Hi,



as far as I can tell this is not resolved yet. It appears that the macOS 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed up.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>>
Sent: Tuesday, January 10, 2017 10:45:07 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
>
>
> Brief "update": dev is still blocked.
>
>
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
>
>
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
>
>
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
>
>
> So either
>
>
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
>
>
> or
>
>
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
>
>
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
>
>
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
>
>
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
>
>
>
>
> Simon
>
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
>
>
> Hi,
>
> I wanted to give a quick update on the state of the dev branch in the CI:
>
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
>
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
>
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
>
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
>
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
>
>
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
>
>
>
> Simon

--
Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/fc95ec0b/attachment.html>

From edward.welbourne at qt.io  Tue Jan 10 13:03:47 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 10 Jan 2017 12:03:47 +0000
Subject: [Development] Cloning version 5.6.2
In-Reply-To: <1330370654.16899.1484040385303@office.mailbox.org>
References: <1330370654.16899.1484040385303@office.mailbox.org>
Message-ID: <HE1PR0202MB26838D570C9F4FEF8F0D148987670@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Daniel Pfeifer wrote:
> Up until one month ago, the following worked to clone version 5.6.2:
>
> git clone --branch v5.6.2 git://code.qt.io/qt/qt5.git .
> ./init-repository --module-subset=essential,qtconnectivity,qtlocation,qtserialbus,qtserialport
[...]
> It now fails with the following output:
>
> + git clone --branch 5.6.2 git://code.qt.io/qt/qtbase.git qtbase
> Cloning into 'qtbase'...
> fatal: Remote branch 5.6.2 not found in upstream origin

That is because the M.m.p branch is always transient and goes away when
the vM.m.p tag gets set; so the branch is gone.

> If I pass `--branch v5.6.2` to `init-repository`, I get the same error.

v5.6.2 is a tag, not a branch.
The branch was 5.6.2

> How can I get the exact tagged version v5.6.2?

git clone without specifying --branch (or with any branch you like, it
doesn't matter) then

git checkout v5.6.2

	Eddy.


From oswald.buddenhagen at qt.io  Tue Jan 10 13:11:27 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Tue, 10 Jan 2017 13:11:27 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <F14A053F-6F74-4093-8003-89F4CDFD017E@ford.com>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170109155440.GB5981@troll08>
	<F14A053F-6F74-4093-8003-89F4CDFD017E@ford.com>
Message-ID: <20170110121127.GC12254@troll08>

On Tue, Jan 10, 2017 at 01:42:12AM +0000, Stottlemyer, Brett (B.S.) wrote:
> The processing of QObject code by repc to generate the .rep input file
> format was added afterwards.  It allows existing Qt header files to be
> used with QtRO with compile time checks.  We don’t use that feature much
> internally, but others are.
> 
you mostly lost me here, because i just don't know enough about the data
flows of the qtro build system, so it would be helpful if you outlined
that.

but my naive understanding of rpc implementations is that you actually
want to create some idl (is this what .rep is about?) from the c++, and
in a later step compile that into stubs and skeletons. the former sounds
like a task moc could do as a side effect, while the latter is for repc.

as it happens, we actually have that in qtbase already, in form of the
dbus tools. and as expected, qdbuscpp2xml is yet another tool that pulls
in moc sources ...

and obviously, moc itself could also be split into two tools.
or, the moc frontend could be replaced with clang, for which code
actually already exists, but wasn't deemed quite ready for prime time
yet. maybe we could actually pull that off now that qdoc is switching
to clang as well.

soliciting input primarily from olivier and thiago here ...

> >  - please verify that improvements to moc and the meta type system have
> >    not obsoleted some repc functionality in the first place.
> 
> Pretty sure that for the primary use case they don’t, but if you can point
> me to specific enhancements to look at, that would be appreciated.
> 
i'll leave it for others to comment on.

> Overall, I can’t quite tell from your response which items are nice to
> have, need to have (by feature freeze) or need to have (by 5.9
> release).  I’d appreciate clarification.
> 
it's in the interest of the qt project to unify the offering as much as
possible, minimizing redundant apis and implementations. the former are
by definition before-freeze items, while the latter are as far as they
cannot be done without impacting the api. (api being used in the
broadest sense here, so tools are obviously also covered.)


From oswald.buddenhagen at qt.io  Tue Jan 10 13:15:14 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Tue, 10 Jan 2017 13:15:14 +0100
Subject: [Development] Cloning version 5.6.2
In-Reply-To: <HE1PR0202MB26838D570C9F4FEF8F0D148987670@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <1330370654.16899.1484040385303@office.mailbox.org>
	<HE1PR0202MB26838D570C9F4FEF8F0D148987670@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <20170110121514.GD12254@troll08>

On Tue, Jan 10, 2017 at 12:03:47PM +0000, Edward Welbourne wrote:
> Daniel Pfeifer wrote:
> > How can I get the exact tagged version v5.6.2?
> 
> git clone without specifying --branch (or with any branch you like, it
> doesn't matter) then
> 
> git checkout v5.6.2
> 
that's a bit misleading. that checkout command should be done on the qt5
repository. then just run init-repository, and you'll already get the
exact tagged checkout. explicitly checking out the tag in each
sub-repository should have exactly zero effect at this point.


From Simon.Hausmann at qt.io  Tue Jan 10 13:45:17 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 10 Jan 2017 12:45:17 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB100634FC62591A02D206B5428C620@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<1615629.r76N4iF3NL@cartman>,
	<VI1PR02MB10068A526F91AC84A819D8F78C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB1006A50C1D50E57CF7C12E228C670@VI1PR02MB1006.eurprd02.prod.outlook.com>,
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB10061678952DEF0823C59A308C670@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


As a heads-up to everyone: Tony's changes are in effect now and staging of changes that target the dev branch for modules outside of qtbase should work again.



Simon

________________________________
From: Tony Sarajärvi
Sent: Tuesday, January 10, 2017 12:31:10 PM
To: Simon Hausmann; development at qt-project.org
Subject: RE: [Development] State of dev branch in CI

Hi,

Sounds good to me. I’ll proceed with that.
Funny that the only platform we’ve managed to get in during the last half a year or year is immediately causing problems so that we have to remove it ;)

-Tony

From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: Tuesday, January 10, 2017 12:43 PM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI


Hi,



I just had another chat with Liang about this situation. We can't get a newer qtbase into qt5.git because tests in declarative fail, some of it also due to a newer qtbase (and the qurl changes). So the path we would propose is



    (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that brought us here.

    (2) We either get fixes or blacklist-additions into the corresponding modules, WHILE the rest of development of modules in Qt outside qtbase with the dev branch can resume.

    (3) RHEL 7.2 is re-added to the CI when it passes tests.



We need agreement and help from the CI team to do that.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>
Sent: Tuesday, January 10, 2017 10:49:29 AM
To: Sean Harmer; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI


Hi,



as far as I can tell this is not resolved yet. It appears that the macOS 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed up.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>>
Sent: Tuesday, January 10, 2017 10:45:07 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
>
>
> Brief "update": dev is still blocked.
>
>
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
>
>
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
>
>
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
>
>
> So either
>
>
>     (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
>
>
> or
>
>
>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
>
>
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
>
>
>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
>
>
>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
>
>
>
>
> Simon
>
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>>
> on behalf of Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
>
>
> Hi,
>
> I wanted to give a quick update on the state of the dev branch in the CI:
>
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
>
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
>
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
>
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
>
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
>
>
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
>
>
>
> Simon

--
Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/2cc9fe08/attachment.html>

From sean.harmer at kdab.com  Tue Jan 10 14:06:46 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 10 Jan 2017 13:06:46 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB10061678952DEF0823C59A308C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB10061678952DEF0823C59A308C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <2821381.nzqEOyAgGH@cartman>

Thanks to all involved in resolving this!

Sean

On Tuesday 10 January 2017 12:45:17 Simon Hausmann wrote:
> Hi,
> 
> 
> As a heads-up to everyone: Tony's changes are in effect now and staging of
> changes that target the dev branch for modules outside of qtbase should
> work again.
> 
> 
> 
> Simon
> 
> ________________________________
> From: Tony Sarajärvi
> Sent: Tuesday, January 10, 2017 12:31:10 PM
> To: Simon Hausmann; development at qt-project.org
> Subject: RE: [Development] State of dev branch in CI
> 
> Hi,
> 
> Sounds good to me. I’ll proceed with that.
> Funny that the only platform we’ve managed to get in during the last half a
> year or year is immediately causing problems so that we have to remove it
> ;)
> 
> -Tony
> 
> From: Development
> [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf
> Of Simon Hausmann Sent: Tuesday, January 10, 2017 12:43 PM
> To: development at qt-project.org
> Subject: Re: [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> 
> 
> I just had another chat with Liang about this situation. We can't get a
> newer qtbase into qt5.git because tests in declarative fail, some of it
> also due to a newer qtbase (and the qurl changes). So the path we would
> propose is
> 
> 
> 
>     (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that
> brought us here.
> 
>     (2) We either get fixes or blacklist-additions into the corresponding
> modules, WHILE the rest of development of modules in Qt outside qtbase with
> the dev branch can resume.
> 
>     (3) RHEL 7.2 is re-added to the CI when it passes tests.
> 
> 
> 
> We need agreement and help from the CI team to do that.
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann
> <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Tuesday, January
> 10, 2017 10:49:29 AM
> To: Sean Harmer;
> development at qt-project.org<mailto:development at qt-project.org> Subject: Re:
> [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> 
> 
> as far as I can tell this is not resolved yet. It appears that the macOS
> 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed
> up.
> 
> 
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer
> <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>> Sent: Tuesday, January
> 10, 2017 10:45:07 AM
> To: development at qt-project.org<mailto:development at qt-project.org>
> Subject: Re: [Development] State of dev branch in CI
> 
> Hi Simon,
> 
> is this resolved yet?
> 
> Cheers,
> 
> Sean
> 
> On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> > Hi,
> > 
> > 
> > Brief "update": dev is still blocked.
> > 
> > 
> > The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to
> > be due to the removal of macOS 10.9 support, while the CI still builds
> > with 10.9.
> > 
> > 
> > We can't bring qt5.git up-to-date with a newer qtbase that includes the
> > pcre fix, because the macOS 10.9 drop
> > (a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre
> > fix.
> > 
> > 
> > A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of
> > the 10.9 drop until the CI "supports" it was rejected.
> > 
> > 
> > So either
> > 
> >     (a) the temporary reversal gets approved instead of rejected. Then
> >     over
> > 
> > the remaining weekend we could try to get a qt5.git update through with
> > the
> > pcre fix to unblock dev.
> > 
> > 
> > or
> > 
> >     (b) the CI removes 10.9 support and moves the features the 10.9 tests
> > 
> > (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> > update through that includes the pcre fix.
> > 
> > 
> > Differently put, there are two things blocking Qt dev branch development
> > 
> > outside of qtbase:
> >     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> > 
> > alternatively RHEL 7.2 temporary reversal in the CI.
> > 
> >     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> > 
> > proceed) or CI changes as mentioned in (b).
> > 
> > 
> > 
> > 
> > Simon
> > 
> > ________________________________
> > From: Development
> > <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:developme
> > nt-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon
> > Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent:
> > Thursday, January 5, 2017 8:50:52 PM
> > To: development
> > Subject: [Development] State of dev branch in CI
> > 
> > 
> > Hi,
> > 
> > I wanted to give a quick update on the state of the dev branch in the CI:
> > 
> > Currently any changes to any module outside of qtbase targeting the dev
> > branch will fail to pass the build stage in the CI.
> > 
> > Recently RHEL 7.2 was added to dev. When that was tested - back in fall
> > last year - all was fine. Then some configure options of qtbase were
> > changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2
> > (longer story but basically because of our binary packages). Earlier this
> > week the change in the CI to add RHEL 7.2 to dev was taken into
> > production and immediately broke the build of all modules in dev because
> > -qt-pcre was not a valid configure parameter anymore and without qtbase
> > nothing else builds. As a consequence the CI changes were reverted.
> > 
> > Meanwhile the qtbase configure parameters were fixed and support for
> > -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> > in the dev branch compiles on RHEL 7.2.
> > 
> > Unfortunately all other modules are built against qtbase from qt5.git,
> > which doesn't understand -qt-pcre yet (wants pcre2). Therefore all
> > modules other than qtbase are broken in dev.
> > 
> > An update of qt5.git with a newer qtbase is scheduled, but unfortunately
> > it
> > won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
> > 
> > There are different options for solving this. One would be to revert the
> > CI
> > change. Another would be to fix the above bug and get the qt5 change
> > through.
> > 
> > 
> > The right solution to prevent these types of situations in the future is
> > to
> > have these platform configs inside qt5.git, not in the CI. Unfortunately
> > that is not a priority yet.
> > 
> > 
> > 
> > Simon
> 
> --
> Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> |
> Managing Director UK KDAB (UK) Ltd, a KDAB Group company
> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From rjvbertin at gmail.com  Tue Jan 10 15:21:07 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 10 Jan 2017 15:21:07 +0100
Subject: [Development] CMake: inconsistent behaviour of find_package(Qt5
 <minversion> <components>)
Message-ID: <1686366.VsVgM8QAFa@portia.local>

Hi,

I started working with a project that shows what I think is inconsistent `find_package(Qt5 ...)` behaviour. In its stock form, the general Qt5 component isn't found while the rest is except for 1 evident exception:

find_package(Qt5 5.3.0 REQUIRED
    COMPONENTS
        Core Gui Network PrintSupport Svg Test Widgets Xml)
find_package(Qt5 5.3.0 QUIET
    COMPONENTS
        Declarative Quick Sql ...)
--->
 * Qt5Core
 * Qt5Gui
 * Qt5Network
 * Qt5PrintSupport
 * Qt5Svg
 * Qt5Test
 * Qt5Widgets
 * Qt5Xml
 * Qt5Qml (required version >= 5.7.1)
 * Qt5Sql
<snip>
-- The following REQUIRED packages have not been found:

 * Qt5 (required version >= 5.3.0)


When I remove "Declarative" from the 2nd find_package call above, all of a sudden Qt5 is found. When I remove the REQUIRED keyword from the 1st call (but not "Declarative"), Qt5 is still not found but I only get a warning.

The components requested in the 2nd call are all set as RECOMMENDED or OPTIONAL in subsequent statements, so the proper way to handle this (assuming the project wants to continue supporting QtQuick1) appears to be to add a dedicated

find_package(Qt5Declarative 5.3.0 QUIET)


All in all this seems inconsistent and at least counterintuitive behaviour to me (which took me a while to figure out). That 2nd, QUIET find_package() doesn't set the REQUIRED property, and also shouldn't override the status of a package that has already been found (not as long as it finds the same installation).

Is this something that can be rectified in Qt's cmake modules, or is it another CMake issue?

R.


From sh at theharmers.co.uk  Tue Jan 10 20:26:56 2017
From: sh at theharmers.co.uk (Sean Harmer)
Date: Tue, 10 Jan 2017 19:26:56 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <2821381.nzqEOyAgGH@cartman>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB10061678952DEF0823C59A308C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<2821381.nzqEOyAgGH@cartman>
Message-ID: <b7b17c2c-f3fa-3901-5a7f-08b7bf72ab59@theharmers.co.uk>

Hi,

seems something is still not happy in CI land.

https://codereview.qt-project.org/#/c/181832/

Could someone take a look please?

Thanks,

Sean

On 10/01/2017 13:06, Sean Harmer wrote:
> Thanks to all involved in resolving this!
>
> Sean
>
> On Tuesday 10 January 2017 12:45:17 Simon Hausmann wrote:
>> Hi,
>>
>>
>> As a heads-up to everyone: Tony's changes are in effect now and staging of
>> changes that target the dev branch for modules outside of qtbase should
>> work again.
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Tony Sarajärvi
>> Sent: Tuesday, January 10, 2017 12:31:10 PM
>> To: Simon Hausmann; development at qt-project.org
>> Subject: RE: [Development] State of dev branch in CI
>>
>> Hi,
>>
>> Sounds good to me. I’ll proceed with that.
>> Funny that the only platform we’ve managed to get in during the last half a
>> year or year is immediately causing problems so that we have to remove it
>> ;)
>>
>> -Tony
>>
>> From: Development
>> [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf
>> Of Simon Hausmann Sent: Tuesday, January 10, 2017 12:43 PM
>> To: development at qt-project.org
>> Subject: Re: [Development] State of dev branch in CI
>>
>>
>> Hi,
>>
>>
>>
>> I just had another chat with Liang about this situation. We can't get a
>> newer qtbase into qt5.git because tests in declarative fail, some of it
>> also due to a newer qtbase (and the qurl changes). So the path we would
>> propose is
>>
>>
>>
>>     (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that
>> brought us here.
>>
>>     (2) We either get fixes or blacklist-additions into the corresponding
>> modules, WHILE the rest of development of modules in Qt outside qtbase with
>> the dev branch can resume.
>>
>>     (3) RHEL 7.2 is re-added to the CI when it passes tests.
>>
>>
>>
>> We need agreement and help from the CI team to do that.
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Development
>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
>> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann
>> <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Tuesday, January
>> 10, 2017 10:49:29 AM
>> To: Sean Harmer;
>> development at qt-project.org<mailto:development at qt-project.org> Subject: Re:
>> [Development] State of dev branch in CI
>>
>>
>> Hi,
>>
>>
>>
>> as far as I can tell this is not resolved yet. It appears that the macOS
>> 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed
>> up.
>>
>>
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Development
>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
>> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer
>> <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>> Sent: Tuesday, January
>> 10, 2017 10:45:07 AM
>> To: development at qt-project.org<mailto:development at qt-project.org>
>> Subject: Re: [Development] State of dev branch in CI
>>
>> Hi Simon,
>>
>> is this resolved yet?
>>
>> Cheers,
>>
>> Sean
>>
>> On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
>>> Hi,
>>>
>>>
>>> Brief "update": dev is still blocked.
>>>
>>>
>>> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to
>>> be due to the removal of macOS 10.9 support, while the CI still builds
>>> with 10.9.
>>>
>>>
>>> We can't bring qt5.git up-to-date with a newer qtbase that includes the
>>> pcre fix, because the macOS 10.9 drop
>>> (a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre
>>> fix.
>>>
>>>
>>> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of
>>> the 10.9 drop until the CI "supports" it was rejected.
>>>
>>>
>>> So either
>>>
>>>     (a) the temporary reversal gets approved instead of rejected. Then
>>>     over
>>>
>>> the remaining weekend we could try to get a qt5.git update through with
>>> the
>>> pcre fix to unblock dev.
>>>
>>>
>>> or
>>>
>>>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
>>>
>>> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
>>> update through that includes the pcre fix.
>>>
>>>
>>> Differently put, there are two things blocking Qt dev branch development
>>>
>>> outside of qtbase:
>>>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
>>>
>>> alternatively RHEL 7.2 temporary reversal in the CI.
>>>
>>>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
>>>
>>> proceed) or CI changes as mentioned in (b).
>>>
>>>
>>>
>>>
>>> Simon
>>>
>>> ________________________________
>>> From: Development
>>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:developme
>>> nt-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon
>>> Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent:
>>> Thursday, January 5, 2017 8:50:52 PM
>>> To: development
>>> Subject: [Development] State of dev branch in CI
>>>
>>>
>>> Hi,
>>>
>>> I wanted to give a quick update on the state of the dev branch in the CI:
>>>
>>> Currently any changes to any module outside of qtbase targeting the dev
>>> branch will fail to pass the build stage in the CI.
>>>
>>> Recently RHEL 7.2 was added to dev. When that was tested - back in fall
>>> last year - all was fine. Then some configure options of qtbase were
>>> changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2
>>> (longer story but basically because of our binary packages). Earlier this
>>> week the change in the CI to add RHEL 7.2 to dev was taken into
>>> production and immediately broke the build of all modules in dev because
>>> -qt-pcre was not a valid configure parameter anymore and without qtbase
>>> nothing else builds. As a consequence the CI changes were reverted.
>>>
>>> Meanwhile the qtbase configure parameters were fixed and support for
>>> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
>>> in the dev branch compiles on RHEL 7.2.
>>>
>>> Unfortunately all other modules are built against qtbase from qt5.git,
>>> which doesn't understand -qt-pcre yet (wants pcre2). Therefore all
>>> modules other than qtbase are broken in dev.
>>>
>>> An update of qt5.git with a newer qtbase is scheduled, but unfortunately
>>> it
>>> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>>>
>>> There are different options for solving this. One would be to revert the
>>> CI
>>> change. Another would be to fix the above bug and get the qt5 change
>>> through.
>>>
>>>
>>> The right solution to prevent these types of situations in the future is
>>> to
>>> have these platform configs inside qt5.git, not in the CI. Unfortunately
>>> that is not a priority yet.
>>>
>>>
>>>
>>> Simon
>>
>> --
>> Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> |
>> Managing Director UK KDAB (UK) Ltd, a KDAB Group company
>> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
>> Mobile: +44 (0)7545 140604
>> KDAB - Qt Experts
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org<mailto:Development at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/development
>


From Simon.Hausmann at qt.io  Tue Jan 10 21:52:01 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 10 Jan 2017 20:52:01 +0000
Subject: [Development] State of dev branch in CI
In-Reply-To: <b7b17c2c-f3fa-3901-5a7f-08b7bf72ab59@theharmers.co.uk>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB10061678952DEF0823C59A308C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<2821381.nzqEOyAgGH@cartman>,
	<b7b17c2c-f3fa-3901-5a7f-08b7bf72ab59@theharmers.co.uk>
Message-ID: <DB5PR02MB0998F4994DF09C300E0C2B718C670@DB5PR02MB0998.eurprd02.prod.outlook.com>

Hi,


I've applied a workaround and created https://bugreports.qt.io/browse/QTQAINFRA-1072 to track this.




Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sh at theharmers.co.uk>
Sent: Tuesday, January 10, 2017 8:26:56 PM
To: development at qt-project.org
Subject: Re: [Development] State of dev branch in CI

Hi,

seems something is still not happy in CI land.

https://codereview.qt-project.org/#/c/181832/

Could someone take a look please?

Thanks,

Sean

On 10/01/2017 13:06, Sean Harmer wrote:
> Thanks to all involved in resolving this!
>
> Sean
>
> On Tuesday 10 January 2017 12:45:17 Simon Hausmann wrote:
>> Hi,
>>
>>
>> As a heads-up to everyone: Tony's changes are in effect now and staging of
>> changes that target the dev branch for modules outside of qtbase should
>> work again.
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Tony Sarajärvi
>> Sent: Tuesday, January 10, 2017 12:31:10 PM
>> To: Simon Hausmann; development at qt-project.org
>> Subject: RE: [Development] State of dev branch in CI
>>
>> Hi,
>>
>> Sounds good to me. I’ll proceed with that.
>> Funny that the only platform we’ve managed to get in during the last half a
>> year or year is immediately causing problems so that we have to remove it
>> ;)
>>
>> -Tony
>>
>> From: Development
>> [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf
>> Of Simon Hausmann Sent: Tuesday, January 10, 2017 12:43 PM
>> To: development at qt-project.org
>> Subject: Re: [Development] State of dev branch in CI
>>
>>
>> Hi,
>>
>>
>>
>> I just had another chat with Liang about this situation. We can't get a
>> newer qtbase into qt5.git because tests in declarative fail, some of it
>> also due to a newer qtbase (and the qurl changes). So the path we would
>> propose is
>>
>>
>>
>>     (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that
>> brought us here.
>>
>>     (2) We either get fixes or blacklist-additions into the corresponding
>> modules, WHILE the rest of development of modules in Qt outside qtbase with
>> the dev branch can resume.
>>
>>     (3) RHEL 7.2 is re-added to the CI when it passes tests.
>>
>>
>>
>> We need agreement and help from the CI team to do that.
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Development
>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
>> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon Hausmann
>> <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent: Tuesday, January
>> 10, 2017 10:49:29 AM
>> To: Sean Harmer;
>> development at qt-project.org<mailto:development at qt-project.org> Subject: Re:
>> [Development] State of dev branch in CI
>>
>>
>> Hi,
>>
>>
>>
>> as far as I can tell this is not resolved yet. It appears that the macOS
>> 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed
>> up.
>>
>>
>>
>>
>>
>> Simon
>>
>> ________________________________
>> From: Development
>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
>> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Sean Harmer
>> <sean.harmer at kdab.com<mailto:sean.harmer at kdab.com>> Sent: Tuesday, January
>> 10, 2017 10:45:07 AM
>> To: development at qt-project.org<mailto:development at qt-project.org>
>> Subject: Re: [Development] State of dev branch in CI
>>
>> Hi Simon,
>>
>> is this resolved yet?
>>
>> Cheers,
>>
>> Sean
>>
>> On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
>>> Hi,
>>>
>>>
>>> Brief "update": dev is still blocked.
>>>
>>>
>>> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to
>>> be due to the removal of macOS 10.9 support, while the CI still builds
>>> with 10.9.
>>>
>>>
>>> We can't bring qt5.git up-to-date with a newer qtbase that includes the
>>> pcre fix, because the macOS 10.9 drop
>>> (a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre
>>> fix.
>>>
>>>
>>> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of
>>> the 10.9 drop until the CI "supports" it was rejected.
>>>
>>>
>>> So either
>>>
>>>     (a) the temporary reversal gets approved instead of rejected. Then
>>>     over
>>>
>>> the remaining weekend we could try to get a qt5.git update through with
>>> the
>>> pcre fix to unblock dev.
>>>
>>>
>>> or
>>>
>>>     (b) the CI removes 10.9 support and moves the features the 10.9 tests
>>>
>>> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
>>> update through that includes the pcre fix.
>>>
>>>
>>> Differently put, there are two things blocking Qt dev branch development
>>>
>>> outside of qtbase:
>>>     (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
>>>
>>> alternatively RHEL 7.2 temporary reversal in the CI.
>>>
>>>     (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
>>>
>>> proceed) or CI changes as mentioned in (b).
>>>
>>>
>>>
>>>
>>> Simon
>>>
>>> ________________________________
>>> From: Development
>>> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:developme
>>> nt-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Simon
>>> Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> Sent:
>>> Thursday, January 5, 2017 8:50:52 PM
>>> To: development
>>> Subject: [Development] State of dev branch in CI
>>>
>>>
>>> Hi,
>>>
>>> I wanted to give a quick update on the state of the dev branch in the CI:
>>>
>>> Currently any changes to any module outside of qtbase targeting the dev
>>> branch will fail to pass the build stage in the CI.
>>>
>>> Recently RHEL 7.2 was added to dev. When that was tested - back in fall
>>> last year - all was fine. Then some configure options of qtbase were
>>> changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2
>>> (longer story but basically because of our binary packages). Earlier this
>>> week the change in the CI to add RHEL 7.2 to dev was taken into
>>> production and immediately broke the build of all modules in dev because
>>> -qt-pcre was not a valid configure parameter anymore and without qtbase
>>> nothing else builds. As a consequence the CI changes were reverted.
>>>
>>> Meanwhile the qtbase configure parameters were fixed and support for
>>> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
>>> in the dev branch compiles on RHEL 7.2.
>>>
>>> Unfortunately all other modules are built against qtbase from qt5.git,
>>> which doesn't understand -qt-pcre yet (wants pcre2). Therefore all
>>> modules other than qtbase are broken in dev.
>>>
>>> An update of qt5.git with a newer qtbase is scheduled, but unfortunately
>>> it
>>> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
>>>
>>> There are different options for solving this. One would be to revert the
>>> CI
>>> change. Another would be to fix the above bug and get the qt5 change
>>> through.
>>>
>>>
>>> The right solution to prevent these types of situations in the future is
>>> to
>>> have these platform configs inside qt5.git, not in the CI. Unfortunately
>>> that is not a priority yet.
>>>
>>>
>>>
>>> Simon
>>
>> --
>> Dr Sean Harmer | sean.harmer at kdab.com<mailto:sean.harmer at kdab.com> |
>> Managing Director UK KDAB (UK) Ltd, a KDAB Group company
>> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
>> Mobile: +44 (0)7545 140604
>> KDAB - Qt Experts
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org<mailto:Development at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170110/1cc11278/attachment.html>

From philippeb8 at gmail.com  Wed Jan 11 00:46:10 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Tue, 10 Jan 2017 18:46:10 -0500
Subject: [Development] [root_ptr] GC + Automatic Reference Counting
Message-ID: <o53rnu$js0$1@blaine.gmane.org>

Greetings,

To go back on the main subject, it came to my attention that Apple is 
using mostly "Automatic Reference Counting" since 2011:
https://en.wikipedia.org/wiki/Automatic_Reference_Counting

The good news is it's not using the GC which makes the OS hangs once in 
a while but the bad news is it still suffers from cyclic references 
which I don't think is acceptable for the software industry nowadays. 
This means the Apple OS leaks.

root_ptr clearly stands apart, hands down.  I just did my research 
regarding all aspects, objectively, in order to mold the best memory 
manager ever and I welcome any objection.  I am also glad the 
boost::fast_pool_allocator does such a great job in the user space.


Regards,
-Phil



From bstottle at ford.com  Wed Jan 11 01:42:38 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Wed, 11 Jan 2017 00:42:38 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170110121127.GC12254@troll08>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170109155440.GB5981@troll08>
	<F14A053F-6F74-4093-8003-89F4CDFD017E@ford.com>
	<20170110121127.GC12254@troll08>
Message-ID: <03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>

On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:



>On Tue, Jan 10, 2017 at 01:42:12AM +0000, Stottlemyer, Brett (B.S.) wrote:
>> The processing of QObject code by repc to generate the .rep input file
>> format was added afterwards.  It allows existing Qt header files to be
>> used with QtRO with compile time checks.  We don’t use that feature much
>> internally, but others are.
>> 
>you mostly lost me here, because i just don't know enough about the data
>flows of the qtro build system, so it would be helpful if you outlined
>that.

Sure.  I guess to start off, I don’t consider QtRO to be a RPC mechanism.
In my mind, RPC would be akin to exposing a QObject’s slots for calling
individually.  With QtRO (which only works Qt to Qt, it isn’t currently
available to other “languages”, like ruby/python/etc.) you talk QObjects.

A Source object is added to the network, and clients (although I’m not
sure that is the right term) can then get a Replica of that object.  Any
change to the Source object (Signals emitted, or Q_Properties changed)
then get communicated to every Replica.  A Slot call is passed back to
the Source for handling, with any “side-effects” forwarded to all Replicas.

With this picture in mind, the key to getting it to work is to hook into
qt_metacall and pass the invocations between processes.  This takes custom
code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
a simple text format for describing the object’s API via Signals, Slot,
Properties and Enums, and generates a Qt header file for the Source and
Replica sides.  The mkspecs then add these files for moc to process.

At some level, I see the .rep format as an extreme of a Q_OBJECT definition
in that only the “API” is defined (property, signal, slot, enum), and
everything else is private/pimpl.  Specific to QtRO, the Source may differ
from the Replica in that Q_PROPERTYs may be CONSTANT on the Source, but
still have a notify on the Replica.  The reason for this is that we want
Replica objects to have default values for properties that are valid
before the connection is established, and then pick up the “real” value
once the connection is made.

>but my naive understanding of rpc implementations is that you actually
>want to create some idl (is this what .rep is about?) from the c++, and
>in a later step compile that into stubs and skeletons. the former sounds
>like a task moc could do as a side effect, while the latter is for repc.

I see it as the opposite for QtRO.  The .rep defines the API, repc creates
the Qt headers for the types, then moc generates the code based on the
headers.

>as it happens, we actually have that in qtbase already, in form of the
>dbus tools. and as expected, qdbuscpp2xml is yet another tool that pulls
>in moc sources ...
>
>and obviously, moc itself could also be split into two tools.
>or, the moc frontend could be replaced with clang, for which code
>actually already exists, but wasn't deemed quite ready for prime time
>yet. maybe we could actually pull that off now that qdoc is switching
>to clang as well.

I'm interested to know if you think this is still relevant based on my
reply.  I’m not really sure how to answer.

>soliciting input primarily from olivier and thiago here ...

Welcomed.

>it's in the interest of the qt project to unify the offering as much as
>possible, minimizing redundant apis and implementations. the former are
>by definition before-freeze items, while the latter are as far as they
>cannot be done without impacting the api. (api being used in the
>broadest sense here, so tools are obviously also covered.)

Completely agree.  At the same time, I don’t want to miss the deadline for
feature freeze, so I’m hoping to get past that hurdle and address some of
your proposals afterwards as a tech preview.

As a playground project I think we haven’t gotten a lot of attention from
The Qt Company and I really do welcome that.  The repc tool specifically is
kind of in a weird spot.  I’m not sure there are any other tools that are
bootstrapped and aren’t in qtbase.  Should repc* not be bootstrapped?
Alternatively, should it be part of qtbase (so moc doesn’t need to be
“3rdParty”)?  Until QtRO is promoted to a Qt module, I don’t think these
questions can really be answered.

*QtRO will do type checking at compile time if an API gets generated from
repc.  You can also “share” any QObject via QtRO, but the Replica is then
dynamically generated and needs runtime checks.  The repc program includes
moc to it can generate a .rep file for any Qobject - thus supporting
compile time checks from existing Qt header files.  Oddly enough, the
generated code is then passed through moc again.  This is the “second”
use-case I mentioned.  I think it is a valid use case, but one I don’t use
much.

Hope that helps,
Brett



From jani.heikkinen at qt.io  Wed Jan 11 09:03:03 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 11 Jan 2017 08:03:03 +0000
Subject: [Development] New Qt 5.8 rc snapshot for testing
Message-ID: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>

Hi

We have new Qt 5.8.0 rc snapshot for testing

Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/720/
mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/726/
Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/622/
src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/

All known blockers should be fixed in these packages and we are targeting to release Qt 5.8.0 Tue 17th January if nothing really serious found during testing. So please inform me immediately if there is some new blocker in the packages.

Please update known issues page (https://wiki.qt.io/Qt_5.8.0_Known_Issues) when needed as well

br,
Jani


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170111/68115a78/attachment.html>

From bstottle at ford.com  Wed Jan 11 09:48:30 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Wed, 11 Jan 2017 08:48:30 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170109155440.GB5981@troll08>
	<F14A053F-6F74-4093-8003-89F4CDFD017E@ford.com>
	<20170110121127.GC12254@troll08>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
Message-ID: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>

On 1/10/17, 7:42 PM, "Stottlemyer, Brett (B.S.)" <bstottle at ford.com> wrote:



>On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:
>
>>you mostly lost me here, because i just don't know enough about the data
>>flows of the qtro build system, so it would be helpful if you outlined
>>that.

...

>*QtRO will do type checking at compile time if an API gets generated from
>repc.

Maybe it is worth expanding on this a little bit.  If you are using QtRO from
the beginning of a project, the idea would be for the owner of an interface
to define the API their object will use in a .rep file.  In the .pro file,
REPC_SOURCE += someInterface.rep is added, which causes repc to generate the
Source side header file, which provides a QObject class for that API with
pure virtual methods for Slots.  The developer then inherits from the base
API class and implements the internal logic to meet the API.  Side note: 
additional Qt Signals/Slots can be added to the derived class, which aren’t
exposed to Replicas if they aren’t in the .rep file.

Anyone that wants to use this interface would add
REPC_REPLICA += someInterface
to their .pro file, which generates (you guessed it) the Replica side header
file.  It is possible to inherit from this class, but usually isn’t necessary
and the class/code can be used directly.

The reason for having moc code as part of repc is to handle the use-case of
someone having an already developed QObject type and wanting to use that
with QtRO.  I.e., a class that doesn’t derive from the auto generated
Source class.  In this case, moc is used to parse the header, and generate
the .rep for your class.  The .rep file can then be used by clients to
get Replicas.

There is another level of detail in QtRO for efficiency and type safety (see
the auto generated someInterfaceSourceAPI template in the Source header).
Feel free to look at that if you want more detail.

Regards,
Brett


From marc.mutz at kdab.com  Wed Jan 11 10:43:43 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Wed, 11 Jan 2017 10:43:43 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170110121127.GC12254@troll08>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
Message-ID: <201701111043.44419.marc.mutz@kdab.com>

Hi Brett,

On Wednesday 11 January 2017 01:42:38 Stottlemyer, Brett (B.S.) wrote:
> With this picture in mind, the key to getting it to work is to hook into
> qt_metacall and pass the invocations between processes.  This takes custom
> code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
> a simple text format for describing the object’s API via Signals, Slot,
> Properties and Enums, and generates a Qt header file for the Source and
> Replica sides.  The mkspecs then add these files for moc to process.

Speaking as someone who has almost no clue about QtRO, from an engineering 
pov, it feels weird to have an easily-parsable representation of a 
QMetaObject, then generate C++ code from it, and then use moc to parse the C++ 
code to generate a QMetaObject. Wouldn't it be much simpler to generate the 
moc files directly from the rep files (maybe even at runtime, with 
QMetaObjectBuilder)?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From Sebastian.Loesch at governikus.de  Wed Jan 11 14:38:37 2017
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Wed, 11 Jan 2017 13:38:37 +0000
Subject: [Development] Review needed on QFileSelector
Message-ID: <1484141890.3447.4.camel@governikus.de>

Hello,

I developed a patch to qt's core module to remove the necessity to have
an unused base file when only loading variants of the file using the
QFileSelector.

I am looking for someone with knowledge in QFileSelector to review my
patch on gerrit:
https://codereview.qt-project.org/#/c/175376/

Thanks in advance for any feedback.

Best regards
Sebastian

From bstottle at ford.com  Wed Jan 11 14:54:11 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Wed, 11 Jan 2017 13:54:11 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <201701111043.44419.marc.mutz@kdab.com>
References: <D61AC824-02C0-4358-81AA-81E5EF02FD8A@ford.com>
	<20170110121127.GC12254@troll08>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<201701111043.44419.marc.mutz@kdab.com>
Message-ID: <E0AE1B2C-4D46-4975-BD96-8B60DF248B25@ford.com>

On 1/11/17, 4:43 AM, "marc at kdab.com on behalf of Marc Mutz" <marc at kdab.com on behalf of marc.mutz at kdab.com> wrote:



>Hi Brett,
>
>On Wednesday 11 January 2017 01:42:38 Stottlemyer, Brett (B.S.) wrote:
>> With this picture in mind, the key to getting it to work is to hook into
>> qt_metacall and pass the invocations between processes.  This takes custom
>> code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
>> a simple text format for describing the object’s API via Signals, Slot,
>> Properties and Enums, and generates a Qt header file for the Source and
>> Replica sides.  The mkspecs then add these files for moc to process.
>
>Speaking as someone who has almost no clue about QtRO, from an engineering 
>pov, it feels weird to have an easily-parsable representation of a 
>QMetaObject, then generate C++ code from it, and then use moc to parse the C++ 
>code to generate a QMetaObject. Wouldn't it be much simpler to generate the 
>moc files directly from the rep files (maybe even at runtime, with 
>QMetaObjectBuilder)?

Hi Marc.  I was not trying to give a comprehensive overview (that what docs
are for, right?) just trying to address Ossi’s comments.  QtRO does provide
for pushing a standard QObject out on the QtRO network and getting a “dynamic”
Replica of it without needing repc/moc.  But while this is possible, it is
a bit painful to work with.  The assumption is that the Replica is in a
different process than the QObject it represents.  The Replica will match the
API, but it needs extra plumbing and is a specific type (a mouthful,
QRemoteObjectDynamicReplica).  It can’t know anything about itself until it
gets information from QtRO about the object is should represent, and then you
need to (in code) look up the methods/properties from the runtime generated
metaobject.  There are no compile time checks against anything.  Works
reasonably well from QML, but as said, hard from C++.  The additional mkspecs
in QtRO hide the additional steps almost completely, and the generated code
provides better performance, the ability to have default values until the
connection is made, and type-safety.  Both options are available, though.

Regards,
Brett



From edward.welbourne at qt.io  Wed Jan 11 15:35:35 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 11 Jan 2017 14:35:35 +0000
Subject: [Development] Qt pi
Message-ID: <HE1PR0202MB268340A353D62ED89D5FE02F87660@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Hi all,

In the course of testing 5.8.0, I was puzzled by an example hard-coding
a value for pi, rather than re-using one from some public header as I
expected.  To my surprise, the standard library only provides M_PI as a
POSIX extension.  It turns out we do have a qmath.h that, sensibly
enough, does

#ifndef M_PI
#define M_PI (3.14159265358979323846)
#endif

Despite this, 302 other places in my Qt-dev source tree supply their own
values for pi.  There is some diversity of values.  Let's start with the
correctly-rounded ones:

3.14159
3.14159265 (enough for float - see below)
3.14159265358979
3.141592653589793 (enough for double - see below)
3.1415926535897932
3.141592653589793238
3.14159265358979323846 (same as M_PI in qmath.h)
3.1415926535897932384626433832795
3.14159265358979323846264338327950288
3.14159265358979323846264338327950288419717
3.14159265359
3.1415927

Then the truncated ones that aren't correct roundings (in each case, the
last digit needs +1):
3.1415
3.141592
3.1415926
3.1415926535
3.141592653589

Finally, the values that look suspiciously like they were meant to be
pi, but aren't (inserting a space after the last matching digit):

3.1415 2 (missing 9) In several parameters to sin(...)
3.14159 62 (last two digits swapped) In some JS benchmarks
3.14159265358979 23846 (missing 3) In an ECMA JS test

I am fairly sure the parameters to sin were meant to use pi; and I
suspect changing the JS tests is out-of-scope as they look like imports
(i.e. third-party).

Wikipedia gives the following first 49 digits (followed by a 0):

3.1415926535897932384626433832795028841971693993751

Experiment with gcc on 64-bit Intel reveals that there is no point
supplying more than the following digits, for each type:

long double: 3.1415926535897932385
     double: 3.141592653589793
      float: 3.1415927

So our M_PI is almost good.  It coincides with what Linux's <math.h>
provides, except that we put parentheses round it - can anyone give me a
good reason for that ?  I doubt it matters.  However, neither M_PI puts
an L suffix on it, so its last four digits are effectively ignored
(because a floating literal is double by default).

It looks like it would make sense to:

i) Change qmath.h's M_PI to (3.14159265358979323846L)
   i.e. make it a long double, let context downgrade it as needed

ii) Change all other hand-crafted approximations to use M_PI.

Can anyone offer me a sane reason to not do this ?
We have have little arithmetic irregularities creeping in from our
inconsistencies ...

	Eddy.


From lars.knoll at qt.io  Wed Jan 11 16:11:45 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Wed, 11 Jan 2017 15:11:45 +0000
Subject: [Development] Qt pi
In-Reply-To: <HE1PR0202MB268340A353D62ED89D5FE02F87660@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <HE1PR0202MB268340A353D62ED89D5FE02F87660@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <1E8A8177-17D7-4A02-89B4-302C95C55D7F@qt.io>

Hi Eddy,

plan sounds good, just go ahead :)

Cheers,
Lars

> On 11 Jan 2017, at 15:35, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Hi all,
> 
> In the course of testing 5.8.0, I was puzzled by an example hard-coding
> a value for pi, rather than re-using one from some public header as I
> expected.  To my surprise, the standard library only provides M_PI as a
> POSIX extension.  It turns out we do have a qmath.h that, sensibly
> enough, does
> 
> #ifndef M_PI
> #define M_PI (3.14159265358979323846)
> #endif
> 
> Despite this, 302 other places in my Qt-dev source tree supply their own
> values for pi.  There is some diversity of values.  Let's start with the
> correctly-rounded ones:
> 
> 3.14159
> 3.14159265 (enough for float - see below)
> 3.14159265358979
> 3.141592653589793 (enough for double - see below)
> 3.1415926535897932
> 3.141592653589793238
> 3.14159265358979323846 (same as M_PI in qmath.h)
> 3.1415926535897932384626433832795
> 3.14159265358979323846264338327950288
> 3.14159265358979323846264338327950288419717
> 3.14159265359
> 3.1415927
> 
> Then the truncated ones that aren't correct roundings (in each case, the
> last digit needs +1):
> 3.1415
> 3.141592
> 3.1415926
> 3.1415926535
> 3.141592653589
> 
> Finally, the values that look suspiciously like they were meant to be
> pi, but aren't (inserting a space after the last matching digit):
> 
> 3.1415 2 (missing 9) In several parameters to sin(...)
> 3.14159 62 (last two digits swapped) In some JS benchmarks
> 3.14159265358979 23846 (missing 3) In an ECMA JS test
> 
> I am fairly sure the parameters to sin were meant to use pi; and I
> suspect changing the JS tests is out-of-scope as they look like imports
> (i.e. third-party).
> 
> Wikipedia gives the following first 49 digits (followed by a 0):
> 
> 3.1415926535897932384626433832795028841971693993751
> 
> Experiment with gcc on 64-bit Intel reveals that there is no point
> supplying more than the following digits, for each type:
> 
> long double: 3.1415926535897932385
>     double: 3.141592653589793
>      float: 3.1415927
> 
> So our M_PI is almost good.  It coincides with what Linux's <math.h>
> provides, except that we put parentheses round it - can anyone give me a
> good reason for that ?  I doubt it matters.  However, neither M_PI puts
> an L suffix on it, so its last four digits are effectively ignored
> (because a floating literal is double by default).
> 
> It looks like it would make sense to:
> 
> i) Change qmath.h's M_PI to (3.14159265358979323846L)
>   i.e. make it a long double, let context downgrade it as needed
> 
> ii) Change all other hand-crafted approximations to use M_PI.
> 
> Can anyone offer me a sane reason to not do this ?
> We have have little arithmetic irregularities creeping in from our
> inconsistencies ...
> 
> 	Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From edward.welbourne at qt.io  Wed Jan 11 16:51:45 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 11 Jan 2017 15:51:45 +0000
Subject: [Development] Qt pi
In-Reply-To: <1E8A8177-17D7-4A02-89B4-302C95C55D7F@qt.io>
References: <HE1PR0202MB268340A353D62ED89D5FE02F87660@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<1E8A8177-17D7-4A02-89B4-302C95C55D7F@qt.io>
Message-ID: <HE1PR0202MB2683A5D99E7FB7FD7025F01387660@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Lars Knoll:
> plan sounds good, just go ahead :)

I've opened QTBUG-58083 for the sake of tracking it.
Anyone with further comments is welcome to look there.
On IRC, peppe has pointed out using L may get narrowing warnings from some compilers.
So I'll start with using M_PI and Math.PI more widely.

	Eddy.


From oswald.buddenhagen at qt.io  Wed Jan 11 17:50:26 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 11 Jan 2017 17:50:26 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
Message-ID: <20170111165026.GA18905@troll08>

On Wed, Jan 11, 2017 at 12:42:38AM +0000, Stottlemyer, Brett (B.S.) wrote:
> I guess to start off, I don’t consider QtRO to be a RPC mechanism.
> In my mind, RPC would be akin to exposing a QObject’s slots for calling
> individually.  With QtRO (which only works Qt to Qt, it isn’t currently
> available to other “languages”, like ruby/python/etc.) you talk QObjects.
> 
technically speaking, it's a distributed object system (which puts it
into the same category as CORBA), but the underlying mechanism is still
rpc.

> At some level, I see the .rep format as an extreme of a Q_OBJECT definition
> in that only the “API” is defined (property, signal, slot, enum), and
> everything else is private/pimpl.
>
yes, that makes .rep an idl format.

> >but my naive understanding of rpc implementations is that you actually
> >want to create some idl (is this what .rep is about?) from the c++, and
> >in a later step compile that into stubs and skeletons. the former sounds
> >like a task moc could do as a side effect, while the latter is for repc.
> 
> I see it as the opposite for QtRO.  The .rep defines the API, repc creates
> the Qt headers for the types,
>
i'm not sure how it's the opposite, when you effectively confirmed what
i speculated.

> then moc generates the code based on the headers.
> 
that's just a rather convoluted way to achieve the same, as marc noted
as well.

> I don’t want to miss the deadline for feature freeze, so I’m hoping to
> get past that hurdle and address some of your proposals afterwards as
> a tech preview.
> 
that seems a bit optimistic, given that we're discussing some rather
fundamental aspects of the design.

also, i don't think we've been bothering a lot about deadlines for TP
modules, so who cares.

> As a playground project I think we haven’t gotten a lot of attention
> from The Qt Company and I really do welcome that.
>
from experience, this isn't going to change. it's on you to reach out
(preferably without imposing a deadline).
it's your project, and it will be released in whatever state it is when
you deem it ready.

and if later somebody else with resources suddenly finds it interesting
but finds it to suck a lot, there will be struggling to get it into
shape, or to get rid of it again, to push for a better solution. we've
been there before.

it doesn't help that you apparently haven't even explored the prior art
within qt even though it was pointed out to you two years ago already.

> The repc tool specifically is kind of in a weird spot.  I’m not sure
> there are any other tools that are bootstrapped and aren’t in qtbase.
> Should repc* not be bootstrapped?  Alternatively, should it be part of
> qtbase (so moc doesn’t need to be “3rdParty”)?  Until QtRO is promoted
> to a Qt module, I don’t think these questions can really be answered.
> 
there is nothing extraordinary about repc from the buildsystem
perspective.
there are some things to fix, but this is not place to discuss them.
other paragraphs are concerned with the duplication of moc.

> >>*QtRO will do type checking at compile time if an API gets generated from
> >>repc.
> 
> Maybe it is worth expanding on this a little bit.  [...]
>
afaict, you just described *precisely* what qdbuscpp2xml and
qdbusxml2cpp do, except that you decided to put both tools into one
executable.

the part that is shared with moc is the c++ parser, and as expressed in
the previous mail, the hope is to get rid of that entirely in favor of
clang.

that leaves us with extracting the relevant meta data from the AST, the
intermediate storage of the meta data (the idl), and the code generator.
this is all relatively little code, so sharing *as such* doesn't seem
too useful. however, it's quite ineffcient that the c++ parsing is done
multiple times, so a unified meta data processing pipeline appears
preferable:
- moc parses the c++ to create an idl file that contains all qt-specific
  meta data (what it should extract and how it should represent it can
  be declared in the headers it includes, so in principle it's possible
  to make it quite generic)
- alternatively, the user provides the idl file (both qtro and qtdbus
  support that already)
- the idl file is fed to various code generators
- the code generated by repc is not fed back into moc for parsing from
  scratch, but instead repc creates a modified idl which is fed directly
  into the moc code generator
  - come to think of it, qtdbus also has *precisely the same* problem
    (see qtbase/mkspecs/features/dbus*). you really managed to replicate
    it down to its warts. ;)

a concrete action point would be exploring in how far it's possible (and
actually sensible) to design a shared meta data representation (idl).
qtdbus' xml is horrible (of course it is), but it's easy to process.
repc's "proper" idl is the exact opposite ...

ah, yeah, qtsystems. have a look and report. ;)

just some food for thought. ;)



From tuukka.turunen at qt.io  Wed Jan 11 19:28:26 2017
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Wed, 11 Jan 2017 18:28:26 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170111165026.GA18905@troll08>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
Message-ID: <AM4PR0202MB29485D37BCB7198B21D929878F660@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Oswald
> Buddenhagen
> Sent: keskiviikkona 11. tammikuuta 2017 18.50
> To: development at qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> > I don’t want to miss the deadline for feature freeze, so I’m hoping to
> > get past that hurdle and address some of your proposals afterwards as
> > a tech preview.
> >
> that seems a bit optimistic, given that we're discussing some rather
> fundamental aspects of the design.
> 
> also, i don't think we've been bothering a lot about deadlines for TP modules,
> so who cares.
> 

As this is a module to be added, we need to have it in place latest at the FF. Preferably modules should be in place earlier than FF.

The criteria for the content of the module is of course less strict when it is a TP, but still if it is likely to need full refactoring perhaps waiting for 5.10 is a better option?

Yours,

	Tuukka


From philippeb8 at gmail.com  Thu Jan 12 01:10:36 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Wed, 11 Jan 2017 19:10:36 -0500
Subject: [Development] [root_ptr] GC + Automatic Reference Counting
In-Reply-To: <o53rnu$js0$1@blaine.gmane.org>
References: <o53rnu$js0$1@blaine.gmane.org>
Message-ID: <b6c08389-51c3-1e6d-889d-443519e5ba76@gmail.com>

On 01/10/2017 06:46 PM, Phil Bouchard wrote:
> Greetings,
>
> To go back on the main subject, it came to my attention that Apple is
> using mostly "Automatic Reference Counting" since 2011:
> https://en.wikipedia.org/wiki/Automatic_Reference_Counting
>
> The good news is it's not using the GC which makes the OS hangs once in
> a while but the bad news is it still suffers from cyclic references
> which I don't think is acceptable for the software industry nowadays.
> This means the Apple OS leaks.
>
> root_ptr clearly stands apart, hands down.  I just did my research
> regarding all aspects, objectively, in order to mold the best memory
> manager ever and I welcome any objection.  I am also glad the
> boost::fast_pool_allocator does such a great job in the user space.

Moreover I will try part of the following kernel level memory manager 
sooner or later:
https://github.com/tempesta-tech/tempesta

At the same time I was just wondering what is the next step?  I am 
obviously trying to get this library part of the Boost library but for 
that I need a review manager:
http://www.boost.org/community/reviews.html#Review_Manager

So any volunteer is most welcome.  It would be subjective to say there 
is no demand in that area given the state of the art in the IT industry 
like previously mentioned.

Also I did compare popular pool allocators and once again I find that 
the boost::fast_pool_allocator stands out.

Lastly I find this subject really interesting and I'm sure I'm not the 
only one so I wish I can help while I still have some free time available.


Sincerely,
-Phil



From bstottle at ford.com  Thu Jan 12 02:19:28 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Thu, 12 Jan 2017 01:19:28 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170111165026.GA18905@troll08>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
Message-ID: <CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>

On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:


>> >but my naive understanding of rpc implementations is that you actually
>> >want to create some idl (is this what .rep is about?) from the c++, and
>> >in a later step compile that into stubs and skeletons. the former sounds
>> >like a task moc could do as a side effect, while the latter is for repc.
>> 
>> I see it as the opposite for QtRO.  The .rep defines the API, repc creates
>> the Qt headers for the types,
>>
>i'm not sure how it's the opposite, when you effectively confirmed what
>i speculated.

To clarify, I simply meant that you described c++ -> idl, while the normal
process for QtRO is idl -> c++.

>> I don’t want to miss the deadline for feature freeze, so I’m hoping to
>> get past that hurdle and address some of your proposals afterwards as
>> a tech preview.
>> 
>that seems a bit optimistic, given that we're discussing some rather
>fundamental aspects of the design.

This is a bit dramatic, isn’t it?  Unless I misinterpret, you are not
suggesting the generated code change, just the process for generating it.
As such, it would seem that any change would be a drop-in replacement, so
I don’t see any criticality to the timing, especially for a TP module.

It also seems like your main objection is the use of moc, which is (as
I’ve already said) an edge case.  If this is the key sticking point, I
can drop support for converting QObjects to .rep files and remove moc
from the repo.

>also, i don't think we've been bothering a lot about deadlines for TP
>modules, so who cares.

Apparently Tuukka does, since he’s suggesting holding off until 5.10...

>it doesn't help that you apparently haven't even explored the prior art
>within qt even though it was pointed out to you two years ago already.

Looking again now, I believe you are talking about Qt Service Framework.  It
does look familiar, so I probably looked at it and discarded it as solving a
separate problem, then forgotten I’d looked.

Top hits on google are

https://blog.qt.io/blog/2009/05/26/qt-service-framework/
https://doc-snapshots.qt.io/qt-mobility/service-frameworks.html

And
https://wiki.qt.io/Service_Framework_API


It provides platform specific implementations of services/daemons with a
common Qt API.  “Once the service has been identified the framework starts
the service and returns a pointer to it.”  This isn’t the use-case I’m
trying to solve.  It doesn’t work between platforms (like QtRO does with
the tcp/ip backend), doesn’t support Q_PROPERTY, doesn’t support default
values, and assumes services can be started from any user code.  It is RPC,
not a distributed object system.  I don’t consider it “prior art”, except
at a "rectangular device with rounded corners" kind of level.

>afaict, you just described *precisely* what qdbuscpp2xml and
>qdbusxml2cpp do, except that you decided to put both tools into one
>executable.

Right, I DO consider the dbus code to be prior art, in that is solves a
very similar problem, so I leveraged the pieces that I could.

>the part that is shared with moc is the c++ parser, and as expressed in
>the previous mail, the hope is to get rid of that entirely in favor of
>clang.
>
>that leaves us with extracting the relevant meta data from the AST, the
>intermediate storage of the meta data (the idl), and the code generator.
>this is all relatively little code, so sharing *as such* doesn't seem
>too useful. however, it's quite ineffcient that the c++ parsing is done
>multiple times, so a unified meta data processing pipeline appears
>preferable:
>- moc parses the c++ to create an idl file that contains all qt-specific
>  meta data (what it should extract and how it should represent it can
>  be declared in the headers it includes, so in principle it's possible
>  to make it quite generic)
>- alternatively, the user provides the idl file (both qtro and qtdbus
>  support that already)
>- the idl file is fed to various code generators
>- the code generated by repc is not fed back into moc for parsing from
>  scratch, but instead repc creates a modified idl which is fed directly
>  into the moc code generator
>  - come to think of it, qtdbus also has *precisely the same* problem
>    (see qtbase/mkspecs/features/dbus*). you really managed to replicate
>    it down to its warts. ;)
>
>a concrete action point would be exploring in how far it's possible (and
>actually sensible) to design a shared meta data representation (idl).
>qtdbus' xml is horrible (of course it is), but it's easy to process.
>repc's "proper" idl is the exact opposite ...

Is it reasonable to assert that all of the above should either be needed for
both QtRO and QtDbus or neither?  If so, I’ll drop the moc support from QtRO
and re-add it once the above is done for qtdbus. 

>ah, yeah, qtsystems. have a look and report. ;)

See above.

>just some food for thought. ;)

Appreciated.  With removal of moc, can we proceed as a Tech Preview in 5.9?

Regards,
Brett


From lars.knoll at qt.io  Thu Jan 12 08:39:33 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Thu, 12 Jan 2017 07:39:33 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
Message-ID: <C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>

I didn't find time to have a more detailed look at the code so far, but hope to get to it over the weekend.

But in general I think we need to put the bars for becoming a TP at the right level. It's not a fully supported module yet, and we put it out especially to collect feedback. So it doesn't have to be 100% at the same level as supported modules. Here are the criteria I think we should have (and that we IMO implicitly used in the past):

* The module solves a problem our users have
  - It either implements new and so far non existent functionality
  - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
* The module builds inside the Qt build system on all platforms
    - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
* The module is CI controlled
* There is a decent set of automated tests covering the main functionality and most of the API of the module
  - The tests pass on all platforms where the module is supported
* APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
* Architecture makes sense
* It follows the Qt coding style and conventions
* Implementation has been checked for sanity
  - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)

IMO that should cover most of the needs and demands we should have for new modules before offering them as a TP.

From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other points in the list above that haven't been discussed yet here?

Cheers,
Lars

On 12 Jan 2017, at 02:19, Stottlemyer, Brett (B.S.) <bstottle at ford.com<mailto:bstottle at ford.com>> wrote:

On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org<mailto:development-bounces+bstottle=ford.com at qt-project.org> on behalf of oswald.buddenhagen at qt.io<mailto:oswald.buddenhagen at qt.io>> wrote:


but my naive understanding of rpc implementations is that you actually
want to create some idl (is this what .rep is about?) from the c++, and
in a later step compile that into stubs and skeletons. the former sounds
like a task moc could do as a side effect, while the latter is for repc.

I see it as the opposite for QtRO.  The .rep defines the API, repc creates
the Qt headers for the types,

i'm not sure how it's the opposite, when you effectively confirmed what
i speculated.

To clarify, I simply meant that you described c++ -> idl, while the normal
process for QtRO is idl -> c++.

I don’t want to miss the deadline for feature freeze, so I’m hoping to
get past that hurdle and address some of your proposals afterwards as
a tech preview.

that seems a bit optimistic, given that we're discussing some rather
fundamental aspects of the design.

This is a bit dramatic, isn’t it?  Unless I misinterpret, you are not
suggesting the generated code change, just the process for generating it.
As such, it would seem that any change would be a drop-in replacement, so
I don’t see any criticality to the timing, especially for a TP module.

It also seems like your main objection is the use of moc, which is (as
I’ve already said) an edge case.  If this is the key sticking point, I
can drop support for converting QObjects to .rep files and remove moc
from the repo.

also, i don't think we've been bothering a lot about deadlines for TP
modules, so who cares.

Apparently Tuukka does, since he’s suggesting holding off until 5.10...

it doesn't help that you apparently haven't even explored the prior art
within qt even though it was pointed out to you two years ago already.

Looking again now, I believe you are talking about Qt Service Framework.  It
does look familiar, so I probably looked at it and discarded it as solving a
separate problem, then forgotten I’d looked.

Top hits on google are

https://blog.qt.io/blog/2009/05/26/qt-service-framework/
https://doc-snapshots.qt.io/qt-mobility/service-frameworks.html

And
https://wiki.qt.io/Service_Framework_API


It provides platform specific implementations of services/daemons with a
common Qt API.  “Once the service has been identified the framework starts
the service and returns a pointer to it.”  This isn’t the use-case I’m
trying to solve.  It doesn’t work between platforms (like QtRO does with
the tcp/ip backend), doesn’t support Q_PROPERTY, doesn’t support default
values, and assumes services can be started from any user code.  It is RPC,
not a distributed object system.  I don’t consider it “prior art”, except
at a "rectangular device with rounded corners" kind of level.

afaict, you just described *precisely* what qdbuscpp2xml and
qdbusxml2cpp do, except that you decided to put both tools into one
executable.

Right, I DO consider the dbus code to be prior art, in that is solves a
very similar problem, so I leveraged the pieces that I could.

the part that is shared with moc is the c++ parser, and as expressed in
the previous mail, the hope is to get rid of that entirely in favor of
clang.

that leaves us with extracting the relevant meta data from the AST, the
intermediate storage of the meta data (the idl), and the code generator.
this is all relatively little code, so sharing *as such* doesn't seem
too useful. however, it's quite ineffcient that the c++ parsing is done
multiple times, so a unified meta data processing pipeline appears
preferable:
- moc parses the c++ to create an idl file that contains all qt-specific
meta data (what it should extract and how it should represent it can
be declared in the headers it includes, so in principle it's possible
to make it quite generic)
- alternatively, the user provides the idl file (both qtro and qtdbus
support that already)
- the idl file is fed to various code generators
- the code generated by repc is not fed back into moc for parsing from
scratch, but instead repc creates a modified idl which is fed directly
into the moc code generator
- come to think of it, qtdbus also has *precisely the same* problem
  (see qtbase/mkspecs/features/dbus*). you really managed to replicate
  it down to its warts. ;)

a concrete action point would be exploring in how far it's possible (and
actually sensible) to design a shared meta data representation (idl).
qtdbus' xml is horrible (of course it is), but it's easy to process.
repc's "proper" idl is the exact opposite ...

Is it reasonable to assert that all of the above should either be needed for
both QtRO and QtDbus or neither?  If so, I’ll drop the moc support from QtRO
and re-add it once the above is done for qtdbus.

ah, yeah, qtsystems. have a look and report. ;)

See above.

just some food for thought. ;)

Appreciated.  With removal of moc, can we proceed as a Tech Preview in 5.9?

Regards,
Brett

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170112/2609d041/attachment.html>

From mitch.curtis at qt.io  Thu Jan 12 09:50:25 2017
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Thu, 12 Jan 2017 08:50:25 +0000
Subject: [Development] Jira action buttons
In-Reply-To: <AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
	<AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <DB5PR0201MB2022CFA6218255FE69C6739288790@DB5PR0201MB2022.eurprd02.prod.outlook.com>

I'm noticing this for bugs too (QTBUG-57965). Do you have a report for tracking this issue, or do you know when it will be fixed?

> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Alexander Blasche
> Sent: Monday, 9 January 2017 9:22 AM
> To: Qt development mailing list <development at qt-project.org>
> Subject: Re: [Development] Jira action buttons
> 
> Hi,
> 
> > -----Original Message-----
> > From: Development [mailto:development-
> > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Samuel
> > bounces+Gaist
> > Sent: Sunday, 8 January 2017 23:44
> 
> > Is there any rule/filter that are applied on the bug reports related
> > to the actions made available ?
> >
> > For example:
> >
> > https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment,
> > Assign, More
> >
> > https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not
> > enough info, Accept, Close
> >
> > I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a
> > duplicate of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t
> > do it currently because for both of them I only get the reduced set of
> buttons.
> 
> This is a bug. Nobody had any state transition options for this task. Jira ran
> out of disk space last week. Maybe this has caused the problem. In any case,
> I have recovered the work flow state and marked QTBUG-57993 as duplicate
> of QTBUG-57992.
> 
> --
> Alex
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From jedrzej.nowacki at qt.io  Thu Jan 12 09:52:35 2017
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Thu, 12 Jan 2017 09:52:35 +0100
Subject: [Development] State of dev branch in CI
In-Reply-To: <VI1PR02MB10064BA5091D8F07D409BF178C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006E7996E473792BC6BEE1B8C600@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<VI1PR02MB11197493133F4C4D1CBF2D3E92670@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB10064BA5091D8F07D409BF178C670@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <1866648.uUL9pKTGMV@42>

On tirsdag 10. januar 2017 11.37.56 CET Simon Hausmann wrote:
>     (2) I really wish the placement of the configuration files for the
> platforms being moved to qt5.git had a high priority, because it prevents
> situations like these where the R&D organization, the project, contributors
> and partners in the ecosystem are blocked from work for several days. As
> such a configuration change went into the CI last Thursday and the problem
> was noticed last Thursday, the change _remained_ in there until now we have
> confirmation that it is going to get reverted. If this had been part of
> qt5.git the change would not go live until all the issues are fixed, while
> nobody else is blocked in their work.

For sake of bureaucracy this is tracked here: https://bugreports.qt.io/browse/
QTQAINFRA-1074 and it is almost solved.

Cheers,
  Jędrek


From alexander.blasche at qt.io  Thu Jan 12 11:29:15 2017
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Thu, 12 Jan 2017 10:29:15 +0000
Subject: [Development] Jira action buttons
In-Reply-To: <DB5PR0201MB2022CFA6218255FE69C6739288790@DB5PR0201MB2022.eurprd02.prod.outlook.com>
References: <C95383CF-E2E5-46F9-9691-A46E52C33E01@edeltech.ch>
	<AM4PR0201MB216498C22FBAAE93A23C2A7AE7640@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<DB5PR0201MB2022CFA6218255FE69C6739288790@DB5PR0201MB2022.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0201MB216471D8DFD072B2B673BA1EE7790@AM4PR0201MB2164.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Mitch Curtis

> I'm noticing this for bugs too (QTBUG-57965). Do you have a report for tracking
> this issue, or do you know when it will be fixed?

Done.

I am fixing as soon as somebody points them out to me. There is no easy way to identify them 

--
Alex

From edward.welbourne at qt.io  Thu Jan 12 11:30:02 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Thu, 12 Jan 2017 10:30:02 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>,
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
Message-ID: <HE1PR0202MB2683E6BADB2DDE15960CDE1287790@HE1PR0202MB2683.eurprd02.prod.outlook.com>

On 12 January 2017 at 08:39, Lars Knoll wrote:
> Here are the criteria I think we should have (and that we IMO implicitly used in the past):

This smells like something we should be turning into a QUIP.

	Eddy.


From tuukka.turunen at qt.io  Thu Jan 12 17:13:00 2017
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Thu, 12 Jan 2017 16:13:00 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
Message-ID: <AM4PR0202MB29480C70CDB0E25A5631530D8F790@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: torstaina 12. tammikuuta 2017 3.19
> To: development at qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen"
> <development-bounces+bstottle=ford.com at qt-project.org on behalf of
> oswald.buddenhagen at qt.io> wrote:
> 
> 
> 
> >also, i don't think we've been bothering a lot about deadlines for TP
> >modules, so who cares.
> 
> Apparently Tuukka does, since he’s suggesting holding off until 5.10...
> 
> >it doesn't help that you apparently haven't even explored the prior art
> >within qt even though it was pointed out to you two years ago already.
> 

Yes, when it comes to being part of a "release train" the cargo needs to be in decent shape when the trains leaves the station.

I would like to emphasize that I have nothing against this module being part of Qt 5.9 as a TP - as long as it is in such shape that causes no harm to the Qt 5.9 release schedule.

Many of the delays we have had with previous Qt 5 releases have been partially caused by not being ready at the FF time. 

Yours,

	Tuukka


From philippeb8 at gmail.com  Fri Jan 13 02:50:51 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Thu, 12 Jan 2017 20:50:51 -0500
Subject: [Development] [root_ptr] GC + Automatic Reference Counting
In-Reply-To: <b6c08389-51c3-1e6d-889d-443519e5ba76@gmail.com>
References: <o53rnu$js0$1@blaine.gmane.org>
	<b6c08389-51c3-1e6d-889d-443519e5ba76@gmail.com>
Message-ID: <o59bpn$up$1@blaine.gmane.org>

On 01/11/2017 07:10 PM, Phil Bouchard wrote:
>
> Moreover I will try part of the following kernel level memory manager
> sooner or later:
> https://github.com/tempesta-tech/tempesta

I just wanted to close the subject with the following note:

I did try the user-space version of the Tempesta Tech memory pool (see 
attached) and I get allocations 473% times faster than the system 
operator new (on an Intel i7 2.4 GHz)!

0: 100000000000000 allocations / second (no allocation)
1: 38739974.57882868 allocations / second (system operator new)
2: 183240796.7309842 allocations / second (tfwpool)
3: 77259572.07468219 allocations / second (boost::pool_allocator)
4: 79126882.32962202 allocations / second (boost::pool_allocator)
5: 238646397.6326277 allocations / second (boost::fast_pool_allocator)
6: 254717365.6111179 allocations / second (boost::fast_pool_allocator)
2 / 1: 473.001850732047% boost

The boost::fast_pool_allocator is as fast but there is no need to define 
the type at compile-time.


Thanks for your time,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 9061 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170112/205ba32b/attachment.cpp>

From bstottle at ford.com  Fri Jan 13 02:58:45 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Fri, 13 Jan 2017 01:58:45 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
Message-ID: <F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>

On 12 January 2017 at 08:39, Lars Knoll wrote:

>From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>points in the list above that haven't been discussed yet here?

Moving the points to below instead of above.  My opinion is (obviously) biased.

>* The module solves a problem our users have
>  - It either implements new and so far non existent functionality
>  - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)

It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
this way:

The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
QtRO is trying to solve.

QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.

My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.

>* The module builds inside the Qt build system on all platforms
>    - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>* The module is CI controlled

Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
qt.io.  If not, what options are there?

>* There is a decent set of automated tests covering the main functionality and most of the API of the module
>  - The tests pass on all platforms where the module is supported
>* APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>* Architecture makes sense
>* It follows the Qt coding style and conventions
>* Implementation has been checked for sanity
>  - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)

For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Regards,
Brett

From tim at klingt.org  Fri Jan 13 07:15:41 2017
From: tim at klingt.org (Tim Blechmann)
Date: Fri, 13 Jan 2017 14:15:41 +0800
Subject: [Development] New Qt 5.8 rc snapshot for testing
In-Reply-To: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>
Message-ID: <7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>

> All known blockers should be fixed in these packages and we are
> targeting to release Qt 5.8.0 Tue 17^th January if nothing really
> serious found during testing. So please inform me immediately if there
> is some new blocker in the packages.

QTBUG-56163 is the main blocker for me, which prevents me from migrating
to qt-5.8. have already reported it 3 months ago and requested it via
the commercial support.

thanks a lot,
tim


> 
>  
> 
> Please update known issues page
> (https://wiki.qt.io/Qt_5.8.0_Known_Issues) when needed as well
> 
>  
> 
> br,
> 
> Jani
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 




From lars.knoll at qt.io  Fri Jan 13 08:24:51 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Fri, 13 Jan 2017 07:24:51 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
Message-ID: <51AC534B-E205-4D43-805D-057CB67C718E@qt.io>

Hi Brett,


> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
> 
> On 12 January 2017 at 08:39, Lars Knoll wrote:
> 
>> From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>> points in the list above that haven't been discussed yet here?
> 
> Moving the points to below instead of above.  My opinion is (obviously) biased.
> 
>> * The module solves a problem our users have
>> - It either implements new and so far non existent functionality
>> - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
> 
> It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
> different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
> this way:
> 
> The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
> distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
> run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
> QtRO is trying to solve.
> 
> QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
> common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
> though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
> in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
> instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
> values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.
> 
> My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.

Agreed.
> 
>> * The module builds inside the Qt build system on all platforms
>>   - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>> * The module is CI controlled
> 
> Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
> ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
> Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
> not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
> accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
> qt.io.  If not, what options are there?

It should be pretty straightforward to enable CI on the module. Pre-conditions are mainly that it’s structured like the other Qt modules. Frederik & Simon what would it take to enable CI on it?
> 
>> * There is a decent set of automated tests covering the main functionality and most of the API of the module
>> - The tests pass on all platforms where the module is supported
>> * APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>> * Architecture makes sense
>> * It follows the Qt coding style and conventions
>> * Implementation has been checked for sanity
>> - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)
> 
> For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
> I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
> for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Agree, it needs a bit of review and of course it’s subjective on how strict one wants to be on the criteria. I don’t see it as a problem that it’s still using C++98, although at least the API should be reviewed to be making use of C++11 before it moves out of TP. I’ll try to have a look at the module over the weekend, and will see if I can find someone else to help.

Cheers,
Lars


From Simon.Hausmann at qt.io  Fri Jan 13 08:38:14 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Fri, 13 Jan 2017 07:38:14 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
Message-ID: <4778f282-e54c-4ad7-bfbd-d63d4fe45b9b@qt.io>

Hi,

From a CI perspective nothing needs to be done.

From the Gerrit side the UI needs to be changed from submit to merge to staging. Gerrit admins can do that.

The module itself needs to support "make install" and be able to run tests against the installed version of the module.

By default the module will be built against the dev branch of qt5.git. If you use for example a 5.8 branch in qtro, then we'll use qt5 5.8. (there are more options, but this is the gist :)

There are a few modules outside of qt/ that are also CI controlled, it's a rather common thing.

Simon


________________________________
From: Lars Knoll
Sent: Jan 13, 2017 08:25
To: Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9


Hi Brett,


> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
>
> On 12 January 2017 at 08:39, Lars Knoll wrote:
>
>> From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>> points in the list above that haven't been discussed yet here?
>
> Moving the points to below instead of above.  My opinion is (obviously) biased.
>
>> * The module solves a problem our users have
>> - It either implements new and so far non existent functionality
>> - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
>
> It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
> different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
> this way:
>
> The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
> distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
> run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
> QtRO is trying to solve.
>
> QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
> common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
> though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
> in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
> instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
> values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.
>
> My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.

Agreed.
>
>> * The module builds inside the Qt build system on all platforms
>>   - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>> * The module is CI controlled
>
> Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
> ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
> Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
> not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
> accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
> qt.io.  If not, what options are there?

It should be pretty straightforward to enable CI on the module. Pre-conditions are mainly that it’s structured like the other Qt modules. Frederik & Simon what would it take to enable CI on it?
>
>> * There is a decent set of automated tests covering the main functionality and most of the API of the module
>> - The tests pass on all platforms where the module is supported
>> * APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>> * Architecture makes sense
>> * It follows the Qt coding style and conventions
>> * Implementation has been checked for sanity
>> - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)
>
> For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
> I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
> for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Agree, it needs a bit of review and of course it’s subjective on how strict one wants to be on the criteria. I don’t see it as a problem that it’s still using C++98, although at least the API should be reviewed to be making use of C++11 before it moves out of TP. I’ll try to have a look at the module over the weekend, and will see if I can find someone else to help.

Cheers,
Lars

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/1ad2d5aa/attachment.html>

From Simon.Hausmann at qt.io  Fri Jan 13 09:22:37 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Fri, 13 Jan 2017 08:22:37 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
Message-ID: <d7e53f21-d6a9-44a3-b133-7d5757f32a85@qt.io>

Hi,

I scheduled a test build in the CI against 5.8 (as dev continues to be broken). The results are public at


http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1484293648911

There are few issues:

1) namespaced build doesn't work
2) license check fails
3) tests run qmake infinitely on Windows.
4) winrt / msvc 2013 build broken



Simon
________________________________
From: Simon Hausmann
Sent: Jan 13, 2017 08:38
To: Lars Knoll; Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

Hi,

From a CI perspective nothing needs to be done.

From the Gerrit side the UI needs to be changed from submit to merge to staging. Gerrit admins can do that.

The module itself needs to support "make install" and be able to run tests against the installed version of the module.

By default the module will be built against the dev branch of qt5.git. If you use for example a 5.8 branch in qtro, then we'll use qt5 5.8. (there are more options, but this is the gist :)

There are a few modules outside of qt/ that are also CI controlled, it's a rather common thing.

Simon


________________________________
From: Lars Knoll
Sent: Jan 13, 2017 08:25
To: Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9


Hi Brett,


> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
>
> On 12 January 2017 at 08:39, Lars Knoll wrote:
>
>> From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>> points in the list above that haven't been discussed yet here?
>
> Moving the points to below instead of above.  My opinion is (obviously) biased.
>
>> * The module solves a problem our users have
>> - It either implements new and so far non existent functionality
>> - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
>
> It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
> different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
> this way:
>
> The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
> distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
> run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
> QtRO is trying to solve.
>
> QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
> common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
> though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
> in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
> instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
> values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.
>
> My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.

Agreed.
>
>> * The module builds inside the Qt build system on all platforms
>>   - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>> * The module is CI controlled
>
> Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
> ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
> Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
> not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
> accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
> qt.io.  If not, what options are there?

It should be pretty straightforward to enable CI on the module. Pre-conditions are mainly that it’s structured like the other Qt modules. Frederik & Simon what would it take to enable CI on it?
>
>> * There is a decent set of automated tests covering the main functionality and most of the API of the module
>> - The tests pass on all platforms where the module is supported
>> * APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>> * Architecture makes sense
>> * It follows the Qt coding style and conventions
>> * Implementation has been checked for sanity
>> - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)
>
> For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
> I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
> for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Agree, it needs a bit of review and of course it’s subjective on how strict one wants to be on the criteria. I don’t see it as a problem that it’s still using C++98, although at least the API should be reviewed to be making use of C++11 before it moves out of TP. I’ll try to have a look at the module over the weekend, and will see if I can find someone else to help.

Cheers,
Lars

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/3ce4c548/attachment.html>

From rjvbertin at gmail.com  Fri Jan 13 11:28:39 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 13 Jan 2017 11:28:39 +0100
Subject: [Development] Reusing Qt code (or: saving .ico files)
Message-ID: <37132297.spU1lHXOGd@bola>

Hello,

Can someone please have a look at the KDE RR below and tell us whether or not it's OK to include qicohandler.* the way I propose in the patch under review? There are some whitespace changes and I added a preprocessor token to exclude ico read support.
My understanding of the GPL legalese is that it should be OK but Christoph is right that we have to double-check.

Maybe we all overlooked something and there is another way to create .ico files, without needing to use (and thus include) QtIcoHandler explicitly? I see that the relevant QtBase code is built on Linux and Mac but I cannot tell whether it is also installed (the header isn't in any case).

Thanks,
René

-------------------------------
Forwarded message:
Date: Friday January 13 2017
From: Christoph Feck <cfeck at kde.org>
Subject: Re: Review Request 129807: proposal: add ksvg2ico

https://git.reviewboard.kde.org/r/129807/#review101968


Someone more experienced with legal matters should review the verbatim inclusion of Qt code; in particular the license header.

- Christoph Feck



From xbenlau at gmail.com  Fri Jan 13 11:38:05 2017
From: xbenlau at gmail.com (Ben Lau)
Date: Fri, 13 Jan 2017 18:38:05 +0800
Subject: [Development] New Qt 5.8 rc snapshot for testing
In-Reply-To: <7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>
References: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>
Message-ID: <CAAq4oL+ynH6DSTu3NJSCbvbUDjTYAHqSN-dm+ZEOnzyugZACSQ@mail.gmail.com>

On 13 January 2017 at 14:15, Tim Blechmann <tim at klingt.org> wrote:

> > All known blockers should be fixed in these packages and we are
> > targeting to release Qt 5.8.0 Tue 17^th January if nothing really
> > serious found during testing. So please inform me immediately if there
> > is some new blocker in the packages.
>
> QTBUG-56163 is the main blocker for me, which prevents me from migrating
> to qt-5.8. have already reported it 3 months ago and requested it via
> the commercial support.
>
> thanks a lot,
> tim
>

I just submitted QTBUG-58133 on yesterday. It will make applications that
use QuickFlux crash when passing a signal with QJSValue (isUndefined ==
true) via a C++ class to QML.

https://bugreports.qt.io/browse/QTBUG-58133
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/845f1bff/attachment.html>

From annulen at yandex.ru  Fri Jan 13 11:52:36 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 13 Jan 2017 13:52:36 +0300
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <37132297.spU1lHXOGd@bola>
References: <37132297.spU1lHXOGd@bola>
Message-ID: <935581484304756@web2h.yandex.ru>



13.01.2017, 13:29, "René J.V. Bertin" <rjvbertin at gmail.com>:
> Hello,
>
> Can someone please have a look at the KDE RR below and tell us whether or not it's OK to include qicohandler.* the way I propose in the patch under review? There are some whitespace changes and I added a preprocessor token to exclude ico read support.
> My understanding of the GPL legalese is that it should be OK but Christoph is right that we have to double-check.
>
> Maybe we all overlooked something and there is another way to create .ico files, without needing to use (and thus include) QtIcoHandler explicitly? I see that the relevant QtBase code is built on Linux and Mac but I cannot tell whether it is also installed (the header isn't in any case).

Why not just use QImageWriter?

>
> Thanks,
> René
>
> -------------------------------
> Forwarded message:
> Date: Friday January 13 2017
> From: Christoph Feck <cfeck at kde.org>
> Subject: Re: Review Request 129807: proposal: add ksvg2ico
>
> https://git.reviewboard.kde.org/r/129807/#review101968
>
> Someone more experienced with legal matters should review the verbatim inclusion of Qt code; in particular the license header.
>
> - Christoph Feck
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From a.volkov at rusbitech.ru  Fri Jan 13 11:58:48 2017
From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=)
Date: Fri, 13 Jan 2017 13:58:48 +0300
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <935581484304756@web2h.yandex.ru>
References: <37132297.spU1lHXOGd@bola> <935581484304756@web2h.yandex.ru>
Message-ID: <b33d52c0-b382-75e1-012f-8f04ceb9666c@rusbitech.ru>

13.01.2017 13:52, Konstantin Tokarev пишет:
> Why not just use QImageWriter?
QImageWriter doesn't support wrting miltiple images into one file.
I wonder is there a bugreport for it?


From annulen at yandex.ru  Fri Jan 13 12:01:10 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 13 Jan 2017 14:01:10 +0300
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <37132297.spU1lHXOGd@bola>
References: <37132297.spU1lHXOGd@bola>
Message-ID: <994221484305270@web2h.yandex.ru>



13.01.2017, 13:29, "René J.V. Bertin" <rjvbertin at gmail.com>:
> Hello,
>
> Can someone please have a look at the KDE RR below and tell us whether or not it's OK to include qicohandler.* the way I propose in the patch under review? There are some whitespace changes and I added a preprocessor token to exclude ico read support.
> My understanding of the GPL legalese is that it should be OK but Christoph is right that we have to double-check.

Your ksvg2ico.cpp is licensed as LGPL 2.1 or 3, while QtIcoHandler is licensed as LGPL3, so combined work cannot be used as LGPL 2.1. If these is fine, I don't see any problems here (but IANAL)

Alternatively you can import QtIcoHandler from Qt 5.6 which is licensed as LGPL 2.1


>
> Maybe we all overlooked something and there is another way to create .ico files, without needing to use (and thus include) QtIcoHandler explicitly? I see that the relevant QtBase code is built on Linux and Mac but I cannot tell whether it is also installed (the header isn't in any case).
>
> Thanks,
> René
>
> -------------------------------
> Forwarded message:
> Date: Friday January 13 2017
> From: Christoph Feck <cfeck at kde.org>
> Subject: Re: Review Request 129807: proposal: add ksvg2ico
>
> https://git.reviewboard.kde.org/r/129807/#review101968
>
> Someone more experienced with legal matters should review the verbatim inclusion of Qt code; in particular the license header.
>
> - Christoph Feck
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From a.volkov at rusbitech.ru  Fri Jan 13 12:42:19 2017
From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=)
Date: Fri, 13 Jan 2017 14:42:19 +0300
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <b33d52c0-b382-75e1-012f-8f04ceb9666c@rusbitech.ru>
References: <37132297.spU1lHXOGd@bola> <935581484304756@web2h.yandex.ru>
	<b33d52c0-b382-75e1-012f-8f04ceb9666c@rusbitech.ru>
Message-ID: <a5246d5b-4e67-9a3e-1c37-80de7a9a32e1@rusbitech.ru>

13.01.2017 13:58, Александр Волков пишет:
> 13.01.2017 13:52, Konstantin Tokarev пишет:
>> Why not just use QImageWriter?
> QImageWriter doesn't support wrting miltiple images into one file.
>

Possible fix: https://codereview.qt-project.org/#/c/182255/


From rjvbertin at gmail.com  Fri Jan 13 12:59:16 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 13 Jan 2017 12:59:16 +0100
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <994221484305270@web2h.yandex.ru>
References: <37132297.spU1lHXOGd@bola> <994221484305270@web2h.yandex.ru>
Message-ID: <5098360.QcEkbXOYpa@portia.local>

On Friday January 13 2017 14:01:10 Konstantin Tokarev wrote:

Hi,


> Alternatively you can import QtIcoHandler from Qt 5.6 which is licensed as LGPL 2.1

Thanks, that'd be easy, only the license is different, nothing else :)



> Why not just use QImageWriter?

I understand from CodeReview 182255 that I'd have to call QImageWriter::write() for each individual image?

If that works cross-platform it would evidently be better.

R.


From Simon.Hausmann at qt.io  Fri Jan 13 13:23:47 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Fri, 13 Jan 2017 12:23:47 +0000
Subject: [Development] New Qt 5.8 rc snapshot for testing
In-Reply-To: <CAAq4oL+ynH6DSTu3NJSCbvbUDjTYAHqSN-dm+ZEOnzyugZACSQ@mail.gmail.com>
References: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>,
	<CAAq4oL+ynH6DSTu3NJSCbvbUDjTYAHqSN-dm+ZEOnzyugZACSQ@mail.gmail.com>
Message-ID: <VI1PR02MB100629CA8DF41B49546F9B188C780@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither

a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing

and I'll fix it.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Ben Lau <xbenlau at gmail.com>
Sent: Friday, January 13, 2017 11:38:05 AM
To: Tim Blechmann
Cc: development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] New Qt 5.8 rc snapshot for testing


On 13 January 2017 at 14:15, Tim Blechmann <tim at klingt.org<mailto:tim at klingt.org>> wrote:
> All known blockers should be fixed in these packages and we are
> targeting to release Qt 5.8.0 Tue 17^th January if nothing really
> serious found during testing. So please inform me immediately if there
> is some new blocker in the packages.

QTBUG-56163 is the main blocker for me, which prevents me from migrating
to qt-5.8. have already reported it 3 months ago and requested it via
the commercial support.

thanks a lot,
tim

I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML.

https://bugreports.qt.io/browse/QTBUG-58133

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/66bef7d9/attachment.html>

From Simon.Hausmann at qt.io  Fri Jan 13 13:31:18 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Fri, 13 Jan 2017 12:31:18 +0000
Subject: [Development] New Qt 5.8 rc snapshot for testing
In-Reply-To: <VI1PR02MB100629CA8DF41B49546F9B188C780@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2513F6B1D366849DEAC673A39D660@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>,
	<CAAq4oL+ynH6DSTu3NJSCbvbUDjTYAHqSN-dm+ZEOnzyugZACSQ@mail.gmail.com>,
	<VI1PR02MB100629CA8DF41B49546F9B188C780@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB100645B06F63BDF836D18F578C780@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


Slight correction: It's not a regression against 5.7, but it is still a regression [☹] . I'll fix it ASAP for 5.8.1 and

back-port it also to the 5.6 branch.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Friday, January 13, 2017 1:23:47 PM
To: Ben Lau; Tim Blechmann
Cc: development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] New Qt 5.8 rc snapshot for testing


Hi,


While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither

a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing

and I'll fix it.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Ben Lau <xbenlau at gmail.com>
Sent: Friday, January 13, 2017 11:38:05 AM
To: Tim Blechmann
Cc: development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] New Qt 5.8 rc snapshot for testing


On 13 January 2017 at 14:15, Tim Blechmann <tim at klingt.org<mailto:tim at klingt.org>> wrote:
> All known blockers should be fixed in these packages and we are
> targeting to release Qt 5.8.0 Tue 17^th January if nothing really
> serious found during testing. So please inform me immediately if there
> is some new blocker in the packages.

QTBUG-56163 is the main blocker for me, which prevents me from migrating
to qt-5.8. have already reported it 3 months ago and requested it via
the commercial support.

thanks a lot,
tim

I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML.

https://bugreports.qt.io/browse/QTBUG-58133

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/2cd5f9e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-☹.png
Type: image/png
Size: 506 bytes
Desc: OutlookEmoji-☹.png
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/2cd5f9e4/attachment.png>

From rjvbertin at gmail.com  Fri Jan 13 14:07:41 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 13 Jan 2017 14:07:41 +0100
Subject: [Development] Reusing Qt code (or: saving .ico files)
In-Reply-To: <935581484304756@web2h.yandex.ru>
References: <37132297.spU1lHXOGd@bola> <935581484304756@web2h.yandex.ru>
Message-ID: <2901290.XOAmKUFTaC@bola>

On Friday January 13 2017 13:52:36 Konstantin Tokarev wrote:

>Why not just use QImageWriter?

Because it doesn't append but writes only a single image, the 1st image in the sequence, suprisingly (and I presume not just on Friday the 13th :)) ?

R


From rjvbertin at gmail.com  Fri Jan 13 14:21:12 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 13 Jan 2017 14:21:12 +0100
Subject: [Development] Reusing Qt code (or: saving .ico files)
References: <37132297.spU1lHXOGd@bola> <935581484304756@web2h.yandex.ru>
	<b33d52c0-b382-75e1-012f-8f04ceb9666c@rusbitech.ru>
	<a5246d5b-4e67-9a3e-1c37-80de7a9a32e1@rusbitech.ru>
Message-ID: <12191218.I3xgYPVFSh@patux.local>

Александр Волков wrote:

> 13.01.2017 13:58, Александр Волков пишет:
>> 13.01.2017 13:52, Konstantin Tokarev пишет:
>>> Why not just use QImageWriter?
>> QImageWriter doesn't support wrting miltiple images into one file.
>>
> 
> Possible fix: https://codereview.qt-project.org/#/c/182255/

Yep, that should do the trick: QtIcoHandler always supported writing multiple 
images, it was just not exposed through the QImageWriter API.

Qt is late to catch up with the animage GIF hype! ;)

R.



From rjvbertin at gmail.com  Fri Jan 13 14:45:02 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 13 Jan 2017 14:45:02 +0100
Subject: [Development] QtIcoHandler
Message-ID: <2100680.mRqu2vfzqZ@bola>

FYI,

I'm tinkering with writing .ico files and tried to visualise the result on Linux, which gave me an error message:

%> gwenview5 test.ico
QImageReader::read() using format hint "ico" failed: "Unknown error"
A bad Qt image decoder moved the buffer to 22 in a call to canRead()! Rewinding.
Image format is actually "ico" not "ico"

This is with Qt 5.7.1 , and it happens with ico files created by QtIcoHandler itself, and with the 3rd party icotool utility. The number of icons in the file makes no difference.

Is this a bug?

R.


From soroush.rabiei at gmail.com  Fri Jan 13 15:07:32 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Fri, 13 Jan 2017 17:37:32 +0330
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma> <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
	<HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <CAOMsk2QhM+C3WgxknMgeTjjmRVe0AD6ZpH_guFDOVn7bW+xrvw@mail.gmail.com>

Sorry for being noisy on this list, but I think we have several issues
needed discussion before going further.

First we have a design decision to make, the minimal set of
assumptions on calendaring systems. According to my minute research we
can assume following facts on every calendar that is in-use:

1. All calendaring systems, show dates in three levels: Year, Month and Day
2. The week is 7 days. It may start at any of these days.
3. Number of months in all years are fixed.

Please let me know about any problem.

Second issue is on CLDR data. I was all mistaken about CLDR. The new
versions (including v29) include month name data for many calendars
(Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew,
Indian, Islamic, Japanese and Persian). I managed to modify the
scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for
Jalali calendar (named as Persian in CLDR terminology). On the other
hand, QLocale integration is completed. Now there is `months_data_per'
array in qlocale_data_p.h and it's working well.

The problem however, is that this data is bigger than what I had in
mind. Apparently there are many communities using Jalali calendars.
There are strange month names for Korean, Russian, Turkish and several
more. (I was expecting data only for Persian and Afghani languages,
maybe Tajik too...) The array containing month names is 2419 bytes.
There is also another 6*2=12 bytes per locale in locale's index table.
considering number of supported locales in qt, we will have 552 * 12 =
6624 bytes there and as a result  the overhead in Qt's binary, will be
9.043 KB only for Jalali calendar. Islamic civil calendar is almost
three times bigger if I'm not much mistaken, and I have no idea about
other calendars. I guess adding five calendars will blow QtCore up to
5~7 Megabytes.

I have changed qlocalexml2cpp.py such that it generates data for each
calendar in a separate array. So it can be excluded by preprocessor
directives. My suggestion is to make calendaring support,
configurable, and provide data only for Gregorian calendar by default.
And also we can give users the option to choose among locales they
want to include in their builds:

    ./configure -developer-build -opensource -confirm-license -debug
-calendars gregorian,persian,islamic_civil

Cheers,
Soroush


From edward.welbourne at qt.io  Fri Jan 13 15:46:20 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Fri, 13 Jan 2017 14:46:20 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2QhM+C3WgxknMgeTjjmRVe0AD6ZpH_guFDOVn7bW+xrvw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>	<29088300.rDUCxivhrG@port-fma>
	<5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
	<HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<CAOMsk2QhM+C3WgxknMgeTjjmRVe0AD6ZpH_guFDOVn7bW+xrvw@mail.gmail.com>
Message-ID: <HE1PR0202MB26837C2F80D963246E4537AB87780@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Soroush Rabiei
> Sorry for being noisy on this list, but I think we have several issues
> needed discussion before going further.

I should note that Lars still holds to the view that we should keep this
out of QDate: which seems to imply roughly just upstreaming
KCalendarSystem, albeit with the opportunity to make any improvements we
want in the process.

> First we have a design decision to make, the minimal set of
> assumptions on calendaring systems. According to my minute research we
> can assume following facts on every calendar that is in-use:
>
> 1. All calendaring systems, show dates in three levels: Year, Month and Day
> 2. The week is 7 days. It may start at any of these days.

French revolutionary calendar:
https://en.wikipedia.org/wiki/French_Republican_Calendar
Not that I propose supporting it !

However, it would be best to design a system which doesn't preclude
someone else implementing it.  If we can avoid hard-coding the
assumption of a seven-day week, so much the better.

> 3. Number of months in all years are fixed.

Is there no lunar calendar with occasional extra months ?

> Please let me know about any problem.
>
> Second issue is on CLDR data. I was all mistaken about CLDR. The new
> versions (including v29) include month name data for many calendars
> (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew,
> Indian, Islamic, Japanese and Persian). I managed to modify the
> scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for
> Jalali calendar (named as Persian in CLDR terminology). On the other
> hand, QLocale integration is completed. Now there is `months_data_per'
> array in qlocale_data_p.h and it's working well.
>
> The problem however, is that this data is bigger than what I had in
> mind. Apparently there are many communities using Jalali calendars.
> There are strange month names for Korean, Russian, Turkish and several
> more. (I was expecting data only for Persian and Afghani languages,
> maybe Tajik too...) The array containing month names is 2419 bytes.
> There is also another 6*2=12 bytes per locale in locale's index table.
> considering number of supported locales in qt, we will have 552 * 12 =
> 6624 bytes there and as a result  the overhead in Qt's binary, will be
> 9.043 KB only for Jalali calendar. Islamic civil calendar is almost
> three times bigger if I'm not much mistaken, and I have no idea about
> other calendars. I guess adding five calendars will blow QtCore up to
> 5~7 Megabytes.

Not something we want to impose on all users of Qt.

> I have changed qlocalexml2cpp.py such that it generates data for each
> calendar in a separate array. So it can be excluded by preprocessor
> directives. My suggestion is to make calendaring support,
> configurable, and provide data only for Gregorian calendar by default.
> And also we can give users the option to choose among locales they
> want to include in their builds:
>
>     ./configure -developer-build -opensource -confirm-license -debug -calendars gregorian,persian,islamic_civil

That sounds reasonable.  Another approach might be to design a
plugin-based architecture - with similar config, but controlling which
plugins get built.  This would make life easier for anyone who wants to
add a calendar system we don't support: they'd just need to add their
plugin to wherever we put ours.

        Eddy.


From oswald.buddenhagen at qt.io  Fri Jan 13 16:09:43 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Fri, 13 Jan 2017 16:09:43 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
Message-ID: <20170113150943.GB21340@troll08>

On Fri, Jan 13, 2017 at 01:58:45AM +0000, Stottlemyer, Brett (B.S.) wrote:
> On 12 January 2017 at 08:39, Lars Knoll wrote:
> >* The module solves a problem our users have
> >  - It either implements new and so far non existent functionality
> >  - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
> 
> It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
> different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
> this way:
> 
> The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
> distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
> run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
> QtRO is trying to solve.
> 
> QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
> common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
> though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
> in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
> instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
> values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.
> 
> My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.
> 
for my taste, there are way too many inconclusive/irrelevant details in
this description. a more layer-oriented approach would be more
convincing imo:

qtdbus is a pure rpc layer.

qtro is a distributed object layer which builds on top of rpc. signals
and slots are exposed rpc. no idea whether you implemented property
propagation on top of generic rpc or via a dedicated protocol part, but
that's just an implementation detail.
it would be perfectly feasible to implement qtro over qtdbus (networked
dbus has been on the table for a decade; dunno if somebody ever pulled
it off).

qtserviceframework is a registration/management layer on top of (local)
rpc.
its intended use appears to be more the creation of platforms rather
than applications, which might explain why it's now bitrotting. ;)
it appears to me that it would be possible to build it on top of a
higher-level representation like qtro, but principally it's indeed rather
orthogonal.


from a purely design perspective, it would seem optimal to have a QtRpc
system of which QtDbus provides a concrete implementation, while QtRo
would be the state extension building on top of it. this would imply
multiple inheritance for an actual instance of qtro.
the principal advantage of this would be a shared idl and surrouding
tooling, which would reduce redundancy on the implementation side.

otoh, we have the existing implementations, and in particular qtdbus
really isn't at a point where it could be just redesigned. we can't drop
the existing qtdbus-xml, and it would be sado-maso to make .rep an
extension of that format.

a more realistic appoach would be having qtdbus as an "invisible"
backend implementation of the generalized qtrpc. note that
qtserviceframework has some of this, which is probably why alex
considered it relevant in the first place.
so a concrete action point would be investigating in how for it's
possible (and actually sensible) to factor out the rpc layer (including
the underlying transport layer, obviously).


it's not really clear to me why you're apparently discarding the idea of
integrating qtro with other object distribution frameworks at the
outset. the systems really aren't fundamentally different, and providing
such integrations may significantly improve qtro adoption where a system
is already established (or is being prescribed).



From marc.mutz at kdab.com  Fri Jan 13 18:41:00 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 13 Jan 2017 18:41:00 +0100
Subject: [Development] Source break policy for function overloads
In-Reply-To: <01A11EC3-A5B5-458A-9A51-14CD84B7DAE0@qt.io>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<6279245.f20ygS2Rua@tjmaciei-mobl1>
	<201607132010.26585.marc.mutz@kdab.com>
	<01A11EC3-A5B5-458A-9A51-14CD84B7DAE0@qt.io>
Message-ID: <7c24cf468e6861730dbafaf97f374c65@kdab.com>

On 2016-07-13 23:55, Lars Knoll wrote:
>> On 13 Jul 2016, at 20:10, Marc Mutz <marc.mutz at kdab.com> wrote:
[...]
>> It should also be noted that there are two categories of SiCs:
>> 
>> a. those that can be fixed client-side without breaking compat with 
>> older Qt
>>   versions, and
>> b. those which cannot
>> 
>> IMO, SiCs of type (a) are acceptable, those of type (b) are obviously 
>> no-no's.
>> 
>> Adding an overload (both cases: 1 + 2 above) is type (a), so is 
>> acceptable.
>> Adding explicit to a ctor that should have been but wasn't is also SiC 
>> Type
>> (a). In these cases, code that breaks is code that deserves to be 
>> broken,
>> because it was brittle.
>> 
>> Renaming a public inline function of a non-exported class is BC, but 
>> SiC Type
>> (b), so not acceptable.
> 
> I think Marc has summed it up very nicely. This is IMO exactly the
> policy we should apply.

QUIP 6 has been created from this:
https://codereview.qt-project.org/182311



From samuel.gaist at edeltech.ch  Fri Jan 13 23:58:42 2017
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Fri, 13 Jan 2017 23:58:42 +0100
Subject: [Development] New library in qtbase
In-Reply-To: <E7927687-0BEE-4A2B-ACA5-0F17BFD3A732@qt.io>
References: <EF33B9A6-DCF6-4DBF-9006-FB22B6EE1BA4@edeltech.ch>
	<13507339.QtWAKzEl5T@tjmaciei-mobl1>
	<00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch>
	<2976940.gPpOHW8DdO@tjmaciei-mobl1>
	<9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch>
	<5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io>
	<938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch>
	<o1qkd0$1er$2@blaine.gmane.org>
	<357754E1-D65A-4037-948D-CCDA582D2D97@qt.io>
	<o1t0ic$3pa$1@blaine.gmane.org>
	<E7927687-0BEE-4A2B-ACA5-0F17BFD3A732@qt.io>
Message-ID: <2ED199A8-0E6C-4EEE-9CE1-9F32C72BFA8B@edeltech.ch>


> On 6 Dec 2016, at 15:44, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> 
> 
>> On 3 Dec 2016, at 00:36, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> 
>> Shawn Rutledge wrote:
>>> http://www.galago-project.org/about.php
>>> 
>>> sounds like it’s just for “presence” to tell instant-messaging clients
>>> whether you are using the computer or not.
>> 
>> I did not suggest you use the Galago software, just this specification:
>> https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html
>> older versions of which were hosted on:
>> http://www.galago-project.org/specs/notification/
>> (which is how it came to be known as the "Galago (notification) spec”).
> 
> That page doesn’t mention Galago.  Anyway org.freedesktop.Notifications is the specification we are already using in qtbase/src/platformsupport/dbustray.
> 
> But we know that increasingly notifications are being used independently from tray icons, and that basically every platform has some kind of notifications, so maybe we’ll end up with another Qt API for that eventually.  It’s unintuitive that if you only want to show notifications but don’t need a tray icon, you have to use QSystemTrayIcon::showMessage().
> 
>> If you want to use an existing library, libnotify is what you are looking
>> for:
>> https://developer.gnome.org/libnotify/
> 
> Well why should Qt depend on another library which does the D-Bus communication in its own way, when we already have Qt D-Bus?
> 
>> All these are GNOME URLs, but the protocol is also supported by KDE Plasma
>> and by other desktop environments:
>> https://wiki.archlinux.org/index.php/Desktop_notifications
> 
> Yeah, that was the idea of implementing it that way, to get it working on Gnome and Ubuntu and KDE.
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi guys,

Thanks for the suggestions provided.

However this is now derailing the thread’s original purpose: decide where the notification related stuff should go.

Short summary, we have three possibilities:
1) Own module (and current implementation)
2) One “core" module and one GUI module to separate concerns for system not requiring a GUI connection (Jake’s suggestion)
3) Put everything in QtGui and implement the stuff in the QPA parts with the implication that a QGuiApplication will be required.

Can we come to an agreement about which one to implement ?

Note that creating a completely separated module (meaning out of qtbase) is not an option since one of the goal beside providing our fellow developers an easy to use API is to replace the current QSystemTrayIcon code with the use of that module and it wouldn’t make sense to have qtbase depending on an external module.

Just to be clear, we are talking here about local notifications not push notifications. That’s another subject with other requirements.

Thanks,
Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/81fbc4e4/attachment.sig>

From kevin.kofler at chello.at  Sat Jan 14 01:09:26 2017
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 14 Jan 2017 01:09:26 +0100
Subject: [Development] Calendar Systems proposal
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma> <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
	<HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2QhM+C3WgxknMgeTjjmRVe0AD6ZpH_guFDOVn7bW+xrvw@mail.gmail.com>
	<HE1PR0202MB26837C2F80D963246E4537AB87780@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <o5bq7i$j40$1@blaine.gmane.org>

Edward Welbourne wrote:

> Soroush Rabiei
>> 3. Number of months in all years are fixed.
> 
> Is there no lunar calendar with occasional extra months ?

Of course there is. Any lunar calendar adjusted for consistency with the 
solar year necessarily has occasional intercalar months. The Jewish calendar 
is the most prominent example. (The Islamic calendar, on the other hand, is 
the most prominent example of a lunar calendar that is NOT adjusted for the 
solar year, which explains why e.g. Ramadan rotates all over the solar year 
over the years.)

        Kevin Kofler



From devel at g76r.eu  Sat Jan 14 13:33:32 2017
From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=)
Date: Sat, 14 Jan 2017 13:33:32 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB26837C2F80D963246E4537AB87780@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma> <5648737.pvz8ZeChiJ@tjmaciei-mobl1>
	<HE1PR0202MB26832095B17BA3C7F0FE650A87600@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2SYsSbbWppSN0yJi3+A+dPgPWkrckLv6oN06j6UQ4a4Uw@mail.gmail.com>
	<HE1PR0202MB2683D2EB383796E879B987D087640@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2QhM+C3WgxknMgeTjjmRVe0AD6ZpH_guFDOVn7bW+xrvw@mail.gmail.com>
	<HE1PR0202MB26837C2F80D963246E4537AB87780@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <9ae7ddd0-be11-0e98-157b-ce20c200531b@g76r.eu>

Le 13/01/2017 à 15:46, Edward Welbourne a écrit :
> Soroush Rabiei
>> 1. All calendaring systems, show dates in three levels: Year, Month and Day
>> 2. The week is 7 days. It may start at any of these days.
> French revolutionary calendar:
> https://en.wikipedia.org/wiki/French_Republican_Calendar
> Not that I propose supporting it !

Don't forget that in addition to weeks being 10 days, days are also 
divided into 10 decimal hours, each of them counting 100 decimal minutes.

It would be a lot of fun to support it. But not sure anyone actually 
needs that. ;-)

-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49


From jpnurmi at qt.io  Sat Jan 14 13:37:06 2017
From: jpnurmi at qt.io (J-P Nurmi)
Date: Sat, 14 Jan 2017 12:37:06 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
Message-ID: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>

Hi,

I'd like to request a WIP branch for the Qt Quick item views. There are plenty of items on the roadmap/wishlist:

- refactor QQuickItemView
  - add support for multiple delegate types (QTBUG-26681)
  - add support for multi-selection
  - add support for multiple columns
- implement TableView (QTBUG-51710)
- implement HeaderView
- implement SortFilterProxyModel
- productize TreeModelAdaptor (QTBUG-54390)

Early feedback from the CI system would be invaluable.

--
J-P Nurmi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/04bb0c30/attachment.html>

From py.siret at gmail.com  Sat Jan 14 14:06:22 2017
From: py.siret at gmail.com (Pierre-Yves Siret)
Date: Sat, 14 Jan 2017 14:06:22 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
Message-ID: <CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>

Hi,
I started implementing SortFilterProxyModel cause we needed it and
published it here : https://github.com/oKcerG/SortFilterProxyModel
For the moment it is not really documented or tested enough.
I left it kinda alone for the past couple months but I plan to do more work
on it, documenting, testing, adding some features and doing some
refactoring.
I also wanted to nominate it as a TP for 5.10.
I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
using private headers from QAIM and ItemViews, etc.).

I think what's interesting in my library is the ability to have multiple
filters and sorters declaratively (as shown in the 2nd more advanced
usecase of the readme), I also have a branch that I haven't pushed yet
where you could define new roles defined from existing source roles.

Where you thinking of that for the SortFilterProxyModel you wanted ?

One of the shortcoming of my SFPM is that it is not really meant to be used
for multiple columns, only roles, and it doesn't support tree models.

Pierre-Yves Siret

2017-01-14 13:37 GMT+01:00 J-P Nurmi <jpnurmi at qt.io>:

> Hi,
>
> I'd like to request a WIP branch for the Qt Quick item views. There are
> plenty of items on the roadmap/wishlist:
>
> - refactor QQuickItemView
>   - add support for multiple delegate types (QTBUG-26681)
>   - add support for multi-selection
>   - add support for multiple columns
> - implement TableView (QTBUG-51710)
> - implement HeaderView
> - implement SortFilterProxyModel
> - productize TreeModelAdaptor (QTBUG-54390)
>
> Early feedback from the CI system would be invaluable.
>
> --
> J-P Nurmi
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/48fac61b/attachment.html>

From jpnurmi at qt.io  Sat Jan 14 17:06:39 2017
From: jpnurmi at qt.io (J-P Nurmi)
Date: Sat, 14 Jan 2017 16:06:39 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>
Message-ID: <A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>

Hi,

Nice, looks great! It would be a very welcome contribution. We could polish and add the missing bits in the WIP branch if you’re interested? I haven’t thought about the exact details and requirements for SortFilterProxyModel yet, but we probably need to support multiple model columns. The plan is to make the new TableView support both, “proper” table models with multiple columns, and the old way of (ab)using roles as columns. :)

--
J-P Nurmi

On 14 Jan 2017, at 14:06, Pierre-Yves Siret <py.siret at gmail.com<mailto:py.siret at gmail.com>> wrote:

Hi,
I started implementing SortFilterProxyModel cause we needed it and published it here : https://github.com/oKcerG/SortFilterProxyModel
For the moment it is not really documented or tested enough.
I left it kinda alone for the past couple months but I plan to do more work on it, documenting, testing, adding some features and doing some refactoring.
I also wanted to nominate it as a TP for 5.10.
I guess it needs to be reworked before a potential inclusion in Qt (pimpl, using private headers from QAIM and ItemViews, etc.).

I think what's interesting in my library is the ability to have multiple filters and sorters declaratively (as shown in the 2nd more advanced usecase of the readme), I also have a branch that I haven't pushed yet where you could define new roles defined from existing source roles.

Where you thinking of that for the SortFilterProxyModel you wanted ?

One of the shortcoming of my SFPM is that it is not really meant to be used for multiple columns, only roles, and it doesn't support tree models.

Pierre-Yves Siret

2017-01-14 13:37 GMT+01:00 J-P Nurmi <jpnurmi at qt.io<mailto:jpnurmi at qt.io>>:
Hi,

I'd like to request a WIP branch for the Qt Quick item views. There are plenty of items on the roadmap/wishlist:

- refactor QQuickItemView
  - add support for multiple delegate types (QTBUG-26681)
  - add support for multi-selection
  - add support for multiple columns
- implement TableView (QTBUG-51710)
- implement HeaderView
- implement SortFilterProxyModel
- productize TreeModelAdaptor (QTBUG-54390)

Early feedback from the CI system would be invaluable.

--
J-P Nurmi


_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/94653ce0/attachment.html>

From robin.burchell at crimson.no  Sat Jan 14 17:24:08 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Sat, 14 Jan 2017 17:24:08 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
Message-ID: <1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>

Hi,

I (of course) wholeheartedly support work in the model/view area. It's
something that could use some TLC, and I'm excited to see what you have
cooking!

I have a longer mental list of things that concern/bother me with
current model/views (some of which we've already discussed), maybe I
should try write that up in some form, if you think it might find it
helpful, but as I don't know how much time I'll be able to dedicate to
making this happen you may prefer me to hold my tongue :-)

+1 to having a branch for it (do you have a name in mind? wip/itemviews?
wip/tableview?)

A thought, that came to mind while thinking about naming, though:
there's a lot of features listed here, and I would expect that they will
mature at different rates as some of them are more standalone, while
others might require more extensive (and careful!) work on the existing,
rather complicated code.

As a result, I start to wonder whether a single branch for all of this
makes sense, or whether it may make sense to do some smaller pieces
either directly on dev, or to use more than one WIP so that it's easier
to land stuff "when it's ready" rather than turning into a huge pile.

I have great confidence in you, of course, just trying to make life
easier along the way, so if you don't want to do this or feel that it
wouldn't be helpful to you, feel free to ignore the idea :)

(PS. I know you won't want to make hard promises, especially this early,
but do you have any idea what kind of timeframe you have in mind for
landing? Fingers crossed for "not 5.9"! ;-))

-- 
  Robin Burchell
  robin at crimson.no

On Sat, Jan 14, 2017, at 01:37 PM, J-P Nurmi wrote:
> Hi,
> 
> I'd like to request a WIP branch for the Qt Quick item views. There are
> plenty of items on the roadmap/wishlist:
> 
> - refactor QQuickItemView
>   - add support for multiple delegate types (QTBUG-26681)
>   - add support for multi-selection
>   - add support for multiple columns
> - implement TableView (QTBUG-51710)
> - implement HeaderView
> - implement SortFilterProxyModel
> - productize TreeModelAdaptor (QTBUG-54390)
> 
> Early feedback from the CI system would be invaluable.
> 
> --
> J-P Nurmi
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From b.terrier at gmail.com  Sat Jan 14 17:28:01 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Sat, 14 Jan 2017 17:28:01 +0100
Subject: [Development] invokeMethod() with function pointers
Message-ID: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>

Hi everyone,

I'm trying to contribute by making QMetaObject::invokeMethod() take function
pointers instead of function names.

I've come up with something that works by looking at the code of
QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate.

However it does not check for parameters and it is implemented as a function
of QObject (because I needed QSlotObjects classes which are not available in
qobjectdef.h). It can handle QObject member functions and functors in which
case  "this" is used to select the event loop (like connect() functions).

I've uploaded my change as a draft on gerrit:
https://codereview.qt-project.org/#/c/182339/

Here is the link to the relevant bug report:
https://bugreports.qt.io/browse/QTBUG-37253

I welcome any comment and feedback.

BR,

Benjamin Terrier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/4890467b/attachment.html>

From bstottle at ford.com  Sat Jan 14 18:07:30 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Sat, 14 Jan 2017 17:07:30 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170113150943.GB21340@troll08>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
Message-ID: <0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>

On 1/13/17, 10:09 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:



>for my taste, there are way too many inconclusive/irrelevant details in
>this description. a more layer-oriented approach would be more
>convincing imo:
>
>qtdbus is a pure rpc layer.
>
>qtro is a distributed object layer which builds on top of rpc. signals
>and slots are exposed rpc. no idea whether you implemented property
>propagation on top of generic rpc or via a dedicated protocol part, but
>that's just an implementation detail.
>it would be perfectly feasible to implement qtro over qtdbus (networked
>dbus has been on the table for a decade; dunno if somebody ever pulled
>it off).
>
>qtserviceframework is a registration/management layer on top of (local)
>rpc.
>its intended use appears to be more the creation of platforms rather
>than applications, which might explain why it's now bitrotting. ;)
>it appears to me that it would be possible to build it on top of a
>higher-level representation like qtro, but principally it's indeed rather
>orthogonal.

My interpretation was that Lars was looking for differences from a Qt user
perspective, and I think my reply was accurate from that perspective.  I
would say you are looking at it from the s/w implementation perspective,
which is absolutely valid.  And I think your description is well-stated
and accurate as well.

>from a purely design perspective, it would seem optimal to have a QtRpc
>system of which QtDbus provides a concrete implementation, while QtRo
>would be the state extension building on top of it.

[...]

>it's not really clear to me why you're apparently discarding the idea of
>integrating qtro with other object distribution frameworks at the
>outset. the systems really aren't fundamentally different, and providing
>such integrations may significantly improve qtro adoption where a system
>is already established (or is being prescribed).

If you really did mean other object distributions systems, which ones are
you thinking of?  Microsoft’s Component Object Model is interesting, but
I’m really not sure how to integrate with it.  Did you mean “integrating
QtRO with other RPC mechanisms”, in terms of layering QtRO on top of a
more abstracted RPC?  If so, I have a very specific reason: type support.
Many of the types Qt natively support do not work automatically with DBus
due to its intended interplay with other languages.  Many useful types
are defined throughout the various Qt modules, and QtRO supports them
all because Qt supports them all.  It also will auto generate streaming
operators for needed structures (PODs, in QtRO).  QtRO has extensions to
support QAIM types, passing batches of calls with QVariant responses
between processes.

In order to support an agnostic wire-format that works with different
languages, I simply believe support needs to be built into Qt itself,
not a specific module.  So QtRO is specific to Qt, while the qtdbus
module only provides a subset of types automatically, but it does provide
such a wire format (and allows you to extend the set of types with
additional code).  This has been discussed in the past.  I’m not against
the idea, I just don’t think it should be plumbed into QtRO (which it
seems like you agree with).

BTW, Ossi, would which of the build systems fixes you mentioned would

help with the qmake loop on windows CI is seeing?  ;)

Regards,
Brett



From thiago.macieira at intel.com  Sat Jan 14 18:42:11 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 14 Jan 2017 09:42:11 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
Message-ID: <25250032.7JlIbCVTYn@tjmaciei-mobl1>

On sábado, 14 de janeiro de 2017 17:28:01 PST Benjamin TERRIER wrote:
> I've uploaded my change as a draft on gerrit:
> https://codereview.qt-project.org/#/c/182339/

No one can see it while it's a draft. You have to publish the change.

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



From b.terrier at gmail.com  Sat Jan 14 18:57:20 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Sat, 14 Jan 2017 18:57:20 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <25250032.7JlIbCVTYn@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<25250032.7JlIbCVTYn@tjmaciei-mobl1>
Message-ID: <CAO+E9op7E+swR4P-uzsVZpaH0zoDbYJTRjVHRDR7h-SL_GsbXA@mail.gmail.com>

2017-01-14 18:42 GMT+01:00 Thiago Macieira <thiago.macieira at intel.com>:

>
> No one can see it while it's a draft. You have to publish the change.
>
>
 Ok, it's done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/9c61cb83/attachment.html>

From annulen at yandex.ru  Sat Jan 14 18:59:45 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sat, 14 Jan 2017 20:59:45 +0300
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <25250032.7JlIbCVTYn@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<25250032.7JlIbCVTYn@tjmaciei-mobl1>
Message-ID: <5996131484416785@web28h.yandex.ru>



14.01.2017, 20:42, "Thiago Macieira" <thiago.macieira at intel.com>:
> On sábado, 14 de janeiro de 2017 17:28:01 PST Benjamin TERRIER wrote:
>>  I've uploaded my change as a draft on gerrit:
>>  https://codereview.qt-project.org/#/c/182339/
>
> No one can see it while it's a draft. You have to publish the change.

Correction: no one except people added as reviewers.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From markg85 at gmail.com  Sat Jan 14 19:20:37 2017
From: markg85 at gmail.com (Mark Gaiser)
Date: Sat, 14 Jan 2017 19:20:37 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>
	<A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>
Message-ID: <CAPd6JnHG3AEN9VfjQpqJx=fu79jEvFprqGKif4Py9QMBpx8kfw@mail.gmail.com>

On Sat, Jan 14, 2017 at 5:06 PM, J-P Nurmi <jpnurmi at qt.io> wrote:

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
>
That new TableView is really going to support models that derive
QAbstractTableModel? Without any changes required on the model side? So if
it works in QTableView (C++ widget) then it will work in the new TableView
(QML component)?
That would be a big win!

Would the view also have transition support?
The current TableView [1] component doesn't have it, the GridView [2]
component does, but it basically only eats list models and requires role
foo..

Do you plan the new TableView to be a styled component (like one of the
many other control components) or a bare component where the user needs to
define the delegates for the contents, header and sidebar?
My preference would be a bare component.

Lots of questions ;)

[1] http://doc.qt.io/qt-5/qml-qtquick-controls-tableview.html
[2] http://doc.qt.io/qt-5/qml-qtquick-gridview.html


> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret <py.siret at gmail.com> wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi <jpnurmi at qt.io>:
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170114/b9b584e4/attachment.html>

From soroush.rabiei at gmail.com  Sun Jan 15 12:09:49 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Sun, 15 Jan 2017 14:39:49 +0330
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
Message-ID: <CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>

Just submitted first change set:

https://codereview.qt-project.org/#/c/182341/

Planning to add three more calendars and separate index array (to
reduce overhead on locales) this week. Persian calendar is still one
day behind. Seems to be related to julian day base. The original
algorithm counts day 1 as a base date.


From jpnurmi at qt.io  Sun Jan 15 12:24:31 2017
From: jpnurmi at qt.io (J-P Nurmi)
Date: Sun, 15 Jan 2017 11:24:31 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>
Message-ID: <598F59C8-3654-4475-B572-222B845EA9D7@qt.io>

Hi,

On 14 Jan 2017, at 17:24, Robin Burchell <robin.burchell at crimson.no<mailto:robin.burchell at crimson.no>> wrote:

I have a longer mental list of things that concern/bother me with
current model/views (some of which we've already discussed), maybe I
should try write that up in some form, if you think it might find it
helpful, but as I don't know how much time I'll be able to dedicate to
making this happen you may prefer me to hold my tongue :-)

There have been some discussions about rewriting the entire item-view framework. I personally believe that would be best done in a major release. :) I’m not planning to start writing a new item-view framework from scratch at this point, but refactor the internals so that it would be possible to reuse the same item view transitions etc. for a two-dimensional table view. In essence, I would like to avoid changing the basic principle how QQuickItemView works, but just split the reusable parts to a more abstract base class, for example. Ideally we wouldn’t have to touch ListView and GridView at all, and they'd continue to work at the same performance they have today.

+1 to having a branch for it (do you have a name in mind? wip/itemviews?
wip/tableview?)

I was thinking wip/itemviews, but I don’t mind wip/tableview either. :)

A thought, that came to mind while thinking about naming, though:
there's a lot of features listed here, and I would expect that they will
mature at different rates as some of them are more standalone, while
others might require more extensive (and careful!) work on the existing,
rather complicated code.

As a result, I start to wonder whether a single branch for all of this
makes sense, or whether it may make sense to do some smaller pieces
either directly on dev, or to use more than one WIP so that it's easier
to land stuff "when it's ready" rather than turning into a huge pile.

I have great confidence in you, of course, just trying to make life
easier along the way, so if you don't want to do this or feel that it
wouldn't be helpful to you, feel free to ignore the idea :)

Having more branches could be an option. All the tasks are somehow connected to each other, though, so I was thinking that it might be easiest to do it all in the same branch to avoid excessive conflicts and merging between multiple WIP-branches. The last two, SortFilterProxyModel and TreeModelAdaptor, would be the most logical ones to split to separate branches, but on the other hand, they also need to be implemented so that they play well with the rest.

(PS. I know you won't want to make hard promises, especially this early,
but do you have any idea what kind of timeframe you have in mind for
landing? Fingers crossed for "not 5.9"! ;-))

There’s so much to do that there is no way we could make all this happen before the 5.9 feature freeze in two weeks. :)

--
J-P Nurmi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170115/e3874c02/attachment.html>

From jpnurmi at qt.io  Sun Jan 15 12:37:06 2017
From: jpnurmi at qt.io (J-P Nurmi)
Date: Sun, 15 Jan 2017 11:37:06 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <CAPd6JnHG3AEN9VfjQpqJx=fu79jEvFprqGKif4Py9QMBpx8kfw@mail.gmail.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>
	<A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>
	<CAPd6JnHG3AEN9VfjQpqJx=fu79jEvFprqGKif4Py9QMBpx8kfw@mail.gmail.com>
Message-ID: <9645E31D-A292-43EA-9770-3989A4FAD0DC@qt.io>

Hi,

> On 14 Jan 2017, at 19:20, Mark Gaiser <markg85 at gmail.com> wrote:
> 
> That new TableView is really going to support models that derive QAbstractTableModel? Without any changes required on the model side? So if it works in QTableView (C++ widget) then it will work in the new TableView (QML component)?
> That would be a big win!
> 
> Would the view also have transition support?
> The current TableView [1] component doesn't have it, the GridView [2] component does, but it basically only eats list models and requires role foo..

Yes, we’re well aware of the limitations and quirks of the TableView in Qt Quick Controls 1. :) QAbstractTableModel support is considered as a requirement for the new TableView. I’m quite confident we can base the new TableView on the same item-view framework ListView and GridView use, so it can support the same item view transitions and so on.

> Do you plan the new TableView to be a styled component (like one of the many other control components) or a bare component where the user needs to define the delegates for the contents, header and sidebar?
> My preference would be a bare component.

The plan is that the new TableView would be on the same line with ListView and GridView. The visual delegates are left to the user to provide. For those who want ready-made styles, we provide a bunch of simple styled delegates in Qt Quick Controls 2.

--
J-P Nurmi



From robin.burchell at crimson.no  Sun Jan 15 13:36:49 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Sun, 15 Jan 2017 13:36:49 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <598F59C8-3654-4475-B572-222B845EA9D7@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>
	<598F59C8-3654-4475-B572-222B845EA9D7@qt.io>
Message-ID: <1484483809.2927831.848228504.3CB4D58B@webmail.messagingengine.com>

Hi,

On Sun, Jan 15, 2017, at 12:24 PM, J-P Nurmi wrote:
> There have been some discussions about rewriting the entire item-view
> framework. I personally believe that would be best done in a major
> release. :)

I guess you're talking about the generic positioner-based view stuff
here, but I wasn't thinking quite so ambitious. That is indeed one thing
that is still bouncing around my head, but I suspect it will stay there
for some time more :)

More generally, I don't disagree that such a thing would be a major
version change, or at least, done in a separate import. Anyway, I'll try
write a longer mail about some of my thoughts on this stuff so they have
a place in the public record, split off from this thread, as it is
definitely a bit of a tangent.

> +1 to having a branch for it (do you have a name in mind? wip/itemviews?
> wip/tableview?)
> 
> I was thinking wip/itemviews, but I don’t mind wip/tableview either. :)

If your specific goal here is to provide enablers for tableview, then
I'd go for wip/tableview.

> Having more branches could be an option. All the tasks are somehow
> connected to each other, though, so I was thinking that it might be
> easiest to do it all in the same branch to avoid excessive conflicts and
> merging between multiple WIP-branches. The last two, SortFilterProxyModel
> and TreeModelAdaptor, would be the most logical ones to split to separate
> branches, but on the other hand, they also need to be implemented so that
> they play well with the rest.

Yes, that's pretty much the sort of division I was thinking; and
especially if Pierre-Yves can help with contributing on the SFPM part,
perhaps that's a good candidate for doing "separately". I understand and
agree with the need for unity, of course, but perhaps communication can
help to some degree there. Anyway, it was just a suggestion. I'll leave
the "how" to you people, you know the details of this work better than I
:)

> There’s so much to do that there is no way we could make all this happen
> before the 5.9 feature freeze in two weeks. :)

Text doesn't quite convey the emotion I meant that statement to evoke
;-); but I guess then you're thinking something like 5.11 (potentially
earlier, if the planets align correctly)? Again, I'm not expecting
promises here, just a rough idea would be a help so I can know when I
need to start trying to pay closer attention to anything touching the
area.

Thanks again.

-- 
  Robin Burchell
  robin at crimson.no


From robin.burchell at crimson.no  Sun Jan 15 15:04:27 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Sun, 15 Jan 2017 15:04:27 +0100
Subject: [Development] New library in qtbase
In-Reply-To: <2ED199A8-0E6C-4EEE-9CE1-9F32C72BFA8B@edeltech.ch>
References: <EF33B9A6-DCF6-4DBF-9006-FB22B6EE1BA4@edeltech.ch>
	<13507339.QtWAKzEl5T@tjmaciei-mobl1>
	<00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch>
	<2976940.gPpOHW8DdO@tjmaciei-mobl1>
	<9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch>
	<5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io>
	<938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch>
	<o1qkd0$1er$2@blaine.gmane.org>
	<357754E1-D65A-4037-948D-CCDA582D2D97@qt.io>
	<o1t0ic$3pa$1@blaine.gmane.org>
	<E7927687-0BEE-4A2B-ACA5-0F17BFD3A732@qt.io>
	<2ED199A8-0E6C-4EEE-9CE1-9F32C72BFA8B@edeltech.ch>
Message-ID: <1484489067.2943961.848263240.33267E5F@webmail.messagingengine.com>

On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote:
> Short summary, we have three possibilities:
> 1) Own module (and current implementation)
> 2) One “core" module and one GUI module to separate concerns for system
> not requiring a GUI connection (Jake’s suggestion)
> 3) Put everything in QtGui and implement the stuff in the QPA parts with
> the implication that a QGuiApplication will be required.
> 
> Can we come to an agreement about which one to implement ?

My own vote would be tending towards 3 once the concept is nailed down.
The existing change looks a little confused from a quick skim, e.g. you
have a QCocoaNotifier which seems to be public API, but this is not the
way I would expect to see this (at least, not in QtGui); I'd expect to
see a "notification" class without any platform specifics, as far as
possible, which then hooked into platform-specific code to "do its
magic".

As the "magic" would tend to be platform-specific, QPA seems to be the
logical place to me; this then also allows a platform implementer to
provide their own custom notification handling, should it be required –
thinking more on the embedded or new platform front here, which is
typically where QPA comes in anyway, where you may not necessarily have
existing services or standards to follow.

I can agree that it's "sad" to have to switch a QCoreApplication to a
QGuiApplication once you need something in it, even if you don't have a
GUI to present (though really, is this a common problem?), but aside
from puritanical concerns, does that actually cause many concrete
issues?

So, considering that, and as it's a problem that already exists for
non-graphical applications to have to interact with images/clipboard,
for syntax highlighting and other text manipulation, etc, I don't think
that adding another case to that problem is a death sentence. I think
it's an extension of a minor inconvenience, but I don't think that
arbitrary splitting of a feature or class is a good way to address that.
It leads to a harder to use & understand API for little gain as I
imagine it, though it is hard to say without a concrete suggestion on
API to review.

In the much longer term, on a separate tangent from your work, it might
be interesting to think about rearranging things to properly address
this problem if the gain is worth it, but even then, that starts to get
tricky & requires a lot of care and research, especially when you
realize that not everything you may want can be done without a windowing
system: clipboard access, for instance, I'd say is almost certainly
impossible to do without a windowing system on all platforms

The same may apply to presenting notifications. Do you know the specific
requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of
those (or future platforms) required the WS, then you'd essentially be
left with a useless API on anything that did not have a QGuiApplication.

I'd say that ultimately, requiring a QGuiApplication instance is a
lesser evil than providing an API that won't work universally.

-- 
  Robin Burchell
  robin at crimson.no


From frederic.marchal at wowtechnology.com  Mon Jan 16 09:13:20 2017
From: frederic.marchal at wowtechnology.com (=?ISO-8859-1?Q?Fr=E9d=E9ric?= Marchal)
Date: Mon, 16 Jan 2017 09:13:20 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>
Message-ID: <3537370.90jLY5Uhsa@port-fma>

On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote:
> Just submitted first change set:
> 
> https://codereview.qt-project.org/#/c/182341/

I'm seeing an error: "The page you requested was not found, or you do not have 
permission to view this page."

Frederic



From olivier at woboq.com  Mon Jan 16 10:34:30 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Mon, 16 Jan 2017 10:34:30 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
Message-ID: <7885071.lxV1XBcrtG@maurice>

On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote:
> Hi everyone,
> 
> I'm trying to contribute by making QMetaObject::invokeMethod() take function
> pointers instead of function names.
> 
> I've come up with something that works by looking at the code of
> QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate.

Thanks for your contribution.

What's the use case for this function? For direct call you better of calling 
the function directly,  and the equivalent of QueuedConnection can be achieved 
with QTimer::singleShot.
Nevertheless, i guess it's worth adding for the sake of consistency.

However, I don't really like QGenericArgument which forces to use Q_ARG. This 
was just a workaround back in the Qt 4 days, around the lack of template 
member function and variadic template. Since we know the arguments of the slot 
at compile time, it would be much nicer to pass the arguments directly. 

> However it does not check for parameters and it is implemented as a function
> of QObject (because I needed QSlotObjects classes which are not available
> in qobjectdef.h). 

But for consistency, it should stay in QMetaObject, I'd say.  We might need to 
move a few more things to qobjectdefs_impl.h to make it happen.

> It can handle QObject member functions and functors in
> which case  "this" is used to select the event loop (like connect()
> functions).
> 
> I've uploaded my change as a draft on gerrit:
> https://codereview.qt-project.org/#/c/182339/
> 
> Here is the link to the relevant bug report:
> https://bugreports.qt.io/browse/QTBUG-37253
> 
> I welcome any comment and feedback.
> 
> BR,
> 
> Benjamin Terrier


-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org




From annulen at yandex.ru  Mon Jan 16 10:57:01 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 16 Jan 2017 12:57:01 +0300
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <7885071.lxV1XBcrtG@maurice>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
Message-ID: <1329451484560621@web1o.yandex.ru>



16.01.2017, 12:34, "Olivier Goffart" <olivier at woboq.com>:
> On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote:
>>  Hi everyone,
>>
>>  I'm trying to contribute by making QMetaObject::invokeMethod() take function
>>  pointers instead of function names.
>>
>>  I've come up with something that works by looking at the code of
>>  QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate.
>
> Thanks for your contribution.
>
> What's the use case for this function? For direct call you better of calling
> the function directly, and the equivalent of QueuedConnection can be achieved
> with QTimer::singleShot.

QTimer::singleShot creates temporary QSingleShotTimer object, which does not seem to be efficient solution if same method needs to be called a lot of times in QueuedConnection way. 

Also, from quick glance it seems like there is no fast path for zero timer interval in startTimer(), so internal timer is registered in event loop for each call.

> Nevertheless, i guess it's worth adding for the sake of consistency.
>
> However, I don't really like QGenericArgument which forces to use Q_ARG. This
> was just a workaround back in the Qt 4 days, around the lack of template
> member function and variadic template. Since we know the arguments of the slot
> at compile time, it would be much nicer to pass the arguments directly.
>
>>  However it does not check for parameters and it is implemented as a function
>>  of QObject (because I needed QSlotObjects classes which are not available
>>  in qobjectdef.h).
>
> But for consistency, it should stay in QMetaObject, I'd say. We might need to
> move a few more things to qobjectdefs_impl.h to make it happen.
>
>>  It can handle QObject member functions and functors in
>>  which case "this" is used to select the event loop (like connect()
>>  functions).
>>
>>  I've uploaded my change as a draft on gerrit:
>>  https://codereview.qt-project.org/#/c/182339/
>>
>>  Here is the link to the relevant bug report:
>>  https://bugreports.qt.io/browse/QTBUG-37253
>>
>>  I welcome any comment and feedback.
>>
>>  BR,
>>
>>  Benjamin Terrier
>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From olivier at woboq.com  Mon Jan 16 11:21:32 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Mon, 16 Jan 2017 11:21:32 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <1329451484560621@web1o.yandex.ru>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice> <1329451484560621@web1o.yandex.ru>
Message-ID: <21862056.qV6QoJcfpJ@maurice>

On Montag, 16. Januar 2017 12:57:01 CET Konstantin Tokarev wrote:
> 16.01.2017, 12:34, "Olivier Goffart" <olivier at woboq.com>:
> > On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote:
> >>  Hi everyone,
> >> 
> >>  I'm trying to contribute by making QMetaObject::invokeMethod() take
> >> function pointers instead of function names.
> >> 
> >>  I've come up with something that works by looking at the code of
> >>  QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate.
> > 
> > Thanks for your contribution.
> > 
> > What's the use case for this function? For direct call you better of
> > calling the function directly, and the equivalent of QueuedConnection can
> > be achieved with QTimer::singleShot.
> 
> QTimer::singleShot creates temporary QSingleShotTimer object, which does not
> seem to be efficient solution if same method needs to be called a lot of
> times in QueuedConnection way.

Yes, that's true: The string based method is optimized for 0ms timeout, but 
not the function pointer one. 
The function pointer version could be optimized for 0 timer the same way that 
the string version of QTimer::singleShot does.
(Well, not exactly the same way currently as we cannot use 
QMetaObject::invokeMethod yet.)

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From jani.heikkinen at qt.io  Mon Jan 16 12:26:10 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Mon, 16 Jan 2017 11:26:10 +0000
Subject: [Development] Qt 5.9 feature freeze
In-Reply-To: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
Message-ID: <AM5PR0202MB25130509B1A02BB989EA92479D7D0@AM5PR0202MB2513.eurprd02.prod.outlook.com>

Kindly reminder: there is a bit more than two weeks left before FF is in effect. So please finalize new features now. 
Is there new submolules coming in for 5.9? If there is those should be added in qt5.git now...

br,
Jani

________________________________________
From: Jani Heikkinen
Sent: Monday, January 2, 2017 12:26 PM
To: development at qt-project.org
Subject: Qt 5.9 feature freeze

Hi all,

Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to finalize all new features for Qt 5.9

Let's this time make sure we will keep the schedule (see https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight with ff. So if you already now see that some feature won't be ready early enough please postpone it to 5.10 instead.

Make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze)

br,
Jani Heikkinen
Release Manager








From edward.welbourne at qt.io  Mon Jan 16 13:40:43 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Mon, 16 Jan 2017 12:40:43 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>,
	<1484411048.2700844.847694632.646032A7@webmail.messagingengine.com>
Message-ID: <HE1PR0202MB268300658ADC20A86ECFA655877D0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Robin Burchell
> I have a longer mental list of things that concern/bother me with
> current model/views (some of which we've already discussed), maybe I
> should try write that up in some form, if you think it might find it
> helpful, but as I don't know how much time I'll be able to dedicate to
> making this happen you may prefer me to hold my tongue :-)

Sounds like a wiki page waiting to be written.
Add it to [[Category:Developing Qt]] and maybe we'll combine it with
other Model/View pages later to make a sub-category.
Or even revive https://wiki.qt.io/Model-View-Design-Issues

	Eddy.


From edward.welbourne at qt.io  Mon Jan 16 14:07:21 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Mon, 16 Jan 2017 13:07:21 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <3537370.90jLY5Uhsa@port-fma>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>,
	<3537370.90jLY5Uhsa@port-fma>
Message-ID: <HE1PR0202MB26832CBE525EB7592CE7090F877D0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote:
>> Just submitted first change set:
>>
>> https://codereview.qt-project.org/#/c/182341/

Frédéric Marchal replied:
> I'm seeing an error: "The page you requested was not found, or you do
> not have permission to view this page."

I've just added you to the list of reviewers - does that help ?

	Eddy.


From oswald.buddenhagen at qt.io  Mon Jan 16 16:14:57 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Mon, 16 Jan 2017 16:14:57 +0100
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
Message-ID: <20170116151457.GC10053@troll08>

On Sat, Jan 14, 2017 at 05:07:30PM +0000, Stottlemyer, Brett (B.S.) wrote:
> My interpretation was that Lars was looking for differences from a Qt user
> perspective, and I think my reply was accurate from that perspective.  I
> would say you are looking at it from the s/w implementation perspective,
> which is absolutely valid.  And I think your description is well-stated
> and accurate as well.
> 
hmm, not really what i tried to get across. i tried to point out
fundamental, architectural differences, and how the concepts relate to
each other, leaving out all the minor things that represent the current
state of the implementations.

> >from a purely design perspective, it would seem optimal to have a QtRpc
> >system of which QtDbus provides a concrete implementation, while QtRo
> >would be the state extension building on top of it.
> 
> [...]
> 
> >it's not really clear to me why you're apparently discarding the idea of
> >integrating qtro with other object distribution frameworks at the
> >outset. the systems really aren't fundamentally different, and providing
> >such integrations may significantly improve qtro adoption where a system
> >is already established (or is being prescribed).
> 
> If you really did mean other object distributions systems, which ones are
> you thinking of?  Microsoft’s Component Object Model is interesting, but
> I’m really not sure how to integrate with it.
>
i was thinking of corba, the example i already mentioned. but i don't
know what is currently relevant in the industries we're targeting.
the task is essentially designing a meta layer (essentially, an idl,
possibly simply adopting an existing one) which can work with different
backends. the essential qt way.
of course, it may be that this task is too complex to get right, in
which case qt bindings for specific systems are a more plausible
approach. i think this is actually what we already do with activeqt.
but then the question forces itself why you had to create *yet another*
distributed object system instead of wrapping an existing one. yes, easy
type handling. see below.

> Did you mean “integrating QtRO with other RPC mechanisms”, in terms of
> layering QtRO on top of a more abstracted RPC?
>
yes, that's the first quoted paragraph above. note that it is a valid
concern independently from the second one.

> If so, I have a very specific reason: type support.
> Many of the types Qt natively support do not work automatically with DBus
> due to its intended interplay with other languages.  Many useful types
> are defined throughout the various Qt modules, and QtRO supports them
> all because Qt supports them all.  It also will auto generate streaming
> operators for needed structures (PODs, in QtRO).  QtRO has extensions to
> support QAIM types, passing batches of calls with QVariant responses
> between processes.
> 
well, in the worst case, the data can be simply sent along via blobs. of
course, that kind of defeats the protocol's native type support, but it
will work just fine if qt is on both ends.

> In order to support an agnostic wire-format that works with different
> languages, I simply believe support needs to be built into Qt itself,
> not a specific module. 
>
yes

> So QtRO is specific to Qt, while the qtdbus module only provides a
> subset of types automatically, but it does provide such a wire format
> (and allows you to extend the set of types with additional code).
>
in a way, you are using dcop as the transport layer: that was kde's
qdatastream-based predecessor of dbus.

> This has been discussed in the past.
> 
indeed, google protocol buffers as a generic data serialization format
have been previously proposed here, but i don't remember the context.

> I’m not against the idea, I just don’t think it should be plumbed into
> QtRO (which it seems like you agree with).
> 
yeah. it would require describing all data types in an idl, and
providing primitives for each supported backend protocol (starting with
qdatastream ... in each existing version).

> BTW, Ossi, would which of the build systems fixes you mentioned would
> help with the qmake loop on windows CI is seeing?  ;)
> 
i don't remember. i'd have to squeeze a full review of your build system
into my todo list.


From oswald.buddenhagen at qt.io  Mon Jan 16 16:24:01 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Mon, 16 Jan 2017 16:24:01 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
Message-ID: <20170116152401.GD10053@troll08>

On Sat, Jan 14, 2017 at 12:37:06PM +0000, J-P Nurmi wrote:
> Early feedback from the CI system would be invaluable.
> 
note that nowadays you can explicitly schedule CI runs on arbitrary
pending changes.
of course, that's not the only _possible_ reason for wanting a branch,
but if it's the only _actual_ reason, then it may make sense to change
the plan.


From b.terrier at gmail.com  Mon Jan 16 19:23:07 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Mon, 16 Jan 2017 19:23:07 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <7885071.lxV1XBcrtG@maurice>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
Message-ID: <CAO+E9op8Z4pQ5012i8XKyN6GCtEye36DoFtq5ju2G+75DNtyMg@mail.gmail.com>

2017-01-16 10:34 GMT+01:00 Olivier Goffart <olivier at woboq.com>:

> On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote:
> > Hi everyone,
> >
> > I'm trying to contribute by making QMetaObject::invokeMethod() take
> function
> > pointers instead of function names.
> >
> > I've come up with something that works by looking at the code of
> > QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate.
>
> Thanks for your contribution.
>
> What's the use case for this function? For direct call you better of
> calling
> the function directly,  and the equivalent of QueuedConnection can be
> achieved
> with QTimer::singleShot.
> Nevertheless, i guess it's worth adding for the sake of consistency.
>

Talking for me here, I use QMetaObject::invokeMethod() to call slots of
QObject accross threads.
I could make use of the new form to call any function (not only slots) and
to have some checks during compilation.

The QTimer solution could work, but you cannot add parameters without using
std::bind.

However, I don't really like QGenericArgument which forces to use Q_ARG.
> This
> was just a workaround back in the Qt 4 days, around the lack of template
> member function and variadic template. Since we know the arguments of the
> slot
> at compile time, it would be much nicer to pass the arguments directly.
>

Agreed. I've got something working with variadic templates, I'll update the
change later.

But for consistency, it should stay in QMetaObject, I'd say.  We might need
> to
> move a few more things to qobjectdefs_impl.h to make it happen.


Can this be done in the same commit? Or do I need to make 2 changes?

Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170116/b4c63652/attachment.html>

From thiago.macieira at intel.com  Mon Jan 16 19:25:31 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 16 Jan 2017 10:25:31 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <CAO+E9op8Z4pQ5012i8XKyN6GCtEye36DoFtq5ju2G+75DNtyMg@mail.gmail.com>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<CAO+E9op8Z4pQ5012i8XKyN6GCtEye36DoFtq5ju2G+75DNtyMg@mail.gmail.com>
Message-ID: <4229254.CHAvtTGChT@tjmaciei-mobl1>

On segunda-feira, 16 de janeiro de 2017 19:23:07 PST Benjamin TERRIER wrote:
> The QTimer solution could work, but you cannot add parameters without using
> std::bind.

Use a lambda.

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



From Jake.Petroules at qt.io  Mon Jan 16 20:10:59 2017
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Mon, 16 Jan 2017 19:10:59 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB26832CBE525EB7592CE7090F877D0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>
	<3537370.90jLY5Uhsa@port-fma>
	<HE1PR0202MB26832CBE525EB7592CE7090F877D0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <B9C0B4A2-F267-4EF3-8FF0-27CCAB9B5FBA@qt.io>

Eddy, "draft" does not do what you think it does. This is why no one can see the change.

Please remove "draft" status and add "WIP: " at the front of the commit message instead so we can all take a look.

Thanks,

> On Jan 16, 2017, at 5:07 AM, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote:
>>> Just submitted first change set:
>>> 
>>> https://codereview.qt-project.org/#/c/182341/
> 
> Frédéric Marchal replied:
>> I'm seeing an error: "The page you requested was not found, or you do
>> not have permission to view this page."
> 
> I've just added you to the list of reviewers - does that help ?
> 
> 	Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io


From jpnurmi at qt.io  Mon Jan 16 22:59:42 2017
From: jpnurmi at qt.io (J-P Nurmi)
Date: Mon, 16 Jan 2017 21:59:42 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <20170116152401.GD10053@troll08>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
Message-ID: <4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>

> On 16 Jan 2017, at 16:24, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
> 
> On Sat, Jan 14, 2017 at 12:37:06PM +0000, J-P Nurmi wrote:
>> Early feedback from the CI system would be invaluable.
>> 
> note that nowadays you can explicitly schedule CI runs on arbitrary
> pending changes.
> of course, that's not the only _possible_ reason for wanting a branch,
> but if it's the only _actual_ reason, then it may make sense to change
> the plan.


I’m expecting the refactoring work to generate quite a large amount of commits. I’d prefer to do it in small steps to reduce the risk of breaking things. This would be a throw-away branch. No merging to the mainline, but ready features would be picked by hand and submitted for review.

--
J-P Nurmi


From kde at carewolf.com  Mon Jan 16 23:07:54 2017
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Mon, 16 Jan 2017 23:07:54 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
Message-ID: <201701162307.55106.kde@carewolf.com>

On Thursday 15 December 2016, Soroush Rabiei wrote:
> Currently there is no support of any calendar system other than Gregorian.
> Gregorian calendar is widely used in western countries. However most
> countries
> in Middle-east, Asia and Africa use other calendar systems. Unfortunately
> there
> is no support for them.
> 
Are you aware of KCalenderSystem? It appears to have most of the calenders, 
and is under LGPL, not sure if it has been ported to KDE Frameworks though, 
and it could probably be useful to reimplement for Qt inclusion, but it might 
be worth checking out if you plan to implement something similar.

Best regards
`Allan


From Shawn.Rutledge at qt.io  Tue Jan 17 08:48:39 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Tue, 17 Jan 2017 07:48:39 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
Message-ID: <6A714072-77D0-4004-9767-7C88DE094115@qt.io>


> On 14 Jan 2017, at 13:37, J-P Nurmi <jpnurmi at qt.io> wrote:
> 
> Hi,
> 
> I'd like to request a WIP branch for the Qt Quick item views. There are plenty of items on the roadmap/wishlist:

+1 from me as well.

I think the back pressure about creating branches is really holding us back - you should be able to click a button somewhere and get one.  The more people expect dev branch to be stable, and whining when it doesn’t always build (which was a frequent problem 5 years ago, but not very often anymore), the more we’re going to need feature branches to do actual development work.  Having a big pile of patches on gerrit always feels disorganized and frustrating.  I’m sure it will be pointed out again that every patch is its own branch, but it doesn’t feel like it’s going anywhere when you work like that, and reviewers just keep ignoring your stuff, and nobody can get a linear view of where you’re going, because the “head” of the linked list is always changing.

I’ll be curious to see though whether a throwaway branch really works out better for you than a direct-merging one.


From devel at g76r.eu  Tue Jan 17 11:21:56 2017
From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=)
Date: Tue, 17 Jan 2017 11:21:56 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <7885071.lxV1XBcrtG@maurice>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
Message-ID: <2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>

Le 16/01/2017 à 10:34, Olivier Goffart a écrit :
> What's the use case for this function? For direct call you better of calling
> the function directly,  and the equivalent of QueuedConnection can be achieved
> with QTimer::singleShot.

Hi.

AFAIK there is no other way to call a method across threads *and wait 
for it result* than QMetaObject::invokeMethod() with 
Qt::BlockingQueuedConnection and Q_RETURN_ARG (apart, of course, making 
the called method thread-safe).

I would personally be happy if (like Benjamin proposes) there were some 
compile time check, IDE symbols following/renaming and no longer need to 
declare such methods as Q_INVOKABLE (or slot).
Therefore IMO methods pointers would be great in 
QMetaObject::invokeMethod() as they are in QObject::connect(). :-)

And maybe lambdas too, if there was a way to choose the thread/eventloop 
in which we want the lambda to be executed (but christmas was a few 
weeks ago, I should not dream ;-)).

Also (I still dream), if there was a way to make invokeMethod() 
automagically choose between a direct call and 
Qt::BlockingQueuedConnection, it would be possible to get rid of this idiom:
     if (QThread::currentThread() == this->thread())
        foo = func();
     else
        QMetaObject::invokeMethod(this, "func",
                  Qt::BlockingQueuedConnection,
                  Q_RETURN_ARG(foo));

Kind of Qt::DirectOrBlockingQueuedConnection.



-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49


From edward.welbourne at qt.io  Tue Jan 17 11:22:57 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 17 Jan 2017 10:22:57 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <B9C0B4A2-F267-4EF3-8FF0-27CCAB9B5FBA@qt.io>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2SLeX=RF_CjPQvfieSWsC_KReOjuEBvK1Lsq1Nbv6Bzww@mail.gmail.com>
	<3537370.90jLY5Uhsa@port-fma>
	<HE1PR0202MB26832CBE525EB7592CE7090F877D0@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<B9C0B4A2-F267-4EF3-8FF0-27CCAB9B5FBA@qt.io>
Message-ID: <HE1PR0202MB26839EA654FEFC3530E4E034877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Jake Petroules
> Eddy, "draft" does not do what you think it does. This is why no one can see the change.

I think you are addressing the wrong person.
Soroush created the review (as a draft) and added me as a reviewer.
That enabled me to add Frederic.

> Please remove "draft" status and add "WIP: " at the front of the commit message instead so we can all take a look.

It already has WIP: on its commit message.

Soroush: please push your next patch set to refs/for/dev, to make the review public.
Subsequent pushes can be to refs/drafts/dev if you like, to make clear it's all still a draft.

	Eddy.


From edward.welbourne at qt.io  Tue Jan 17 11:30:19 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 17 Jan 2017 10:30:19 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <201701162307.55106.kde@carewolf.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>,
	<201701162307.55106.kde@carewolf.com>
Message-ID: <HE1PR0202MB2683FD0F831088C130D67208877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Allan Sandfeld Jensen asked:
> Are you aware of KCalenderSystem?

Yes - Sergio Martins helpfully brought it up a couple of weeks ago:
http://lists.qt-project.org/pipermail/development/2017-January/028241.html

Current plan is roughly to upstream it.  Debate remains as to whether it
should sit outside QDate (Lars) or be taken by overloads of QDate
methods to tweak their action (Soroush and I).

	Eddy.


From oswald.buddenhagen at qt.io  Tue Jan 17 11:56:07 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Tue, 17 Jan 2017 11:56:07 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
	<4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>
Message-ID: <20170117105607.GB24383@troll08>

On Mon, Jan 16, 2017 at 09:59:42PM +0000, J-P Nurmi wrote:
> > On 16 Jan 2017, at 16:24, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
> > 
> > On Sat, Jan 14, 2017 at 12:37:06PM +0000, J-P Nurmi wrote:
> >> Early feedback from the CI system would be invaluable.
> >> 
> > note that nowadays you can explicitly schedule CI runs on arbitrary
> > pending changes.
> > of course, that's not the only _possible_ reason for wanting a branch,
> > but if it's the only _actual_ reason, then it may make sense to change
> > the plan.
> 
> 
> I’m expecting the refactoring work to generate quite a large amount of commits. I’d prefer to do it in small steps to reduce the risk of breaking things. This would be a throw-away branch. No merging to the mainline, but ready features would be picked by hand and submitted for review.
> 
fair enough. note that you're adding to the CI load, so try to batch
your integrations in as far as reasonable. as always, actually.
you didn't specify the source, so i assumed dev.

speaking of how hard is to get branches: the policy is quite clear that
done (and abandoned) branches should be deleted (or moved to a hidden
namespace, if you insist on archiving your throw-away branch). they
aren't, they are piling up. what exactly do you expect in return?


From edward.welbourne at qt.io  Tue Jan 17 12:55:09 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 17 Jan 2017 11:55:09 +0000
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>,
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
Message-ID: <HE1PR0202MB268319F548256034801ABC30877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Grégoire Barbier:
> Kind of Qt::DirectOrBlockingQueuedConnection.

Blocking_DirectOrQueued_Connection, surely.

	Eddy.


From edward.welbourne at qt.io  Tue Jan 17 14:29:53 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 17 Jan 2017 13:29:53 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <20170117105607.GB24383@troll08>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
	<4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>,
	<20170117105607.GB24383@troll08>
Message-ID: <HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Oswald Buddenhagen:
> speaking of how hard is to get branches: the policy is quite clear that
> done (and abandoned) branches should be deleted (or moved to a hidden
> namespace, if you insist on archiving your throw-away branch). they
> aren't, they are piling up. what exactly do you expect in return?

Which reminds me, back in August I investigated then-current wip/s:
http://lists.qt-project.org/pipermail/development/2016-August/026859.html

Two branches (only in qtbase) are done with and can be killed:
wip/qstring-utf8
wip/lite

One branch is dead but should perhaps be archived (i.e. moved to an
out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
qtquickcontrols, qtbase).

I also observe wip/qtquickintergration in qt3d, which is clearly a typo
for wip/qtquickintegration (which contains every commit of the typo-ed
version).

Ossi, would you take care of those ?


Here's the list of all (other) currently live wip/s (in which modules)
with date and author of the tip commit (on whichever module that's most
recent):

  wip/animation (qt3d) 2017/Jan, Sean Harmer
  wip/pointerhandler (qtdeclarative) 2017/Jan, Shawn Rutledge
  wip/qtquickintegration (qt3d) 2017/Jan, Sean Harmer
  wip/scenegraphng (qtdeclarative) 2017/Jan, Laszlo Agocs

  wip/qbs (qtbase) 2016/Dec,  Christian Kandeler
  wip/qtwebkit/next (qt5) 2016/Oct, Konstantin Tokarev
  wip/particles (qt3d) 2016/Sep, Liang Qi
  wip/next (qtwebkit) 2016/Aug, Liang Qi
  wip/remac (qtbase) 2016/Aug, Jan Arve Saether
  wip/nacl (qtbase, qtdeclarative) 2016/Jul, Gabriel de Dietrich
  wip/speech-recognition (qtspeech) 2016/Apr, Frederik Gladhorn

  wip/win (qtconnectivity) 2015/Dec, Alex Blasche
  wip/network-test-server (qtbase) 2015/Oct, me
  wip/dbus (qtdeclarative) 2015/Oct, Sérgio Martins
  wip/47-based (qtwebengine) 2015/Oct, Allan Sandfeld Jensen
  wip/mir (qtbase) 2015/Aug, Paul Olav Tvete; Canonical wanted it in 2016/Aug
  wip/highdpi (qtbase) 2015/Jul, Paul Olav Tvete; probably dead ?
  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen
  wip/threading (qtcanvas3d) 2015/Jul, Miikka Heikkinen

  wip/gc (qtdeclarative) 2014/Apr, Thiago Macieira
  wip/calendar (qtquickcontrols) 2014/Feb, Mitch Curtis

  winrt (qtbase) 2013/Sep,  Andrew Knight <andrew.knight at digia.com>
  wip/winrt (qttools) 2013/Aug, Andrew Knight <andrew.knight at digia.com>
  wip/android (qtscript, qtdoc, qtimageformats, qtquick1,
               qtgraphicaleffects) 2013/Feb, Eskil Abrahamsen Blomfeldt

  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser

  wip/qa (qtlocation) 2011/Aug, shubinba <natalia.shubina at nokia.com>
  wip/v8 (qtscript) 2011/Jul, Peter Varga
  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu <qt-info at nokia.com>
  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser <michael.brasser at nokia.com>
  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson <yann.bodson at nokia.com>
  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter <andrew.den-exter at nokia.com>

and I am naturally suspicious of those whose last commit is from an
e-mail @nokia, all from 2011; these sound suspiciously dead.
Please review those you know anything about ... especially the old ones.

	Eddy.


From py.siret at gmail.com  Tue Jan 17 14:33:59 2017
From: py.siret at gmail.com (Pierre-Yves Siret)
Date: Tue, 17 Jan 2017 14:33:59 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<CANi=iPFsOZA2=J=4hSmb+Et8gRJ7MTrm5gY_zYJp80QG2-5pjg@mail.gmail.com>
	<A3C9E367-F95C-49DB-A2D1-08868A16673C@qt.io>
Message-ID: <CANi=iPFHv-RdaSpK0iN9TgUeQYWXzwbC+UXY4UCYM8iFsfQ22w@mail.gmail.com>

Not really related to all the branch business going on, but I want to say
i'd gladly help and participate in this WIP, wherever that takes place.

2017-01-14 17:06 GMT+01:00 J-P Nurmi <jpnurmi at qt.io>:

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret <py.siret at gmail.com> wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi <jpnurmi at qt.io>:
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170117/cd0a549e/attachment.html>

From edward.welbourne at qt.io  Tue Jan 17 14:54:12 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 17 Jan 2017 13:54:12 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
	<4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>,
	<20170117105607.GB24383@troll08>,
	<HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0202MB268310557E8A41309F91AE18877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

I wrote:
> Which reminds me, back in August I investigated then-current wip/s:
> http://lists.qt-project.org/pipermail/development/2016-August/026859.html

and Ossi brought git fetch's -p option to my attention.
Most of those mentioned before are still here, but:

> Two branches (only in qtbase) are done with and can be killed:
> wip/qstring-utf8
> wip/lite

wip/qstring-utf8 is already gone.

> I also observe wip/qtquickintergration in qt3d, which is clearly a typo
> for wip/qtquickintegration (which contains every commit of the typo-ed
> version).

This one has already been removed.

> Here's the list of all (other) currently live wip/s (in which modules)
> with date and author of the tip commit (on whichever module that's most
> recent):
[...]
>  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen

This one is also gone.
All others are as described ...

	Eddy.


From rjvbertin at gmail.com  Tue Jan 17 17:40:17 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 17 Jan 2017 17:40:17 +0100
Subject: [Development] config.summary in Qt 5.8?
Message-ID: <1558505.Alc0NSi4VC@portia.local>

Hi,

Trying the current 5.8.0-rc tarball I notice that the configure step no longer creates a config.summary file, while it still prints out the summary.

Will this be brought back in the final release? I found it very handy...

Thanks,
R.


From thiago.macieira at intel.com  Tue Jan 17 18:11:32 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 17 Jan 2017 09:11:32 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
Message-ID: <10897770.bxSinyeOCv@tjmaciei-mobl1>

Em terça-feira, 17 de janeiro de 2017, às 11:21:56 PST, Grégoire Barbier 
escreveu:
> And maybe lambdas too, if there was a way to choose the thread/eventloop
> in which we want the lambda to be executed (but christmas was a few
> weeks ago, I should not dream ;-)).

If we do this, it should be possible to write:

	QMetaObject::invokeMethod(object, [=]() { 
		doSomething(); return something; },
		Qt::BlockingQueuedConnection,
		Q_RETURN_ARG(foo));

Since we have lambdas and std::bind, I don't see the point of supporting 
passing arguments. The return value is interesting still.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Jan 17 18:13:12 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 17 Jan 2017 09:13:12 -0800
Subject: [Development] config.summary in Qt 5.8?
In-Reply-To: <1558505.Alc0NSi4VC@portia.local>
References: <1558505.Alc0NSi4VC@portia.local>
Message-ID: <14616360.CtjVUeoBnA@tjmaciei-mobl1>

Em terça-feira, 17 de janeiro de 2017, às 17:40:17 PST, René J.V. Bertin 
escreveu:
> Hi,
> 
> Trying the current 5.8.0-rc tarball I notice that the configure step no
> longer creates a config.summary file, while it still prints out the
> summary.
> 
> Will this be brought back in the final release? I found it very handy...

No, only for 5.8.1.

For 5.8.0, config.log will have to do.

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



From thiago.macieira at intel.com  Tue Jan 17 18:14:19 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 17 Jan 2017 09:14:19 -0800
Subject: [Development] Calendar Systems proposal
In-Reply-To: <HE1PR0202MB26839EA654FEFC3530E4E034877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<B9C0B4A2-F267-4EF3-8FF0-27CCAB9B5FBA@qt.io>
	<HE1PR0202MB26839EA654FEFC3530E4E034877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <1641862.tGJ9v3s695@tjmaciei-mobl1>

Em terça-feira, 17 de janeiro de 2017, às 10:22:57 PST, Edward Welbourne 
escreveu:
> Jake Petroules
> 
> > Eddy, "draft" does not do what you think it does. This is why no one can
> > see the change.
> I think you are addressing the wrong person.
> Soroush created the review (as a draft) and added me as a reviewer.
> That enabled me to add Frederic.
> 
> > Please remove "draft" status and add "WIP: " at the front of the commit
> > message instead so we can all take a look.
> It already has WIP: on its commit message.
> 
> Soroush: please push your next patch set to refs/for/dev, to make the review
> public. Subsequent pushes can be to refs/drafts/dev if you like, to make
> clear it's all still a draft.

People not added to the reviews will not see them.

Don't use refs/drafts for anything you want other people to see.

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



From rjvbertin at gmail.com  Tue Jan 17 18:49:40 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Tue, 17 Jan 2017 18:49:40 +0100
Subject: [Development] config.summary in Qt 5.8?
References: <1558505.Alc0NSi4VC@portia.local>
	<14616360.CtjVUeoBnA@tjmaciei-mobl1>
Message-ID: <2180819.KVT24caeeI@portia.local>

Thiago Macieira wrote:

> No, only for 5.8.1.
> 
> For 5.8.0, config.log will have to do.

Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not surprised. 
(I *will* be surprised if all my little hacks continue to work...)

Maybe the patch to reintroduce config.summary is already available somewhere for 
local backporting?

Either way I suppose that the new config.summary will have to same layout as 
what configure prints at the end, so won't compare side-by-side to the summaries 
of previous versions?

R.



From thiago.macieira at intel.com  Tue Jan 17 19:07:24 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 17 Jan 2017 10:07:24 -0800
Subject: [Development] config.summary in Qt 5.8?
In-Reply-To: <2180819.KVT24caeeI@portia.local>
References: <1558505.Alc0NSi4VC@portia.local>
	<14616360.CtjVUeoBnA@tjmaciei-mobl1>
	<2180819.KVT24caeeI@portia.local>
Message-ID: <1630166.8ExBN7gvDr@tjmaciei-mobl1>

Em terça-feira, 17 de janeiro de 2017, às 18:49:40 PST, René J. V. Bertin 
escreveu:
> Thiago Macieira wrote:
> > No, only for 5.8.1.
> > 
> > For 5.8.0, config.log will have to do.
> 
> Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not
> surprised. (I *will* be surprised if all my little hacks continue to
> work...)
> 
> Maybe the patch to reintroduce config.summary is already available somewhere
> for local backporting?

Yes, 47784b4352351f042d1e3b61e7151cdcc7c0bac1.

> Either way I suppose that the new config.summary will have to same layout as
> what configure prints at the end, so won't compare side-by-side to the
> summaries of previous versions?

No, I don't think so.

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



From kfunk at kde.org  Tue Jan 17 19:11:44 2017
From: kfunk at kde.org (Kevin Funk)
Date: Tue, 17 Jan 2017 19:11:44 +0100
Subject: [Development] config.summary in Qt 5.8?
In-Reply-To: <2180819.KVT24caeeI@portia.local>
References: <1558505.Alc0NSi4VC@portia.local>
	<14616360.CtjVUeoBnA@tjmaciei-mobl1>
	<2180819.KVT24caeeI@portia.local>
Message-ID: <1900140.Y0WyXvG9e8@kerberos>

On Tuesday, 17 January 2017 18:49:40 CET René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > No, only for 5.8.1.
> > 
> > For 5.8.0, config.log will have to do.
> 
> Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not
> surprised. (I *will* be surprised if all my little hacks continue to
> work...)
> 
> Maybe the patch to reintroduce config.summary is already available somewhere
> for local backporting?

In Google: '"config.summary" qtbase 5.8'

-> https://bugreports.qt.io/browse/QTBUG-56225
-> https://codereview.qt-project.org/#/c/180823/

> Either way I suppose that the new config.summary will have to same layout as
> what configure prints at the end, so won't compare side-by-side to the
> summaries of previous versions?

Apply the patch and check, I'd say.

Hope that helps :)

Cheers,
Kevin

> R.
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170117/9c53c98f/attachment.sig>

From rjvbertin at gmail.com  Tue Jan 17 20:57:18 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Tue, 17 Jan 2017 20:57:18 +0100
Subject: [Development] config.summary in Qt 5.8?
References: <1558505.Alc0NSi4VC@portia.local>
	<14616360.CtjVUeoBnA@tjmaciei-mobl1>
	<2180819.KVT24caeeI@portia.local> <1900140.Y0WyXvG9e8@kerberos>
Message-ID: <2955532.K6fQfG2BTx@portia.local>

Kevin Funk wrote:

> -> https://bugreports.qt.io/browse/QTBUG-56225
> -> https://codereview.qt-project.org/#/c/180823/

> Apply the patch and check, I'd say.
> 
> Hope that helps :)

Yep, it did, thanks :)

R.



From thomas.sondergaard at karoshealth.com  Tue Jan 17 21:37:31 2017
From: thomas.sondergaard at karoshealth.com (=?UTF-8?Q?Thomas_S=C3=B8ndergaard?=)
Date: Tue, 17 Jan 2017 21:37:31 +0100
Subject: [Development] QWidget::setWindowState(Qt::WindowStates) vs
 QWindow::setWindowState(Qt::WindowState)
Message-ID: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>

Hi,

I'm looking at the Qt code with intention to fix it so this code

    QWidget widget;
    widget.setWindowState(Qt::WindowMaximized);
    widget.showMinized();

will show the window iconified and when the user (or program) unminimize
the window it pops up maximized. This is currently not possible (QTBUG-57882
<https://bugreports.qt.io/browse/QTBUG-57882>).

I've been trying to read the Qt code and it seems to me the problem is that
QWindow::setWindowState(Qt::WindowState) and
QPlatformWindow::setWindowState(Qt::WindowState) only take a
Qt::WindowState argument not a Qt::WindowStates argument. This seems to
make it impossible to set the correct state on the windows-system window.

Is this intentional or a known issue?

I would be happy to get suggestions for how this is best fixed.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170117/e7aa968a/attachment.html>

From rjvbertin at gmail.com  Tue Jan 17 22:02:12 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 17 Jan 2017 22:02:12 +0100
Subject: [Development] Qt 5.8: ICU vs. iconv
Message-ID: <1724254.zAB6RyaYyW@portia.local>

Hi,

Another quick question: I understand it is no longer possible to configure Qt to use both iconv and ICU as I've always done (possible without effect?).
Given that neither of the 3 supported iconv variants is accepted when ICU is used I take it that ICU is the preferred alternative.

Is that correct, across all platforms?

Thanks,
R.


From thiago.macieira at intel.com  Tue Jan 17 22:27:33 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 17 Jan 2017 13:27:33 -0800
Subject: [Development] Qt 5.8: ICU vs. iconv
In-Reply-To: <1724254.zAB6RyaYyW@portia.local>
References: <1724254.zAB6RyaYyW@portia.local>
Message-ID: <3073211.1eZTBdgWio@tjmaciei-mobl1>

On terça-feira, 17 de janeiro de 2017 22:02:12 PST René J.V. Bertin wrote:
> Hi,
> 
> Another quick question: I understand it is no longer possible to configure
> Qt to use both iconv and ICU as I've always done (possible without
> effect?). Given that neither of the 3 supported iconv variants is accepted
> when ICU is used I take it that ICU is the preferred alternative.
> 
> Is that correct, across all platforms?

Yes, ICU is preferred.

It should have been possible to enable Iconv for QTextCodec and let ICU be 
used for QCollator and QTimeZone. Looks like we forgot. But no, please use ICU 
instead of iconv anyway.

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



From rjvbertin at gmail.com  Tue Jan 17 22:51:33 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Tue, 17 Jan 2017 22:51:33 +0100
Subject: [Development] Qt 5.8: ICU vs. iconv
References: <1724254.zAB6RyaYyW@portia.local>
	<3073211.1eZTBdgWio@tjmaciei-mobl1>
Message-ID: <1944646.g98YfSkVe1@portia.local>

Thiago Macieira wrote:

> It should have been possible to enable Iconv for QTextCodec and let ICU be
> used for QCollator and QTimeZone. Looks like we forgot. But no, please use ICU
> instead of iconv anyway.

OK, one external dependency to handle everything, makes sense, thanks.

R.



From bstottle at ford.com  Wed Jan 18 03:51:50 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Wed, 18 Jan 2017 02:51:50 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170116151457.GC10053@troll08>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
	<20170116151457.GC10053@troll08>
Message-ID: <CF3BB45E-1D4A-4BA7-97D2-E82276638AB2@ford.com>

On 1/16/17, 10:14 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:


>of course, it may be that this task is too complex to get right, in
>which case qt bindings for specific systems are a more plausible
>approach. i think this is actually what we already do with activeqt.
>but then the question forces itself why you had to create *yet another*
>distributed object system instead of wrapping an existing one. yes, easy
>type handling. see below.

The crux of the matter, in my opinion, boils down to a couple of things.

1) Creating a wire-format that works with other languages is a much bigger
undertaking, and one that would need to be integrated into Qt itself, not
QtRO.  Based on the (lack of) response from others, it seems this is not
a palatable change at this time.

2) A Qt-to-Qt distributed object system can provide a rich set of features
leveraging Qt’s existing capabilities, without requiring a lot of additional
code by the user.  Such a system doesn’t currently exist in Qt, would
provide value, and thus the request to move QtRO out of the playground.
*yet another* isn’t relevant unless you want to delve back into the wire-
format side of this discussion (#1).

For providing Qt new functionality, I feel the existing QtRO design is sound.
If at some point #1 becomes a reality, I would be glad to revisit a generic
idl.

Regards,
Brett

From tuukka.turunen at qt.io  Wed Jan 18 07:52:31 2017
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Wed, 18 Jan 2017 06:52:31 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <CF3BB45E-1D4A-4BA7-97D2-E82276638AB2@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
	<20170116151457.GC10053@troll08>
	<CF3BB45E-1D4A-4BA7-97D2-E82276638AB2@ford.com>
Message-ID: <AM4PR0202MB29485AFDD409D3A6191CA8DE8F7F0@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: keskiviikkona 18. tammikuuta 2017 4.52
> To: Oswald Buddenhagen <Oswald.Buddenhagen at qt.io>;
> development at qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 

...

> 
> For providing Qt new functionality, I feel the existing QtRO design is sound.
> If at some point #1 becomes a reality, I would be glad to revisit a generic idl.
> 

When QtRO becomes part of Qt, would you continue as the maintainer of the module and have adequate time to polish it so that it can be fully supported in the upcoming Qt releases?

Yours,

	Tuukka


> Regards,
> Brett
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From konstantin at podsvirov.pro  Wed Jan 18 08:21:55 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Wed, 18 Jan 2017 10:21:55 +0300
Subject: [Development] [SUGGESTION] (QTIFW-916) Distribute CMake tools as
 part of the QtSDK
Message-ID: <7161491484724115@web12h.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170118/e8881b64/attachment.html>

From Shawn.Rutledge at qt.io  Wed Jan 18 08:49:08 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Wed, 18 Jan 2017 07:49:08 +0000
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
	<4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>
	<20170117105607.GB24383@troll08>
	<HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <08387337-1156-4E08-A569-DB425FEE76FD@qt.io>


> On 17 Jan 2017, at 14:29, Edward Welbourne <edward.welbourne at qt.io> wrote:
> One branch is dead but should perhaps be archived (i.e. moved to an
> out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
> qtquickcontrols, qtbase).

This was brought up before… Tizen still exists and Qt should still be able to run on it, IMO, supported or not.  So if the work was not finished, why kill it and have to start over later on?

Otherwise someone had better archive it.  Ideally the archive should be accessible too.

>  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
>  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser
> 
>  wip/qa (qtlocation) 2011/Aug, shubinba <natalia.shubina at nokia.com>
>  wip/v8 (qtscript) 2011/Jul, Peter Varga
>  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu <qt-info at nokia.com>
>  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser <michael.brasser at nokia.com>
>  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson <yann.bodson at nokia.com>
>  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter <andrew.den-exter at nokia.com>

Yeah sounds like I’d better look at a few of those.


From filippocucchetto at gmail.com  Wed Jan 18 09:23:14 2017
From: filippocucchetto at gmail.com (Filippo Cucchetto)
Date: Wed, 18 Jan 2017 09:23:14 +0100
Subject: [Development] Branch request: wip/itemviews in qtdeclarative
In-Reply-To: <08387337-1156-4E08-A569-DB425FEE76FD@qt.io>
References: <4C7E90C1-BAEF-486C-92EE-7DC86974BD04@qt.io>
	<20170116152401.GD10053@troll08>
	<4B959D19-84A8-4988-9C3F-08BB1AD06D70@qt.io>
	<20170117105607.GB24383@troll08>
	<HE1PR0202MB2683252194E0FCCE6B933BC8877C0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<08387337-1156-4E08-A569-DB425FEE76FD@qt.io>
Message-ID: <CA+zKVJewOQfHjabGEm7AxkwdM=CBdceO_KdGLmURvdQk1R82-A@mail.gmail.com>

Getting back to the real topic some thoughts about the current state of the
ItemViews and what we need
- TableView with horizontal virtualization
- TableViews probably should do column delegate caching
- Decide if we should go back to basic integer row/column fields (exposed
to delegates) or use QModelIndexes
This is important and could have big impacts on the design and api.
- Connected to the previous point we should decide if we want to make
QAbstractModel of QObject* first citizens
or not. In particular i found envaluable the design exposed by Stephen
Kelly here https://conf.qtcon.org/en/qtcon/public/events/355
Look at the video (
http://mirrors.fe.up.pt/kde-applicationdata/akademy/2016/355_how_to_interface_nonqt_model_code_with_qml.mp4)

 at time 18:26. Where the QModelIndexes are wrapped inside a QObject.
- The current way to expose data to the QML view delegates is inflexible
due to QAIM::roleNames(). First is not possible to emit a roleNamesChanged
without resetting the model. Second if the model contains a list
heterogeneous data the roleNames() should return a QMap that is the union
of all
the possible fields. For overcoming this problems most of the users return
a QObject*. This solution allows dynamic roleNames and remove the need
for writing lots of QAIM


F.

2017-01-18 8:49 GMT+01:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:

>
> > On 17 Jan 2017, at 14:29, Edward Welbourne <edward.welbourne at qt.io>
> wrote:
> > One branch is dead but should perhaps be archived (i.e. moved to an
> > out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
> > qtquickcontrols, qtbase).
>
> This was brought up before… Tizen still exists and Qt should still be able
> to run on it, IMO, supported or not.  So if the work was not finished, why
> kill it and have to start over later on?
>
> Otherwise someone had better archive it.  Ideally the archive should be
> accessible too.
>
> >  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen
> Blomfeldt
> >  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser
> >
> >  wip/qa (qtlocation) 2011/Aug, shubinba <natalia.shubina at nokia.com>
> >  wip/v8 (qtscript) 2011/Jul, Peter Varga
> >  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu <
> qt-info at nokia.com>
> >  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser <
> michael.brasser at nokia.com>
> >  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson <yann.bodson at nokia.com
> >
> >  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter <
> andrew.den-exter at nokia.com>
>
> Yeah sounds like I’d better look at a few of those.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Filippo Cucchetto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170118/544092a3/attachment.html>

From rjvbertin at gmail.com  Wed Jan 18 09:51:43 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 18 Jan 2017 09:51:43 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt 5.8/configure
Message-ID: <12696459.erqPW8QydK@bola>

Hi,

Among the tweak I have in my script to build Qt for installation into /opt/local, using dependencies from there, I have a patch for qtbase/configure that prunes a number of unnecessary/undesirable items from DEFAULT_INCDIR and DEFAULT_LIBDIR (see below). 

I cannot seem to find any trace of those variables in the Qt 5.8 build system, and the only info I've gleaned from Google shows that those variables were used frequently in the configure invocation.

How does this work out with Qt 5.8? Can I assume that there is no more need to remove undesirable elements from the 2 default search paths, or do I have to apply my filter elsewhere? 

Thanks,
R.

The filter most likely dates back to Qt 5.5; I haven't checked to what extent it still removed anything in Qt 5.7 :
--------
 [ "$OPT_VERBOSE" = "yes" ] && tty=/dev/stderr
 eval "`LC_ALL=C $TEST_COMPILER $SYSROOT_FLAG $TEST_COMPILER_CXXFLAGS -xc++ -E -v - < /dev/null 2>&1 > /dev/null | $AWK "$awkprog" | tee $tty`"
 unset tty
+# remove unnecessary and unwanted paths (for MacPorts we don't want /usr/local/include either)
+DEFAULT_INCDIRS=`echo ${DEFAULT_INCDIRS} | sed -e 's|/usr/include/[xi][0-9][^-]*-linux-gnu[^ ]*||g' -e 's|/usr/lib/gcc/[xi][0-9][^-]*-linux-gnu/[^ ]*||g' -e 's|/usr/include/c++[^ ]*||g' -e 's|/usr/local/include||g'`
+DEFAULT_LIBDIRS=`echo ${DEFAULT_LIBDIRS} | sed -e 's|/usr/lib/[xi][0-9][^-]*-linux-gnu||g' -e 's|/lib/[xi][0-9][^-]*-linux-gnu||g' -e 's|/usr/lib/gcc/[xi][0-9][^-]*-linux-gnu/[0-9][^ ]*||g'`
+echo "Pruned DEFAULT_INCDIRS=$DEFAULT_INCDIRS"
+echo "Pruned DEFAULT_LIBDIRS=$DEFAULT_LIBDIRS"
 
 echo "Done running configuration tests."
 
------------


From Shawn.Rutledge at qt.io  Wed Jan 18 09:54:06 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Wed, 18 Jan 2017 08:54:06 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <20170116151457.GC10053@troll08>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
	<20170116151457.GC10053@troll08>
Message-ID: <A0C0BC20-FDCB-46CD-952F-099965836855@qt.io>


> On 16 Jan 2017, at 16:14, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
> On Sat, Jan 14, 2017 at 05:07:30PM +0000, Stottlemyer, Brett (B.S.) wrote:
>> 
>> If you really did mean other object distributions systems, which ones are
>> you thinking of?  Microsoft’s Component Object Model is interesting, but
>> I’m really not sure how to integrate with it.
>> 
> i was thinking of corba, the example i already mentioned. but i don't
> know what is currently relevant in the industries we're targeting.

Maybe DDS, which is also from Object Management Group, which uses IDL in approximately the same way, but is extended to support both multicast and point-to-point communication and has the pub-sub metaphor.  Unlike many alternatives, it’s peer-to-peer.  We have one customer who uses it extensively, so there was a back-burner idea to integrate some sort of support for it in Qt.  https://en.wikipedia.org/wiki/Data_Distribution_Service

Speaking of pub-sub, I’ve been hearing about MQTT lately, but haven’t tried to use it.  Seems it’s popular with the IOT crowd for now.  Has the same disadvantages of D-Bus (as it’s usually used): only TCP and only via a message broker, so it’s not decentralized enough to be truly resilient.

> well, in the worst case, the data can be simply sent along via blobs. of
> course, that kind of defeats the protocol's native type support, but it
> will work just fine if qt is on both ends.

Exactly… it’s going to end up as some sort of byte stream anyway.  The correct usage of D-Bus wire protocol can (and should) be refined over time, but at least you have somewhere to start.

I’m not convinced that D-Bus is everything an RPC system should be, but it happens to be popular.  Yes it can run across the network - I did that experiment ages ago.  That usage is not “supported” mainly because the author didn’t want to bite off more than he could chew; CORBA was already prior art at the time, and it’s clear that distributed object systems are way more complex than IPC on one machine.  But I think if you can get away with using the same wire protocol for that too, why not… at least the XML is easy to parse, as Ossi points out.  (Although if one was reinventing it today, why use XML… maybe JSON? maybe a binary XML-like self-describing representation.  But all of those can be converted anyway.)  And you only need it for introspection; you are also free to hard-code your own usage of the wire protocol on both ends without having to write XML first.

What seems to be unique from what you’ve said about qtro so far is automatic serialization without having to write all the stream operators, in cases where they don’t already exist, right?  But that’s just a way of getting a byte array, which can indeed be a blob as long as your decoding technique is universal.

So I do like the idea of this being turned into a layer which can run on top of various RPC and object communication mechanisms instead of only one new black box.  Ideally it could run on all of them, but that’s many years of work, of course.  Later, communicating with non-Qt processes could even be possible.  Even if you don’t see it as a goal yet, maybe someone will.

>> This has been discussed in the past.
>> 
> indeed, google protocol buffers as a generic data serialization format
> have been previously proposed here, but i don't remember the context.

And from what I read they suck… too much code is generated, which bloats the application and takes too long to compile.  Google reinvents the wheel too sometimes, just because they can, and it’s not always elegant, nor does it always pick the tallest giants to stand on their shoulders.  The author went on to write CapnCrunch, which I hear good things about.  Still didn’t get around to trying it.


From oswald.buddenhagen at qt.io  Wed Jan 18 11:10:04 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 18 Jan 2017 11:10:04 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
In-Reply-To: <12696459.erqPW8QydK@bola>
References: <12696459.erqPW8QydK@bola>
Message-ID: <20170118101004.GF24383@troll08>

On Wed, Jan 18, 2017 at 09:51:43AM +0100, René J.V. Bertin wrote:
> How does this work out with Qt 5.8?
>
the bulk of the code is in toolchain.prf.
note that i have some related patches for 5.8 on gerrit.


From rjvbertin at gmail.com  Wed Jan 18 12:08:03 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 18 Jan 2017 03:08:03 -0800 (PST)
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
Message-ID: <3049164.HWW1izGdnU@portia.local>

Hi,


Still tinkering with Qt 5.8, now doing a more complete "toplevel" build on Mac.

I have PulseAudio and Gstreamer 1.0 installed in the target prefix, but those are strictly for use with GTk/Gnome apps, I don't want to introduce dependencies on these libraries in Qt.

I see that QtMultiMedia's plugins.pro has

unix:!mac:!android {
    qtConfig(gstreamer) {
       SUBDIRS += gstreamer
    } else {
        SUBDIRS += audiocapture
    }

    qtConfig(pulseaudio): SUBDIRS += pulseaudio
    qtConfig(alsa): SUBDIRS += alsa

    # v4l is turned off because it is not supported in Qt 5
    # qtConfig(linux_v4l) {
    #     SUBDIRS += v4l
    # }
}

But yet the configure process picks up both PulseAudio and GStreamer 1.0. As expected this still happens when I out-comment the relevant lines in the above snippet.

I've managed to get rid of PulseAudio by hacking qtmultimedia/src/qtmultimedia/configure.json but not so with GStreamer.

What happened with the --no-pulseaudio configure argument? I get the impression that one can supposedly pass arguments to QtMultiMedia's configure step, but how does that work?

Google hasn't been of much help, only older results that discuss how to *activate* PulseAudio support for cross-platform development.

Thanks,
René


From rjvbertin at gmail.com  Wed Jan 18 12:54:15 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 12:54:15 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
References: <12696459.erqPW8QydK@bola> <20170118101004.GF24383@troll08>
Message-ID: <2085443.GmYgfnh0FH@portia.local>

Oswald Buddenhagen wrote:

> the bulk of the code is in toolchain.prf.
> note that i have some related patches for 5.8 on gerrit.

Yes, I found toolchain.prf, and already replaced the reference to 
/usr/local/include in there (which I think is redundant anyway as most compilers 
on Unix look there anyway?).

Filtering in a QMake file won't be as trivial as in a regular shell script, but 
I'll try to find your patches on gerrit, thanks.

R.




From rjvbertin at gmail.com  Wed Jan 18 13:28:14 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 13:28:14 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer (and libGL ...)
References: <3049164.HWW1izGdnU@portia.local>
Message-ID: <2926129.ADvgQ6qmY8@portia.local>

Seems the configure process also picks up the X11 libGL when it's available.

I used to protect against that in the configure script, but the OpenGL detection 
logic has been moved from out of there, too :-/


diff --git a/qtbase/configure b/qtbase/configure
index 0b8b417..91c6bc1 100755
--- a/qtbase/configure
+++ b/qtbase/configure
@@ -5310,8 +5310,19 @@ if [ "$XPLATFORM_MAC" = "yes" ]; then
 fi
 
 # auto-detect OpenGL support (es2 = OpenGL ES 2.0 or higher)
+doOpenGLTest() {
+    if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" 
= "" -a "$XPLATFORM_MAC" = "yes" ]; then
+        # QT_QPA_DEFAULT_PLATFORM is either empty or set by the user, so we 
have to check 
+        # both manually and automatically selected cocoa. It qpa=cocoa, we do 
NOT want to
+        # use pkg-config to find the OpenGL libraries because it's too likely 
to find
+        # OpenGL libraries that are not the system frameworks appropriate for 
cocoa mode.
+        compileTest unix/opengldesktop "OpenGL"
+    else
+        compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
+    fi
+}
 if [ "$CFG_OPENGL" = "auto" ] || [ "$CFG_OPENGL" = "yes" ]; then
-    if compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL; then
+    if doOpenGLTest; then
         CFG_OPENGL=desktop
     elif compileTestWithPkgConfig glesv2 unix/opengles2 "OpenGL ES 2.0" 
OPENGL_ES2; then
         CFG_OPENGL=es2
@@ -5339,7 +5350,7 @@ elif [ "$CFG_OPENGL" = "es2" ]; then
     fi
 elif [ "$CFG_OPENGL" = "desktop" ]; then
     # Desktop OpenGL support
-    compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
+    doOpenGLTest
     if [ $? != "0" ]; then
         echo "The OpenGL functionality test failed!"
         echo " You might need to modify the include and library search paths by 
editing"




From oswald.buddenhagen at qt.io  Wed Jan 18 13:56:59 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 18 Jan 2017 13:56:59 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
In-Reply-To: <2085443.GmYgfnh0FH@portia.local>
References: <12696459.erqPW8QydK@bola> <20170118101004.GF24383@troll08>
	<2085443.GmYgfnh0FH@portia.local>
Message-ID: <20170118125659.GG24383@troll08>

On Wed, Jan 18, 2017 at 12:54:15PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> 
> > the bulk of the code is in toolchain.prf.
> > note that i have some related patches for 5.8 on gerrit.
> 
> Yes, I found toolchain.prf, and already replaced the reference to 
> /usr/local/include in there (which I think is redundant anyway as most compilers 
> on Unix look there anyway?).
> 
it's for the bsds.
it's only a fallback anyway; it shouldn't trigger on any system which
uses gcc.

> Filtering in a QMake file won't be as trivial as in a regular shell
> script,
>
yes ... it should be even easier ... ;)



From rjvbertin at gmail.com  Wed Jan 18 13:58:41 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 18 Jan 2017 13:58:41 +0100
Subject: [Development] Qt5.8/Mac: finding the correct OpenGL libraries when
 pkg-config is also used
Message-ID: <1996291.KxXAHhmyRr@portia.local>

Hi,

I'm starting a new thread for this, because it's a much bigger problem than the topic of the thread where I already posted this.

It seems the configure process picks up the X11 libGL when it's available and pkg-config is (has to be!) used to find intended dependencies.

I used to protect against that in the configure script (see the patch below), but the OpenGL detection logic has been moved from out of there, as a number of other things :-/

The patch disabled the pkgconfig check for OpenGL when building for Cocoa, but left it in when building for XCB.
IIUC the basic OpenGL test is now done in GtGui/configure.json . I can remove the pkgConfig "gl" test from that file and it seems this has the expected effect (rebuild has just started), but is there a way to do this conditionally?

Also, I had to clean the whole build directory and reconfigure from scratch to get this change to be taken into account. Is there a less brute way to reconfigure?

Thanks ... again. I hope the new configure system was worth it, for now I'm not seeing any of the benefits I understand it's supposed to have!

R.


diff --git a/qtbase/configure b/qtbase/configure
index 0b8b417..91c6bc1 100755
--- a/qtbase/configure
+++ b/qtbase/configure
@@ -5310,8 +5310,19 @@ if [ "$XPLATFORM_MAC" = "yes" ]; then
 fi
 
 # auto-detect OpenGL support (es2 = OpenGL ES 2.0 or higher)
+doOpenGLTest() {
+    if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = "" -a "$XPLATFORM_MAC" = "yes" ]; then
+        # QT_QPA_DEFAULT_PLATFORM is either empty or set by the user, so we have to check 
+        # both manually and automatically selected cocoa. It qpa=cocoa, we do NOT want to
+        # use pkg-config to find the OpenGL libraries because it's too likely to find
+        # OpenGL libraries that are not the system frameworks appropriate for cocoa mode.
+        compileTest unix/opengldesktop "OpenGL"
+    else
+        compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
+    fi
+}
 if [ "$CFG_OPENGL" = "auto" ] || [ "$CFG_OPENGL" = "yes" ]; then
-    if compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL; then
+    if doOpenGLTest; then
         CFG_OPENGL=desktop
     elif compileTestWithPkgConfig glesv2 unix/opengles2 "OpenGL ES 2.0" OPENGL_ES2; then
         CFG_OPENGL=es2
@@ -5339,7 +5350,7 @@ elif [ "$CFG_OPENGL" = "es2" ]; then
     fi
 elif [ "$CFG_OPENGL" = "desktop" ]; then
     # Desktop OpenGL support
-    compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
+    doOpenGLTest
     if [ $? != "0" ]; then
         echo "The OpenGL functionality test failed!"
         echo " You might need to modify the include and library search paths by editing"



From oswald.buddenhagen at qt.io  Wed Jan 18 14:14:59 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 18 Jan 2017 14:14:59 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <3049164.HWW1izGdnU@portia.local>
References: <3049164.HWW1izGdnU@portia.local>
Message-ID: <20170118131459.GH24383@troll08>

On Wed, Jan 18, 2017 at 03:08:03AM -0800, René J.V. Bertin wrote:
> What happened with the --no-pulseaudio configure argument? I get the
> impression that one can supposedly pass arguments to QtMultiMedia's
> configure step, but how does that work?
> 
if you're doing a top-level build, you just pass it to configure.
otherwise, "qmake <srcdir> -- -no-pulseaudio -no-gstreamer".

to re-configure, use "./config.status -recheck-all" resp.
"qmake <srcdir> -- -redo -recheck-all".
or just "rm config.cache; make qmake" if you're feeling brutal.



From rjvbertin at gmail.com  Wed Jan 18 14:16:47 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 14:16:47 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
References: <12696459.erqPW8QydK@bola> <20170118101004.GF24383@troll08>
	<2085443.GmYgfnh0FH@portia.local> <20170118125659.GG24383@troll08>
Message-ID: <3404295.Lu5jhi0If0@portia.local>

Oswald Buddenhagen wrote:

> it's only a fallback anyway; it shouldn't trigger on any system which
> uses gcc.

Or clang? Not that it matters, probably, if the compiler already looks in those 
locations by default (I'm pretty sure clang does).

>> Filtering in a QMake file won't be as trivial as in a regular shell
>> script,
>>
> yes ... it should be even easier ... ;)

Provided you're at least as fluent in qmake as in *sh and sed? :)

R



From bstottle at ford.com  Wed Jan 18 14:50:09 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Wed, 18 Jan 2017 13:50:09 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <AM4PR0202MB29485AFDD409D3A6191CA8DE8F7F0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
	<20170116151457.GC10053@troll08>
	<CF3BB45E-1D4A-4BA7-97D2-E82276638AB2@ford.com>
	<AM4PR0202MB29485AFDD409D3A6191CA8DE8F7F0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <AD9FB242-5161-4DE0-A858-B65FCCC371AA@ford.com>

On 1/18/17, 1:52 AM, "Tuukka Turunen" <tuukka.turunen at qt.io> wrote:


>> 
>
>When QtRO becomes part of Qt, would you continue as the maintainer of the module and have adequate time to polish it so that it can be fully supported in the upcoming Qt releases?
>
>Yours,
>
>	Tuukka

Sure, that is the plan.  That does however tie into a question I had.  Would my Maintainer status for the playground project automatically carry forward?  Or will I lose my approver rights once it moves into Qt?  I understand Approver rights are not granted lightly, while it is also very difficult to maintain a module without being able to +2 reviews.

What has happened in the past?

Regards,
Brett

From rjvbertin at gmail.com  Wed Jan 18 14:51:15 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 18 Jan 2017 14:51:15 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error running
 lrelease building qttranslations
Message-ID: <3690700.6U8OlGP5WM@bola>

Hello,

On linux I get the following error doing a toplevel style build of most components in qt-everywhere 5.8 :

make: Entering directory `/path/to/build/qttranslations'
cd translations/ && ( test -e Makefile || /path/to/build/qtbase/bin/qmake -o Makefile /path/to/qt-everywhere-opensource-src-5.8.0-rc/qttranslations/translations/translations.pro -qtconf /path/to/build/qtbase/bin/qt.conf -- -platform linux-g++-64 -prefix /opt/local -archdatadir /opt/local/libexec/qt5 -docdir /opt/local/share/doc/qt5 -headerdir /opt/local/include/qt5 -plugindir /opt/local/share/qt5/plugins -importdir /opt/local/share/qt5/imports -qmldir /opt/local/share/qt5/qml -datadir /opt/local/share/qt5 -bindir /opt/local/libexec/qt5/bin -libexecdir /opt/local/libexec/qt5/libexec -translationdir /opt/local/share/qt5/translations -sysconfdir /opt/local/etc/qt5 -examplesdir /opt/local/libexec/qt5/bin/examples -testsdir /opt/local/share/qt5/tests -hostbindir /opt/local/libexec/qt5/bin -hostdatadir /opt/local/share/qt5 -v -release -opensource -confirm-license -shared -libdir /opt/local/libexec/qt5/lib -hostlibdir /opt/local/libexec/qt5/lib -xcb -xcb-xlib -qpa xcb -rpath -R /opt/local/lib -R /opt/local/libexec/qt5/lib -no-reduce-relocations -make libs -make tools -nomake examples -nomake tests -verbose -no-pch -cups -icu -fontconfig -dbus-linked -glib -no-directfb -no-use-gold-linker -optimized-qmake -system-sqlite -no-sql-db2 -no-sql-ibase -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite2 -no-sql-tds -force-debug-info -no-strip -no-separate-debug-info --reduce-exports ) && make -f Makefile 
make[1]: Entering directory `/path/to/build/qttranslations/translations'
/path/to/build/qttranslations/translations/lrelease_wrapper.sh /path/to/qt-everywhere-opensource-src-5.8.0-rc/qttranslations/translations/assistant_hu.ts -qm assistant_hu.qm
Updating 'assistant_hu.qm'...
/path/to/build/qttools/bin/lrelease: relocation error: /path/to/build/qttools/bin/lrelease: symbol _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String, version Qt_5 not defined in file libQt5Core.so.5 with link time reference
make[1]: *** [assistant_hu.qm] Error 127
make[1]: Leaving directory `/path/to/build/qttranslations/translations'
make: *** [sub-translations-make_first] Error 2
make: Leaving directory `/path/to/build/qttranslations'
Command exited with non-zero status 2

%> ldd /path/to/build/qttools/bin/lrelease
        linux-vdso.so.1 =>  (0x00007ffdae338000)
        libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5 (0x00007f148dac3000)
        libQt5Core.so.5 => /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x00007f148d3dc000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f148d068000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f148cca3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f148ca84000)
        libz.so.1 => /opt/local/lib/libz.so.1 (0x00007f148c869000)
        libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f148c462000)
        libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f148c0e8000)
        libpcre16.so.0 => /opt/local/lib/libpcre16.so.0 (0x00007f148be7a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f148bc76000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f148b96d000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f148b765000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f148b45f000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f148b247000)
        /lib64/ld-linux-x86-64.so.2 (0x000055a67e80e000)
        libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f14899da000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f148979b000)

I have configured using -rpath, and the wrapper script sets LD_LIBRARY_PATH correctly as far as I can see so one of the most recent solutions found by Google cannot apply (http://stackoverflow.com/questions/36128645/error-on-execution-version-qt-5-not-found-required-by)

What can this be?

Thanks,
R.


From thomas.sondergaard at karoshealth.com  Wed Jan 18 16:21:19 2017
From: thomas.sondergaard at karoshealth.com (=?UTF-8?Q?Thomas_S=C3=B8ndergaard?=)
Date: Wed, 18 Jan 2017 16:21:19 +0100
Subject: [Development] QWidget::setWindowState(Qt::WindowStates) vs
 QWindow::setWindowState(Qt::WindowState)
In-Reply-To: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>
References: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>
Message-ID: <CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>

I hope my previous email wasn't offensive or downright stupid; no one has
replied. I certainly meant no disrespect. While I'm waiting for a response,
let me throw a specific proposal out there.

First, I assume the correct solution is to extend QWindow and
QPlatformWindow so they can deal with compound states such as
Qt::WindowMaximized|Qt::WindowMinimized, just like QWidget can. Since
QWindow::setWindowState(Qt::WindowState) and Qt::WindowState
QWindow::windowState() cannot be modified, I'm thinking of adding

Qt::WindowStates QWindow::fullWindowState() const;
void QWindow::setFullWindowState(Qt::WindowStates);

and

Qt::WindowStates QPlatformWindow::fullWindowState() const;
void QPlatformWindow::setFullWindowState(Qt::WindowStates);

The existing QWindow::windowState() would then be implemented using the
effectiveState() function from qwidget.cpp (I'd move it over)

I can experiment with these changes and implementing them in the xcb and
windows platform plugins, but early feedback is always great, so I avoid
wasting time.

Thanks for making Qt

Thomas




On 17 January 2017 at 21:37, Thomas Søndergaard <
thomas.sondergaard at karoshealth.com> wrote:

> Hi,
>
> I'm looking at the Qt code with intention to fix it so this code
>
>     QWidget widget;
>     widget.setWindowState(Qt::WindowMaximized);
>     widget.showMinized();
>
> will show the window iconified and when the user (or program) unminimize
> the window it pops up maximized. This is currently not possible (
> QTBUG-57882 <https://bugreports.qt.io/browse/QTBUG-57882>).
>
> I've been trying to read the Qt code and it seems to me the problem is
> that QWindow::setWindowState(Qt::WindowState) and QPlatformWindow::
> setWindowState(Qt::WindowState) only take a Qt::WindowState argument not
> a Qt::WindowStates argument. This seems to make it impossible to set the
> correct state on the windows-system window.
>
> Is this intentional or a known issue?
>
> I would be happy to get suggestions for how this is best fixed.
>
> Best regards,
> Thomas
>



-- 

Thomas Sondergaard | karoshealth

Product Architect


M: +45 5157 3090 | Skype: tsondergaard


Krumtappen 4, 3rd floor

DK-2500 Valby, Denmark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170118/534117dd/attachment.html>

From rjvbertin at gmail.com  Wed Jan 18 16:57:34 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 16:57:34 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
Message-ID: <2176939.T9KuBGGDei@portia.local>

Oswald Buddenhagen wrote:


> if you're doing a top-level build, you just pass it to configure.

But how? Configure now yells on -no-pulseaudio :
>> ERROR: Unknown command line option '-no-pulseaudio'.

And that error comes from qmake, possibly because it doesn't know this option 
when processing qtbase.pro (and that it needs to be instructed to cache unknown 
options for later perusal)?

I tried "-no-feature-pulseaudio", which leads to
ERROR: Enabling/Disabling unknown feature 'pulseaudio'.

(at least the option is recognised).

> otherwise, "qmake <srcdir> -- -no-pulseaudio -no-gstreamer".
> 
> to re-configure, use "./config.status -recheck-all" resp.

Corresponding to `configure -redo -recheck-all`. I missed the "recheck-all" 
option, thanks.

R.



From thiago.macieira at intel.com  Wed Jan 18 17:21:51 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 08:21:51 -0800
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
In-Reply-To: <12696459.erqPW8QydK@bola>
References: <12696459.erqPW8QydK@bola>
Message-ID: <4869425.M5TOxZ6bLd@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 09:51:43 PST René J.V. Bertin wrote:
> Hi,
> 
> Among the tweak I have in my script to build Qt for installation into
> /opt/local, using dependencies from there, I have a patch for
> qtbase/configure that prunes a number of unnecessary/undesirable items from
> DEFAULT_INCDIR and DEFAULT_LIBDIR (see below).

Why do you need to prune anything?

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



From thiago.macieira at intel.com  Wed Jan 18 17:41:52 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 08:41:52 -0800
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <3049164.HWW1izGdnU@portia.local>
References: <3049164.HWW1izGdnU@portia.local>
Message-ID: <3122424.xRJrAOf771@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 03:08:03 PST René J.V. Bertin wrote:
> But yet the configure process picks up both PulseAudio and GStreamer 1.0. As
> expected this still happens when I out-comment the relevant lines in the
> above snippet.

The section you pasted has nothing to do with the configure tests. Only the 
uses of it. So configure finds things that it will not use, as that section was 
unix:!mac.

Please confirm whether you have a real problem or just a red herring.

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



From thiago.macieira at intel.com  Wed Jan 18 17:44:19 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 08:44:19 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <3690700.6U8OlGP5WM@bola>
References: <3690700.6U8OlGP5WM@bola>
Message-ID: <10610085.pkE7NQFHkc@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 14:51:15 PST René J.V. Bertin wrote:
> symbol _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String,
> version Qt_5 not defined in file libQt5Core.so.5 with link time reference

Can you confirm whether the problem is

 a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String isn't 
present in QtCore at all; or

 b) that the symbol is present, but the Qt_5 ELF version isn't.

> %> ldd /path/to/build/qttools/bin/lrelease
>         linux-vdso.so.1 =>  (0x00007ffdae338000)
>         libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5
>         (0x00007f148dac3000) libQt5Core.so.5 =>
>         /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x00007f148d3dc000)

Was that the correct QtCore?

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



From dangelog at gmail.com  Wed Jan 18 17:50:43 2017
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Wed, 18 Jan 2017 17:50:43 +0100
Subject: [Development] QWidget::setWindowState(Qt::WindowStates) vs
 QWindow::setWindowState(Qt::WindowState)
In-Reply-To: <CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>
References: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>
	<CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>
Message-ID: <CAPm+cvgf3E42YA5+Sj7B_X9Z3mAU0_a-B5gmGg9OsEXqq7UGQA@mail.gmail.com>

On Wed, Jan 18, 2017 at 4:21 PM, Thomas Søndergaard
<thomas.sondergaard at karoshealth.com> wrote:
> I hope my previous email wasn't offensive or downright stupid; no one has
> replied. I certainly meant no disrespect. While I'm waiting for a response,
> let me throw a specific proposal out there.


FWIW I've received *both* emails right now. Email server hiccup?

-- 
Giuseppe D'Angelo


From rjvbertin at gmail.com  Wed Jan 18 18:29:16 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 18:29:16 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local>
	<3122424.xRJrAOf771@tjmaciei-mobl1>
Message-ID: <3300735.MaP4xKZtqv@portia.local>

Thiago Macieira wrote:

> Please confirm whether you have a real problem or just a red herring.

The configure summary claims it will build with support for GStreamer 1.0 and 
PulseAudio. Assuming that claim is not a red herring itself I indeed have a 
problem.



From rjvbertin at gmail.com  Wed Jan 18 18:31:36 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 18:31:36 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
References: <12696459.erqPW8QydK@bola> <4869425.M5TOxZ6bLd@tjmaciei-mobl1>
Message-ID: <10137917.LNcru7vAgB@portia.local>

Thiago Macieira wrote:

>> Among the tweak I have in my script to build Qt for installation into
>> /opt/local, using dependencies from there, I have a patch for
>> qtbase/configure that prunes a number of unnecessary/undesirable items from
>> DEFAULT_INCDIR and DEFAULT_LIBDIR (see below).
> 
> Why do you need to prune anything?

If memory serves me well unwanted libraries were being pulled in from Ubuntu's 
multiarch system libraries. Possibly system Qt5 libraries that I've since 
uninstalled.
As far as I can tell the patchfile was created almost 2y ago and never 
documented exactly what happened. It looks like the pruning is no longer 
necessary; time will tell whether I'll need to intervene in toolchain.prf.

R.



From rjvbertin at gmail.com  Wed Jan 18 18:46:53 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 18:46:53 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <3690700.6U8OlGP5WM@bola> <10610085.pkE7NQFHkc@tjmaciei-mobl1>
Message-ID: <6249913.OyTMn6BmrN@portia.local>

Thiago Macieira wrote:

> Can you confirm whether the problem is
> 
>  a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String isn't
> present in QtCore at all; or

The symbol is present in the 5.8.0 version in the build tree, but not in the 
installed version.

>  b) that the symbol is present, but the Qt_5 ELF version isn't.

How do I check that?

NB: it's only lrelease that fails, all other build steps complete just fine. I 
presume other executables must be called that also require new ABIs/symbols from 
QtCore . Setting LD_LIBRARY_PATH and QT_PLUGIN_PATH by hand I can also run just 
about any existing binary against Qt 5.8 .

> 
>> %> ldd /path/to/build/qttools/bin/lrelease
>>         linux-vdso.so.1 =>  (0x00007ffdae338000)
>>         libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5
>>         (0x00007f148dac3000) libQt5Core.so.5 =>
>>         /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x00007f148d3dc000)
> 
> Was that the correct QtCore?

That's the installed library, not the one it should be using as long as 5.8.0 
has not been installed.

Something is different between lrelease and other executables: ldd's output 
doesn't change for it when I set LD_LIBRARY_PATH as it does for qtdiag, for 
instance. Both result from the same build:

%> env LD_LIBRARY_PATH=/path/to/destroot/opt/local/libexec/qt5angel/lib 
QT_PLUGIN_PATH=/path/to/destroot/opt/local/share/qt5angel/plugins:/opt/local/share/qt5/plugins 
ldd /path/to/build/qttools/bin/qtdiag 
        linux-vdso.so.1 =>  (0x00007ffef63ed000)
        libQt5Gui.so.5 => 
/path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Gui.so.5 
(0x00007f2fcd179000)
        libQt5Network.so.5 => 
/path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Network.so.5 
(0x00007f2fccde7000)
        libQt5Core.so.5 => 
/path/to/destroot/opt/local/libexec/qt5angel/lib/libQt5Core.so.5 
(0x00007f2fcc6fc000)

%> ldd /path/to/build/qttools/bin/qtdiag                                                                                
linux-vdso.so.1 =>  (0x00007ffdbda5c000)
        libQt5Gui.so.5 => /opt/local/libexec/qt5/lib/libQt5Gui.so.5 
(0x00007f417876c000)
        libQt5Network.so.5 => /opt/local/libexec/qt5/lib/libQt5Network.so.5 
(0x00007f41783fd000)
        libQt5Core.so.5 => /opt/local/libexec/qt5/lib/libQt5Core.so.5 
(0x00007f4177d17000)




From thiago.macieira at intel.com  Wed Jan 18 19:39:34 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 10:39:34 -0800
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <3300735.MaP4xKZtqv@portia.local>
References: <3049164.HWW1izGdnU@portia.local>
	<3122424.xRJrAOf771@tjmaciei-mobl1>
	<3300735.MaP4xKZtqv@portia.local>
Message-ID: <1908416.S2PJJNq741@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 18:29:16 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Please confirm whether you have a real problem or just a red herring.
> 
> The configure summary claims it will build with support for GStreamer 1.0
> and PulseAudio. Assuming that claim is not a red herring itself I indeed
> have a problem.

Don't assume. The question stands.

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



From rjvbertin at gmail.com  Wed Jan 18 20:03:46 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 20:03:46 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local>
	<3122424.xRJrAOf771@tjmaciei-mobl1>
	<3300735.MaP4xKZtqv@portia.local>
	<1908416.S2PJJNq741@tjmaciei-mobl1>
Message-ID: <1970814.zkKvfIn1MW@portia.local>

Thiago Macieira wrote:

> Don't assume. The question stands.

Actually the answer is yes. If this message is printed as a red herring, that's 
a bug, so also a problem. It would mean that even with the libraries present I 
couldn't build WITH support for GStreamer and/or PulseAudio.

As Oswald pointed out, there are supposed to be options that determine how 
QtMultiMedia is to be configured. It isn't clear how to pass those options to 
the toplevel configure script, and I haven't succeeded to do that until now. 
That's a fishy problem too.

I have followed a complementary approach: I created a patch that causes the 
pulseaudio and gstreamer checks in QtMultiMedia's configure.json to search for 
something inexistent, and thus fails. With this, configure prints that the 
features will not be supported, and that is NOT a void claim.

I have more urgent matters to pursue than checking if a build that is announced 
to contain non-desired features will indeed contain them. I may do that later.



From thiago.macieira at intel.com  Wed Jan 18 20:27:40 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 11:27:40 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <6249913.OyTMn6BmrN@portia.local>
References: <3690700.6U8OlGP5WM@bola> <10610085.pkE7NQFHkc@tjmaciei-mobl1>
	<6249913.OyTMn6BmrN@portia.local>
Message-ID: <4028738.5qvlobGL3z@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 18:46:53 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Can you confirm whether the problem is
> > 
> >  a) that _ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String
> >  isn't> 
> > present in QtCore at all; or
> 
> The symbol is present in the 5.8.0 version in the build tree, but not in the
> installed version.

I see that the QStringList::join(QLatin1String) overload was added in 5.8. 
Does t mean that the installed version is 5.7 or earlier?

> NB: it's only lrelease that fails, all other build steps complete just fine.
> I presume other executables must be called that also require new
> ABIs/symbols from QtCore . Setting LD_LIBRARY_PATH and QT_PLUGIN_PATH by
> hand I can also run just about any existing binary against Qt 5.8 .

So what's different with lrelease? Did the wrapper not set the correct 
LD_LIBRARY_PATH?

> >> %> ldd /path/to/build/qttools/bin/lrelease
> >> 
> >>         linux-vdso.so.1 =>  (0x00007ffdae338000)
> >>         libQt5Xml.so.5 => /opt/local/libexec/qt5/lib/libQt5Xml.so.5
> >>         (0x00007f148dac3000) libQt5Core.so.5 =>
> >>         /opt/local/libexec/qt5/lib/libQt5Core.so.5 (0x00007f148d3dc000)
> > 
> > Was that the correct QtCore?
> 
> That's the installed library, not the one it should be using as long as
> 5.8.0 has not been installed.

Ok, so that is the problem. The question is why LD_LIBRARY_PATH was not 
properly set. Or...

You mentioned:
> I have configured using -rpath

Check the lrelease binary with objdump -p: do you set RPATH? Do you see 
RUNPATH?

If you see the former but not the latter, then LD_LIBRARY_PATH has no effect. 
That would also explain this behaviour:

> Something is different between lrelease and other executables: ldd's output
> doesn't change for it when I set LD_LIBRARY_PATH as it does for qtdiag, for
> instance. Both result from the same build:

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



From thiago.macieira at intel.com  Wed Jan 18 20:31:22 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 11:31:22 -0800
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
In-Reply-To: <10137917.LNcru7vAgB@portia.local>
References: <12696459.erqPW8QydK@bola> <4869425.M5TOxZ6bLd@tjmaciei-mobl1>
	<10137917.LNcru7vAgB@portia.local>
Message-ID: <1956964.Syb4dX8N9D@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 18:31:36 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> >> Among the tweak I have in my script to build Qt for installation into
> >> /opt/local, using dependencies from there, I have a patch for
> >> qtbase/configure that prunes a number of unnecessary/undesirable items
> >> from
> >> DEFAULT_INCDIR and DEFAULT_LIBDIR (see below).
> > 
> > Why do you need to prune anything?
> 
> If memory serves me well unwanted libraries were being pulled in from
> Ubuntu's multiarch system libraries. Possibly system Qt5 libraries that
> I've since uninstalled.

While that may be so, the DEFAULT_XXXDIR is only tangentially related. They 
don't add dirs to the search path. On the contrary: those remove paths that we 
may have got from pkg-config or similar.

Also, the Xcode's clang doesn't search /usr/local/include when the --sysroot 
option is passed. It's possible we performed an incorrect detection in Qt 5.7 
and earlier, but the 5.8 detection should be better.

> As far as I can tell the patchfile was created almost 2y ago and never
> documented exactly what happened. It looks like the pruning is no longer
> necessary; time will tell whether I'll need to intervene in toolchain.prf.

Right, need more information.

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



From rjvbertin at gmail.com  Wed Jan 18 21:24:45 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 21:24:45 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <3690700.6U8OlGP5WM@bola> <10610085.pkE7NQFHkc@tjmaciei-mobl1>
	<6249913.OyTMn6BmrN@portia.local>
	<4028738.5qvlobGL3z@tjmaciei-mobl1>
Message-ID: <57144091.0X3xbXNGtW@portia.local>

Thiago Macieira wrote:


> I see that the QStringList::join(QLatin1String) overload was added in 5.8.
> Does t mean that the installed version is 5.7 or earlier?

Yes, 5.7.1 .

> Ok, so that is the problem. The question is why LD_LIBRARY_PATH was not
> properly set. Or...

During the build lrelease is invoked through a wrapper which sets

LD_LIBRARY_PATH=/path/to/build/qtbase/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

that looks correct to me.


> Check the lrelease binary with objdump -p: do you set RPATH? Do you see
> RUNPATH?

That must be it:

For lrelease:
  RPATH                $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib

For qtdiag:
  RUNPATH              $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib

R




From rjvbertin at gmail.com  Wed Jan 18 23:00:06 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 18 Jan 2017 23:00:06 +0100
Subject: [Development] DEFAULT_INCDIR and DEFAULT_LIBDIR in Qt
 5.8/configure
References: <12696459.erqPW8QydK@bola> <4869425.M5TOxZ6bLd@tjmaciei-mobl1>
	<10137917.LNcru7vAgB@portia.local>
	<1956964.Syb4dX8N9D@tjmaciei-mobl1>
Message-ID: <3694610.lTxZdUlNyW@portia.local>

Thiago Macieira wrote:

> Also, the Xcode's clang doesn't search /usr/local/include when the --sysroot
> option is passed. It's possible we performed an incorrect detection in Qt 5.7
> and earlier, but the 5.8 detection should be better.

Sorry, I didn't make this explicit, but I only had to prune on Linux (I use 
almost the same build scripts on both platforms, Mac and Linux). It didn't seem 
completely relevant for the original question (where the code had gone).

I don't think the reason why I ever needed the pruning is of much general 
interest anyway. We'll see if/when the need manifests itself again.

R.



From thiago.macieira at intel.com  Thu Jan 19 00:53:20 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 18 Jan 2017 15:53:20 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <57144091.0X3xbXNGtW@portia.local>
References: <3690700.6U8OlGP5WM@bola> <4028738.5qvlobGL3z@tjmaciei-mobl1>
	<57144091.0X3xbXNGtW@portia.local>
Message-ID: <2982668.4t5Pnxh3cX@tjmaciei-mobl1>

On quarta-feira, 18 de janeiro de 2017 21:24:45 PST René J. V. Bertin wrote:
> For lrelease:
>   RPATH               
> $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
> 
> For qtdiag:
>   RUNPATH             
> $ORIGIN/../lib:/opt/local/lib:/opt/local/libexec/qt5/lib
> 
> R

Can you compare the command-lines used to link those two applications? What's 
different?

It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it 
but lrelease doesn't?

Ossi: what was the conclusion of our discussion on --enable-new-dtags?

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



From tuukka.turunen at qt.io  Thu Jan 19 07:31:27 2017
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Thu, 19 Jan 2017 06:31:27 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <AD9FB242-5161-4DE0-A858-B65FCCC371AA@ford.com>
References: <2A1B433B-F019-4A8E-A1A7-0F31C79CBB62@ford.com>
	<03DADCF2-1353-4A17-A815-371E7D54CD0F@ford.com>
	<20170111165026.GA18905@troll08>
	<CBFDA9ED-84C9-4DC6-80CB-694CF842A064@ford.com>
	<C73951BD-08B3-4F68-99B0-05FDCF53AB11@qt.io>
	<F94DE97E-14A3-4AF9-A0C7-34B28485EE1A@ford.com>
	<F7C720C6-E219-44AA-870C-5744E7019F7F@ford.com>
	<20170113150943.GB21340@troll08>
	<0A2EAE46-1AD2-473E-B29B-C5A078BE4CD4@ford.com>
	<20170116151457.GC10053@troll08>
	<CF3BB45E-1D4A-4BA7-97D2-E82276638AB2@ford.com>
	<AM4PR0202MB29485AFDD409D3A6191CA8DE8F7F0@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<AD9FB242-5161-4DE0-A858-B65FCCC371AA@ford.com>
Message-ID: <AM4PR0202MB2948A85642DEAA377551DB278F7E0@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: keskiviikkona 18. tammikuuta 2017 15.50
> To: development at qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> On 1/18/17, 1:52 AM, "Tuukka Turunen" <tuukka.turunen at qt.io> wrote:
> 
> 
> >>
> >
> >When QtRO becomes part of Qt, would you continue as the maintainer of
> the module and have adequate time to polish it so that it can be fully
> supported in the upcoming Qt releases?
> >
> >Yours,
> >
> >	Tuukka
> 
> Sure, that is the plan.  That does however tie into a question I had.  Would
> my Maintainer status for the playground project automatically carry forward?
> Or will I lose my approver rights once it moves into Qt?  I understand
> Approver rights are not granted lightly, while it is also very difficult to
> maintain a module without being able to +2 reviews.
> 
> What has happened in the past?
> 

Hi,

Unless someone objects and proposes a better maintainer (which is quite unlike as you are the main author), you would continue as the maintainer of the module.

Yours,

	Tuukka

> Regards,
> Brett
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From bo at vikingsoft.eu  Thu Jan 19 09:25:07 2017
From: bo at vikingsoft.eu (Bo Thorsen)
Date: Thu, 19 Jan 2017 09:25:07 +0100
Subject: [Development] QWidget::setWindowState(Qt::WindowStates) vs
 QWindow::setWindowState(Qt::WindowState)
In-Reply-To: <CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>
References: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>
	<CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>
Message-ID: <650f74a4-7ceb-81f3-55fb-3ab13e43d733@vikingsoft.eu>

Hej Thomas,

Please don't take silence as some indication that people are offended. I 
just think you found a corner case that no one has considered and do not 
consider one way or the other.

You ask for the best way to proceed: As usual with issues like this, you 
should enter a bug in the bug tracker.

Bo Thorsen.

Den 18-01-2017 kl. 16:21 skrev Thomas Søndergaard:
> I hope my previous email wasn't offensive or downright stupid; no one
> has replied. I certainly meant no disrespect. While I'm waiting for a
> response, let me throw a specific proposal out there.
>
> First, I assume the correct solution is to extend QWindow and
> QPlatformWindow so they can deal with compound states such as
> Qt::WindowMaximized|Qt::WindowMinimized, just like QWidget can. Since
> QWindow::setWindowState(Qt::WindowState) and Qt::WindowState
> QWindow::windowState() cannot be modified, I'm thinking of adding
>
> Qt::WindowStates QWindow::fullWindowState() const;
> void QWindow::setFullWindowState(Qt::WindowStates);
>
> and
>
> Qt::WindowStates QPlatformWindow::fullWindowState() const;
> void QPlatformWindow::setFullWindowState(Qt::WindowStates);
>
> The existing QWindow::windowState() would then be implemented using the
> effectiveState() function from qwidget.cpp (I'd move it over)
>
> I can experiment with these changes and implementing them in the xcb and
> windows platform plugins, but early feedback is always great, so I avoid
> wasting time.
>
> Thanks for making Qt
>
> Thomas
>
>
>
>
> On 17 January 2017 at 21:37, Thomas Søndergaard
> <thomas.sondergaard at karoshealth.com
> <mailto:thomas.sondergaard at karoshealth.com>> wrote:
>
>     Hi,
>
>     I'm looking at the Qt code with intention to fix it so this code
>
>         QWidget widget;
>         widget.setWindowState(Qt::WindowMaximized);
>         widget.showMinized();
>
>     will show the window iconified and when the user (or program)
>     unminimize the window it pops up maximized. This is currently not
>     possible (QTBUG-57882 <https://bugreports.qt.io/browse/QTBUG-57882>).
>
>     I've been trying to read the Qt code and it seems to me the problem
>     is that QWindow::setWindowState(Qt::WindowState) and
>     QPlatformWindow::setWindowState(Qt::WindowState) only take a
>     Qt::WindowState argument not a Qt::WindowStates argument. This seems
>     to make it impossible to set the correct state on the windows-system
>     window.
>
>     Is this intentional or a known issue?
>
>     I would be happy to get suggestions for how this is best fixed.


Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu


From oswald.buddenhagen at qt.io  Thu Jan 19 11:41:43 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 19 Jan 2017 11:41:43 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <2982668.4t5Pnxh3cX@tjmaciei-mobl1>
References: <3690700.6U8OlGP5WM@bola> <4028738.5qvlobGL3z@tjmaciei-mobl1>
	<57144091.0X3xbXNGtW@portia.local>
	<2982668.4t5Pnxh3cX@tjmaciei-mobl1>
Message-ID: <20170119104143.GB30487@ugly>

On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote:
> Ossi: what was the conclusion of our discussion on --enable-new-dtags?
> 
it's now enabled by default. i have no clue why it would be wrong for
lrelease. a more complete survey of the executables in the qt build dir
would be necessary (check for stale files!).



From rjvbertin at gmail.com  Thu Jan 19 11:55:25 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Thu, 19 Jan 2017 11:55:25 +0100
Subject: [Development] platform theme plugins and automatically loading them
Message-ID: <2684170.AbVgOGtKZq@bola>

Hi,

You probably remember that I have been tinkering with an auto-loading Qt platform theme plugin for Mac, an adapted version of the KDE platform theme plugin from "Plasma Integration". The goal is to provide support for KDE's colour & icon palettes plus font role definitions (from kdeglobals) which can then be used with any application style including the native macintosh style. This makes KF5 applications look a lot more how they are designed to look.

The set-up is simple:
- QCocoaIntegration::themeNames() returns an additional theme name, "kde"
- the build system is patched so that qgenericunixservices and qgenericunixthemes are built and included, so a "kde" theme is defined at that level
- the platform theme plugin declares a org.qt-project.Qt.QPA.QPlatformThemeFactoryInterface.5.1 key "kde".
- the platform theme plugin main class has a proxy to the native theme, created as

nativeTheme = QGuiApplicationPrivate::platformIntegration()->createPlatformTheme(QGuiApplication::platformName());

That proxy is used whenever the theme plugin doesn't completely override the native theme choice.

I'm not really sure exactly why, but this works, nor to what extent QGenericUnixThemes are required (I've tried following the execution flow but the lldb debugger tends to get stuck).

Two questions: 

1. Does the platform theme plugin have to be called "kde", i.e. have the same name as the internal "kde" theme? IOW, are platform theme plugins matched to existing internal plugins themes (to extend them), or are they "plugins that provide additional platform themes"? In yet other words, can I call the platform theme plugin "cocoa" and leave out the internal QKdeTheme?

2. Has anything changed in the related functionality between Qt 5.7.1 and Qt 5.8.0? I'm currently testing 5.8.0RC installed into a "destroot" (make install INSTALL_ROOT=foo) using DYLD_FRAMEWORK_PATH and QT_PLUGIN_PATH set appropriately. Existing apps run fine and even use my installed application styles, but apparently NOT the platform theme plugin. I thus get the KDE look and feel, but all platform integration is lost that is normally provided through the native theme proxy. My platform theme binary is loaded from what I can tell, but its entry point isn't called. Is that to be expected?

Thanks,
René




From oswald.buddenhagen at qt.io  Thu Jan 19 11:56:52 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 19 Jan 2017 11:56:52 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <2176939.T9KuBGGDei@portia.local>
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local>
Message-ID: <20170119105651.GC30487@ugly>

On Wed, Jan 18, 2017 at 04:57:34PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> > if you're doing a top-level build, you just pass it to configure.
> 
> But how? Configure now yells on -no-pulseaudio :
> >> ERROR: Unknown command line option '-no-pulseaudio'.
> 
> And that error comes from qmake, possibly because it doesn't know this option 
> when processing qtbase.pro (and that it needs to be instructed to cache unknown 
> options for later perusal)?
> 
> I tried "-no-feature-pulseaudio", which leads to
> ERROR: Enabling/Disabling unknown feature 'pulseaudio'.
> 
> (at least the option is recognised).
> 
that's what happens when you don't follow my instructions. i explicitly
told you that the configure approach is for a top-level (qt5.git) build.

> > otherwise, "qmake <srcdir> -- -no-pulseaudio -no-gstreamer".
> > 
*this* is the syntax you need. _in qtmultimedia_.



From b.terrier at gmail.com  Thu Jan 19 12:24:34 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Thu, 19 Jan 2017 12:24:34 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <10897770.bxSinyeOCv@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
	<10897770.bxSinyeOCv@tjmaciei-mobl1>
Message-ID: <CAO+E9ooWGKKPmS=3ageuK18dx2hLZ_zjttN-WHhaGS2Hd_MAfg@mail.gmail.com>

Hi,

I've got an issue.

Adding

template <typename Func>
static typename
QtPrivate::QEnableIf<!QtPrivate::FunctionPointer<Func>::IsPointerToMemberFunction
  && QtPrivate::FunctionPointer<Func>::ArgumentCount == -1
  && !std::is_same<const char*, Func>::value, bool>::Type
  invokeMethod(QObject *object, Func function)

to QMetaObject breaks existing code and the auto tests in particular.

In tst_qmetaobject.cpp there is this test:
QVERIFY(!QMetaObject::invokeMethod(&obj, 0));
because the new overload of invokeMethod() gets called this lead to
compilation error instead
of just returning false at run-time.

To solve the issue one must add an explicit cast like so:
QVERIFY(!QMetaObject::invokeMethod(&obj, (const char*)0));
Note that casting to "char *" does not solve the issue.

Is this "source break"  acceptable (it might be looking at "Source
break policy for function overloads" discussion and quip 6) and the
autotests should be fixed?
Or should another solution be found (Thiago proposed to use a
different name in QTBUG-37253)?

Thanks

Regards,

Benjamin


From rjvbertin at gmail.com  Thu Jan 19 14:31:29 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Thu, 19 Jan 2017 14:31:29 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
Message-ID: <30311520.oodxC44c8O@bola>

Thiago Macieira wrote:

> Can you compare the command-lines used to link those two applications? What's
> different?

qtdiag:

g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../bin/qtdiag .obj/main.o .obj/qtdiag.o   -L/usr/X11R6/lib64 -L/path/to/build/qtbase/lib -lQt5Gui -lQt5Network -lQt5Core -lGL -lpthread

lrelease, lupdate & lconvert:

g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lrelease .obj/main.o .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/ioutils.o .obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o .obj/qmakeparser.o .obj/qmakeevaluator.o .obj/qmakebuiltins.o .obj/profileevaluator.o .obj/qrc_proparser.o   -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread 
g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lupdate .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/ioutils.o .obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o .obj/qmakeparser.o .obj/qmakeevaluator.o .obj/qmakebuiltins.o .obj/profileevaluator.o .obj/main.o .obj/merge.o .obj/simtexth.o .obj/cpp.o .obj/java.o .obj/ui.o .obj/qdeclarative.o .obj/qrc_proparser.o   -L/path/to/build/qtdeclarative/lib -lQt5QmlDevTools -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread 
g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../../bin/lconvert .obj/main.o .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o   -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread

linguist:

g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath-link,/path/to/build/qttools/lib -o ../../../bin/linguist .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/batchtranslationdialog.o .obj/errorsview.o .obj/finddialog.o .obj/formpreviewview.o .obj/globals.o .obj/main.o .obj/mainwindow.o .obj/messageeditor.o .obj/messageeditorwidgets.o .obj/messagehighlighter.o .obj/messagemodel.o .obj/phrasebookbox.o .obj/phrase.o .obj/phrasemodel.o .obj/phraseview.o .obj/printout.o .obj/recentfiles.o .obj/sourcecodeview.o .obj/statistics.o .obj/translatedialog.o .obj/translationsettingsdialog.o .obj/simtexth.o .obj/qrc_linguist.o .obj/moc_batchtranslationdialog.o .obj/moc_errorsview.o .obj/moc_finddialog.o .obj/moc_formpreviewview.o .obj/moc_mainwindow.o .obj/moc_messageeditor.o .obj/moc_messageeditorwidgets.o .obj/moc_messagehighlighter.o .obj/moc_messagemodel.o .obj/moc_phrasebookbox.o .obj/moc_phrase.o .obj/moc_phrasemodel.o .obj/moc_phraseview.o .obj/moc_recentfiles.o .obj/moc_sourcecodeview.o .obj/moc_statistics.o .obj/moc_translatedialog.o .obj/moc_translationsettingsdialog.o   -L/usr/X11R6/lib64 -L/path/to/build/qttools/lib -lQt5UiTools -L/path/to/build/qtbase/lib -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread

> It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it
> but lrelease doesn't?

Yep. Neither do lupdate and lconvert, but linguist does (they come all from the linguist dir). A bit as if the non-gui utilities were left out.

Oswald Buddenhagen wrote:

> On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote:
>> Ossi: what was the conclusion of our discussion on --enable-new-dtags?
>> 
> it's now enabled by default. i have no clue why it would be wrong for
> lrelease. a more complete survey of the executables in the qt build dir
> would be necessary (check for stale files!).

This was in a fresh build-from-scratch, so stale files should be unlikely.


From rjvbertin at gmail.com  Thu Jan 19 14:40:43 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 19 Jan 2017 14:40:43 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
Message-ID: <3422221.6D8iA3gxC2@patux.local>

Oswald Buddenhagen wrote:


>> 
> that's what happens when you don't follow my instructions. i explicitly
> told you that the configure approach is for a top-level (qt5.git) build.

You wrote
>> if you're doing a top-level build, you just pass it to configure.

I'm doing a top-level build, not from qt5.git but from the qt-everywhere-
opensource-5.8.0RC tarball. So I'm using a traditional configure/make/make 
install cycle.

When you pass -no-pulseaudio to configure it ends up in the "qmake [...] -- 
"[...] -no-pulseaudio [...]" commandline. 

>> > otherwise, "qmake <srcdir> -- -no-pulseaudio -no-gstreamer".
>> > 
> *this* is the syntax you need. _in qtmultimedia_.

Yeah, I got that, but it's not what I'm doing.

R.



From rjvbertin at gmail.com  Thu Jan 19 15:41:03 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 19 Jan 2017 15:41:03 +0100
Subject: [Development] platform theme plugins and automatically loading
 them
References: <2684170.AbVgOGtKZq@bola>
Message-ID: <6335529.rJLyWVqult@portia.local>

René J.V. Bertin wrote:

> 1. Does the platform theme plugin have to be called "kde", i.e. have the same
> name as the internal "kde" theme? IOW, are platform theme plugins matched to
> existing internal plugins themes (to extend them), or are they "plugins that
> provide additional platform themes"? In yet other words, can I call the
> platform theme plugin "cocoa" and leave out the internal QKdeTheme?

To answer this myself: No, the plugin doesn't need to be called "kde" and the 
built-in kde theme from qgenericunixthemes isn't required.
And yes, if I rename the platform theme plugin to "cocoa" it is always loaded 
without need to add an extra theme name in qcocoaintegration.

R.



From devel at g76r.eu  Thu Jan 19 16:18:30 2017
From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=)
Date: Thu, 19 Jan 2017 16:18:30 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <10897770.bxSinyeOCv@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
	<10897770.bxSinyeOCv@tjmaciei-mobl1>
Message-ID: <c1af544f-5514-20c5-5d08-537d54532617@g76r.eu>

Le 17/01/2017 à 18:11, Thiago Macieira a écrit :
> Em terça-feira, 17 de janeiro de 2017, às 11:21:56 PST, Grégoire Barbier
> escreveu:
>> And maybe lambdas too, if there was a way to choose the thread/eventloop
>> in which we want the lambda to be executed (but christmas was a few
>> weeks ago, I should not dream ;-)).
>
> If we do this, it should be possible to write:
>
> 	QMetaObject::invokeMethod(object, [=]() {
> 		doSomething(); return something; },
> 		Qt::BlockingQueuedConnection,
> 		Q_RETURN_ARG(foo));

It would be great. :-)

> Since we have lambdas and std::bind, I don't see the point of supporting
> passing arguments.

Agree.

> The return value is interesting still.

With lambdas the return value itself can be replaced with a captured 
reference, isn't it ?
Anyway it's still convenient to have it when calling plain old methods 
rather than lambdas.


-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49


From rjvbertin at gmail.com  Thu Jan 19 18:31:49 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 19 Jan 2017 18:31:49 +0100
Subject: [Development] platform theme plugins and automatically loading
 them
References: <2684170.AbVgOGtKZq@bola>
Message-ID: <7803975.nOsVFKo1t3@portia.local>

René J.V. Bertin wrote:


> 2. Has anything changed in the related functionality between Qt 5.7.1 and Qt
> 5.8.0? I'm currently testing 5.8.0RC installed into a "destroot" (make install

Something has indeed changed here, but apparently already in 5.7.1 . I have a 
version check in my platform theme plugin that prints a warning in case of a 
mismatch, and that always worked. AFAICR I didn't have to rebuild the plugin 
before it loaded when I upgraded from 5.6.2 to 5.7.1, I just got that warning 
every time I started an application.

The lack of feedback is quite annoying actually, esp. since other plugins load 
without problem.

R.



From thomas.sondergaard at karoshealth.com  Thu Jan 19 19:17:14 2017
From: thomas.sondergaard at karoshealth.com (=?UTF-8?Q?Thomas_S=C3=B8ndergaard?=)
Date: Thu, 19 Jan 2017 18:17:14 +0000
Subject: [Development] QWidget::setWindowState(Qt::WindowStates) vs
 QWindow::setWindowState(Qt::WindowState)
In-Reply-To: <650f74a4-7ceb-81f3-55fb-3ab13e43d733@vikingsoft.eu>
References: <CAC551QsbGMeCk1bkThBwkme=4c86XYRw1Q2pF7RRBOd_vN3aYQ@mail.gmail.com>
	<CAC551QtFau3MVhr7=SpYEkis1Zpf89Lu_aHTdfLy_yF58zomcw@mail.gmail.com>
	<650f74a4-7ceb-81f3-55fb-3ab13e43d733@vikingsoft.eu>
Message-ID: <CAC551QvvdHzPVBhiXRex7Pt+EbOBqdonzRV+ytU1AkW9stBR+A@mail.gmail.com>

Hi Bo

On Thu, 19 Jan 2017 at 09.25, Bo Thorsen <bo at vikingsoft.eu> wrote:

> Hej Thomas
>

> [...]


> You ask for the best way to proceed: As usual with issues like this, you
>
> should enter a bug in the bug tracker.
>
I did, QTBUG-57882. See original post.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170119/09d034e7/attachment.html>

From giuseppe.dangelo at kdab.com  Thu Jan 19 19:34:08 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Thu, 19 Jan 2017 19:34:08 +0100
Subject: [Development] Texture image loading library
Message-ID: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>

Hi,
As part of some ongoing work I'd like to add some private classes in Qt
to deal with loading of texture files.

Texture files (.dds, .ktx, etc.) are somehow different from ordinary
image files. Not only they store image data in GPU-oriented formats
(that don't require any decoding on the CPU), but a given texture can be
made by multiple images arranged in a complex way (e.g. _one_ texture
can be an array of images with multiple mipmap levels). As such, we
currently don't have APIs to deal with them, and QImage is definitely
the wrong class.

Nonetheless, since such loaders would be useful in more than one place
(qtbase, qtdeclarative, qt3d) I think that the best place for them would
be a new private library in qtimageformats.

(Most of the code in question would actually be extracted from qt3d,
which already has DDS/KTX loaders.)

What do you think?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170119/a4aa6a03/attachment.bin>

From oswald.buddenhagen at qt.io  Thu Jan 19 21:23:55 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 19 Jan 2017 21:23:55 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <3422221.6D8iA3gxC2@patux.local>
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local>
Message-ID: <20170119202355.GD30487@ugly>

On Thu, Jan 19, 2017 at 02:40:43PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> > that's what happens when you don't follow my instructions. i explicitly
> > told you that the configure approach is for a top-level (qt5.git) build.
> 
> You wrote
> >> if you're doing a top-level build, you just pass it to configure.
> 
> I'm doing a top-level build, not from qt5.git but from the qt-everywhere-
> opensource-5.8.0RC tarball. So I'm using a traditional configure/make/make 
> install cycle.
> 
that doesn't matter. the point is that you talked about qtbase.pro
instead of the top-level project qt.pro.


From oswald.buddenhagen at qt.io  Thu Jan 19 22:15:38 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 19 Jan 2017 22:15:38 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <30311520.oodxC44c8O@bola>
References: <30311520.oodxC44c8O@bola>
Message-ID: <20170119211538.GE30487@ugly>

On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote:
> Thiago Macieira wrote:
> > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it
> > but lrelease doesn't?
> 
> Yep. Neither do lupdate and lconvert, but linguist does (they come all from the linguist dir). A bit as if the non-gui utilities were left out.
> 
that's actually mostly what is happening. the host tools don't use new
dtags, because there is no configure test for that.
of course, it's actually a bit silly that this is also done for native
builds, so https://codereview.qt-project.org/182877 .
cross-builds will of course continue to suffer from this problem.
also, when you look in the patch's context, you'll notice that
reduce_relocations and separate_debug_info should actually also be
covered by the conditions, but i didn't want to make the coverage even
worse.

one way to fix this would be duplicating all configure tests that apply
to host tools. we actually already do that for a few things.

the other solution would be not building host tools at all when doing a
cross-build, but requiring a native build as a basis.
qmake in the 5.8 branch is actually at a point where this would be kinda
easy to implement.
however, doing that would be a rather significant break in how things
are handled from the user perspective, so we may want to hold this off
until we do something as drastic as switching build systems altogether,
at least when this build mode becomes the only option.


From rjvbertin at gmail.com  Thu Jan 19 22:20:59 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 19 Jan 2017 22:20:59 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
Message-ID: <2412448.GjSeErjmQu@portia.local>

Oswald Buddenhagen wrote:


> that doesn't matter. the point is that you talked about qtbase.pro
> instead of the top-level project qt.pro.

I've also been talking since the beginning about configure. Sorry about the 
confusion. That configure script is obfuscated enough to make it very easy to 
miss the fact it chdirs back up 1 level (after the toplevel configure script did 
the opposite).

The fact remains that it's qmake that complains about unknown arguments when I 
pass -no-pulseaudio and/or -no-gstreamer.

Let me try to reformulate the question: what options must I pass to
../qt-everywhere-opensource-src-5.8.0-rc/configure so that the qtmultimedia 
component is built without pulseaudio and gstreamer support? I'm doing an out-
of-source build, hence the "../qt*".

R.



From oswald.buddenhagen at qt.io  Thu Jan 19 22:22:17 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 19 Jan 2017 22:22:17 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
Message-ID: <20170119212217.GF30487@ugly>

On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> Nonetheless, since such loaders would be useful in more than one place
> (qtbase, qtdeclarative, qt3d) I think that the best place for them would
> be a new private library in qtimageformats.
> 
you can't put it there if qtbase is to use it.

the central "regular" image loaders are in qtgui, and the "elementary"
(6MeB of sources ...) opengl support is nowadays also in qtgui, so it
seems quite plausible to put the texture loaders there as well.


From rjvbertin at gmail.com  Thu Jan 19 23:00:58 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 19 Jan 2017 23:00:58 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <30311520.oodxC44c8O@bola> <20170119211538.GE30487@ugly>
Message-ID: <9069557.ocROtIixcQ@portia.local>

Oswald Buddenhagen wrote:

> On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote:
>> Thiago Macieira wrote:
>> > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has
>> > it but lrelease doesn't?
>> 
>> Yep. Neither do lupdate and lconvert, but linguist does (they come all from
>> the linguist dir). A bit as if the non-gui utilities were left out.
>> 
> that's actually mostly what is happening. the host tools don't use new
> dtags, because there is no configure test for that.

Ah, of course, makes sense, and that probably means lrelease and siblings aren't 
the only ones that would fail in a similar when used during the build? Curiously 
it doesn't seem to be the case with qmake, moc etc.

> of course, it's actually a bit silly that this is also done for native
> builds, so https://codereview.qt-project.org/182877 .

Ah, dang, I got the invite for that before I saw this. 

> cross-builds will of course continue to suffer from this problem.

It's already quite a feat a software collection this complex can be cross-build, 
it doesn't shock me that doing this puts stricter constraints on the host than 
doing a native build. Like using a pure Gnome desktop :)

> the other solution would be not building host tools at all when doing a
> cross-build, but requiring a native build as a basis.

I think that would make a lot of sense, esp. when using clang (which is cross-
platform capable off the shelf).

> however, doing that would be a rather significant break in how things
> are handled from the user perspective

That's never nice, but does it really have to change a lot that's not "behind 
the scenes", besides the requirement of having done a native build first? Those 
host tools are now built as part of the overall build process, the effect of not 
having to do could be limited to a faster cross build?

R



From thiago.macieira at intel.com  Fri Jan 20 02:49:18 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 17:49:18 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <20170119211538.GE30487@ugly>
References: <30311520.oodxC44c8O@bola> <20170119211538.GE30487@ugly>
Message-ID: <5713818.M5Skm0smuH@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 22:15:38 PST Oswald Buddenhagen wrote:
> the other solution would be not building host tools at all when doing a
> cross-build, but requiring a native build as a basis.

Long-term we should do that, but we need to support the current way for a 
couple of releases.

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



From thiago.macieira at intel.com  Fri Jan 20 02:52:31 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 17:52:31 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <9069557.ocROtIixcQ@portia.local>
References: <30311520.oodxC44c8O@bola> <20170119211538.GE30487@ugly>
	<9069557.ocROtIixcQ@portia.local>
Message-ID: <1674503.xn2ZNG9tWW@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 23:00:58 PST René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> > that's actually mostly what is happening. the host tools don't use new
> > dtags, because there is no configure test for that.
> 
> Ah, of course, makes sense, and that probably means lrelease and siblings
> aren't the only ones that would fail in a similar when used during the
> build? Curiously it doesn't seem to be the case with qmake, moc etc.

The tools affected are those that can be bootstrapped but weren't (because 
it's not a cross compilation). Since they weren't bootstrapped, they link to 
the Qt libraries being compiled, which results in the linking problem.

qmake, moc and rcc are always bootstrapped.

But uic should be suffering from this

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



From thiago.macieira at intel.com  Fri Jan 20 02:53:58 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 17:53:58 -0800
Subject: [Development] Texture image loading library
In-Reply-To: <20170119212217.GF30487@ugly>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly>
Message-ID: <15354361.lzZear9qlH@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 22:22:17 PST Oswald Buddenhagen wrote:
> the central "regular" image loaders are in qtgui, and the "elementary"
> (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> seems quite plausible to put the texture loaders there as well.

And eventually they could become public API.

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



From thiago.macieira at intel.com  Fri Jan 20 03:01:54 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 18:01:54 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <CAO+E9ooWGKKPmS=3ageuK18dx2hLZ_zjttN-WHhaGS2Hd_MAfg@mail.gmail.com>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<10897770.bxSinyeOCv@tjmaciei-mobl1>
	<CAO+E9ooWGKKPmS=3ageuK18dx2hLZ_zjttN-WHhaGS2Hd_MAfg@mail.gmail.com>
Message-ID: <30349975.Y0Ycl6y2NR@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 12:24:34 PST Benjamin TERRIER wrote:
> template <typename Func>
> static typename
> QtPrivate::QEnableIf<!QtPrivate::FunctionPointer<Func>::IsPointerToMemberFun
> ction && QtPrivate::FunctionPointer<Func>::ArgumentCount == -1
>   && !std::is_same<const char*, Func>::value, bool>::Type
>   invokeMethod(QObject *object, Func function)
> 
> to QMetaObject breaks existing code and the auto tests in particular.
> 
> In tst_qmetaobject.cpp there is this test:
> QVERIFY(!QMetaObject::invokeMethod(&obj, 0));
> because the new overload of invokeMethod() gets called this lead to
> compilation error instead
> of just returning false at run-time.
> 
> To solve the issue one must add an explicit cast like so:
> QVERIFY(!QMetaObject::invokeMethod(&obj, (const char*)0));
> Note that casting to "char *" does not solve the issue.

Because it's a template, so the template when Func = char* matches better than 
the overload with const char*. I assume that using nullptr without casting 
also breaks, correct?

> Is this "source break"  acceptable (it might be looking at "Source
> break policy for function overloads" discussion and quip 6) and the
> autotests should be fixed?

>From what you explained, this will not affect the case when the pointer is a 
const char *, so neither

	const char *func = "deleteLater";
	QMetaObject::invokeMethod(&obj, func);

nor

	const char *func = nullptr;
	QMetaObject::invokeMethod(&obj, func);

will stop compiling. So if you add an overload taking a non-const char* (and 
its unit test), we also catch the even more dubious code:

	char func[] = "deleteLater";
	QMetaObject::invokeMethod(&obj, func);

The only case that would break would be for a constant null pointer literal, 
which in my opinion is acceptable, since it should never happen in real code.

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



From thiago.macieira at intel.com  Fri Jan 20 03:06:15 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 18:06:15 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <c1af544f-5514-20c5-5d08-537d54532617@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<10897770.bxSinyeOCv@tjmaciei-mobl1>
	<c1af544f-5514-20c5-5d08-537d54532617@g76r.eu>
Message-ID: <8483155.DrVsvcOi5s@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 16:18:30 PST Grégoire Barbier wrote:
> > The return value is interesting still.
> 
> With lambdas the return value itself can be replaced with a captured
> reference, isn't it ?
> Anyway it's still convenient to have it when calling plain old methods
> rather than lambdas.

Hmm... right. What I had proposed:

       QMetaObject::invokeMethod(object, [=]() { 
                doSomething(); return something; },
                Qt::BlockingQueuedConnection,
                Q_RETURN_ARG(foo));

Could be rewritten as:

       QMetaObject::invokeMethod(object, [=, &foo]() { 
                doSomething(); foo = something; },
                Qt::BlockingQueuedConnection);

And that allows us to drop the Q_RETURN_ARG ugliness. That's much better.

PS: should we invert the argument order and have the connection type appear 
before the functor? I find it ugly to have a lambda in the middle of a 
parameter list.

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



From thiago.macieira at intel.com  Fri Jan 20 03:07:23 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 19 Jan 2017 18:07:23 -0800
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <2412448.GjSeErjmQu@portia.local>
References: <3049164.HWW1izGdnU@portia.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local>
Message-ID: <6107075.WrVyhs6MEK@tjmaciei-mobl1>

On quinta-feira, 19 de janeiro de 2017 22:20:59 PST René J. V. Bertin wrote:
> I've also been talking since the beginning about configure. Sorry about the
> confusion.

There are two configure scripts: one in the top-level and one in qtbase. Please 
be clear which one you mean.

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



From marc.mutz at kdab.com  Fri Jan 20 09:10:45 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 20 Jan 2017 09:10:45 +0100
Subject: [Development] Status of 5.6
Message-ID: <201701200910.45106.marc.mutz@kdab.com>

Hi,

I noted that mere mortals can't stage stuff to 5.6 anymore, and no-one else 
does, either, at least for qtbase (last was on Jan 10th, when appearently 
there wasn't a lock-down, yet?).

There are tons of accepted backports waiting to be staged, some for security-
critical fixes...

What's going on?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From laszlo.agocs at qt.io  Fri Jan 20 09:25:48 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Fri, 20 Jan 2017 08:25:48 +0000
Subject: [Development] Texture image loading library
In-Reply-To: <15354361.lzZear9qlH@tjmaciei-mobl1>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly>,<15354361.lzZear9qlH@tjmaciei-mobl1>
Message-ID: <AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>


Hi Giuseppe,


It is hard to say for sure without seeing the actual code, but if there are no 3rd party dependencies involved and all we are talking about is a compact, private helper class in the style of Qt3D's current TextureLoadingHelper, then adding it next to QOpenGL* in QtGui is still the way to go. (long term these GL enablers should be moved out from QtGui but that's something for the far future and is not feasible to change now)


This would bring the benefit of potential reuse in the Quick (Image element) compressed texture support, once that materializes at some point in the future.


Are ETC1 and ETC2 included? They would be fairly important as well.


Best regards,

Laszlo



________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Friday, January 20, 2017 2:53 AM
To: development at qt-project.org
Subject: Re: [Development] Texture image loading library

On quinta-feira, 19 de janeiro de 2017 22:22:17 PST Oswald Buddenhagen wrote:
> the central "regular" image loaders are in qtgui, and the "elementary"
> (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> seems quite plausible to put the texture loaders there as well.

And eventually they could become public API.

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

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/07838bc9/attachment.html>

From b.terrier at gmail.com  Fri Jan 20 09:59:55 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Fri, 20 Jan 2017 09:59:55 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <30349975.Y0Ycl6y2NR@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<10897770.bxSinyeOCv@tjmaciei-mobl1>
	<CAO+E9ooWGKKPmS=3ageuK18dx2hLZ_zjttN-WHhaGS2Hd_MAfg@mail.gmail.com>
	<30349975.Y0Ycl6y2NR@tjmaciei-mobl1>
Message-ID: <CAO+E9oq0v=H+tT0ROB6wEJn7K_iLiegy2YGHFqZ26Yn8uEC36g@mail.gmail.com>

2017-01-20 3:01 GMT+01:00 Thiago Macieira <thiago.macieira at intel.com>:
> Because it's a template, so the template when Func = char* matches better than
> the overload with const char*. I assume that using nullptr without casting
> also breaks, correct?

Correct.

> From what you explained, this will not affect the case when the pointer is a
> const char *, so neither
>
>         const char *func = "deleteLater";
>         QMetaObject::invokeMethod(&obj, func);
>
> nor
>
>         const char *func = nullptr;
>         QMetaObject::invokeMethod(&obj, func);
>
> will stop compiling. So if you add an overload taking a non-const char* (and
> its unit test), we also catch the even more dubious code:
>
>         char func[] = "deleteLater";
>         QMetaObject::invokeMethod(&obj, func);
>
> The only case that would break would be for a constant null pointer literal,
> which in my opinion is acceptable, since it should never happen in real code.

As an alternative to adding "char *" overload, it seems that replacing
"std::is_same<const char *,Func>"
by "std::is_same<char *, Func>" in the "QtPrivate::QEnableIf" part of
the template solves the issue
for char * and const char *.


Also I have checked QTimer and QTimer::singleShot(0, &obj, (char *)0);
doesn't compile because
the "wrong" overload is chosen. Removing the const in the std::is_same
should also fix this.


From edward.welbourne at qt.io  Fri Jan 20 10:12:03 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Fri, 20 Jan 2017 09:12:03 +0000
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <6107075.WrVyhs6MEK@tjmaciei-mobl1>
References: <3049164.HWW1izGdnU@portia.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local>,<6107075.WrVyhs6MEK@tjmaciei-mobl1>
Message-ID: <HE1PR0202MB2683E231087D71D2F148C0C787710@HE1PR0202MB2683.eurprd02.prod.outlook.com>

On quinta-feira, 19 de janeiro de 2017 22:20:59 PST René J. V. Bertin wrote:
>> I've also been talking since the beginning about configure. Sorry
>> about the confusion.

Thiago Macieira replied:
> There are two configure scripts: one in the top-level and one in
> qtbase. Please be clear which one you mean.

René had continued, saying:
>> Let me try to reformulate the question: what options must I pass to
>> ../qt-everywhere-opensource-src-5.8.0-rc/configure so that the qtmultimedia 
>> component is built without pulseaudio and gstreamer support?

which I suppose to be fairly explicit about which configure script he's
talking about.

        Eddy.


From rjvbertin at gmail.com  Fri Jan 20 10:35:35 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 20 Jan 2017 10:35:35 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local>
	<6107075.WrVyhs6MEK@tjmaciei-mobl1>
	<HE1PR0202MB2683E231087D71D2F148C0C787710@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <5633450.DGfcQWWgJu@patux.local>

Edward Welbourne wrote:

> which I suppose to be fairly explicit about which configure script he's
> talking about.

Thanks, Eddy.

I know it's important to avoid ambiguity, but I have also mentioned from the 
beginning that I was doing a top-level build and it simply didn't occur to me 
immediately that there could be confusion about which configure script I was 
calling. Apologies for that, but why would someone call qt-
everywhere*/qtbase/configure directly in a top-level build, instead of qt-
everywhere*/configure? Or worse, even if I did, would I be stupid enough to skip 
the -top-level argument which is evidently the reason I knew this is called 
doing a top-level build?!

R.



From giuseppe.dangelo at kdab.com  Fri Jan 20 10:38:35 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 20 Jan 2017 10:38:35 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <20170119212217.GF30487@ugly>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly>
Message-ID: <d714dc62-9c6a-11cb-9831-05db00dab6f7@kdab.com>

Il 19/01/2017 22:22, Oswald Buddenhagen ha scritto:
> you can't put it there if qtbase is to use it.

*Shees* Sorry, I planned to write that Qtbase is unlikely to use it
directly, except for providing enablers to other modules. But ok, let's
put this stuff in there.

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/7a43939a/attachment.bin>

From giuseppe.dangelo at kdab.com  Fri Jan 20 10:45:30 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 20 Jan 2017 10:45:30 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
Message-ID: <cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>

Il 20/01/2017 09:25, Laszlo Agocs ha scritto:
> This would bring the benefit of potential reuse in the Quick (Image
> element) compressed texture support, once that materializes at some
> point in the future.
> 
> 
> Are ETC1 and ETC2 included? They would be fairly important as well.

Yes, but only because .ktx files can store textured compressed in those
formats. That is: the idea is to be able to load texture files, the
format of the texture stored inside those files depends just on the
limitations of the container. .ktx can store textures in any internal
format supported by OpenGL, .dds is more D3D oriented, yet we can
support a huge degree of it.

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/f3927ffb/attachment.bin>

From rjvbertin at gmail.com  Fri Jan 20 10:51:20 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin)
Date: Fri, 20 Jan 2017 10:51:20 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <30311520.oodxC44c8O@bola> <20170119211538.GE30487@ugly>
	<9069557.ocROtIixcQ@portia.local>
	<1674503.xn2ZNG9tWW@tjmaciei-mobl1>
Message-ID: <1846566.5Us7CF32ds@patux.local>

Thiago Macieira wrote:


> The tools affected are those that can be bootstrapped but weren't (because
> it's not a cross compilation). Since they weren't bootstrapped, they link to
> the Qt libraries being compiled, which results in the linking problem.

Terminology maybe, but I thought the problem was that they were created with 
links to the Qt libraries being compiled, but executed using the Qt libraries at 
the RPATH location that ldd shows, or whatever other version ld.so finds.

Not to kick in open doors but there's another approach: build dedicated versions 
of the host tools needed during the build that only work with the libraries from 
the build directory. You could relink them before installing. But I presume that 
a cross-build will have to build dedicated versions anyway as the installable 
versions built for the target system won't run, so it might actually reduce 
complexity to use dedicated versions for native builds too, no?

> But uic should be suffering from this

Too late to check now :)
Is uic used during the build? If it is it was clearly not "suffering from this"!

R.



From oswald.buddenhagen at qt.io  Fri Jan 20 10:55:38 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Fri, 20 Jan 2017 10:55:38 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <2412448.GjSeErjmQu@portia.local>
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local>
Message-ID: <20170120095538.GJ24383@troll08>

On Thu, Jan 19, 2017 at 10:20:59PM +0100, René J. V. Bertin wrote:
> Let me try to reformulate the question: what options must I pass to
> ../qt-everywhere-opensource-src-5.8.0-rc/configure so that the qtmultimedia 
> component is built without pulseaudio and gstreamer support?
>
check whether qtmultimedia/{config_help.txt,configure.json} exist and
claim support.
to verify whether it's specific to the module, also try
-no-qml-interpreter to see whether it works for qtdeclarative.


From olivier at woboq.com  Fri Jan 20 11:01:25 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Fri, 20 Jan 2017 11:01:25 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <CAO+E9oq0v=H+tT0ROB6wEJn7K_iLiegy2YGHFqZ26Yn8uEC36g@mail.gmail.com>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<30349975.Y0Ycl6y2NR@tjmaciei-mobl1>
	<CAO+E9oq0v=H+tT0ROB6wEJn7K_iLiegy2YGHFqZ26Yn8uEC36g@mail.gmail.com>
Message-ID: <1882153.kjMbbIsSqa@maurice>

On Freitag, 20. Januar 2017 09:59:55 CET Benjamin TERRIER wrote:
> 2017-01-20 3:01 GMT+01:00 Thiago Macieira <thiago.macieira at intel.com>:
> > we also catch the even more dubious code:
> >         char func[] = "deleteLater";
> >         QMetaObject::invokeMethod(&obj, func);

I think we should still support that.

> > 
> > The only case that would break would be for a constant null pointer
> > literal, which in my opinion is acceptable, since it should never happen
> > in real code.

I'd say breaking with 0 or nullptr is an acceptable source compatibility break 
since this makes no sens.


> As an alternative to adding "char *" overload, it seems that replacing
> "std::is_same<const char *,Func>"
> by "std::is_same<char *, Func>" in the "QtPrivate::QEnableIf" part of
> the template solves the issue
> for char * and const char *.

Maybe we need a smarter condition in the enable_if like is_callable or
!std::is_convertible<Func, const char *>

> Also I have checked QTimer and QTimer::singleShot(0, &obj, (char *)0);
> doesn't compile because
> the "wrong" overload is chosen. Removing the const in the std::is_same
> should also fix this.

this overload of QTimer::singleShot is meant to be used with the SLOT macro, 
so that's only a "const char*".  Nobody ever complained about that since Qt 
5.4 when it was added, so i think we could leave it like that.

But if you want to "fix" it there, there is also QMenu::addAction and 
QToolbar::addAction

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org


From laszlo.agocs at qt.io  Fri Jan 20 11:05:50 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Fri, 20 Jan 2017 10:05:50 +0000
Subject: [Development] Texture image loading library
In-Reply-To: <cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>,
	<cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
Message-ID: <AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>


Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D should have some code for it IIRC), but that can be added later.


Cheers,

Laszlo




________________________________
From: giuseppe.dangelo at kdab.com <giuseppe.dangelo at kdab.com> on behalf of Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Sent: Friday, January 20, 2017 10:45 AM
To: Laszlo Agocs; development at qt-project.org
Subject: Re: [Development] Texture image loading library

Il 20/01/2017 09:25, Laszlo Agocs ha scritto:
> This would bring the benefit of potential reuse in the Quick (Image
> element) compressed texture support, once that materializes at some
> point in the future.
>
>
> Are ETC1 and ETC2 included? They would be fairly important as well.

Yes, but only because .ktx files can store textured compressed in those
formats. That is: the idea is to be able to load texture files, the
format of the texture stored inside those files depends just on the
limitations of the container. .ktx can store textures in any internal
format supported by OpenGL, .dds is more D3D oriented, yet we can
support a huge degree of it.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/dca711ac/attachment.html>

From oswald.buddenhagen at qt.io  Fri Jan 20 11:06:34 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Fri, 20 Jan 2017 11:06:34 +0100
Subject: [Development] Status of 5.6
In-Reply-To: <201701200910.45106.marc.mutz@kdab.com>
References: <201701200910.45106.marc.mutz@kdab.com>
Message-ID: <20170120100634.GK24383@troll08>

On Fri, Jan 20, 2017 at 09:10:45AM +0100, Marc Mutz wrote:
> I noted that mere mortals can't stage stuff to 5.6 anymore, and no-one else 
> does, either, at least for qtbase (last was on Jan 10th, when appearently 
> there wasn't a lock-down, yet?).
> 
> There are tons of accepted backports waiting to be staged, some for security-
> critical fixes...
> 
we can do integration rounds (simon actually did one a week or two ago),
but it requires paying extra attention to the correct cherry-picking
format, which quite some changes actually failed to follow.

> What's going on?
> 
we're being lame. it's mostly between me and eddy. you may want to join
in: https://codereview.qt-project.org/177706


From giuseppe.dangelo at kdab.com  Fri Jan 20 11:11:09 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 20 Jan 2017 11:11:09 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
	<AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
Message-ID: <2859414c-6566-3e6e-9ec3-da8c6af154e8@kdab.com>

Il 20/01/2017 11:05, Laszlo Agocs ha scritto:
> Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D
> should have some code for it IIRC), but that can be added later.
> 

Is there anyone using those containers? Last time I checked I had a very
hard time finding specifications for them (I think they were hosted on
some Ericsson website that went offline). Also usually tools that can
compress in ETC1/2 can write in KTX.

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/007be84c/attachment.bin>

From olivier at woboq.com  Fri Jan 20 11:14:12 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Fri, 20 Jan 2017 11:14:12 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
Message-ID: <8487709.0MKfFRgsmG@maurice>

On Dienstag, 17. Januar 2017 11:21:56 CET Grégoire Barbier wrote:
> Le 16/01/2017 à 10:34, Olivier Goffart a écrit :
> > What's the use case for this function? For direct call you better of
> > calling the function directly,  and the equivalent of QueuedConnection
> > can be achieved with QTimer::singleShot.
> 
> Hi.
> 
> AFAIK there is no other way to call a method across threads *and wait
> for it result* than QMetaObject::invokeMethod() with
> Qt::BlockingQueuedConnection and Q_RETURN_ARG (apart, of course, making
> the called method thread-safe).

That's a valid use case. Thank you for bringing that up.

[...]

> Also (I still dream), if there was a way to make invokeMethod()
> automagically choose between a direct call and
> Qt::BlockingQueuedConnection, it would be possible to get rid of this idiom:
> if (QThread::currentThread() == this->thread())
>         foo = func();
>      else
>         QMetaObject::invokeMethod(this, "func",
>                   Qt::BlockingQueuedConnection,
>                   Q_RETURN_ARG(foo));
> 
> Kind of Qt::DirectOrBlockingQueuedConnection.

See the discussion in https://codereview.qt-project.org/83404/ for why this is 
not a good idea.
In summary, BlockingQueuedConnection is dangerous as it can lead to deadlock 
if the other thread is waiting on your thread. In order to use it properly, 
you really need to know, while programming in which thread you are and which 
thread you try to communicate to, and be sure that there is never in your 
program cases where the other thread may be waiting on a QWaitCondition for 
your other thread. So this pattern with QThread::currentThread() == this-
>thread() before a BlockingQueuedConnection is really dangerous.


On the other hand, it would be useful to get the return value of a 
QueuedConnection in a QFuture.


-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org






From laszlo.agocs at qt.io  Fri Jan 20 11:14:37 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Fri, 20 Jan 2017 10:14:37 +0000
Subject: [Development] Texture image loading library
In-Reply-To: <2859414c-6566-3e6e-9ec3-da8c6af154e8@kdab.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
	<AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>,
	<2859414c-6566-3e6e-9ec3-da8c6af154e8@kdab.com>
Message-ID: <AM4PR0201MB1892CDED7C9B15501CC8858A87710@AM4PR0201MB1892.eurprd02.prod.outlook.com>


Hmm right. Could be that it is less relevant today. Android's etc1tool only did PKM but perhaps that is not so interesting anymore with the advent of ETC2.


Cheers,

Laszlo


________________________________
From: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Sent: Friday, January 20, 2017 11:11:09 AM
To: Laszlo Agocs; development at qt-project.org
Subject: Re: [Development] Texture image loading library

Il 20/01/2017 11:05, Laszlo Agocs ha scritto:
> Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D
> should have some code for it IIRC), but that can be added later.
>

Is there anyone using those containers? Last time I checked I had a very
hard time finding specifications for them (I think they were hosted on
some Ericsson website that went offline). Also usually tools that can
compress in ETC1/2 can write in KTX.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/18daec22/attachment.html>

From rjvbertin at gmail.com  Fri Jan 20 13:06:09 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 20 Jan 2017 13:06:09 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local>
	<3122424.xRJrAOf771@tjmaciei-mobl1>
	<3300735.MaP4xKZtqv@portia.local>
	<1908416.S2PJJNq741@tjmaciei-mobl1>
Message-ID: <1594370.HoQ5R8knDP@portia.local>

Thiago Macieira wrote:

> Don't assume. The question stands.

QED:

%> rm -rf /path/to/build/qtmultimedia
%> tar -xf /path/to/qt-everywhere-opensource-src-5.8.0-rc.tar.xz qt-everywhere-
opensource-src-5.8.0-rc/qtmultimedia
%> (cd /path/to/build ; /path/to/qt-everywhere-opensource-src-5.8.0-rc/configure 
-redo -recheck-all ...)
%> (cd /path/to/build ; make)
%> otool -L /path/to/build/qtmultimedia/lib/libqgsttools_p.dylib 
/path/to/build/qtmultimedia/lib/libqgsttools_p.dylib:
   libqgsttools_p.1.dylib
   /opt/local/libexec/qt5/Library/Frameworks/QtMultimediaWidgets.framework/Versions/5/QtMultimediaWidgets 
   /opt/local/libexec/qt5/Library/Frameworks/QtMultimedia.framework/Versions/5/QtMultimedia
   /opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/Versions/5/QtNetwork 
   /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore
   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
   /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
   /opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Versions/5/QtGui
   /opt/local/libexec/qt5/Library/Frameworks/QtWidgets.framework/Versions/5/QtWidgets
   /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
   /System/Library/Frameworks/AGL.framework/Versions/A/AGL 
   /opt/local/lib/libgstaudio-1.0.0.dylib
   /opt/local/lib/libgstvideo-1.0.0.dylib
   /opt/local/lib/libgstpbutils-1.0.0.dylib
   /opt/local/lib/libgstapp-1.0.0.dylib
   /opt/local/lib/libgstbase-1.0.0.dylib
   /opt/local/lib/libgstreamer-1.0.0.dylib
   /opt/local/lib/libgobject-2.0.0.dylib
   /opt/local/lib/libpulse-mainloop-glib.0.dylib 
   /opt/local/lib/libpulse.0.dylib
   /opt/local/lib/libglib-2.0.0.dylib
   /opt/local/lib/libintl.8.dylib
   /usr/lib/libc++.1.dylib
   /usr/lib/libSystem.B.dylib
   
%> otool -L 
/path/to/build/qtmultimedia/plugins/mediaservice/libqtmedia_audioengine.dylib 
/path/to/build/qtmultimedia/plugins/mediaservice/libqtmedia_audioengine.dylib:
   libqtmedia_audioengine.dylib
   /opt/local/libexec/qt5/Library/Frameworks/QtMultimedia.framework/Versions/5/QtMultimedia
   /opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/Versions/5/QtNetwork
   /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore 
   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
   /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
   /opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Versions/5/QtGui 
   /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
   /System/Library/Frameworks/AGL.framework/Versions/A/AGL 
   /opt/local/lib/libpulse-mainloop-glib.0.dylib 
   /opt/local/lib/libpulse.0.dylib 
   /opt/local/lib/libglib-2.0.0.dylib 
   /opt/local/lib/libintl.8.dylib 
   /usr/lib/libc++.1.dylib 
   /usr/lib/libSystem.B.dylib 




From marc.mutz at kdab.com  Fri Jan 20 15:32:01 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 20 Jan 2017 15:32:01 +0100
Subject: [Development] Status of 5.6
In-Reply-To: <20170120100634.GK24383@troll08>
References: <201701200910.45106.marc.mutz@kdab.com>
	<20170120100634.GK24383@troll08>
Message-ID: <201701201532.01120.marc.mutz@kdab.com>

On Friday 20 January 2017 11:06:34 Oswald Buddenhagen wrote:
> On Fri, Jan 20, 2017 at 09:10:45AM +0100, Marc Mutz wrote:
> > I noted that mere mortals can't stage stuff to 5.6 anymore, and no-one
> > else does, either, at least for qtbase (last was on Jan 10th, when
> > appearently there wasn't a lock-down, yet?).
> > 
> > There are tons of accepted backports waiting to be staged, some for
> > security- critical fixes...
> 
> we can do integration rounds (simon actually did one a week or two ago),
> but it requires paying extra attention to the correct cherry-picking
> format, which quite some changes actually failed to follow.

Please do them, then. There haven't been any since Jan 4th in QtBase, it 
seems.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From sean.harmer at kdab.com  Fri Jan 20 15:55:00 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Fri, 20 Jan 2017 14:55 +0000
Subject: [Development] Coding convention for private includes
Message-ID: <4219590.ZTIWWNod3B@titan>

Hi,

Just a query about the coding convention around inclusion of private headers 
as specified at:

https://wiki.qt.io/Coding_Conventions#Including_headers

It states:

If you need to include private headers, be careful. Use the following syntax, 
irrespective of which module or directory whatever_p.h is in.

 #include <private/whatever_p.h>

The issue is that this could lead to collisions. Is it OK to use:

 #include <QtModule/private/whatever_p.h>

?

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From devel at g76r.eu  Fri Jan 20 17:34:50 2017
From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=)
Date: Fri, 20 Jan 2017 17:34:50 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <8487709.0MKfFRgsmG@maurice>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
	<8487709.0MKfFRgsmG@maurice>
Message-ID: <bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>

Le 20/01/2017 à 11:14, Olivier Goffart a écrit :
> On Dienstag, 17. Januar 2017 11:21:56 CET Grégoire Barbier wrote:
>> Le 16/01/2017 à 10:34, Olivier Goffart a écrit :
>> > What's the use case for this function? For direct call you better of
>> > calling the function directly,  and the equivalent of QueuedConnection
>> > can be achieved with QTimer::singleShot.
>>
>> Hi.
>>
>> AFAIK there is no other way to call a method across threads *and wait
>> for it result* than QMetaObject::invokeMethod() with
>> Qt::BlockingQueuedConnection and Q_RETURN_ARG (apart, of course, making
>> the called method thread-safe).
>
> That's a valid use case. Thank you for bringing that up.
>
> [...]
>
>> Also (I still dream), if there was a way to make invokeMethod()
>> automagically choose between a direct call and
>> Qt::BlockingQueuedConnection, it would be possible to get rid of this idiom:
>> if (QThread::currentThread() == this->thread())
>>         foo = func();
>>      else
>>         QMetaObject::invokeMethod(this, "func",
>>                   Qt::BlockingQueuedConnection,
>>                   Q_RETURN_ARG(foo));
>>
>> Kind of Qt::DirectOrBlockingQueuedConnection.
>
> See the discussion in https://codereview.qt-project.org/83404/ for why this is
> not a good idea.
> In summary, BlockingQueuedConnection is dangerous as it can lead to deadlock
> if the other thread is waiting on your thread. In order to use it properly,
> you really need to know, while programming in which thread you are and which
> thread you try to communicate to, and be sure that there is never in your
> program cases where the other thread may be waiting on a QWaitCondition for
> your other thread. So this pattern with QThread::currentThread() == this-
>>thread() before a BlockingQueuedConnection is really dangerous.

Thank you it's very interesting.

But, I use this pattern mainly to protect data-access methods (such as a 
getter on an implicitly shared object) than can be either called from 
the owner thread or another one.
I'll keep using it, without fear, unless the called object's owner 
thread was likelly to change.

I respect the fact that you rejected Qt::BlockingAutoConnection in 2014 
because of its potential danger, but I'm not sure that it's better to 
let people use the "QThread::currentThread() == this" pattern without 
being warned rather than implementing Qt::BlockingAutoConnection, with a 
detailed warning in the doc.

Moreover, I don't understand whi BlockingAutoConnection would be more 
dangerous (if it were to be added) than BlockingQueuedConnection is 
currently already dangerous.

With your own words from 2014:

"""
I would not even try to solve this race with moveToThead, as a mention, 
i think we just need to document that one must not call moveToThread 
when Blocking connecitona re involved.
"""

Maybe it would be interesting to set this comment in enum 
Qt::ConnectionType doc, just right to Qt::BlockingQueuedConnection (or a 
would-be Qt::BlockingAutoConnection) and not only in the "Signals and 
Slots Across Threads" paragraph, to make everything safer with noobs 
(like me) that do not read the whole docs but only spam the F1 key from 
with Qt Creator.

> On the other hand, it would be useful to get the return value of a
> QueuedConnection in a QFuture.

Well.
In french there is a very funny expression which means more or less "to 
use a hammer to kill a fly". ;-)
Let's take an example, I clearly don't think I would like to use a 
QFuture, make it thread-safe with a QMutex and the like in the following 
code (even though you've just make me learn that 
Qt::BlockingQueuedConnection may be dangerous, in the following code I 
know it's not, because A object never changes thread):

class B;
class A : public QObject {
   Q_OBJECT
   QLinkedList<B> _queue;
public:
   /** This method is thread-safe. */
   B pop() const {
     B value;
     if (QThread::currentThread() == this->thread())
       value = doPop();
     else
       QMetaObject::invokeMethod(this, "doFoo",
              Qt::BlockingQueuedConnection,
              Q_RETURN_ARG(B, value));
     return value;
   }
private:
   /** This method is not thread-safe. */
   Q_INVOKABLE B doPop() {
     return _queue.takeFirst();
   }
};

In the other hand, I would by far prefer to write this code, both the 
lambda and Qt::AutoBlockingConnection make the code shorter and easier 
to understand (and I don't expect that using QFuture would lead to the 
same result):

class B;
class A : public QObject {
   Q_OBJECT
   QLinkedList<B> _queue;
public:
   /** This method is thread-safe. */
   B pop() const {
      B value;
      QMetaObject::invokeMethod(this, [&value]() {
              value = _queue.takeFirst();
          }, Qt::AutoBlockingConnection);
      }
   }
};

Of course in this simple case, it's obvious that make the method 
thread-safe (e.g. with a QMutex/QMutexLocker) is easier and lighter than 
a queued call. But it's not always so obvious.

-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49


From thiago.macieira at intel.com  Fri Jan 20 18:09:51 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 20 Jan 2017 09:09:51 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <1846566.5Us7CF32ds@patux.local>
References: <30311520.oodxC44c8O@bola> <1674503.xn2ZNG9tWW@tjmaciei-mobl1>
	<1846566.5Us7CF32ds@patux.local>
Message-ID: <3931500.fVEvxk9aqZ@tjmaciei-mobl1>

On sexta-feira, 20 de janeiro de 2017 10:51:20 PST René J.  V. Bertin wrote:
> > But uic should be suffering from this
> 
> Too late to check now :)
> Is uic used during the build? If it is it was clearly not "suffering from
> this"!

It is used in QtWidgets and possibly other modules. It may have suffered from 
the problem of loading the wrong library at runtime, but didn't crash because 
the new uic didn't use any symbols that are new in 5.8.

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



From abbapoh at gmail.com  Fri Jan 20 18:26:51 2017
From: abbapoh at gmail.com (abbapoh at gmail.com)
Date: Fri, 20 Jan 2017 20:26:51 +0300
Subject: [Development] Texture image loading library
In-Reply-To: <AM4PR0201MB1892CDED7C9B15501CC8858A87710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
	<AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<2859414c-6566-3e6e-9ec3-da8c6af154e8@kdab.com>
	<AM4PR0201MB1892CDED7C9B15501CC8858A87710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
Message-ID: <F5B492A0-8BB2-49A4-9F54-88BB39AF44ED@gmail.com>

Hm, I already started a project that supports that functionality as a replacement to the current image formats:
https://github.com/ABBAPOH/imageformats-ng
http://abbapoh.github.io/docs/imageformats-ng/

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

> 20 янв. 2017 г., в 13:14, Laszlo Agocs <laszlo.agocs at qt.io> написал(а):
> 
> 
> Hmm right. Could be that it is less relevant today. Android's etc1tool only did PKM but perhaps that is not so interesting anymore with the advent of ETC2.
> 
> 
> Cheers,
> Laszlo
> 
> 
> From: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
> Sent: Friday, January 20, 2017 11:11:09 AM
> To: Laszlo Agocs; development at qt-project.org
> Subject: Re: [Development] Texture image loading library
>  
> Il 20/01/2017 11:05, Laszlo Agocs ha scritto:
> > Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D
> > should have some code for it IIRC), but that can be added later.
> > 
> 
> Is there anyone using those containers? Last time I checked I had a very
> hard time finding specifications for them (I think they were hosted on
> some Ericsson website that went offline). Also usually tools that can
> compress in ETC1/2 can write in KTX.
> 
> Cheers,
> -- 
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/6686f7ff/attachment.html>

From rjvbertin at gmail.com  Fri Jan 20 18:27:31 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 20 Jan 2017 18:27:31 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <30311520.oodxC44c8O@bola> <1674503.xn2ZNG9tWW@tjmaciei-mobl1>
	<1846566.5Us7CF32ds@patux.local>
	<3931500.fVEvxk9aqZ@tjmaciei-mobl1>
Message-ID: <2391590.JZiKGoIaMY@portia.local>

Thiago Macieira wrote:

> It is used in QtWidgets and possibly other modules. It may have suffered from
> the problem of loading the wrong library at runtime, but didn't crash because
> the new uic didn't use any symbols that are new in 5.8.

That'd be an explanation, but is that what the "-version Qt_5" error is about?

R.



From annulen at yandex.ru  Fri Jan 20 18:35:49 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 20 Jan 2017 20:35:49 +0300
Subject: [Development] Texture image loading library
In-Reply-To: <20170119212217.GF30487@ugly>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly>
Message-ID: <7419371484933749@web10h.yandex.ru>



20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
>>  Nonetheless, since such loaders would be useful in more than one place
>>  (qtbase, qtdeclarative, qt3d) I think that the best place for them would
>>  be a new private library in qtimageformats.
>
> you can't put it there if qtbase is to use it.
>
> the central "regular" image loaders are in qtgui, and the "elementary"
> (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> seems quite plausible to put the texture loaders there as well.

FWIW not everyone is happy by fact that QtGui is bloated with OpenGL code
and pulls in OpenGL libraries into application adress space with itself.

> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From abbapoh at gmail.com  Fri Jan 20 19:08:12 2017
From: abbapoh at gmail.com (abbapoh at gmail.com)
Date: Fri, 20 Jan 2017 21:08:12 +0300
Subject: [Development] Texture image loading library
In-Reply-To: <F5B492A0-8BB2-49A4-9F54-88BB39AF44ED@gmail.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <15354361.lzZear9qlH@tjmaciei-mobl1>
	<AM4PR0201MB18920D485A95BB4007F2427287710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<cea26da8-5901-e6bb-ca05-fd3fbbd40f77@kdab.com>
	<AM4PR0201MB1892C555B692452B3FC0586387710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<2859414c-6566-3e6e-9ec3-da8c6af154e8@kdab.com>
	<AM4PR0201MB1892CDED7C9B15501CC8858A87710@AM4PR0201MB1892.eurprd02.prod.outlook.com>
	<F5B492A0-8BB2-49A4-9F54-88BB39AF44ED@gmail.com>
Message-ID: <82704CB9-D9B3-4BC6-A58E-341FAE978643@gmail.com>

Sorry, wrong quotation, I meant to quote original letter

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

> 20 янв. 2017 г., в 20:26, abbapoh at gmail.com написал(а):
> 
> Hm, I already started a project that supports that functionality as a replacement to the current image formats:
> https://github.com/ABBAPOH/imageformats-ng
> http://abbapoh.github.io/docs/imageformats-ng/
> 
> Иван Комиссаров
> 
>> 20 янв. 2017 г., в 13:14, Laszlo Agocs <laszlo.agocs at qt.io> написал(а):
>> 
>> 
>> Hmm right. Could be that it is less relevant today. Android's etc1tool only did PKM but perhaps that is not so interesting anymore with the advent of ETC2.
>> 
>> 
>> Cheers,
>> Laszlo
>> 
>> 
>> From: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
>> Sent: Friday, January 20, 2017 11:11:09 AM
>> To: Laszlo Agocs; development at qt-project.org
>> Subject: Re: [Development] Texture image loading library
>>  
>> Il 20/01/2017 11:05, Laszlo Agocs ha scritto:
>> > Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D
>> > should have some code for it IIRC), but that can be added later.
>> > 
>> 
>> Is there anyone using those containers? Last time I checked I had a very
>> hard time finding specifications for them (I think they were hosted on
>> some Ericsson website that went offline). Also usually tools that can
>> compress in ETC1/2 can write in KTX.
>> 
>> Cheers,
>> -- 
>> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
>> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
>> KDAB - Qt, C++ and OpenGL Experts
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170120/bdcb1670/attachment.html>

From rjvbertin at gmail.com  Fri Jan 20 21:14:00 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 20 Jan 2017 21:14 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local> <20170120095538.GJ24383@troll08>
Message-ID: <2236020.5LaOjxUbUR@portia.local>

Oswald Buddenhagen wrote:


> check whether qtmultimedia/{config_help.txt,configure.json} exist and

They do.

> claim support.

I think I can do better: apparently I have found the culprit. In the Features 
section of qtmultimedia/src/multimedia/configure.json:

        "pulseaudio": {
            "label": "PulseAudio",
            "autoDetect": "config.unix",
            "condition": "libs.pulseaudio",
            "output": [ "feature", "privateFeature" ]
        },

Removing the "autoDetect" line solves the issue. As far as I can tell this 
doesn't interfere with auto-detection on Linux (tested with `configure -redo -
recheck-all` WITHOUT any -pulseaudio option).

> to verify whether it's specific to the module, also try
> -no-qml-interpreter to see whether it works for qtdeclarative.

Works.

R



From gunnar.roth at gmx.de  Fri Jan 20 23:51:32 2017
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Fri, 20 Jan 2017 23:51:32 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<7885071.lxV1XBcrtG@maurice>
	<2c4b9bc6-89fd-3e09-02d4-2a70dcfb2f05@g76r.eu>
	<8487709.0MKfFRgsmG@maurice>
	<bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
Message-ID: <D5E88CF6-6C7E-4340-B8D5-339F000CEC9A@gmx.de>


> 
> I respect the fact that you rejected Qt::BlockingAutoConnection in 2014 because of its potential danger, but I'm not sure that it's better to let people use the "QThread::currentThread() == this" pattern without being warned rather than implementing Qt::BlockingAutoConnection, with a detailed warning in the doc.
> 
> Moreover, I don't understand whi BlockingAutoConnection would be more dangerous (if it were to be added) than BlockingQueuedConnection is currently already dangerous.

I also don’t understand why adding  "QThread::currentThread() == this“ should make the method more dangerous, actually it makes it a bit more safe for the same thread case, the potential deadlock problem remains with or without.

Regards,
Gunnar Roth 

From thiago.macieira at intel.com  Sat Jan 21 00:06:53 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 20 Jan 2017 15:06:53 -0800
Subject: [Development] Coding convention for private includes
In-Reply-To: <4219590.ZTIWWNod3B@titan>
References: <4219590.ZTIWWNod3B@titan>
Message-ID: <2301797.7IKVIsLUIV@tjmaciei-mobl1>

On sexta-feira, 20 de janeiro de 2017 14:55:00 PST Sean Harmer wrote:
> Hi,
> 
> Just a query about the coding convention around inclusion of private headers
> as specified at:
> 
> https://wiki.qt.io/Coding_Conventions#Including_headers
> 
> It states:
> 
> If you need to include private headers, be careful. Use the following
> syntax, irrespective of which module or directory whatever_p.h is in.
> 
>  #include <private/whatever_p.h>
> 
> The issue is that this could lead to collisions. Is it OK to use:
> 
>  #include <QtModule/private/whatever_p.h>
> 
> ?

You need to be careful when including a private header from another private 
header. But if it's from a .cpp, you can use even relative paths.

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



From thiago.macieira at intel.com  Sat Jan 21 00:20:53 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 20 Jan 2017 15:20:53 -0800
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<8487709.0MKfFRgsmG@maurice>
	<bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
Message-ID: <2932012.vQArHYP3Zi@tjmaciei-mobl1>

On sexta-feira, 20 de janeiro de 2017 17:34:50 PST Grégoire Barbier wrote:
> > See the discussion in https://codereview.qt-project.org/83404/ for why
> > this is not a good idea.
> > In summary, BlockingQueuedConnection is dangerous as it can lead to
> > deadlock if the other thread is waiting on your thread. In order to use
> > it properly, you really need to know, while programming in which thread
> > you are and which thread you try to communicate to, and be sure that
> > there is never in your program cases where the other thread may be
> > waiting on a QWaitCondition for your other thread. So this pattern with
> > QThread::currentThread() == this-> 
> >>thread() before a BlockingQueuedConnection is really dangerous.

> I respect the fact that you rejected Qt::BlockingAutoConnection in 2014
> because of its potential danger, but I'm not sure that it's better to
> let people use the "QThread::currentThread() == this" pattern without
> being warned rather than implementing Qt::BlockingAutoConnection, with a
> detailed warning in the doc.

It's a shift of responsibility. If we had the BlockingAutoConnection (or 
SynchronousConnection, which is what I wanted to call it during Qt 4.5 when I 
first proposed it), the deadlock would be Qt's fault. Since it's you doing 
that, the deadlock becomes your fault and you're the one who needs to fix it.

> Moreover, I don't understand whi BlockingAutoConnection would be more
> dangerous (if it were to be added) than BlockingQueuedConnection is
> currently already dangerous.

Think about this: QueuedConnection and BlockingQueuedConnection chase the 
target object across moveToThreads. That is, if thread A is doing 
invokeMethod() while thread B does obj->moveToThread(C), then the invocation 
chases obj to thread C. That's a good thing.

But what happens if it got moved to thread A? Since thread A is blocked on a 
semaphore wait, it can't handle the incoming metacall event. That's a 
deadlock.

What's more, we can't solve it: even if we could detect the deadlock formation 
before it happens (and I'm not sure we can), we'd need to pick the metacall 
event out of the event queue, which means it could jump the queue and things 
would execute in the wrong order. So, no, it's impossible to implement 
BlockingAutoConnection so long as the object can be moved back to the calling 
thread.

> With your own words from 2014:
> 
> """
> I would not even try to solve this race with moveToThead, as a mention,
> i think we just need to document that one must not call moveToThread
> when Blocking connecitona re involved.
> """
> 
> Maybe it would be interesting to set this comment in enum
> Qt::ConnectionType doc, just right to Qt::BlockingQueuedConnection (or a
> would-be Qt::BlockingAutoConnection) and not only in the "Signals and
> Slots Across Threads" paragraph, to make everything safer with noobs
> (like me) that do not read the whole docs but only spam the F1 key from
> with Qt Creator.

Adding the warning to BlockingQueuedConnection is a good idea.

> > On the other hand, it would be useful to get the return value of a
> > QueuedConnection in a QFuture.

That's no different than a QueuedConnection with a posted event back with the 
result. In fact, we have a very good implementation for "post event back with 
result": we call it a "signal-slot connection".

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



From thiago.macieira at intel.com  Sat Jan 21 00:22:05 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 20 Jan 2017 15:22:05 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <2391590.JZiKGoIaMY@portia.local>
References: <30311520.oodxC44c8O@bola> <3931500.fVEvxk9aqZ@tjmaciei-mobl1>
	<2391590.JZiKGoIaMY@portia.local>
Message-ID: <1675354.YPmOQYsqtY@tjmaciei-mobl1>

On sexta-feira, 20 de janeiro de 2017 18:27:31 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It is used in QtWidgets and possibly other modules. It may have suffered
> > from the problem of loading the wrong library at runtime, but didn't
> > crash because the new uic didn't use any symbols that are new in 5.8.
> 
> That'd be an explanation, but is that what the "-version Qt_5" error is
> about?

A red herring. You've focused on the wrong part of the information.

The linker told you that it can't find a symbol with a given ELF version. 
That's because the symbol isn't present at all, with any ELF version.

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



From rjvbertin at gmail.com  Sat Jan 21 09:50:50 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Sat, 21 Jan 2017 09:50:50 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <30311520.oodxC44c8O@bola> <3931500.fVEvxk9aqZ@tjmaciei-mobl1>
	<2391590.JZiKGoIaMY@portia.local>
	<1675354.YPmOQYsqtY@tjmaciei-mobl1>
Message-ID: <99031130.JgsEfcrxlB@patux.local>

Thiago Macieira wrote:


> A red herring. You've focused on the wrong part of the information.
> 
> The linker told you that it can't find a symbol with a given ELF version.
> That's because the symbol isn't present at all, with any ELF version.

OK, thanks, I didn't catch that bit from what Google told me. So I would not 
have gotten the same error if the symbol were present with another ELF version?

R.



From oswald.buddenhagen at qt.io  Sat Jan 21 11:31:34 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Sat, 21 Jan 2017 11:31:34 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
In-Reply-To: <2236020.5LaOjxUbUR@portia.local>
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local> <20170120095538.GJ24383@troll08>
	<2236020.5LaOjxUbUR@portia.local>
Message-ID: <20170121103134.GA21792@ugly>

On Fri, Jan 20, 2017 at 09:14:00PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> 
> 
> > check whether qtmultimedia/{config_help.txt,configure.json} exist and
> 
> They do.
> 
> > claim support.
> 
> I think I can do better: apparently I have found the culprit. In the Features 
> section of qtmultimedia/src/multimedia/configure.json:
> 
>         "pulseaudio": {
>             "label": "PulseAudio",
>             "autoDetect": "config.unix",
>             "condition": "libs.pulseaudio",
>             "output": [ "feature", "privateFeature" ]
>         },
> 
> Removing the "autoDetect" line solves the issue.
>
that makes just no sense whatsoever. the command line options are
declared in a separate section near the top of the file, and there is no
feedback to them from the features. if the effect you're describing is
genuine, there is something seriously screwed up in the qmake internals;
you may get useful reports from valgrind or asan.

> As far as I can tell this doesn't interfere with auto-detection on
> Linux (tested with `configure -redo - recheck-all` WITHOUT any
> -pulseaudio option).
> 
correct.

> > to verify whether it's specific to the module, also try
> > -no-qml-interpreter to see whether it works for qtdeclarative.
> 
> Works.
> 
ok, so the system as such is functional.


From sean.harmer at kdab.com  Sat Jan 21 11:51:11 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 21 Jan 2017 10:51:11 +0000
Subject: [Development] Texture image loading library
In-Reply-To: <7419371484933749@web10h.yandex.ru>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <7419371484933749@web10h.yandex.ru>
Message-ID: <3257741.bPMclx67ll@titan>

On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> >>  Nonetheless, since such loaders would be useful in more than one place
> >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them would
> >>  be a new private library in qtimageformats.
> > 
> > you can't put it there if qtbase is to use it.
> > 
> > the central "regular" image loaders are in qtgui, and the "elementary"
> > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > seems quite plausible to put the texture loaders there as well.
> 
> FWIW not everyone is happy by fact that QtGui is bloated with OpenGL code
> and pulls in OpenGL libraries into application adress space with itself.

Well that decision was made prior to Qt 5.0 being released. This doesn't 
change that or add any OpenGL specific code. It's just about parsing a file 
format and finding somewhere common to do that so that Qt Quick and Qt 3D don't 
have to duplicate code.

Cheers,

Sean

> 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Regards,
> Konstantin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From steveire at gmail.com  Sat Jan 21 12:30:40 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 21 Jan 2017 11:30:40 +0000
Subject: [Development] QFlags Zero handling
Message-ID: <o5vgor$jgi$1@blaine.gmane.org>

Hi,

Does anyone know why QFlags has a constructor taking a Zero pointer? My 
guess is that it's a hack to make initializing like

 Qt::WindowFlags = 0

work? The problem encountered is that porting tools convert that to 

 Qt::WindowFlags = nullptr

which is undesirable.

 https://mail.kde.org/pipermail/kde-frameworks-devel/2017-January/042091.html

Is there a better solution to that with modern c++?

Thanks,

Steve.



PS:

I mentioned there that Q_NO_TYPESAFE_FLAGS is broken. Attempting to compile

 #define Q_NO_TYPESAFE_FLAGS
 #include <QObject>

does not work as of Qt 5.5. It gives a flood like this:

qnamespace.h: In function ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::Orientations)’:
qnamespace.h:1689:31: error: redefinition of ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::Orientations)’
qnamespace.h:1687:31: note: ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::Alignment)’ previously defined here
qnamespace.h: In function ‘constexpr const char* 
Qt::qt_getEnumName(Qt::Orientations)’:
qnamespace.h:1689:137: error: redefinition of ‘constexpr const char* 
Qt::qt_getEnumName(Qt::Orientations)’
qnamespace.h:1687:134: note: ‘constexpr const char* 
Qt::qt_getEnumName(Qt::Alignment)’ previously defined here
qnamespace.h: In function ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::DropActions)’:
qnamespace.h:1690:31: error: redefinition of ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::DropActions)’
qnamespace.h:1687:31: note: ‘const QMetaObject* 
Qt::qt_getEnumMetaObject(Qt::Alignment)’ previously defined here
qnamespace.h: In function ‘constexpr const char* 
Qt::qt_getEnumName(Qt::DropActions)’:

The define could be removed from qflags.h. Perhaps something could be 
changed in qnamespace.h to allow the code to compile instead (and make the 
enum meta objects not available), but it doesn't seem worth it.







From devel at g76r.eu  Sat Jan 21 13:35:31 2017
From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=)
Date: Sat, 21 Jan 2017 13:35:31 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <2932012.vQArHYP3Zi@tjmaciei-mobl1>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<8487709.0MKfFRgsmG@maurice>
	<bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
	<2932012.vQArHYP3Zi@tjmaciei-mobl1>
Message-ID: <f966c0b5-f336-614d-dc19-1ce46b0710af@g76r.eu>

Le 21/01/2017 à 00:20, Thiago Macieira a écrit :
> It's a shift of responsibility. If we had the BlockingAutoConnection (or
> SynchronousConnection, which is what I wanted to call it during Qt 4.5 when I
> first proposed it), the deadlock would be Qt's fault. Since it's you doing
> that, the deadlock becomes your fault and you're the one who needs to fix it.

Sorry I didn't realized until reading this that the deadlock was in the 
if itself, it's stupid. So of course I agree to not shift the 
responsibilities and will keep writing my own ifs (where they are safe).

Anyway the other ideas in the thread are still interesting IMO.
Thanks.

-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49


From apoenitz at t-online.de  Sat Jan 21 13:51:15 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Sat, 21 Jan 2017 13:51:15 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <3257741.bPMclx67ll@titan>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<20170119212217.GF30487@ugly> <7419371484933749@web10h.yandex.ru>
	<3257741.bPMclx67ll@titan>
Message-ID: <20170121125115.GA5093@klara.mpi.htwm.de>

On Sat, Jan 21, 2017 at 10:51:11AM +0000, Sean Harmer wrote:
> On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> > 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> > > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> > >>  Nonetheless, since such loaders would be useful in more than one place
> > >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them would
> > >>  be a new private library in qtimageformats.
> > > 
> > > you can't put it there if qtbase is to use it.
> > > 
> > > the central "regular" image loaders are in qtgui, and the "elementary"
> > > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > > seems quite plausible to put the texture loaders there as well.
> > 
> > FWIW not everyone is happy by fact that QtGui is bloated with OpenGL code
> > and pulls in OpenGL libraries into application adress space with itself.
> 
> Well that decision was made prior to Qt 5.0 being released.

I think it's about time to stop using the existence of decisions that were
made around the 5.0 release as part of a technical discussion.

2012 was a very special year for Qt development, in a very special environment,
leading to very special decisions, some of which already at that time were made
knowing that they are only acceptable in this context.

Yes, there might still be real consequences for Qt development today, e.g.
due to the independently existing compatibility promises, which, might
make it impossible to disentangle Qt Gui and OpenGL, leading to the same
conclusion. But then *this* argument should be used.

Andre'


From sean.harmer at kdab.com  Sat Jan 21 14:25:41 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 21 Jan 2017 13:25:41 +0000
Subject: [Development] Texture image loading library
In-Reply-To: <20170121125115.GA5093@klara.mpi.htwm.de>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<3257741.bPMclx67ll@titan>
	<20170121125115.GA5093@klara.mpi.htwm.de>
Message-ID: <59421643.6II7UyjWLo@titan>

On Saturday 21 January 2017 13:51:15 André Pönitz wrote:
> On Sat, Jan 21, 2017 at 10:51:11AM +0000, Sean Harmer wrote:
> > On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> > > 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> > > > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> > > >>  Nonetheless, since such loaders would be useful in more than one
> > > >>  place
> > > >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them
> > > >>  would
> > > >>  be a new private library in qtimageformats.
> > > > 
> > > > you can't put it there if qtbase is to use it.
> > > > 
> > > > the central "regular" image loaders are in qtgui, and the "elementary"
> > > > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > > > seems quite plausible to put the texture loaders there as well.
> > > 
> > > FWIW not everyone is happy by fact that QtGui is bloated with OpenGL
> > > code
> > > and pulls in OpenGL libraries into application adress space with itself.
> > 
> > Well that decision was made prior to Qt 5.0 being released.
> 
> I think it's about time to stop using the existence of decisions that were
> made around the 5.0 release as part of a technical discussion.

I'm not. I'm pointing out that this technical decision has nothing to do with 
the one to put OpenGL dependent related features in QtGui.

> 2012 was a very special year for Qt development, in a very special
> environment, leading to very special decisions, some of which already at
> that time were made knowing that they are only acceptable in this context.

Well, some of us don't have visibility of what decisions were made, the 
reasoning behind them and what issues were identified, as that took place 
behind closed doors.

> Yes, there might still be real consequences for Qt development today, e.g.
> due to the independently existing compatibility promises, which, might
> make it impossible to disentangle Qt Gui and OpenGL, leading to the same
> conclusion. But then *this* argument should be used.

For the record I have no problem with removing the OpenGL dependency from 
QtGui in the future. It's possible now to compile with it stripped out but of 
course that's an all or nothing approach. I don't see how we could rectify 
this in the Qt5 life time. Anyway, that's not what this thread is about. It's 
about being able to parse texture files into CPU addressable memory. From there 
it can be used by OpenGL, Direct3D, Vulkan, Metal, $OTHER_API.

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From abbapoh at gmail.com  Sat Jan 21 15:02:57 2017
From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=)
Date: Sat, 21 Jan 2017 17:02:57 +0300
Subject: [Development] Texture image loading library
In-Reply-To: <59421643.6II7UyjWLo@titan>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<3257741.bPMclx67ll@titan> <20170121125115.GA5093@klara.mpi.htwm.de>
	<59421643.6II7UyjWLo@titan>
Message-ID: <ADC09EA5-913F-49D4-AA9C-619759BC0A0B@gmail.com>


> 21 янв. 2017 г., в 16:25, Sean Harmer <sean.harmer at kdab.com> написал(а):
> 
>  It's 
> about being able to parse texture files into CPU addressable memory. From there 
> it can be used by OpenGL, Direct3D, Vulkan, Metal, $OTHER_API.
> 

Do I understand correctly that all is needed is to scan header of the texture, get some info from it and than load whole texture to the byte array?
It may be reasonable to create separate libraries that handle specific textures (dds, etc1, …).
For now, I see some duplication of the code - there are similar structures in qt3d/src/threed/textures/qgltextureutils.cpp and qtimageformats/src/plugins/imageformats/dds/ddsheader.h, for example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170121/61a4d898/attachment.html>

From rjvbertin at gmail.com  Sat Jan 21 16:47:52 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Sat, 21 Jan 2017 16:47:52 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local> <20170120095538.GJ24383@troll08>
	<2236020.5LaOjxUbUR@portia.local> <20170121103134.GA21792@ugly>
Message-ID: <1623549.xEuoOOPHLG@patux.local>

Oswald Buddenhagen wrote:


>>
> that makes just no sense whatsoever. the command line options are
> declared in a separate section near the top of the file, and there is no

That's what I had been thinking all the time too. It's only when you draw my 
attention to config_help.txt and saw the "unix only" remark that I had the idea 
to scout configure.json for something that could limit the pulseaudio option to 
unix. Edit: I hadn't actually checked supprt for -[no-]gstreamer before; it 
turned out this option *does* exist on Mac, so I knew to search for a difference 
in the handling of pulseaudio and gstreamer.

There is another reason why this shouldn't make sense: config.unix should be true 
on Mac.

> feedback to them from the features. if the effect you're describing is
> genuine, there is something seriously screwed up in the qmake internals;
> you may get useful reports from valgrind or asan.

I can try valgrind, but finding something useful among the big load of output 
isn't going to be trivial.
It should be a lot more straightforward for you to check if you can reproduce 
the effect. Could this be a side-effect of some kind of interaction with other 
things in the configure.json file?


>> > to verify whether it's specific to the module, also try
>> > -no-qml-interpreter to see whether it works for qtdeclarative.
>> 
>> Works.
>> 
> ok, so the system as such is functional.

Yes, it would appear so.
I should check to see what happens when I introduce the line I removed in this 
option, to see if that has any effect.

R.



From olivier at woboq.com  Sat Jan 21 17:10:04 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Sat, 21 Jan 2017 17:10:04 +0100
Subject: [Development] QFlags Zero handling
In-Reply-To: <o5vgor$jgi$1@blaine.gmane.org>
References: <o5vgor$jgi$1@blaine.gmane.org>
Message-ID: <2667408.dsvGrLJ3s6@maurice>

On Samstag, 21. Januar 2017 11:30:40 CET Stephen Kelly wrote:
> Hi,
> 
> Does anyone know why QFlags has a constructor taking a Zero pointer? My
> guess is that it's a hack to make initializing like
> 
>  Qt::WindowFlags = 0
> 
> work?

Correct.
We want to be able to initialize it with the literal 0, but not with any int 
or unrelated enum value:

 Qt::WindowFlags foo = 0;  // should work
 Qt::WindowFlags bar = 42;  // should NOT work
 Qt::WindowFlags bar = Qt::DownArrow;  // MUST NOT work (unrelated enum)

So the trick is to allow the initialization with a pointer so we can use 0, 
but not anything that gets converted to an int. 

A QFlags(int) constructor would work with any enum or anything that can be 
converted to int. That would defeat the purpose of QFlags.

> The problem encountered is that porting tools convert that to
> 
>  Qt::WindowFlags = nullptr
> 
> which is undesirable.

Yes, this is a case in which 0 was desired over nullptr. The problem is that 
you now even get a warning if you use "= 0" with some warning options.
So the trick is not really working anymore.

I'm not aware of another trick to enable the implicit conversion from '0' and 
no other thing.

If we allow implicit conversion from int, but still want to disable conversion 
from other enums, we could come up to something like this:

 QFlags(T); // normal constructor for the enum type
 QFlags(int);  // allow conversion from int
 
 // disallow construction from all other enumerations
 template<typename X> 
 QFlags(X, std::enable_if_t<std::is_enum_v<X>> *= nullptr) = delete;

But I'd rather QFlags not being implicitly constructed from int.

> https://mail.kde.org/pipermail/kde-frameworks-devel/2017-January/042091.html
> 
> Is there a better solution to that with modern c++?

As mentioned in the link, if you don't want to use nullptr because it's not 
pretty, and you don't want to use 0 because of the warning. Then the remaining 
option is to force the default constructor:

  Qt::WindowFlags = {};

> PS:
> 
> I mentioned there that Q_NO_TYPESAFE_FLAGS is broken. [...]
> The define could be removed from qflags.h. Perhaps something could be
> changed in qnamespace.h to allow the code to compile instead (and make the
> enum meta objects not available), but it doesn't seem worth it.

Yes, Q_NO_TYPESAFE_FLAGS is broken, as are most of the Q_NO_XXX.
I guess it could be removed, since QFlags does not have runtime cost, there is 
no point of keeping it, even for qt lite.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org


From thiago.macieira at intel.com  Sat Jan 21 17:06:03 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 21 Jan 2017 08:06:03 -0800
Subject: [Development] QFlags Zero handling
In-Reply-To: <o5vgor$jgi$1@blaine.gmane.org>
References: <o5vgor$jgi$1@blaine.gmane.org>
Message-ID: <3586906.LcelLRjjFF@tjmaciei-mobl1>

On sábado, 21 de janeiro de 2017 11:30:40 PST Stephen Kelly wrote:
> Hi,
> 
> Does anyone know why QFlags has a constructor taking a Zero pointer? My
> guess is that it's a hack to make initializing like
> 
>  Qt::WindowFlags = 0
> 
> work? The problem encountered is that porting tools convert that to
> 
>  Qt::WindowFlags = nullptr
> 
> which is undesirable.
> 
>  https://mail.kde.org/pipermail/kde-frameworks-devel/2017-January/042091.htm
> l
> 
> Is there a better solution to that with modern c++?

Use {}.

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



From thiago.macieira at intel.com  Sat Jan 21 16:57:24 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 21 Jan 2017 07:57:24 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <99031130.JgsEfcrxlB@patux.local>
References: <30311520.oodxC44c8O@bola> <1675354.YPmOQYsqtY@tjmaciei-mobl1>
	<99031130.JgsEfcrxlB@patux.local>
Message-ID: <1898373.k3bOoRPh7U@tjmaciei-mobl1>

On sábado, 21 de janeiro de 2017 09:50:50 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > A red herring. You've focused on the wrong part of the information.
> > 
> > The linker told you that it can't find a symbol with a given ELF version.
> > That's because the symbol isn't present at all, with any ELF version.
> 
> OK, thanks, I didn't catch that bit from what Google told me. So I would not
> have gotten the same error if the symbol were present with another ELF
> version?

No, you'd have got the same error message...

You'd have got a different message if we didn't use ELF versions.

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



From thiago.macieira at intel.com  Sat Jan 21 17:28:43 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 21 Jan 2017 08:28:43 -0800
Subject: [Development] QFlags Zero handling
In-Reply-To: <2667408.dsvGrLJ3s6@maurice>
References: <o5vgor$jgi$1@blaine.gmane.org> <2667408.dsvGrLJ3s6@maurice>
Message-ID: <4609103.0dzQzRNt9N@tjmaciei-mobl1>

On sábado, 21 de janeiro de 2017 17:10:04 PST Olivier Goffart wrote:
> > I mentioned there that Q_NO_TYPESAFE_FLAGS is broken. [...]
> > The define could be removed from qflags.h. Perhaps something could be
> > changed in qnamespace.h to allow the code to compile instead (and make the
> > enum meta objects not available), but it doesn't seem worth it.
> 
> Yes, Q_NO_TYPESAFE_FLAGS is broken, as are most of the Q_NO_XXX.
> I guess it could be removed, since QFlags does not have runtime cost, there
> is no point of keeping it, even for qt lite.

Agreed on qflags.

For the other flags, we've agreed to keep them around even if we know they're 
broken. Someone may want them and may want them enough to submit fixes for the 
build issues.

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



From rjvbertin at gmail.com  Sat Jan 21 17:31:34 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Sat, 21 Jan 2017 17:31:34 +0100
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
References: <30311520.oodxC44c8O@bola> <1675354.YPmOQYsqtY@tjmaciei-mobl1>
	<99031130.JgsEfcrxlB@patux.local>
	<1898373.k3bOoRPh7U@tjmaciei-mobl1>
Message-ID: <2335569.nQXx1dQHP2@portia.local>

Thiago Macieira wrote:

>> OK, thanks, I didn't catch that bit from what Google told me. So I would not
>> have gotten the same error if the symbol were present with another ELF
>> version?
> 
> No, you'd have got the same error message...

Hmm, is that useful, not being able to distinguish between "symbol not available 
at all" and "symbol not available with this ELF version"?

R



From rjvbertin at gmail.com  Sat Jan 21 19:37:49 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Sat, 21 Jan 2017 19:37:49 +0100
Subject: [Development] qt5.8 : configuring the use of PulseAudio and/or
 GStreamer
References: <3049164.HWW1izGdnU@portia.local> <20170118131459.GH24383@troll08>
	<2176939.T9KuBGGDei@portia.local> <20170119105651.GC30487@ugly>
	<3422221.6D8iA3gxC2@patux.local> <20170119202355.GD30487@ugly>
	<2412448.GjSeErjmQu@portia.local> <20170120095538.GJ24383@troll08>
	<2236020.5LaOjxUbUR@portia.local> <20170121103134.GA21792@ugly>
Message-ID: <5995941.75AH5xb35P@portia.local>

Oswald Buddenhagen wrote:

> feedback to them from the features. if the effect you're describing is
> genuine, there is something seriously screwed up in the qmake internals;
> you may get useful reports from valgrind or asan.

HAH! Would you believe I can no longer reproduce the error I copied earlier in 
this thread? I'm not going to swear I didn't make or dream it up but I almost 
feel like doing just that...

It does suggest that there's something fishy in qmake's internals. It actually 
felt like looking at a Heisenbug, so to be certain I've unpacked to a fresh 
build dir, but same there. All of a sudden -no-pulseaudio is happily accepted, 
provided the qtmultimedia directory is present. (That bit is a tad annoying but 
I guess we can live with that. Would be nice though if `configure --help` 
scoured the available */config_help.txt files and printed the additional known 
options.}

I have a trace from valgrind but there's nothing in there that suggests foul 
play anywhere. A couple of memory leaks (see below) but nothing surprising nor 
particularly shocking for something like qmake.

==56998== HEAP SUMMARY:
==56998==     in use at exit: 656,533 bytes in 4,188 blocks
==56998==   total heap usage: 1,047,206 allocs, 1,043,018 frees, 173,627,879 
bytes allocated
==56998==
==56998== Searching for pointers to 4,188 not-freed blocks
==56998== Checked 20,540,472 bytes
==56998==
==56998== LEAK SUMMARY:
==56998==    definitely lost: 4,240 bytes in 73 blocks
==56998==    indirectly lost: 30,816 bytes in 84 blocks
==56998==      possibly lost: 265,256 bytes in 70 blocks
==56998==    still reachable: 295,509 bytes in 3,496 blocks
==56998==         suppressed: 60,712 bytes in 465 blocks






From thiago.macieira at intel.com  Sun Jan 22 07:01:13 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 21 Jan 2017 22:01:13 -0800
Subject: [Development] Qt5.8/Linux : -version `Qt_5' not found error
 running lrelease building qttranslations
In-Reply-To: <2335569.nQXx1dQHP2@portia.local>
References: <30311520.oodxC44c8O@bola> <1898373.k3bOoRPh7U@tjmaciei-mobl1>
	<2335569.nQXx1dQHP2@portia.local>
Message-ID: <3139063.qWQyYDY1DY@tjmaciei-mobl1>

On sábado, 21 de janeiro de 2017 17:31:34 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> >> OK, thanks, I didn't catch that bit from what Google told me. So I would
> >> not have gotten the same error if the symbol were present with another
> >> ELF version?
> > 
> > No, you'd have got the same error message...
> 
> Hmm, is that useful, not being able to distinguish between "symbol not
> available at all" and "symbol not available with this ELF version"?

The dynamic linker isn't going to perform extra checks to tell you more 
precise details. It searched for 
_ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String@@Qt_5 and 
didn't find it. Searching for a specific symbol is easy because the symbol table 
is hashed and 97%+ of the symbols in QtCore can be found with just 5 string 
comparisons (average is 1.8). Without knowing which ELF versions may exist, it 
would need to do a full symbol search, which in my QtCore is 6223 comparisons.

Besides, it doesn't matter if 
_ZN9QtPrivate16QStringList_joinERK11QStringList13QLatin1String@@somethingelse 
exists, as it can't be used.

If you're trying to debug the issue, you can easily tell what case it is with 
readelf.

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



From bstottle at ford.com  Sun Jan 22 15:13:45 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Sun, 22 Jan 2017 14:13:45 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <d7e53f21-d6a9-44a3-b133-7d5757f32a85@qt.io>
References: <d7e53f21-d6a9-44a3-b133-7d5757f32a85@qt.io>
Message-ID: <7D0E3678-4351-45A1-BADE-E495EF1A7971@ford.com>

On 1/13/17, 3:22 AM, "Simon Hausmann" <Simon.Hausmann at qt.io> wrote:


>I scheduled a test build in the CI against 5.8 (as dev continues to be broken).

What are the implications for feature freeze if dev is still broken?

>There are few issues:
>
>1) namespaced build doesn't work

Fixed

>2) license check fails

Fixed

>3) tests run qmake infinitely on Windows.

Unable to reproduce or get details

>4) winrt / msvc 2013 build broken

Fixed

>Simon

Thanks!

As I understand it, there are several remaining steps to convert to a Qt Tech Preview, most of which I need help with.
1) Move /playground/qtremoteobjects to /qt/qtremoteobjects (need The Qt Company help here)
1a) Be ideal to create to rename the master branch to dev at this point (need The Qt Company help here)
2) Enable CI against the repository (need The Qt Company help here)
3) Submit a change to the qt5 repo to add QtRO (depends on #1 and #2)

I’ve started #3 here: https://codereview.qt-project.org/#/c/183053, but until the repo is moved, I’m unable to add it as a submodule.

Regards,
Brett


From Simon.Hausmann at qt.io  Sun Jan 22 16:51:19 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sun, 22 Jan 2017 15:51:19 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
Message-ID: <1a0193bf-9d06-4f57-ab96-e365a42e1cb9@qt.io>

Hi,

I have scheduled a new build of the current master branch against qt's dev branch:

http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1485097792522


5 out of 21 build configurations are failing.


Simon


________________________________
From: "Stottlemyer, Brett (B.S.)" <bstottle at ford.com>
Sent: Jan 22, 2017 15:13
To: Simon Hausmann; Lars Knoll; Alistair Adams; Buddenhagen Oswald
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9


On 1/13/17, 3:22 AM, "Simon Hausmann" <Simon.Hausmann at qt.io> wrote:


>I scheduled a test build in the CI against 5.8 (as dev continues to be broken).

What are the implications for feature freeze if dev is still broken?

>There are few issues:
>
>1) namespaced build doesn't work

Fixed

>2) license check fails

Fixed

>3) tests run qmake infinitely on Windows.

Unable to reproduce or get details

>4) winrt / msvc 2013 build broken

Fixed

>Simon

Thanks!

As I understand it, there are several remaining steps to convert to a Qt Tech Preview, most of which I need help with.
1) Move /playground/qtremoteobjects to /qt/qtremoteobjects (need The Qt Company help here)
1a) Be ideal to create to rename the master branch to dev at this point (need The Qt Company help here)
2) Enable CI against the repository (need The Qt Company help here)
3) Submit a change to the qt5 repo to add QtRO (depends on #1 and #2)

I’ve started #3 here: https://codereview.qt-project.org/#/c/183053, but until the repo is moved, I’m unable to add it as a submodule.

Regards,
Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170122/04043a09/attachment.html>

From bstottle at ford.com  Sun Jan 22 17:50:37 2017
From: bstottle at ford.com (Stottlemyer, Brett (B.S.))
Date: Sun, 22 Jan 2017 16:50:37 +0000
Subject: [Development] Switch Qt Remote Objects to a Tech Preview for Qt
 5.9
In-Reply-To: <1a0193bf-9d06-4f57-ab96-e365a42e1cb9@qt.io>
References: <1a0193bf-9d06-4f57-ab96-e365a42e1cb9@qt.io>
Message-ID: <A5072477-1A6D-4D56-8AD3-722D81904573@ford.com>

On 1/22/17, 10:51 AM, "Simon Hausmann" <Simon.Hausmann at qt.io> wrote:



>Hi,
>
>I have scheduled a new build of the current master branch against qt's dev branch:
>
>http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1485097792522
>
>
>5 out of 21 build configurations are failing.

Thanks again, Simon.

All 5 should be addressed by https://codereview.qt-project.org/183062 and https://codereview.qt-project.org/#/c/183059 once merged.

Regards,
Brett

From thomas.sondergaard at karoshealth.com  Mon Jan 23 09:28:38 2017
From: thomas.sondergaard at karoshealth.com (=?UTF-8?Q?Thomas_S=C3=B8ndergaard?=)
Date: Mon, 23 Jan 2017 09:28:38 +0100
Subject: [Development] Why doesn't xcb platform plugin use
 _NET_WM_STATE_HIDDEN?
Message-ID: <CAC551Qu6VsrpRSg5kTSWsTk38hnYij36xzzSLXh0CzFSg0nZZA@mail.gmail.com>

Why doesn't the XCB platform plugin use _NET_WM_STATE_HIDDEN? There are a
number of bugs related to it QTBUG-31117, QTBUG-39376, QTBUG-34430 and the
commit that address them (commit 382b7afbe253) uses the old WM_STATE.

I am looking at this because I'm trying to fix QTBUG-57882 which is about
the lack of support for setting the full window state on the native window
from Qt, so the programmer cannot programmatically set both minimized and
maximized state on a window at the same time, despite that being a
perfectly valid thing to do.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170123/56a43f27/attachment.html>

From rjvbertin at gmail.com  Mon Jan 23 10:56:27 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 23 Jan 2017 10:56:27 +0100
Subject: [Development] Change in qt/qtbase[5.8]: utilize configure
 results better in native builds
In-Reply-To: <20170120093801.GI24383@troll08>
References: <gerrit.1484859545719.Id62a3c1c6b7ae422b14efb4fbea0892b05a047cc@codereview.qt-project.org>
	<2684315.oSk383N0NL@bola> <20170120093801.GI24383@troll08>
Message-ID: <3191822.sgVLKp4EMN@bola>

Hi,

Is it possible that the failure (below) finding the QPA plugin in the test set-up below is a result of this proposed change, somehow?
Or am I overlooking an error in the env. settings to load the required binaries from the testing location?

Qt5 5.8.0RC built with the patch from https://codereview.qt-project.org/182877 was installed with INSTALL_ROOT=/opt/local/testing

Can it be that this difference between Qt5Core.so and Qt5gui.so has something to do with it (all other libraries use $ORIGIN too)?
%> objdump -p /opt/local/testing/libexec/qt5/lib/libQt5Core.so | fgrep PATH
  RUNPATH              /opt/local/lib:/opt/local/libexec/qt5/lib
%> objdump -p /opt/local/testing/libexec/qt5/lib/libQt5Gui.so | fgrep PATH
  RUNPATH              $ORIGIN:/opt/local/lib:/opt/local/libexec/qt5/lib

The error:
%> env LD_LIBRARY_PATH=/opt/local/testing/libexec/qt5/lib QT_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins QT_QPA_PLATFORM_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins/platforms systray-qt5/systray-qt5
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "/opt/local/testing/share/qt5/plugins/platforms".

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Reinstalling the application may fix this problem.
Abort (core dumped)



From kevin.ottens at kdab.com  Mon Jan 23 11:00:02 2017
From: kevin.ottens at kdab.com (Kevin Ottens)
Date: Mon, 23 Jan 2017 11:00:02 +0100
Subject: [Development] Coding convention for private includes
In-Reply-To: <2301797.7IKVIsLUIV@tjmaciei-mobl1>
References: <4219590.ZTIWWNod3B@titan> <2301797.7IKVIsLUIV@tjmaciei-mobl1>
Message-ID: <15501545.SEE3ubVcIF@wintermute>

Hello,

On Friday, 20 January 2017 15:06:53 CET Thiago Macieira wrote:
> On sexta-feira, 20 de janeiro de 2017 14:55:00 PST Sean Harmer wrote:
> > Just a query about the coding convention around inclusion of private
> > headers as specified at:
> > 
> > https://wiki.qt.io/Coding_Conventions#Including_headers
> > 
> > It states:
> > 
> > If you need to include private headers, be careful. Use the following
> > syntax, irrespective of which module or directory whatever_p.h is in.
> > 
> >  #include <private/whatever_p.h>
> > 
> > The issue is that this could lead to collisions. Is it OK to use:
> >  #include <QtModule/private/whatever_p.h>
> > 
> > ?
> 
> You need to be careful when including a private header from another private
> header. But if it's from a .cpp, you can use even relative paths.

What do you have in mind as risk when you say one needs to be careful?
Would that apply for using #include <QtModule/private/foo_p.h> in other 
private headers?

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4661 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170123/6450f591/attachment.bin>

From iamsergio at gmail.com  Mon Jan 23 11:30:50 2017
From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=)
Date: Mon, 23 Jan 2017 10:30:50 +0000
Subject: [Development] Change in qt/qtbase[5.8]: utilize configure
 results better in native builds
In-Reply-To: <3191822.sgVLKp4EMN@bola>
References: <gerrit.1484859545719.Id62a3c1c6b7ae422b14efb4fbea0892b05a047cc@codereview.qt-project.org>
	<2684315.oSk383N0NL@bola> <20170120093801.GI24383@troll08>
	<3191822.sgVLKp4EMN@bola>
Message-ID: <CA+hbW7RK-xCYF-5671rq+y3OOBWPDa+zPHvynby+D+59V=1LKw@mail.gmail.com>

On Mon, Jan 23, 2017 at 9:56 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> The error:
> %> env LD_LIBRARY_PATH=/opt/local/testing/libexec/qt5/lib QT_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins QT_QPA_PLATFORM_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins/platforms systray-qt5/systray-qt5
> This application failed to start because it could not find or load the Qt platform plugin "xcb"
> in "/opt/local/testing/share/qt5/plugins/platforms".
>
> Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
>
> Reinstalling the application may fix this problem.
> Abort (core dumped)

Hi,


Try running with QT_DEBUG_PLUGINS=1 and report back.

Regards,
Sergio Martins


From giuseppe.dangelo at kdab.com  Mon Jan 23 11:33:23 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Mon, 23 Jan 2017 11:33:23 +0100
Subject: [Development] Texture image loading library
In-Reply-To: <ADC09EA5-913F-49D4-AA9C-619759BC0A0B@gmail.com>
References: <a12b78dd-41db-578e-cea3-7f162d1b7f6d@kdab.com>
	<3257741.bPMclx67ll@titan> <20170121125115.GA5093@klara.mpi.htwm.de>
	<59421643.6II7UyjWLo@titan>
	<ADC09EA5-913F-49D4-AA9C-619759BC0A0B@gmail.com>
Message-ID: <8f42c97b-ccbd-14fb-82d3-20a9e75e65f9@kdab.com>

Il 21/01/2017 15:02, Иван Комиссаров ha scritto:
> Do I understand correctly that all is needed is to scan header of the
> texture, get some info from it and than load whole texture to the byte
> array?

Yes, get some metadata from the file, and no, not necessarily extract
the images as byte arrays.

It would actually be a total waste to copy it in CPU memory if you can
avoid that. The ideal and easy path would be getting a QOpenGLTexture
out of such a file with 0 CPU copies (e.g.: mmap the file, upload into
texture).

> It may be reasonable to create separate libraries that handle specific
> textures (dds, etc1, …).

I don't see the point at this stage, nor what advantage it would bring
to the user if she has to identify the file format first, and then use a
specific loader. (Side note: DDS is a file format, ETC1 is a compression
format. We want to parse/load data from the file, not decode or
decompress such data.)

> For now, I see some duplication of the code - there are similar
> structures in qt3d/src/threed/textures/qgltextureutils.cpp and
> qtimageformats/src/plugins/imageformats/dds/ddsheader.h, for example.

Yes, the one in qt3d should be extracted and reused, alongside with the
KTX format reader. The one in qtimageformats is currently dead.

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170123/b7de24a5/attachment.bin>

From rjvbertin at gmail.com  Mon Jan 23 12:18:28 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 23 Jan 2017 12:18:28 +0100
Subject: [Development] Change in qt/qtbase[5.8]: utilize configure
 results better in native builds
In-Reply-To: <CA+hbW7RK-xCYF-5671rq+y3OOBWPDa+zPHvynby+D+59V=1LKw@mail.gmail.com>
References: <gerrit.1484859545719.Id62a3c1c6b7ae422b14efb4fbea0892b05a047cc@codereview.qt-project.org>
	<3191822.sgVLKp4EMN@bola>
	<CA+hbW7RK-xCYF-5671rq+y3OOBWPDa+zPHvynby+D+59V=1LKw@mail.gmail.com>
Message-ID: <3763479.q990aNFhAJ@bola>

On Monday January 23 2017 10:30:50 Sérgio Martins wrote:

>Try running with QT_DEBUG_PLUGINS=1 and report back.

Hah, I think I was onto something, but it's not what I thought:

%> objdump -p systray-qt5/systray-qt5 | fgrep PATH
  RPATH                /opt/local/libexec/qt5/lib


As a result, all 5.8.0 platform plugins give an error like this:

%> env LD_LIBRARY_PATH=/opt/local/testing/libexec/qt5/lib QT_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins QT_QPA_PLATFORM_PLUGIN_PATH=/opt/local/testing/share/qt5/plugins/platforms QT_DEBUG_PLUGINS=1 systray-qt5/systray-qt5
...
Found metadata in lib /opt/local/testing/share/qt5/plugins/platforms/libqxcb.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "xcb"
        ]
    },
    "className": "QXcbIntegrationPlugin",
    "debug": false,
    "version": 329728
}
In /opt/local/testing/share/qt5/plugins/platforms/libqxcb.so:
  Plugin uses incompatible Qt library (5.8.0) [release]
...

and then finally the process fails with

Found metadata in lib /opt/local/share/qt5/plugins/platforms/libqxcb.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "xcb"
        ]
    },
    "className": "QXcbIntegrationPlugin",
    "debug": false,
    "version": 329473
}
QLibraryPrivate::loadPlugin failed on "/opt/local/share/qt5/plugins/platforms/libqxcb.so" : "Cannot load library /opt/local/share/qt5/plugins/platforms/libqxcb.so: (/opt/local/libexec/qt5/lib/libQt5Core.so.5: version `Qt_5.8' not found (required by /opt/local/testing/libexec/qt5/lib/libQt5XcbQpa.so.5))"
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "/opt/local/testing/share/qt5/plugins/platforms".

IOW, I'll need to find a way to build that systray app in such a way that it contains RUNPATH instead of RPATH.

Is that what qmake 5.8.0 should do with the patch from this codereview in place? 

R.


From announce at qt-project.org  Mon Jan 23 12:28:58 2017
From: announce at qt-project.org (List for announcements regarding Qt releases and development)
Date: Mon, 23 Jan 2017 11:28:58 +0000
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
Message-ID: <mailman.3032.1485171663.3960.announce@qt-project.org>

Hi all,

Qt 5.8.0 and Qt Creator 4.2.1 releases are out! For details please see the blog post (http://blog.qt.io/blog/2017/01/23/qt-5-8-released/, http://blog.qt.io/blog/2017/01/23/qt-creator-4-2-1-released/) & visit in https://www.qt.io/qt5-8/

Big thanks to everyone involved!

Br,
Jani

_______________________________________________
Announce mailing list
Announce at qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce


From thiago.macieira at intel.com  Mon Jan 23 17:15:41 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 23 Jan 2017 08:15:41 -0800
Subject: [Development] Coding convention for private includes
In-Reply-To: <15501545.SEE3ubVcIF@wintermute>
References: <4219590.ZTIWWNod3B@titan> <2301797.7IKVIsLUIV@tjmaciei-mobl1>
	<15501545.SEE3ubVcIF@wintermute>
Message-ID: <6038627.a411Jlt26p@tjmaciei-mobl1>

On segunda-feira, 23 de janeiro de 2017 11:00:02 PST Kevin Ottens wrote:
> > You need to be careful when including a private header from another
> > private
> > header. But if it's from a .cpp, you can use even relative paths.
> 
> What do you have in mind as risk when you say one needs to be careful?
> Would that apply for using #include <QtModule/private/foo_p.h> in other
> private headers?

No, that should be ok.

"Be careful" means not using "foo_p.h" or "../kernel/foo_p.h". There may be 
additional rules for headers that are used in the bootstrap library, but those 
won't affect you.

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



From vindrg at gmail.com  Mon Jan 23 18:13:17 2017
From: vindrg at gmail.com (Vincas Dargis)
Date: Mon, 23 Jan 2017 19:13:17 +0200
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
In-Reply-To: <mailman.3032.1485171663.3960.announce@qt-project.org>
References: <mailman.3032.1485171663.3960.announce@qt-project.org>
Message-ID: <639a3e64-35e6-aeff-7cfc-6827ceea1a25@gmail.com>

2017.01.23 13:28, List for announcements regarding Qt releases and development wrote:
> Hi all,
>
1> Qt 5.8.0 and Qt Creator 4.2.1 releases are out!

Will there be a 5.7.2 release? Thanks.


From thiago.macieira at intel.com  Mon Jan 23 18:45:10 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 23 Jan 2017 09:45:10 -0800
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
In-Reply-To: <639a3e64-35e6-aeff-7cfc-6827ceea1a25@gmail.com>
References: <mailman.3032.1485171663.3960.announce@qt-project.org>
	<639a3e64-35e6-aeff-7cfc-6827ceea1a25@gmail.com>
Message-ID: <3108883.bHpFtgp0Eq@tjmaciei-mobl1>

On segunda-feira, 23 de janeiro de 2017 19:13:17 PST Vincas Dargis wrote:
> 2017.01.23 13:28, List for announcements regarding Qt releases and 
development wrote:
> > Hi all,
> 
> 1> Qt 5.8.0 and Qt Creator 4.2.1 releases are out!
> 
> Will there be a 5.7.2 release? Thanks.

No. There will be a 5.6.2, but not another 5.7.x.

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



From jani.heikkinen at qt.io  Tue Jan 24 11:27:21 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 24 Jan 2017 10:27:21 +0000
Subject: [Development] Qt 5.9 feature freeze
In-Reply-To: <AM5PR0202MB25130509B1A02BB989EA92479D7D0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>,
	<AM5PR0202MB25130509B1A02BB989EA92479D7D0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
Message-ID: <DB3PR02MB09282ECD171BCF3E8A3B56B9D750@DB3PR02MB092.eurprd02.prod.outlook.com>

Hi all,

Only one week left. And we should start soft branching from 'dev' to '5.9' already tomorrow & finalize it 1.2.2017 to be able to have the FF as planned. 
Please update new features page as soon as possible; https://wiki.qt.io/New_Features_in_Qt_5.9 is quite empty still...

br,
Jani

________________________________________
From: Jani Heikkinen
Sent: Monday, January 16, 2017 1:26 PM
To: development at qt-project.org
Subject: Re: Qt 5.9 feature freeze

Kindly reminder: there is a bit more than two weeks left before FF is in effect. So please finalize new features now.
Is there new submolules coming in for 5.9? If there is those should be added in qt5.git now...

br,
Jani

________________________________________
From: Jani Heikkinen
Sent: Monday, January 2, 2017 12:26 PM
To: development at qt-project.org
Subject: Qt 5.9 feature freeze

Hi all,

Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to finalize all new features for Qt 5.9

Let's this time make sure we will keep the schedule (see https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight with ff. So if you already now see that some feature won't be ready early enough please postpone it to 5.10 instead.

Make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze)

br,
Jani Heikkinen
Release Manager








From b.terrier at gmail.com  Tue Jan 24 12:34:01 2017
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Tue, 24 Jan 2017 12:34:01 +0100
Subject: [Development] invokeMethod() with function pointers
In-Reply-To: <f966c0b5-f336-614d-dc19-1ce46b0710af@g76r.eu>
References: <CAO+E9or8JigzWUz3vKNQVcRCUr=_wZH0sr5f8CANA17WxLsgug@mail.gmail.com>
	<8487709.0MKfFRgsmG@maurice>
	<bb0d805d-9375-0d83-d805-6ac0f5d0c07c@g76r.eu>
	<2932012.vQArHYP3Zi@tjmaciei-mobl1>
	<f966c0b5-f336-614d-dc19-1ce46b0710af@g76r.eu>
Message-ID: <CAO+E9opamb_TreDqU28uKuFFiV2D+UFczCjE5szWABPzC_W3cw@mail.gmail.com>

Hi,

I'd like to get this in before 5.9 FF.

The current state is:
 - It works for member functions, function pointers and functors
 - It soft breaks existing code that were passing null literals.
 - The new functions do not accepts any arguments, users have to use lambda
 - The new functions do accept an optional return argument in the form
"ReturnType *" (without using Q_ARG),
the type is checked during compilation for function pointers (member or
not) using QtPrivate::FunctionPointer.
I am not sure for functors though as QtPrivate::FunctionPointer does not
work in this case, but QFunctorSlotObject
ensure that the actual return type of the functor can be assigned to a
ReturnType.

What must be done:
 - Add documentation
 - Complete auto tests
 - Optionally, remove the "ReturnType *" argument and for users to use
lambda with capture.
This remove the need to check for return in case of queued connection, but
add the responsibility for the user to ensure the lifespace
of variable captured by reference to sill be valid when the lambda is
executed.
- Optionally, move the function pointer/lambda to the last argument
position. This can make nicer code when using lambda,
at the cost of having to provide more overloads instead of using optional
arguments.

I would appreciate if any of you could check the gerrit change (
https://codereview.qt-project.org/#/c/182339/) and provide feedbacks,
especially if there is anything that would require a major change of the
current state.

Also, I'd like to get more opinions about the 2 optional changes.

Thanks.

Regards,

Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170124/f828695f/attachment.html>

From Kai.Koehne at qt.io  Tue Jan 24 13:00:40 2017
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Tue, 24 Jan 2017 12:00:40 +0000
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <20161110142306.GC9877@troll08>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
Message-ID: <AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>

Looks like this discussion got stuck before reaching a conclusion ...

> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, November 10, 2016 3:23 PM
> To: development at qt-project.org; releasing at qt-project.org
> Subject: Re: [Development] Change file process & improvement proposal
> [...]
> > 1) Let's enable [ChangeLog] -tag by default in commit template. After
> > that you must remove/comment out it by purpose if you don't want add
> > it.
> >
> i really don't think this will make a positive difference. the problem is that
> many people just don't have the right audience-oriented mindset.
> we *already* have lots of garbage changelog entries, and this will just
> worsen the S/N ratio.

Actually looking through the commit logs e.g. in qtbase, I do think most [ChangeLog] entries are rather fine - surely some tweaking is sometimes necessary, but the quality of the ChangeLog entries we have is not all that bad.

What is obvious though is that a lot of commits where I would have expected a [ChangeLog] do not have one. What's more, a well written [ChangeLog] entry will help also during the review, and can serve as a sanity check when it comes to the right branch being targeted etc.

I therefore agree with Janne that we should encourage people to write them, and changing the default template is a very easy thing to do.

> > And in addition to this update sanity bot so that it will give '-1' if
> > change log entry isn't given in release branch.
> >
> this is probably not sensible. most last-minute fixes relate to recently
> introduced problems, which means that they specifically *don't* need
> changelog entries.

That might be the case until the first .0 release from the branch is done, but surely not afterwards.

Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. Is that easy to enable/disable?

> here's what i think would actually make a difference (based on historical
> evidence within trolltech):
> https://bugreports.qt.io/browse/QTQAINFRA-933

Such a tool/infrastructure would be cool to have, indeed. It requires a lot more investment though than the incremental changes Jani proposed. 

I therefore suggest to implement Jani's suggestions for the time being. If we find out they're not effective, we can always come back and look into alternative processes.

1. Enable [ChangeLog] tag in commit template

https://codereview.qt-project.org/183244

2. Add check in sanity bot to check for missing ChangeLog entries (potentially only in 5.x branches after 5.x.0 is out)

(who could do this?)

Regards

Kai


From frederik.gladhorn at qt.io  Tue Jan 24 13:20:35 2017
From: frederik.gladhorn at qt.io (Frederik Gladhorn)
Date: Tue, 24 Jan 2017 13:20:35 +0100
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
Message-ID: <1685543.Pak2pvBs3S@frederik-thinkcentre-m93p>

On tirsdag 24. januar 2017 12.00.40 CET Kai Koehne wrote:
> Looks like this discussion got stuck before reaching a conclusion ...
> 
> > -----Original Message-----
> > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> > project.org] On Behalf Of Oswald Buddenhagen
> > Sent: Thursday, November 10, 2016 3:23 PM
> > To: development at qt-project.org; releasing at qt-project.org
> > Subject: Re: [Development] Change file process & improvement proposal
> > [...]
> > 
> > > 1) Let's enable [ChangeLog] -tag by default in commit template. After
> > > that you must remove/comment out it by purpose if you don't want add
> > > it.
> > 
> > i really don't think this will make a positive difference. the problem is
> > that many people just don't have the right audience-oriented mindset.
> > we *already* have lots of garbage changelog entries, and this will just
> > worsen the S/N ratio.
> 
> Actually looking through the commit logs e.g. in qtbase, I do think most
> [ChangeLog] entries are rather fine - surely some tweaking is sometimes
> necessary, but the quality of the ChangeLog entries we have is not all that
> bad.
> 
> What is obvious though is that a lot of commits where I would have expected
> a [ChangeLog] do not have one. What's more, a well written [ChangeLog]
> entry will help also during the review, and can serve as a sanity check
> when it comes to the right branch being targeted etc.
> 
> I therefore agree with Janne that we should encourage people to write them,
> and changing the default template is a very easy thing to do.
> > > And in addition to this update sanity bot so that it will give '-1' if
> > > change log entry isn't given in release branch.
> > 
> > this is probably not sensible. most last-minute fixes relate to recently
> > introduced problems, which means that they specifically *don't* need
> > changelog entries.
> 
> That might be the case until the first .0 release from the branch is done,
> but surely not afterwards.
> 
> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
> branched_. Is that easy to enable/disable?
> > here's what i think would actually make a difference (based on historical
> > evidence within trolltech):
> > https://bugreports.qt.io/browse/QTQAINFRA-933
> 
> Such a tool/infrastructure would be cool to have, indeed. It requires a lot
> more investment though than the incremental changes Jani proposed.
> 
> I therefore suggest to implement Jani's suggestions for the time being. If
> we find out they're not effective, we can always come back and look into
> alternative processes.
> 
> 1. Enable [ChangeLog] tag in commit template
> 
> https://codereview.qt-project.org/183244
> 
> 2. Add check in sanity bot to check for missing ChangeLog entries
> (potentially only in 5.x branches after 5.x.0 is out)

Why only there? All relevant changes should have it - regardless of branch.

I would actually suggest we change the sanity bot to -1 any change that has no 
[ChangeLog] entry. And we then agree on a marker that says "no changelog 
needed".

[ChangeLog] none

or similar.
At this point we'll be all constantly reminded to add change log entries and 
it's still reasonably easy to opt out.

Cheers,
Frederik

> 
> (who could do this?)
> 
> Regards
> 
> Kai
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing




From rpzrpzrpz at gmail.com  Tue Jan 24 15:29:42 2017
From: rpzrpzrpz at gmail.com (mark diener)
Date: Tue, 24 Jan 2017 08:29:42 -0600
Subject: [Development] Qt 5.9 feature freeze
In-Reply-To: <DB3PR02MB09282ECD171BCF3E8A3B56B9D750@DB3PR02MB092.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<AM5PR0202MB25130509B1A02BB989EA92479D7D0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<DB3PR02MB09282ECD171BCF3E8A3B56B9D750@DB3PR02MB092.eurprd02.prod.outlook.com>
Message-ID: <CAChgv6oxyAoThm0W8DnNOXmwiWG0v-A_11kqF3uQO-XHZrkf0Q@mail.gmail.com>

Jani:

Qt shipped 5.8.0. Qt Lite shipped. Nice Job.

Maybe Qt should actually define "Feature Freeze" as the following:

Qt will now FREEZE new development and task dev staff 100% for 2
months to clean out all the bugs that are P2 important and up
and get caught up on bug fixing.

At the end of 2 months, we will release 5.8.1 and then begin new
development on 5.9 based on the bug fixed 5.8 branch.

https://bugreports.qt.io/browse/QTBUG-46298

Version 5.2.1?  Really?

Why even report bugs if they are not going to get fixed for YEARS.

There there is this glaring FONT omission:

https://bugreports.qt.io/browse/QTBUG-58002

How did this make it past any sort of QA?

A coherent Qt reply appreciated:

md

















On Tue, Jan 24, 2017 at 4:27 AM, Jani Heikkinen <jani.heikkinen at qt.io> wrote:
> Hi all,
>
> Only one week left. And we should start soft branching from 'dev' to '5.9' already tomorrow & finalize it 1.2.2017 to be able to have the FF as planned.
> Please update new features page as soon as possible; https://wiki.qt.io/New_Features_in_Qt_5.9 is quite empty still...
>
> br,
> Jani
>
> ________________________________________
> From: Jani Heikkinen
> Sent: Monday, January 16, 2017 1:26 PM
> To: development at qt-project.org
> Subject: Re: Qt 5.9 feature freeze
>
> Kindly reminder: there is a bit more than two weeks left before FF is in effect. So please finalize new features now.
> Is there new submolules coming in for 5.9? If there is those should be added in qt5.git now...
>
> br,
> Jani
>
> ________________________________________
> From: Jani Heikkinen
> Sent: Monday, January 2, 2017 12:26 PM
> To: development at qt-project.org
> Subject: Qt 5.9 feature freeze
>
> Hi all,
>
> Please remember that Qt 5.9 Feature Freeze is 1.2.2017, so less than month to finalize all new features for Qt 5.9
>
> Let's this time make sure we will keep the schedule (see https://wiki.qt.io/Qt_5.9_Release). To be able to do that we need to be tight with ff. So if you already now see that some feature won't be ready early enough please postpone it to 5.10 instead.
>
> Make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.9) and fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze)
>
> br,
> Jani Heikkinen
> Release Manager
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From edward.welbourne at qt.io  Tue Jan 24 15:38:11 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 24 Jan 2017 14:38:11 +0000
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>,
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>

> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. Is that easy to enable/disable?

It should be easy to detect that 5.x.0 "has branched" - check for
existence of either origin/5.x.0 branch or v5.x.0 tag.  That we're
committing to 5.x is fairly easy *in Gerrit* (with its relatively
conservative branch set), and checking for 5.x when folk are using that
locally for development is easy, but checking a topic-branch for whether
it's based on (so presumptively targetting) 5.x rather than 5.y or dev
may be trickier.  (Getting such checks through code review may also be
tricky; c.f. https://codereview.qt-project.org/177706 ...)

	Eddy.


From oswald.buddenhagen at qt.io  Tue Jan 24 16:20:33 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Tue, 24 Jan 2017 16:20:33 +0100
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <20170124152033.GE20252@troll08>

On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote:
> > Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
> > branched_. Is that easy to enable/disable?
> 
> It should be easy to detect that 5.x.0 "has branched" - check for
> existence of either origin/5.x.0 branch or v5.x.0 tag. [...]
>
that's answering the wrong question. changes for 5.x.0 may require a
changelog just as well, as the branch may receive fixes against 5.(x-1).

we could suppress the changelog enforcement for example by standardizing
my "amends <sha1>." lines in the commit messages. if the reference is to
a commit which has not been tagged yet, we know that users won't find it
interesting.


From Kai.Koehne at qt.io  Tue Jan 24 16:30:06 2017
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Tue, 24 Jan 2017 15:30:06 +0000
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <1685543.Pak2pvBs3S@frederik-thinkcentre-m93p>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<1685543.Pak2pvBs3S@frederik-thinkcentre-m93p>
Message-ID: <AMSPR02MB152629CE526F9E53688A69498750@AMSPR02MB152.eurprd02.prod.outlook.com>

> -----Original Message-----
> > [...]
> > I therefore suggest to implement Jani's suggestions for the time
> > being. If we find out they're not effective, we can always come back
> > and look into alternative processes.
> >
> > 1. Enable [ChangeLog] tag in commit template
> >
> > https://codereview.qt-project.org/183244
> >
> > 2. Add check in sanity bot to check for missing ChangeLog entries
> > (potentially only in 5.x branches after 5.x.0 is out)
> 
> Why only there? All relevant changes should have it - regardless of branch.
> 
> I would actually suggest we change the sanity bot to -1 any change that has
> no [ChangeLog] entry. And we then agree on a marker that says "no
> changelog needed".
> 
> [ChangeLog] none
> 
> or similar.

This will add quite some noise - There'll always be a significant portion of the commits, if not the majority, which do not require a ChangeLog. 

But yeah, it's easy to check and enforce :) I could live with this, too.

Kai


From thiago.macieira at intel.com  Tue Jan 24 17:53:16 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 24 Jan 2017 08:53:16 -0800
Subject: [Development] Qt 5.9 feature freeze
In-Reply-To: <CAChgv6oxyAoThm0W8DnNOXmwiWG0v-A_11kqF3uQO-XHZrkf0Q@mail.gmail.com>
References: <AM5PR0202MB2513FE97428C9C19C612ED959D6F0@AM5PR0202MB2513.eurprd02.prod.outlook.com>
	<DB3PR02MB09282ECD171BCF3E8A3B56B9D750@DB3PR02MB092.eurprd02.prod.outlook.com>
	<CAChgv6oxyAoThm0W8DnNOXmwiWG0v-A_11kqF3uQO-XHZrkf0Q@mail.gmail.com>
Message-ID: <2753289.yrSJ5a9ruQ@tjmaciei-mobl1>

Em terça-feira, 24 de janeiro de 2017, às 08:29:42 PST, mark diener escreveu:
> Jani:
> 
> Qt shipped 5.8.0. Qt Lite shipped. Nice Job.
> 
> Maybe Qt should actually define "Feature Freeze" as the following:
> 
> Qt will now FREEZE new development and task dev staff 100% for 2
> months to clean out all the bugs that are P2 important and up
> and get caught up on bug fixing.

We can't tell people not to work on something. But they can't push new 
development to the 5.9 branch. From the FF onwards, all changes to the 5.9 
branch are related to stabilisation and bugfixing.

New features can go to dev, which will be 5.10.

> At the end of 2 months, we will release 5.8.1 and then begin new
> development on 5.9 based on the bug fixed 5.8 branch.

Ah, no. That's extremely unlikely.

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



From gunnar.roth at gmx.de  Tue Jan 24 22:01:49 2017
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Tue, 24 Jan 2017 22:01:49 +0100
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
In-Reply-To: <3108883.bHpFtgp0Eq@tjmaciei-mobl1>
References: <mailman.3032.1485171663.3960.announce@qt-project.org>
	<639a3e64-35e6-aeff-7cfc-6827ceea1a25@gmail.com>
	<3108883.bHpFtgp0Eq@tjmaciei-mobl1>
Message-ID: <0E7BAAB8-5FC6-4AFD-A24B-77477369C101@gmx.de>


>> 
> 
> No. There will be a 5.6.2, but not another 5.7.x.
Well, there IS already a 5.6.2 version.

Regals,
Gunnar Roth



From thiago.macieira at intel.com  Tue Jan 24 22:43:25 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 24 Jan 2017 13:43:25 -0800
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
In-Reply-To: <0E7BAAB8-5FC6-4AFD-A24B-77477369C101@gmx.de>
References: <mailman.3032.1485171663.3960.announce@qt-project.org>
	<3108883.bHpFtgp0Eq@tjmaciei-mobl1>
	<0E7BAAB8-5FC6-4AFD-A24B-77477369C101@gmx.de>
Message-ID: <2410060.PUyzjMetjn@tjmaciei-mobl1>

Em terça-feira, 24 de janeiro de 2017, às 22:01:49 PST, Gunnar Roth escreveu:
> > No. There will be a 5.6.2, but not another 5.7.x.
> 
> Well, there IS already a 5.6.2 version.

Ok, so there will be a 5.6.3.

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



From dima00782 at gmail.com  Wed Jan 25 07:31:29 2017
From: dima00782 at gmail.com (Dmitriy -)
Date: Wed, 25 Jan 2017 13:31:29 +0700
Subject: [Development] V8 integration
Message-ID: <CAJ0=vFDrQGcLfEdTJd1PzUR2RezS=48uCHxeLAe-VRNSrEfW=Q@mail.gmail.com>

Hello Qt developers.

I know that Qt uses V4 engine as a primary JavaScript engine, but Does it
still possible to use V8 and build qt with it?

-- 
Regards,
Dmitry Bezheckov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/c99dcfa2/attachment.html>

From Simon.Hausmann at qt.io  Wed Jan 25 08:40:45 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Wed, 25 Jan 2017 07:40:45 +0000
Subject: [Development] V8 integration
Message-ID: <f77ff418-b271-4700-8efd-d0127a098370@qt.io>

Hi,

I'm afraid that is not possible.


Simon


________________________________
From: Dmitriy - <dima00782 at gmail.com>
Sent: Jan 25, 2017 07:31
To: development at qt-project.org
Subject: [Development] V8 integration

Hello Qt developers.

I know that Qt uses V4 engine as a primary JavaScript engine, but Does it still possible to use V8 and build qt with it?

--
Regards,
Dmitry Bezheckov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/e014b4b4/attachment.html>

From dima00782 at gmail.com  Wed Jan 25 08:56:08 2017
From: dima00782 at gmail.com (Dmitriy -)
Date: Wed, 25 Jan 2017 14:56:08 +0700
Subject: [Development] V8 integration
In-Reply-To: <f77ff418-b271-4700-8efd-d0127a098370@qt.io>
References: <f77ff418-b271-4700-8efd-d0127a098370@qt.io>
Message-ID: <CAJ0=vFBbXHmEQbqGHg07cFYpoagDqJxfXSL+icCwFFVjfp4v5A@mail.gmail.com>

But Is it very hard to change qt5 js engine to v8 (5.1)?

On Wed, Jan 25, 2017 at 2:40 PM, Simon Hausmann <Simon.Hausmann at qt.io>
wrote:

> Hi,
>
> I'm afraid that is not possible.
>
>
> Simon
>
>
> ------------------------------
> *From:* Dmitriy - <dima00782 at gmail.com>
> *Sent:* Jan 25, 2017 07:31
> *To:* development at qt-project.org
> *Subject:* [Development] V8 integration
>
> Hello Qt developers.
>
> I know that Qt uses V4 engine as a primary JavaScript engine, but Does it
> still possible to use V8 and build qt with it?
>
> --
> Regards,
> Dmitry Bezheckov.
>



-- 
Regards,
Dmitry Bezheckov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/e5a4c1e0/attachment.html>

From Simon.Hausmann at qt.io  Wed Jan 25 08:57:54 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Wed, 25 Jan 2017 07:57:54 +0000
Subject: [Development] V8 integration
Message-ID: <f225aa5b-98ab-41b9-a63c-1d5aa9f0863a@qt.io>

Hi,

In Qt 5.1 we are still using V8. To change a later version of Qt to use V8 is very hard, yes.


Simon


________________________________
From: Dmitriy - <dima00782 at gmail.com>
Sent: Jan 25, 2017 08:56
To: Simon Hausmann
Cc: development at qt-project.org
Subject: Re: [Development] V8 integration

But Is it very hard to change qt5 js engine to v8 (5.1)?

On Wed, Jan 25, 2017 at 2:40 PM, Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:
Hi,

I'm afraid that is not possible.


Simon


________________________________
From: Dmitriy - <dima00782 at gmail.com<mailto:dima00782 at gmail.com>>
Sent: Jan 25, 2017 07:31
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: [Development] V8 integration

Hello Qt developers.

I know that Qt uses V4 engine as a primary JavaScript engine, but Does it still possible to use V8 and build qt with it?

--
Regards,
Dmitry Bezheckov.



--
Regards,
Dmitry Bezheckov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/9e6bcb01/attachment.html>

From edward.welbourne at qt.io  Wed Jan 25 10:21:09 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 25 Jan 2017 09:21:09 +0000
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <20170124152033.GE20252@troll08>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<20170124152033.GE20252@troll08>
Message-ID: <HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>

On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote:
>>> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
>>> branched_. Is that easy to enable/disable?
>>
>> It should be easy to detect that 5.x.0 "has branched" - check for
>> existence of either origin/5.x.0 branch or v5.x.0 tag. [...]

On 24 January 2017 16:20, Oswald Buddenhagen replied:
> that's answering the wrong question. changes for 5.x.0 may require a
> changelog just as well, as the branch may receive fixes against 5.(x-1).

What the proposal actually asked for was technically feasible; so I said
how to do it.  My impression was that the proposal was motivated by a
claim that stabilisation fixes typically won't want a change-log, as
they're fixes to recent changes.  The reasoning there may in fact be
flawed - a fix to a recent change *with a change-log entry* might well
need to amend/update the change-log entry.  Still, aside from that, I
suppose patch branches (M.m.p) are typically such stabilisation.

However, you seem to be talking about *release* 5.x.0 rather than the
*branch* of that name, so I'm not really clear on what you're talking
about.

> we could suppress the changelog enforcement for example by standardizing
> my "amends <sha1>." lines in the commit messages. if the reference is to
> a commit which has not been tagged yet, we know that users won't find it
> interesting.

I have never heard of these amends <sha1> lines; where are they
explained ?  In any case, users may find a change interesting even if
there is no specific earlier commit that can be pinned down as what this
new change amends - sometimes, the origin of a status quo (being
amended) is murky, its causes are contentious and most of the lines of
prior code involved date from the 190MB commit 38be0d1383 that pulled
most of our code into git in the first place.  Still, maybe your
amends-spec addresses that ...

	Eddy.


From Shawn.Rutledge at qt.io  Wed Jan 25 10:32:19 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Wed, 25 Jan 2017 09:32:19 +0000
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <FEE37F44-D9F7-411D-985A-4ACA3FDE3C80@qt.io>


> On 25 Jan 2017, at 10:21, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> I have never heard of these amends <sha1> lines; where are they
> explained ?  In any case, users may find a change interesting even if
> there is no specific earlier commit that can be pinned down as what this
> new change amends - sometimes, the origin of a status quo (being
> amended) is murky, its causes are contentious and most of the lines of
> prior code involved date from the 190MB commit 38be0d1383 that pulled
> most of our code into git in the first place.  Still, maybe your
> amends-spec addresses that …

You’ll find many of them in the logs, and every valid SHA1 (or even unique prefix of a SHA1) turns into a link automatically in some tools such as gitk, and the git log viewer in Creator, which helps a bit with following the chain of reasoning behind a block of code.  Forming a link which identifies a subset of the lines of the patch would be really very cool, but I don’t know of a way.


From rjvbertin at gmail.com  Wed Jan 25 11:06:32 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 25 Jan 2017 11:06:32 +0100
Subject: [Development] Change in qt/qtbase[5.8]: utilize configure
 results better in native builds
References: <gerrit.1484859545719.Id62a3c1c6b7ae422b14efb4fbea0892b05a047cc@codereview.qt-project.org>
	<3191822.sgVLKp4EMN@bola>
	<CA+hbW7RK-xCYF-5671rq+y3OOBWPDa+zPHvynby+D+59V=1LKw@mail.gmail.com>
	<3763479.q990aNFhAJ@bola>
Message-ID: <1714046.FPAAP9RtcM@patux.local>

René J.V. Bertin wrote:


> IOW, I'll need to find a way to build that systray app in such a way that it
> contains RUNPATH instead of RPATH.
> 
> Is that what qmake 5.8.0 should do with the patch from this codereview in
> place?

Answer: no, it doesn't. I installed the 5.8.0RC build from the testing area to 
the actual prefix and ran the new qmake. The resulting binary still has RPATH 
instead of RUNPATH.

This is the .pro file:

HEADERS       = window.h
SOURCES       = main.cpp window.cpp
RESOURCES     = systray.qrc
QT += widgets
# install
target.path = $$[QT_INSTALL_EXAMPLES]/widgets/desktop/systray
INSTALLS += target


R.



From oswald.buddenhagen at qt.io  Wed Jan 25 12:13:29 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 25 Jan 2017 12:13:29 +0100
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <20170125111329.GH20252@troll08>

On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote:
> However, you seem to be talking about *release* 5.x.0 rather than the
> *branch* of that name, so I'm not really clear on what you're talking
> about.
> 
i don't know how you arrived at this conclusion, but it isn't relevant
to my reasoning anyway.

> > we could suppress the changelog enforcement for example by standardizing
> > my "amends <sha1>." lines in the commit messages. if the reference is to
> > a commit which has not been tagged yet, we know that users won't find it
> > interesting.
> 
> I have never heard of these amends <sha1> lines; where are they
> explained ?
>
git log --author=oswald

> In any case, users may find a change interesting even if there is no
> specific earlier commit that can be pinned down [...]
>
unsurprisingly, i think that the correct fallback in case of a missing
reference is assuming that the commit relates to a tagged commit (if
it's even a fix at all) and therefore complaining about a missing
changelog.


From konstantin at podsvirov.pro  Wed Jan 25 13:43:01 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Wed, 25 Jan 2017 15:43:01 +0300
Subject: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released
In-Reply-To: <mailman.3032.1485171663.3960.announce@qt-project.org>
References: <mailman.3032.1485171663.3960.announce@qt-project.org>
Message-ID: <6696081485348181@web3j.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/e979028c/attachment.html>

From thomas.sondergaard at karoshealth.com  Wed Jan 25 17:47:15 2017
From: thomas.sondergaard at karoshealth.com (=?UTF-8?Q?Thomas_S=C3=B8ndergaard?=)
Date: Wed, 25 Jan 2017 17:47:15 +0100
Subject: [Development] Conditionally use xcb (or Xlib) in tst_qwindow.cpp?
Message-ID: <CAC551Qubm5M7aB8yRmPv_nYy0vvBgfC0bQstpg=rBSYXJhg8Ng@mail.gmail.com>

Hi,

I can see there is code in tests that depending on e.g. Q_OS_WIN32 and
Q_OS_UNIX conditionally includes, for the platform, universally available
headers like <sys/socket.h>. I would like to add a unit test that requires
checking state on the native window behind QWindow. Doing this on windows
with Q_OS_WIN32 should be fine, but how do I make the corresponding test
that requires a bit of XCB/Xlib code?

Specifically I would like to add a test to tst_qwindow.cpp and perhaps
tst_qwidget.cpp that check that the window state (minimized, maximized,
fullscreen) on the native window is what we expect it to be.

Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170125/991d315f/attachment.html>

From thiago.macieira at intel.com  Wed Jan 25 17:52:45 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 25 Jan 2017 08:52:45 -0800
Subject: [Development] Conditionally use xcb (or Xlib) in
 tst_qwindow.cpp?
In-Reply-To: <CAC551Qubm5M7aB8yRmPv_nYy0vvBgfC0bQstpg=rBSYXJhg8Ng@mail.gmail.com>
References: <CAC551Qubm5M7aB8yRmPv_nYy0vvBgfC0bQstpg=rBSYXJhg8Ng@mail.gmail.com>
Message-ID: <1959232.CEeIuXpcYE@tjmaciei-mobl1>

Em quarta-feira, 25 de janeiro de 2017, às 17:47:15 PST, Thomas Søndergaard 
escreveu:
> Hi,
> 
> I can see there is code in tests that depending on e.g. Q_OS_WIN32 and
> Q_OS_UNIX conditionally includes, for the platform, universally available
> headers like <sys/socket.h>. I would like to add a unit test that requires
> checking state on the native window behind QWindow. Doing this on windows
> with Q_OS_WIN32 should be fine, but how do I make the corresponding test
> that requires a bit of XCB/Xlib code?
> 
> Specifically I would like to add a test to tst_qwindow.cpp and perhaps
> tst_qwidget.cpp that check that the window state (minimized, maximized,
> fullscreen) on the native window is what we expect it to be.

Actually, it isn't that easy on Windows either. You cannot assume that the 
test is being run with the "windows" plugin.

You need to query QPA to find out which plugin you're using before using the 
backend native functions on the native handle.

As for linking to the required libraries, you should look into
	src/plugins/platforms/xcb/*.pro

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



From jani.heikkinen at qt.io  Thu Jan 26 06:28:23 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Thu, 26 Jan 2017 05:28:23 +0000
Subject: [Development] HEADS-UP: Branching from 'dev' to '5.9' started
Message-ID: <DB3PR02MB092508435BAD08C3A334ED49D770@DB3PR02MB092.eurprd02.prod.outlook.com>

Hi all,

We have now soft branched '5.9' from 'dev'. Target is to have final downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of February.

Please finalize ongoing changes in 'dev' and start using '5.9' for new changes targeted to Qt 5.9.0 release. 

Make sure all Qt 5.9.0 new features are ready in 'dev' latest Tuesday 31st January (see feature freeze checklist from https://wiki.qt.io/Qt_5_Feature_Freeze). At this time we really want to respect the feature freeze so if your feature isn't ready early enough please postpone it to 5.10 instead. So no new feature development in '5.9'; just stabilization and bug fixing. Remember also update new features page (https://wiki.qt.io/New_Features_in_Qt_5.9)

br,
Jani Heikkinen
Release Manager
The Qt Company







From edward.welbourne at qt.io  Thu Jan 26 09:51:24 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Thu, 26 Jan 2017 08:51:24 +0000
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <20170125111329.GH20252@troll08>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>,
	<20170125111329.GH20252@troll08>
Message-ID: <HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>

On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote:
>> However, you seem to be talking about *release* 5.x.0 rather than the
>> *branch* of that name, so I'm not really clear on what you're talking
>> about.

25 January 2017 12:13, Oswald Buddenhagen:
> i don't know how you arrived at this conclusion, but it isn't relevant
> to my reasoning anyway.

On the other hand, it's a fairly good clue to the possibility that I've
misunderstood what you were talking about.

>>> we could suppress the changelog enforcement for example by standardizing
>>> my "amends <sha1>." lines in the commit messages. if the reference is to
>>> a commit which has not been tagged yet, we know that users won't find it
>>> interesting.
>
>> I have never heard of these amends <sha1> lines; where are they
>> explained ?
>>
> git log --author=oswald

So a sort of after-the-fact fixup! tag.

>> In any case, users may find a change interesting even if there is no
>> specific earlier commit that can be pinned down [...]
>
> unsurprisingly, i think that the correct fallback in case of a missing
> reference is assuming that the commit relates to a tagged commit (if
> it's even a fix at all) and therefore complaining about a missing
> changelog.

I don't know what you're saying, much less why it's supposed to be the
obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
similar; why should a commit without an amends line be assumed to relate
to one of these ?  I *can* see how an amends line would be a basis for
not demanding a changelog entry, though.

	Eddy.


From oswald.buddenhagen at qt.io  Thu Jan 26 12:51:51 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 26 Jan 2017 12:51:51 +0100
Subject: [Development] Change file process & improvement proposal
In-Reply-To: <HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170125111329.GH20252@troll08>
	<HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <20170126115151.GD3289@troll08>

On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> I don't know what you're saying, much less why it's supposed to be the
> obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> similar; why should a commit without an amends line be assumed to
> relate to one of these ?
> 
i used "tagged commit" as a shorthand for "a commit which is reachable
from a tag", which should be fairly clear from the context. i.e., "git
tag --contains <sha1>" returns something.


From Kai.Koehne at qt.io  Thu Jan 26 13:28:30 2017
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Thu, 26 Jan 2017 12:28:30 +0000
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <20170126115151.GD3289@troll08>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170125111329.GH20252@troll08>
	<HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170126115151.GD3289@troll08>
Message-ID: <AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development at qt-project.org; releasing at qt-project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > I don't know what you're saying, much less why it's supposed to be the
> > obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> > similar; why should a commit without an amends line be assumed to
> > relate to one of these ?
> >
> i used "tagged commit" as a shorthand for "a commit which is reachable from
> a tag", which should be fairly clear from the context. i.e., "git tag --contains
> <sha1>" returns something.

Well, I had a hard time deciphering this, too. 



Anyway, this all feels like we get side-tracked in details. To reiterate:

- We do (still) have a problem with our ChangeLog files
  * The quality of the entries, and the scope, greatly differs (between modules)
  * We do have a problem getting them in place on time for a release

Jani's proposal is to fix parts of this is to encourage committers and reviewers to write [ChangeLog] entries as part of the commit. This could be encouraged by
* Enabling the [ChangeLog] line by default in the commit template
* Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)

For the sanity bot, either we decide that _every_ change has a [ChangeLog], or we try to make the bot intelligent enough to decide whether a commit needs a change log, or not. Parts of the discussion so far makes me think that this will be an uphill battle though.

So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] -" for commits that don't need one?

Regards

Kai

> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

From sean.harmer at kdab.com  Thu Jan 26 15:11:33 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Thu, 26 Jan 2017 14:11:33 +0000
Subject: [Development] Branch request for Qt 3D
Message-ID: <2897263.8yd7yXIFgB@titan>

Hi,

Could somebody create me a new wip/physics branch for the Qt 3D branched off 
of dev please? This is to start preparing a physics aspect hopefully for Qt 
5.10.

The existing wip/animation and wip/qtquickintegration branches should be going 
away shortly to keep things under control.

Thanks in advance,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From schluchti at gmail.com  Thu Jan 26 15:38:44 2017
From: schluchti at gmail.com (Bernhard B)
Date: Thu, 26 Jan 2017 15:38:44 +0100
Subject: [Development] Improve performance (listview +
 onVerticalVelocityChanged)
Message-ID: <CAF80AFbc6aBPBCLRzOtJpy5DqzF4j+troitFpH_0oZsEvRV2ig@mail.gmail.com>

Hi,

I am currently trying to optimize my Listview for performance. I already
removed most of the bottlenecks by following the great recommendations at:
http://doc.qt.io/qt-5/qtquick-performance.html

However, there is one problem I don't how to solve. It's about this code
part:

ListView{
    clip: true
    property real flickTabBarTreshold;

    Component.onCompleted: {
        flickTabBarTreshold = (2/3) * maximumFlickVelocity;
    }

    onVerticalVelocityChanged: {


    //when user scrolls fast enough up, show the tab bar     //and the
"back to top" button

    if(verticalVelocity < -flickTabBarTreshold) {
        backToTopButton.visible = true;

        tabBar.show();

    }



    //when user scrolls fast enough down hide "back to top" button
//and the tab bar
    if(verticalVelocity > flickTabBarTreshold){

        backToTopButton.visible = false;

        tabBar.hide();

    }

    //always disable "back to top button" when top reached
if(indexAt(contentX, contentY) === 0)        backToTopButton.visible =
false;

    }
}

This part is one of the biggest performance bottlenecks at the moment (as
it gets called a lot of times) and has a significant impact on the
scrolling behavior (lagging).

My idea was to put that code somehow in my C++ Listmodel and emit only a
signal when something actually changed.

For the last part

//always disable "back to top button" when top
reachedif(indexAt(contentX, contentY) === 0)   backToTopButton.visible
= false;


I think it should be possible to check that in the
QVariant <http://doc.qt.io/qt-5/qvariant.html> QAbstractItemModel::data(const
QModelIndex <http://doc.qt.io/qt-5/qmodelindex.html> &*index*, int *role* =
Qt::DisplayRole) const

method. When index.row() === 0, I a signal will be emitted. In QML I am
connecting on that signal and execute  backToTopButton.visible = false;

I haven't tested it yet, but I think it should work.

For the other two conditions however, I am a little bit clueless.

Does anyone of you guys maybe have an idea on how to improve that?

Any help is really appreciated.


Thanks,

Bernhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/62b5480a/attachment.html>

From robertpancoast77 at gmail.com  Thu Jan 26 18:49:10 2017
From: robertpancoast77 at gmail.com (=?UTF-8?Q?=C6=A6OB_COASTN?=)
Date: Thu, 26 Jan 2017 12:49:10 -0500
Subject: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless
 Receiver+Controller
Message-ID: <CAHoh2tSjVx2QRXfZ=vEFOoi_Xq1Q6qm_ZprfvOpS0eVMkwqwsQ@mail.gmail.com>

Greetings,

This is my first post to qt-project mailing list.
The information provided on https://github.com/qt/qtgamepad states:
Supported Platforms: Native Backends
Linux (evdev)
Window (xinput)
Android

I aim to develop QTgamepad on Windows Server 2012R2.

1.) Has the latest QTgamepad build been confirmed to function with Windows
Server 2012R2?
2.) Has the latest QTgamepad build been confirmed to function with Xbox
Controllers?

Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate
correctly.
The "Qt Gamepad Configure Buttons Example" compiles and runs, but the
connected Gamepads drop down never populates.
However, the values for the gamepad input accurately reflect button and
stick status.

It seems that something is not properly functioning with the
"GamepadManager.connectedGamepads".

3.) Any advice for troubleshooting?
4.) Is there a recommended Windows Operating System known to work with the
latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?

Thanks,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/2917edef/attachment.html>

From Andy.Nichols at qt.io  Thu Jan 26 19:19:23 2017
From: Andy.Nichols at qt.io (Andy Nichols)
Date: Thu, 26 Jan 2017 18:19:23 +0000
Subject: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless
 Receiver+Controller
In-Reply-To: <CAHoh2tSjVx2QRXfZ=vEFOoi_Xq1Q6qm_ZprfvOpS0eVMkwqwsQ@mail.gmail.com>
References: <CAHoh2tSjVx2QRXfZ=vEFOoi_Xq1Q6qm_ZprfvOpS0eVMkwqwsQ@mail.gmail.com>
Message-ID: <AM5PR0202MB2513BD4E58AA5281C0F6387797770@AM5PR0202MB2513.eurprd02.prod.outlook.com>

Hi,


  1.  I’ve not confirmed if QtGamepad works for Windows Server 2012 (not sure what kernel that is, but not a supported platform that I know of).  Should world anyway though.
  2.  Yes, QtGamepad definitely works with Xbox 360 and Xbox One controllers.  It is designed to after the SDL Gamepad API which makes all game controllers look/map to Xbox 360 controllers.
  3.  This is actually expected behavior.  The Configuration example depends on the backend supporting re-mapping.  That only works with the evdev backend.  The Xinput backend doesn’t support configuring the mapping of the controller, but you shouldn’t need to giving that you already are using a supported controller.  Rather if you want different aliases for buttons pressed you would handle that in your applications.
  4.  That combination is known to work (that’s what I wrote it for/with).  I was not using the server version of windows, but rather the standard Windows 7, 8, 10 kernels.

Actually Base of what you said things sound like they are working already.  I think there is an existing bug report for the Xinput backend for not reporting connecting and disconnecting properly.  It still should handle multiple connected controllers and the inputs for each, but might not send the connected and disconnected signals.

I guess I should also mention that this mailing list isn’t the correct place for this kind of inquiry, as this is about the development of Qt, and not the usage of Qt.

Regards,
Andy Nichols

From: Development [mailto:development-bounces+andy.nichols=qt.io at qt-project.org] On Behalf Of ?OB COASTN
Sent: Thursday, January 26, 2017 6:49 PM
To: development at qt-project.org
Subject: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless Receiver+Controller

Greetings,

This is my first post to qt-project mailing list.
The information provided on https://github.com/qt/qtgamepad states:
Supported Platforms: Native Backends
Linux (evdev)
Window (xinput)
Android

I aim to develop QTgamepad on Windows Server 2012R2.

1.) Has the latest QTgamepad build been confirmed to function with Windows Server 2012R2?
2.) Has the latest QTgamepad build been confirmed to function with Xbox Controllers?

Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate correctly.
The "Qt Gamepad Configure Buttons Example" compiles and runs, but the connected Gamepads drop down never populates.
However, the values for the gamepad input accurately reflect button and stick status.

It seems that something is not properly functioning with the "GamepadManager.connectedGamepads".

3.) Any advice for troubleshooting?
4.) Is there a recommended Windows Operating System known to work with the latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?

Thanks,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/94e4d5c6/attachment.html>

From robertpancoast77 at gmail.com  Thu Jan 26 20:00:29 2017
From: robertpancoast77 at gmail.com (=?UTF-8?Q?=C6=A6OB_COASTN?=)
Date: Thu, 26 Jan 2017 14:00:29 -0500
Subject: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation
Message-ID: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>

Greetings,

The cross-compilation of Qt5 and additional modules adds support for
headless Qt5 applications to run as native k1om co-processor applications.

Files that required modification include 'configure
<https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea41be717ff46#diff-e2d5a00791bce9a01f99bc6fd613a39d>'
and 'mkspecs/linux-icc/qmake.conf'

Reference:
https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea41be717ff46

I think it should be possible to create a new
'mkspecs/linux-icc-k1om/qmake.conf'.

Any thoughts for reworking the changes to  'configure' ?


Thanks,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/465336a1/attachment.html>

From annulen at yandex.ru  Thu Jan 26 20:06:07 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 26 Jan 2017 22:06:07 +0300
Subject: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation
In-Reply-To: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>
References: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>
Message-ID: <681801485457567@web1g.yandex.ru>



26.01.2017, 22:00, "ƦOB COASTN" <robertpancoast77 at gmail.com>:
> Greetings,
>
> The cross-compilation of Qt5 and additional modules adds support for headless Qt5 applications to run as native k1om co-processor applications.
>
> Files that required modification include 'configure' and 'mkspecs/linux-icc/qmake.conf'
>
> Reference:
> https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea41be717ff46
>
> I think it should be possible to create a new 'mkspecs/linux-icc-k1om/qmake.conf'.
>
> Any thoughts for reworking the changes to  'configure' ?

configure was largely reworked for Qt 5.8, your patch is against old version


-- 
Regards,
Konstantin


From schluchti at gmail.com  Thu Jan 26 20:09:26 2017
From: schluchti at gmail.com (Bernhard B)
Date: Thu, 26 Jan 2017 20:09:26 +0100
Subject: [Development] Improve performance (listview +
 onVerticalVelocityChanged)
In-Reply-To: <CAF80AFbc6aBPBCLRzOtJpy5DqzF4j+troitFpH_0oZsEvRV2ig@mail.gmail.com>
References: <CAF80AFbc6aBPBCLRzOtJpy5DqzF4j+troitFpH_0oZsEvRV2ig@mail.gmail.com>
Message-ID: <CAF80AFZcwyWoWJGBVose1NQRcbfsDqNQ8p_W=+8_pLivcH65Aw@mail.gmail.com>

I think I solved my problem. In case someone is interested, that's my
solution:

//hide "back to top" button when movement ended and we are

//at index 0

onMovementEnded: {
    if(indexAt(contentX, contentY) === 0){

      backToTopButton.visible = false;

  }

}

onFlickStarted: {

    //when user scrolls fast enough up, show the tab bar

    //and the "back to top" button

    if(verticalVelocity < -flickTabBarTreshold) {

        backToTopButton.visible = true;

        tabBar.show();

    }


    //when user scrolls fast enough down hide "back to top" button

    //and the tab bar

    if(verticalVelocity > flickTabBarTreshold){

        backToTopButton.visible = false;

        tabBar.hide();

    }

}

I don't know if this is the best solution, but it seems to work.

Thanks,
Bernhard

2017-01-26 15:38 GMT+01:00 Bernhard B <schluchti at gmail.com>:

> Hi,
>
> I am currently trying to optimize my Listview for performance. I already
> removed most of the bottlenecks by following the great recommendations at:
> http://doc.qt.io/qt-5/qtquick-performance.html
>
> However, there is one problem I don't how to solve. It's about this code
> part:
>
> ListView{
>     clip: true
>     property real flickTabBarTreshold;
>
>     Component.onCompleted: {
>         flickTabBarTreshold = (2/3) * maximumFlickVelocity;
>     }
>
>     onVerticalVelocityChanged: {
>
>
>     //when user scrolls fast enough up, show the tab bar     //and the "back to top" button
>
>     if(verticalVelocity < -flickTabBarTreshold) {
>         backToTopButton.visible = true;
>
>         tabBar.show();
>
>     }
>
>
>
>     //when user scrolls fast enough down hide "back to top" button    //and the tab bar
>     if(verticalVelocity > flickTabBarTreshold){
>
>         backToTopButton.visible = false;
>
>         tabBar.hide();
>
>     }
>
>     //always disable "back to top button" when top reached    if(indexAt(contentX, contentY) === 0)        backToTopButton.visible = false;
>
>     }
> }
>
> This part is one of the biggest performance bottlenecks at the moment (as
> it gets called a lot of times) and has a significant impact on the
> scrolling behavior (lagging).
>
> My idea was to put that code somehow in my C++ Listmodel and emit only a
> signal when something actually changed.
>
> For the last part
>
> //always disable "back to top button" when top reachedif(indexAt(contentX, contentY) === 0)   backToTopButton.visible = false;
>
>
> I think it should be possible to check that in the
> QVariant <http://doc.qt.io/qt-5/qvariant.html> QAbstractItemModel::data(const
> QModelIndex <http://doc.qt.io/qt-5/qmodelindex.html> &*index*, int *role*
> = Qt::DisplayRole) const
>
> method. When index.row() === 0, I a signal will be emitted. In QML I am
> connecting on that signal and execute  backToTopButton.visible = false;
>
> I haven't tested it yet, but I think it should work.
>
> For the other two conditions however, I am a little bit clueless.
>
> Does anyone of you guys maybe have an idea on how to improve that?
>
> Any help is really appreciated.
>
>
> Thanks,
>
> Bernhard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/70e892c8/attachment.html>

From robertpancoast77 at gmail.com  Thu Jan 26 20:14:59 2017
From: robertpancoast77 at gmail.com (=?UTF-8?Q?=C6=A6OB_COASTN?=)
Date: Thu, 26 Jan 2017 14:14:59 -0500
Subject: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless
 Receiver+Controller
In-Reply-To: <AM5PR0202MB2513BD4E58AA5281C0F6387797770@AM5PR0202MB2513.eurprd02.prod.outlook.com>
References: <CAHoh2tSjVx2QRXfZ=vEFOoi_Xq1Q6qm_ZprfvOpS0eVMkwqwsQ@mail.gmail.com>
	<AM5PR0202MB2513BD4E58AA5281C0F6387797770@AM5PR0202MB2513.eurprd02.prod.outlook.com>
Message-ID: <CAHoh2tTyVWyYmKfttKV5sUcyxi15eacH4GX8jZjwXtMvoNP6Dw@mail.gmail.com>

Hello Andy,

Thanks for the quick response.
Let's continue this discussion in the appropriate mailing list.

Reference:
http://lists.qt-project.org/pipermail/interest/2017-January/025940.html

Thanks,
Rob

On Thu, Jan 26, 2017 at 1:19 PM, Andy Nichols <Andy.Nichols at qt.io> wrote:

> Hi,
>
>
>
>    1. I’ve not confirmed if QtGamepad works for Windows Server 2012 (not
>    sure what kernel that is, but not a supported platform that I know of).
>    Should world anyway though.
>    2. Yes, QtGamepad definitely works with Xbox 360 and Xbox One
>    controllers.  It is designed to after the SDL Gamepad API which makes all
>    game controllers look/map to Xbox 360 controllers.
>    3. This is actually expected behavior.  The Configuration example
>    depends on the backend supporting re-mapping.  That only works with the
>    evdev backend.  The Xinput backend doesn’t support configuring the mapping
>    of the controller, but you shouldn’t need to giving that you already are
>    using a supported controller.  Rather if you want different aliases for
>    buttons pressed you would handle that in your applications.
>    4. That combination is known to work (that’s what I wrote it
>    for/with).  I was not using the server version of windows, but rather the
>    standard Windows 7, 8, 10 kernels.
>
>
>
> Actually Base of what you said things sound like they are working
> already.  I think there is an existing bug report for the Xinput backend
> for not reporting connecting and disconnecting properly.  It still should
> handle multiple connected controllers and the inputs for each, but might
> not send the connected and disconnected signals.
>
>
>
> I guess I should also mention that this mailing list isn’t the correct
> place for this kind of inquiry, as this is about the development of Qt, and
> not the usage of Qt.
>
>
>
> Regards,
>
> Andy Nichols
>
>
>
> *From:* Development [mailto:development-bounces+andy.nichols=
> qt.io at qt-project.org] *On Behalf Of *?OB COASTN
> *Sent:* Thursday, January 26, 2017 6:49 PM
> *To:* development at qt-project.org
> *Subject:* [Development] qtgamepad Support for Microsoft Xbox 360
> Wireless Receiver+Controller
>
>
>
> Greetings,
>
>
>
> This is my first post to qt-project mailing list.
>
> The information provided on https://github.com/qt/qtgamepad states:
>
> Supported Platforms: Native Backends
>
> Linux (evdev)
>
> Window (xinput)
>
> Android
>
>
>
> I aim to develop QTgamepad on Windows Server 2012R2.
>
>
>
> 1.) Has the latest QTgamepad build been confirmed to function with Windows
> Server 2012R2?
>
> 2.) Has the latest QTgamepad build been confirmed to function with Xbox
> Controllers?
>
>
>
> Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate
> correctly.
>
> The "Qt Gamepad Configure Buttons Example" compiles and runs, but the
> connected Gamepads drop down never populates.
>
> However, the values for the gamepad input accurately reflect button and
> stick status.
>
>
>
> It seems that something is not properly functioning with the
> "GamepadManager.connectedGamepads".
>
>
>
> 3.) Any advice for troubleshooting?
>
> 4.) Is there a recommended Windows Operating System known to work with the
> latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?
>
>
>
> Thanks,
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/ff6eedf5/attachment.html>

From robertpancoast77 at gmail.com  Thu Jan 26 20:19:15 2017
From: robertpancoast77 at gmail.com (=?UTF-8?Q?=C6=A6OB_COASTN?=)
Date: Thu, 26 Jan 2017 14:19:15 -0500
Subject: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation
In-Reply-To: <681801485457567@web1g.yandex.ru>
References: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>
	<681801485457567@web1g.yandex.ru>
Message-ID: <CAHoh2tTpg7bCZw_m2GYNGqAyPS+p1xAw67xNVskD4eU5kr4xjA@mail.gmail.com>

Greetings Konstantin,

I appreciate the insight/direction and will rework patches for the 5.8.0
codebase.

Thanks,
Rob


On Thu, Jan 26, 2017 at 2:06 PM, Konstantin Tokarev <annulen at yandex.ru>
wrote:

>
>
> 26.01.2017, 22:00, "ƦOB COASTN" <robertpancoast77 at gmail.com>:
> > Greetings,
> >
> > The cross-compilation of Qt5 and additional modules adds support for
> headless Qt5 applications to run as native k1om co-processor applications.
> >
> > Files that required modification include 'configure' and
> 'mkspecs/linux-icc/qmake.conf'
> >
> > Reference:
> > https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea4
> 1be717ff46
> >
> > I think it should be possible to create a new
> 'mkspecs/linux-icc-k1om/qmake.conf'.
> >
> > Any thoughts for reworking the changes to  'configure' ?
>
> configure was largely reworked for Qt 5.8, your patch is against old
> version
>
>
> --
> Regards,
> Konstantin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170126/0abaae55/attachment.html>

From milian.wolff at kdab.com  Fri Jan 27 00:20:46 2017
From: milian.wolff at kdab.com (Milian Wolff)
Date: Fri, 27 Jan 2017 00:20:46 +0100
Subject: [Development] QQmlListProperty<T>: static_assert that T inherits
 QObject
Message-ID: <1815381.pD7mR6tSTG@agathebauer>

Hey all,

the QQmlListProperty states:

"Note: QQmlListProperty can only be used for lists of QObject-derived object 
pointers."

Since I am bad at reading documentation, I previously tried (I think multiple 
times) to do something like:

QQmlListProperty<MyGadget>

or even

QQmlListProperty<NeitherQObjectNorQGadget>

This happily compiles and only at runtime does it not work. So I thought I'd 
add a static assert to QQmlListProperty to check this at compile time:

https://codereview.qt-project.org/#/c/183631/

But this uncovered this gem inside qtdeclarative itself:

qqmlobjectcreator_p.h:
158:    QQmlListProperty<void> _currentList;

Uhm, a void* list, really? Should this be a QQmlListProperty<QObject>?

Digging further, I find a few places where QQmlListProperty<T> is instantiated 
for non-QObjects, mostly within qmlRegisterUncreateableType, which is easy to 
prevent by leveraging std::enable_if.

Digging even further, I hit the first road-block though with my approach: 
Adding the static assert directly to QQmlListProperty means that T must be 
fully defined when the list property gets used. Does this make this change 
source-incompatible? Is there a workaround for this? I fixed the issues inside 
Qt Declarative itself, but I wonder whether this is acceptable for existing 
users of QQmlListProperty outside of QtDeclarative.

The second road-block comes when compiling the tests - apparently 
QQmlListProperty also works with interfaces! So I added another type trait for 
that. Is that acceptable?

Thanks

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/63a3fe43/attachment.bin>

From thiago.macieira at intel.com  Fri Jan 27 00:33:23 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 26 Jan 2017 15:33:23 -0800
Subject: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation
In-Reply-To: <CAHoh2tTpg7bCZw_m2GYNGqAyPS+p1xAw67xNVskD4eU5kr4xjA@mail.gmail.com>
References: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>
	<681801485457567@web1g.yandex.ru>
	<CAHoh2tTpg7bCZw_m2GYNGqAyPS+p1xAw67xNVskD4eU5kr4xjA@mail.gmail.com>
Message-ID: <106107874.rDKcWVjNkR@tjmaciei-mobl1>

Em quinta-feira, 26 de janeiro de 2017, às 14:19:15 PST, ƦOB COASTN escreveu:
> Greetings Konstantin,
> 
> I appreciate the insight/direction and will rework patches for the 5.8.0
> codebase.

5.8.0 is too old for that already. Please base your patches on the latest 5.8 
branch.

I've just tried to build things with -mmic and I can't get anything linking. I 
should probably follow the instructions, but I couldn't be bothered to look 
for them.

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



From robertpancoast77 at gmail.com  Fri Jan 27 00:38:55 2017
From: robertpancoast77 at gmail.com (Robert Pancoast)
Date: Thu, 26 Jan 2017 18:38:55 -0500
Subject: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation
In-Reply-To: <106107874.rDKcWVjNkR@tjmaciei-mobl1>
References: <CAHoh2tT_-bDq-wVWCtf70hxnhhNqFjR7wCQ1ZZQJ2+pYoVwSQg@mail.gmail.com>
	<681801485457567@web1g.yandex.ru>
	<CAHoh2tTpg7bCZw_m2GYNGqAyPS+p1xAw67xNVskD4eU5kr4xjA@mail.gmail.com>
	<106107874.rDKcWVjNkR@tjmaciei-mobl1>
Message-ID: <E4CFFAA5-B969-4343-9F94-FE3AC89E35CC@gmail.com>

Greetings Thiago,

I will take a closer look and get this functioning with latest dev branch from qt/qtbase. 

Thanks,
Rob



> On Jan 26, 2017, at 6:33 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
>> Em quinta-feira, 26 de janeiro de 2017, às 14:19:15 PST, ƦOB COASTN escreveu:
>> Greetings Konstantin,
>> 
>> I appreciate the insight/direction and will rework patches for the 5.8.0
>> codebase.
> 
> 5.8.0 is too old for that already. Please base your patches on the latest 5.8 
> branch.
> 
> I've just tried to build things with -mmic and I can't get anything linking. I 
> should probably follow the instructions, but I couldn't be bothered to look 
> for them.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From callu.david at gmail.com  Fri Jan 27 00:57:37 2017
From: callu.david at gmail.com (David Callu)
Date: Fri, 27 Jan 2017 00:57:37 +0100
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
Message-ID: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>

Hi,

I spend 3 day to search, fix and test my patch for this bug.
I finally found 3 Issue about it :

https://bugreports.qt.io/browse/QTBUG-53127
https://bugreports.qt.io/browse/QTBUG-45646
https://bugreports.qt.io/browse/QTBUG-30949

QTBUG-45646 have a patch that fix the bug. I did a similare patch on my own
and it work fine on windows.


but the code review of this patch :
https://codereview.qt-project.org/#/c/112854/
have the status

*Abandoned.*
This bug is here seen 2011, from the Initial import from the monolithic
Qt.commit.

Why did this patch is abandoned ?
What can i do to reactive it ?

If it is not correct, what can I do to fix it ?


Regards

David Callu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/3e10266d/attachment.html>

From thiago.macieira at intel.com  Fri Jan 27 04:49:27 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 26 Jan 2017 19:49:27 -0800
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
Message-ID: <21531114.eFUhLhnxeK@tjmaciei-mobl1>

Em sexta-feira, 27 de janeiro de 2017, às 00:57:37 PST, David Callu escreveu:
> Hi,
> 
> I spend 3 day to search, fix and test my patch for this bug.
> I finally found 3 Issue about it :

First of all, are you joining an IPv4 multicast group or an IPv6 one?

If it is IPv4, the priority for your issue has just dropped to the floor. I 
won't debug IPv4 multicast on Windows, on principle.

If it is IPv6, I'll do it.

> but the code review of this patch :
> https://codereview.qt-project.org/#/c/112854/
> have the status
> 
> *Abandoned.*
> This bug is here seen 2011, from the Initial import from the monolithic
> Qt.commit.
> 
> Why did this patch is abandoned ?

I don't know.

> What can i do to reactive it ?

I've just asked Andy to do it. If he doesn't do it, you can submit the fix 
yourself.

> If it is not correct, what can I do to fix it ?

Debug and submit your patch, if this one doesn't do it.

I will review IPv4 patches, but I will not lift a finger to test them.

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



From martin.leutelt at basyskom.com  Fri Jan 27 09:28:21 2017
From: martin.leutelt at basyskom.com (Martin Leutelt)
Date: Fri, 27 Jan 2017 09:28:21 +0100
Subject: [Development] Improve performance (listview +
 onVerticalVelocityChanged)
In-Reply-To: <CAF80AFZcwyWoWJGBVose1NQRcbfsDqNQ8p_W=+8_pLivcH65Aw@mail.gmail.com>
Message-ID: <3741182806-27813@mx1.basyskom.com>

Hi,


 From:   Bernhard B <schluchti at gmail.com> 
 To:   <development at qt-project.org> 
 Sent:   1/26/2017 8:09 PM 
 Subject:   Re: [Development] Improve performance (listview + onVerticalVelocityChanged) 





I think I solved my problem. In case someone is interested, that's my solution:

//hide "back to top" button when movement ended and we are//at index 0onMovementEnded: {
    if(indexAt(contentX, contentY) === 0){       backToTopButton.visible = false;   }}

onFlickStarted: {     //when user scrolls fast enough up, show the tab bar     //and the "back to top" button     if(verticalVelocity < -flickTabBarTreshold) {         backToTopButton.visible = true;         tabBar.show();     } 
     //when user scrolls fast enough down hide "back to top" button     //and the tab bar     if(verticalVelocity > flickTabBarTreshold){         backToTopButton.visible = false;         tabBar.hide();     }}

I don't know if this is the best solution, but it seems to work.


I guess you could also bind the visibility of your backToTopButton/tabBar to the ListView properties atYBeginning, flickingVertically and the comparison of
the verticalVelocity against your threshold.


Just as an info: the 'development' list is for questions regarding the development of Qt itself, questions regarding the usage of Qt should go to the 'interest' list.
More people will respond there.






Thanks,
Bernhard


Regards
Martin






2017-01-26 15:38 GMT+01:00 Bernhard B <schluchti at gmail.com>:






Hi, 

I am currently trying to optimize my Listview for performance. I already removed most of the bottlenecks by following the great recommendations at: http://doc.qt.io/qt-5/qtquick-performance.html

However, there is one problem I don't how to solve. It's about this code part:

ListView{
    clip: true
    property real flickTabBarTreshold;

    Component.onCompleted: {
        flickTabBarTreshold = (2/3) * maximumFlickVelocity;
    }


    onVerticalVelocityChanged: {
    
    //when user scrolls fast enough up, show the tab bar 
    //and the "back to top" button     if(verticalVelocity < -flickTabBarTreshold) {
        backToTopButton.visible = true;         tabBar.show();     }     
    
    //when user scrolls fast enough down hide "back to top" button
    //and the tab bar
    if(verticalVelocity > flickTabBarTreshold){         backToTopButton.visible = false;         tabBar.hide();     }

    //always disable "back to top button" when top reached
    if(indexAt(contentX, contentY) === 0)
        backToTopButton.visible = false;    }

}


This part is one of the biggest performance bottlenecks at the moment (as it gets called a lot of times) and has a significant impact on the scrolling behavior (lagging).


My idea was to put that code somehow in my C++ Listmodel and emit only a signal when something actually changed.


For the last part 

//always disable "back to top button" when top reached
if(indexAt(contentX, contentY) === 0)
   backToTopButton.visible = false;

I think it should be possible to check that in the 
QVariant QAbstractItemModel::data(const QModelIndex &index, int role = Qt::DisplayRole) const
method. When index.row() === 0, I a signal will be emitted. In QML I am connecting on that signal and execute  backToTopButton.visible = false;

I haven't tested it yet, but I think it should work.
For the other two conditions however, I am a little bit clueless. 

Does anyone of you guys maybe have an idea on how to improve that?


Any help is really appreciated.


Thanks,

Bernhard
 
 

_______________________________________________ 
Development mailing list 
Development at qt-project.org 
http://lists.qt-project.org/mailman/listinfo/development 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/89ff9809/attachment.html>

From konrad at silmor.de  Fri Jan 27 10:10:45 2017
From: konrad at silmor.de (Konrad Rosenbaum)
Date: Fri, 27 Jan 2017 10:10:45 +0100
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <21531114.eFUhLhnxeK@tjmaciei-mobl1>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
	<21531114.eFUhLhnxeK@tjmaciei-mobl1>
Message-ID: <07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>

Hi Thiago,

On Fri, January 27, 2017 04:49, Thiago Macieira wrote:
> If it is IPv4, the priority for your issue has just dropped to the floor.
> I
> won't debug IPv4 multicast on Windows, on principle.

> I will review IPv4 patches, but I will not lift a finger to test them.

I'm not sure whether this argument is persuasive for you: industry will
stay on IPv4 private networks (192.168.*, 10.*, 172.16.*, etc.) for a LONG
time. The networks are working, the infrastructure is known to every admin
out there, and lots of software has problems with IPv6 if it supports it
at all!

In fact quite a few of my colleagues will not recognize 2001:db8::42 as a
valid IP address...

In short: IPv4 (including multicast, which is used for "message buses")
has to work well for the foreseeable future. Even on an OS that we both
would not recommend for production use... ;-)


   Konrad



From mitch.curtis at qt.io  Fri Jan 27 10:20:10 2017
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Fri, 27 Jan 2017 09:20:10 +0000
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <DM2PR11MB01570F9743276E4A2C81111EF3770@DM2PR11MB0157.namprd11.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170125111329.GH20252@troll08>
	<HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170126115151.GD3289@troll08>,
	<AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>
	<DM2PR11MB01570F9743276E4A2C81111EF3770@DM2PR11MB0157.namprd11.prod.outlook.com>
Message-ID: <DB5PR0201MB202291C1264221BB3B78C0AB88760@DB5PR0201MB2022.eurprd02.prod.outlook.com>

It seems that not every reviewer with approval rights is aware (or seems to care, or just forgets) about stuff like this, though. It's a similar problem with docs; no doc team member is added to patches and so you end up with lots of doc issues that they then have to stumble upon after years of it being exposed to the public.

From: Releasing [mailto:releasing-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Schumann, Spencer
Sent: Thursday, 26 January 2017 5:11 PM
To: Kai Koehne <Kai.Koehne at qt.io>; Oswald Buddenhagen <Oswald.Buddenhagen at qt.io>; development at qt-project.org; releasing at qt-project.org
Subject: Re: [Releasing] [Development] Change file process & improvement proposal


> For the sanity bot, either we decide that _every_ change has a [ChangeLog], or we try to make the bot intelligent

> enough to decide whether a commit needs a change log, or not. Parts of the discussion so far makes me think

> that this will be an uphill battle though.
>
> So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] -" for commits that don't need one?



I doubt the decision on whether a changelog is needed could be adequately automated. Sometimes, even a one character change might need a detailed changelog.



Isn't this something that could and should be enforced via the code review process? If reviewers see that the changelog is missing or inadequate, they can reject the change.



- Spencer

________________________________
From: Releasing <releasing-bounces+spencer.schumann=echostar.com at qt-project.org<mailto:releasing-bounces+spencer.schumann=echostar.com at qt-project.org>> on behalf of Kai Koehne <Kai.Koehne at qt.io<mailto:Kai.Koehne at qt.io>>
Sent: Thursday, January 26, 2017 5:28:30 AM
To: Oswald Buddenhagen; development at qt-project.org<mailto:development at qt-project.org>; releasing at qt-project.org<mailto:releasing at qt-project.org>
Subject: Re: [Releasing] [Development] Change file process & improvement proposal



> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt-
> project.org<mailto:releasing-bounces+kai.koehne=qt.io at qt-%0b%3e%20project.org>] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development at qt-project.org<mailto:development at qt-project.org>; releasing at qt-project.org<mailto:releasing at qt-project.org>
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
>
> On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > I don't know what you're saying, much less why it's supposed to be the
> > obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> > similar; why should a commit without an amends line be assumed to
> > relate to one of these ?
> >
> i used "tagged commit" as a shorthand for "a commit which is reachable from
> a tag", which should be fairly clear from the context. i.e., "git tag --contains
> <sha1>" returns something.

Well, I had a hard time deciphering this, too.



Anyway, this all feels like we get side-tracked in details. To reiterate:

- We do (still) have a problem with our ChangeLog files
  * The quality of the entries, and the scope, greatly differs (between modules)
  * We do have a problem getting them in place on time for a release

Jani's proposal is to fix parts of this is to encourage committers and reviewers to write [ChangeLog] entries as part of the commit. This could be encouraged by
* Enabling the [ChangeLog] line by default in the commit template
* Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)

For the sanity bot, either we decide that _every_ change has a [ChangeLog], or we try to make the bot intelligent enough to decide whether a commit needs a change log, or not. Parts of the discussion so far makes me think that this will be an uphill battle though.

So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] -" for commits that don't need one?

Regards

Kai

> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org<mailto:Releasing at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/releasing
_______________________________________________
Releasing mailing list
Releasing at qt-project.org<mailto:Releasing at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/releasing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/0027c267/attachment.html>

From callu.david at gmail.com  Fri Jan 27 10:31:58 2017
From: callu.david at gmail.com (David Callu)
Date: Fri, 27 Jan 2017 10:31:58 +0100
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <21531114.eFUhLhnxeK@tjmaciei-mobl1>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
	<21531114.eFUhLhnxeK@tjmaciei-mobl1>
Message-ID: <CA+bFnLhPTRvwqOhUHvaDotCyVboOofoMsoZ-g6r5nu9XR09aBA@mail.gmail.com>

Hi Tiago

2017-01-27 4:49 GMT+01:00 Thiago Macieira <thiago.macieira at intel.com>:

> Em sexta-feira, 27 de janeiro de 2017, às 00:57:37 PST, David Callu
> escreveu:
> > Hi,
> >
> > I spend 3 day to search, fix and test my patch for this bug.
> > I finally found 3 Issue about it :
>
> First of all, are you joining an IPv4 multicast group or an IPv6 one?
>

It is IPv4 bug, IPv6 implementation use the interface index that work fine.


> If it is IPv4, the priority for your issue has just dropped to the floor. I
> won't debug IPv4 multicast on Windows, on principle.
>

I won't work/debug/code on windows, but have to do. My company provide a
solution
that work on linux/mac/windows. And IPv4 multicast on windows is not an
option.

I already have a patch for this bug, I test it. I also using a not so bad
windows' command (netsh),
to ask the system the multicast state. And I see that the code do the job.



> If it is IPv6, I'll do it.
>





> > but the code review of this patch :
> > https://codereview.qt-project.org/#/c/112854/
> > have the status
> >
> > *Abandoned.*
> > This bug is here seen 2011, from the Initial import from the monolithic
> > Qt.commit.
> >
> > Why did this patch is abandoned ?
>
> I don't know.
>
> > What can i do to reactive it ?
>
> I've just asked Andy to do it. If he doesn't do it, you can submit the fix
> yourself.
>
ok, I will do this if needed.


>
> > If it is not correct, what can I do to fix it ?
>
> Debug and submit your patch, if this one doesn't do it.
>
> I will review IPv4 patches, but I will not lift a finger to test them.
>
ok


Regards
David Callu


>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/530434df/attachment.html>

From callu.david at gmail.com  Fri Jan 27 10:33:03 2017
From: callu.david at gmail.com (David Callu)
Date: Fri, 27 Jan 2017 10:33:03 +0100
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
	<21531114.eFUhLhnxeK@tjmaciei-mobl1>
	<07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
Message-ID: <CA+bFnLgjFu_tu4U+NmUgHr+kGP_bZMWAuzzkczF_KKoj+oFt=A@mail.gmail.com>

2017-01-27 10:10 GMT+01:00 Konrad Rosenbaum <konrad at silmor.de>:

> Hi Thiago,
>
> On Fri, January 27, 2017 04:49, Thiago Macieira wrote:
> > If it is IPv4, the priority for your issue has just dropped to the floor.
> > I
> > won't debug IPv4 multicast on Windows, on principle.
>
> > I will review IPv4 patches, but I will not lift a finger to test them.
>
> I'm not sure whether this argument is persuasive for you: industry will
> stay on IPv4 private networks (192.168.*, 10.*, 172.16.*, etc.) for a LONG
> time. The networks are working, the infrastructure is known to every admin
> out there, and lots of software has problems with IPv6 if it supports it
> at all!
>
> In fact quite a few of my colleagues will not recognize 2001:db8::42 as a
> valid IP address...
>
> In short: IPv4 (including multicast, which is used for "message buses")
> has to work well for the foreseeable future. Even on an OS that we both
> would not recommend for production use... ;-)
>
> agree, +1
David


>
>    Konrad
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/0b5eecd6/attachment.html>

From annulen at yandex.ru  Fri Jan 27 10:36:59 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 27 Jan 2017 12:36:59 +0300
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
	<21531114.eFUhLhnxeK@tjmaciei-mobl1>
	<07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
Message-ID: <3267331485509819@web13m.yandex.ru>



27.01.2017, 12:11, "Konrad Rosenbaum" <konrad at silmor.de>:
> Hi Thiago,
>
> On Fri, January 27, 2017 04:49, Thiago Macieira wrote:
>>  If it is IPv4, the priority for your issue has just dropped to the floor.
>>  I
>>  won't debug IPv4 multicast on Windows, on principle.
>
>>  I will review IPv4 patches, but I will not lift a finger to test them.
>
> I'm not sure whether this argument is persuasive for you: industry will
> stay on IPv4 private networks (192.168.*, 10.*, 172.16.*, etc.) for a LONG
> time. The networks are working, the infrastructure is known to every admin
> out there, and lots of software has problems with IPv6 if it supports it
> at all!

I think here Thiago just stated his personal priorities/interests, not official
position of Qt Project.

Still, multicast on Linux has much more industrial uses than on Windows.

>
> In fact quite a few of my colleagues will not recognize 2001:db8::42 as a
> valid IP address...
>
> In short: IPv4 (including multicast, which is used for "message buses")
> has to work well for the foreseeable future. Even on an OS that we both
> would not recommend for production use... ;-)
>
>    Konrad
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Fri Jan 27 16:44:47 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 27 Jan 2017 07:44:47 -0800
Subject: [Development] Windows: Trying to join to a multicast group as a
 receiver with specific interface always uses default interface
In-Reply-To: <07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
References: <CA+bFnLi+5LscBLJ1YWMHSSsZ_5QdMwJkPp1tcgVuh7DuF5fhaA@mail.gmail.com>
	<21531114.eFUhLhnxeK@tjmaciei-mobl1>
	<07d0e26135937160572945d50e9fa64e.squirrel@squirrel.six.silmor.de>
Message-ID: <3880962.UKFQkGBpXm@tjmaciei-mobl1>

Em sexta-feira, 27 de janeiro de 2017, às 10:10:45 PST, Konrad Rosenbaum 
escreveu:
> I'm not sure whether this argument is persuasive for you: industry will
> stay on IPv4 private networks (192.168.*, 10.*, 172.16.*, etc.) for a LONG
> time. The networks are working, the infrastructure is known to every admin
> out there, and lots of software has problems with IPv6 if it supports it
> at all!
> 
> In fact quite a few of my colleagues will not recognize 2001:db8::42 as a
> valid IP address...
> 
> In short: IPv4 (including multicast, which is used for "message buses")
> has to work well for the foreseeable future. Even on an OS that we both
> would not recommend for production use... 

I understand it and I don't doubt you. But I won't do the work.

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



From sean.harmer at kdab.com  Fri Jan 27 16:48:54 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Fri, 27 Jan 2017 15:48:54 +0000
Subject: [Development] Policy for examples with large resources?
Message-ID: <3557848.NiF31eeBSu@cartman>

Hi,

we're adding in support for Physics Based Rendering to Qt 3D for much nicer 
rendering results. To make this look good we need resources (environment maps) 
that are large, typically many megabytes. See for e.g. https://codereview.qt-project.org/#/c/183721/

Obviously putting these directly in the qt3d repo is not ideal yet we need 
examples to demonstrate this stuff (and more in the future). Is there a way we 
can get a git-lfs repo set up as a submodule to be referenced by the qt3d 
repo?

Or is there some other solution that would be preferred?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From Simon.Hausmann at qt.io  Fri Jan 27 16:49:15 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Fri, 27 Jan 2017 15:49:15 +0000
Subject: [Development] QQmlListProperty<T>: static_assert that T
 inherits QObject
In-Reply-To: <1815381.pD7mR6tSTG@agathebauer>
References: <1815381.pD7mR6tSTG@agathebauer>
Message-ID: <VI1PR02MB1006409367E9D8D6B39DFE1D8C760@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


Regarding the question about why the engine itself uses QQmlListProperty<void> internally when populating

list properties during instantiation, I think you've already found the answer yourself: Because of interface types :)


I think it would be great if incorrectly used types could be reported to the developer as early as possible, but at the same

time the ability to things like forward-declaring "Foo" used by "Q_PROPERTY(QQmlListProperty<Foo> ...)" is likely a feature

used by many people when designing class interfaces. So I'm not sure it's a good idea to suddenly break their build when

upgrading to a new version of Qt.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Milian Wolff <milian.wolff at kdab.com>
Sent: Friday, January 27, 2017 12:20:46 AM
To: qt-dev
Subject: [Development] QQmlListProperty<T>: static_assert that T inherits QObject

Hey all,

the QQmlListProperty states:

"Note: QQmlListProperty can only be used for lists of QObject-derived object
pointers."

Since I am bad at reading documentation, I previously tried (I think multiple
times) to do something like:

QQmlListProperty<MyGadget>

or even

QQmlListProperty<NeitherQObjectNorQGadget>

This happily compiles and only at runtime does it not work. So I thought I'd
add a static assert to QQmlListProperty to check this at compile time:

https://codereview.qt-project.org/#/c/183631/

But this uncovered this gem inside qtdeclarative itself:

qqmlobjectcreator_p.h:
158:    QQmlListProperty<void> _currentList;

Uhm, a void* list, really? Should this be a QQmlListProperty<QObject>?

Digging further, I find a few places where QQmlListProperty<T> is instantiated
for non-QObjects, mostly within qmlRegisterUncreateableType, which is easy to
prevent by leveraging std::enable_if.

Digging even further, I hit the first road-block though with my approach:
Adding the static assert directly to QQmlListProperty means that T must be
fully defined when the list property gets used. Does this make this change
source-incompatible? Is there a workaround for this? I fixed the issues inside
Qt Declarative itself, but I wonder whether this is acceptable for existing
users of QQmlListProperty outside of QtDeclarative.

The second road-block comes when compiling the tests - apparently
QQmlListProperty also works with interfaces! So I added another type trait for
that. Is that acceptable?

Thanks

--
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/746d8bf8/attachment.html>

From milian.wolff at kdab.com  Fri Jan 27 16:54:54 2017
From: milian.wolff at kdab.com (Milian Wolff)
Date: Fri, 27 Jan 2017 16:54:54 +0100
Subject: [Development] QQmlListProperty<T>: static_assert that T
 inherits QObject
In-Reply-To: <VI1PR02MB1006409367E9D8D6B39DFE1D8C760@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <1815381.pD7mR6tSTG@agathebauer>
	<VI1PR02MB1006409367E9D8D6B39DFE1D8C760@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <2476715.ckLiL7QcBD@milian-kdab2>

On Friday, January 27, 2017 4:49:15 PM CET Simon Hausmann wrote:
> Hi,
> 
> 
> Regarding the question about why the engine itself uses
> QQmlListProperty<void> internally when populating list properties during 
instantiation, I think you've already found the answer yourself: Because of 
interface types :)

I.e. we need to keep it that way - ok.

> I think it would be great if incorrectly used types could be reported to the
> developer as early as possible, but at the same time the ability to things
> like forward-declaring "Foo" used by "Q_PROPERTY(QQmlListProperty<Foo> ...)"
> is likely a feature used by many people when designing class interfaces. So
> I'm not sure it's a good idea to suddenly break their build when upgrading
> to a new version of Qt.

Has anyone an idea how to fix that in a different way then?

It's a pity imo, if we decide that forward declaring is more important than 
enforcing the correct type hierarchy.

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/ef3153da/attachment.bin>

From oswald.buddenhagen at qt.io  Fri Jan 27 17:40:30 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Fri, 27 Jan 2017 17:40:30 +0100
Subject: [Development] Policy for examples with large resources?
In-Reply-To: <3557848.NiF31eeBSu@cartman>
References: <3557848.NiF31eeBSu@cartman>
Message-ID: <20170127164030.GI3289@troll08>

On Fri, Jan 27, 2017 at 03:48:54PM +0000, Sean Harmer wrote:
> Is there a way we can get a git-lfs repo set up as a submodule to be
> referenced by the qt3d repo?
> 
sure. you just need to prototype a solution which i can deploy to our
server. as of now, you have gerrit 2.7 and apache at your disposal.

> Or is there some other solution that would be preferred?
> 
one quite ugly variant is doing poor man's "lfs" by putting a script in
the repo which uses wget and such to fetch data from some well-known
location. the file names on the server should be versioned, of course.
the problem is of course reviewing and uploading the files ...


From annulen at yandex.ru  Fri Jan 27 17:48:12 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 27 Jan 2017 19:48:12 +0300
Subject: [Development] Policy for examples with large resources?
In-Reply-To: <20170127164030.GI3289@troll08>
References: <3557848.NiF31eeBSu@cartman> <20170127164030.GI3289@troll08>
Message-ID: <5863931485535692@web25h.yandex.ru>



27.01.2017, 19:41, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> On Fri, Jan 27, 2017 at 03:48:54PM +0000, Sean Harmer wrote:
>>  Is there a way we can get a git-lfs repo set up as a submodule to be
>>  referenced by the qt3d repo?
>
> sure. you just need to prototype a solution which i can deploy to our
> server. as of now, you have gerrit 2.7 and apache at your disposal.
>
>>  Or is there some other solution that would be preferred?
>
> one quite ugly variant is doing poor man's "lfs" by putting a script in
> the repo which uses wget and such to fetch data from some well-known
> location. the file names on the server should be versioned, of course.
> the problem is of course reviewing and uploading the files ...

Another variant which is similar but (arguably) somewhat less ugly is to put
assets into Conan[1] package. We already have necessary qt5.git infrastructure
in place.

[1] https://www.conan.io/

> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From Jason at zx2c4.com  Sat Jan 28 00:16:04 2017
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 28 Jan 2017 00:16:04 +0100
Subject: [Development] Incorrect TLS Session Verification on macOS with
 OrLater Options
Message-ID: <CAHmME9rr2BRfP+iaFELrm+ZM4DaF5mWvpZSPpyQOTwWRiiLPig@mail.gmail.com>

Hi,

The file src/network/ssl/qsslsocket_mac.cpp contains a nasty bug
preventing the use of setProtocol(QSsl::TlsV1_2OrLater):

bool QSslSocketBackendPrivate::verifySessionProtocol() const
{
   bool protocolOk = false;
   if (configuration.protocol == QSsl::AnyProtocol)
       protocolOk = true;
   else if (configuration.protocol == QSsl::TlsV1SslV3)
       protocolOk = (sessionProtocol() >= QSsl::SslV3);
   else if (configuration.protocol == QSsl::SecureProtocols)
       protocolOk = (sessionProtocol() >= QSsl::TlsV1_0);
   else
       protocolOk = (sessionProtocol() == configuration.protocol);

   return protocolOk;
}

In the else clause, it checks for equality between sessionProtocol()
and the configuration protocol. If the configuration protocol is
*OrLater, this will always be false, and so verification will never
succeed. And indeed, sessionProtocol() never returns an OrLater
response:

    switch (protocol) {
   case kSSLProtocol2:
       return QSsl::SslV2;
   case kSSLProtocol3:
       return QSsl::SslV3;
   case kTLSProtocol1:
       return QSsl::TlsV1_0;
   case kTLSProtocol11:
       return QSsl::TlsV1_1;
   case kTLSProtocol12:
       return QSsl::TlsV1_2;
   default:
       return QSsl::UnknownProtocol;
   }

The solution is to properly match the OrLaters and use the usual >= comparison.

A current workaround is to hard code the SSL version and not use an
OrLater, which is a bummer. Please fix and backport to LTS.

Thanks,
Jason


From alex at vikingsoft.eu  Sat Jan 28 10:27:34 2017
From: alex at vikingsoft.eu (Alejandro Exojo)
Date: Sat, 28 Jan 2017 10:27:34 +0100
Subject: [Development] Policy for examples with large resources?
In-Reply-To: <3557848.NiF31eeBSu@cartman>
References: <3557848.NiF31eeBSu@cartman>
Message-ID: <2565886.gzp8R3vWYR@walt>

On Friday 27 January 2017 15:48:54 Sean Harmer wrote:
> Obviously putting these directly in the qt3d repo is not ideal yet we need 
> examples to demonstrate this stuff (and more in the future). Is there a way
> we  can get a git-lfs repo set up as a submodule to be referenced by the
> qt3d repo?
> 
> Or is there some other solution that would be preferred?

I wholeheartedly recommend that you diverge as little as possible from Git 
LFS. The experience on the client side is really good, and with git v2.11 
(easy to compile locally if your vendor doesn't ship it) the speed has been 
increased 70 times with a new filter system, so it is close to the speed that 
native support would give you.

The problem for the Qt project is server side. Github, Gitlab and Bitbucket 
have support for LFS, but there is no production ready open source standalone 
LFS server (https://github.com/git-lfs/git-lfs/wiki/Implementations) that 
could live side by side with gerrit. Using those 3rd parties would be an 
option, but I don't see how, given that contribution to gerrit is different 
than the pull-request model of those.

The LFS blobs are uploaded as a pre-push hook, so that could be replaced by a 
script that runs rsync to upload your .git/lfs/objects that are not yet on the 
server. That way you ensure all versions are kept.

Then, the download of files happens in the "smudge" filter. You could replace 
that by a script that checks if the blob is there, downloads it, then calls 
git-lfs-smudge. I think you bypass all Git LFS usage of the network, but then 
your history would still be compatible, and the workflow good.

Oh, and there is also a custom transfer support, but I haven't tried myself: 
https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu


From mikkel at krautz.dk  Sat Jan 28 23:31:40 2017
From: mikkel at krautz.dk (Mikkel Krautz)
Date: Sat, 28 Jan 2017 23:31:40 +0100
Subject: [Development] Incorrect TLS Session Verification on macOS with
 OrLater Options
In-Reply-To: <CAHmME9rr2BRfP+iaFELrm+ZM4DaF5mWvpZSPpyQOTwWRiiLPig@mail.gmail.com>
References: <CAHmME9rr2BRfP+iaFELrm+ZM4DaF5mWvpZSPpyQOTwWRiiLPig@mail.gmail.com>
Message-ID: <CAAJZzgZ_hrDz+wOtrviiTYYjv1ZTYnr_iuOkmnUYT8f=h3qTtg@mail.gmail.com>

On Sat, Jan 28, 2017 at 12:16 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi,
>
> The file src/network/ssl/qsslsocket_mac.cpp contains a nasty bug
> preventing the use of setProtocol(QSsl::TlsV1_2OrLater):
>
> bool QSslSocketBackendPrivate::verifySessionProtocol() const
> {
>    bool protocolOk = false;
>    if (configuration.protocol == QSsl::AnyProtocol)
>        protocolOk = true;
>    else if (configuration.protocol == QSsl::TlsV1SslV3)
>        protocolOk = (sessionProtocol() >= QSsl::SslV3);
>    else if (configuration.protocol == QSsl::SecureProtocols)
>        protocolOk = (sessionProtocol() >= QSsl::TlsV1_0);
>    else
>        protocolOk = (sessionProtocol() == configuration.protocol);
>
>    return protocolOk;
> }
>
> In the else clause, it checks for equality between sessionProtocol()
> and the configuration protocol. If the configuration protocol is
> *OrLater, this will always be false, and so verification will never
> succeed. And indeed, sessionProtocol() never returns an OrLater
> response:
>
>     switch (protocol) {
>    case kSSLProtocol2:
>        return QSsl::SslV2;
>    case kSSLProtocol3:
>        return QSsl::SslV3;
>    case kTLSProtocol1:
>        return QSsl::TlsV1_0;
>    case kTLSProtocol11:
>        return QSsl::TlsV1_1;
>    case kTLSProtocol12:
>        return QSsl::TlsV1_2;
>    default:
>        return QSsl::UnknownProtocol;
>    }
>
> The solution is to properly match the OrLaters and use the usual >= comparison.
>
> A current workaround is to hard code the SSL version and not use an
> OrLater, which is a bummer. Please fix and backport to LTS.
>
> Thanks,
> Jason
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi Jason,

Thanks for reporting this.

I'm working on fixing it here (currently WIP):
https://codereview.qt-project.org/#/c/183781/

Thanks,
Mikkel


From jianliang79 at gmail.com  Sun Jan 29 05:13:48 2017
From: jianliang79 at gmail.com (Liang Jian)
Date: Sun, 29 Jan 2017 12:13:48 +0800
Subject: [Development] Shall we turn on /utf-8 compiler option when build qt
 for Windows?
Message-ID: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>

    Start from qt-5.8 I can't build qt anymore under Windows(simplified
chinese locale). Since there is a file
src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1
character, msvc2015 assume the source code's character set should be CP936
which make the complilation fail.
    I can only build qt by comment the line which contain the specical
character in src/plugins/generic/tuiotouch/qtuiohandler.cpp.
    But if I turn on -developer-build in configuration step, thing will get
worse than before, since -developer-build means treat warning as error, and
again I can't build qt anymore since there are other files contain
non-latin1 character (such as qstring.cpp), the build will fail due to the
character set warning.
    I am working on a Windows 10 x64 simplifed chinese machine, msvc2015
update3
    For more detail please refer to
https://bugreports.qt.io/browse/QTBUG-58161

    As a workaround, I have to modify the file
qtbase/mkspecs/common/msvc-desktop.conf
QMAKE_CFLAGS            = -nologo -Zc:wchar_t /utf-8
    After I add /utf-8 compiler option the build goes well.
    Shall we turn on this compiler option by default?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170129/b7e4273d/attachment.html>

From apoenitz at t-online.de  Sun Jan 29 10:33:39 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Sun, 29 Jan 2017 10:33:39 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
Message-ID: <20170129093339.GA15723@klara.mpi.htwm.de>

On Sun, Jan 29, 2017 at 12:13:48PM +0800, Liang Jian wrote:
>     Start from qt-5.8 I can't build qt anymore under Windows(simplified
> chinese locale). Since there is a file
> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1
> character, msvc2015 assume the source code's character set should be CP936
> which make the complilation fail.
>     I can only build qt by comment the line which contain the specical
> character in src/plugins/generic/tuiotouch/qtuiohandler.cpp.
>     But if I turn on -developer-build in configuration step, thing will get
> worse than before, since -developer-build means treat warning as error, and
> again I can't build qt anymore since there are other files contain
> non-latin1 character (such as qstring.cpp), the build will fail due to the
> character set warning.
>     I am working on a Windows 10 x64 simplifed chinese machine, msvc2015
> update3
>     For more detail please refer to
> https://bugreports.qt.io/browse/QTBUG-58161
> 
>     As a workaround, I have to modify the file
> qtbase/mkspecs/common/msvc-desktop.conf
> QMAKE_CFLAGS            = -nologo -Zc:wchar_t /utf-8
>     After I add /utf-8 compiler option the build goes well.
>     Shall we turn on this compiler option by default?

We should remove non-ASCII characters from the sources if they cause problems.

If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
on all supported compilers, that's fine to have, but mining log messages
or comments with characters that are known to cause issues in the processing
are a mindless waste of resources.

Andre'



From thiago.macieira at intel.com  Mon Jan 30 02:21:57 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 29 Jan 2017 17:21:57 -0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <20170129093339.GA15723@klara.mpi.htwm.de>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
Message-ID: <5938704.sfqBRPjXeF@tjmaciei-mobl1>

On domingo, 29 de janeiro de 2017 10:33:39 PST André Pönitz wrote:
> We should remove non-ASCII characters from the sources if they cause
> problems.

We've had this discussion. One of our largest contributors has a full legal 
name that doesn't fit in ASCII.

	Klarälvdalens Datakonsult AB

> If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
> on all supported compilers, that's fine to have

That's usually one of the problematic ones.

Not on this file, though:

    qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ 
" << x << y << "∡" << angle <<

That's easy to fix by using "\342\210\241" instead.

So, we should:
 a) still avoid non-ASCII in our source files, aside from comments
 b) allow non-ASCII in comments, as needed
 c) turn the -utf-8 option on for MSVC2015U3.

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



From hamed.masafi at gmail.com  Mon Jan 30 08:59:12 2017
From: hamed.masafi at gmail.com (Hamed Masafi)
Date: Mon, 30 Jan 2017 11:29:12 +0330
Subject: [Development] Calendar Systems proposal
Message-ID: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>

I'm working on qml support of calendar system,
for porting this mechanism to qml we have two option:

1)
Add a global object to jsengine?
Somthing like that :

var date = new Date;
var cal = new JalaliCalendar;
var out = date.toString(cal, "yyyy-MM-dd");

In this case JalaliCalendar is a new global object type (like date, string,
regex, array and etc).

2)
Or another option may be adding calendar() to global Qt function, the usage
example can be like that:

var date = new Date;
var out = date.toString(Qt.calendar('jalali'), "yyyy-MM-dd");

​3)

var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

In this method Qt.calendar like Qt.locale initialize with a string.

Now question is that: witch form is preferred? Will be case (1) break Qt
rules?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/1913b4c3/attachment.html>

From marc.mutz at kdab.com  Mon Jan 30 09:42:05 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Mon, 30 Jan 2017 09:42:05 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <5938704.sfqBRPjXeF@tjmaciei-mobl1>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
Message-ID: <201701300942.05911.marc.mutz@kdab.com>

On Monday 30 January 2017 02:21:57 Thiago Macieira wrote:
>     qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << "
> @  " << x << y << "∡" << angle <<
> 
> That's easy to fix by using "\342\210\241" instead.

Which is totally and utterly opaque. So much so that one feels forced to add a 
comment

  // ∡

but then MSVC complains, too.

Lose-lose.

The question really is: why does this come up only now? Is it because of 
MSVC2015, and does it thus mean that only compilers that provide the /utf-8
option warn? In that case, the correct thing is to enable the option and leave 
UTF-8 chars in the source alone.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From Julius.Bullinger at asctec.de  Mon Jan 30 09:40:57 2017
From: Julius.Bullinger at asctec.de (Julius Bullinger)
Date: Mon, 30 Jan 2017 08:40:57 +0000
Subject: [Development] Policy for examples with large resources?
In-Reply-To: <5863931485535692@web25h.yandex.ru>
References: <3557848.NiF31eeBSu@cartman> <20170127164030.GI3289@troll08>
	<5863931485535692@web25h.yandex.ru>
Message-ID: <cd19a3124be2408593bf7eea656644c0@SRV1.asctec.local>

Hi Konstantin

On Friday, 27 January, 2017 at 17:48, Konstantin Tokarev wrote:
> 27.01.2017, 19:41, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
>> On Fri, Jan 27, 2017 at 03:48:54PM +0000, Sean Harmer wrote:
>>>  Is there a way we can get a git-lfs repo set up as a submodule to be
>>>  referenced by the qt3d repo?
>>
>> sure. you just need to prototype a solution which i can deploy to our
>> server. as of now, you have gerrit 2.7 and apache at your disposal.
>>
>>>  Or is there some other solution that would be preferred?
>>
>> one quite ugly variant is doing poor man's "lfs" by putting a script in
>> the repo which uses wget and such to fetch data from some well-known
>> location. the file names on the server should be versioned, of course.
>> the problem is of course reviewing and uploading the files ...
> 
> Another variant which is similar but (arguably) somewhat less ugly is to put
> assets into Conan[1] package. We already have necessary qt5.git infrastructure
> in place.
> 
>  [1] https://www.conan.io/

What do you mean by "We already have necessary qt5.git infrastructure in place"?

As a Conan user myself, I'd like to learn more about these packages. Are there official Qt packages for Conan available? I've found a few unofficial ones, but didn’t know anything about official support. Could you provide a link or some documentation?

Thanks,

Julius

From jianliang79 at gmail.com  Mon Jan 30 09:50:29 2017
From: jianliang79 at gmail.com (Liang Jian)
Date: Mon, 30 Jan 2017 16:50:29 +0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <201701300942.05911.marc.mutz@kdab.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<201701300942.05911.marc.mutz@kdab.com>
Message-ID: <CAFo+GDW-3Aaye604Co8i5E0AGnOdpAgpZBqQ9wpkroG_4yPgQQ@mail.gmail.com>

https://codereview.qt-project.org/#/c/183817/

On Mon, Jan 30, 2017 at 4:42 PM, Marc Mutz <marc.mutz at kdab.com> wrote:

> On Monday 30 January 2017 02:21:57 Thiago Macieira wrote:
> >     qCDebug(lcTuioSet) << "Processing SET for token " << classId << id
> << "
> > @  " << x << y << "∡" << angle <<
> >
> > That's easy to fix by using "\342\210\241" instead.
>
> Which is totally and utterly opaque. So much so that one feels forced to
> add a
> comment
>
>   // ∡
>
> but then MSVC complains, too.
>
> Lose-lose.
>
> The question really is: why does this come up only now? Is it because of
> MSVC2015, and does it thus mean that only compilers that provide the /utf-8
> option warn? In that case, the correct thing is to enable the option and
> leave
> UTF-8 chars in the source alone.
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/f431a78e/attachment.html>

From giuseppe.dangelo at kdab.com  Mon Jan 30 09:56:46 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Mon, 30 Jan 2017 09:56:46 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <5938704.sfqBRPjXeF@tjmaciei-mobl1>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
Message-ID: <79af8d51-4137-8c1d-f903-19d0ff985aa1@kdab.com>

Il 30/01/2017 02:21, Thiago Macieira ha scritto:
> So, we should:
>  a) still avoid non-ASCII in our source files, aside from comments
>  b) allow non-ASCII in comments, as needed

Didn't we have issues with UTF-8 in comments too, when using MSVC?

>  c) turn the -utf-8 option on for MSVC2015U3.

But just for Qt own build, not push this option onto the users. Also,
does this fix anything? Is MSVC 2015 U3 the only one complaining, and we
can live with UTF-8 in the source when using other compilers?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/6bc7248c/attachment.bin>

From edward.welbourne at qt.io  Mon Jan 30 10:48:13 2017
From: edward.welbourne at qt.io (Edward, Welbourne)
Date: Mon, 30 Jan 2017 09:48:13 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
References: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
Message-ID: <HE1PR0202MB26839D6AF51B08926D83E02C874B0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Hamed Masafi (30 January 2017 08:59):
> I'm working on qml support of calendar system,

That shall complement Soroush Rabiei's work on the C++ side:
https://codereview.qt-project.org/182341
http://bugreports.qt.io/browse/QTBUG-58404
Prior discussion:
http://lists.qt-project.org/pipermail/development/2016-December/028125.html
http://lists.qt-project.org/pipermail/development/2017-January/028234.html

> for porting this mechanism to qml we have two option:
>
> 1)
> Add a global object to jsengine?
> Somthing like that :
>
> var date = new Date;
> var cal = new JalaliCalendar;
> var out = date.toString(cal, "yyyy-MM-dd");
>
> In this case JalaliCalendar is a new global object type (like date,
> string, regex, array and etc).

If I understand Lars correctly, he prefers an API where the calendar
object carries methods that act on a date and any further arguments it
may need (similar to QLocale), so cal.toString(date, "yyyy-MM-dd") is
more likely (although I personally like the style of API you give above,
where the date object has the calendar-aware methods; too many of the
details are the same between calendar systems).  Aside from that, this
is roughly the shape the C++ API shall have, making it a natural model
for the QML to follow.

That C++ API is designed, however, with an eye on the long tail of less
widely used calendars - we aim to let their users be able to add a C++
class, possibly via a plugin, whose instances implement their calendar.
With this model for QML's API, that would require them to *also* add a
QML aspect of their C++ class.  I'm not sure how easy that is, or how
pluggable.

> 2)
> Or another option may be adding calendar() to global Qt function, the
> usage example can be like that:
>
> var date = new Date;
> var out = date.toString(Qt.calendar('jalali'), "yyyy-MM-dd");

This would require some infrastructure behind Qt.calendar() that would
let authors of calendar system classes register them so that it knows
how to instantiate them.  If that's easier than whatever it takes to add
a global object to QML (or an property of the Qt object), it might be a
good way to make life easier for calendar system implementors.

> ​3)
>
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");
>
> In this method Qt.calendar like Qt.locale initialize with a string.

Not sure what you're proposing here - you don't mention Qt.calendar in
the code example, which looks more like 1) with JalaliCalendar moved to
the Qt object - which may indeed be a better place for it than as a
naked global object.

> Now question is that: witch form is preferred? Will be case (1) break
> Qt rules?

I don't know what rules QML might impose.  Each of these would, in one
way or another, require the calendar system code to register itself in
some way with QML, associated with the name by which QML is to refer to
it.  The details of whether that name is in the namespace of some
visible object (the ECMAScript global object or the Qt object) or in
some internal mapping (for 2) are a matter of what's practical or
convenient - someone with more QML fu than I can claim can advise you
better there.

	Eddy.

From edward.welbourne at qt.io  Mon Jan 30 10:58:30 2017
From: edward.welbourne at qt.io (Edward, Welbourne)
Date: Mon, 30 Jan 2017 09:58:30 +0000
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
Message-ID: <HE1PR0202MB2683446D52AA0662F5FF4884874B0@HE1PR0202MB2683.eurprd02.prod.outlook.com>

Liang Jian (29 January 2017 05:13):
>    Start from qt-5.8 I can't build qt anymore under Windows(simplified
> chinese locale). Since there is a file
> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain
> non-latin-1 character, msvc2015 assume the source code's character set
> should be CP936 which make the complilation fail.

Stray thought: this sounds like something that would be fixed (on Unix)
by setting the locale-controlling environment variables, so that your
build happens in a local using UTF-8 as its encoding; hopefully, that
would then coax the compiler into using this by default and not getting
upset.  I'm not sure how that works on MS-Windows, but I'd just set
LANG=en.UTF-8 in my environment on any Unix; this would then only affect
the process in which I set it.  So it might be worth seeing if you can
do that (or something equivalent) for the process that runs configure &&
make for you.

If that *does* work ... perhaps we should hack this into our Makefiles,

	Eddy.


From soroush.rabiei at gmail.com  Mon Jan 30 11:04:30 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Mon, 30 Jan 2017 13:34:30 +0330
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
References: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
Message-ID: <CAOMsk2QuvktnJEqBUr2s+HFR+TJsxy5ZCP8QL-Ec4u3K8SW2eA@mail.gmail.com>

> Now question is that: witch form is preferred? Will be case (1) break Qt
> rules?

I don't know about QML and it'd design principles, but I like option
3. Though it must take that calendar instance as second argument I
suppose:

    var out = date.toString("yyyy/MM/dd", Qt.JalaliCalendar); // Is
this possible?

Speaking of the API, I wish to share an idea about not to put calendar
implementations in a plugin subsystem.

There are differences between those concepts that are implemented as
plugins and calendars. A calendar system is not an image format nor a
database implementation. There will be no new calendar (at least, it's
unlikely to have a brand new calendar) and there will be no newer
versions of existing calendars. What is the point of having calendars
as plugins? And we have to keep QGregorianCalendar everywhere after
all... And we will have the problem of instantiation. While plugins
have no public header, then how we are supposed to use them in code?
Like this:

    QDate d;
    d.setDate(y,m,d,QCalendar::fromName("jalali"));

Or maybe:

    d.setDate(y,m,d,"jalali");


Let's add all calendar systems that do have locale information in
CLDR, and make all of them configurable as to be built or not, except
QGregorianCalendar. Then decide on a default subset of calendars to be
compiled into qtbase. That will be something like:

+----+-----------------+--------------------+------------+--------+
|No. |Name             |Variant             |Configurable|Default |
+----+-----------------+--------------------+------------+--------+
|1   |Gregorian        |                    |No          |Yes     |
+----+-----------------+--------------------+------------+--------+
|2   |Islamic          |Astronomical        |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|3   |Islamic          |Civil (Algorithmic) |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|4   |Persian          |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|5   |Hebrew           |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|6   |Chinese          |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|7   |Japanese         |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|8   |Buddhist         |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|9   |Republic of China|                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|10  |Coptic           |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|11  |Ethiopic         |Amete Alem          |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|12  |Ethiopic         |Amete Mihret        |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|13  |Indian           |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+

For historical calendars, Qt users are unlikely to add marginal
calendar systems -> A reason to avoid plugin system. Though having
current schema, they can subclass QAbstractCalendar and add their
calendar (not as a loadable plugin) in their own code.


From viktor.engelmann at qt.io  Mon Jan 30 11:09:54 2017
From: viktor.engelmann at qt.io (Viktor Engelmann)
Date: Mon, 30 Jan 2017 11:09:54 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <20170129093339.GA15723@klara.mpi.htwm.de>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
Message-ID: <0ea48aa4-2994-8111-eeba-dfe1f0edc3a6@qt.io>

I have a unit test for webengine that sends an HTTP Post request
which includes several unicode characters (outside of ä,ö,ü or other
Latin1 characters). I deliberately did that to make the test harder
to pass.


Am 29.01.2017 um 10:33 schrieb André Pönitz:
> On Sun, Jan 29, 2017 at 12:13:48PM +0800, Liang Jian wrote:
>>     Start from qt-5.8 I can't build qt anymore under Windows(simplified
>> chinese locale). Since there is a file
>> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1
>> character, msvc2015 assume the source code's character set should be CP936
>> which make the complilation fail.
>>     I can only build qt by comment the line which contain the specical
>> character in src/plugins/generic/tuiotouch/qtuiohandler.cpp.
>>     But if I turn on -developer-build in configuration step, thing will get
>> worse than before, since -developer-build means treat warning as error, and
>> again I can't build qt anymore since there are other files contain
>> non-latin1 character (such as qstring.cpp), the build will fail due to the
>> character set warning.
>>     I am working on a Windows 10 x64 simplifed chinese machine, msvc2015
>> update3
>>     For more detail please refer to
>> https://bugreports.qt.io/browse/QTBUG-58161
>>
>>     As a workaround, I have to modify the file
>> qtbase/mkspecs/common/msvc-desktop.conf
>> QMAKE_CFLAGS            = -nologo -Zc:wchar_t /utf-8
>>     After I add /utf-8 compiler option the build goes well.
>>     Shall we turn on this compiler option by default?
> We should remove non-ASCII characters from the sources if they cause problems.
>
> If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
> on all supported compilers, that's fine to have, but mining log messages
> or comments with characters that are known to cause issues in the processing
> are a mindless waste of resources.
>
> Andre'
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



From robin.burchell at crimson.no  Mon Jan 30 11:20:47 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Mon, 30 Jan 2017 11:20:47 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
References: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
Message-ID: <1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com>

On Mon, Jan 30, 2017, at 08:59 AM, Hamed Masafi wrote:
> I'm working on qml support of calendar system,
> for porting this mechanism to qml we have two option:

Have you considered whether Date.prototype.toLocaleDateString could be
of use for this? See:
http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring

Disclaimer: I'm not intimately familiar with this API, but stumbled
across it while looking into other possible alternatives for this
problem.

-- 
  Robin Burchell
  robin at crimson.no


From ulf.hermann at qt.io  Mon Jan 30 11:23:34 2017
From: ulf.hermann at qt.io (Ulf Hermann)
Date: Mon, 30 Jan 2017 11:23:34 +0100
Subject: [Development] Improve performance (listview +
 onVerticalVelocityChanged)
In-Reply-To: <CAF80AFZcwyWoWJGBVose1NQRcbfsDqNQ8p_W=+8_pLivcH65Aw@mail.gmail.com>
References: <CAF80AFbc6aBPBCLRzOtJpy5DqzF4j+troitFpH_0oZsEvRV2ig@mail.gmail.com>
	<CAF80AFZcwyWoWJGBVose1NQRcbfsDqNQ8p_W=+8_pLivcH65Aw@mail.gmail.com>
Message-ID: <60c3dbee-bbc2-c427-e276-0c86bf997419@qt.io>

Am 26.01.2017 um 20:09 schrieb Bernhard B:
> I think I solved my problem. In case someone is interested, that's my 
> solution:

Can't you bind the "visible" properties to the velocity? Then it doesn't 
have to execute so much javascript and the code looks cleaner and more 
declarative. The bindings will still be executed on every change in 
velocity, but it's likely that they'll be better optimized:

Something {
id: backToTopButton
visible: listView.verticalVelocity < -flickTabBarThreshold
}

SomethingElse {
id: tabBar
visible: backToTopButton.visible
}

br,
Ulf


From viktor.engelmann at qt.io  Mon Jan 30 11:35:52 2017
From: viktor.engelmann at qt.io (Viktor Engelmann)
Date: Mon, 30 Jan 2017 11:35:52 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <5938704.sfqBRPjXeF@tjmaciei-mobl1>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
Message-ID: <40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>



Am 30.01.2017 um 02:21 schrieb Thiago Macieira:
> That's usually one of the problematic ones.
>
> Not on this file, though:
>
>     qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ 
> " << x << y << "∡" << angle <<
>
> That's easy to fix by using "\342\210\241" instead.

But that's just cheating - the UTF8 is still there, you only hide it...
Also, this way the UTF8 codes are hard-coded - if UTF8 is ever
deprecated or you want to write non-ASCII to a shell that doesn't
support UTF8, you'd have to change all these codes *manually*.
As far as I can see, all our codes *are* UTF-8 encoded (a least they
should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
2017!) instead of just telling the compiler the encoding we are using?

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B




From giuseppe.dangelo at kdab.com  Mon Jan 30 11:40:12 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Mon, 30 Jan 2017 11:40:12 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
Message-ID: <22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>

Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
> As far as I can see, all our codes *are* UTF-8 encoded (a least they
> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
> 2017!) instead of just telling the compiler the encoding we are using?

So *all* of our compilers happily support UTF-8 encoded sources?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/b5d9680a/attachment.bin>

From viktor.engelmann at qt.io  Mon Jan 30 12:06:19 2017
From: viktor.engelmann at qt.io (Viktor Engelmann)
Date: Mon, 30 Jan 2017 12:06:19 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
Message-ID: <cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>


Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B




From Simon.Hausmann at qt.io  Mon Jan 30 12:23:30 2017
From: Simon.Hausmann at qt.io (Simon, Hausmann)
Date: Mon, 30 Jan 2017 11:23:30 +0000
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>,
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
Message-ID: <VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>


Making a warning go away for compilers that we know support utf-8 may not come at the price of your life :)


I for one am all in favor of requiring just the Qt source code (not talking about customer code) to be encoded in a 24 year

old standard and add all the necessary flags to the compilers to make them understand it instead of producing a warning.


We practically support three different front-ends: GCC, clang and MSVC. All three - MSVC with the help of an option - can

grok UTF-8. Let's use it at least inside Qt :)


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Viktor Engelmann <viktor.engelmann at qt.io>
Sent: Monday, January 30, 2017 12:06:19 PM
To: development at qt-project.org
Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?


Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

--

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/40d2249d/attachment.html>

From viktor.engelmann at qt.io  Mon Jan 30 12:36:42 2017
From: viktor.engelmann at qt.io (Viktor Engelmann)
Date: Mon, 30 Jan 2017 12:36:42 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <16966e49-1265-2a1e-e7c2-07dc37b55d28@qt.io>



Am 30.01.2017 um 12:23 schrieb Simon, Hausmann:
>
>
> Making a warning go away for compilers that we know support utf-8 may
> not come at the price of your life :)
>
>
> I for one am all in favor of requiring just the Qt source code (not
> talking about customer code) to be encoded in a 24 year
>
> old standard and add all the necessary flags to the compilers to make
> them understand it instead of producing a warning.
>
>
> We practically support three different front-ends: GCC, clang and
> MSVC. All three - MSVC with the help of an option - can
>
> grok UTF-8. Let's use it at least inside Qt :)
>
>
> Simon
>

personally, I want
- every file in the world converted to UTF8
- every software made compatible to UTF8
- compatibility to any other encoding removed from every software
- everyone burned at stake for heresy who says that any other encoding
has ever existed

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/c0d553c5/attachment.html>

From annulen at yandex.ru  Mon Jan 30 12:41:47 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 30 Jan 2017 14:41:47 +0300
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <16966e49-1265-2a1e-e7c2-07dc37b55d28@qt.io>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<16966e49-1265-2a1e-e7c2-07dc37b55d28@qt.io>
Message-ID: <1571481485776507@web28h.yandex.ru>



30.01.2017, 14:37, "Viktor Engelmann" <viktor.engelmann at qt.io>:
> Am 30.01.2017 um 12:23 schrieb Simon, Hausmann:
>> Making a warning go away for compilers that we know support utf-8 may not come at the price of your life :)
>>
>> I for one am all in favor of requiring just the Qt source code (not talking about customer code) to be encoded in a 24 year
>>
>> old standard and add all the necessary flags to the compilers to make them understand it instead of producing a warning.
>>
>> We practically support three different front-ends: GCC, clang and MSVC. All three - MSVC with the help of an option - can
>>
>> grok UTF-8. Let's use it at least inside Qt :)
>>
>> Simon
>
> personally, I want
> - every file in the world converted to UTF8
> - every software made compatible to UTF8
> - compatibility to any other encoding removed from every software
> - everyone burned at stake for heresy who says that any other encoding has ever existed

... still UTF8 requires conversion into UTF16 to be used with most parts of Qt. Arrrgh.

>
> -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin


From annulen at yandex.ru  Mon Jan 30 12:43:22 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 30 Jan 2017 14:43:22 +0300
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>,
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <1582481485776602@web28h.yandex.ru>



30.01.2017, 14:24, "Simon, Hausmann" <simon.hausmann at qt.io>:
> Making a warning go away for compilers that we know support utf-8 may not come at the price of your life :)
>
> I for one am all in favor of requiring just the Qt source code (not talking about customer code) to be encoded in a 24 year
>
> old standard and add all the necessary flags to the compilers to make them understand it instead of producing a warning.
>
> We practically support three different front-ends: GCC, clang and MSVC. All three - MSVC with the help of an option - can

What about Intel? (IIRC they use EDG frontend, aren't they?)

>
> grok UTF-8. Let's use it at least inside Qt :)
>
> Simon
> ----------------------------------------
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Viktor Engelmann <viktor.engelmann at qt.io>
> Sent: Monday, January 30, 2017 12:06:19 PM
> To: development at qt-project.org
> Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
>
> Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
>> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>>> 2017!) instead of just telling the compiler the encoding we are using?
>> So *all* of our compilers happily support UTF-8 encoded sources?
>
> I wouldn't bet my life on that (especially not for windows!)
>
> --
>
> Viktor Engelmann
> Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
>
> Viktor.Engelmann at qt.io
> +49 151 26784521
>
> http://qt.io
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin
> Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin


From lars.knoll at qt.io  Mon Jan 30 12:45:56 2017
From: lars.knoll at qt.io (Lars, Knoll)
Date: Mon, 30 Jan 2017 11:45:56 +0000
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
Message-ID: <84B7C927-017D-4679-B7F7-84DC59E19A40@qt.io>


> On 30 Jan 2017, at 12:06, Viktor Engelmann <viktor.engelmann at qt.io> wrote:
> 
> 
> Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
>> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>>> 2017!) instead of just telling the compiler the encoding we are using?
>> So *all* of our compilers happily support UTF-8 encoded sources?
> 
> I wouldn't bet my life on that (especially not for windows!)

I think MSVC 2013 still doesn’t support utf8 as input encoding. But that compiler will get phased out at some point.

Cheers,
Lars



From lars.knoll at qt.io  Mon Jan 30 12:48:09 2017
From: lars.knoll at qt.io (Lars, Knoll)
Date: Mon, 30 Jan 2017 11:48:09 +0000
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <E206BE22-8685-4B4F-BB23-9571F8275921@qt.io>


On 30 Jan 2017, at 12:23, Simon, Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:


Making a warning go away for compilers that we know support utf-8 may not come at the price of your life :)

I for one am all in favor of requiring just the Qt source code (not talking about customer code) to be encoded in a 24 year
old standard and add all the necessary flags to the compilers to make them understand it instead of producing a warning.

We practically support three different front-ends: GCC, clang and MSVC. All three - MSVC with the help of an option - can
grok UTF-8. Let's use it at least inside Qt :)

+1. Let’s enable it.

Btw, this had actually been planned for Qt 5.0. Unfortunately we couldn’t implement it back then, as MSVC was not allowing us to set the input encoding to utf8.

Cheers,
Lars


Simon
________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Viktor Engelmann <viktor.engelmann at qt.io<mailto:viktor.engelmann at qt.io>>
Sent: Monday, January 30, 2017 12:06:19 PM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?


Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

--

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io<mailto:Viktor.Engelmann at qt.io>
+49 151 26784521

http://qt.io<http://qt.io/>
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/375ce754/attachment.html>

From tor.arne.vestbo at qt.io  Mon Jan 30 12:54:44 2017
From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=)
Date: Mon, 30 Jan 2017 12:54:44 +0100
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170125111329.GH20252@troll08>
	<HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170126115151.GD3289@troll08>
	<AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>
Message-ID: <666e03d8-8be7-e78f-b29e-10dff6af98ee@qt.io>


On 26/01/2017 13:28, Kai Koehne wrote:
> So, any strong opinion against enforcing a [ChangeLog] line, with
> "[ChangeLog] -" for commits that don't need one?

Yes. Absolutely not. This will just reverse the problem, creating noise 
in the commits and lots of useless ChangeLog entries, we might as well 
use git log directly.

tor arne


From tor.arne.vestbo at qt.io  Mon Jan 30 12:54:44 2017
From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=)
Date: Mon, 30 Jan 2017 12:54:44 +0100
Subject: [Development] [Releasing] Change file process & improvement
 proposal
In-Reply-To: <AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>
References: <AM5PR0202MB2515C2C7A31443134681A33D9DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<AM5PR0202MB2515791CD26B93EE01DE78979DB80@AM5PR0202MB2515.eurprd02.prod.outlook.com>
	<20161110142306.GC9877@troll08>
	<AMSPR02MB152F5C1074E155D98B29B3E98750@AMSPR02MB152.eurprd02.prod.outlook.com>
	<HE1PR0202MB2683F8EFC6E73129730BE03087750@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170124152033.GE20252@troll08>
	<HE1PR0202MB2683911DF15BF08416BC753987740@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170125111329.GH20252@troll08>
	<HE1PR0202MB26839BE25390FD7D7345232887770@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<20170126115151.GD3289@troll08>
	<AMSPR02MB152859A3CB8252D51FCC7FD98770@AMSPR02MB152.eurprd02.prod.outlook.com>
Message-ID: <666e03d8-8be7-e78f-b29e-10dff6af98ee@qt.io>


On 26/01/2017 13:28, Kai Koehne wrote:
> So, any strong opinion against enforcing a [ChangeLog] line, with
> "[ChangeLog] -" for commits that don't need one?

Yes. Absolutely not. This will just reverse the problem, creating noise 
in the commits and lots of useless ChangeLog entries, we might as well 
use git log directly.

tor arne



From soroush.rabiei at gmail.com  Mon Jan 30 13:13:30 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Mon, 30 Jan 2017 15:43:30 +0330
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
Message-ID: <CAOMsk2Qa8r1JTjrynF2ZUEAX_EbRMUB=7N5h750d_-X3kiYMNw@mail.gmail.com>

Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's
not much to do. Either we implement calendars as factory classes
operating on QDate, or adding to QDate's API, there is not much work
left to do.


From frederik.gladhorn at qt.io  Mon Jan 30 13:45:49 2017
From: frederik.gladhorn at qt.io (Frederik Gladhorn)
Date: Mon, 30 Jan 2017 13:45:49 +0100
Subject: [Development] Branch request for Qt 3D
In-Reply-To: <2897263.8yd7yXIFgB@titan>
References: <2897263.8yd7yXIFgB@titan>
Message-ID: <1908151.Oz97rNEoN0@frederik-thinkcentre-m93p>

On torsdag 26. januar 2017 14.11.33 CET Sean Harmer wrote:
> Hi,
> 
> Could somebody create me a new wip/physics branch for the Qt 3D branched off
> of dev please? This is to start preparing a physics aspect hopefully for Qt
> 5.10.

Looks like this has been done, the branch is there.

Cheers,
Frederik


> 
> The existing wip/animation and wip/qtquickintegration branches should be
> going away shortly to keep things under control.
> 
> Thanks in advance,
> 
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From sean.harmer at kdab.com  Mon Jan 30 13:49:40 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 30 Jan 2017 12:49:40 +0000
Subject: [Development] Branch request for Qt 3D
In-Reply-To: <1908151.Oz97rNEoN0@frederik-thinkcentre-m93p>
References: <2897263.8yd7yXIFgB@titan>
	<1908151.Oz97rNEoN0@frederik-thinkcentre-m93p>
Message-ID: <4979845.i06TdYO4P3@cartman>

On Monday 30 January 2017 13:45:49 Frederik Gladhorn wrote:
> On torsdag 26. januar 2017 14.11.33 CET Sean Harmer wrote:
> > Hi,
> > 
> > Could somebody create me a new wip/physics branch for the Qt 3D branched
> > off of dev please? This is to start preparing a physics aspect hopefully
> > for Qt 5.10.
> 
> Looks like this has been done, the branch is there.

Yes, thanks. Ossi did it on Friday.

Cheers,

Sean



From thiago.macieira at intel.com  Mon Jan 30 17:29:08 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:29:08 -0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <201701300942.05911.marc.mutz@kdab.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<201701300942.05911.marc.mutz@kdab.com>
Message-ID: <2214936.MNRte6C32M@tjmaciei-mobl1>

On segunda-feira, 30 de janeiro de 2017 09:42:05 PST Marc Mutz wrote:
>   // ∡

Better:  // U++2221 MEASURED ANGLE

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



From thiago.macieira at intel.com  Mon Jan 30 17:30:49 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:30:49 -0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <79af8d51-4137-8c1d-f903-19d0ff985aa1@kdab.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<79af8d51-4137-8c1d-f903-19d0ff985aa1@kdab.com>
Message-ID: <17777359.jmSXjxjUd5@tjmaciei-mobl1>

On segunda-feira, 30 de janeiro de 2017 09:56:46 PST Giuseppe D'Angelo wrote:
> Il 30/01/2017 02:21, Thiago Macieira ha scritto:
> > So, we should:
> >  a) still avoid non-ASCII in our source files, aside from comments
> >  b) allow non-ASCII in comments, as needed
> 
> Didn't we have issues with UTF-8 in comments too, when using MSVC?

Yes, which means that if it chokes on KDAB's name in qglobal.h, too bad.

> >  c) turn the -utf-8 option on for MSVC2015U3.
> 
> But just for Qt own build, not push this option onto the users. Also,
> does this fix anything? Is MSVC 2015 U3 the only one complaining, and we
> can live with UTF-8 in the source when using other compilers?

This will affect the Qt build only. Only MSVC 2015 U3 gets the fix, the older 
versions and MSVC 2013 will still be affected.

Sorry, tough luck for the others.

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



From thiago.macieira at intel.com  Mon Jan 30 17:32:50 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:32:50 -0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <1582481485776602@web28h.yandex.ru>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<1582481485776602@web28h.yandex.ru>
Message-ID: <2044329.rGcy5TJXY3@tjmaciei-mobl1>

On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev wrote:
> What about Intel? (IIRC they use EDG frontend, aren't they?)

icc on Mac and Windows operates like GCC and Clang.

I'll check icl.exe on Windows. It is supposed to operate like MSVC, but it 
might have some other options or have never complained.

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



From thiago.macieira at intel.com  Mon Jan 30 17:35:44 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:35:44 -0800
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <HE1PR0202MB2683446D52AA0662F5FF4884874B0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<HE1PR0202MB2683446D52AA0662F5FF4884874B0@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <1584099.cTbc79kfUN@tjmaciei-mobl1>

On segunda-feira, 30 de janeiro de 2017 09:58:30 PST Edward, Welbourne wrote:
> I'm not sure how that works on MS-Windows, but I'd just set
> LANG=en.UTF-8 in my environment on any Unix; this would then only affect
> the process in which I set it.  So it might be worth seeing if you can
> do that (or something equivalent) for the process that runs configure &&
> make for you.

It's not always possible. Changing the system language on Windows is possible, 
but it's not always available (not always free), applies to all processes and 
I wouldn't be surprised if it required a reboot.

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



From thiago.macieira at intel.com  Mon Jan 30 17:37:42 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:37:42 -0800
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2Qa8r1JTjrynF2ZUEAX_EbRMUB=7N5h750d_-X3kiYMNw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2Qa8r1JTjrynF2ZUEAX_EbRMUB=7N5h750d_-X3kiYMNw@mail.gmail.com>
Message-ID: <12368628.XfrxSSNARZ@tjmaciei-mobl1>

On segunda-feira, 30 de janeiro de 2017 15:43:30 PST Soroush Rabiei wrote:
> Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's
> not much to do. Either we implement calendars as factory classes
> operating on QDate, or adding to QDate's API, there is not much work
> left to do.

I'll review your change proposal to QDate, but don't hold your hopes up that 
it'll pass in time for the feature freeze.

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



From thiago.macieira at intel.com  Mon Jan 30 17:57:24 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 30 Jan 2017 08:57:24 -0800
Subject: [Development] [Interest] Printer-specific options in Qt5's
 print dialog (Linux, CUPS)
In-Reply-To: <de0a6890b5d7d5b5d5adc1e2b1065593@posteo.de>
References: <de0a6890b5d7d5b5d5adc1e2b1065593@posteo.de>
Message-ID: <3899068.oCfgoQ7oib@tjmaciei-mobl1>

Resending this to the development mailing list.

Others: please read Michael's email below.

On segunda-feira, 30 de janeiro de 2017 14:12:32 PST you wrote:
> Hi,
> 
> in September 2015, I asked about the status of printer-specific options
> in the Qt 5 print dialog on Linux (with CUPS as printing system), s.
> thread at [1].
> 
> As John Layt explained, a rework of the print dialog had started for Qt
> 5 but could not be finished until then. The implementation for
> printer-specific options had been rather broken in Qt 4 and was removed
> for Qt 5, with the plan to reimplement them as part of a new printing
> system. John explained that unfortunately, work on the new printing
> system could not be continued then due to lack of time and money. As far
> as I can see, the situation now is still mostly the same.
> 
> As printer-specific options (like e.g. selecting a particular input
> tray, setting a PIN for a confidential print job, punching, creating a
> booklet, ...) are quite an important feature for us (City of Munich), we
> are currently evaluating different options for how to continue. One
> option is to implement that functionality ourselves or have a contractor
> implement it for us.
> 
> We would very much like this feature to be available upstream so that
> everybody can benefit from it and we do not have to maintain it in our
> own "fork" of Qt.
> 
> Before we make any further plans, I wanted to ask about the Qt project's
> current plan for the print dialog.
> 
> While I am very grateful for the links John has given about the new
> print system back then, some points are still a bit vague to me and I
> currently do not know what the next concrete steps in the implementation
> of the new print system would be to get closer to the desired goal. (Any
> further information on that is welcome.)
> 
> Back then, John had written that various new features need to be
> implemented for the new Qt print system and a temporary solution based
> on the current code might be a better approach at first. In case no
> activities are currently planned on Qt's side, our current technical
> approach would probably be to implement the feature based on the current
> 
> code base and make an implementation similar to what John wrote in [2]:
> > Given the dependency tree of new features required to reach the end
> > point, a temporary implementation might be a better bet than waiting
> > for the new print system, i.e. reimplement the old extra page but
> > smarter. The main problem with the old page was it duplicated settings
> > from the main dialog, and hid the fact you could actually edit the
> > values. The UX I had in mind for Qt4 was to choose all the features
> > that could be supported directly in the main dialog and add them
> > there, then filter those out in the extra page in a generic editing
> > view. It would require a lot of work around parsing PPD's and matching
> > option codes to existing ui, but it's doable.
> 
> I would be very grateful for any further information on the topic,
> particularly on the following questions:
> 
> 1) Are there (concrete) plans for the next steps considering the Qt
> print dialog?
> 2) Is the Qt project interested in us working together with them to get
> the feature implemented upstream?
> 3) Is a temporary implementation as described above considered as a good
> approach for now?
> 4) Are there other people/organisations that have the same problem? Do
> you have approaches to deal with that?
> 
> Possibly, Qt's development mailing list might be a better place when it
> comes to more details about a a possible implementation, but I wanted to
> start here where the discussion took place in 2015.
> 
> Regards,
> Michael
> 
> PS: Besides the implementation of printer-specific options, there are a
> few other things in the Qt 5 print dialog that we would like to address,
> but that will be done separately.
> 
> 
> [1]
> http://lists.qt-project.org/pipermail/interest/2015-September/thread.html#18
> 692 [2]
> http://lists.qt-project.org/pipermail/interest/2015-September/018700.html
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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



From apoenitz at t-online.de  Mon Jan 30 18:29:05 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Mon, 30 Jan 2017 18:29:05 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <5938704.sfqBRPjXeF@tjmaciei-mobl1>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
Message-ID: <20170130172905.GA1702@klara.mpi.htwm.de>

On Sun, Jan 29, 2017 at 05:21:57PM -0800, Thiago Macieira wrote:
> On domingo, 29 de janeiro de 2017 10:33:39 PST André Pönitz wrote:
> > We should remove non-ASCII characters from the sources if they cause
> > problems.
> 
> We've had this discussion. One of our largest contributors has a full legal 
> name that doesn't fit in ASCII.
> 
> 	Klarälvdalens Datakonsult AB

That's the very reason why I wrote:
 
> > If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
> > on all supported compilers, that's fine to have
> 
> That's usually one of the problematic ones.

Not in the case here, and not in the other case attempting to fix build
problems recently, namely https://codereview.qt-project.org/#/c/173622/
which is, by the way, *still* in a state inconsistent with the project
governance rules.
 
> Not on this file, though:
> 
>     qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ 
> " << x << y << "∡" << angle <<
> 
> That's easy to fix by using "\342\210\241" instead.

The fix I would use is something like

     qCDebug(lcTuioSet) << "Processing SET for token " << classId << id
        << " @ " << x << y << "angle:" << angle << ...

There is no need to use non-ASCII here at all. "\nnn" is fine in case
where \nnn is *really* needed, e.g. some auto tests.

> So, we should:
>  a) still avoid non-ASCII in our source files, aside from comments

Yes.

>  b) allow non-ASCII in comments, as needed

If *really* needed, or proven to be no problem in practice.

The mentioning of "Klarälvdalens" is a red herring in predecessors of
this discussion.  The 'ä' in the comments is not a problem in the two
controversial changes.  *If* it turns out to be a problem elsewhere,
which I don't expect, there needs to be an explanation why a transcription
of "ä" can be considered a more severe "legal issue" than the "legal
issue" originating from transcribing "©" as "(C)" in the same line. 

>  c) turn the -utf-8 option on for MSVC2015U3.

Yes.

Andre'


From apoenitz at t-online.de  Mon Jan 30 18:41:54 2017
From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=)
Date: Mon, 30 Jan 2017 18:41:54 +0100
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io>
	<22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com>
	<cc074548-1e8f-0ec8-7a1a-c4df72ed1937@qt.io>
	<VI1PR02MB1006520740FF57A1C6D619268C4B0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <20170130174154.GB1702@klara.mpi.htwm.de>

On Mon, Jan 30, 2017 at 11:23:30AM +0000, Simon, Hausmann wrote:
> We practically support three different front-ends: GCC, clang and
> MSVC. All three - MSVC with the help of an option - can
> grok UTF-8. Let's use it at least inside Qt :)

Qt source is handled by a variety of tools, not only compilers.

Nowadays they kind of all kind of always support kind of UTF-8, yeah, so
use it, if it works. Fine.

But I absolutely don't get the point of trying to run with my head into
a wall because I know there is a door in the wall on the construction
drawing in this place, even if my eyes tell me it's a couple of feet to
the left.

Andre'


From marc.mutz at kdab.com  Mon Jan 30 20:03:24 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Mon, 30 Jan 2017 20:03:24 +0100
Subject: [Development] Feature Freeze Exception: QStringView
Message-ID: <201701302003.25214.marc.mutz@kdab.com>

Hi,

QStringView is ready to be merged, but the maintainer has asked for another 
week before he can properly review the class.

In case you don't remember, here's the discussion thread from 2015: 
http://lists.qt-project.org/pipermail/development/2015-October/023358.html

Here's the evolving patch series:
https://codereview.qt-
project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z

I feel the patch addresses all concerns raised in the discussion:

1. size_type: we agreed on on ssize_t equivalent to strike a balance between
   the Qt preference of 32-bit signed types over the STL preference for 64-bit
   unsigned types.
2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
   without deeply-routed support in QString would be a still-born. We also
   don't have time come Qt 6 to port all of Qt to a QStringView developed
   elsewhere. The current patches just scratch the surface. Everywhere
   QStringRef is currently used, QStringView can be used. And a lot of places
   that traditionally only took QString should take QStringView, too, e.g.
   QFile::encodeName(). So I added it to Qt.
3. Keeping existing QString overloads for implicit sharing.
   The patch does not remove anything. It will, as it progresses, implement
   QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
   overloads (2: only where the function read from the string, 3: also where
   it stores the string), so that at some later point in time we can just flip
   a preprocessor switch and compare executable size and execution speed of
   both sets of overloads, everything else being equal.

So, in order to give the maintainers more time for review, I'd like to ask for 
a feature freeze extension for QStringView until end of next week, plus a few 
days to deal with maintainer review comments.

Why should it be granted? Because QStringView is by far the biggest revolution 
in Qt since 5.0, all the while integrating naturally and step-by-step into 
existing code, _tremendously_ simplifying it along the way (cf. the commits 
that start to make use of QStringView: https://codereview.qt-
project.org/183864 https://codereview.qt-project.org/183925), esp. where, in 
private API, we can already remove the other overloads.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From mwoehlke.floss at gmail.com  Mon Jan 30 20:42:57 2017
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Mon, 30 Jan 2017 14:42:57 -0500
Subject: [Development] Shall we turn on /utf-8 compiler option when
 build qt for Windows?
In-Reply-To: <20170130172905.GA1702@klara.mpi.htwm.de>
References: <CAFo+GDX3bw1x30SEz5t-UFcLk6ht8V62gkn890A8127cv_FGSQ@mail.gmail.com>
	<20170129093339.GA15723@klara.mpi.htwm.de>
	<5938704.sfqBRPjXeF@tjmaciei-mobl1>
	<20170130172905.GA1702@klara.mpi.htwm.de>
Message-ID: <588F9741.1000606@gmail.com>

On 2017-01-30 12:29, André Pönitz wrote:
> *If* it turns out to be a problem elsewhere, which I don't expect,
> there needs to be an explanation why a transcription of "ä" can be
> considered a more severe "legal issue" than the "legal issue"
> originating from transcribing "©" as "(C)" in the same line.

Well, since (fortunately) those lines seem to start with "Copyright", a
"©" would be redundant, so for that case there is no issue. (Really, all
those "(C)"s ought to just be removed.)

-- 
Matthew


From hamed.masafi at gmail.com  Mon Jan 30 21:07:48 2017
From: hamed.masafi at gmail.com (Hamed Masafi)
Date: Mon, 30 Jan 2017 20:07:48 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com>
References: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
	<1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com>
Message-ID: <CAEJBZd11PG65oM0PRFZk0o15AFxpBz-LTxu4tFzffHd0Lg99Hg@mail.gmail.com>

> That shall complement Soroush Rabiei's work on the C++ side:
Yes, that's right. I'm trying to port Soroush's calendar mechanism to qml
side of Qt.

> If I understand Lars correctly, he prefers an API where the calendar
> object carries methods that act on a date and any further arguments it
> may need (similar to QLocale), so cal.toString(date, "yyyy-MM-dd") is
> more likely (although I personally like the style of API you give above,
> where the date object has the calendar-aware methods; too many of the
> details are the same between calendar systems).  Aside from that, this
> is roughly the shape the C++ API shall have, making it a natural model
> for the QML to follow.
I'm not sure we can add an global type to script engine that are not in
ecma script.

> Not sure what you're proposing here - you don't mention Qt.calendar in
> the code example, which looks more like 1) with JalaliCalendar moved to
> the Qt object - which may indeed be a better place for it than as a
> naked global object.
No; in this case Qt.JalaliCalendar is a QEnum and not an object (my
suggestion explained below)

> I don't know what rules QML might impose.  Each of these would, in one
> way or another, require the calendar system code to register itself in
> some way with QML, associated with the name by which QML is to refer to
> it.  The details of whether that name is in the namespace of some
> visible object (the ECMAScript global object or the Qt object) or in
> some internal mapping (for 2) are a matter of what's practical or
> convenient - someone with more QML fu than I can claim can advise you
> better there.
My prefer option is form (3)
We can add an enumeration to global space.
var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

> Have you considered whether Date.prototype.toLocaleDateString could be
> of use for this? See:
>
http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
Date.prototype.toLocaleDateString is used to converting date to a string
bases on a Locale. we can use this function for accepting an CalendarType
(CalendarType is a QEnum that contains list of calendar types like;
gregorian, jalali, hindi or etc)
date.toLocaleString(format);
date.toLocaleString(CalendarType, format);
date.toLocaleString(locale, format);
date.toLocaleString(CalendarType, locale, format);

But there are some bugs related to this prototype, We have to solve that
within this process.
https://bugreports.qt.io/browse/QTBUG-32492
https://bugreports.qt.io/browse/QTBUG-41712

> var out = date.toString("yyyy/MM/dd", Qt.JalaliCalendar); // Is
> this possible?
This is my choice too. And answer is "yes". This is possible. But for that
we must conclusion below paragraph [*]:

> There are differences between those concepts that are implemented as
> plugins and calendars. A calendar system is not an image format nor a
> database implementation. There will be no new calendar (at least, it's
> unlikely to have a brand new calendar) and there will be no newer
> versions of existing calendars. What is the point of having calendars
> as plugins? And we have to keep QGregorianCalendar everywhere after
> all... And we will have the problem of instantiation. While plugins
> have no public header, then how we are supposed to use them in code?
> Like this:
[*]: I'm agree with Soroush. Calendar system must bot be pluginable. Due
the facts that soroush said.

I think to continue we must conclusion on that calendar types must be
plugin or not?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/3375dc31/attachment.html>

From robin.burchell at crimson.no  Mon Jan 30 22:03:23 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Mon, 30 Jan 2017 22:03:23 +0100
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAEJBZd11PG65oM0PRFZk0o15AFxpBz-LTxu4tFzffHd0Lg99Hg@mail.gmail.com>
References: <CAEJBZd1kZidUA6PBAjaQUYPM-Xk+haypo5YKJmpD5rCM1xn1fQ@mail.gmail.com>
	<1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com>
	<CAEJBZd11PG65oM0PRFZk0o15AFxpBz-LTxu4tFzffHd0Lg99Hg@mail.gmail.com>
Message-ID: <1485810203.2838450.864653776.00F11FBC@webmail.messagingengine.com>

On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
> My prefer option is form (3)
> We can add an enumeration to global space.
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

I would prefer to not modify standard APIs if we can avoid it (unless we
have a good reason to do so and such a change is pretty low risk).
Keeping close to the rest of the JS ecosystem means that skills learned
in one place are easily translated to another (meaning less
QJSEngine-specific knowledge and docs are required). In the particular
case of Date.prototype.toString(), it also means that should any future
specification start supporting additional arguments there, we aren't
going to open ourselves up to future unexpected problems.

> > Have you considered whether Date.prototype.toLocaleDateString could be
> > of use for this? See:
> >
> http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
> Date.prototype.toLocaleDateString is used to converting date to a string
> bases on a Locale. we can use this function for accepting an CalendarType
> (CalendarType is a QEnum that contains list of calendar types like;
> gregorian, jalali, hindi or etc)
> date.toLocaleString(format);
> date.toLocaleString(CalendarType, format);
> date.toLocaleString(locale, format);
> date.toLocaleString(CalendarType, locale, format);

Right, if you look at the spec I linked you to, that's what it
specifies- converting a date to a string in a locale-specific way. They
don't use an enum, but a string to describe the calendar system (plus
some additional options to control the formatting result in an
additional optional parameter). I can admit the spec is a bit hard to
read. Here's a slightly less formal description, with some examples:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString

If you want to see it in action, in a browser, try something like this
in a web browser JS console:

    console.log(new Date().toLocaleDateString("ar-EG"))

I see:

    ٣٠‏/١‏/٢٠١٧

Which I hope is something useful/meaningful, I'm unfortunately not
familiar enough with that locale to tell. I've confirmed this to work in
recent releases of Safari, Firefox and Chrome on OS X. Outside of
browsers, YMMV. I didn't get Nodejs to respect the locale options, for
instance.

What we implement now is nothing close to this (in fact, we simply
ignore all arguments and return the argument using local formatting) -
my guess is that it is down to most of this being added after ES5.

> But there are some bugs related to this prototype, We have to solve that
> within this process.

As I said, as it stands, our implementation is currently not doing what
you need - it would need to be fleshed out to actually use the provided
arguments. However, I think that extending this seems to be a pretty
good match for the functionality you are wanting to add?

-- 
  Robin Burchell
  robin at crimson.no


From andy.shaw at qt.io  Tue Jan 31 08:04:31 2017
From: andy.shaw at qt.io (Andrew, Shaw)
Date: Tue, 31 Jan 2017 07:04:31 +0000
Subject: [Development] [Interest] Printer-specific options in Qt5's
 print dialog (Linux, CUPS)
In-Reply-To: <3899068.oCfgoQ7oib@tjmaciei-mobl1>
References: <de0a6890b5d7d5b5d5adc1e2b1065593@posteo.de>
	<3899068.oCfgoQ7oib@tjmaciei-mobl1>
Message-ID: <6025AF62-E52E-4AF6-A263-AD5E712FA25E@qt.io>



Development på vegne av Thiago Macieira <development-bounces+andy.shaw=qt.io at qt-project.org på vegne av thiago.macieira at intel.com> skrev følgende den 30.01.2017, 17.57:

    Resending this to the development mailing list.
    
    Others: please read Michael's email below.
    
    On segunda-feira, 30 de janeiro de 2017 14:12:32 PST you wrote:
    > Hi,
    > 
    > in September 2015, I asked about the status of printer-specific options
    > in the Qt 5 print dialog on Linux (with CUPS as printing system), s.
    > thread at [1].
    > 
    > As John Layt explained, a rework of the print dialog had started for Qt
    > 5 but could not be finished until then. The implementation for
    > printer-specific options had been rather broken in Qt 4 and was removed
    > for Qt 5, with the plan to reimplement them as part of a new printing
    > system. John explained that unfortunately, work on the new printing
    > system could not be continued then due to lack of time and money. As far
    > as I can see, the situation now is still mostly the same.
    
Unfortunately it would seem that John is no longer working on the printing system in Qt, so little has been done on it lately, though there are some of us doing changes to it still but they are mainly fixes and not actual features.

    > As printer-specific options (like e.g. selecting a particular input
    > tray, setting a PIN for a confidential print job, punching, creating a
    > booklet, ...) are quite an important feature for us (City of Munich), we
    > are currently evaluating different options for how to continue. One
    > option is to implement that functionality ourselves or have a contractor
    > implement it for us.
    > 
    > We would very much like this feature to be available upstream so that
    > everybody can benefit from it and we do not have to maintain it in our
    > own "fork" of Qt.
    > 
    > Before we make any further plans, I wanted to ask about the Qt project's
    > current plan for the print dialog.
    > 
    > While I am very grateful for the links John has given about the new
    > print system back then, some points are still a bit vague to me and I
    > currently do not know what the next concrete steps in the implementation
    > of the new print system would be to get closer to the desired goal. (Any
    > further information on that is welcome.)
    > 
    > Back then, John had written that various new features need to be
    > implemented for the new Qt print system and a temporary solution based
    > on the current code might be a better approach at first. In case no
    > activities are currently planned on Qt's side, our current technical
    > approach would probably be to implement the feature based on the current
    > 
    > code base and make an implementation similar to what John wrote in [2]:
    > > Given the dependency tree of new features required to reach the end
    > > point, a temporary implementation might be a better bet than waiting
    > > for the new print system, i.e. reimplement the old extra page but
    > > smarter. The main problem with the old page was it duplicated settings
    > > from the main dialog, and hid the fact you could actually edit the
    > > values. The UX I had in mind for Qt4 was to choose all the features
    > > that could be supported directly in the main dialog and add them
    > > there, then filter those out in the extra page in a generic editing
    > > view. It would require a lot of work around parsing PPD's and matching
    > > option codes to existing ui, but it's doable.
    > 
    > I would be very grateful for any further information on the topic,
    > particularly on the following questions:
    > 
    > 1) Are there (concrete) plans for the next steps considering the Qt
    > print dialog?

Currently there are none as, to my knowledge, no one is working on the print dialog specifically.

    > 2) Is the Qt project interested in us working together with them to get
    > the feature implemented upstream?

I would be willing to look at the changes and review them, I am sure there are others out there too who would be willing too.

    > 3) Is a temporary implementation as described above considered as a good
    > approach for now?

To be honest I am not entirely sure, I personally would be in favour of implementing it the right way the first time if it is going to go into Qt rather than having a stop-gap solution. There is nothing to gain I think from an intermediate solution, though if you are referring to doing it in your own code then it is probably ideal for the short-term.

    > 4) Are there other people/organisations that have the same problem? Do
    > you have approaches to deal with that?

Not to my knowledge, but that is not to say that there is no one out there.

    > Possibly, Qt's development mailing list might be a better place when it
    > comes to more details about a a possible implementation, but I wanted to
    > start here where the discussion took place in 2015.

Personally I would go ahead and submit what you have then we can at least look at the code and take anything further from there in that respect. As for the overall direction of the printing module this would probably be a good place to discuss that.

Andy


From m.weghorn at posteo.de  Tue Jan 31 09:55:01 2017
From: m.weghorn at posteo.de (Michael Weghorn)
Date: Tue, 31 Jan 2017 09:55:01 +0100
Subject: [Development] [Interest] Printer-specific options in Qt5's
 print dialog (Linux, CUPS)
In-Reply-To: <6025AF62-E52E-4AF6-A263-AD5E712FA25E@qt.io>
References: <de0a6890b5d7d5b5d5adc1e2b1065593@posteo.de>
	<3899068.oCfgoQ7oib@tjmaciei-mobl1>
	<6025AF62-E52E-4AF6-A263-AD5E712FA25E@qt.io>
Message-ID: <6a998402d6deb9fb2b8f505d9860b4af@posteo.de>

Thank you very much for your reply.

On 2017-01-31 08:04, Andrew, Shaw wrote:

> 
>     > 2) Is the Qt project interested in us working together with them 
> to get
>     > the feature implemented upstream?
> 
> I would be willing to look at the changes and review them, I am sure
> there are others out there too who would be willing too.

Thank you, that is great.

> 
>     > 3) Is a temporary implementation as described above considered as 
> a good
>     > approach for now?
> 
> To be honest I am not entirely sure, I personally would be in favour
> of implementing it the right way the first time if it is going to go
> into Qt rather than having a stop-gap solution. There is nothing to
> gain I think from an intermediate solution, though if you are
> referring to doing it in your own code then it is probably ideal for
> the short-term.

We are definitely also interested in doing it the right way and would 
very much like an implementation that is sustainable and fits into Qt's 
strategy and plans for the print module.
As I tried to describe in my previous email, my problem here is that I 
currently do not really know what would be the "right way" to do such an 
implementation. My current understanding of the desired future print 
system in Qt is still too vague to be able to estimate that 
appropriately. The links about the plans for the Qt print system that 
John provided in his email [1] give some kind of overview, but are 
currently not enough for me to deduce the concrete next steps that need 
to be taken for the implementation.

If you (or somebody else) can give more information on that, this is 
certainly something we would be happy about and that we will examine 
more closely.


> 
> Personally I would go ahead and submit what you have then we can at
> least look at the code and take anything further from there in that
> respect. As for the overall direction of the printing module this
> would probably be a good place to discuss that.

We currently don't have a finished implementation. In case you can give 
further hints on what a "desirable" implementation could look like, we 
would like to take that into account from the beginning. Otherwise, we 
(or a contractor) might possibly start working on an implementation 
similar to how it was done in Qt 4 (for now).

The old implementation used CUPS' PPD API which has been deprecated for 
a while [2]. So far, I could not really find out how to handle all 
printer-specific options using the recommended Job Ticket APIs instead, 
but I asked on CUPS' mailing list today and will try to use the "right" 
solution in that place from the beginning.


Michael

[1] 
http://lists.qt-project.org/pipermail/interest/2015-September/018700.html
[2] https://www.cups.org/doc/api-ppd.html
[3] http://lists.cups.org/pipermail/cups/2017-January/028192.html


From lars.knoll at qt.io  Tue Jan 31 10:08:35 2017
From: lars.knoll at qt.io (Lars, Knoll)
Date: Tue, 31 Jan 2017 09:08:35 +0000
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701302003.25214.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
Message-ID: <D33A4518-2821-4183-9295-CE69CC168290@qt.io>

Hi Marc,

The downside of any exceptions to the feature freeze (as we've seen before) is added risk to our schedules. We should use this sparingly (and I've been probably giving exceptions too often in the past).

> On 30 Jan 2017, at 20:03, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> QStringView is ready to be merged, but the maintainer has asked for another 
> week before he can properly review the class.
> 
> In case you don't remember, here's the discussion thread from 2015: 
> http://lists.qt-project.org/pipermail/development/2015-October/023358.html
> 
> Here's the evolving patch series:
> https://codereview.qt-
> project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z
> 
> I feel the patch addresses all concerns raised in the discussion:
> 
> 1. size_type: we agreed on on ssize_t equivalent to strike a balance between
>   the Qt preference of 32-bit signed types over the STL preference for 64-bit
>   unsigned types.
> 2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
>   without deeply-routed support in QString would be a still-born. We also
>   don't have time come Qt 6 to port all of Qt to a QStringView developed
>   elsewhere. The current patches just scratch the surface. Everywhere
>   QStringRef is currently used, QStringView can be used. And a lot of places
>   that traditionally only took QString should take QStringView, too, e.g.
>   QFile::encodeName(). So I added it to Qt.
> 3. Keeping existing QString overloads for implicit sharing.
>   The patch does not remove anything. It will, as it progresses, implement
>   QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
>   overloads (2: only where the function read from the string, 3: also where
>   it stores the string), so that at some later point in time we can just flip
>   a preprocessor switch and compare executable size and execution speed of
>   both sets of overloads, everything else being equal.
> 
> So, in order to give the maintainers more time for review, I'd like to ask for 
> a feature freeze extension for QStringView until end of next week, plus a few 
> days to deal with maintainer review comments.

I understand that you want to have the patch series finally merged. Actually I do as well, I believe that QStringView is the right approach moving forward.

But I do wonder about the approach here. The series has been around pretty much unchanged for quite some time now without anybody working on it. You had lots of time since summer to get this into shape an merged. Now, a week before the feature freeze and suddenly this absolutely has to go in? 

> Why should it be granted? Because QStringView is by far the biggest revolution 
> in Qt since 5.0, all the while integrating naturally and step-by-step into 
> existing code, _tremendously_ simplifying it along the way (cf. the commits 
> that start to make use of QStringView: https://codereview.qt-
> project.org/183864 https://codereview.qt-project.org/183925), esp. where, in 
> private API, we can already remove the other overloads.

I agree, that the series cleans things up and is a great improvement. But the biggest revolution since 5.0? It's an API addition that brings performance optimisations in Qt's string handling.

What would we really loose if we worked towards getting this into the dev branch in the next few weeks? We don't exactly have hundreds of users/customers who can't live without it. And pushing it into dev would give you lots of time to make sure we make best possible use of the class throughout all of Qt for 5.10.

Cheers,
Lars



From abbapoh at gmail.com  Tue Jan 31 10:55:52 2017
From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=)
Date: Tue, 31 Jan 2017 12:55:52 +0300
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701302003.25214.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
Message-ID: <CAES5P-W=fNfpkmsVJmnyRe2mabX3kqGpj_YzNi8h5me4K-OokQ@mail.gmail.com>

Great job!
What about QByteArrayView? Do you plan to use std::string_view instead?
What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
std::string_view::remove_prefix/suffix), find and other QString methods
that doesn't modify the string? Do you plan to add them later or support
only small subset of operations (similar to std::string_view?)
Or maybe i miss some commits?

2017-01-30 22:03 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> Hi,
>
> QStringView is ready to be merged, but the maintainer has asked for another
> week before he can properly review the class.
>
> In case you don't remember, here's the discussion thread from 2015:
> http://lists.qt-project.org/pipermail/development/2015-October/023358.html
>
> Here's the evolving patch series:
> https://codereview.qt-
> project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z
>
> I feel the patch addresses all concerns raised in the discussion:
>
> 1. size_type: we agreed on on ssize_t equivalent to strike a balance
> between
>    the Qt preference of 32-bit signed types over the STL preference for
> 64-bit
>    unsigned types.
> 2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
>    without deeply-routed support in QString would be a still-born. We also
>    don't have time come Qt 6 to port all of Qt to a QStringView developed
>    elsewhere. The current patches just scratch the surface. Everywhere
>    QStringRef is currently used, QStringView can be used. And a lot of
> places
>    that traditionally only took QString should take QStringView, too, e.g.
>    QFile::encodeName(). So I added it to Qt.
> 3. Keeping existing QString overloads for implicit sharing.
>    The patch does not remove anything. It will, as it progresses, implement
>    QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and
> QStringRef
>    overloads (2: only where the function read from the string, 3: also
> where
>    it stores the string), so that at some later point in time we can just
> flip
>    a preprocessor switch and compare executable size and execution speed of
>    both sets of overloads, everything else being equal.
>
> So, in order to give the maintainers more time for review, I'd like to ask
> for
> a feature freeze extension for QStringView until end of next week, plus a
> few
> days to deal with maintainer review comments.
>
> Why should it be granted? Because QStringView is by far the biggest
> revolution
> in Qt since 5.0, all the while integrating naturally and step-by-step into
> existing code, _tremendously_ simplifying it along the way (cf. the commits
> that start to make use of QStringView: https://codereview.qt-
> project.org/183864 https://codereview.qt-project.org/183925), esp. where,
> in
> private API, we can already remove the other overloads.
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170131/667eb5c9/attachment.html>

From marc.mutz at kdab.com  Tue Jan 31 12:07:52 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 31 Jan 2017 12:07:52 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <D33A4518-2821-4183-9295-CE69CC168290@qt.io>
References: <201701302003.25214.marc.mutz@kdab.com>
	<D33A4518-2821-4183-9295-CE69CC168290@qt.io>
Message-ID: <201701311207.52884.marc.mutz@kdab.com>

Hi Lars,

On Tuesday 31 January 2017 10:08:35 Lars, Knoll wrote:
[...]
> > So, in order to give the maintainers more time for review, I'd like to
> > ask for a feature freeze extension for QStringView until end of next
> > week, plus a few days to deal with maintainer review comments.
> 
> I understand that you want to have the patch series finally merged.
> Actually I do as well, I believe that QStringView is the right approach
> moving forward.
> 
> But I do wonder about the approach here. The series has been around pretty
> much unchanged for quite some time now without anybody working on it. You
> had lots of time since summer to get this into shape an merged. Now, a
> week before the feature freeze and suddenly this absolutely has to go in?

I have been sxcheduled to work on this in January, but was out with sick child 
and then myself afterwards for almost two weeks. That's why it's late.

Then again, as you say, the main patch has been around for the better part of 
a year, and the basic idea has been around since the beginning.

> > Why should it be granted? Because QStringView is by far the biggest
> > revolution in Qt since 5.0, all the while integrating naturally and
> > step-by-step into existing code, _tremendously_ simplifying it along the
> > way (cf. the commits that start to make use of QStringView:
> > https://codereview.qt-
> > project.org/183864 https://codereview.qt-project.org/183925), esp. where,
> > in private API, we can already remove the other overloads.
> 
> I agree, that the series cleans things up and is a great improvement. But
> the biggest revolution since 5.0? It's an API addition that brings
> performance optimisations in Qt's string handling.

No, this is not at all about performance. It's mostly about stream-lining the 
API, and adding flexibility:

1. Traditionally, a lot of stuff has been taking QString, and QString only. If
   you're lucky, you get (QChar*, int) on top, so you can use an automatic
   buffer to hold the string data, with all the ugliness at the
   call site that entails. QStringView takes all that pain and hides it
   (see https://codereview.qt-
project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified).
   It also allows for clearer interfaces, because instead of a QString and an
   int, you can just pass a QStringView, since creating a sub-view suddenly
   costs nothing:

2. QStringView gives the caller the choice of container for string data. This
   makes Qt much more interoperable with 3rd-party libraries. QStringView will
   make QStringLiteral all but obsolete, since you can now just pass u"string"
   or, on Windows, L"string" to any QStringView-taking function. We can
   trivially define a QStringViewLiteral that uses one of the other, depending
   on platform. I backed that feature out, though, since I fist need to verify
   that we support no compilers anymore that would fall back to fromUtf8() for
   QStringLiteral.

3. And yes, performance. Where today we have to return QString, even where we
   know a maximum size, and even where we don't:  It will allow
   QLocale::toString() to return something equivalent to char16_t[N], e.g.
   std::array, in order to not allocate memory just to format numbers,
   something that has so far eluded any practical solution. For internal
   functions that return temporary QStrings, we can switch to QVarLengthArray,
   and avoid heap allocations in common cases.

The last such fundamental change to QtBase was the possibility to connect 
signals to lambdas. Believe me, QStringView has the same caliber.

> What would we really loose if we worked towards getting this into the dev
> branch in the next few weeks? We don't exactly have hundreds of
> users/customers who can't live without it. And pushing it into dev would
> give you lots of time to make sure we make best possible use of the class
> throughout all of Qt for 5.10.

I have found that even with just relational operators, conversions, and 
iterators (ie. just the Long-live commit in the series), maybe 
QString::append() and QStirngBuilder integration, you can already do a lot of 
stuff. For us, getting QStringView into dev next week means one week of delay, 
but for our users, it means half a year delay. Qt is desperately in need of 
better integration with std C++, and QStringView is hand-down the largest such 
contribution. Not having it means people will continue to spend^Wwaste time 
porting stuff to QStringRef, which will later be replaced by QStringView. 
Don#t get me wrong, I love the work Anton and others have done in the area. I 
now just need to grep for QStringRef to find code to port to QStringView, but 
the real value of QStringView lies in where there was no QStringRef-overload 
in the first place, e.g. QColor: https://codereview.qt-project.org/184038

In the end, it's your call, of course.

I personally don't care whether it goes into 5.9 or 5.10, but for our users 
and for other contributors, I hope that it makes it into 5.9, since, judging 
from 5.8, a lot of internal performance improvements come into stable 
branches, and we really don't need more QStringRef uses in Qt. esp. in public 
API, where we need to carry it all the way to Qt 6.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From marc.mutz at kdab.com  Tue Jan 31 12:24:02 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 31 Jan 2017 12:24:02 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <CAES5P-W=fNfpkmsVJmnyRe2mabX3kqGpj_YzNi8h5me4K-OokQ@mail.gmail.com>
References: <201701302003.25214.marc.mutz@kdab.com>
	<CAES5P-W=fNfpkmsVJmnyRe2mabX3kqGpj_YzNi8h5me4K-OokQ@mail.gmail.com>
Message-ID: <201701311224.02465.marc.mutz@kdab.com>

On Tuesday 31 January 2017 10:55:52 Иван Комиссаров wrote:
> What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
> std::string_view::remove_prefix/suffix), find and other QString methods
> that doesn't modify the string? Do you plan to add them later or support
> only small subset of operations (similar to std::string_view?)
> Or maybe i miss some commits?

As I wrote multiple times before, the end game is that QStringView carries all 
of the const QString API, as much as is possible. Hopefully, that will be the 
state going into 5.10.0.

If it goes into 5.9, it will only provide a very limited subset, but even so 
it allows full use of the type in APIs since many parsing tasks quickly 
delegate to something working on QChar*, anyway.

ATM, I try to strike a balance between adding new functions and adding new 
users. Adding new functions is a lot of work, since I write comprehensive 
tests that test a function across all string-like classes in Qt and that tend 
to find bugs in other implementations, too, cf. QStringRef::toLatin1(). Adding 
new users is comparatively easy, and more rewarding work.

As for toInt() etc, they need QStringView support in QLocale, which is what 
I'm focusing on atm, with several patches already up on Gerrit. Stuff like 
toLower() has less priority, since toString().toLower() is just as efficient 
(non-shared QString returned invoking rvalue-overload of toLower(), reusing 
the internal buffer). But they will come, too, but I'm not sure about the 
form. They could return QString, of course, or they could take any container, 
toStdBasicString-style, so you could pass a QVarLengthArray or a static 
buffer.

> What about QByteArrayView? Do you plan to use std::string_view instead?

QByteArrayView will also come. Come Qt 6, QStringView, QLatin1String, 
QByteArrayView should all be represented by the same template. Until then, 
tst_qstringapisymmetry ensures equally-named functions have a subset of 
operations between them that behave identical (the views have stricter 
preconditions for some functions, thus "subset").

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From Andy.Nichols at qt.io  Tue Jan 31 12:47:03 2017
From: Andy.Nichols at qt.io (Andy, Nichols)
Date: Tue, 31 Jan 2017 11:47:03 +0000
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701311207.52884.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
	<D33A4518-2821-4183-9295-CE69CC168290@qt.io>
	<201701311207.52884.marc.mutz@kdab.com>
Message-ID: <DEA9B53B-BDB8-4146-8191-CACB67CB4D93@qt.io>

While QStringView looks like a nice addition to Qt, I don’t think we should risk delaying the next release over it.  It is bad enough there is always a rush to cram things in the week leading up to the release and even worse when we start talking about extensions.  If we are going to have time based releases we need to follow the rules, and accept that there is always another release.  It’s much better to integrate early and have time to work out the kinks, rather than integrate a feature at the last second.

> On 31 Jan 2017, at 12:07, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> Hi Lars,
> 
> On Tuesday 31 January 2017 10:08:35 Lars, Knoll wrote:
> [...]
>>> So, in order to give the maintainers more time for review, I'd like to
>>> ask for a feature freeze extension for QStringView until end of next
>>> week, plus a few days to deal with maintainer review comments.
>> 
>> I understand that you want to have the patch series finally merged.
>> Actually I do as well, I believe that QStringView is the right approach
>> moving forward.
>> 
>> But I do wonder about the approach here. The series has been around pretty
>> much unchanged for quite some time now without anybody working on it. You
>> had lots of time since summer to get this into shape an merged. Now, a
>> week before the feature freeze and suddenly this absolutely has to go in?
> 
> I have been sxcheduled to work on this in January, but was out with sick child 
> and then myself afterwards for almost two weeks. That's why it's late.
> 
> Then again, as you say, the main patch has been around for the better part of 
> a year, and the basic idea has been around since the beginning.
> 
>>> Why should it be granted? Because QStringView is by far the biggest
>>> revolution in Qt since 5.0, all the while integrating naturally and
>>> step-by-step into existing code, _tremendously_ simplifying it along the
>>> way (cf. the commits that start to make use of QStringView:
>>> https://codereview.qt-
>>> project.org/183864 https://codereview.qt-project.org/183925), esp. where,
>>> in private API, we can already remove the other overloads.
>> 
>> I agree, that the series cleans things up and is a great improvement. But
>> the biggest revolution since 5.0? It's an API addition that brings
>> performance optimisations in Qt's string handling.
> 
> No, this is not at all about performance. It's mostly about stream-lining the 
> API, and adding flexibility:
> 
> 1. Traditionally, a lot of stuff has been taking QString, and QString only. If
>   you're lucky, you get (QChar*, int) on top, so you can use an automatic
>   buffer to hold the string data, with all the ugliness at the
>   call site that entails. QStringView takes all that pain and hides it
>   (see https://codereview.qt-
> project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified).
>   It also allows for clearer interfaces, because instead of a QString and an
>   int, you can just pass a QStringView, since creating a sub-view suddenly
>   costs nothing:
> 
> 2. QStringView gives the caller the choice of container for string data. This
>   makes Qt much more interoperable with 3rd-party libraries. QStringView will
>   make QStringLiteral all but obsolete, since you can now just pass u"string"
>   or, on Windows, L"string" to any QStringView-taking function. We can
>   trivially define a QStringViewLiteral that uses one of the other, depending
>   on platform. I backed that feature out, though, since I fist need to verify
>   that we support no compilers anymore that would fall back to fromUtf8() for
>   QStringLiteral.
> 
> 3. And yes, performance. Where today we have to return QString, even where we
>   know a maximum size, and even where we don't:  It will allow
>   QLocale::toString() to return something equivalent to char16_t[N], e.g.
>   std::array, in order to not allocate memory just to format numbers,
>   something that has so far eluded any practical solution. For internal
>   functions that return temporary QStrings, we can switch to QVarLengthArray,
>   and avoid heap allocations in common cases.
> 
> The last such fundamental change to QtBase was the possibility to connect 
> signals to lambdas. Believe me, QStringView has the same caliber.
> 
>> What would we really loose if we worked towards getting this into the dev
>> branch in the next few weeks? We don't exactly have hundreds of
>> users/customers who can't live without it. And pushing it into dev would
>> give you lots of time to make sure we make best possible use of the class
>> throughout all of Qt for 5.10.
> 
> I have found that even with just relational operators, conversions, and 
> iterators (ie. just the Long-live commit in the series), maybe 
> QString::append() and QStirngBuilder integration, you can already do a lot of 
> stuff. For us, getting QStringView into dev next week means one week of delay, 
> but for our users, it means half a year delay. Qt is desperately in need of 
> better integration with std C++, and QStringView is hand-down the largest such 
> contribution. Not having it means people will continue to spend^Wwaste time 
> porting stuff to QStringRef, which will later be replaced by QStringView. 
> Don#t get me wrong, I love the work Anton and others have done in the area. I 
> now just need to grep for QStringRef to find code to port to QStringView, but 
> the real value of QStringView lies in where there was no QStringRef-overload 
> in the first place, e.g. QColor: https://codereview.qt-project.org/184038
> 
> In the end, it's your call, of course.
> 
> I personally don't care whether it goes into 5.9 or 5.10, but for our users 
> and for other contributors, I hope that it makes it into 5.9, since, judging 
> from 5.8, a lot of internal performance improvements come into stable 
> branches, and we really don't need more QStringRef uses in Qt. esp. in public 
> API, where we need to carry it all the way to Qt 6.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From lars.knoll at qt.io  Tue Jan 31 13:32:03 2017
From: lars.knoll at qt.io (Lars, Knoll)
Date: Tue, 31 Jan 2017 12:32:03 +0000
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <DEA9B53B-BDB8-4146-8191-CACB67CB4D93@qt.io>
References: <201701302003.25214.marc.mutz@kdab.com>
	<D33A4518-2821-4183-9295-CE69CC168290@qt.io>
	<201701311207.52884.marc.mutz@kdab.com>
	<DEA9B53B-BDB8-4146-8191-CACB67CB4D93@qt.io>
Message-ID: <E2225067-49EE-4F69-A428-9E8EFF437827@qt.io>

As much as I love getting new features in, I have to agree here. 

Let's get this into dev as soon as we can, and make sure we have a great story to tell for 5.10.

Cheers,
Lars

> On 31 Jan 2017, at 12:47, Andy, Nichols <Andy.Nichols at qt.io> wrote:
> 
> While QStringView looks like a nice addition to Qt, I don’t think we should risk delaying the next release over it.  It is bad enough there is always a rush to cram things in the week leading up to the release and even worse when we start talking about extensions.  If we are going to have time based releases we need to follow the rules, and accept that there is always another release.  It’s much better to integrate early and have time to work out the kinks, rather than integrate a feature at the last second.
> 
>> On 31 Jan 2017, at 12:07, Marc Mutz <marc.mutz at kdab.com> wrote:
>> 
>> Hi Lars,
>> 
>> On Tuesday 31 January 2017 10:08:35 Lars, Knoll wrote:
>> [...]
>>>> So, in order to give the maintainers more time for review, I'd like to
>>>> ask for a feature freeze extension for QStringView until end of next
>>>> week, plus a few days to deal with maintainer review comments.
>>> 
>>> I understand that you want to have the patch series finally merged.
>>> Actually I do as well, I believe that QStringView is the right approach
>>> moving forward.
>>> 
>>> But I do wonder about the approach here. The series has been around pretty
>>> much unchanged for quite some time now without anybody working on it. You
>>> had lots of time since summer to get this into shape an merged. Now, a
>>> week before the feature freeze and suddenly this absolutely has to go in?
>> 
>> I have been sxcheduled to work on this in January, but was out with sick child 
>> and then myself afterwards for almost two weeks. That's why it's late.
>> 
>> Then again, as you say, the main patch has been around for the better part of 
>> a year, and the basic idea has been around since the beginning.
>> 
>>>> Why should it be granted? Because QStringView is by far the biggest
>>>> revolution in Qt since 5.0, all the while integrating naturally and
>>>> step-by-step into existing code, _tremendously_ simplifying it along the
>>>> way (cf. the commits that start to make use of QStringView:
>>>> https://codereview.qt-
>>>> project.org/183864 https://codereview.qt-project.org/183925), esp. where,
>>>> in private API, we can already remove the other overloads.
>>> 
>>> I agree, that the series cleans things up and is a great improvement. But
>>> the biggest revolution since 5.0? It's an API addition that brings
>>> performance optimisations in Qt's string handling.
>> 
>> No, this is not at all about performance. It's mostly about stream-lining the 
>> API, and adding flexibility:
>> 
>> 1. Traditionally, a lot of stuff has been taking QString, and QString only. If
>>  you're lucky, you get (QChar*, int) on top, so you can use an automatic
>>  buffer to hold the string data, with all the ugliness at the
>>  call site that entails. QStringView takes all that pain and hides it
>>  (see https://codereview.qt-
>> project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified).
>>  It also allows for clearer interfaces, because instead of a QString and an
>>  int, you can just pass a QStringView, since creating a sub-view suddenly
>>  costs nothing:
>> 
>> 2. QStringView gives the caller the choice of container for string data. This
>>  makes Qt much more interoperable with 3rd-party libraries. QStringView will
>>  make QStringLiteral all but obsolete, since you can now just pass u"string"
>>  or, on Windows, L"string" to any QStringView-taking function. We can
>>  trivially define a QStringViewLiteral that uses one of the other, depending
>>  on platform. I backed that feature out, though, since I fist need to verify
>>  that we support no compilers anymore that would fall back to fromUtf8() for
>>  QStringLiteral.
>> 
>> 3. And yes, performance. Where today we have to return QString, even where we
>>  know a maximum size, and even where we don't:  It will allow
>>  QLocale::toString() to return something equivalent to char16_t[N], e.g.
>>  std::array, in order to not allocate memory just to format numbers,
>>  something that has so far eluded any practical solution. For internal
>>  functions that return temporary QStrings, we can switch to QVarLengthArray,
>>  and avoid heap allocations in common cases.
>> 
>> The last such fundamental change to QtBase was the possibility to connect 
>> signals to lambdas. Believe me, QStringView has the same caliber.
>> 
>>> What would we really loose if we worked towards getting this into the dev
>>> branch in the next few weeks? We don't exactly have hundreds of
>>> users/customers who can't live without it. And pushing it into dev would
>>> give you lots of time to make sure we make best possible use of the class
>>> throughout all of Qt for 5.10.
>> 
>> I have found that even with just relational operators, conversions, and 
>> iterators (ie. just the Long-live commit in the series), maybe 
>> QString::append() and QStirngBuilder integration, you can already do a lot of 
>> stuff. For us, getting QStringView into dev next week means one week of delay, 
>> but for our users, it means half a year delay. Qt is desperately in need of 
>> better integration with std C++, and QStringView is hand-down the largest such 
>> contribution. Not having it means people will continue to spend^Wwaste time 
>> porting stuff to QStringRef, which will later be replaced by QStringView. 
>> Don#t get me wrong, I love the work Anton and others have done in the area. I 
>> now just need to grep for QStringRef to find code to port to QStringView, but 
>> the real value of QStringView lies in where there was no QStringRef-overload 
>> in the first place, e.g. QColor: https://codereview.qt-project.org/184038
>> 
>> In the end, it's your call, of course.
>> 
>> I personally don't care whether it goes into 5.9 or 5.10, but for our users 
>> and for other contributors, I hope that it makes it into 5.9, since, judging 
>> from 5.8, a lot of internal performance improvements come into stable 
>> branches, and we really don't need more QStringRef uses in Qt. esp. in public 
>> API, where we need to carry it all the way to Qt 6.
>> 
>> Thanks,
>> Marc
>> 
>> -- 
>> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - The Qt, C++ and OpenGL Experts
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From marc.mutz at kdab.com  Tue Jan 31 13:47:09 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 31 Jan 2017 13:47:09 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <E2225067-49EE-4F69-A428-9E8EFF437827@qt.io>
References: <201701302003.25214.marc.mutz@kdab.com>
	<DEA9B53B-BDB8-4146-8191-CACB67CB4D93@qt.io>
	<E2225067-49EE-4F69-A428-9E8EFF437827@qt.io>
Message-ID: <201701311347.15272.marc.mutz@kdab.com>

On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote:
> As much as I love getting new features in, I have to agree here.
> 
> Let's get this into dev as soon as we can, and make sure we have a great
> story to tell for 5.10.

Ok, then. I'll rewrite the series to \since 5.10.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From philwave at gmail.com  Tue Jan 31 13:50:26 2017
From: philwave at gmail.com (Philippe)
Date: Tue, 31 Jan 2017 13:50:26 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701302003.25214.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
Message-ID: <20170131135025.C230.6F0322A@gmail.com>

As far as I understand, I see a performance regression with QStringView, for all the cases where copy-on-write can't take place any longer.
In the following code, an extra malloc is needed. Or am I wrong?

void bar()
{
	QString s("hello");
	foo(s)
}

void foo(QStringView sv)
{
	QString str(sv);	// malloc needed
}

void foo2(const QString& s)
{
	QString str(s);	// faster because of COW
}

Philippe


On Mon, 30 Jan 2017 20:03:24 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:

> Hi,
> 
> QStringView is ready to be merged, but the maintainer has asked for another 
> week before he can properly review the class.
> 
> In case you don't remember, here's the discussion thread from 2015: 
> http://lists.qt-project.org/pipermail/development/2015-October/023358.html
> 
> Here's the evolving patch series:
> https://codereview.qt-
> project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z
> 
> I feel the patch addresses all concerns raised in the discussion:
> 
> 1. size_type: we agreed on on ssize_t equivalent to strike a balance between
>    the Qt preference of 32-bit signed types over the STL preference for 64-bit
>    unsigned types.
> 2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
>    without deeply-routed support in QString would be a still-born. We also
>    don't have time come Qt 6 to port all of Qt to a QStringView developed
>    elsewhere. The current patches just scratch the surface. Everywhere
>    QStringRef is currently used, QStringView can be used. And a lot of places
>    that traditionally only took QString should take QStringView, too, e.g.
>    QFile::encodeName(). So I added it to Qt.
> 3. Keeping existing QString overloads for implicit sharing.
>    The patch does not remove anything. It will, as it progresses, implement
>    QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
>    overloads (2: only where the function read from the string, 3: also where
>    it stores the string), so that at some later point in time we can just flip
>    a preprocessor switch and compare executable size and execution speed of
>    both sets of overloads, everything else being equal.
> 
> So, in order to give the maintainers more time for review, I'd like to ask for 
> a feature freeze extension for QStringView until end of next week, plus a few 
> days to deal with maintainer review comments.
> 
> Why should it be granted? Because QStringView is by far the biggest revolution 
> in Qt since 5.0, all the while integrating naturally and step-by-step into 
> existing code, _tremendously_ simplifying it along the way (cf. the commits 
> that start to make use of QStringView: https://codereview.qt-
> project.org/183864 https://codereview.qt-project.org/183925), esp. where, in 
> private API, we can already remove the other overloads.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From cfeck at kde.org  Tue Jan 31 14:32:15 2017
From: cfeck at kde.org (Christoph Feck)
Date: Tue, 31 Jan 2017 14:32:15 +0100
Subject: [Development] Printer-specific options in Qt5's print dialog
 (Linux, CUPS)
In-Reply-To: <6a998402d6deb9fb2b8f505d9860b4af@posteo.de>
References: <de0a6890b5d7d5b5d5adc1e2b1065593@posteo.de>
	<3899068.oCfgoQ7oib@tjmaciei-mobl1>
	<6025AF62-E52E-4AF6-A263-AD5E712FA25E@qt.io>
	<6a998402d6deb9fb2b8f505d9860b4af@posteo.de>
Message-ID: <9807a11e-9dd1-87c8-b1a9-89b4f33e69c2@kde.org>

On 31.01.2017 09:55, Michael Weghorn wrote:

> [...] The links about the plans for the Qt print system that
> John provided in his email [1] give some kind of overview, but are
> currently not enough for me to deduce the concrete next steps that need
> to be taken for the implementation.
>
> If you (or somebody else) can give more information on that, this is
> certainly something we would be happy about and that we will examine
> more closely.

According to 
http://www.layt.net/john/blog/odysseus/focusing_on_printing_in_qt_5 John 
also did a big triage of reported issues in the printing system, which 
has a master bug at https://bugreports.qt.io/browse/QTBUG-37696

> [1]
> http://lists.qt-project.org/pipermail/interest/2015-September/018700.html



From sergio.martins at kdab.com  Tue Jan 31 15:09:06 2017
From: sergio.martins at kdab.com (Sergio Martins)
Date: Tue, 31 Jan 2017 14:09:06 +0000
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <20170131135025.C230.6F0322A@gmail.com>
References: <201701302003.25214.marc.mutz@kdab.com>
	<20170131135025.C230.6F0322A@gmail.com>
Message-ID: <570984572ae2917f474044799f3db362@kdab.com>

On 2017-01-31 12:50, Philippe wrote:
> As far as I understand, I see a performance regression with
> QStringView, for all the cases where copy-on-write can't take place
> any longer.
> In the following code, an extra malloc is needed. Or am I wrong?
> 
> void bar()
> {
> 	QString s("hello");
> 	foo(s)
> }
> 
> void foo(QStringView sv)
> {
> 	QString str(sv);	// malloc needed
> }
> 
> void foo2(const QString& s)
> {
> 	QString str(s);	// faster because of COW
> }

Hi Philippe,

What will you do with str ?
If you do write operations it will detach, so the COW argument doesn't 
apply.
If you only do read operations then you don't even need the QString.
In fact the first malloc isn't even needed, since you could just do 
foo("hello") if I understand correctly.


Regards,
-- 
Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts


From philwave at gmail.com  Tue Jan 31 15:24:18 2017
From: philwave at gmail.com (Philippe)
Date: Tue, 31 Jan 2017 15:24:18 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <570984572ae2917f474044799f3db362@kdab.com>
References: <20170131135025.C230.6F0322A@gmail.com>
	<570984572ae2917f474044799f3db362@kdab.com>
Message-ID: <20170131152417.C23F.6F0322A@gmail.com>

For instance, a method such as:

QLabel::setText(...)

stores the passed argument somewhere. A malloc will be needed if
QStringView is the interface and a QString the passed argument.

Ok, this example is not a performance critical case.

I just want to highlight, that QStringView is not COW friendly. AFAIK.

Philippe

On Tue, 31 Jan 2017 14:09:06 +0000
Sergio Martins <sergio.martins at kdab.com> wrote:

> On 2017-01-31 12:50, Philippe wrote:
> > As far as I understand, I see a performance regression with
> > QStringView, for all the cases where copy-on-write can't take place
> > any longer.
> > In the following code, an extra malloc is needed. Or am I wrong?
> > > void bar()
> > {
> > 	QString s("hello");
> > 	foo(s)
> > }
> > > void foo(QStringView sv)
> > {
> > 	QString str(sv);	// malloc needed
> > }
> > > void foo2(const QString& s)
> > {
> > 	QString str(s);	// faster because of COW
> > }
> 
> Hi Philippe,
> 
> What will you do with str ?
> If you do write operations it will detach, so the COW argument doesn't apply.
> If you only do read operations then you don't even need the QString.
> In fact the first malloc isn't even needed, since you could just do foo("hello") if I understand correctly.
> 
> 
> Regards,
> -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts




From thiago.macieira at intel.com  Tue Jan 31 16:18:59 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 31 Jan 2017 07:18:59 -0800
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701311207.52884.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
	<D33A4518-2821-4183-9295-CE69CC168290@qt.io>
	<201701311207.52884.marc.mutz@kdab.com>
Message-ID: <4690544.OpgdffnZ55@tjmaciei-mobl1>

Em terça-feira, 31 de janeiro de 2017, às 12:07:52 PST, Marc Mutz escreveu:
> No, this is not at all about performance. It's mostly about stream-lining
> the API, and adding flexibility:
> 
> 1. Traditionally, a lot of stuff has been taking QString, and QString only.
> If you're lucky, you get (QChar*, int) on top, so you can use an automatic
> buffer to hold the string data, with all the ugliness at the
>    call site that entails. QStringView takes all that pain and hides it
>    (see https://codereview.qt-> project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified)
> . It also allows for clearer interfaces, because instead of a QString and an
> int, you can just pass a QStringView, since creating a sub-view suddenly
> costs nothing:

But we still have to have QString overloads in public functions, otherwise 
creating full copies would now suddenly cost something.

> 2. QStringView gives the caller the choice of container for string data.
> This makes Qt much more interoperable with 3rd-party libraries. QStringView
> will make QStringLiteral all but obsolete, since you can now just pass
> u"string" or, on Windows, L"string" to any QStringView-taking function. We
> can trivially define a QStringViewLiteral that uses one of the other,
> depending on platform. I backed that feature out, though, since I fist need
> to verify that we support no compilers anymore that would fall back to
> fromUtf8() for QStringLiteral.

There's an interesting advanage for using QStringView on data alloated by 
CoreFramework / Cocoa or by Win32, but since we don't own the data, we have to 
be very careful. In fact, unlike everything else in Qt, QStringView never owns 
the data and that is a major change in how we think.

It was the cause of Thierry's bug yesterday 
https://codereview.qt-project.org/184004

> 3. And yes, performance. Where today we have to return QString, even where
> we know a maximum size, and even where we don't:  It will allow
>    QLocale::toString() to return something equivalent to char16_t[N], e.g.
>    std::array, in order to not allocate memory just to format numbers,
>    something that has so far eluded any practical solution. For internal
>    functions that return temporary QStrings, we can switch to
> QVarLengthArray, and avoid heap allocations in common cases.

I'll study this when the time comes, but first reaction to:

	using NumberString = char16_t[32];
	NumberString toString(int value, bool *ok = nullptr);

Sounds like an awfully ugly API and prone to errors.

> The last such fundamental change to QtBase was the possibility to connect
> signals to lambdas. Believe me, QStringView has the same caliber.

I don't doubt it. Which is why I need more time to review this.

> delay, but for our users, it means half a year delay. Qt is desperately in
> need of better integration with std C++, and QStringView is hand-down the
> largest such contribution. 

Sorry, but I have yet to see any codebase using std::u16string, so I really 
doubt that QStringView allows us better integration with standard library-
based C++.

> Not having it means people will continue to
> spend^Wwaste time porting stuff to QStringRef, which will later be replaced
> by QStringView. Don#t get me wrong, I love the work Anton and others have
> done in the area. I now just need to grep for QStringRef to find code to
> port to QStringView, but the real value of QStringView lies in where there
> was no QStringRef-overload in the first place, e.g. QColor:
> https://codereview.qt-project.org/184038

Indeed, and it's unfortunate.

> I personally don't care whether it goes into 5.9 or 5.10, but for our users
> and for other contributors, I hope that it makes it into 5.9, since, judging
> from 5.8, a lot of internal performance improvements come into stable
> branches, and we really don't need more QStringRef uses in Qt. esp. in
> public API, where we need to carry it all the way to Qt 6.

Our users have used QString for 25 years and QStringRef for 10, so we another 
6 months is not too big a deal.

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



From marc.mutz at kdab.com  Tue Jan 31 18:39:43 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 31 Jan 2017 18:39:43 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <20170131152417.C23F.6F0322A@gmail.com>
References: <20170131135025.C230.6F0322A@gmail.com>
	<570984572ae2917f474044799f3db362@kdab.com>
	<20170131152417.C23F.6F0322A@gmail.com>
Message-ID: <201701311839.44054.marc.mutz@kdab.com>

On Tuesday 31 January 2017 15:24:18 Philippe wrote:
> For instance, a method such as:
> 
> QLabel::setText(...)
> 
> stores the passed argument somewhere. A malloc will be needed if
> QStringView is the interface and a QString the passed argument.
> 
> Ok, this example is not a performance critical case.
> 
> I just want to highlight, that QStringView is not COW friendly. AFAIK.

Q6String will likely have the small-string optimisation, so short strings 
aren't actually COWed, but deep-copied. Passing through QStringView then is 
about the same efficiency as passing through a const QString&.

But that's why we'll have QStringView Level 3, where only the QStringView 
QLabel::setText() overload will be compiled in. Then, we compile Qt with 
either level and check the respective performance of the result. I'll wager 
that the results will be very interesting.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From marc.mutz at kdab.com  Tue Jan 31 18:53:55 2017
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 31 Jan 2017 18:53:55 +0100
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <4690544.OpgdffnZ55@tjmaciei-mobl1>
References: <201701302003.25214.marc.mutz@kdab.com>
	<201701311207.52884.marc.mutz@kdab.com>
	<4690544.OpgdffnZ55@tjmaciei-mobl1>
Message-ID: <201701311853.56327.marc.mutz@kdab.com>

On Tuesday 31 January 2017 16:18:59 Thiago Macieira wrote:
> Em terça-feira, 31 de janeiro de 2017, às 12:07:52 PST, Marc Mutz escreveu:
> > No, this is not at all about performance. It's mostly about stream-lining
> > the API, and adding flexibility:
> > 
> > 1. Traditionally, a lot of stuff has been taking QString, and QString
> > only. If you're lucky, you get (QChar*, int) on top, so you can use an
> > automatic buffer to hold the string data, with all the ugliness at the
> > 
> >    call site that entails. QStringView takes all that pain and hides it
> >    (see https://codereview.qt->
> >    project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,u
> >    nified)
> > 
> > . It also allows for clearer interfaces, because instead of a QString and
> > an int, you can just pass a QStringView, since creating a sub-view
> > suddenly
> 
> > costs nothing:
>
> But we still have to have QString overloads in public functions, otherwise
> creating full copies would now suddenly cost something.

Using QStringView level 3 we'll be able to fact-check that. And I was under 
the impression that Q6String would use SSO...?
 
> > 2. QStringView gives the caller the choice of container for string data.
> > This makes Qt much more interoperable with 3rd-party libraries.
> > QStringView will make QStringLiteral all but obsolete, since you can now
> > just pass u"string" or, on Windows, L"string" to any QStringView-taking
> > function. We can trivially define a QStringViewLiteral that uses one of
> > the other, depending on platform. I backed that feature out, though,
> > since I fist need to verify that we support no compilers anymore that
> > would fall back to fromUtf8() for QStringLiteral.
> 
> There's an interesting advanage for using QStringView on data alloated by
> CoreFramework / Cocoa or by Win32, but since we don't own the data, we have
> to be very careful. In fact, unlike everything else in Qt, QStringView
> never owns the data and that is a major change in how we think.
> 
> It was the cause of Thierry's bug yesterday
> https://codereview.qt-project.org/184004

This is a bug caused by unclear ownership semantics of QByteArray. QStringView 
has clear ownership semantics, so bugs are much less likely. Yes, you have 
problem with stability of references, but you cannot avoid that. Even in Java, 
an int into a container has the problem that the int may get out with the 
resp. index in the container...

> > 3. And yes, performance. Where today we have to return QString, even
> > where we know a maximum size, and even where we don't:  It will allow
> > 
> >    QLocale::toString() to return something equivalent to char16_t[N],
> >    e.g. std::array, in order to not allocate memory just to format
> >    numbers, something that has so far eluded any practical solution. For
> >    internal functions that return temporary QStrings, we can switch to
> > 
> > QVarLengthArray, and avoid heap allocations in common cases.
> 
> I'll study this when the time comes, but first reaction to:
> 
> 	using NumberString = char16_t[32];
> 	NumberString toString(int value, bool *ok = nullptr);
> 
> Sounds like an awfully ugly API and prone to errors.

This does not compile. I was thinking about a QFormattedNumber<T>, which would 
contain a buffer of sufficient size to hold the result, and implicit 
converstions to QString, QStringView.

> > The last such fundamental change to QtBase was the possibility to connect
> > signals to lambdas. Believe me, QStringView has the same caliber.
> 
> I don't doubt it. Which is why I need more time to review this.
> 
> > delay, but for our users, it means half a year delay. Qt is desperately
> > in need of better integration with std C++, and QStringView is hand-down
> > the largest such contribution.
> 
> Sorry, but I have yet to see any codebase using std::u16string, so I really
> doubt that QStringView allows us better integration with standard library-
> based C++.

u"string". The only reason we don't use that, yet, is that MSVC < 2015 doesn't 
support it. Let's drop 2013 in 5.10 and we can replace all QStringLiterals 
with char16_t string literals.

> > Not having it means people will continue to
> > spend^Wwaste time porting stuff to QStringRef, which will later be
> > replaced by QStringView. Don#t get me wrong, I love the work Anton and
> > others have done in the area. I now just need to grep for QStringRef to
> > find code to port to QStringView, but the real value of QStringView lies
> > in where there was no QStringRef-overload in the first place, e.g.
> > QColor:
> > https://codereview.qt-project.org/184038
> 
> Indeed, and it's unfortunate.

I reviewed additions to public (QtBase) API between 5.8 and 5.9 and the only 
problem is the addition of QStringRef::isRightToLeft() as an out-of-line 
function. I expect that I'll de-out-line most QString/QStringRef functions 
that become backed by a QStringView implementation, qstring_compat.cpp-style, 
and since we won't have QStringView in 5.9, there's another out-of-line 
function to deal with. But what's one in dozens...?

> > I personally don't care whether it goes into 5.9 or 5.10, but for our
> > users and for other contributors, I hope that it makes it into 5.9,
> > since, judging from 5.8, a lot of internal performance improvements come
> > into stable branches, and we really don't need more QStringRef uses in
> > Qt. esp. in public API, where we need to carry it all the way to Qt 6.
> 
> Our users have used QString for 25 years and QStringRef for 10, so we
> another 6 months is not too big a deal.

But we only have had C++11 for five years...

It's not a problem, but an inconvenience. I don't know when Qt6 will come 
around, but by then we should have all of QtBase equipped with QStringView 
overloads to be able to judge which level to keep in Qt 6. If we try to do the 
remaining overloads in the frenzy leading to 6.0.0, we'll fail to achieve that 
goal.

But since it's decided to postpone to 5.10 anyway, let's at least make sure we 
start to merge the series asap after the final dev→5.9 downmerge.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts


From thiago.macieira at intel.com  Tue Jan 31 19:32:55 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 31 Jan 2017 10:32:55 -0800
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701311839.44054.marc.mutz@kdab.com>
References: <20170131135025.C230.6F0322A@gmail.com>
	<20170131152417.C23F.6F0322A@gmail.com>
	<201701311839.44054.marc.mutz@kdab.com>
Message-ID: <13927077.7djPAdjcQo@tjmaciei-mobl1>

On terça-feira, 31 de janeiro de 2017 18:39:43 PST Marc Mutz wrote:
> Q6String will likely have the small-string optimisation, so short strings
> aren't actually COWed, but deep-copied. Passing through QStringView then is
> about the same efficiency as passing through a const QString&.

Not sure you can count on this optimisation. Even my expanded QString is only 
24 bytes on 64-bit, which means that you can store floor((24 - 1) / 2) = 11 
characters in the short string. I don't have my data ready here, but when I 
calculated the histogram for qHash, 22 bytes was very far from the 
overwhelming majority of the strings (I remember 34 bytes was a significant 
mark, I just don't remember if it was 75% or 90%).

My current QString for 32-bit is only 12 bytes, which gives us 5 characters at 
most. That's definitely more overhead than the potential gain.

It would be better to expand it to 32 bytes, even on 32-bit platforms. That's 
15 characters and can be implemented by two SSE moves (or one AVX) on x86, 
versus one SSE plus one GPR on 64-bit or three GPR moves on 32-bit.

That implies we need to expand QVariant to 40 bytes. Fortunately, we don't 
plan on keeping QList the way it is, or it would suffer greatly.

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



From thiago.macieira at intel.com  Tue Jan 31 19:52:34 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 31 Jan 2017 10:52:34 -0800
Subject: [Development] Feature Freeze Exception: QStringView
In-Reply-To: <201701311853.56327.marc.mutz@kdab.com>
References: <201701302003.25214.marc.mutz@kdab.com>
	<4690544.OpgdffnZ55@tjmaciei-mobl1>
	<201701311853.56327.marc.mutz@kdab.com>
Message-ID: <2520893.RM0PXepoGU@tjmaciei-mobl1>

On terça-feira, 31 de janeiro de 2017 18:53:55 PST Marc Mutz wrote:
> > There's an interesting advanage for using QStringView on data alloated by
> > CoreFramework / Cocoa or by Win32, but since we don't own the data, we
> > have
> > to be very careful. In fact, unlike everything else in Qt, QStringView
> > never owns the data and that is a major change in how we think.
> > 
> > It was the cause of Thierry's bug yesterday
> > https://codereview.qt-project.org/184004
> 
> This is a bug caused by unclear ownership semantics of QByteArray.
> QStringView has clear ownership semantics, so bugs are much less likely.
> Yes, you have problem with stability of references, but you cannot avoid
> that. Even in Java, an int into a container has the problem that the int
> may get out with the resp. index in the container...

Good point, that's a point in favour of having Q{String,ByteArray}View.

We need to think how that will work with having classes for exclusive 
ownership (not implicitly shared). That's the counterpart of the Views: they 
don't own, but they only have read-only access. I want to provide a solution 
for the mutating operations too.
 
> > I'll study this when the time comes, but first reaction to:
> > 	using NumberString = char16_t[32];
> > 	NumberString toString(int value, bool *ok = nullptr);
> > 
> > Sounds like an awfully ugly API and prone to errors.
> 
> This does not compile. I was thinking about a QFormattedNumber<T>, which
> would contain a buffer of sufficient size to hold the result, and implicit
> converstions to QString, QStringView.

Ok. And since we don't subscribe to "Almost Always Auto", we won't be bitten 
by:

	auto str = locale.toString(value);
	if (str.startsWith('0'))

> > Sorry, but I have yet to see any codebase using std::u16string, so I
> > really
> > doubt that QStringView allows us better integration with standard library-
> > based C++.
> 
> u"string". The only reason we don't use that, yet, is that MSVC < 2015
> doesn't support it. Let's drop 2013 in 5.10 and we can replace all
> QStringLiterals with char16_t string literals.

The reason we don't really use QStringLiterals is the design of QStringData. 
It has a 16- or 24-byte overhead.

If I had finished[*] my new QString/QVector/QByteArray for 5.0, we could have 
because the overhead would have been much smaller: exactly the same as 
u"string". See how there's no static in:

https://github.com/thiagomacieira/qtbase/blob/master/src/corelib/tools/
qstring.h#L177

[*] actually, I had finished it, and I've kept a series of patches to QtQml and 
the Qt Creator debug dumpers to keep it working. I just didn't want to delay 
5.0 further at the time.

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