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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

[Development] New Qt5.6 Beta snapshot available

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

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

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

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

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 ai

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

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

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

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:

[Development] Introducing qEnvironmentVariable

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

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

On December 4, 2015 18:11:39 Nicolás Ulrich wrote: > 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) > > [Screenshot 2015-12-04 13.55.13.png]

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

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 de

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

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

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

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 shoul

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

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

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

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:

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

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

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

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 alleviatin

Re: [Development] Proposal to change connectSlotsByName behavior

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

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

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 funct

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

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.

Re: [Development] Proposal to change connectSlotsByName behavior

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

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

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 lib

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

On December 4, 2015 16:10:56 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 menti

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

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.

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

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

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

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

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

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

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

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

[Development] Qt infra maintenance during weekend

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.

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

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

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

On Dec 4, 2015, at 7:53 AM, Mark De Wit mailto:mark.de...@iesve.com>> 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.

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

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 20

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

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

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

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 us

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

On Dec 3, 2015, at 8:31 AM, Shaw Andy mailto:andy.s...@theqtcompany.com>> 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

Re: [Development] Proposal to change connectSlotsByName behavior

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

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?

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

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

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

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

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

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

Re: [Development] QFutureInterface

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 K

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

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

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.

Re: [Development] QFutureInterface

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

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

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

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

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

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 n

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

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

Re: [Development] Proposal to change connectSlotsByName behavior

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

Re: [Development] Proposal to change connectSlotsByName behavior

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

Re: [Development] Proposal to change connectSlotsByName behavior

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

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

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

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 everyt

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

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

Re: [Development] QFutureInterface

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 pa

Re: [Development] Proposal to change connectSlotsByName behavior

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

Re: [Development] Proposal to change connectSlotsByName behavior

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