Re: [Development] Proposal to change connectSlotsByName behavior

[André Somers]

 >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?

 Both. A breath first search makes sense there as well. I don't think 
the

 order of the children is specified there so one should not rely on it
 anyway.


It isn't specified, so we can change.

But I'd expect that the flattening of the tree produces depth-first. 
Breadth-

first could result in a violation of the principle of least surprise.
Why? That is not my expectation at all. If you ask somebody if he has a 
child named Maria, is he most likely to first name his second daughter 
or the granddaughter by his first child you think?




 I'd like to add a new alternative (though it does not exclude a 
change

 now either):

 - Deprecate the behaviour and remove in Qt 6.


What behaviour would you want to be removed? The whole 
connectSlotsByName()?
Yes, the whole feature. IMnsHO it is indeed a misfeature as Eike called 
it. There are a few more in Qt, but this certainly is one.


André

___
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]

Hmm, interesting, I wasn't aware of that location.  However, I don't think 
those flags are right, hasn't OpenGL switched to be Dynamic instead of Desktop, 
for instance?

Having looked around further, I'm liking the look of this:

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

Mark

-Original Message-
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Alejandro Exojo
Sent: 03 December 2015 19:08
To: development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries

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
___
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 08:16:43 André Somers wrote:
> >But I'd expect that the flattening of the tree produces depth-first.
> >Breadth-
> >first could result in a violation of the principle of least surprise.
> 
> Why? That is not my expectation at all. If you ask somebody if he has a
> child named Maria, is he most likely to first name his second daughter
> or the granddaughter by his first child you think?

I agree and disagree. The listing people may use in their heads may look like 
breadth first, but it's actually more chaotic. If you asked someone to name all 
the descendants of a grandparent, they will probably group siblings, and the 
groups may be sorted by generation, but within each generation the groups may 
be out of order.

Nana
Alice   Bob Charlie 
Dave
Elsa, Frank Gerald, Hector, Isabel   Joey,Kevin Lisa

If you ask for someone to list that, it may come out as "Alice, Bob, Dave, 
Charlie, Gerald, Hector, Isabel, Lisa, Elsa, Frank, Kevin, Joey"

However, when talking about computer programming, I'd wager that people expect 
depth-first, if not for the simple reason that this is how they'd implement it 
if they were asked to.

-- 
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?

[Marc Mutz]

On Friday 04 December 2015 08:35:05 Randall O'Reilly wrote:
> 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.. :)

You should be monitoring the community you are so quick to judge. Google GSL. 
Just because something has been done that way for decades doesn't mean it's 
best, for any definiton of the word.

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

[Thiago Macieira]

On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > 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. 

That's why we use the mailing list and discuss the issue. Our collective minds 
together are quite powerful.

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

You're calling for "opt-in by default" approach, while I am calling for an 
"opt-out by default" approach. Since we need to decide which C++ features to 
use in the first place due to old compilers we need to support, I think we're 
effectively "opt-out by default".

But either way, the end result is the same.

> > we don't use underscores
> 
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!

Not in our API. Those qt_ functions are private API. The underscore is, in 
fact, the marker that it is private.

-- 
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?

[Olivier Goffart]

On Friday 4. December 2015 00:13:33 Thiago Macieira wrote:
> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > > we don't use underscores
> > 
> > ... except we do (grep "qt_"). And there's *nothing* wrong with that!
> 
> Not in our API. Those qt_ functions are private API. The underscore is, in
> fact, the marker that it is private.

Except in macros.  (Ok, this is going too far :-))
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to change connectSlotsByName behavior

[André Somers]

-- Original Message --
From: "Thiago Macieira" 
To: development@qt-project.org
Sent: 04/12/2015 03:00:15
Subject: Re: [Development] Proposal to change connectSlotsByName 
behavior



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.
There are explicit methods for setting the tab order. Relying of the 
order of creation (which may be the default tab order - I did not check) 
is also pure luck, especially with designer-created UI's. I would think 
the connect-by-name is more used with designer created UI's than with 
hand-crafted UI.




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

list.


I am for it. I think it makes more sense than the current behaviour.


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?
Both. A breath first search makes sense there as well. I don't think the 
order of the children is specified there so one should not rely on it 
anyway.




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.

Because that is an implementation detail. That the one uses the other 
makes it convenient for them to be the same, but the one does not _need_ 
to use the other. But in this case I think it makes sense for both to 
change. If changing findChildren is regarded as too risky though, I 
don't think that that is an argument to not change connectSlotsByName 
either.



 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.

I'd like to add a new alternative (though it does not exclude a change 
now either):


- Deprecate the behaviour and remove in Qt 6.

I have never thought this feature to lead to good design. It makes for 
"magic" in the sense that it is tricky to trace what happened. It leads 
to un-Qt-ish naming of methods, and it leads to naming methods based on 
when they are triggered instead of what they do. I find the latter 
usually leads to more readable code, more so if there is more than one 
way to trigger the behaviour encoded in the method. Last, I think 
private slots (for which this would be most used) are largely on the way 
out anyway. Trivial slots can be replaced by lambda's and non-trivial 
ones need a good function name anyway.


André





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

[Development] Explicit tree data structure in Qt (was: Re[2]: Proposal to change connectSlotsByName behavior)

[André Somers]

-- Original Message --
From: "Thiago Macieira" 
To: development@qt-project.org
Sent: 04/12/2015 09:33:03
Subject: Re: [Development] Proposal to change connectSlotsByName 
behavior



On Friday 04 December 2015 08:16:43 André Somers wrote:

 >But I'd expect that the flattening of the tree produces depth-first.
 >Breadth-
 >first could result in a violation of the principle of least 
surprise.


 Why? That is not my expectation at all. If you ask somebody if he has 
a
 child named Maria, is he most likely to first name his second 
daughter

 or the granddaughter by his first child you think?


I agree and disagree. The listing people may use in their heads may 
look like
breadth first, but it's actually more chaotic. If you asked someone to 
name all
the descendants of a grandparent, they will probably group siblings, 
and the
groups may be sorted by generation, but within each generation the 
groups may

be out of order.

   Nana
 Alice Bob Charlie Dave
Elsa, Frank Gerald, Hector, Isabel Joey,Kevin Lisa

If you ask for someone to list that, it may come out as "Alice, Bob, 
Dave,

Charlie, Gerald, Hector, Isabel, Lisa, Elsa, Frank, Kevin, Joey"
Well, indeed you are right. If I am to name or even count descendants, 
I'd probably go depth-first.




However, when talking about computer programming, I'd wager that people 
expect
depth-first, if not for the simple reason that this is how they'd 
implement it

if they were asked to.

This is getting off topic, but this discussion does make me wonder - 
again - if we shouldn't move away from this intrusive parent-children 
data structure completely. We are not using intrusive data structures 
any more to create (linked) lists, why do we still do that for 
trees/forests? Then, you would just get the iterator with the behaviour 
you need (depth first or breath first or some other access pattern) and 
run whatever algorithm you need on that. And yes, that would be a very, 
very intrusive change.


André

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

Re: [Development] QFutureInterface

[Marc Mutz]

On Friday 27 November 2015 13:45:28 Bauer, Christian wrote:
> Hi Marc,
> 
> > You should be able to develop a QPromise/QPackagedTask with the current
> > QFutureInterface already. At least as long as it's attached to some >
> > QThreadPool.
> > What, exactly, are you trying to do that requires a patch to QFI?
> 
> I am not aware of any QPackagedTask in Qt, only of packaged_task in C++11.
> Or do you mean RunFunctionTaskBase?

I said "you can develop one", not that there _is_ one already :)

[...]
> 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.

1. Inherit your runnable from QRunnable and QFutureInterface
In the ctor, call QFI::setRunnable(this).
2. Create an instance of your runnable, call runnable.future() to get the
QFuture end
3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool*
for how to implant that into the QFutureInterface so work stealing works).
4. From within runnable::run() operate the QFutureInterface API
5. Use the QFuture obtained in (2) as you'd use an other future.

> We can achieve this by using a custom waitForFinished() in our future
> wrapper, instead of using the QFuture waitForFinished. But this requires
> access to the QWaitCondition of the QFutureInterface.

Don't understand this, but maybe I don't need to. Just tell me where your use-
case fails in the recipe above.

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 08:39:55 Olivier Goffart wrote:
> > 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.

You're right. I seem to remember the order being important for tabbing, but I 
guess it's something from before Qt 4 then.

Ok, that argument is gone.

> > 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.

[cut part about findChild, which is not relevant]

> 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.

For cleanliness purposes, I would prefer both functions get changed.

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

[Marc Mutz]

On Friday 04 December 2015 09:04:18 Thiago Macieira wrote:
> > The tab order is set with QWidget::setTabOrder and does not depends on
> > the order of the children.
> 
> You're right. I seem to remember the order being important for tabbing, but
> I  guess it's something from before Qt 4 then.
> 
> Ok, th

Construction order is the _default_ tab order. Using setTabOrder is bad style. 
So yes, construction order of widgets is still important.

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

[Marc Mutz]

On Friday 04 December 2015 00:05:19 Benjamin TERRIER wrote:
> In my opinion it also breaks encapsulation as the naming in a widget
> can alter the signal/slot connections in another widget.

This is precisely the reason why connectSlotsByName is a bad idea in the first 
place; changing the name of a widget breaks connections (at runtime, not at 
compile time as with QObject::connect()).

Just don't use it. Then we can let the function r.i.p. come Qt 6... :)

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

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Thiago Macieira
> Sent: Friday, 4 December 2015 9:14
> To: development@qt-project.org
> Subject: Re: [Development] RFC: more liberal 'auto' rules?
> 
> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > > 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.
> 
> That's why we use the mailing list and discuss the issue. Our collective minds
> together are quite powerful.

First of all I'd like to point out that I agree with Thiago and Randall. In 
fact, I added the auto policy to the Qt coding conventions.

This policy has been in place for much longer in Qt Creator (and therefore the 
Qt version  just an adoption). I had my fair share of arguing over what is 
better or worse readability wise. At the end of the day it's subjective which 
makes argumentation about right or wrong harder. For me the point is that if I 
have to look up a function signature to figure out what type is behind the 
return values auto type then that's bad. An always auto policy is just asking 
for such situations. 

> You're calling for "opt-in by default" approach, while I am calling for an
> "opt-out by default" approach.

+1
--
Alex


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

Re: [Development] QFutureInterface

[Bauer, Christian]

Hi Marc,

First: thanks for your suggestions.

> 1. Inherit your runnable from QRunnable and QFutureInterface
>In the ctor, call QFI::setRunnable(this).
>2. Create an instance of your runnable, call runnable.future() to get the
>QFuture end
> 3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool*
>for how to implant that into the QFutureInterface so work stealing works).
> 4. From within runnable::run() operate the QFutureInterface API 5. Use 
>the  QFuture obtained in (2) as you'd use an other future.
So the QPackagedTask would be a Runnable that you run on the thread pool, and 
that runnable represents a QPromise at the same time.

Maybe I am missing something here, but I don't think this solves my problem.
In my scenario, the QPackagedTask does not produce the result. The task only 
triggers something else that will - in some point in the future - produce the 
actual result. By the time the result is produced, the original QPackagedTask 
does not even exist anymore. 

The idea of the patch is to support decoupling the Promise (QFI) from the task 
that I schedule via QConcurrent::run().
Some task will call the promise and set the result, instead of the promise 
receiving the return value of the task.

I could provide a code example if this helps...

Thanks
 Christian

___
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 09:13:33 Thiago Macieira wrote:
> You're calling for "opt-in by default" approach, while I am calling for an 
> "opt-out by default" approach. Since we need to decide which C++ features
> to  use in the first place due to old compilers we need to support, I
> think we're effectively "opt-out by default".

Opt-in for _which_ C++ features to use, sure.

But opt-out of _how_ to use them, vis a vis the greater C++ community.

The guidelines on lambdas in the coding standard are pretty good in that 
regard. They point out specific compiler bugs (some of which may no longer play 
a role in 5.7, e.g. MSVC 2010), and mandate certain workarounds, but do not 
further restrict the use of lambdas.

The guideline for auto is not at all like that, though.

Given a (beautiful) auto variable and an (ugly) lambda, I'd say that it's 
lambdas which make the code less readable, not auto. But if readability is 
only defined as "I can see all types", then the reverse it true, yes.


On Friday 04 December 2015 10:45:06 Blasche Alexander wrote:
>  For me the point is that if I have to look up a function signature to
>  figure out what type is behind the return values auto type then that's
>  bad.

Playing the devil's advocate here, I wonder how we could have accepted code 
like this before:

le->setText(foo.description());

after all, you have to "look up the description() signature to figure out which 
type" is being passed to setText(), as defined above. We all write code like 
the above. And not only if the involved functions scream "it's QString, 
stupid".

But now people (not saying 'you') will be vehemently -1'ing the completely 
equivalent code

   const auto desc = foo.description();
   le->setText(desc);

on grounds of reduced readbility compared to

   const QString desc = foo.description();
   le->setText(desc);

That makes no sense.

And as an aside, since it has been mentioned in this thread: in Python _all_ 
variables are 'auto'. All. Without exception. Are Python programmers more 
intelligent? Or do they just tolerate more pain? :)

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] QFutureInterface

[Marc Mutz]

On Friday 04 December 2015 10:49:04 Bauer, Christian wrote:
> I could provide a code example if this helps...

Yes, please provide a short example with std::promise, which, afaiu, works for 
your use-case.

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] New Qt5.6 Beta snapshot available

[Heikkinen Jani]

Hi all,


We have finally new qt5.6 beta snapshot available


Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/

Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/

Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/

Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/



Unfortunately it seems these aren't yet final beta packages, in mac package 
creator seems to be unusable because of 
QTBUG-49676 [Reg 5.5->5.6]: 
Painting of widgets broken when embedding QQuickWidget


Please test the packages & report all findings in Jira. We are trying to get 
beta out as soon as possible so please inform all new beta blockers to me 
immediately.


br,

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

[Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget?

[René J . V . Bertin]

Hi,

What are the native classes (widgets) used to implement QTabBar and QTabWidget 
widgets on OS X? I was expecting NSTabView and family, but can find no 
occurrence of anything related in the source.

Cf:
https://bugreports.qt.io/browse/QTBUG-49758


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

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

[Rafael Roquetto]

On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > And as an aside, since it has been mentioned in this thread: in Python
> > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > programmers more intelligent? Or do they just tolerate more pain? :)
> > 
> > i'd suggest the latter.
> > no, really. people use external static checkers because the language
> > lacks the feature.
> > the lack of static typing is a common feature of scripting languages and
> > makes them convenient to a degree, but it is an utter nightmare for any
> > "real" software development. i really wouldn't want to go there.
> 
> But auto is still staticaly typed.
> 
> 
> When you have code like
> 
>foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> 
> You don't see any type. 
> 
> This code that use auto is not less readable. Even if you don't know what's 
> the type of bar without looking it up.
> 
>   auto *bar = foo->bar();
>   bar->setFaz(m_factory->createFaz(bar->type()));

Until you need to change your code and call any method of bar. Suppose I
need to change the following code, to print the first item of the collection:

auto *bar = foo->collection();

/*TODO: print first item here */

model->setCollection(bar); // we know bar is a collection, but of what kind?


Choose the right alternative:

a) qDebug() << bar->first();
b) qDebug() << bar->values().first();
c) qDebug() << bar[0]
d) none of the above


To answer this, you will need to find out the return type of
Foo::collection(); The compiler knows it, but the reader does not. And the
answer depends on whether it is  a QList/QVector, QHash/QMap, etc... Had it
been explicit, any programmer familiar with the Qt API (or any API in context)
would be able to directly write down the right statement.


Just an idea.

Cheers,
Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts


smime.p7s
Description: S/MIME cryptographic signature
___
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 4, 2015 08:35:19 Randall O'Reilly  
wrote:

> 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..

Hmm,  do you really believe we cannot improve? If you compare signal and slots 
with resumable functions it looks quite complicated for many use cases. Look 
how complicated our network API is. It could be much easier with resumable 
functions. I don't say signal slots should go away but should be used in places 
their they have still an advantage. 

Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but 
now C++ is incorporating many advanced features for concurrency and other areas 
from C#,  Python and other interesting languages. The world is changing and we 
should adapt to this changing context. 

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

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

[Bubke Marco]

On December 4, 2015 10:45:19 Blasche Alexander 
 wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf
>> Of Thiago Macieira
>> Sent: Friday, 4 December 2015 9:14
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
>> > > 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.
>> 
>> That's why we use the mailing list and discuss the issue. Our collective 
>> minds
>> together are quite powerful.
>
> First of all I'd like to point out that I agree with Thiago and Randall. In 
> fact, I added the auto policy to the Qt coding conventions.
>
> This policy has been in place for much longer in Qt Creator (and therefore 
> the Qt version  just an adoption). I had my fair share of arguing over what 
> is better or worse readability wise. At the end of the day it's subjective 
> which makes argumentation about right or wrong harder. For me the point is 
> that if I have to look up a function signature to figure out what type is 
> behind the return values auto type then that's bad. An always auto policy is 
> just asking for such situations. 

With the clang code model it is quite easy to provide that information. In my 
opinion it is better to give your functions and variables descriptive names so 
you don't need to look for the declaration. 

For Test Driven Development it is better to use auto if you must exchange types 
with mocks. So the interface(concepts) is important but not the type.

>> You're calling for "opt-in by default" approach, while I am calling for an
>> "opt-out by default" approach.
>
> +1
> --
> Alex
>
>
> ___
> 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] RFC: more liberal 'auto' rules?

[Knoll Lars]

I think we all agree with the goal we have with Qt to make C++ development 
accessible and easy. This is something we will continue to do. 

But the question asked here was about how we use a certain c++11 feature in our 
*implementation*. This is clearly different from what we do with our APIs and 
what we ask our users to know.

To implement Qt, we can and should use C++ in the most efficient way. If it 
makes sense to use certain features (and we can actually use them on all 
platforms), let's use them. But of course let's not force all of these upon our 
users.

Cheers,
Lars




On 04/12/15 08:58, "Development on behalf of Smith Martin" 
 
wrote:

>+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
>> 

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

[Olivier Goffart]

On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > And as an aside, since it has been mentioned in this thread: in Python
> > _all_ variables are 'auto'. All. Without exception. Are Python
> > programmers more intelligent? Or do they just tolerate more pain? :)
> 
> i'd suggest the latter.
> no, really. people use external static checkers because the language
> lacks the feature.
> the lack of static typing is a common feature of scripting languages and
> makes them convenient to a degree, but it is an utter nightmare for any
> "real" software development. i really wouldn't want to go there.

But auto is still staticaly typed.


When you have code like

   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));

You don't see any type. 

This code that use auto is not less readable. Even if you don't know what's 
the type of bar without looking it up.

  auto *bar = foo->bar();
  bar->setFaz(m_factory->createFaz(bar->type()));



___
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]

On Dec 3, 2015, at 8:31 AM, Shaw Andy 
> wrote:

>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.

I *really* need to spend some time browsing All 
Classes  !

http://doc.qt.io/qt-5/classes.html

Thanks again Andy!

-Ed


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 
> 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 >; 
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.

This 

[Development] Qt infra maintenance during weekend

[Hirvonen Olli]

There will be downtime on some development servers on coming weekend 5.-6.12. 
This is due to virtualization platform organization.

Maintenance starts on Saturday 5.12. at 08:00 CET and it might take until 
Sunday 16:00 CET. Estimation of the break is hard to estimate. Hopefully break 
is shorter.

For example, CI does not work during that time. IT guys will inform Coin 
operators (Frederik, Simon and Jedrzej) after machines are up and running again.

Sorry for the inconvenience caused.

-Olli

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

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

[Koehne Kai]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Subject: [Development] RFC: more liberal 'auto' rules?
> 
>[..]
> 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:
> 

Just want to comment on this argument ...

I know that some influential members are suggesting the AAA (almost always 
auto), 
but I think it's a bit overboard to claim that this is "the C++ world".

Take for instance the coding guidelines of Clang:

http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

Or google:

https://google.github.io/styleguide/cppguide.html#auto

Even the C++ core guidelines don't explicitly say 'use auto always', but only 
to avoid redundant repetition of type names:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-auto

So I think the ruling is still out whether the "AAA style" is really picked up 
by a lot of projects.

Regards

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

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> And as an aside, since it has been mentioned in this thread: in Python _all_ 
> variables are 'auto'. All. Without exception. Are Python programmers more 
> intelligent? Or do they just tolerate more pain? :)
> 
i'd suggest the latter.
no, really. people use external static checkers because the language
lacks the feature.
the lack of static typing is a common feature of scripting languages and
makes them convenient to a degree, but it is an utter nightmare for any
"real" software development. i really wouldn't want to go there.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to change connectSlotsByName behavior

[Giuseppe D'Angelo]

On Fri, Dec 4, 2015 at 12:05 AM, Benjamin TERRIER  wrote:
>
> 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.

I don't like the idea of changing a behaviour which is now more than
10 years old. If so, it must happen for Qt 6, and the best we can do
in Qt 5 is add warnings (in debug builds of Qt?) that
connectSlotsByName with multiple children matching the name leads to
undefined results and can change at any time...

About findChild(ren) ordering, I would say to fix the documentation
(once more because people using it are relying on the behaviour).

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

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > And as an aside, since it has been mentioned in this thread: in Python
> > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > programmers more intelligent? Or do they just tolerate more pain? :)
> > 
> > i'd suggest the latter.
> > no, really. people use external static checkers because the language
> > lacks the feature.
> > the lack of static typing is a common feature of scripting languages and
> > makes them convenient to a degree, but it is an utter nightmare for any
> > "real" software development. i really wouldn't want to go there.
> 
> But auto is still staticaly typed.
> 
that's why using a scripting language as a source of arguments wasn't a
very wise move tactically, even as an aside. ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget?

[Olivier Goffart]

On Friday 4. December 2015 12:10:10 René J.V. Bertin wrote:
> Hi,
> 
> What are the native classes (widgets) used to implement QTabBar and
> QTabWidget widgets on OS X? I was expecting NSTabView and family, but can
> find no occurrence of anything related in the source.

QWidgets (and QML) don't use native UI views. They draw everything themself.
The drawing is done in the style (qmacstyle_mac.mm in this case)

So to repeat:
QTabBar::paintEvent asks the style to paint the tabs 
QMacStyle::drawControl (see the case CE_TabBarTabShape) draws it.
Apparently it's using HIThemeTabDrawInfo and HIThemeDrawTab.

I hope this answer your question.

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

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

[Edward Sutton]

On Dec 4, 2015, at 7:53 AM, Mark De Wit 
> wrote:

>We tried this solution already in combination with WebEngine.  It draws a 
>bitmap of the current view into the PDF.  Even text gets rendered as bitmaps, 
>it is a far cry from supporting our multi-page HTML documents.

I may have tried QPdfWriter once as well and had issues with sizing and 
scaling.  I know I spent a *lot* of time with cross-platform PDF generation 
development.

Rendering PDF report text as bitmaps would not be acceptable to my customers 
either.

Not good news for developers that must create PDFs on iOS.

-Ed


Mark

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 04 December 2015 13:31
To: Shaw Andy >
Cc: Mark De Wit >; 
development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 3, 2015, at 8:31 AM, Shaw Andy 
> wrote:

>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.

I *really* need to spend some time browsing All 
Classes  !

http://doc.qt.io/qt-5/classes.html

Thanks again Andy!

-Ed



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 
> 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 >; 
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.

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

[Mark De Wit]

We tried this solution already in combination with WebEngine.  It draws a 
bitmap of the current view into the PDF.  Even text gets rendered as bitmaps, 
it is a far cry from supporting our multi-page HTML documents.

Mark

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 04 December 2015 13:31
To: Shaw Andy 
Cc: Mark De Wit ; development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 3, 2015, at 8:31 AM, Shaw Andy 
> wrote:

>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.

I *really* need to spend some time browsing All 
Classes  !

http://doc.qt.io/qt-5/classes.html

Thanks again Andy!

-Ed



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 
> 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 >; 
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 

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

[Shaw Andy]

It wasn’t meant to be seen as a viable solution for rendering from QtWebEngine 
at least, but more for if you were already rending to a QPrinter with QPainter. 
If you use drawText() and so forth then that should work with QPdfWriter in a 
way that makes the text be rendered as text in the PDF. If this is not 
happening then please report it as it should be handled correctly in that 
instance.

Andy

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 4. desember 2015 15:07
To: Mark De Wit
Cc: Shaw Andy; development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 4, 2015, at 7:53 AM, Mark De Wit 
> wrote:

>We tried this solution already in combination with WebEngine.  It draws a 
>bitmap of the current view into the PDF.  Even text gets rendered as bitmaps, 
>it is a far cry from supporting our multi-page HTML documents.

I may have tried QPdfWriter once as well and had issues with sizing and 
scaling.  I know I spent a *lot* of time with cross-platform PDF generation 
development.

Rendering PDF report text as bitmaps would not be acceptable to my customers 
either.

Not good news for developers that must create PDFs on iOS.

-Ed


Mark

From: Edward Sutton [mailto:edward.sut...@subsite.com]
Sent: 04 December 2015 13:31
To: Shaw Andy >
Cc: Mark De Wit >; 
development@qt-project.org
Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


On Dec 3, 2015, at 8:31 AM, Shaw Andy 
> wrote:

>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.

I *really* need to spend some time browsing All 
Classes  !

http://doc.qt.io/qt-5/classes.html

Thanks again Andy!

-Ed




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 
> 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 >; 
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,

  

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

[Marc Mutz]

On Friday 04 December 2015 14:12:00 Rafael Roquetto wrote:
> Until you need to change your code and call any method of bar.

QtC prints the signature of the function when you hover the mouse over it — 
since _ages_. It also completes function names of auto variables. Since 
_ages_. Even if it should be the case that it doesn't, yet, show the deduced 
type when you hover over the 'auto', the lhs can be inspected by hovering, and 
the rhs's type is clear[1].

But ok, for those of us using vi, I motion to ban function chaining like

le->setText(foo.description());

or

   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));

Everyone in favour of restricting auto use due to readability concerns is 
automatically (no pun intended) counted as in-favour of the motion, with 
prejudice.

Thanks,
Marc

[1] If it's not clear, we need to ban the use of template functions.

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

[Nicolás Ulrich]

Would be great something like Android Studio does with some things.
For example it shows the "deduced" string in a different format (top) and
when you click/modify it shows the "real" code (bottom)

[image: Screenshot 2015-12-04 13.55.13.png]


On Fri, Dec 4, 2015 at 1:49 PM Thiago Macieira 
wrote:

On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
> The clang code model completes auto so it should be not that hard.
Actually
> I would call an ordered map or unordered map a dictionary.

Does Creator have a way to reveal the deduced type of an auto? That would
go a
long way to alleviating the pain of using it.

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

[Marc Mutz]

On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote:
> > But auto is still staticaly typed.
> >
> > 
> 
> that's why using a scripting language as a source of arguments wasn't a
> very wise move tactically, even as an aside. ;)

I, indeed, did not anticipate that anyone here would be able to seriously 
confuse static typing and var/auto, the omitting of the type name in variable 
declarations.

I have the feeling I wasn't wrong, though.

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

[Thiago Macieira]

On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
> The clang code model completes auto so it should be not that hard.  Actually
> I would call an ordered map or unordered map a dictionary. 

Does Creator have a way to reveal the deduced type of an auto? That would go a 
long way to alleviating the pain of using it.

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

[Benjamin TERRIER]

2015-12-04 10:30 GMT+01:00 Marc Mutz :
> This is precisely the reason why connectSlotsByName is a bad idea in the first
> place; changing the name of a widget breaks connections (at runtime, not at
> compile time as with QObject::connect()).
>
> Just don't use it. Then we can let the function r.i.p. come Qt 6... :)

As many seems to think connectSlotsByName should not be used, maybe it
should be, as André Somers said, deprecated.

However it is used by the designer plugin within Qt Creator as it uses
the fact that uic will generate a call to connectsSlotByName to
automatically generates slots when the user clicks on "Go to slots.."
in the context menu.
This means that every widget class that has a ui file will call
connectSlotsByName.
There is still an open bug report asking to make the call optional
(https://bugreports.qt.io/browse/QTBUG-27866)

BR,

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 Friday 04 December 2015 15:01:07 Knoll Lars wrote:
> To implement Qt, we can and should use C++ in the most efficient way. If it
> makes sense to use certain features (and we can actually use them on all
> platforms), let's use them. But of course let's not force all of these upon
> our users.

Let me say again that our source code is product and it must be readable (to 
an extent) by our users. We should write efficient code, but not to a point 
that 
it's not understandable anymore by an advanced Qt application developer.

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

[Matthew Woehlke]

On 2015-12-04 03:01, André Somers wrote:
> On 2015-12-03 21:00, Thiago Macieira wrote:
>> 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.
>
> There are explicit methods for setting the tab order. Relying of the
> order of creation (which may be the default tab order - I did not check)
> is also pure luck, especially with designer-created UI's.

I would have to disagree with that (and agree with Marc). I'm quite
careful (or at least, I try to be) when using Designer to ensure that my
widgets are defined in the .ui file in tab order. I, like Marc, consider
it bad form to override the implicit tab order. (For one, it's a
maintenance headache.)

At any rate, any time I find that my tab order is wrong, I *always* fix
it by changing the order of the widgets in the .ui file.

(p.s. I believe that the order also controls the order in which widgets
are painted. Although this shouldn't matter 99.9% of the time, it does
if you have overlapping widgets.)

IMHO, QWidget::setTabOrder should be used exclusively when you need the
tab order to differ from the child order.

> I'd like to add a new alternative (though it does not exclude a change
> now either):
> 
> - Deprecate the behaviour and remove in Qt 6.
> 
> I have never thought this feature to lead to good design. It makes for
> "magic" in the sense that it is tricky to trace what happened. It leads
> to un-Qt-ish naming of methods, and it leads to naming methods based on
> when they are triggered instead of what they do.

+1.

-- 
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 Friday 04 December 2015 15:46:58 Bubke Marco wrote:
> Hmm,  do you really believe we cannot improve? If you compare signal and
> slots with resumable functions it looks quite complicated for many use
> cases. Look how complicated our network API is. It could be much easier
> with resumable functions. I don't say signal slots should go away but
> should be used in places their they have still an advantage. 

Our networking API is quite complex, but it could be worse. It could be like 
Boost.Asio and what's being proposed to the C++ standard networking API.

Let me put it this way: *I* do not understand it.

So yeah, we should use new things that make our lives and our users' lives 
easier, like we've done with variadic templates. We do not have to use things 
that make it worse.
-- 
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 4, 2015 16:39:14 Curtis Mitch  wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
>> Olivier Goffart
>> Sent: Friday, 4 December 2015 2:25 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
>> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
>> > > And as an aside, since it has been mentioned in this thread: in
>> > > Python _all_ variables are 'auto'. All. Without exception. Are
>> > > Python programmers more intelligent? Or do they just tolerate more
>> > > pain? :)
>> >
>> > i'd suggest the latter.
>> > no, really. people use external static checkers because the language
>> > lacks the feature.
>> > the lack of static typing is a common feature of scripting languages
>> > and makes them convenient to a degree, but it is an utter nightmare
>> > for any "real" software development. i really wouldn't want to go there.
>> 
>> But auto is still staticaly typed.
>> 
>> 
>> When you have code like
>> 
>>foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
>>
>> You don't see any type.
>> 
>> This code that use auto is not less readable. Even if you don't know
>> what's the type of bar without looking it up.
>> 
>>   auto *bar = foo->bar();
>>   bar->setFaz(m_factory->createFaz(bar->type()));
>> 
>
> Isn't this kind of a bad example, because there was no type declared/visible 
> in the first place?
>
> Anyway, if you're going to take the time to move the result of foo->bar() 
> onto its own line, why not just declare a type? What benefit does auto give 
> here?

We have a maximum length in the coding style.  So if you give your variables 
and functions descriptive names you cannot chain them so you needs variables 
inbetween. The type information is not that important in that case. Anyway we 
can provide the actual type for auto in creator. Like we will provide 
highlighting for output parameters. A good tool can provide all the 
informations so we don't need to overload the source code with that 
information. So we can make the intent of the code much more clear. 

> I really dislike hiding types behind a generic keyword.
>  
>> 
>> ___
>> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Qt5.6 Beta snapshot available

[Thiago Macieira]

On Friday 04 December 2015 10:42:39 Heikkinen Jani wrote:
> We have finally new qt5.6 beta snapshot available
> 
> 
> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/
> 
> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/
> 
> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/
> 
> Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/

Hi Jani

Repeating the request from Linux packagers: they cannot create packages unless 
we provide the split sources. The split sources are our official release 
channel, not the big tarball.

-- 
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] New Qt5.6 Beta snapshot available

[Helio Chissini de Castro]

Well, i'm not relying anymore on the released sources, i'm generating our
test tarballs from git, in the specific case, the 5.6 branch.

We complained already, and I decided that not worth wait to have our tasks
done.

If is too difficult to generate the official splitted tarballs, i can offer
as a community member to generate it and provide for Linux distros in the
not official basis.

Regards, Helio

On Fri, Dec 4, 2015, 17:55 Thiago Macieira 
wrote:

On Friday 04 December 2015 10:42:39 Heikkinen Jani wrote:
> We have finally new qt5.6 beta snapshot available
>
>
> Windows: http:// 
download.qt.io /
snapshots

/qt/5.6/5.6.0-beta/278/

>
> Linux: http:// 
download.qt.io /
snapshots

/qt/5.6/5.6.0-beta/287/

>
> Mac: http:// 
download.qt.io /
snapshots

/qt/5.6/5.6.0-beta/221/

>
> Src: http://

download.qt.io
/
snapshots

/qt/5.6/5.6.0-beta/
latest
_
src
/


Hi Jani

Repeating the request from Linux packagers: they cannot create packages
unless
we provide the split sources. The split sources are our official release
channel, not the big tarball.

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

[André Pönitz]

On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
> On 2015-12-04 15:35, André Pönitz wrote:
> > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> >> and it's one reason less to make errors:
> >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> >> QByteArray 
> >> is way to frequent. (and the compiler won't complain)
> > 
> > ["QString instead of QByteArray" does not happen with proper
> > QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> > replacement of explicit types by 'auto' doesn't produce identical results.]
> 
> But wrongly mixing integer types *does* happen. I speak from personal
> experience based on a code base that has a relatively large mess of
> *exactly* such errors.
> 
> > Code is typically read more often than changed. Targeting at making
> > specific refactorings easier is optimizing the wrong utility function.
> 
> Which of these is easier to read? (More importantly, which is easier to
> *verify* that it is correct?)
> 
>   for (int i = 0; i < list.size(); ++i)
> foo(list[i]);

Whether the access is correct depends on the type of list, which you don't
disclose.

In any case, this loop follows a well-known pattern.

>   for (auto i : qtIndexRange(list.size())
> foo(list[i]);


Whether the access is correct depends on the type of list, which you don't
disclose.

In any case, this is an uncommon pattern, using some unknown qtIndexRange()
function. Moreover it is more to type. The extra level of parantheses makes
it harder to parse for humans, introducing an aditional source of errors,
which you nicely demonstrated by making the example non-compilable.

> Which is *really* more meaningful?

The first one.

> "The type of 'i' is 'int', and I
> really, really hope that 'list' is actually indexed by 'int'", or "the
> type of 'i' is the index type of 'list'¹"?
> 
> Do you really *care* what is the type of 'i'?

Yes, I do care about types, almost always.

> Or do you care that it is
> the *correct* type. I (and others) submit that the latter is more valuable.

Your message has been heard. I do not agree with you.

I feel more comfortable arguing about whether a type is the right one
if the type is known than when it is unknown.

There *are* some sensible uses of 'auto', those are pretty much the ones
listed in Creator's coding-style.qdoc. Overuse of 'auto' reduces
code readability and maintainability, I would not like to see the Qt
code base move there.

Andre'
___
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-04 15:35, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
> 
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]

But wrongly mixing integer types *does* happen. I speak from personal
experience based on a code base that has a relatively large mess of
*exactly* such errors.

> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

Which of these is easier to read? (More importantly, which is easier to
*verify* that it is correct?)

  for (int i = 0; i < list.size(); ++i)
foo(list[i]);

  for (auto i : qtIndexRange(list.size())
foo(list[i]);

Which is *really* more meaningful? "The type of 'i' is 'int', and I
really, really hope that 'list' is actually indexed by 'int'", or "the
type of 'i' is the index type of 'list'¹"?

Do you really *care* what is the type of 'i'? Or do you care that it is
the *correct* type. I (and others) submit that the latter is more valuable.

(¹ ...assuming that decltype(list.size()) is the index type, which it
had darned well better be or whoever wrote the API of decltype(list)
needs to have their coding privileges revoked.)

-- 
Matthew

___
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-04 17:43, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> Which of these is easier to read? (More importantly, which is easier to
>> *verify* that it is correct?)
>>
>>   for (int i = 0; i < list.size(); ++i)
>> foo(list[i]);
> 
> Whether the access is correct depends on the type of list, which you don't
> disclose.

That's sort of *the point*. I can't tell if the above is correct or not.
If it used 'auto', I'd know.

(And it's sort of implied that it *is* wrong. Because, y'know, I see
loops like the above quite often where, indeed, they do in fact use the
wrong type. Actually, QList/QVector are about the *only* times the above
is written correctly without using 'auto'. More often than not, a loop
like that written against a non-Qt container uses the wrong index type.)

> In any case, this loop follows a well-known pattern.

It also follows a really *bad* pattern. The count is reevaluated every
time (well, you hope the compiler will hoist it, but the code says that
it is). Using type deduction... well, sucks:

  for (auto i = decltype(list.size()){0}; i < list.size(); ++i)

>>   for (auto i : qtIndexRange(list.size())
>> foo(list[i]);
> 
> In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> function.

Really?

  (Python)
  for i in range(len(list))

Just because it isn't standardized (or in Qt) yet doesn't mean it's
"unheard of". It's just that C++ users have been suffering with the
difficult to use form while programmers in other languages have had the
much more sensible form for a long time.

Really, it's not hard... nasty glorified while loop vs. 'I want to
iterate over the indices [starting at zero] up to list.size()'.

There's a reason I strongly prefer the latter form and use it whenever I
can (usually subject to compiler compatibility limitations).

> Moreover it is more to type.

Really?

  for (auto i : qtInlist.si))
 - vs. -
  for (int i = 0; i < list.si; ++i)

Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
*correct*. Yours... may or may not be... as you pointed out, I don't
know without knowing decltype(list). (Or I could use the much longer,
*much* uglier old-style for loop with decltype that is correct, but then
mine wins hands-down.)

> The extra level of parantheses makes it harder to parse for
> humans,introducing an aditional source of errors, which you nicely
> demonstrated by making the example non-compilable.

Bah. A decent IDE would have flagged that as soon as I stopped typing.
(Actually, a decent *text editor* would have shown me () matches, so I
would have noticed *as* I was typing. I challenge you to write bug-free
code the first time in a text editor whose most advanced feature is cut
and paste.)

>> Which is *really* more meaningful?
> 
> The first one.

Sorry, but I must strongly disagree.

>> "The type of 'i' is 'int', and I
>> really, really hope that 'list' is actually indexed by 'int'", or "the
>> type of 'i' is the index type of 'list'¹"?
>>
>> Do you really *care* what is the type of 'i'?
> 
> Yes, I do care about types, almost always.

Why? As long as it's the *correct* type, what difference did it make?

Let's say that the correct type is my_list::index_t. Let's say I used that:

  for (my_list::index_t i = 0; i < list.size(); ++i)

How is that better? Do you know now what is the actual type of 'i'?

I submit that writing 'my_list::index_t' is not a significant
improvement over 'auto'. It didn't tell you anything about the actual
type of 'i'. (It does suggest that the type of 'list' might be 'my_list'
and that a 'my_list' probably uses 'my_list::index_t' as its indexing
type. But there's still that "probably". Whereas 'auto' says the type
*is* the indexing type.)

> Your message has been heard. I do not agree with you.

Likewise.

> I feel more comfortable arguing about whether a type is the right one
> if the type is known than when it is unknown.

Then you are missing the point. In fact, you are missing the whole point
of 'auto'. By using 'auto' correctly, it's possible to know that the
type *is correct*, even if you don't know what the type actually *is*.
(Or if a change elsewhere should change what is the correct type.)

-- 
Matthew

___
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 19:06:51 Oswald Buddenhagen wrote:
> it's not that anyone is confused, it's that your "aside" was inherently
> flawed: variables in python are dynamically typed, so the suggestion
> that they are "auto" in any way related to c++ makes no sense
> whatsoever. my response aimed merely at showing that even your little
> "joke" was off.

Again: I was referring to the omission of any form of type name when declaring 
variables. That Python is _also_ dynamically typed is correct, but irrelevant. 
If you have a problem distinguishing these two orthogonal issues, s/Python/C#/

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

[André Pönitz]

On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> > > You don't see any type.
> > > 
> > > This code that use auto is not less readable. Even if you don't know
> > > what's the type of bar without looking it up.
> > > 
> > >   auto *bar = foo->bar();
> > >   bar->setFaz(m_factory->createFaz(bar->type()));
> > 
> > Isn't this kind of a bad example, because there was no type declared/visible
> > in the first place?
> 
> Precisely my point!   
> There is no type visible before and nobody complains.  So why should one 
> suddenly complains there are no types in the second snippet

Because they are different from a human reader's point of view.

In the second snippet the scope of the 'bar' is larger than for an immediate
use. This loses the context in which it is used, i.e. makes it harder to
reason about whether the use is ok, and adds load on a human reader that
needs to keep mental track of this 'untyped' item when reading the code until
it goes out of scope in case there's another use of this item.

Both alternatives help to reduce that load:

- immediate consumption of the temporary makes it explicit that the item is
  used exactly once and provides the consumer as additional context, helping
  judging whether the use is ok,

- using a separate line with a real type provides a stepping stone by
  giving additional information about the intermediate item *to the
  human reader*, helping him to split the task of verifying that
  'the right thing is produced and consumed' into smaller subtasks.

> > I really dislike hiding types behind a generic keyword.
> 
> Because the type is redundent

It might be redundant for the compiler, but it is not for human
readers of the code.

> and it's one reason less to make errors:
> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> QByteArray 
> is way to frequent. (and the compiler won't complain)

["QString instead of QByteArray" does not happen with proper
QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
replacement of explicit types by 'auto' doesn't produce identical results.]

> It is also refactoring-proof.  Because you might want to change the name of
> the type from "FazManager" to "FazHolder", and then you need to touch less
> code in your refactoring

Code is typically read more often than changed. Targeting at making
specific refactorings easier is optimizing the wrong utility function.

Andre'
___
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 4, 2015 21:33:57 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> > > You don't see any type.
>> > > 
>> > > This code that use auto is not less readable. Even if you don't know
>> > > what's the type of bar without looking it up.
>> > > 
>> > >   auto *bar = foo->bar();
>> > >   bar->setFaz(m_factory->createFaz(bar->type()));
>> > 
>> > Isn't this kind of a bad example, because there was no type 
>> > declared/visible
>> > in the first place?
>> 
>> Precisely my point!   
>> There is no type visible before and nobody complains.  So why should one 
>> suddenly complains there are no types in the second snippet
>
> Because they are different from a human reader's point of view.
>
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use. This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code until
> it goes out of scope in case there's another use of this item.
>
> Both alternatives help to reduce that load:
>
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
>   judging whether the use is ok,
>
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

For subtask you should write a new function with a descriptive name. Actually I 
don't buy they argument that explicit types improve readability so much as we 
allow long functions which do many subtasks. In python a never missed the types 
and python code in general is in my opinion much more readable. In my opinion 
is the culture and not so much the style guides. 

I think readable code is produced by programmers who care and not so much by 
style guides. It is easy to write unreadable code which complies to a style 
guide but much harder to write good readable code. And if I look at our code I 
must say I have seen much more readable code. So we have plenty space to 
improve. ;-)

I think we discuss the matter of types so much because we have not a good 
culture to give variables and functions descriptive names. And how to decompose 
larger functions in smaller thanks to describe the intention. It's not only Qt 
but C++ in general.

My argument for auto is quite simple that it is makes dependency  breaking 
easier which is very important for Test Driven Development. And if you have 
good tests you can refactore your code much easier because you know the 
probability to introduce new bugs by code changes is much lower. This 
refactorings leads to much better readable code. So my argument is that should 
be used if it leads to more readable code. Our style guide can only gives hints 
about it.  So developing rigid rules which stop the code to envolve in a more 
readable state is maybe not that smart.

In the end you have always trust in the developers that they cares about the 
readability of what they produce. 

So I would like to add the advise to use auto if it makes unit testing easier.

And with the clang code model we could add refactorings which change auto to 
the actual type too. But I  prefer to visulize it in a other way. We could 
provide some kind of overlay.

>> > I really dislike hiding types behind a generic keyword.
>> 
>> Because the type is redundent
>
> It might be redundant for the compiler, but it is not for human
> readers of the code.
>
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
>
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]
>
>> It is also refactoring-proof.  Because you might want to change the name of
>> the type from "FazManager" to "FazHolder", and then you need to touch less
>> code in your refactoring
>
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.
>
> Andre'
> ___
> 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] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 5, 2015 01:43:40 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
>> > 
>> > Whether the access is correct depends on the type of list, which you don't
>> > disclose.
>> 
>> That's sort of *the point*. I can't tell if the above is correct or not.
>> If it used 'auto', I'd know.
>
> You don't know whether operator[] or .at() is the best way to access
> by index until you know the type of list. Once you know the type of
> list, you also know what the type of i should be. There's no point
> in being fuzzy about it unless there is a *significant* advantage
> to it (like using 'auto' for iterator types which are mostly line
> noise).
>
>> (And it's sort of implied that it *is* wrong. Because, y'know, I see
>> loops like the above quite often where, indeed, they do in fact use the
>> wrong type. Actually, QList/QVector are about the *only* times the above
>> is written correctly without using 'auto'. More often than not, a loop
>> like that written against a non-Qt container uses the wrong index type.)
>
> The context of this discussion is the development of Qt. Thank you for
> confirming that 'int' is the right thing to use.
>
>> > In any case, this loop follows a well-known pattern.
>> 
>> It also follows a really *bad* pattern. The count is reevaluated every
>> time (well, you hope the compiler will hoist it, but the code says that
>> it is). Using type deduction... well, sucks:
>> 
>>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
> [
> If you care about size() re-evaluation:
>
> for (int i = 0, n = list.size(); i < n; ++i)
> ... 
> ]
>
>>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>
> Please stay on topic. The topic was whether to be more 'liberal' with
> the use of auto in Qt, written mostly in C++, not Python.
>  
>> > 
>> > The extra level of parantheses makes it harder to parse for
>> > humans,introducing an aditional source of errors, which you nicely
>> > demonstrated by making the example non-compilable.
>> 
>> Bah. A decent IDE would have flagged that as soon as I stopped typing.
>
> You are basically assuming that there's no need for you to write sane
> code to start with because during your development work you have a
> decent IDE to help you out. This assumption is wrong, independent
> of the existence of such an IDE.
>
> Since the discussion here is about what to use in Qt, the whole Qt
> development workflow matters. A lot of Qt code reading happens on Gerrit
> without IDE features at hand. The context there usually just a few lines.
> The appropriateness of an expression 'list[x]' is impossible to judge
> on Gerrit after applying an 'Almost always auto' policy.

Oswald and I spoke about using the clang code model to provide the information 
to gerrit too. It should be not that hard.

But you have to import the code in the IDE anyway because of the missing 
context.  For non trivial change review the calling context is far to important 
to be ignored. A html code browser could change that but we don't have one in 
gerrit. 

> This argument is not restricted to 'auto'. In general, code patterns
> that rely completely on IDE support are not beneficial for Qt
> development.
>
>> [...]
>> >> Which is *really* more meaningful?
>> > 
>> > The first one.
>> 
>> Sorry, but I must strongly disagree.
>
> So we agree to disagree. This was a call for comments. We've now 
> established the fact that there's no consensus on this matter.
>
>> In fact, you are missing the whole point of 'auto'.
>
> I don't think so.
>
>> By using 'auto' correctly, it's possible to know that the
>> type *is correct*, even if you don't know what the type actually *is*.
>
> You are missing the fact that Qt development is not an IDE-only workflow
> and does in general not operate on complete translation unit. You also
> do not seem to believe that at least some humans need a bit more explicit
> context than compilers to efficiently read code.
>
> Andre'
> ___
> 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] RFC: more liberal 'auto' rules?

[André Pönitz]

On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
> On 2015-12-04 17:43, André Pönitz wrote:
> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
> >> Which of these is easier to read? (More importantly, which is easier to
> >> *verify* that it is correct?)
> >>
> >>   for (int i = 0; i < list.size(); ++i)
> >> foo(list[i]);
> > 
> > Whether the access is correct depends on the type of list, which you don't
> > disclose.
> 
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.

You don't know whether operator[] or .at() is the best way to access
by index until you know the type of list. Once you know the type of
list, you also know what the type of i should be. There's no point
in being fuzzy about it unless there is a *significant* advantage
to it (like using 'auto' for iterator types which are mostly line
noise).

> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)

The context of this discussion is the development of Qt. Thank you for
confirming that 'int' is the right thing to use.

> > In any case, this loop follows a well-known pattern.
> 
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
> 
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)

[
If you care about size() re-evaluation:

for (int i = 0, n = list.size(); i < n; ++i)
... 
]

>   for (auto i : qtIndexRange(list.size())
> >> foo(list[i]);
> > 
> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> > function.
> 
> Really?
> 
>   (Python)

Please stay on topic. The topic was whether to be more 'liberal' with
the use of auto in Qt, written mostly in C++, not Python.
 
> > 
> > The extra level of parantheses makes it harder to parse for
> > humans,introducing an aditional source of errors, which you nicely
> > demonstrated by making the example non-compilable.
> 
> Bah. A decent IDE would have flagged that as soon as I stopped typing.

You are basically assuming that there's no need for you to write sane
code to start with because during your development work you have a
decent IDE to help you out. This assumption is wrong, independent
of the existence of such an IDE.

Since the discussion here is about what to use in Qt, the whole Qt
development workflow matters. A lot of Qt code reading happens on Gerrit
without IDE features at hand. The context there usually just a few lines.
The appropriateness of an expression 'list[x]' is impossible to judge
on Gerrit after applying an 'Almost always auto' policy.

This argument is not restricted to 'auto'. In general, code patterns
that rely completely on IDE support are not beneficial for Qt
development.

> [...]
> >> Which is *really* more meaningful?
> > 
> > The first one.
> 
> Sorry, but I must strongly disagree.

So we agree to disagree. This was a call for comments. We've now 
established the fact that there's no consensus on this matter.

> In fact, you are missing the whole point of 'auto'.

I don't think so.

> By using 'auto' correctly, it's possible to know that the
> type *is correct*, even if you don't know what the type actually *is*.

You are missing the fact that Qt development is not an IDE-only workflow
and does in general not operate on complete translation unit. You also
do not seem to believe that at least some humans need a bit more explicit
context than compilers to efficiently read code.

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

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

[Olivier Goffart]

On Friday 4. December 2015 21:35:16 André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> > > > You don't see any type.
> > > > 
> > > > This code that use auto is not less readable. Even if you don't know
> > > > what's the type of bar without looking it up.
> > > > 
> > > >   auto *bar = foo->bar();
> > > >   bar->setFaz(m_factory->createFaz(bar->type()));
> > > 
> > > Isn't this kind of a bad example, because there was no type
> > > declared/visible in the first place?
> > 
> > Precisely my point!
> > There is no type visible before and nobody complains.  So why should one
> > suddenly complains there are no types in the second snippet
> 
> Because they are different from a human reader's point of view.
> 
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use.

That's a good argument for the need of sensible variable name,  but not for 
mandating to write explicitly the type.

> This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code
> until it goes out of scope in case there's another use of this item.

If you were able to reason about   foo->bar()  in the first snippet without 
having the type explicitly written, why would the human reader need to see the 
type explicitly written in the second siuppet?

> Both alternatives help to reduce that load:
> 
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
> judging whether the use is ok,
> 
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

There might be cases where the type name is an important information and in 
that case we should put it of course.  But in many case it is not.
In the given example, 'bar' is only used locally.
What might be more interesting is a decent variable name. 
Yet, it is frequent to see non-descriptive names for such localy used 
variable. That's because this information is obvious and redundant.

> > > I really dislike hiding types behind a generic keyword.
> > 
> > Because the type is redundent
> 
> It might be redundant for the compiler, but it is not for human
> readers of the code.


Another example:

   fazCount++; // Increment the fazCount by one.
   name.remove(' '); // Remove all the spaces from the name.

Following your argument, the comments makes the code more readable? The human 
reader might not know what remove() does? Then such comments should be 
mandatory? In practice, someone familiar with the code base will know what 
Foo::bar() returns.

> > and it's one reason less to make errors:
> > Using 'int' instead of 'quint64' or 'size_t', or QString instead of
> > QByteArray is way to frequent. (and the compiler won't complain)
> 
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]

The point is: it is just another oportunity to make mistakes.

> > It is also refactoring-proof.  Because you might want to change the name
> > of the type from "FazManager" to "FazHolder", and then you need to touch
> > less code in your refactoring
> 
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

I'm claiming that auto often does not harm readability.
Given that, optimizing to make refactoring easier will allow the code base to 
evolve and to stay readable when things are changing



Just to be clear. I'm not advocating to use auto everywhere. I'm just saying 
that the coding style is currently too strict by forbiding auto in most cases.



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

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

[Bubke Marco]

I think the discussion is getting in an antagonistic direction and we should 
get back to our normal agonistic way or maybe being cooperative. ;-)

I have seen big systems in dynamically languages like small talk or python and 
except that they were slower they look actually much more readable. So I think 
history have shown that type declaration is not the key to readable code. In my 
opinion it is the excuse to find good names. ;-)

And what we should not forget is that tools getting better. So old rules can 
getting unproductive in a changing context. In my opinion we have to adapt to a 
changing context all the time and old wisdom can  loose it's usefulness fast.

So what about reviewing our style guides from time to time.  With tools like 
clang format and clang tidy it should be not that hard to adapt code to a 
changed style guide. 

On December 5, 2015 00:11:14 Matthew Woehlke  wrote:

> On 2015-12-04 17:43, André Pönitz wrote:
>> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>>> Which of these is easier to read? (More importantly, which is easier to
>>> *verify* that it is correct?)
>>>
>>>   for (int i = 0; i < list.size(); ++i)
>>> foo(list[i]);
>> 
>> Whether the access is correct depends on the type of list, which you don't
>> disclose.
>
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.
>
> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)
>
>> In any case, this loop follows a well-known pattern.
>
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
>
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
>>>   for (auto i : qtIndexRange(list.size())
>>> foo(list[i]);
>> 
>> In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> function.
>
> Really?
>
>   (Python)
>   for i in range(len(list))

for index,  value in enumerate(iteratable):
print(index,  value) 

would be much better because index accesses are quite slow. But it shows nicely 
why types can reduce readability. 

for (auto {index,  value} : enumerate(iteratable)) 

Is so far I understand the new syntax in C++. Actually I  want to use that 
because it makes code much more readable. 

Think about 

auto {value ,  isConvertable}  = variant.toDouble();

In that case auto would enforce the test much more and the code is very 
readable too. 

> Just because it isn't standardized (or in Qt) yet doesn't mean it's
> "unheard of". It's just that C++ users have been suffering with the
> difficult to use form while programmers in other languages have had the
> much more sensible form for a long time.
>
> Really, it's not hard... nasty glorified while loop vs. 'I want to
> iterate over the indices [starting at zero] up to list.size()'.
>
> There's a reason I strongly prefer the latter form and use it whenever I
> can (usually subject to compiler compatibility limitations).
>
>> Moreover it is more to type.
>
> Really?
>
>   for (auto i : qtInlist.si))
>  - vs. -
>   for (int i = 0; i < list.si; ++i)
>
> Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
> *correct*. Yours... may or may not be... as you pointed out, I don't
> know without knowing decltype(list). (Or I could use the much longer,
> *much* uglier old-style for loop with decltype that is correct, but then
> mine wins hands-down.)
>
>> The extra level of parantheses makes it harder to parse for
>> humans,introducing an aditional source of errors, which you nicely
>> demonstrated by making the example non-compilable.
>
> Bah. A decent IDE would have flagged that as soon as I stopped typing.
> (Actually, a decent *text editor* would have shown me () matches, so I
> would have noticed *as* I was typing. I challenge you to write bug-free
> code the first time in a text editor whose most advanced feature is cut
> and paste.)
>
>>> Which is *really* more meaningful?
>> 
>> The first one.
>
> Sorry, but I must strongly disagree.
>
>>> "The type of 'i' is 'int', and I
>>> really, really hope that 'list' is actually indexed by 'int'", or "the
>>> type of 'i' is the index type of 'list'¹"?
>>>
>>> Do you really *care* what is the type of 'i'?
>> 
>> Yes, I do care about types, almost always.
>
> Why? As long as it's the *correct* type, what difference did it make?
>
> Let's say that the correct type is my_list::index_t. Let's say I used that:
>
>   for (my_list::index_t i = 0; i < list.size(); ++i)
>
> How is that better? Do you know now what is the actual type of 'i'?

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

[Thiago Macieira]

On Saturday 05 December 2015 00:57:23 Bubke Marco wrote:
> Oswald and I spoke about using the clang code model to provide the
> information to gerrit too. It should be not that hard.

Please make sure those changes are making their way to Gerrit upstream.

Forking Gerrit is not a good idea.
-- 
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] Introducing qEnvironmentVariable

[Thiago Macieira]

I've just pushed a new function called qEnvironmentVariable. It's basically 
the equivalent of qgetenv returning a QString. Here's the rule of when to use 
it:

A) qEnvironmentVariable:
1) file paths
Always use this function when dealing with environment variables containing 
paths, in any OS.
Exception: when writing Unix-only code and you're going to pass that path to a 
non-Qt function taking 8-bit file paths (very rare)

2) Windows code
This function is more efficient than qgetenv on Windows because the environment 
on Windows is stored already as UTF-16. However, the gains may be quite small 
because the C runtime may be keeping both the UTF-16 and locale environments.

3) when you're about to convert to QString anyway
This function does that for you, so you save some keystrokes and parentheses 
in your code.

B) qgetenv:
1) when you're going to use as a QByteArray or it doesn't matter
It's ok to continue using qgetenv if you need a QByteArray anyway. Please note 
file paths should never be stored in QByteArrays on Windows.

2) Unix code
This function is more efficient than qEnvironmentVariable on Unix because the 
environment is stored in 8-bit. Note again the rules above for file paths.

3) converting from 8-bit *without* NFD/NFC conversion
On the extremely rare case, on OS X and iOS, that your environment variable 
must not undergo NFC/NFD conversion, use QString::fromUtf8(qgetenv(x))


As a corollary, in cross-platform code that is not dealing with file paths, you 
can choose either qgetenv or qEnvironmentVariable to suit your code best.

Note that if your variable contains numbers, you should use 
qEnvironmentVariableIntValue:

C) qEnvironmentVariableIntValue
Use if you just want the value. Use it directly if an unset variable is 
equivalent to it set to zero:
x = qEnvironmentVariableIntValue("FOO");

Do not write:
if (qEnvironmentVariableIsSet("FOO"))
x = qEnvironmentVariableIntValue("FOO");
write instead:
bool ok;
x = qEnvironmentVariableIntValue("FOO", );
it's equivalent to:
x = qgetenv("FOO").toInt();
but won't allocate memory in a QByteArray temporary.

D) qEnvironmentVariableIsSet, qEnvironmentVariableIsEmpty
Prefer !qEnvironmentVariableIsEmpty over the IsSet alternative. This allows 
"unsetting" a variable in a Unix shell by setting it to empty. Example:

$ QT_MESSAGE_PATTERN= ./appname

E) qputenv, qunsetenv
Don't use. They leak memory by construction. If you're dealing with the 
environment for a child process, set it with QProcessEnvironment instead.

-- 
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?

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 07:30:10PM +0100, Marc Mutz wrote:
> On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote:
> > > But auto is still staticaly typed.
> > > 
> > 
> > that's why using a scripting language as a source of arguments wasn't a
> > very wise move tactically, even as an aside. ;)
> 
> I, indeed, did not anticipate that anyone here would be able to seriously 
> confuse static typing and var/auto, the omitting of the type name in variable 
> declarations.
> 
it's not that anyone is confused, it's that your "aside" was inherently
flawed: variables in python are dynamically typed, so the suggestion
that they are "auto" in any way related to c++ makes no sense
whatsoever. my response aimed merely at showing that even your little
"joke" was off.

> I have the feeling I wasn't wrong, though.
> 
???
___
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 4, 2015 17:49:08 Thiago Macieira  wrote:

> On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
>> The clang code model completes auto so it should be not that hard.  Actually
>> I would call an ordered map or unordered map a dictionary. 
>
> Does Creator have a way to reveal the deduced type of an auto? That would go 
> a 
> long way to alleviating the pain of using it.

In the clang code model we use the clang AST. So if the compiler knows it, we 
can show it. It's on the roadmap for 3.7.

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

[Olivier Goffart]

On Friday 4. December 2015 15:39:01 Curtis Mitch wrote:
> > -Original Message-
> > From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> > Olivier Goffart
> > Sent: Friday, 4 December 2015 2:25 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] RFC: more liberal 'auto' rules?
> > 
> > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > > And as an aside, since it has been mentioned in this thread: in
> > > > Python _all_ variables are 'auto'. All. Without exception. Are
> > > > Python programmers more intelligent? Or do they just tolerate more
> > > > pain? :)
> > > 
> > > i'd suggest the latter.
> > > no, really. people use external static checkers because the language
> > > lacks the feature.
> > > the lack of static typing is a common feature of scripting languages
> > > and makes them convenient to a degree, but it is an utter nightmare
> > > for any "real" software development. i really wouldn't want to go there.
> > 
> > But auto is still staticaly typed.
> > 
> > 
> > When you have code like
> > 
> >foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> > 
> > You don't see any type.
> > 
> > This code that use auto is not less readable. Even if you don't know
> > what's the type of bar without looking it up.
> > 
> >   auto *bar = foo->bar();
> >   bar->setFaz(m_factory->createFaz(bar->type()));
> 
> Isn't this kind of a bad example, because there was no type declared/visible
> in the first place?

Precisely my point!   
There is no type visible before and nobody complains.  So why should one 
suddenly complains there are no types in the second snippet

> Anyway, if you're going to take the time to move the result of foo->bar()
> onto its own line, why not just declare a type? What benefit does auto give
> here?
> 
> I really dislike hiding types behind a generic keyword.

Because the type is redundent and it's one reason less to make errors:
Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray 
is way to frequent. (and the compiler won't complain)

It is also refactoring-proof.  Because you might want to change the name of 
the type from "FazManager" to "FazHolder", and then you need to touch less 
code in your refactoring. 

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

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

[Olivier Goffart]

On Friday 4. December 2015 13:12:00 Rafael Roquetto wrote:
> On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > > And as an aside, since it has been mentioned in this thread: in Python
> > > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > > programmers more intelligent? Or do they just tolerate more pain? :)
> > > 
> > > i'd suggest the latter.
> > > no, really. people use external static checkers because the language
> > > lacks the feature.
> > > the lack of static typing is a common feature of scripting languages and
> > > makes them convenient to a degree, but it is an utter nightmare for any
> > > "real" software development. i really wouldn't want to go there.
> > 
> > But auto is still staticaly typed.
> > 
> > 
> > When you have code like
> > 
> >foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> > 
> > You don't see any type.
> > 
> > This code that use auto is not less readable. Even if you don't know
> > what's
> > the type of bar without looking it up.
> > 
> >   auto *bar = foo->bar();
> >   bar->setFaz(m_factory->createFaz(bar->type()));
> 
> Until you need to change your code and call any method of bar. Suppose I
> need to change the following code, to print the first item of the
> collection:
> 
> auto *bar = foo->collection();
> 
> /*TODO: print first item here */
> 
> model->setCollection(bar); // we know bar is a collection, but of what
> kind?
> 
> 
> Choose the right alternative:
> 
> a) qDebug() << bar->first();
> b) qDebug() << bar->values().first();
> c) qDebug() << bar[0]
> d) none of the above
> 
> 
> To answer this, you will need to find out the return type of
> Foo::collection(); The compiler knows it, but the reader does not. And the
> answer depends on whether it is  a QList/QVector, QHash/QMap, etc... Had it
> been explicit, any programmer familiar with the Qt API (or any API in
> context) would be able to directly write down the right statement.

Ok, so i'll write it like this:

  AddresseeList *bar = foo->collection();

Is it better? do you know how to print the first element? You anyway need to 
look up what the AdresseeList typedef is. (Yes, it was made a typedef so one 
can more easily change what is the underlying, it's not so untypical)
You anyway have to know or lookup all the code you play around. 
Someone familiar with the codebase knows what Foo::collection() returns or can 
quickly look it up.
But the day somebody fixes the API and returns a  "const AddresseeList*" 
instead, you have to fix the locations you did not use auto.


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