date:20160813

Re: [Development] Which changes are suitable for 5.6?

2016-08-13 Thread Thiago Macieira

On sábado, 13 de agosto de 2016 20:30:39 PDT Gunnar Roth wrote:
> >> b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk.
> > 
> > Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x
> > must run just fine with Qt 5.6.y even if y < x.
> 
> Well thats something I honestly di not know before. So that means something
> compiled with qt 5.6.2 is able to run with 5.6.0?

Yes.

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

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

Re: [Development] Which changes are suitable for 5.6?

2016-08-13 Thread Gunnar Roth

Hi Thiago,
thanks for you answers.

> Am 13.08.2016 um 20:05 schrieb Thiago Macieira :
> 
> On sábado, 13 de agosto de 2016 18:08:16 PDT Gunnar Roth wrote:
>> 1. category is just adding code, which does not influence current
>> code. 
>> a. adding qAsConst in qgolbal.h. That is actually something i really
>> like to have in qt 5.6, because it is very useful and has no risk. 
> 
> Except that it's impossible. For the feature to work, we need rvalue 
> references to prevent wrong use. We can't do that in 5.6 because it doesn't 
> require C++11.
Hmm ok, as that works with vs 2012 ( and wec2013) I didn’t think about that. 
But even vs2010 has this.
But ok there may be other compilers , which I don’t have knowledge about then.
> 
>> b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk. 
> 
> Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x 
> must 
> run just fine with Qt 5.6.y even if y < x.
Well thats something I honestly di not know before. So that means something 
compiled 
with qt 5.6.2 is able to run with 5.6.0? 

> 
>> c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in
>> destructor, because quickcontrols2 instantiates it in  a way that it is not
>> registered, but on cleanup crashes when removing as there is no check if it
>> was added at all. I consider that a bug in Qt 5.6.1
> 
> I have no idea about this one.
> 
>>  d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no
>> risk. 
> 
> But violates Qt API policy even worse than adding an enum because it would 
> cause dynamic linker errors.

As I thought API compatibility were like between 5.6 and 5.7 , I didn’t see the 
problem.

>> e. adding Q_QUICK_PRIVATE_EXPORT to  QQuickStateAction  class in
>> qquickstate_p.h
> 
> That's ok.
> 
>> 2. category is enhancing code but also modifies existing code.
>> 
>>  a.  enhance qml module lookup behavior in a way making things a lot
>> easier.
>> 
>>   qqmlimport.* is changed ( by merging simply the code from 5.7 to do a
>> lookup like this: For example, QtQml.Models 2.0:
>>   - base/QtQml/Models.2.0/qmldir
>>   - base/QtQml.2.0/Models/qmldir
>>   - base/QtQml/Models.2/qmldir
>>   - base/QtQml.2/Models/qmldir
>>   - base/QtQml/Models/qmldir
>>  This is very convenient. quickcontrols2 works without that but only
>> with the default style. quickcontrols1 is jumping through hoops to achieve
>> similar without change qtdeclarative.
> 
> No idea about this.
> 
>>  b. adding MovementDirection property  to QQuickPathView, i just copied
>> qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same
>> risk then.
> 
> API policy violation.


Sure now i know. 
Well ok then I will just maintain my patches privately.

Regards,
Gunnar Roth


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

Re: [Development] Which changes are suitable for 5.6?

2016-08-13 Thread Thiago Macieira

On sábado, 13 de agosto de 2016 18:08:16 PDT Gunnar Roth wrote:
> 1. category is just adding code, which does not influence current
> code. 
> a. adding qAsConst in qgolbal.h. That is actually something i really
> like to have in qt 5.6, because it is very useful and has no risk. 

Except that it's impossible. For the feature to work, we need rvalue 
references to prevent wrong use. We can't do that in 5.6 because it doesn't 
require C++11.

> b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk. 

Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x must 
run just fine with Qt 5.6.y even if y < x.

> c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in
> destructor, because quickcontrols2 instantiates it in  a way that it is not
> registered, but on cleanup crashes when removing as there is no check if it
> was added at all. I consider that a bug in Qt 5.6.1

I have no idea about this one.

>   d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no
> risk. 

But violates Qt API policy even worse than adding an enum because it would 
cause dynamic linker errors.

> e. adding Q_QUICK_PRIVATE_EXPORT to  QQuickStateAction  class in
> qquickstate_p.h

That's ok.

> 2. category is enhancing code but also modifies existing code.
> 
>   a.  enhance qml module lookup behavior in a way making things a lot
> easier.
> 
>qqmlimport.* is changed ( by merging simply the code from 5.7 to do a
> lookup like this: For example, QtQml.Models 2.0:
>- base/QtQml/Models.2.0/qmldir
>- base/QtQml.2.0/Models/qmldir
>- base/QtQml/Models.2/qmldir
>- base/QtQml.2/Models/qmldir
>- base/QtQml/Models/qmldir
>   This is very convenient. quickcontrols2 works without that but only
> with the default style. quickcontrols1 is jumping through hoops to achieve
> similar without change qtdeclarative.

No idea about this.

>   b. adding MovementDirection property  to QQuickPathView, i just copied
> qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same
> risk then.

API policy violation.

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

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

Re: [Development] Which changes are suitable for 5.6?

2016-08-13 Thread Gunnar Roth

Hi Thiago,

to make qt 5.6.x support the quick controls2 there are only a few changes 
needed.
1. category is just adding code, which does not influence current code.
a. adding qAsConst in qgolbal.h. That is actually something i really like 
to have in qt 5.6, because it is very useful and has no risk. 
b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk.
c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in 
destructor, because quickcontrols2 instantiates 
it in  a way that it is not registered, but on cleanup crashes when 
removing as there is no check if it was added at all. I consider
that a bug in Qt 5.6.1

  d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no risk.
  e. adding Q_QUICK_PRIVATE_EXPORT to  QQuickStateAction  class in 
qquickstate_p.h

2. category is enhancing code but also modifies existing code.

  a.  enhance qml module lookup behavior in a way making things a lot easier.

   qqmlimport.* is changed ( by merging simply the code from 5.7 to do a 
lookup like this:
   For example, QtQml.Models 2.0:
   - base/QtQml/Models.2.0/qmldir
   - base/QtQml.2.0/Models/qmldir
   - base/QtQml/Models.2/qmldir
   - base/QtQml.2/Models/qmldir
   - base/QtQml/Models/qmldir
  This is very convenient. quickcontrols2 works without that but only with 
the default style. quickcontrols1 is jumping 
  through hoops to achieve similar without change qtdeclarative.

  b. adding MovementDirection property  to QQuickPathView, i just copied 
qquickpathview.* from qt 5.7. I assume a low risk, 
  but qt 5.7 has the same risk then.

The changes in the quick controls itself are just a matter of changing some 7 
to a 6, 5.7.0 to 5.6.1 and 2.7 to 2.6

So actually I don’t see a dragon but maybe a dwarf lizard there ;-)

I can send the actual patches on request, they do not contain any code I wrote 
myself ( other than changing numbers)

Regards,
Gunnar Roth

> Am 12.08.2016 um 18:26 schrieb Thiago Macieira :
> 
> On sexta-feira, 12 de agosto de 2016 14:03:24 PDT Gunnar Roth wrote:
>> Does a request of  having qtquickcontrols2 and qtvirtualkeyboard 2.1
>> backported to 5.6. x have chance? Actually I managed to do this myself, but
>> an upstream solutuion is preferrable. The problem is that some important OS
>> is no longer supported in 5.7. 
> 
> Quite impossible. Those are defintely new features.
> 
> However, there's a compromise: we can have a branch for the unofficial 
> support. 
> Anyone using that will know "there be dragons"
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] New repository for QtOAuth

2016-08-13 Thread Konstantin Ritt

I don't see any need in distinguishing different OAuth implementations for
Qt -- once we have an "officially supported" Qt module, it'll be a default
opt-in for the user's code.

+1 for QtOAuth as a separate module

Regards,
Konstantin

2016-08-13 11:28 GMT+04:00 Sune Vuorela :

> On 2016-08-12, Fredrik de Vibe  wrote:
> > We have recently been working on an implementation of OAuth (1+2), and
> > this is now approaching a state in which it can be distributed as a tech
> > preview. For this we'll need a new public repository.
>
> there is a handful of external projects doing oauth with qt. Have
> anything been done to ensure applications don't blow up if several
> libraries gets loaded into the same process?
>
> The ones I've found seems to have some of the following distinguishing
> marks
>
> One puts everything in namespace QOAuth and has a QtOAuth header
>
> One seems to put everything with O0foo O1foo and O2foo
>
> another one seems to name everything like KQOAuthfoo (and despite the
> name, I don't think it has any ties to the KDE project)
>
> and one just with a class OAuth2, and this one looks a bit like example
> code.
>
>
> So, depending on how the qt project qtoauth is done, it might conflict
> to some degree with the first of them.  The first of them is also
> available in Debian and other linux distributions as qoauth (libqoauth1
> and libqoauth-dev)
>
> > The main reason for OAuth to reside in its own module (and not as a part
> > of qtnetwork) is that it is specialized, and most qtnetwork users won't
> > need it. This avoids increasing the footprint of, and unnecessary
> > complexity in, qtnetwork. Another reason is that OAuth, while depending
> > on and using networking mechanisms, isn't in itself really a networking
> > mechanism.
>
> Agreed.
>
> /Sune
>
> ___
> 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] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming...

2016-08-13 Thread Lars Knoll

Sounds good to me.

We'll also need some days past the feature free to get the remaining changes to 
the configuration system merged.

Cheers,
Lars

On 12 Aug 2016, at 21:31, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:

Hi,

I totally support Kai's request.

On the upside: The qtlocation build is fixed :)


Simon

From: Development 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Kai Koehne mailto:kai.koe...@qt.io>>
Sent: Friday, August 12, 2016 3:03:18 PM
To: Jani Heikkinen; 
development@qt-project.org
Cc: releas...@qt-project.org
Subject: Re: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' 
ongoing, Qt 5.8 Feature Freeze coming...

Hi,

Unfortunately, we're having great difficulties to get patches integrated into 
Qt WebEngine in the last days, right now due to qtlocation not compiling 
(QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like 
to ask for an exception for getting features into 5.8 for Qt WebEngine even 
after Monday morning.

The features still waiting to get merged are
Printing: https://codereview.qt-project.org/#/c/162928/ and following
Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/
Support for certificate transparency: 
https://codereview.qt-project.org/#/c/167275/
Support for custom QML context menu/ dialogs: 
https://codereview.qt-project.org/#/c/162263/, 
https://codereview.qt-project.org/#/c/165731/
Support for Qt Quick 2 Controls dialogs: 
https://codereview.qt-project.org/#/c/162262/

Regards

Kai


> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Jani Heikkinen
> Sent: Monday, August 08, 2016 12:58 PM
> To: development@qt-project.org
> Cc: releas...@qt-project.org
> Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8
> Feature Freeze coming...
>
> Hi all,
>
>
>
>
> Qt5.git integration in 'dev' succeed during the weekend and we have soft
> branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th
> August 2016 as well as final branching from 'dev' to '5.8'
>
>
>
>
>
> So please start using '5.8' for changes targeted to Qt 5.8 release and 
> finalize
> ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen
> Monday 15th Aug (morning).
>
>
>
>
> Please make sure
>
>
> - All new modules for Qt 5.8 are in 'dev' & part of qt5.git
>
>
> - All mandatory new features are in 'dev' now or coming in within a week?
>
>
> - New feature page contains all new features etc:
> https://wiki.qt.io/New_Features_in_Qt_5.8
>
>
>
>
> We will create first src packages from latest qt5.git integration as soon as
> possible. Please check the packages immediately when available to see if
> something important is missing. Those packages should be quite close to Qt
> 5.8 alpha packages so it will be really important to check the packages now.
>
>
>
>
> br,
>
> Jani
>
>
>
>
>
> Jani Heikkinen
> Release Manager
>
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikki...@qt.io
> +358 50 4873735
> http://qt.io 
>
>
>  
>  
> 
> 
> 
> 
>

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

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

Re: [Development] New repository for QtOAuth

2016-08-13 Thread Sune Vuorela

On 2016-08-12, Fredrik de Vibe  wrote:
> We have recently been working on an implementation of OAuth (1+2), and 
> this is now approaching a state in which it can be distributed as a tech 
> preview. For this we'll need a new public repository.

there is a handful of external projects doing oauth with qt. Have
anything been done to ensure applications don't blow up if several
libraries gets loaded into the same process?

The ones I've found seems to have some of the following distinguishing
marks

One puts everything in namespace QOAuth and has a QtOAuth header

One seems to put everything with O0foo O1foo and O2foo

another one seems to name everything like KQOAuthfoo (and despite the
name, I don't think it has any ties to the KDE project)

and one just with a class OAuth2, and this one looks a bit like example
code.

So, depending on how the qt project qtoauth is done, it might conflict
to some degree with the first of them.  The first of them is also
available in Debian and other linux distributions as qoauth (libqoauth1
and libqoauth-dev)

> The main reason for OAuth to reside in its own module (and not as a part 
> of qtnetwork) is that it is specialized, and most qtnetwork users won't 
> need it. This avoids increasing the footprint of, and unnecessary 
> complexity in, qtnetwork. Another reason is that OAuth, while depending 
> on and using networking mechanisms, isn't in itself really a networking 
> mechanism.

Agreed.

/Sune

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

Re: [Development] Which changes are suitable for 5.6?

Re: [Development] Which changes are suitable for 5.6?

Re: [Development] Which changes are suitable for 5.6?

Re: [Development] Which changes are suitable for 5.6?

Re: [Development] New repository for QtOAuth

Re: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming...

Re: [Development] New repository for QtOAuth

7 matches

Site Navigation

Mail list logo

Footer information