Re: [Development] Source incompatible proposal: removing Qt::WA_ values for widget orientation

[Robin Burchell]

On Thu, Dec 15, 2011 at 7:43 AM,   wrote:
> It's not worth it IMO. Let's remove them.

Done:
http://codereview.qt-project.org/#change,11280
http://codereview.qt-project.org/#change,11281 (is also sort of
related, relies on 11280)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature defines in Qt 5?

[Olivier Goffart]

On Monday 12 December 2011 15:21:40 Stephen Kelly wrote:
> Hi there,
> 
> Is there any plan to keep or remove the defines in features.txt in Qt 5?
> (eg, QT_NO_SQL, QT_NO_DATESTRING etc)
> 
> A colleague told me about talk of removing all the ifdefs, but he thought
> he'd convinced whoever it was he was talking to that the stuff should be
> kept.
> 
> Is it something that would need to be modularised?


There is the feature that are disabled in the boostrapping phase. Thos might 
stay.

For the other ones: The policy in Qt 4 was that we do not maintain them, but 
we leave them there (as they do not hurt in most cases) and accept patches 
that fix them.
I don't see why we should change that. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze date?

[Peter Hartmann]

On 12/14/2011 06:42 PM, ext Thiago Macieira wrote:
> On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote:
>> Ok, well let's start the list:
>>
>> https://wiki.qt-project.org/5.0_Feature_Requirements

my addition for network (feel free to point out more):


== Network ==

* SSL errors (+ OCSP etc.): make it possible to display SSL errors 
without stalling QNetworkAccessManager 
(http://bugreports.qt.nokia.com/browse/QTBUG-19032)

* Authentication: make it possible to display authentication dialog 
without stalling QNetworkAccessManager 
(https://bugreports.qt.nokia.com/browse/QTBUG-16251); this is obviously 
closely tied to above task

* remove QHttp (https://bugreports.qt.nokia.com/browse/QTBUG-22750)

* rewrite cookie jar (https://bugreports.qt.nokia.com/browse/QTBUG-23145)


Peter


>>
>> One thing we could do is:
>>
>> 1. Let people populate the list
>> 2. Review the list for plausibility in a reasonable timeframe
>>  and personal availability.
>> 3. Estimate the time for the responsible people to get the work done.
>> 4. Schedule feature freeze based on that.
>> 5. Features that unfortunately don't get finished by then don't make
>>  it into 5.0, and possibly .x.
>>
>> That's just an idea of how to make progress though. Making a scheduling
>> decision without any idea of what needs to be done in that timeframe doesn't
>> really make sense.
>
> That's why I started the thread. We need to know what we need to do so we can
> make a scheduling decision. Or, alternatively, we need to decide what we can
> do given the schedule.
>
> I also oppose to your item #5 above. I don't want to see anything on a page
> called "5.0 requirements" that can be postponed. I want *only* the stuff that
> *must* go into 5.0, i.e., what cannot go into 5.1 or a later release until
> 6.0.
>
> If we reach the feature freeze date and a requirement isn't complete yet,
> we'll need to make a call whether to delay the freeze or not. This is
> something we'll do only for 5.0, as for any future releases, anything can be
> postponed.  That also means we don't have "feature requirements", but only a
> wish-list. [That's between us developers; in public communication we may call
> them differently]
>
> For those things that can be postponed, we should have a separate roadmap
> page. We can also start collecting ideas for future releases.
>
 Backward incompatible change freeze?
 (Yes)
>>>
>>> See above on both SIC and BIC changes.
>>
>> Right. This would be soft-frozen probably at RC or beta time.
>
> Depending on whether you referred to source or binary incompatible changes;
> and for the source ones, it's understood it applies to new features only.
>
>>> Of the "I can't judge" QtWidgets features above, considering that module
>>> is
>>> in Done state and we have a source-compatible requirement for 5.0 for
>>> existing features, I would wager that they are not Qt 5.0 requirements.
>>
>> Yes, but there are also lessons which we need to ensure are not forgotten so
>> that we have useful API for QML. An example is the QCompletion stuff. Doing
>> that 'properly' and in a future-proof, QML compatible way probably actually
>> depends on itemmodels getting new features, such as a virtual search()
>> method to supercede the match() method. That's just an example. There may
>> be others.
>
> I agree. However, we'll never finish finding new requirements or need to 
> improve
> the API, so we need to make a cut somewhere based on our best understanding. I
> might be an optimist here, but I'd have expected all these studies where we
> need new API to have completed by now. We're 5 months into the 5.0 cycle, 1
> year into the QtDeclarative API, 6½ years since ItemViews and the rest of the
> Qt 4 API.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Qt Commercial 4.8.0 release delta to LGPL version

[Turunen Tuukka]

Hi All,

Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you 
e-mail about the delta between these.

We have worked hard with 4.8 to improve it for desktop and embedded platforms 
according to the needs of commercial licensees. We have fixed a lot of bugs and 
included support to new platforms. While doing these, we have made close to 200 
contributions in the past few months, but unfortunately not all these have yet 
been merged in to Qt.

So now there is total of 108 improvements and bug fixes available in Qt 
Commercial 4.8.0 that are not part of the LGPL release. I want to underline 
that this is not the intended way of differentiating our offering. Going 
forward I hope that we can be more aligned. I would like to see most of the 
current delta integrated to Qt by the time of 4.8.1, if it is possible.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: 
www.digia.com
 or qt.digia.com

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

Re: [Development] Feature defines in Qt 5?

[Stephen Kelly]

On Thursday, December 15, 2011 11:06:47 you wrote:
> On Monday 12 December 2011 15:21:40 Stephen Kelly wrote:
> > Hi there,
> > 
> > Is there any plan to keep or remove the defines in features.txt in Qt 5?
> > (eg, QT_NO_SQL, QT_NO_DATESTRING etc)
> > 
> > A colleague told me about talk of removing all the ifdefs, but he
> > thought
> > he'd convinced whoever it was he was talking to that the stuff should be
> > kept.
> > 
> > Is it something that would need to be modularised?
> 
> There is the feature that are disabled in the boostrapping phase. Thos might
> stay.
> 
> For the other ones: The policy in Qt 4 was that we do not maintain them, but
> we leave them there (as they do not hurt in most cases) and accept patches
> that fix them.
> I don't see why we should change that.

Nor do I. We've certainly had cases where it was useful to have them there.

The reason I'm bringing it up is that I want to be able to communicate through 
the CMake files which features Qt was built excluding. 

For example, if Qt was built with QT_NO_DATESTRING, it makes sense for all 
downstreams to define QT_NO_DATESTRING too.

Obviously I don't want to do that work if there is a plan to remove the 
features and the ifdefs themselves. If the plan is not to remove them, then I 
can go ahead with the work.

Thanks,

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

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removing QtWebkit from gerrit (& qt5.git)

[Simon Hausmann]

On Thursday, December 15, 2011 07:53:29 AM Knoll Lars wrote:
> On 12/12/11 6:21 PM, "ext Robin Burchell"  wrote:
> >On Thu, Dec 8, 2011 at 12:20 AM, Rohan McGovern
> >
> > wrote:
> >> Unfortunately the qtwebkit pointed at by qt5.git is outdated and known
> >> not to work.
> >
> >Given that webkit is developed upstream inside webkit.org, I'd second
> >that there's no reason having it there, aside perhaps from CI, though
> >AFAIK they have their own infrastructure for this.
> >
> >As qtwebkit adds hugely to cloning qt5 (unless you remember to disable
> >it), as well as the frequent build problems for people new to Qt 5
> >etc, is there any real objection to it being removed? Who can make
> >that decision (I guess Lars?), and who would handle doing that?
> 
> I don't have any fundamental issues with removing it, but would like to
> hear some comments from people working on QtWebKit. Simon, any comments
> from your side?

I don't mind if you'd like to remove the entry to QtWebKit from qt5.git right 
now, but as Alexis also pointed out:

We have every intention of bringing it back, and we have somebody working on 
it.

WebKit may not be developed in Gerrit itself, but we do want to be part of the 
Qt product and its release. We do want that a Qt 5.0.0 tag in qt5.git includes 
a sha1 for a WebKit release.

The build system parts I believe are mostly resolved (WebKit trunk's build 
system is overhauled and should integrate nicely). What we are lacking is a 
git repository that contains a reduced set of files and is therefore faster to 
clone. Along with that we are also lacking a slightly more structured module 
release process.


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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Frans Klaver]

On Thu, Dec 15, 2011 at 12:21 PM, Turunen Tuukka
 wrote:

> Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send
> you e-mail about the delta between these.
>
> We have worked hard with 4.8 to improve it for desktop and embedded
> platforms according to the needs of commercial licensees. We have fixed a
> lot of bugs and included support to new platforms. While doing these, we
> have made close to 200 contributions in the past few months, but
> unfortunately not all these have yet been merged in to Qt.
>
> So now there is total of 108 improvements and bug fixes available in Qt
> Commercial 4.8.0 that are not part of the LGPL release. I want to underline
> that this is not the intended way of differentiating our offering. Going
> forward I hope that we can be more aligned. I would like to see most of the
> current delta integrated to Qt by the time of 4.8.1, if it is possible.

Wouldn't it make sense to have some people from digia as maintainers
or approvers?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Robin Burchell]

On Thu, Dec 15, 2011 at 12:45 PM, Frans Klaver  wrote:
> Wouldn't it make sense to have some people from digia as maintainers
> or approvers?

If they earn the position through work and trustworthiness, sure. You
don't just parachute people in because it might make sense.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[sinan.tanilkan]

Hi,

Thank you for you summary Tuukka.

We hope to move Qt 4 to Gerrit soon. This should enable faster handling of 
contributions.

Best regards,
Sinan Tanilkan
Mobile Phones Middleware - Integration and Quality Engineering
http://wikis.in.nokia.com/QtQualityEngineering

From: development-bounces+sinan.tanilkan=nokia@qt-project.org 
[development-bounces+sinan.tanilkan=nokia@qt-project.org] on behalf of ext 
Turunen Tuukka [tuukka.turu...@digia.com]
Sent: Thursday, December 15, 2011 12:21 PM
To: development@qt-project.org
Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version


Hi All,

Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you 
e-mail about the delta between these.

We have worked hard with 4.8 to improve it for desktop and embedded platforms 
according to the needs of commercial licensees. We have fixed a lot of bugs and 
included support to new platforms. While doing these, we have made close to 200 
contributions in the past few months, but unfortunately not all these have yet 
been merged in to Qt.

So now there is total of 108 improvements and bug fixes available in Qt 
Commercial 4.8.0 that are not part of the LGPL release. I want to underline 
that this is not the intended way of differentiating our offering. Going 
forward I hope that we can be more aligned. I would like to see most of the 
current delta integrated to Qt by the time of 4.8.1, if it is possible.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: www.digia.com or 
qt.digia.com

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

Re: [Development] Feature freeze date?

[Stephen Kelly]

On Wednesday, December 14, 2011 18:42:49 Thiago Macieira wrote:
> On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote:
> > Ok, well let's start the list:
> > 
> > https://wiki.qt-project.org/5.0_Feature_Requirements
> > 
> > One thing we could do is:
> > 
> > 1. Let people populate the list
> > 2. Review the list for plausibility in a reasonable timeframe
> > 
> > and personal availability.
> > 
> > 3. Estimate the time for the responsible people to get the work done.
> > 4. Schedule feature freeze based on that.
> > 5. Features that unfortunately don't get finished by then don't make
> > 
> > it into 5.0, and possibly .x.
> > 
> > That's just an idea of how to make progress though. Making a scheduling
> > decision without any idea of what needs to be done in that timeframe
> > doesn't really make sense.
> 
> That's why I started the thread. We need to know what we need to do so we
> can make a scheduling decision. Or, alternatively, we need to decide what
> we can do given the schedule.
> 
> I also oppose to your item #5 above. I don't want to see anything on a page
> called "5.0 requirements" that can be postponed. I want *only* the stuff
> that *must* go into 5.0, i.e., what cannot go into 5.1 or a later release
> until 6.0.

My item number 5 is for stuff like 'We wanted the new {QUrl,QDateTime,QLocale} 
but the work is not in gerrit for reason x, so while it would have been nice, 
we'll have to manage without it, as we have managed with it in Qt4 up to now.'

It's for 'If it happens at all it will have to happen for 5.0. It can't happen 
after that, and if if doesn't happen before that, then it doesn't happen' 
items.

So yes, as you write below (snipped), it's more of a wish-list.



> > Yes, but there are also lessons which we need to ensure are not
> > forgotten so that we have useful API for QML. An example is the
> > QCompletion stuff. Doing that 'properly' and in a future-proof, QML
> > compatible way probably actually depends on itemmodels getting new
> > features, such as a virtual search() method to supercede the match()
> > method. That's just an example. There may be others.
> 
> I agree. However, we'll never finish finding new requirements or need to
> improve the API, so we need to make a cut somewhere based on our best
> understanding. I might be an optimist here, but I'd have expected all these
> studies where we need new API to have completed by now. We're 5 months into
> the 5.0 cycle, 1 year into the QtDeclarative API, 6½ years since ItemViews
> and the rest of the Qt 4 API.

True, but for the most part, realistic and achievable plans for Qt5 API are a 
recent thing, any maybe are still only in the heads of people who have been 
working on the stuff in TT/Nokia.

Thanks,

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

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Frans Klaver]

On Thu, Dec 15, 2011 at 12:50 PM, Robin Burchell  wrote:
> On Thu, Dec 15, 2011 at 12:45 PM, Frans Klaver  wrote:
>> Wouldn't it make sense to have some people from digia as maintainers
>> or approvers?
>
> If they earn the position through work and trustworthiness, sure. You
> don't just parachute people in because it might make sense.

I didn't intend to suggest that they should be parachuted in. It could
be worth investigating if some people from digia may have already
shown that they fit the bill. As far as I know current maintainers and
approvers have the possibility to nominate someone for a position, but
if no one cares to do that, there won't be any progress. I could be
wrong though. A lot of desktop users of Qt would probably be happy if
for example QtWidgets fixes end up in the main-line development
quickly.

If no one from digia has shown enough merit, there's no point in promoting them.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Your target features for Qt 5.0

[Stephen Kelly]

Hi,

I'm just creating a new thread for greater visibility. 

Please collect your target features for Qt 5.0 in this wiki page:

https://wiki.qt-project.org/5.0_Feature_Targets

Please avoid adding features that can be added in a subsequent 5.x release and 
limit your entries only to features that must be in 5.0 for source 
compatibility, binary compatibility or behaviour compatbility reasons.

The list will be used for tracking progress schedule and goals for the 5.0, so 
having features in your head is not enough.

More context here:

http://thread.gmane.org/gmane.comp.lib.qt.devel/887

On Thursday, December 15, 2011 06:40:35 lars.kn...@nokia.com wrote:
> Once we have the list, let's go through it and do some estimations of what
> it requires. But let's avoid falling into the trap of requiring a perfect
> world/solution. No matter how much time we give ourselves, we won't be
> able to do everything we maybe would like to do, and we'll have to cut of
> at some point.

Thanks,

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

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze date?

[Stephen Kelly]

On Wednesday, December 14, 2011 20:53:16 you wrote:
> 3. What about recently (and quite vigorously) discussed RegExp
> overhaul? It is not on the list (yet). Should it be added? As far as I
> gather from the discussion (I can't judge that myself fully), it is
> pretty big, and poses a threat to BC (in QString).

I've added it now.

Feel free to bring up or add anything else that you think is missing.

Thanks,

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

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature defines in Qt 5?

[Thiago Macieira]

On Thursday, 15 de December de 2011 12.25.10, Stephen Kelly wrote:
> The reason I'm bringing it up is that I want to be able to communicate
> through  the CMake files which features Qt was built excluding.
>
> For example, if Qt was built with QT_NO_DATESTRING, it makes sense for all
> downstreams to define QT_NO_DATESTRING too.

Isn't the define available for everyone including cmake? It should be in
qconfig.h, which is installed.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature defines in Qt 5?

[Stephen Kelly]

On Thursday, December 15, 2011 13:12:42 Thiago Macieira wrote:
> On Thursday, 15 de December de 2011 12.25.10, Stephen Kelly wrote:
> > The reason I'm bringing it up is that I want to be able to communicate
> > through  the CMake files which features Qt was built excluding.
> > 
> > For example, if Qt was built with QT_NO_DATESTRING, it makes sense for
> > all downstreams to define QT_NO_DATESTRING too.
> 
> Isn't the define available for everyone including cmake? It should be in
> qconfig.h, which is installed.

You're right. I think that is probably enough. I'll do some experimentation.

Thanks,

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

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Olivier Goffart]

On Thursday 15 December 2011 11:53:12 sinan.tanil...@nokia.com wrote:
> Hi,
> 
> Thank you for you summary Tuukka.
> 
> We hope to move Qt 4 to Gerrit soon. This should enable faster handling of
> contributions.

Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?

I also see a lot of commit in Qt 4.8 that are not in Qt5. This is a problem.




> 
> Best regards,
> Sinan Tanilkan
> Mobile Phones Middleware - Integration and Quality Engineering
> http://wikis.in.nokia.com/QtQualityEngineering
> 
> From: development-bounces+sinan.tanilkan=nokia@qt-project.org
> [development-bounces+sinan.tanilkan=nokia@qt-project.org] on behalf of
> ext Turunen Tuukka [tuukka.turu...@digia.com] Sent: Thursday, December 15,
> 2011 12:21 PM
> To: development@qt-project.org
> Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version
> 
> 
> Hi All,
> 
> Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send
> you e-mail about the delta between these.
> 
> We have worked hard with 4.8 to improve it for desktop and embedded
> platforms according to the needs of commercial licensees. We have fixed a
> lot of bugs and included support to new platforms. While doing these, we
> have made close to 200 contributions in the past few months, but
> unfortunately not all these have yet been merged in to Qt.
> 
> So now there is total of 108 improvements and bug fixes available in Qt
> Commercial 4.8.0 that are not part of the LGPL release. I want to underline
> that this is not the intended way of differentiating our offering. Going
> forward I hope that we can be more aligned. I would like to see most of the
> current delta integrated to Qt by the time of 4.8.1, if it is possible.
> 
> Yours,
> 
> --
> Tuukka Turunen
> Director, Qt Commercial R&D
> Digia Plc
> Piippukatu 11, 40100 Jyväskylä, Finland
> 
> Visit us at: www.digia.com or
> qt.digia.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Thiago Macieira]

On Thursday, 15 de December de 2011 13.01.06, Frans Klaver wrote:
> I didn't intend to suggest that they should be parachuted in. It could
> be worth investigating if some people from digia may have already
> shown that they fit the bill. As far as I know current maintainers and
> approvers have the possibility to nominate someone for a position, but
> if no one cares to do that, there won't be any progress. I could be
> wrong though. A lot of desktop users of Qt would probably be happy if
> for example QtWidgets fixes end up in the main-line development
> quickly.
>
> If no one from digia has shown enough merit, there's no point in promoting
> them.

I've spoken about this to Tuukka in a couple of occasions. It's my
understanding that getting the Digia engineers become approvers and eventually
maintainers for the parts they work mostly on is their intention too.

However, right now, those engineers are mostly working on Qt 4.8, which is not
part of Gerrit, so any work they might have been doing is lost to us.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Atlant Schmidt]

Tuukka:

  How can we most-easily discover the list of changes that
  are in Qt Commercial 4.8.0 but not in (LGPL) Qt 4.8.0?

  We have several bugs we're particularly interested in...

 Atlant

From: development-bounces+aschmidt=dekaresearch@qt-project.org 
[mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf 
Of Turunen Tuukka
Sent: Thursday, December 15, 2011 06:22
To: development@qt-project.org
Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version


Hi All,

Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you 
e-mail about the delta between these.

We have worked hard with 4.8 to improve it for desktop and embedded platforms 
according to the needs of commercial licensees. We have fixed a lot of bugs and 
included support to new platforms. While doing these, we have made close to 200 
contributions in the past few months, but unfortunately not all these have yet 
been merged in to Qt.

So now there is total of 108 improvements and bug fixes available in Qt 
Commercial 4.8.0 that are not part of the LGPL release. I want to underline 
that this is not the intended way of differentiating our offering. Going 
forward I hope that we can be more aligned. I would like to see most of the 
current delta integrated to Qt by the time of 4.8.1, if it is possible.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: 
www.digia.com
 or qt.digia.com




Click 
here
 to report this email as spam.


This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze date?

[João Abecasis]

Tomasz Siekierda wrote:
> Now, 2 possible additions to the freeze list:
> 3. What about recently (and quite vigorously) discussed RegExp
> overhaul? It is not on the list (yet). Should it be added? As far as I
> gather from the discussion (I can't judge that myself fully), it is
> pretty big, and poses a threat to BC (in QString).

I think we should be able to remove QRegExp from QtCore's ABI, and that 
shouldn't be too much work (remember to quote me on that ;-). That would mean 
QRegExp would be available in a separate library, but wouldn't otherwise break 
source compatibility. 

> 4. V8 location - still not fully agreed, but it should be put in it's
> final place before freeze (or no?).

V8 is not part of the public ABI, I think. Where the repository ends up 
shouldn't matter, anyway.

Cheers,


João

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Turunen Tuukka]

>  How can we most-easily discover the list of changes that
>  are in Qt Commercial 4.8.0 but not in (LGPL) Qt 4.8.0?
Easiest is probably to diff source, but if you do not want to check out the Qt 
Commercial evaluation, you can see pending 4.8 merge requests in 
https://qt.gitorious.org/qt/qt/merge_requests, or compare the release notes.

I do not think the delta between these releases is not that relevant as such, 
it is more important that delta is smaller in the next patch release.

Yours,

Tuukka

From: 
development-bounces+aschmidt=dekaresearch@qt-project.org
 [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On 
Behalf Of Turunen Tuukka
Sent: Thursday, December 15, 2011 06:22
To: development@qt-project.org
Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version


Hi All,

Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you 
e-mail about the delta between these.

We have worked hard with 4.8 to improve it for desktop and embedded platforms 
according to the needs of commercial licensees. We have fixed a lot of bugs and 
included support to new platforms. While doing these, we have made close to 200 
contributions in the past few months, but unfortunately not all these have yet 
been merged in to Qt.

So now there is total of 108 improvements and bug fixes available in Qt 
Commercial 4.8.0 that are not part of the LGPL release. I want to underline 
that this is not the intended way of differentiating our offering. Going 
forward I hope that we can be more aligned. I would like to see most of the 
current delta integrated to Qt by the time of 4.8.1, if it is possible.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: 
www.digia.com
 or qt.digia.com




Click 
here
 to report this email as spam.


This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[marius.storm-olsen]

I'm sure that will improve significantly once we get the sources into Gerrit, 
as it will drastically reduce the round-trip time for reviews, and will make 
the patches more visible to everybody.

So, great job everybody on getting Qt 4.8.0 out; now let's get the wheels 
turning on moving Qt 4.x over!

Thanks!
--
.marius

From: development-bounces+marius.storm-olsen=nokia@qt-project.org 
[mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On 
Behalf Of ext Turunen Tuukka
Sent: Thursday, December 15, 2011 7:05 AM
To: Atlant Schmidt; development@qt-project.org
Subject: Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

>  How can we most-easily discover the list of changes that
>  are in Qt Commercial 4.8.0 but not in (LGPL) Qt 4.8.0?
Easiest is probably to diff source, but if you do not want to check out the Qt 
Commercial evaluation, you can see pending 4.8 merge requests in 
https://qt.gitorious.org/qt/qt/merge_requests, or compare the release notes.

I do not think the delta between these releases is not that relevant as such, 
it is more important that delta is smaller in the next patch release.

Yours,

Tuukka

From: 
development-bounces+aschmidt=dekaresearch@qt-project.org
 [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On 
Behalf Of Turunen Tuukka
Sent: Thursday, December 15, 2011 06:22
To: development@qt-project.org
Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version


Hi All,

Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you 
e-mail about the delta between these.

We have worked hard with 4.8 to improve it for desktop and embedded platforms 
according to the needs of commercial licensees. We have fixed a lot of bugs and 
included support to new platforms. While doing these, we have made close to 200 
contributions in the past few months, but unfortunately not all these have yet 
been merged in to Qt.

So now there is total of 108 improvements and bug fixes available in Qt 
Commercial 4.8.0 that are not part of the LGPL release. I want to underline 
that this is not the intended way of differentiating our offering. Going 
forward I hope that we can be more aligned. I would like to see most of the 
current delta integrated to Qt by the time of 4.8.1, if it is possible.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: 
www.digia.com
 or qt.digia.com





Click 
here
 to report this email as spam.


This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Frans Klaver]

On Thu, Dec 15, 2011 at 1:29 PM, Thiago Macieira
 wrote:

> I've spoken about this to Tuukka in a couple of occasions. It's my
> understanding that getting the Digia engineers become approvers and eventually
> maintainers for the parts they work mostly on is their intention too.

Right.

> However, right now, those engineers are mostly working on Qt 4.8, which is not
> part of Gerrit, so any work they might have been doing is lost to us.

Hm, that explains something at least. If Olivier is correct about them
not following some policy then it's not too surprising some work got
lost on the way.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QRegularExpression -- first round of API review

[Giuseppe D'Angelo]

Hi everybody. Sorry for the length of thjis message, but doing API
reviews by mail is hard, and I needed to explain many decisions here and
there (and, of course, the API itself). :-(

Attached to this mail (and also here:  --
if you don't want to download and open a file) you can find a stripped
down version of the QRegularExpression API I'm working on. It's
deliberately stripped down because at this stage I'd like to have
feedbacks about the API and not about the code itself. We're still free
of changing all parts of it, so, even if you dislike the tiniest bit of
something, please go ahead and say it.

And it's deliberaltely without comments, so the reader's exercise now is
reading it and finding out if it's understandable at a first glance.
Once you're done, I'll start commenting the non-obvious points.

General
As discussed, two implicitly shared, copy on write, reentrant value
classes: the regexp itself (pattern + options) and the result of a match
against a subject string (fixes the T7 in
 ). The regexp
also stores the compiled form of itself as an hidden optimization --
most const methods actually do modify the shared instance. The backend
is PCRE so the feature set is quite big (fixing T1-T4). I have already
planned to expand the enums to support even more options.

QRegularExpression
  PatternOptions
The PatternOptions flag contains the pattern options, i.e. modify the
characters that the pattern should match.

*   CaseInsensitiveOption is the /i flag (case Insensitive Match). In
QRegExp it was set by a separate method (setCaseSensitivity),
holding a Qt::CaseSensitivity value. Here IMHO it just clutters the
API to have different getters and setters for the options.

*   InvertedGreedinessOption is the /U flag (not present in Perl)
inverts the greediness of the quantifiers: they became not greedy by
default, and greedy if followed by ?. See also the T3 in the list.

*   DotMatchesEverythingOption is the /s flag (Single line match): the
dot (.) metacharacter matches everything including newlines.

*   MultilineMatchOption is the /m flag (Multi line match): the caret
(^) and the dollar ($) metacharacters are allowed to match at (and
just before) any newline inside the string (as well as the ordinary
begin and end of the string)

*   ExtendedPatternSyntaxOption is the /x flag (eXtended pattern
syntax): whitespace data inside the regexp is ignored, and an
unescaped # outside a character class starts a comment that goes
till the next newline (inside the pattern!). It's probably not very
useful in C++, where one can use the default rules for string
literals, but it may be handy if one stores complicated regexps in
an external file.

*   UseUnicodePropertiesOption enables the use Unicode properties for
character classes such as \w, \s, \d, etc. (and obviously their
counterparts \W, \S, etc.), instead of making them just match the
standard ASCII ranges

*   AllowDuplicatedNamesOption allows duplicated named capturing
patterns (that is (? ... ) patterns)

*   DontCaptureOption disables the use of unnamed capturing parenthesis
-- they all behave as if they all were (?:...) parenthesis. Named
ones continue to work.

*   MatchFirstlineOnlyOption restricts an unanchored pattern to start to
match only before the first newline (although the match can continue
over it).

*   DollarMatchesOnlyAtEndOption changes the meaning of the dollar ($)
metacharacter to match only at the very end of the string, while
usually it matches at the end AND at a newline right before the end

  CompileHints
The CompileHints are hints to the regexp engine itself. Basically they
control the optimization of the compiled regexp (the PCRE API is
pcre_study).

*   StudyPatternCompileHint tells PCRE engine to study the pattern,
which basically means performing very simple optimization tasks
(f.i., the engine records the minimum size of a string to get a
successful match, and if the subject string is shorter the match
aborts immediately)

*   JitCompileHint implies StudyPatternCompileHint, and enables the JIT
compilation of the pattern. Of course this has a cost, and there's a
tradeoff to consider between spending time compilating the regexp
instead of just matching against a string.

  MatchOptions
The MatchOptions control the match itself.

*   AnchoredMatch forces the match to start at the first matching point
inside the subject string, even if the regexp doesn't have carets or
other metacharacters that normally force such a match

Re: [Development] QRegularExpression -- first round of API review

[Oswald Buddenhagen]

On Thu, Dec 15, 2011 at 04:43:49PM +, ext Giuseppe D'Angelo wrote:
>pos, matchedLength, endPos
>
inconsistent naming

> void setPatternOptions(PatternOptions options, bool on = true);
> 
i don't like that too much, because *un*setting options en masse sucks -
you need to make a "block" of options to set, and a "block" of options
to delete. that's half as bad if all options are off by default, but
then one has to wonder whether a way to unset them actually makes sense
in the first place.
fwiw, the usual elegant solution is having a value and a mask parameter.
the mask could have two magic values meaning "un-/set all asserted in
vlaue" to mean effectively what your bool means. the default argument
would be the magic value for setting, so the standard syntax would set
all flags named in the first argument.

just the obvious. i'll let others have the real fun. ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Robin Burchell]

Hi Tuukka,

(now that I've left some hours to digest this...)

2011/12/15 Turunen Tuukka :
> So now there is total of 108 improvements and bug fixes available in Qt
> Commercial 4.8.0 that are not part of the LGPL release. I want to underline
> that this is not the intended way of differentiating our offering. Going
> forward I hope that we can be more aligned. I would like to see most of the
> current delta integrated to Qt by the time of 4.8.1, if it is possible.

First: let me say thanks for bringing this up sooner rather than
later. That is certainly quiet a backlog (in a bad way), and one that
should be addressed ASAP, if not yesterday :). It's also pleasing to
hear that you want to work to bring these changes back to the Qt
Project.

In my opinion, there's two issues that need addressing here.

The first (already brought up) is gerrit. Gitorious' merge requests
are painful for everyone involved, so they're just going to slow you
down. Once things get into Gerrit, assuming they work in a similar
fashion to Qt 5, I think you'll find that changes can get pushed
forward a fair bit easier (especially assuming you know the right
people to poke for reviews, which I expect you do for the most part).

The second is that these changes have been going to Qt 4.8. Some
people seem to have assumed this was an issue, but I'm not entirely
sure this was correct, as I seem to recall that Ossi had a magical
script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that
is the case, there really isn't much further problem I think. If this
script doesn't do what I'm hoping, then we're going to have to figure
out how to get this work into Qt 5 with the minimum of pain (meaning
as soon as possible), before merging becomes impossible or at least
impractical.

So anyway, the summary of my thoughts on solving this would be:
- get 4.x into Gitorious ASAP
- get the changes into 4.x (can probably be ongoing while the above
isn't finished, but will be helped)
- cherry-pick them into Qt 5 (in any way possible) to make sure work
isn't lost or duplicated, since I assume that your customers will be
asking about Qt 5 sooner rather than later :)

...and we're back to working as one big, happy family in Gerrit :)

[1]: http://lists.qt-project.org/pipermail/development/2011-November/000483.html
- though this repo has apparently been merged into qtrepotools.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Robin Burchell]

Hi,

On Thu, Dec 15, 2011 at 1:23 PM, Olivier Goffart  wrote:
> On Thursday 15 December 2011 11:53:12 sinan.tanil...@nokia.com wrote:
>> We hope to move Qt 4 to Gerrit soon. This should enable faster handling of
>> contributions.
>
> Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?

I'd agree that would make sense to be a policy. But for it to be a
policy, it needs to be documented and communicated somewhere. You
can't expect this information to just filter out by itself, or expect
that it's common sense for everyone.

I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
Should it be?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Robin Burchell]

Hi,

On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell  wrote:
>> Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?
>
> I'd agree that would make sense to be a policy. But for it to be a
> policy, it needs to be documented and communicated somewhere. You
> can't expect this information to just filter out by itself, or expect
> that it's common sense for everyone.
>
> I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
> Should it be?

Actually, when I read this a second time looking for something
relevant, I see the complete opposite:

"11. Make sure you submit against the lowest applicable branch from
which a release is still planned. Cherry-picks ("backports") are
frowned upon, while forward-merging to more recent branches happens on
a regular basis."
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Moving QUndoStack and QUndoCommand out of QtWidgets

[Jesus Sanchez-Palencia]

Hi there,

I would like to gather your opinion on whether we should move
QUndoStack and QUndoCommand out of QtWidgets so they could be used
without requiring this module as an extra dependency.

After a brief investigation, I believe this could done by:

1- moving QUndoCommand entirely;

2- moving QUndoStack without moving the APIs that rely on or need
QAction (QAction *createUndoAction() and QAction *createRedoAction());

3- creating a new class (QUndoStackAction ??) inside QtWidgets and
implement the APIs mentioned above there (createUndoAction and
createRedoAction);

4- applying the same logic to QUndoGroup.


QtWebKit, for instance, would benefit from this immediately, as we aim
on removing the QtWidgets dependencies.

Suggestions, comments and any sort of feedback here would be more than welcome.

Thanks in advance,
Jesus Sanchez-Palencia
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Thursday 15 December 2011 22:31:32 Robin Burchell wrote:
> Hi,
> 
> On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell  
wrote:
> >> Wasn't the policy to first push the code in Qt5, then backport in Qt
> >> 4.8?> 
> > I'd agree that would make sense to be a policy. But for it to be a
> > policy, it needs to be documented and communicated somewhere. You
> > can't expect this information to just filter out by itself, or expect
> > that it's common sense for everyone.
> > 
> > I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
> > Should it be?
> 
> Actually, when I read this a second time looking for something
> relevant, I see the complete opposite:
> 
> "11. Make sure you submit against the lowest applicable branch from
> which a release is still planned. Cherry-picks ("backports") are
> frowned upon, while forward-merging to more recent branches happens on
> a regular basis."

Well, that is when the branches lies in the same repository.
With Qt 4 cannot be merged in Qt 5 because of the modularisation.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets

[Olivier Goffart]

On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
> Hi there,
> 
> I would like to gather your opinion on whether we should move
> QUndoStack and QUndoCommand out of QtWidgets so they could be used
> without requiring this module as an extra dependency.
> 
> After a brief investigation, I believe this could done by:
> 
> 1- moving QUndoCommand entirely;
> 
> 2- moving QUndoStack without moving the APIs that rely on or need
> QAction (QAction *createUndoAction() and QAction *createRedoAction());
> 
> 3- creating a new class (QUndoStackAction ??) inside QtWidgets and
> implement the APIs mentioned above there (createUndoAction and
> createRedoAction);
> 
> 4- applying the same logic to QUndoGroup.
> 
> 
> QtWebKit, for instance, would benefit from this immediately, as we aim
> on removing the QtWidgets dependencies.
> 
> Suggestions, comments and any sort of feedback here would be more than
> welcome.

I beleive QAction should also be moved back in QtGui
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QRegularExpression -- first round of API review

[joao.abecasis]

Hi Giuseppe,

I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm 
actually referring to the API.

I started looking at it and it seems too cluttered. Specially this early in the 
process. It's hard to review something that is trying to be everything or maybe 
it's just exposing too many things.

I would like to challenge you to do the opposite: give us the minimum API that 
can offer the most important features. To get there start from short 
self-contained code examples showing the features in use (I'm interested in 
seeing those) -- API design is about how it gets used, not so much about the 
number of features.

For instance, in Perl, regular expressions are essentially a string, a couple 
of operators and some magic variables for the captures (and lots of magic 
everywhere...). (Now, I'm not saying we should do regular expressions in Qt as 
they are done in Perl)

The API, as it stands seems too hard-wired to the implementation or feature set 
of the engine giving it little opportunity for evolving. Another issue is that 
it is hard for me to see if (or where) the API itself is imposing performance 
penalties on the implementation.

Finally, note that it is usually ok to add API as time goes by, but our BC 
promises mean we have to maintain most of what we add for a long time.

Cheers,


João


From: development-bounces+joao.abecasis=nokia@qt-project.org 
[development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext 
Giuseppe D'Angelo [dange...@gmail.com]
Sent: 15 December 2011 17:43
To: development@qt-project.org
Subject: [Development] QRegularExpression -- first round of API review

Hi everybody. Sorry for the length of thjis message, but doing API
reviews by mail is hard, and I needed to explain many decisions here and
there (and, of course, the API itself). :-(

Attached to this mail (and also here:  --
if you don't want to download and open a file) you can find a stripped
down version of the QRegularExpression API I'm working on. It's
deliberately stripped down because at this stage I'd like to have
feedbacks about the API and not about the code itself. We're still free
of changing all parts of it, so, even if you dislike the tiniest bit of
something, please go ahead and say it.

And it's deliberaltely without comments, so the reader's exercise now is
reading it and finding out if it's understandable at a first glance.
Once you're done, I'll start commenting the non-obvious points.

General
As discussed, two implicitly shared, copy on write, reentrant value
classes: the regexp itself (pattern + options) and the result of a match
against a subject string (fixes the T7 in
 ). The regexp
also stores the compiled form of itself as an hidden optimization --
most const methods actually do modify the shared instance. The backend
is PCRE so the feature set is quite big (fixing T1-T4). I have already
planned to expand the enums to support even more options.

QRegularExpression
  PatternOptions
The PatternOptions flag contains the pattern options, i.e. modify the
characters that the pattern should match.

*   CaseInsensitiveOption is the /i flag (case Insensitive Match). In
QRegExp it was set by a separate method (setCaseSensitivity),
holding a Qt::CaseSensitivity value. Here IMHO it just clutters the
API to have different getters and setters for the options.

*   InvertedGreedinessOption is the /U flag (not present in Perl)
inverts the greediness of the quantifiers: they became not greedy by
default, and greedy if followed by ?. See also the T3 in the list.

*   DotMatchesEverythingOption is the /s flag (Single line match): the
dot (.) metacharacter matches everything including newlines.

*   MultilineMatchOption is the /m flag (Multi line match): the caret
(^) and the dollar ($) metacharacters are allowed to match at (and
just before) any newline inside the string (as well as the ordinary
begin and end of the string)

*   ExtendedPatternSyntaxOption is the /x flag (eXtended pattern
syntax): whitespace data inside the regexp is ignored, and an
unescaped # outside a character class starts a comment that goes
till the next newline (inside the pattern!). It's probably not very
useful in C++, where one can use the default rules for string
literals, but it may be handy if one stores complicated regexps in
an external file.

*   UseUnicodePropertiesOption enables the use Unicode properties for
character classes such as \w, \s, \d, etc. (and obviously their
counterparts \W, \S, etc.), instead of making them just match the
standard ASCII ranges

*   AllowDuplicatedNamesOption allows dupli

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Charley Bay]

I'm quoting Robin's email (with some of my comments), because I think it
was a great message that I don't want "lost":

On Thu, Dec 15, 2011 at 2:16 PM, Robin Burchell wrote:

> Hi Tuukka,
>
> (now that I've left some hours to digest this...)
>
> 2011/12/15 Turunen Tuukka :
> > So now there is total of 108 improvements and bug fixes available in Qt
> > Commercial 4.8.0 that are not part of the LGPL release. I want to
> underline
> > that this is not the intended way of differentiating our offering. Going
> > forward I hope that we can be more aligned. I would like to see most of
> the
> > current delta integrated to Qt by the time of 4.8.1, if it is possible.
>
> First: let me say thanks for bringing this up sooner rather than
> later. That is certainly quiet a backlog (in a bad way), and one that
> should be addressed ASAP, if not yesterday :). It's also pleasing to
> hear that you want to work to bring these changes back to the Qt
> Project.
>

We're a Qt Commercial customer, and attended the Commercial Forums at Qt
Developer Days in San Francisco a few weeks ago, so this was not a surprise
to us.  The issue was explained (multiple development processes at
different organizations, current in-inefficiencies synchronizing
maintenance among the participants), and the greatest concern seemed to be
that the community-as-a-whole might be confused about how/why this
"result-came-about", when the only issue is simply that
community-management is still in the process of being launched, and we have
not yet established efficient synchronization across the different
structures.

Agree with Robin:  This is an important issue (technical backlog), and it
is A Good Thing(TM)  it was brought up through a clear message to the
community in a timely manner.

Further, having the benefit of "more-in-depth-information" shared by Digia
at Developer Days, IMHO this is merely a "process issue" (albeit a "real
one").  Digia did important work with these changes that benefit the
*whole* community, and the goal is to share them with the *whole*
community.  We (the "whole community") merely need a process that permits
this to happen as efficiently as possible, and IMHO everybody is already
"on-board" with a positive "work-together" Goal-And-Attitude to ensure we
all vector in the same direction.

In short, my opinion is simply:  This is merely a (short-term) result from
the fact that multiple processes-and-structures currently exist.  We can
improve this.  I see only positive intent-and-actions among all the
players, so this clearly seems resolvable.


> In my opinion, there's two issues that need addressing here.
>
> The first (already brought up) is gerrit. Gitorious' merge requests
> are painful for everyone involved, so they're just going to slow you
> down. Once things get into Gerrit, assuming they work in a similar
> fashion to Qt 5, I think you'll find that changes can get pushed
> forward a fair bit easier (especially assuming you know the right
> people to poke for reviews, which I expect you do for the most part).
>
> The second is that these changes have been going to Qt 4.8. Some
> people seem to have assumed this was an issue, but I'm not entirely
> sure this was correct, as I seem to recall that Ossi had a magical
> script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that
> is the case, there really isn't much further problem I think. If this
> script doesn't do what I'm hoping, then we're going to have to figure
> out how to get this work into Qt 5 with the minimum of pain (meaning
> as soon as possible), before merging becomes impossible or at least
> impractical.
>

Very good points.


> So anyway, the summary of my thoughts on solving this would be:
> - get 4.x into Gitorious ASAP
>

+1


> - get the changes into 4.x (can probably be ongoing while the above
> isn't finished, but will be helped)
>

+1


> - cherry-pick them into Qt 5 (in any way possible) to make sure work
> isn't lost or duplicated, since I assume that your customers will be
> asking about Qt 5 sooner rather than later :)
>

+1

We are a commercial customer, and yes, we want Qt5 "sooner".  ;-))


> ...and we're back to working as one big, happy family in Gerrit :)
>
> [1]:
> http://lists.qt-project.org/pipermail/development/2011-November/000483.html
> - though this repo has apparently been merged into qtrepotools.
>

Really good points and suggestions by Robin, +1.

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

Re: [Development] QRegularExpression -- first round of API review

[Giuseppe D'Angelo]

On 15 December 2011 19:45, Oswald Buddenhagen
 wrote:
> On Thu, Dec 15, 2011 at 04:43:49PM +, ext Giuseppe D'Angelo wrote:
>>    pos, matchedLength, endPos
>>
> inconsistent naming

Well, pos and matchedLength come straight from QRegExp and I kept
them. But please, any suggestion is welcome! (I'm not even a native
English speaker). (In case it isn't clear: endPos() == pos() +
matchedLength() - 1)

>>     void setPatternOptions(PatternOptions options, bool on = true);
>>
> i don't like that too much, because *un*setting options en masse sucks -
> you need to make a "block" of options to set, and a "block" of options
> to delete.
I copied the setXXX(flags, bool on = true) from
QPainter::setRenderHints, I was quite sure it's also used somewhere
else. So are you suggesting a simple setPatternOptions(options) that
simply sets (as in *assigns*) the argument as the current option set?

> that's half as bad if all options are off by default, but
> then one has to wonder whether a way to unset them actually makes sense
> in the first place.

Yes, all options are off by default. I don't see any particular
problem with turning an option on and then off again. What do you
think about this?

> fwiw, the usual elegant solution is having a value and a mask parameter.
> the mask could have two magic values meaning "un-/set all asserted in
> vlaue" to mean effectively what your bool means. the default argument
> would be the magic value for setting, so the standard syntax would set
> all flags named in the first argument.

I'm not sure I understand this point completely -- isn't that what the
method does? I.e.
  rx.setPatternOptions(CaseInsensitiveOption | DotMatchesEverythingOption)
turns on those two options, and leaves the others unchanged.

Thanks for the feedback.

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QRegularExpression -- first round of API review

[Thiago Macieira]

On Thursday, 15 de December de 2011 22.53.19, joao.abeca...@nokia.com wrote:
> Hi Giuseppe,
>
> I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm
> actually referring to the API.

Hi as well Giuseppe

I did read most of your email :-) Thanks for the effort so far.

I'd like to start by saying I agree with Ossi: the test/set way of setting
flags is "un-Qt-ish". I know it exists in a few places, but they are the vast
minority. I'd prefer a regular pair of getter and setter on the QFlags type.

> I started looking at it and it seems too cluttered. Specially this early in
> the process. It's hard to review something that is trying to be everything
> or maybe it's just exposing too many things.

João is also right: it seems you're trying to provide all the power of PCRE to
the user in the first go. It's  good that you're exploring everything, so we
know which way we may go in the future, but I think we can trim down on the
features at the first iteration of the API.

The next thing that I find weird is the set of match functions. My first
reaction was to ask you to call them "indexIn", but since they don't return an
index but a match object, the name is fine. But still, do we need a match,
partialMatch and exactMatch? Also note that the boolean in partialMatch is
also "un-Qt-ish", so you'll need to replace it with an enum as well. If you
do, you may as well merge all three functions.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze date?

[lars.knoll]

On 12/15/11 7:25 PM, "ext Peter Hartmann"  wrote:

>On 12/14/2011 06:42 PM, ext Thiago Macieira wrote:
>> On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote:
>>> Ok, well let's start the list:
>>>
>>> https://wiki.qt-project.org/5.0_Feature_Requirements
>
>my addition for network (feel free to point out more):
>
>
>== Network ==
>
>* SSL errors (+ OCSP etc.): make it possible to display SSL errors
>without stalling QNetworkAccessManager
>(http://bugreports.qt.nokia.com/browse/QTBUG-19032)
>
>* Authentication: make it possible to display authentication dialog
>without stalling QNetworkAccessManager
>(https://bugreports.qt.nokia.com/browse/QTBUG-16251); this is obviously
>closely tied to above task
>
>* remove QHttp (https://bugreports.qt.nokia.com/browse/QTBUG-22750)

* Make QFtp private

Cheers,
Lars

>
>* rewrite cookie jar (https://bugreports.qt.nokia.com/browse/QTBUG-23145)
>
>
>Peter
>
>
>>>
>>> One thing we could do is:
>>>
>>> 1. Let people populate the list
>>> 2. Review the list for plausibility in a reasonable timeframe
>>> and personal availability.
>>> 3. Estimate the time for the responsible people to get the work done.
>>> 4. Schedule feature freeze based on that.
>>> 5. Features that unfortunately don't get finished by then don't make
>>> it into 5.0, and possibly .x.
>>>
>>> That's just an idea of how to make progress though. Making a scheduling
>>> decision without any idea of what needs to be done in that timeframe
>>>doesn't
>>> really make sense.
>>
>> That's why I started the thread. We need to know what we need to do so
>>we can
>> make a scheduling decision. Or, alternatively, we need to decide what
>>we can
>> do given the schedule.
>>
>> I also oppose to your item #5 above. I don't want to see anything on a
>>page
>> called "5.0 requirements" that can be postponed. I want *only* the
>>stuff that
>> *must* go into 5.0, i.e., what cannot go into 5.1 or a later release
>>until
>> 6.0.
>>
>> If we reach the feature freeze date and a requirement isn't complete
>>yet,
>> we'll need to make a call whether to delay the freeze or not. This is
>> something we'll do only for 5.0, as for any future releases, anything
>>can be
>> postponed.  That also means we don't have "feature requirements", but
>>only a
>> wish-list. [That's between us developers; in public communication we
>>may call
>> them differently]
>>
>> For those things that can be postponed, we should have a separate
>>roadmap
>> page. We can also start collecting ideas for future releases.
>>
> Backward incompatible change freeze?
> (Yes)

 See above on both SIC and BIC changes.
>>>
>>> Right. This would be soft-frozen probably at RC or beta time.
>>
>> Depending on whether you referred to source or binary incompatible
>>changes;
>> and for the source ones, it's understood it applies to new features
>>only.
>>
 Of the "I can't judge" QtWidgets features above, considering that
module
 is
 in Done state and we have a source-compatible requirement for 5.0 for
 existing features, I would wager that they are not Qt 5.0
requirements.
>>>
>>> Yes, but there are also lessons which we need to ensure are not
>>>forgotten so
>>> that we have useful API for QML. An example is the QCompletion stuff.
>>>Doing
>>> that 'properly' and in a future-proof, QML compatible way probably
>>>actually
>>> depends on itemmodels getting new features, such as a virtual search()
>>> method to supercede the match() method. That's just an example. There
>>>may
>>> be others.
>>
>> I agree. However, we'll never finish finding new requirements or need
>>to improve
>> the API, so we need to make a cut somewhere based on our best
>>understanding. I
>> might be an optimist here, but I'd have expected all these studies
>>where we
>> need new API to have completed by now. We're 5 months into the 5.0
>>cycle, 1
>> year into the QtDeclarative API, 61Ž2 years since ItemViews and the rest
>>of the
>> Qt 4 API.
>>
>>
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Playground - 3D Audio module

[michael.goddard]

Hello,

On 14/12/11 8:53 AM, "ext Laszlo Papp"  wrote:

>I would like to work on a 3D Audio module in Qt Playground [1] that might
>be
>beneficial later for projects, like Qt3D, game engines, development
>platforms,
>or games without a platform underneath. Surprisingly enough, certain media
>players also prefer using 3D audio and OpenAL in general for their goals.

Sounds good ("Approved" :).  We're also interested in making use of OpenAL
in QtMultimedia* so it sounds like a good way to start.

>The module name would be either QtOpenAL or 3D Audio. Either one works
>for me.

I'd prefer QtOpenAL because there are other 3D audio systems (if less
popular), but there may be a trademark issue.  I've asked Cristy about
this and I'll send another email.  It is probably necessary to delay the
playground initiation until after that.

>The short description would be something like: "This module offers
>classes that
>make it easy to use OpenAL in Qt applications". It currently also deals
>with
>convenient and more common tasks, like decoding from various compressed
>formats
>into raw PCM data. There are no license problems about using openal-soft
>[2],

This part is also something we've been looking at doing in QtMultimedia
(e.g. QMediaPlayer -> raw PCM, or via other classes).  Currently we use
whatever platform media framework we have to decode audio which might
result in differences between platforms though.  It would be nice to share
some of that code someway or another.

Cheers,
MichaelG

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

Re: [Development] Feature freeze date?

[jason.mcdonald]

Having been release manager for several past Qt feature releases (4.5 to 4.7), 
I'm wary of setting a single feature freeze date and having a big rush to cram 
all the new features into the master branch in the last couple of days before 
the deadline.  Instead, I would like to see a staggered delivery of features, 
where each large change is tested, merged and tested some more before the gate 
is opened for the next big change.

For the Qt 4.5.0 and 4.6.0 releases, we did the former, and in both cases the 
last minute rush to push in all the new features caused substantial breakage 
and significantly delayed the alpha and beta releases.  For Qt 4.6, it took two 
weeks after the feature freeze date to get the branch compiling again on all 
the Tier 1 platforms (that was the criteria for an alpha release) and several 
months to satisfy the (fairly lax) quality criteria for a beta release.

For the Qt 4.7.0 release, we staggered the merging of new features over several 
weeks and had a much better result, with alpha release packages building 
successfully on the day after the feature freeze.

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

Re: [Development] QRegularExpression -- first round of API review

[Giuseppe D'Angelo]

On 15 December 2011 22:53,   wrote:
> Hi Giuseppe,

Hi João,
thanks for the comments.

> I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm 
> actually referring to the API.
>
> I started looking at it and it seems too cluttered. Specially this early in 
> the process. It's hard to review something that is trying to be everything or 
> maybe it's just exposing too many things.
>
> I would like to challenge you to do the opposite: give us the minimum API 
> that can offer the most important features. To get there start from short 
> self-contained code examples showing the features in use (I'm interested in 
> seeing those) -- API design is about how it gets used, not so much about the 
> number of features.

Then we should discuss what those "important features" are. In my mail
I pointed out how the API is supposed to fix the T1-T7 issues, but I
can understand not all of them have the same priority.

(Other sub-objectives are 1) keeping the QRegExp "feature set" 2) keep
existing stuff working; but I guess that if QRegExp gets moved in a
stand-alone module, we simply can make other modules in Qt depend on
that one until we have a replacement, and thus not breaking anything.)

I'd like to collect feedbacks about these priorities, especially from
the intended users of the API! If you have the chance, please tell
developers to give their opinions.

Continuing: you're totally right about the missing examples. I'll
write some down and then post them.

> For instance, in Perl, regular expressions are essentially a string, a couple 
> of operators and some magic variables for the captures (and lots of magic 
> everywhere...). (Now, I'm not saying we should do regular expressions in Qt 
> as they are done in Perl)

That's basically the same here, but there are also options to control
the optimization level (you may not want to lose time optimizizing,
esp. for quick, one-shot matches; or prefer to optimize in case you
have to filter a model of 100k+ strings) and the match behaviour (some
options are actually implemented in Perl -- see what I wrote about the
/g algorithm -- but they are not avaiable to the user).

At high level:
- QRegularExpression is the pattern+options, as in Perl's "/pattern/options".
- QRegularExpressionMatch is the rough equivalent of Perl's capturing variables:
  - $& -> cap(0)
  - $1...$n -> cap(n)
  - $+[n] -> pos(n)
  - $-[n] -> endPos(n)
  - $+{str} -> capturedText(str)
  - $-{str} -> capturedTextsForName(str)
 etc.

Plus, the match object is used to implement /g, that is, to repeatedly
match on a string (as convenience API).

> The API, as it stands seems too hard-wired to the implementation or feature 
> set of the engine giving it little opportunity for evolving.

Where do you feel I could improve this? F.i. removing some enum is
easy, but I guess the problem isn't there.

> Another issue is that it is hard for me to see if (or where) the API itself 
> is imposing performance penalties on the implementation.

The biggest hit as of now is obviously the conversions all around the
place from/to UTF-8, which have a memory and time impact. This will
eventually be solved when PCRE ships with native UTF-16 support (see
Stephen Kelly's mail about this). Apart from that the implementation
is almost straightforward -- just call the method in PCRE that does
the work and grab the result.

The other hit I talked about is inside the implementation of iterating
backwards (and lastMatch). I cannot see any good general way to
implement it, apart from iterating forward from the beginning (and
eventually caching such results. A match result in terms of captured
strings is quite small -- we just keep the offsets inside the
subject). The fact is that matching backwards is simply something a
bit outside the regexp world.

Cheers,
--
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QRegularExpression -- first round of API review

[Giuseppe D'Angelo]

2011/12/16 Thiago Macieira :
> I did read most of your email :-) Thanks for the effort so far.

Hero :-) Thank you for reading!

> I'd like to start by saying I agree with Ossi: the test/set way of setting
> flags is "un-Qt-ish". I know it exists in a few places, but they are the vast
> minority. I'd prefer a regular pair of getter and setter on the QFlags type.

No problem. Will do.

>> I started looking at it and it seems too cluttered. Specially this early in
>> the process. It's hard to review something that is trying to be everything
>> or maybe it's just exposing too many things.
>
> João is also right: it seems you're trying to provide all the power of PCRE to
> the user in the first go. It's  good that you're exploring everything, so we
> know which way we may go in the future, but I think we can trim down on the
> features at the first iteration of the API.

Ok, see the other message about this.

> The next thing that I find weird is the set of match functions. My first
> reaction was to ask you to call them "indexIn", but since they don't return an
> index but a match object, the name is fine. But still, do we need a match,
> partialMatch and exactMatch?

* match: I think it should stay :-)

* exactMatch: it's convenience, and it's there... because QRegExp
offered it (although there it was handy to perform partial matching).
As I wrote, an user can get the very same result by wrapping a pattern
between \A and \z (and that's more or less how it would be
implemented). It's just a matter of deciding if we want it or not. Up
to the consensus.

* lastMatch (again, being there because QRegExp offered it) this is
tricky to implement correctly and efficiently, and needs the same
discussion about iterating backwards.

* partialMatch: the "hard" version may be removed, for now, in favour
of adding, later, a more general way to perform incremental matching
over non contiguous chunks of data (and iterating, as in /g, over such
matches). The "soft" version might stay there for validators, if you
feel that its behaviour is the right one.

> Also note that the boolean in partialMatch is
> also "un-Qt-ish", so you'll need to replace it with an enum as well. If you
> do, you may as well merge all three functions.

Surely I can merge match, exactMatch and partialMatch in only one
method, with an enum to control the behaviour.
OTOH lastMatch may require a different offset (from the *end* of the
string), so I'm not sure if merging it as well.

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QRegularExpression -- first round of API review

[Andre Somers]

Op 16-12-2011 1:07, Giuseppe D'Angelo schreef:
>
>> fwiw, the usual elegant solution is having a value and a mask parameter.
>> the mask could have two magic values meaning "un-/set all asserted in
>> vlaue" to mean effectively what your bool means. the default argument
>> would be the magic value for setting, so the standard syntax would set
>> all flags named in the first argument.
> I'm not sure I understand this point completely -- isn't that what the
> method does? I.e.
>rx.setPatternOptions(CaseInsensitiveOption | DotMatchesEverythingOption)
> turns on those two options, and leaves the others unchanged.
>
Really? Now to me _that_ is unexpected behaviour. I would have expected 
that this method call would set the options to exactly 
(CaseInsensitiveOption | DotMatchesEverythingOption), no matter what the 
previous value of the matchingOptions value was.

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