Discussion:
Starting preparations for Qt 5.1
(too old to reply)
Ahumada Sergio
2013-03-18 10:24:23 UTC
Permalink
Hi,

Making of Qt 5.1 minor release will soon start:

- Plan is to move 'dev' into 'stable' branch on March 19th.

- After March 19th any changes that are required to get in for 5.1
need to be pushed into 'stable' branch. So if your needed changes don't make it today,
please wait after the merge is done and re-target it.

- I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed.

- If we decide to do 5.0.3, it could be done from the 'release' branch.

Cheers,
--
Sergio Ahumada
Release Engineer - Digia, Qt
Giuseppe D'Angelo
2013-03-18 12:36:20 UTC
Permalink
On 18 March 2013 11:24, Ahumada Sergio <***@digia.com> wrote:
>
> Making of Qt 5.1 minor release will soon start:
>
> - Plan is to move 'dev' into 'stable' branch on March 19th.
>
> - After March 19th any changes that are required to get in for 5.1
> need to be pushed into 'stable' branch. So if your needed changes don't make it today,
> please wait after the merge is done and re-target it.

I don't like this very much. We've been running late with the merge,
but giving people a 1 day notice (without prior warnings) seems
unfair. And, I think stable should never get broken w.r.t. forward
binary compatibility, unless at very specific points -- i.e. when we
merge -dev into it. The branch guidelines indeed specify that we
should freeze and stabilize -dev, not -stable, and release 5.1 alpha
out of -dev, not -stable, so that eventual API/ABI fixes to 5.1
material go into -dev. We should merge only when in -beta quality.

--
Giuseppe D'Angelo
Ahumada Sergio
2013-03-18 13:22:32 UTC
Permalink
On 18 March 2013 11:24, Ahumada Sergio <***@digia.com> wrote:
>>
>> Making of Qt 5.1 minor release will soon start:
>>
>> - Plan is to move 'dev' into 'stable' branch on March 19th.
>>
>> - After March 19th any changes that are required to get in for 5.1
>> need to be pushed into 'stable' branch. So if your needed changes don't make it today,
>> please wait after the merge is done and re-target it.
>
> I don't like this very much. We've been running late with the merge,
> but giving people a 1 day notice (without prior warnings) seems
> unfair. And, I think stable should never get broken w.r.t. forward
> binary compatibility, unless at very specific points -- i.e. when we
> merge -dev into it. The branch guidelines indeed specify that we
> should freeze and stabilize -dev, not -stable, and release 5.1 alpha
> out of -dev, not -stable, so that eventual API/ABI fixes to 5.1
> material go into -dev. We should merge only when in -beta quality.

Hi,

The warning was giving a month ago http://lists.qt-project.org/pipermail/development/2013-February/009838.html

So this one extra day (or two) is just a friendly reminder.

About the tag, one could argue that making the tag (and alpha release) before or after the merge might be the same.

Cheers,
--
Sergio Ahumada
Release Engineer - Digia, Qt
Giuseppe D'Angelo
2013-03-18 13:36:41 UTC
Permalink
On 18 March 2013 14:22, Ahumada Sergio <***@digia.com> wrote:
> About the tag, one could argue that making the tag (and alpha release) before or after the merge might be the same.

This is not only about making the 5.1.0-alpha1 tag. This is about not
breaking forward binary compatibility in stable unless extraordinary
circumstances. The branch guidelines imply that we should not merge
unless we are (almost) in beta quality, see
http://i.imgur.com/N1jVW.png (from
http://qt-project.org/wiki/Branch-Guidelines , 2nd picture).

We can declare dev frozen and not accept any new
significant/destabilizing feature, but I disagree on the point that we
should retarget small new features (pending, not yet +2d) to stable,
as well as getting the first round of API feedback (which could mean
API/ABI breaks) in stable. (That of course could still happen after a
beta released from -stable, but it would probably require much
stronger arguments in order to go through.)

Just my 2c,
--
Giuseppe D'Angelo
Thiago Macieira
2013-03-18 14:44:54 UTC
Permalink
On segunda-feira, 18 de março de 2013 14.36.41, Giuseppe D'Angelo wrote:
> On 18 March 2013 14:22, Ahumada Sergio <***@digia.com> wrote:
> > About the tag, one could argue that making the tag (and alpha release)
> > before or after the merge might be the same.
> This is not only about making the 5.1.0-alpha1 tag. This is about not
> breaking forward binary compatibility in stable unless extraordinary
> circumstances. The branch guidelines imply that we should not merge
> unless we are (almost) in beta quality, see
> http://i.imgur.com/N1jVW.png (from
> http://qt-project.org/wiki/Branch-Guidelines , 2nd picture).

That was not my intention when I wrote that.

"dev" is already in alpha state. As soon as we do the feature-freeze, we can
release the alpha and it should be fine. And Sergio is right: whether the tag
appears shortly before or shortly after the dev/stable does not make a
difference.

> We can declare dev frozen and not accept any new
> significant/destabilizing feature, but I disagree on the point that we
> should retarget small new features (pending, not yet +2d) to stable,

dev doesn't freeze. The freezing of Qt 5.1 *is* the merge of dev into stable.

> as well as getting the first round of API feedback (which could mean
> API/ABI breaks) in stable. (That of course could still happen after a
> beta released from -stable, but it would probably require much
> stronger arguments in order to go through.)

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Eskil Abrahamsen Blomfeldt
2013-03-18 14:02:23 UTC
Permalink
On 03/18/2013 11:24 AM, Ahumada Sergio wrote:
> - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed.

I have a patch pending for 'stable' which I think should go into Qt 5.0.3:

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

Unless there is a decision that we will never release on the Qt 5.0.x
series ever again (which does not sound plausible, as we would have to
if there was e.g. a bad security issue in the 5.0.2 release), I think it
sounds safer to make a 5.0 branch that can be used to release patches in
the future. Isn't that what we always did before? If the problem is
making sure the branch is merged back, maybe we could make it policy
that you submit to both stable and 5.0 if you want the patch in both?

-- Eskil
Oswald Buddenhagen
2013-03-18 14:22:46 UTC
Permalink
On Mon, Mar 18, 2013 at 10:24:23AM +0000, Ahumada Sergio wrote:
> Hi,
>
> Making of Qt 5.1 minor release will soon start:
>
> - Plan is to move 'dev' into 'stable' branch on March 19th.
>
i'd like to raise a formal objection.

CI was virtually unusable for two weeks now.
due to that there is a completely unreasonable backlog of changes meant
for 5.1 now. it makes no sense to re-target (or even deny them) due to
infrastructure problems.
also, we didn't have a single qt5.git integration in several weeks now.
that means that there is a fair amount of uncertainty involved (well, in
fact, i know that it's broken - my half-integrated patch series
contributes to that).

consequently we should delay the freeze by at least one week.

> - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed.
>
in fact, thiago and me already decided that we'll create an old/5.0
branch from stable right before we merge dev.
Turunen Tuukka
2013-03-18 15:16:22 UTC
Permalink
On 18.3.2013 16.44, "Thiago Macieira" <***@intel.com> wrote:

>On segunda-feira, 18 de março de 2013 14.36.41, Giuseppe D'Angelo wrote:
>> On 18 March 2013 14:22, Ahumada Sergio <***@digia.com> wrote:
>> > About the tag, one could argue that making the tag (and alpha release)
>> > before or after the merge might be the same.
>> This is not only about making the 5.1.0-alpha1 tag. This is about not
>> breaking forward binary compatibility in stable unless extraordinary
>> circumstances. The branch guidelines imply that we should not merge
>> unless we are (almost) in beta quality, see
>> http://i.imgur.com/N1jVW.png (from
>> http://qt-project.org/wiki/Branch-Guidelines , 2nd picture).
>
>That was not my intention when I wrote that.
>
>"dev" is already in alpha state. As soon as we do the feature-freeze, we
>can
>release the alpha and it should be fine. And Sergio is right: whether the
>tag
>appears shortly before or shortly after the dev/stable does not make a
>difference.
>
>> We can declare dev frozen and not accept any new
>> significant/destabilizing feature, but I disagree on the point that we
>> should retarget small new features (pending, not yet +2d) to stable,
>
>dev doesn't freeze. The freezing of Qt 5.1 *is* the merge of dev into
>stable.
>
>> as well as getting the first round of API feedback (which could mean
>> API/ABI breaks) in stable. (That of course could still happen after a
>> beta released from -stable, but it would probably require much
>> stronger arguments in order to go through.)


So the 'Alpha' release is the state we are in at the time when merge to
stable has been successfully done?

How should we distribute the 'Alpha' release? Is it enough to tag and
announce it? Is there benefit in packaging it to source-only installer?

I think it would be really good not to start any kind maturation process
on different 'Alpha' releases, but rather concentrate on 'Beta' release,
i.e. having decently working set and release tested content in binary
installers. Furthermore, I would like to get first 'Beta' out as soon as
we can - without very long testing process before we can announce it to
exist - and make another 'Beta' if we think it is needed.


Yours,

Tuukka
Knoll Lars
2013-03-18 15:18:07 UTC
Permalink
On 3/18/13 3:22 PM, "Oswald Buddenhagen" <***@digia.com>
wrote:

>On Mon, Mar 18, 2013 at 10:24:23AM +0000, Ahumada Sergio wrote:
>> Hi,
>>
>> Making of Qt 5.1 minor release will soon start:
>>
>> - Plan is to move 'dev' into 'stable' branch on March 19th.
>>
>i'd like to raise a formal objection.
>
>CI was virtually unusable for two weeks now.
>due to that there is a completely unreasonable backlog of changes meant
>for 5.1 now. it makes no sense to re-target (or even deny them) due to
>infrastructure problems.

We have said that we'll move to time based releases. Should we stop this
because we aren't yet good enough in controlling our systems? I don't
think so. It might feel unfair to some people, but we've had these
discussions about some features missing the deadline every single minor
release.

Now if there are one or two features that are vital to make Qt 5.1
possible, we can discuss exceptions for those. But then we need to make
sure they go in in the next two days. Which features would these be?

>also, we didn't have a single qt5.git integration in several weeks now.
>that means that there is a fair amount of uncertainty involved (well, in
>fact, i know that it's broken - my half-integrated patch series
>contributes to that).

Yes, that is a concern for me as well.

If you're already claiming responsibility for at least part of the
problem, could you then help getting it fixed?
>
>consequently we should delay the freeze by at least one week.
>
>> - I haven't planed to create any branch yet for commits already in
>>'stable' and not in 'release'. So speak up if this is needed.
>>
>in fact, thiago and me already decided that we'll create an old/5.0
>branch from stable right before we merge dev.

Not that I'm principally opposed to this, but please remember proper
process: These should at least get discussed on this ML, not just get
decided by two people and then announced.

Lars
Thiago Macieira
2013-03-18 17:36:27 UTC
Permalink
On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote:
> We have said that we'll move to time based releases. Should we stop this
> because we aren't yet good enough in controlling our systems? I don't
> think so. It might feel unfair to some people, but we've had these
> discussions about some features missing the deadline every single minor
> release.
>
> Now if there are one or two features that are vital to make Qt 5.1
> possible, we can discuss exceptions for those. But then we need to make
> sure they go in in the next two days. Which features would these be?

I know of only the QUrlPathInfo and the timezone features, plus minor API
changes, for QtCore. The former is something that had been lost in my large
dashboard until last week, and John's changes were too big to review while I
was at a conference.

> >> - I haven't planed to create any branch yet for commits already in
> >>
> >>'stable' and not in 'release'. So speak up if this is needed.
> >
> >in fact, thiago and me already decided that we'll create an old/5.0
> >branch from stable right before we merge dev.
>
> Not that I'm principally opposed to this, but please remember proper
> process: These should at least get discussed on this ML, not just get
> decided by two people and then announced.

I thought it was discussed on the mailing list.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Stephen Kelly
2013-03-19 10:58:15 UTC
Permalink
On Monday, March 18, 2013 10:36:27 Thiago Macieira wrote:
> I know of only the QUrlPathInfo and the timezone features, plus minor API
> changes, for QtCore. The former is something that had been lost in my large
> dashboard until last week, and John's changes were too big to review while
> I was at a conference.

I think I'd prefer not adding the timezone stuff until 5.2. It will need to
change a lot for that release anyway (implementation wise) as only then it
will get the ICU support, right? Will that also be a behavior change in eg,
how datetimes are parsed? Is there also a behavior change with the existing
patches? How well is that tested with code external to qtbase? Why rush it in
in the week we want to branch for alpha? The chances of it struggling through
CI itself are pretty high.

Thanks,

--
Stephen Kelly <***@kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
Sorvig Morten
2013-03-19 06:56:37 UTC
Permalink
On Mar 18, 2013, at 4:18 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 3:22 PM, "Oswald Buddenhagen" <***@digia.com>
> wrote:
>>>
>> i'd like to raise a formal objection.
>>
>> CI was virtually unusable for two weeks now.
>> due to that there is a completely unreasonable backlog of changes meant
>> for 5.1 now. it makes no sense to re-target (or even deny them) due to
>> infrastructure problems.
>
> We have said that we'll move to time based releases. Should we stop this
> because we aren't yet good enough in controlling our systems? I don't
> think so. It might feel unfair to some people, but we've had these
> discussions about some features missing the deadline every single minor
> release.

Well, a central component of time-based releases is that it's actually possible to plan your work to meet the deadline.

My current rate is spending several days per change. We should stop and make our systems usable.


>
> Now if there are one or two features that are vital to make Qt 5.1
> possible, we can discuss exceptions for those. But then we need to make
> sure they go in in the next two days. Which features would these be?

I would like to get https://codereview.qt-project.org/#change,49452 in to support HighDpi on Mac. I have several changes after that but they are all bug fixes and can go into stable.

But how can I make sure it goes in the next two days?

Morten
Knoll Lars
2013-03-18 15:19:53 UTC
Permalink
On 3/18/13 4:16 PM, "Turunen Tuukka" <***@digia.com> wrote:

>
>On 18.3.2013 16.44, "Thiago Macieira" <***@intel.com> wrote:
>
>>On segunda-feira, 18 de março de 2013 14.36.41, Giuseppe D'Angelo wrote:
>>> On 18 March 2013 14:22, Ahumada Sergio <***@digia.com>
>>>wrote:
>>> > About the tag, one could argue that making the tag (and alpha
>>>release)
>>> > before or after the merge might be the same.
>>> This is not only about making the 5.1.0-alpha1 tag. This is about not
>>> breaking forward binary compatibility in stable unless extraordinary
>>> circumstances. The branch guidelines imply that we should not merge
>>> unless we are (almost) in beta quality, see
>>> http://i.imgur.com/N1jVW.png (from
>>> http://qt-project.org/wiki/Branch-Guidelines , 2nd picture).
>>
>>That was not my intention when I wrote that.
>>
>>"dev" is already in alpha state. As soon as we do the feature-freeze, we
>>can
>>release the alpha and it should be fine. And Sergio is right: whether the
>>tag
>>appears shortly before or shortly after the dev/stable does not make a
>>difference.
>>
>>> We can declare dev frozen and not accept any new
>>> significant/destabilizing feature, but I disagree on the point that we
>>> should retarget small new features (pending, not yet +2d) to stable,
>>
>>dev doesn't freeze. The freezing of Qt 5.1 *is* the merge of dev into
>>stable.
>>
>>> as well as getting the first round of API feedback (which could mean
>>> API/ABI breaks) in stable. (That of course could still happen after a
>>> beta released from -stable, but it would probably require much
>>> stronger arguments in order to go through.)
>
>
>So the 'Alpha' release is the state we are in at the time when merge to
>stable has been successfully done?
>
>How should we distribute the 'Alpha' release? Is it enough to tag and
>announce it? Is there benefit in packaging it to source-only installer?
>
>I think it would be really good not to start any kind maturation process
>on different 'Alpha' releases, but rather concentrate on 'Beta' release,
>i.e. having decently working set and release tested content in binary
>installers. Furthermore, I would like to get first 'Beta' out as soon as
>we can - without very long testing process before we can announce it to
>exist - and make another 'Beta' if we think it is needed.

Everything we need for the alpha we'll need for the beta as well.
Thiago Macieira
2013-03-18 15:27:11 UTC
Permalink
On segunda-feira, 18 de março de 2013 15.19.53, Knoll Lars wrote:
> >I think it would be really good not to start any kind maturation process
> >on different 'Alpha' releases, but rather concentrate on 'Beta' release,
> >i.e. having decently working set and release tested content in binary
> >installers. Furthermore, I would like to get first 'Beta' out as soon as
> >we can - without very long testing process before we can announce it to
> >exist - and make another 'Beta' if we think it is needed.
>
> Everything we need for the alpha we'll need for the beta as well. From my
> point of view it's enough if qt5.git successfully got updated, the new
> modules are part of it, and we have source packages. Other things are
> optional. Anybody thinks we need more for the alpha?

No, I agree with you.

We need to have all the features complete and documented, all modules
compiling and building together and we need to have source packages.

The first item was required before the feature was integrated. There should be
no incomplete features in any official branch.

The second one should be happening by way of the CI checks, but we may have a
delay in the master full build and we need a check of that. It means we need
to do the git branches after the next qt5.git integration.

And then we need to produce buildable packages.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Turunen Tuukka
2013-03-18 15:46:48 UTC
Permalink
On 18.3.2013 17.27, "Thiago Macieira" <***@intel.com> wrote:

>On segunda-feira, 18 de março de 2013 15.19.53, Knoll Lars wrote:
>> >I think it would be really good not to start any kind maturation
>>process
>> >on different 'Alpha' releases, but rather concentrate on 'Beta'
>>release,
>> >i.e. having decently working set and release tested content in binary
>> >installers. Furthermore, I would like to get first 'Beta' out as soon
>>as
>> >we can - without very long testing process before we can announce it to
>> >exist - and make another 'Beta' if we think it is needed.
>>
>> Everything we need for the alpha we'll need for the beta as well. From
>>my
>> point of view it's enough if qt5.git successfully got updated, the new
>> modules are part of it, and we have source packages. Other things are
>> optional. Anybody thinks we need more for the alpha?
>
>No, I agree with you.
>
>We need to have all the features complete and documented, all modules
>compiling and building together and we need to have source packages.
>
>The first item was required before the feature was integrated. There
>should be
>no incomplete features in any official branch.
>
>The second one should be happening by way of the CI checks, but we may
>have a
>delay in the master full build and we need a check of that. It means we
>need
>to do the git branches after the next qt5.git integration.
>
>And then we need to produce buildable packages.

Excellent!

I hope we can produce source packages about immediately (or the next day)
after the merge is done. Iikka, can you check that also the new repos are
working with the packaging scripts?

Yours,

Tuukka
Knoll Lars
2013-03-18 16:05:48 UTC
Permalink
On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:

>On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>wrote:
>
>QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>failures.
>See https://codereview.qt-project.org/#change,48905.
>
>
>
>+ QtSerialPort: https://codereview.qt-project.org/#change,49157

+ Mac and X11 extras. Yes, these are known.

In addition, we need to get qt5.git updated to recent sha1's of all qt
modules.

Cheers,
Lars
Jake Thomas Petroules
2013-03-18 22:47:49 UTC
Permalink
Don't you mean Mac and Windows? I thought X11 was added a while ago.
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: ***@petroules.com

On Mar 18, 2013, at 12:05 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>> wrote:
>>
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>>
>>
>>
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>
> + Mac and X11 extras. Yes, these are known.
>
> In addition, we need to get qt5.git updated to recent sha1's of all qt
> modules.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sorvig Morten
2013-03-19 06:52:42 UTC
Permalink
On Mar 18, 2013, at 5:05 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>> wrote:
>>
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>>
>>
>>
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>
> + Mac and X11 extras. Yes, these are known.


QtMacExtras is currently not in a releasable state. It's missing documentation, some examples and needs some general polish and bug fixes.

I think we also need to resolve the "native type" converters discussion to know which API's goes into QtMacExtras.

Since we are running out of time for 5.1 - should we postpone it to 5.2?

Morten
Jake Thomas Petroules
2013-03-19 16:16:03 UTC
Permalink
I think we should just postpone the extras 'till 5.2, yes.

QtWindowsExtras needs a ton more work - Ivan Vizir's big Windows 7 features commit is still not ready and likely won't for a while. I believe he said he is planning a second commit with more of them since thumbnail toolbars were left out of his first one for reasons of time. Like Morten said, QtMacExtras needs a lot more polish too. Unfortunately he and I are the only ones working on it.

As for the operators, I remember there was a discussion on IRC suggesting we simply declare the methods and operators and forward declare the types necessary in QtCore/QtGui, and implement them in QtWindowsExtras/QtMacExtras. Then the former need not link to any additional libraries.

My vote is for constructors and conversion operators on (the all caps types are Win32 types):

QString <=> NSString
QPoint <=> CGPoint, NSPoint, POINT
QSize <=> CGSize, NSSize, (there's no `SIZE` afaik)
QRect <=> CGRect, NSSize, SIZE
QMargins <=> MARGINS

Darwin has a lot of image types. UIImage converters are not strictly necessary since UIImage has easy methods to/from CGImageRef since iOS 2.0. However, something like: `inline UIImage* QImageToUIImage(const QImage &image) { return [UIImage imageWithCGImage:QImageToCGImage(image)]; }` would save typing so I think we should add them anyways. Similar story with CIImage (except there's no CIImage -> CGImageRef and can't be from the looks of the API).

QIcon <=> HICON
QImage/QPixmap <=> HBITMAP, CGImageRef, NSImage, UIImage, CIImage
QString <=> CFStringRef, NSString

Anything else?

After all this, though, I think we should still implement the constructors and operators in terms of free functions so that the converters are also usable by Qt 4.

Are there any objections to this? Can we start adding constructors and operators to QtCore and QtGui?
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: ***@petroules.com

On Mar 19, 2013, at 2:52 AM, Sorvig Morten <***@digia.com> wrote:

>
> On Mar 18, 2013, at 5:05 PM, Knoll Lars <***@digia.com> wrote:
>
>> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>>
>>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>>> wrote:
>>>
>>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>>> failures.
>>> See https://codereview.qt-project.org/#change,48905.
>>>
>>>
>>>
>>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>>
>> + Mac and X11 extras. Yes, these are known.
>
>
> QtMacExtras is currently not in a releasable state. It's missing documentation, some examples and needs some general polish and bug fixes.
>
> I think we also need to resolve the "native type" converters discussion to know which API's goes into QtMacExtras.
>
> Since we are running out of time for 5.1 - should we postpone it to 5.2?
>
> Morten
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2013-03-19 17:14:34 UTC
Permalink
On terça-feira, 19 de março de 2013 12.16.03, Jake Thomas Petroules wrote:
> As for the operators, I remember there was a discussion on IRC suggesting we
> simply declare the methods and operators and forward declare the types
> necessary in QtCore/QtGui, and implement them in
> QtWindowsExtras/QtMacExtras. Then the former need not link to any
> additional libraries.

You can't do that on Windows. All methods of an exported class must be in the
same DLL, or the DLL won't build.

> After all this, though, I think we should still implement the constructors
> and operators in terms of free functions so that the converters are also
> usable by Qt 4.
>
> Are there any objections to this? Can we start adding constructors and
> operators to QtCore and QtGui?

No.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Jake Thomas Petroules
2013-03-19 17:18:23 UTC
Permalink
On Mar 19, 2013, at 1:14 PM, Thiago Macieira <***@intel.com> wrote:

> On terça-feira, 19 de março de 2013 12.16.03, Jake Thomas Petroules wrote:
>> As for the operators, I remember there was a discussion on IRC suggesting we
>> simply declare the methods and operators and forward declare the types
>> necessary in QtCore/QtGui, and implement them in
>> QtWindowsExtras/QtMacExtras. Then the former need not link to any
>> additional libraries.
>
> You can't do that on Windows. All methods of an exported class must be in the
> same DLL, or the DLL won't build.


Oh, interesting. We link to all the libraries that have the Windows types anyways,
so it shouldn't be a problem to include them directly in QtCore/QtGui, right?
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: ***@petroules.com
Thiago Macieira
2013-03-19 17:42:16 UTC
Permalink
On terça-feira, 19 de março de 2013 13.18.23, Jake Thomas Petroules wrote:
> On Mar 19, 2013, at 1:14 PM, Thiago Macieira <***@intel.com>
wrote:
> > On terça-feira, 19 de março de 2013 12.16.03, Jake Thomas Petroules wrote:
> >> As for the operators, I remember there was a discussion on IRC suggesting
> >> we simply declare the methods and operators and forward declare the
> >> types necessary in QtCore/QtGui, and implement them in
> >> QtWindowsExtras/QtMacExtras. Then the former need not link to any
> >> additional libraries.
> >
> > You can't do that on Windows. All methods of an exported class must be in
> > the same DLL, or the DLL won't build.
>
> Oh, interesting. We link to all the libraries that have the Windows types
> anyways, so it shouldn't be a problem to include them directly in
> QtCore/QtGui, right?

Right, but we may want to wait for 5.2 then. Don't rush new features you've
just started discussing in the week of the feature freeze.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Friedemann Kleint
2013-03-20 07:52:45 UTC
Permalink
Hi,

>>...[Extras image conversion]... for the operators, I remember there
was a discussion on IRC suggesting we
>>simply declare the methods and operators and forward declare the types
>>necessary in QtCore/QtGui, and implement them in
>>QtWindowsExtras/QtMacExtras. Then the former need not link to any
additional libraries.

> You can't do that on Windows. All methods of an exported class must
be in the same DLL, or the DLL won't build.

But it should be possible by introducing a special export macro for it -
such that the application sees "export", and while building the library,
"import" is seen?

Friedemann

--
Friedemann Kleint
Digia, Qt
Thiago Macieira
2013-03-20 15:07:48 UTC
Permalink
On quarta-feira, 20 de março de 2013 08.52.45, Friedemann Kleint wrote:
> But it should be possible by introducing a special export macro for it -
> such that the application sees "export", and while building the library,
> "import" is seen?

It might be possible to do that. Someone needs to test it:

class Q_CORE_EXPORT Foo
{
public:
void thisMethodIsInCore();
Q_GUI_EXPORT void thisMethodIsInGui();

bool thisIsInline() { return true; }
};

Please try compiling QtCore, QtGui and an application, in debug mode, calling
all three methods (except for the Gui method in QtCore).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Knoll Lars
2013-03-18 19:31:03 UTC
Permalink
On 3/18/13 6:36 PM, "Thiago Macieira" <***@intel.com> wrote:

>On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote:
>> We have said that we'll move to time based releases. Should we stop this
>> because we aren't yet good enough in controlling our systems? I don't
>> think so. It might feel unfair to some people, but we've had these
>> discussions about some features missing the deadline every single minor
>> release.
>>
>> Now if there are one or two features that are vital to make Qt 5.1
>> possible, we can discuss exceptions for those. But then we need to make
>> sure they go in in the next two days. Which features would these be?
>
>I know of only the QUrlPathInfo and the timezone features, plus minor API
>changes, for QtCore. The former is something that had been lost in my
>large
>dashboard until last week, and John's changes were too big to review
>while I
>was at a conference.

Yes. I doubt we'll get timezone done in time though, unless you're happy
with the API as it is now.

The file selectors would be very helpful for declarative. Getting it in is
important, because I'd like to set the standard before everybody does his
own. I think BlackBerry might also need it to move over to Qt 5 at some
point

>
>> >> - I haven't planed to create any branch yet for commits already in
>> >>
>> >>'stable' and not in 'release'. So speak up if this is needed.
>> >
>> >in fact, thiago and me already decided that we'll create an old/5.0
>> >branch from stable right before we merge dev.
>>
>> Not that I'm principally opposed to this, but please remember proper
>> process: These should at least get discussed on this ML, not just get
>> decided by two people and then announced.
>
>I thought it was discussed on the mailing list.

Ok, I might have missed it. The way Ossi put it, it sounded like an IRC
discussion.

Cheers,
Lars
Thiago Macieira
2013-03-18 22:52:40 UTC
Permalink
On segunda-feira, 18 de março de 2013 19.31.03, Knoll Lars wrote:
> >I know of only the QUrlPathInfo and the timezone features, plus minor API
> >changes, for QtCore. The former is something that had been lost in my
> >large
> >dashboard until last week, and John's changes were too big to review
> >while I
> >was at a conference.
>
> Yes. I doubt we'll get timezone done in time though, unless you're happy
> with the API as it is now.

I'll do my best to review it.

> The file selectors would be very helpful for declarative. Getting it in is
> important, because I'd like to set the standard before everybody does his
> own. I think BlackBerry might also need it to move over to Qt 5 at some
> point

I delegated that because I had no time. Therefore, I will abide by the
decisions of whoever did review it.

I would still like it work for the Mac HighDPI functionality and work with
QFile. I don't want a class in QtCore that can't be used with other QtCore
classes directly.

> >> >in fact, thiago and me already decided that we'll create an old/5.0
> >> >branch from stable right before we merge dev.
> >>
> >> Not that I'm principally opposed to this, but please remember proper
> >> process: These should at least get discussed on this ML, not just get
> >> decided by two people and then announced.
> >
> >I thought it was discussed on the mailing list.
>
> Ok, I might have missed it. The way Ossi put it, it sounded like an IRC
> discussion.

He surprised me too.

And if it was an IRC conclusion, he could have said "we came to the conclusion
that creating old/5.0 is a good idea".

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