Re: [Development] RFC: more liberal 'auto' rules?

[Smith Martin]

+1

martin


From: Development  on behalf of Randall 
O'Reilly 
Sent: Friday, December 04, 2015 8:35 AM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

This debate between the std:: lib and wider C++ community vs. the Qt traditions 
seems never-ending :)  At the risk of perpetuating the inevitable flame war, my 
perspective is well captured in this article:  
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++ is WAY too complex of a language, and other alternatives are rapidly 
gaining users (particularly Python in the domain of scientific computing).  The 
STL and its sea of recursive templates has in particular been incredibly 
daunting.  C++11 helps, but the complexity remains..

Of course, there is no “right” answer in any of these language debates: only 
different people optimizing different ends of many different fundamental 
tradeoffs.

C and C++ in general tend to attract people who favor optimization over 
simplicity / usability of the language.  Marc is clearly in that camp, 
advocating many ways of optimizing performance..  With all the new language 
options, presumably those that stick with C++ are even more apt to be obsessed 
with performance..

But Qt is beloved by many (myself included) because it provides a *simple*, 
elegant, well-designed, well-named API, that does a lot of stuff..  Not because 
of its optimal performance or cutting-edge language features and adherence to 
the C++ standard..

I got “stuck” in C++ for historical reasons: it was the only viable option for 
object-oriented programming in the 1990’s.  Sure, I care about optimization for 
my critical inner loops.  But for everything else, I really wish it was a lot 
simpler.  And again, I value Qt for making it so in the GUI, which consumes a 
huge amount of my code, and has minimal performance demands, because it is a 
GUI and the human in the loop is almost always the rate limiting factor.  Of 
course we don’t want exponential slowdowns with large numbers of Widgets etc, 
but I’ve never found that to be a problem in Qt.

So anyway, this is just a vote to keep with the solid tradition of favoring 
simplicity, clarity, usability, readability, etc, instead of just following the 
std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite everything 
in Go or Python or something.. :)

- Randy

> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
>
> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>> That depends on how big the remainder is. I argue that we're relevant
>>> enough  that our own direction is big enough to be of relevance.
>>
>> That didn't come out right. Rephrasing:
>>
>> Qt has enough market share by itself that we can choose our own direction
>> and still be relevant. We are allowed to disagree with what others do.
>
> Yes, but only if we know *better*.
>
> I very much doubt that more than very few people in Qt development have the
> knowledge to objectively overrule the accepted C++ authorities. I myself have
> seen over and over again that how I thought a feature should be used was blown
> to smithereens by members of the committee, usually rightfully so.
>
> So the default should be to follow what the greater C++ community is doing,
> while *divergence* from that needs to be argued for.
>
> Everything else is approaching hubris, imo.
>
>> we don't use exceptions
>
> ...and look at the sorry state of error handling in Qt - every class does it
> differently... It's ok not to use exceptions, but not having a consistent 
> error
> handling strategy doesn't put us into a position to throw that stone.
>
>> we don't use underscores
>
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] Proposal to change connectSlotsByName behavior

[Ziller Eike]

> On Dec 4, 2015, at 00:05, Benjamin TERRIER  wrote:
> 
> Hi everyone,
> 
> This message follows an exchange I've had with Thiago on a bug report:
>https://bugreports.qt.io/browse/QTBUG-49749
> 
> 
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot named "on__" in a given
> object,
> a child object named " and connect the signal to the
> slot. Moreover the documentation says that the search is recursive so
> any
> descendant QObject is looked up (not only direct children).
> 
> My issue here is that the search is done by instantiation order
> (depth-first search) which means that if 2 (or more) children have the
> same name one has
> to know which one is instantiated first to know which one will be
> connected. And of course imposing on the developer to use unique names
> throughout
> a QObject hierarchy is not feasible in particular if he/she is using a
> third-party library and might not know the object names used
> internally.
> 
> This can lead to various hazardous situation, for instance, in a
> perfectly working software, one can break the behavior of the main
> window by simply adding
> a widget in a grand-grand-child widget.
> Or worse if the UI is made using Qt Designer, the behavior of the
> application can be changed by simply reordering the widgets in the
> layout as it will also
> change their creation order.
> An application could even break at runtime if a user enables a plugin
> or set an HMI element visible.
> 
> In my opinion it also breaks encapsulation as the naming in a widget
> can alter the signal/slot connections in another widget.

That is inherent to the “feature”, independent of how the search order is.

> My proposal is to change the behavior of connectSlotsByName to do a
> breadth-first search. In this case, if a direct child is a match it
> will be used
> for the connection regardless of possible matches deeper in the
> hierarchy. Doing so would solve the situations stated above and
> restore encapsulation.

Even though your suggestion would make the issue less prominent, it would not 
actually solve it.
It still highly depends on how the different UI parts are combined. UI from 
e.g. a plugin does not necessarily end up further down in the hierarchy than 
the widget that you wanted to connect to originally.

main
- group box
- - some other widget that is used for grouping
- - - some button (a) that you want to connect to
- plugin specific widget
- - some button with same object name as (a)

Aside from not being able to guard against things like 
myWidget->setParent(window()) anyhow.

IMO:
1. connectSlotsByName is a misfeature. Try not to use it at all.
2. If you really must use it (for what?), use _unique_ object names. E.g. by 
pre- or appending a random sequence of characters, or by using long object 
names that describe where they are used 
(choosePathForSpecificSettingInMainApplicationButton).
3. I don’t see why the risk of breaking existing applications would be worth it 
for a behavior change that does not really fix the issue. Even with your 
proposed change you must do (1) or (2), but then you don’t need the proposed 
change.

Br, Eike

> It seems that Thiago's opinion is that it can not be changed as this
> behavior has been here since Qt 4 and it might break existing
> applications.
> 
> On my side I think it's at least a buggy and error prone behavior or
> even a flawed design and that it must be changed as soon as possible.
> About the risk of breaking existing applications,
> I think making the change is less risky for Qt users as in the current
> state every Qt software can break with any change to an object name or
> instantiation order.
> Also as Qt Designer does push the users to use the connectSlotsByName
> mechanism, it is even possible to generate an example of this
> "unwanted" behavior
> without writing a single line of code (see attached zip in the bug report).
> 
> 
> Regards,
> 
> Benjamin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Proposal to change connectSlotsByName behavior

[Olivier Goffart]

On Thursday 3. December 2015 18:00:15 Thiago Macieira wrote:
> On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
> > I don't think it will break too many applications because anyone who was
> > relying on the order of instentiation for that has just its application
> > working out of pure luck. (And i'm pretty sure that your proposal is
> > always
> > the intended behaviour)
> 
> Note that for widgets, the order is not pure luck. The order of children of
> a QWidget implies the tabbing order. Therefore, it is usually well-defined.

The tab order is set with QWidget::setTabOrder and does not depends on the 
order of the children.

> I don't mind changing the order, as long as there's a consensus in the
> mailing list.
> 
> If we do decide to change the order, I have a follow-up question:
>  do we change it only in connectSlotsByName, or do we change
>  QObject::findChildren to reflect the new order?
> 
> Right now, connectSlotsByName simply uses findChildren's order. If we decide
> to change the order in one but not the order, I'd like to hear a compelling
> reason why it's ok for them be different.


The documentation of findChild says:

If there is more than one child matching the search, the most
direct ancestor is returned. If there are several direct
ancestors, it is undefined which one will be returned. In that
case, findChildren() should be used.

This would be the expected behaviour, unfortunately, the implementation does 
not follow that.

FindChildren does not document the order.
So the order is then unspecified.  

Changing the order of findChildren would make the function slower.
Changing the order in connectSlotsByName would only make that function 
slightly slower.

I do not have strog opinion if the two functions must follow the same order.


-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Short downtime on mailing list services

[Järvenpää Petri]

Due to some hardware migration mailing list services will experience a short 
downtime during the weekend.

Apologies for any delays caused in mail delivery.


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

Re: [Development] RFC: more liberal 'auto' rules?

[Randall O'Reilly]

This debate between the std:: lib and wider C++ community vs. the Qt traditions 
seems never-ending :)  At the risk of perpetuating the inevitable flame war, my 
perspective is well captured in this article:  
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++ is WAY too complex of a language, and other alternatives are rapidly 
gaining users (particularly Python in the domain of scientific computing).  The 
STL and its sea of recursive templates has in particular been incredibly 
daunting.  C++11 helps, but the complexity remains..

Of course, there is no “right” answer in any of these language debates: only 
different people optimizing different ends of many different fundamental 
tradeoffs.

C and C++ in general tend to attract people who favor optimization over 
simplicity / usability of the language.  Marc is clearly in that camp, 
advocating many ways of optimizing performance..  With all the new language 
options, presumably those that stick with C++ are even more apt to be obsessed 
with performance..

But Qt is beloved by many (myself included) because it provides a *simple*, 
elegant, well-designed, well-named API, that does a lot of stuff..  Not because 
of its optimal performance or cutting-edge language features and adherence to 
the C++ standard..

I got “stuck” in C++ for historical reasons: it was the only viable option for 
object-oriented programming in the 1990’s.  Sure, I care about optimization for 
my critical inner loops.  But for everything else, I really wish it was a lot 
simpler.  And again, I value Qt for making it so in the GUI, which consumes a 
huge amount of my code, and has minimal performance demands, because it is a 
GUI and the human in the loop is almost always the rate limiting factor.  Of 
course we don’t want exponential slowdowns with large numbers of Widgets etc, 
but I’ve never found that to be a problem in Qt.

So anyway, this is just a vote to keep with the solid tradition of favoring 
simplicity, clarity, usability, readability, etc, instead of just following the 
std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite everything 
in Go or Python or something.. :)

- Randy

> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
> 
> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>> That depends on how big the remainder is. I argue that we're relevant
>>> enough  that our own direction is big enough to be of relevance.
>> 
>> That didn't come out right. Rephrasing:
>> 
>> Qt has enough market share by itself that we can choose our own direction
>> and still be relevant. We are allowed to disagree with what others do.
> 
> Yes, but only if we know *better*.
> 
> I very much doubt that more than very few people in Qt development have the 
> knowledge to objectively overrule the accepted C++ authorities. I myself have 
> seen over and over again that how I thought a feature should be used was 
> blown 
> to smithereens by members of the committee, usually rightfully so.
> 
> So the default should be to follow what the greater C++ community is doing, 
> while *divergence* from that needs to be argued for.
> 
> Everything else is approaching hubris, imo.
> 
>> we don't use exceptions
> 
> ...and look at the sorry state of error handling in Qt - every class does it 
> differently... It's ok not to use exceptions, but not having a consistent 
> error 
> handling strategy doesn't put us into a position to throw that stone.
> 
>> we don't use underscores
> 
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
> > That depends on how big the remainder is. I argue that we're relevant
> > enough  that our own direction is big enough to be of relevance.
> 
> That didn't come out right. Rephrasing:
> 
> Qt has enough market share by itself that we can choose our own direction
> and still be relevant. We are allowed to disagree with what others do.

Yes, but only if we know *better*.

I very much doubt that more than very few people in Qt development have the 
knowledge to objectively overrule the accepted C++ authorities. I myself have 
seen over and over again that how I thought a feature should be used was blown 
to smithereens by members of the committee, usually rightfully so.

So the default should be to follow what the greater C++ community is doing, 
while *divergence* from that needs to be argued for.

Everything else is approaching hubris, imo.

> we don't use exceptions

...and look at the sorry state of error handling in Qt - every class does it 
differently... It's ok not to use exceptions, but not having a consistent error 
handling strategy doesn't put us into a position to throw that stone.

> we don't use underscores

... except we do (grep "qt_"). And there's *nothing* wrong with that!

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to change connectSlotsByName behavior

[Thiago Macieira]

On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
> I don't think it will break too many applications because anyone who was
> relying on the order of instentiation for that has just its application
> working out of pure luck. (And i'm pretty sure that your proposal is always
> the intended behaviour)

Note that for widgets, the order is not pure luck. The order of children of a 
QWidget implies the tabbing order. Therefore, it is usually well-defined.

I don't mind changing the order, as long as there's a consensus in the mailing 
list.

If we do decide to change the order, I have a follow-up question:
 do we change it only in connectSlotsByName, or do we change 
 QObject::findChildren to reflect the new order?

Right now, connectSlotsByName simply uses findChildren's order. If we decide to 
change the order in one but not the order, I'd like to hear a compelling 
reason why it's ok for them be different.

> Other possibilities may include:
>  - Connect signals of both objects.  (Probably not a good idea since it does
> make it even more confusing)

Agreed that this is not a good idea. Let's discard it.

>  - Throw a warning if there are two objects with the same name.

This is orthogonal.
-- 
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] RFC: more liberal 'auto' rules?

[Thiago Macieira]

On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
> That depends on how big the remainder is. I argue that we're relevant
> enough  that our own direction is big enough to be of relevance.

That didn't come out right. Rephrasing:

Qt has enough market share by itself that we can choose our own direction and 
still be relevant. We are allowed to disagree with what others do.

> For example, we don't use exceptions and underscores.

-- 
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] Proposal to change connectSlotsByName behavior

[Olivier Goffart]

On Friday 4. December 2015 00:05:19 Benjamin TERRIER wrote:
> Hi everyone,
> 
> This message follows an exchange I've had with Thiago on a bug report:
> https://bugreports.qt.io/browse/QTBUG-49749
> 
> 
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot named "on__" in a given
> object,
> a child object named " and connect the signal to the
> slot. Moreover the documentation says that the search is recursive so
> any
> descendant QObject is looked up (not only direct children).
> 
> My issue here is that the search is done by instantiation order
> (depth-first search) which means that if 2 (or more) children have the
> same name one has
> to know which one is instantiated first to know which one will be
> connected. And of course imposing on the developer to use unique names
> throughout
> a QObject hierarchy is not feasible in particular if he/she is using a
> third-party library and might not know the object names used
> internally.
> 
> This can lead to various hazardous situation, for instance, in a
> perfectly working software, one can break the behavior of the main
> window by simply adding
> a widget in a grand-grand-child widget.
> Or worse if the UI is made using Qt Designer, the behavior of the
> application can be changed by simply reordering the widgets in the
> layout as it will also
> change their creation order.
> An application could even break at runtime if a user enables a plugin
> or set an HMI element visible.
> 
> In my opinion it also breaks encapsulation as the naming in a widget
> can alter the signal/slot connections in another widget.
> 
> 
> 
> My proposal is to change the behavior of connectSlotsByName to do a
> breadth-first search. In this case, if a direct child is a match it
> will be used
> for the connection regardless of possible matches deeper in the
> hierarchy. Doing so would solve the situations stated above and
> restore encapsulation.
> 
> 
> It seems that Thiago's opinion is that it can not be changed as this
> behavior has been here since Qt 4 and it might break existing
> applications.
> 
> On my side I think it's at least a buggy and error prone behavior or
> even a flawed design and that it must be changed as soon as possible.
> About the risk of breaking existing applications,
> I think making the change is less risky for Qt users as in the current
> state every Qt software can break with any change to an object name or
> instantiation order.
> Also as Qt Designer does push the users to use the connectSlotsByName
> mechanism, it is even possible to generate an example of this
> "unwanted" behavior
> without writing a single line of code (see attached zip in the bug report).
> 


I tend to agree with your proposal.
I don't think it will break too many applications because anyone who was 
relying on the order of instentiation for that has just its application 
working out of pure luck. (And i'm pretty sure that your proposal is always 
the intended behaviour)


Other possibilities may include:
 - Connect signals of both objects.  (Probably not a good idea since it does 
make it even more confusing)
 - Throw a warning if there are two objects with the same name.


-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

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

[Development] Proposal to change connectSlotsByName behavior

[Benjamin TERRIER]

Hi everyone,

This message follows an exchange I've had with Thiago on a bug report:
https://bugreports.qt.io/browse/QTBUG-49749


In the current state, QMetaObject::connectSlotsByName() tries to find,
for each slot named "on__" in a given
object,
a child object named " and connect the signal to the
slot. Moreover the documentation says that the search is recursive so
any
descendant QObject is looked up (not only direct children).

My issue here is that the search is done by instantiation order
(depth-first search) which means that if 2 (or more) children have the
same name one has
to know which one is instantiated first to know which one will be
connected. And of course imposing on the developer to use unique names
throughout
a QObject hierarchy is not feasible in particular if he/she is using a
third-party library and might not know the object names used
internally.

This can lead to various hazardous situation, for instance, in a
perfectly working software, one can break the behavior of the main
window by simply adding
a widget in a grand-grand-child widget.
Or worse if the UI is made using Qt Designer, the behavior of the
application can be changed by simply reordering the widgets in the
layout as it will also
change their creation order.
An application could even break at runtime if a user enables a plugin
or set an HMI element visible.

In my opinion it also breaks encapsulation as the naming in a widget
can alter the signal/slot connections in another widget.



My proposal is to change the behavior of connectSlotsByName to do a
breadth-first search. In this case, if a direct child is a match it
will be used
for the connection regardless of possible matches deeper in the
hierarchy. Doing so would solve the situations stated above and
restore encapsulation.


It seems that Thiago's opinion is that it can not be changed as this
behavior has been here since Qt 4 and it might break existing
applications.

On my side I think it's at least a buggy and error prone behavior or
even a flawed design and that it must be changed as soon as possible.
About the risk of breaking existing applications,
I think making the change is less risky for Qt users as in the current
state every Qt software can break with any change to an object name or
instantiation order.
Also as Qt Designer does push the users to use the connectSlotsByName
mechanism, it is even possible to generate an example of this
"unwanted" behavior
without writing a single line of code (see attached zip in the bug report).


Regards,

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

Re: [Development] RFC: more liberal 'auto' rules?

[Thiago Macieira]

On Thursday 03 December 2015 21:15:42 Bubke Marco wrote:
> On December 3, 2015 19:06:17 Thiago Macieira  
wrote:
> > On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> >> The remainder of the C++ world is moving towards an "always auto" scheme.
> >> We don't need to go there, but I'd at least like to propose, for new
> >> code and> 
> >> as a drive-by, the *required* use of auto for:
> > The remainder of the C++ world is no indication for us.
> 
> Actually I think it is. If Qt is to different we loosing mind share.

That depends on how big the remainder is. I argue that we're relevant enough 
that our own direction is big enough to be of relevance.

For example, we don't use exceptions and underscores.

> > Also remember that, for us, the source code is a product. We need to have
> > 
> > readable source code, so we have two ground rules that must be respected:
> >  1) the use of auto must make the code more readable, not less
> >  2) Qt Creator must be able to parse and deduce the correct type
> 
> They Clang code model is doing it already and we working hard on building up
> a infrastructure on țop of clang to exchange the old code model with the
> new clang version completely.
> > #2 is, of course, a transient issue, because Creator will get better over
> > time.

Good to know!

And since we're talking about it... when will Creator get support for 
concepts? :-P

That way, even in template code, it will be able to complete some things that 
the concept guarantees. Example:

template  concept bool IsNullable()
{
return requires(T type) { 
{type.isNull()} -> bool; 
}
}

template  bool isNull(T t)
{
return t.   // <--- should offer "isNull" here

-- 
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] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 3, 2015 19:06:17 Thiago Macieira  wrote:

> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
>> The remainder of the C++ world is moving towards an "always auto" scheme. We
>> don't need to go there, but I'd at least like to propose, for new code and
>> as a drive-by, the *required* use of auto for:
>
> The remainder of the C++ world is no indication for us.

Actually I think it is. If Qt is to different we loosing mind share. 

> Also remember that, for us, the source code is a product. We need to have 
> readable source code, so we have two ground rules that must be respected:
>
>  1) the use of auto must make the code more readable, not less
>  2) Qt Creator must be able to parse and deduce the correct type

They Clang code model is doing it already and we working hard on building up a 
infrastructure on țop of clang to exchange the old code model with the new 
clang version completely. 

> #2 is, of course, a transient issue, because Creator will get better over 
> time.
>
> As for #1, it's subjective. "More readable" does not mean "fewer characters". 
> If someone reading the code cannot understand what that variable is doing, 
> then it's less readable. Thankfully, Qt API is well designed so you can 
> usually tell from the function name what it does, without having to know the 
> class it is defined in. But it follows that if you're interfacing with non-Qt 
> API, then their API may be worse and this less readable. For example, the 
> "is" 
> prefix for boolean properties helps a lot, since you won't have to decide 
> whether a plain word in English is a state or a an action, as in "empty".
>
>> - template code (esp., but not necessarily only, when the type name would
>>   require the use of 'typename')
>
> Agreed, except when in violation of the ground rules.
>
>> - all loop variables (both index and iterators)
>
> Except for primitives, because "int" is shorter than "auto".
>
>>   the reason being that spelling out the name is usually wrong:
>>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>>   also helps when porting from Qt containers to STL ones
>
> I disagree. We'll use int, thank you. You know I disagree about porting from 
> Qt containers to Standard Library ones. Therefore, that is not an argument to 
> convince me to write uglier code with auto.
>
>> - all references to elements in a collection (same problem - way too easy to
>> misspell std::pair for std::pair...)
>
> Example?
>
>> Optional use of auto: whereever it makes sense. Use your own judgement, but
>> remember: fear is a bad advisor.
>> 
>> For range-for, I'd suggest the following patterns:
>> 
>> - loop variable: singular name of collection name (foo : foos)
>>   - otherwise: 'e' (for element) or first letter (r : rects)
>> - for (auto e : collection) // (for pass-by-value types, or if you modify)
>> - for (const auto &e : collection) // for pass-by-reference types
>> - for (auto &e : collection) // mutating (also: pointer variables/no auto
>> *&e) 
>
> Agreed.
>
>> - for (const auto *e : collection) // const pointers
>> - for (auto *e : collection) // non-const pointer
>
> Why? Why not allow "auto e" and e is a pointer?
>
>> - explicit type name should be the exception
>
> Agreed.
>
>> This is covering a large part of the usefulness of auto.
>> 
>> I don't really like to add anything more detailed to the "rules". Scott
>> Meyers' books do a much better job at explaining than we ever could.
>
> Qt has never and will never build without warnings from -Weffc++. Some of 
> Scott's rules are good, but we do not have to adopt them all.
>
> -- 
> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFutureInterface

[Alejandro Exojo]

El Friday 27 November 2015, Bauer, Christian escribió:
> Our (simplified) problem is: this function does not return a value but
> feeds an asynchronous pipeline. When the pipeline processing is done it
> will call promise.SetResult(); promise.reportResult();
> and only then the future should be notified of the result.

I would not mind see your patch in code review, and read what others have to 
say for or against. Having a QPromise or some other public API for QFuture 
would be nice, as you could attach a QFutureWatcher to it.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Alejandro Exojo]

El Thursday 03 December 2015, Mark De Wit escribió:
> Building from source would be an option, I guess.  We have done it in the
> past, but the build process / flags (for distribution) is not sufficiently
> well documented, and starting with 5.5.1 we were excited to be able to use
> official binaries.

When reproducing a build, I always start with the flags in this repository:

http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Matthew Woehlke]

On 2015-12-03 13:02, Thiago Macieira wrote:
> On 2015-12-03 13:49, Marc Mutz wrote:
> I'd at least like to propose, for new code and as 
>> a drive-by, the *required* use of auto for:
>> 
>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>>   also helps when porting from Qt containers to STL ones

You probably want my index range helper¹ for index iteration...
otherwise you need ugly work-arounds to use type deduction.

The enumerate helper is also useful for iterating over (Qt) associative
containers. (Needs to change to make a copy of the container, though, so
that it doesn't have dangling references in case of temporaries. That's
a trivial change though.)

(¹ http://permalink.gmane.org/gmane.comp.lib.qt.devel/21327)

> Except for primitives, because "int" is shorter than "auto".

Automatic matching of the index type to the type that the container
*actually uses for indices* is preferable to a shorter name. Even if you
"know" that the type is int.

Whether or not uses of Qt containers are ever replaced with use of STL
containers, it's just good habit. Maybe less important in Qt itself, but
I still submit that it would be good for Qt to demonstrate the "right"
way to do things. Because for your users, it *does* matter. (I have a
code base that is absolutely rife with index type mismatches because it
predates auto and qtIndexRange. With proper use of those, such errors
are avoided.)

MHO: don't use a possible type conversion if you can avoid it, and if
you do, use uniform initialization so that the compiler will reject a
narrowing conversion.

-- 
Matthew

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

Re: [Development] RFC: more liberal 'auto' rules?

[Thiago Macieira]

On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The remainder of the C++ world is moving towards an "always auto" scheme. We
> don't need to go there, but I'd at least like to propose, for new code and
> as a drive-by, the *required* use of auto for:

The remainder of the C++ world is no indication for us.

Also remember that, for us, the source code is a product. We need to have 
readable source code, so we have two ground rules that must be respected:

 1) the use of auto must make the code more readable, not less
 2) Qt Creator must be able to parse and deduce the correct type

#2 is, of course, a transient issue, because Creator will get better over 
time.

As for #1, it's subjective. "More readable" does not mean "fewer characters". 
If someone reading the code cannot understand what that variable is doing, 
then it's less readable. Thankfully, Qt API is well designed so you can 
usually tell from the function name what it does, without having to know the 
class it is defined in. But it follows that if you're interfacing with non-Qt 
API, then their API may be worse and this less readable. For example, the "is" 
prefix for boolean properties helps a lot, since you won't have to decide 
whether a plain word in English is a state or a an action, as in "empty".

> - template code (esp., but not necessarily only, when the type name would
>   require the use of 'typename')

Agreed, except when in violation of the ground rules.

> - all loop variables (both index and iterators)

Except for primitives, because "int" is shorter than "auto".

>   the reason being that spelling out the name is usually wrong:
>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>   also helps when porting from Qt containers to STL ones

I disagree. We'll use int, thank you. You know I disagree about porting from 
Qt containers to Standard Library ones. Therefore, that is not an argument to 
convince me to write uglier code with auto.

> - all references to elements in a collection (same problem - way too easy to
> misspell std::pair for std::pair...)

Example?

> Optional use of auto: whereever it makes sense. Use your own judgement, but
> remember: fear is a bad advisor.
> 
> For range-for, I'd suggest the following patterns:
> 
> - loop variable: singular name of collection name (foo : foos)
>   - otherwise: 'e' (for element) or first letter (r : rects)
> - for (auto e : collection) // (for pass-by-value types, or if you modify)
> - for (const auto &e : collection) // for pass-by-reference types
> - for (auto &e : collection) // mutating (also: pointer variables/no auto
> *&e) 

Agreed.

> - for (const auto *e : collection) // const pointers
> - for (auto *e : collection) // non-const pointer

Why? Why not allow "auto e" and e is a pointer?

> - explicit type name should be the exception

Agreed.

> This is covering a large part of the usefulness of auto.
> 
> I don't really like to add anything more detailed to the "rules". Scott
> Meyers' books do a much better job at explaining than we ever could.

Qt has never and will never build without warnings from -Weffc++. Some of 
Scott's rules are good, but we do not have to adopt them all.

-- 
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] RFC: more liberal 'auto' rules?

[Marc Mutz]

Hi,

The wiki[1] currently contains some rules for how to use automatic type 
deduction for variables (Q_C_AUTO_TYPE) that are very restrictive.

[1] I get an ERROR: state not found when trying to log in, btw.

And pointless.

The remainder of the C++ world is moving towards an "always auto" scheme. We 
don't need to go there, but I'd at least like to propose, for new code and as 
a drive-by, the *required* use of auto for:

- template code (esp., but not necessarily only, when the type name would
  require the use of 'typename')
- all loop variables (both index and iterators)
  the reason being that spelling out the name is usually wrong:
  size_t i = stdVector.size() // wrong, should be std::vector::size_type...
  also helps when porting from Qt containers to STL ones
- all references to elements in a collection (same problem - way too easy to
  misspell std::pair for std::pair...)

Optional use of auto: whereever it makes sense. Use your own judgement, but 
remember: fear is a bad advisor.

For range-for, I'd suggest the following patterns:

- loop variable: singular name of collection name (foo : foos)
  - otherwise: 'e' (for element) or first letter (r : rects)
- for (auto e : collection) // (for pass-by-value types, or if you modify)
- for (const auto &e : collection) // for pass-by-reference types
- for (auto &e : collection) // mutating (also: pointer variables/no auto *&e)
- for (const auto *e : collection) // const pointers
- for (auto *e : collection) // non-const pointer
- explicit type name should be the exception

This is covering a large part of the usefulness of auto.

I don't really like to add anything more detailed to the "rules". Scott 
Meyers' books do a much better job at explaining than we ever could.

Opinions?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Thiago Macieira]

On Thursday 03 December 2015 18:13:58 Konstantin Tokarev wrote:
> > Instead, you should build this:
> > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-o
> > pensource-src-5.5.1.zip
> > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-> 
> > > opensource-src-5.5.1.tar.gz
> No, thanks, I need features which I've contributed to 5.6 branch.

You can compile your own version of qtwebkit, no problem. I have my own 
patches to it.

That doesn't mean they will be released.

-- 
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] Please do not remove QtWebkit from 5.6 official binaries

[Konstantin Tokarev]

03.12.2015, 18:05, "Thiago Macieira" :
> On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote:
>>  > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are
>>  > also
>>  > QtWebKit 5.6.0 sources in git, they are just not part of the official
>>  > release.
>>  Why not at least package its sources them same way as are sources of Qt
>>  add-ons?
>
> Because we decided not to. We should not even have created the 5.6 branch on
> that repository, because there will be no 5.6.0 release. The changes that
> landed on that branch will remain forever unreleased.
>
> Instead, you should build this:
> http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip
> http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz

No, thanks, I need features which I've contributed to 5.6 branch.

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Thiago Macieira]

On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote:
> > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are
> > also
> > QtWebKit 5.6.0 sources in git, they are just not part of the official
> > release.
> Why not at least package its sources them same way as are sources of Qt
> add-ons?

Because we decided not to. We should not even have created the 5.6 branch on 
that repository, because there will be no 5.6.0 release. The changes that 
landed on that branch will remain forever unreleased.

Instead, you should build this:
http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip
http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz

-- 
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] Please do not remove QtWebkit from 5.6 official binaries

[Shaw Andy]

There is QPdfWriter at least which is a paint device, so you could use that for 
generating PDFs as that is available iOS from what I can see.

Andy

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Edward Sutton
Sent: 3. desember 2015 15:09
To: Mark De Wit
Cc: development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries

Will Qt 5.6 have alternative methods to export HTML to PDF that support major 
platforms of Android, iOS, Linux, OS X, and Windows?

On iOS a Qt developer must resort to native code to generate PDF files.

Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported 
on iOS.  While iOS can create and displays PDF’s just fine, iOS has no printer 
support.


In the future, Is it possible the PDF creation dependency could be separated 
from QPrinter?  So that Qt PDF generation would have better cross-platform 
support?



QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on 
iOS

printer.setOutputFormat(QPrinter::PdfFormat);

printer.setOutputFileName(pdfFileName);

drawReport(printer);

m_painter.end();


Without understanding internals of PDF file creation, it feels like PDF 
creation should not be dependent on QPrinter?

-Ed


On Dec 3, 2015, at 7:37 AM, Mark De Wit 
mailto:mark.de...@iesve.com>> wrote:

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I’m happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit mailto:mark.de...@iesve.com>>; 
development@qt-project.org
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Edward Sutton]

Will Qt 5.6 have alternative methods to export HTML to PDF that support major 
platforms of Android, iOS, Linux, OS X, and Windows?

On iOS a Qt developer must resort to native code to generate PDF files.

Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported 
on iOS.  While iOS can create and displays PDF’s just fine, iOS has no printer 
support.


In the future, Is it possible the PDF creation dependency could be separated 
from QPrinter?  So that Qt PDF generation would have better cross-platform 
support?


QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on 
iOS

printer.setOutputFormat(QPrinter::PdfFormat);

printer.setOutputFileName(pdfFileName);

drawReport(printer);

m_painter.end();


Without understanding internals of PDF file creation, it feels like PDF 
creation should not be dependent on QPrinter?

-Ed


On Dec 3, 2015, at 7:37 AM, Mark De Wit 
mailto:mark.de...@iesve.com>> wrote:

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I’m happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit mailto:mark.de...@iesve.com>>; 
development@qt-project.org
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Mark De Wit]

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I'm happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit ; development@qt-project.org
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Konstantin Tokarev]

03.12.2015, 15:41, "Allan Sandfeld Jensen" :
> On Thursday 03 December 2015, Mark De Wit wrote:
>>  Hi all,
>>
>>  QtWebEngine does not yet have feature parity with QtWebkit. For instance,
>>  print support (especially export to PDF) is a critical requirement for my
>>  use of Webkit. This missing feature prevents me from migrating to
>>  WebEngine.
>>
>>  Removing webkit from the official distribution will prevent me (and surely
>>  others) from upgrading to 5.6.
>
> Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are also
> QtWebKit 5.6.0 sources in git, they are just not part of the official release.

Why not at least package its sources them same way as are sources of Qt add-ons?

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Allan Sandfeld Jensen]

On Thursday 03 December 2015, Mark De Wit wrote:
> Hi all,
> 
> QtWebEngine does not yet have feature parity with QtWebkit.  For instance,
> print support (especially export to PDF) is a critical requirement for my
> use of Webkit.  This missing feature prevents me from migrating to
> WebEngine.
> 
> Removing webkit from the official distribution will prevent me (and surely
> others) from upgrading to 5.6.
> 
Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are also 
QtWebKit 5.6.0 sources in git, they are just not part of the official release.

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Turunen Tuukka]

Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[André Somers]

Op 03/12/2015 om 12:18 schreef Mark De Wit:


Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For 
instance, print support (especially export to PDF) is a critical 
requirement for my use of Webkit.  This missing feature prevents me 
from migrating to WebEngine.


Removing webkit from the official distribution will prevent me (and 
surely others) from upgrading to 5.6.



You should still be able to build QtWebkit against 5.6 if I understand 
it correctly, so you can still upgrade if you want. It does take more 
effort though.


André

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

[Development] Please do not remove QtWebkit from 5.6 official binaries

[Mark De Wit]

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

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