Re: [Development] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:
> Bubke Marco wrote:
> > So you optimized the container for growing with allocations. I don't think
> > it is the most common case. Having cache misses in traversing the
> > container can be much worse and is much harder to fix than a reserve.
> 
> Almost all my containers grow with allocations. How should I know in advance
> how much memory to reserve? It'd just waste an arbitrary amount of memory
> and then still end up reallocating because it'll inevitably be exceeded at
> some point. Variable-size containers are variable-size for a reason.
> 
> I consider reserve() to be a technical detail and a micro-optimization I
> really should not have to bother with in 99+% of the cases.

This is very wrong. In my experience with profiling applications, the most 
hotspots can be fixed by adding reserve to loops where the size is known or 
can be guessed. This has a tremendous effect on runtime speed, also for 
QVector using realloc (remember: not doing something will always be faster 
than something, even if it's fast).

If you have code that adds elements from time to time and you cannot estimate 
the size, then I claim the speed of these operations is irrelevant anyways. 

Also note how calling reserve with an estimated value ("this vector usually 
has about N elements") fits into the usual memory/speed trade off: You may 
waste memory (improve your estimate!), but it's also much faster.

Bye

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The 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] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 21/01/16 00:45, Andrew den Exter wrote:



On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly 
> wrote:




And there are the obvious runtime costs to building and
maintaining a cache that is of little or no use to most people
most of the time, which is I think a strong argument for it being
an off by default feature if implemented.



I think the cost would need to be measured before letting it
influence design decisions. We are not talking about monstrous
amounts of data.


Famous last words.  I have to assume any cache is going to be 
pre-populated with data from every role


Wow, that sounds bad indeed.

My idea is to cache when the data is first requested in a memoizing 
design. All of those requests go through the same classes in the QML 
implementation.




any binding with a conditional statement in it opens up the 
possibility that a role won't be accessed until after the row is removed


So you are thinking of QML code like this in a delegate:

 Text {
 text: someCondition ? model.someRole : model.otherRole
 }

Is that correct?

In that scenario, if someCondition is always true, then my memoization 
will cache the data for someRole, but not for otherRole.


Then, the row for that delegate gets removed and it gets animated away.

While it is animated away, someCondition becomes false, and the entire 
binding gets re-evaluated. Because the corresponding row is already 
gone, and because otherRole was never accessed while it was still there, 
the data for otherRole is not memoized, and we end up again with the a 
bug similar to what I posted on github with 'undefined' in the text field.


Thanks for pointing that out. It is a limitation of my proposal that 
conditionally accessed data can still cause artifacts.


So here's a summary of approaches possible for this class of bug:

* Cheap memoization
* Very expensive up-front cache population
* Somehow inspect bindings in delegates to find out what roles they 
could use

* Something else

For data which is conditionally accessed, the memoization does not fix 
everything, but up-front caching could.

For data which is not conditionally accessed, the memoization is enough.

We can try to decide what makes sense for QML to do.

Thanks,

Steve.

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

Re: [Development] What kind of airplane we want to build?

[André Somers]

Op 21/01/2016 om 10:02 schreef Marc Mutz:

I'm not saying we don't need new API should we replace QThread with
std::thead. I'm saying that all the hard, impressive, work is already done. It
seems to be mostly a question of API now.
Sorry, but I think API design _is_ the hard work. Not the part that 
is/should be the afterthought. And I think that that very thought has 
been the basis of the succes of Qt over the years.


André

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

Re: [Development] What kind of airplane we want to build?

[Marc Mutz]

On Thursday 21 January 2016 09:14:58 André Somers wrote:
> Op 21/01/2016 om 10:02 schreef Marc Mutz:
> > I'm not saying we don't need new API should we replace QThread with
> > std::thead. I'm saying that all the hard, impressive, work is already
> > done. It seems to be mostly a question of API now.
> 
> Sorry, but I think API design _is_ the hard work. Not the part that
> is/should be the afterthought. And I think that that very thought has
> been the basis of the succes of Qt over the years.

I disagree. For anything related to multithreading (and that's what we're 
talking about here), implementation is orders of magnitude harder than API.

-- 
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] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 07:59:18 Mathias Hasselmann wrote:
> Am 21.01.2016 um 08:00 schrieb Marc Mutz:
> > On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
> >> Marc Mutz wrote:
> >>> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
>  All these are horrible and error-prone hacks that have obvious
>  lifetime issues. You are complaining about Qt containers because the
>  detaching can invalidate iterators. Well, the lifetime issues you
>  introduce with the above proposed solutions are much worse! And a
>  caching mutable member also destroys thread-safety (in addition to
>  the obvious lifetime issue that the next call surprisingly
>  invalidates your existing reference).
> >>> 
> >>> One word: QModelIndex.
> 
> Sorry Marc, no. Really.
> 
> QModelIndex is entirely unrelated to the problem Eike raised.

I was replying to Kevin. QModelIndex exactly fits his complaints about const-&:

It's a reference used in interfaces. As soon as you store it, though, it may 
become stale at the next opportunity (like when calling a virtual function). 
You're supposed to store them in QPersistentModelIndex in that case. But QPMI 
is extremely expensive.

Compare that to:

 const std::vector & foos();

You can either assign the result to a const-& (=QModelIndex case), get max 
performance, but suffer from possible invalidation if you call out to unknown 
code. Or you store it in a copy, incurring the copy, but insulating yourself 
from changes to the original object (=QPersistentModelIndex case).

They really are two instances of the same class of problem: dangling 
references. And you cannot escape that problem. Not in C++, and not in other 
imperative languages, either. If you replaced QMI with an int, as you could, 
for QAbstractListModels, then you'd have exactly the same problems of 
invalidation (who updates your int if the row it points to gets removed?).

> I highly reward your expertise and what you are doing for Qt, and I
> really don't want my high opinion of you being spoiled. So please grab
> fine cup of tea, take a comfortable seat and spent some time on
> understanding, why this discussion took such dramatic shift away from
> its initial topic, why you are receiving such heat. Also please take
> some time to recall what other properties but performance are important
> when designing general purpose libraries.

If I have given the impression that it's just about speed, I'm sorry.

Speed is one argument, yes. If the Qt class had that much more (useful, to 
avoid counting indexOf() as a feature) features than the std counterpart, I 
would be the last to talk about replacing it. QString e.g. has superior 
Unicode handling. We can discuss how it should be laid out (CoW or not, say), 
but no-one challenges the very right of QString to exist.

But if a Qt class has only half the feature of its std counterpart and at the 
same time performs worse, then the question needs to be asked whether that 
class really needs to be in Qt.

So yes, I cannot shake the deeply-ingrained C++ principle of "don't pay for 
what you don't use". It's what keeps C++ relevant these days, despite its 
rough edges.

But speed is not the only reason:

I don't like Q_FOREACH not just because it performs badly, which it really 
doesn't, usually, for Qt types, but because it makes it hard to reason about 
the code (why is a copy taken? Is is needed?).

I don't like QThread being a QObject because it makes misusing the API all too 
easy.

I don't like QList because only experts can tell which guarantees it provides 
for any given type (can I keep references into the container across appends?). 
It's also the only container in the C++ world where iterator and reference 
validity are not synonyms: An append where capacity() == size() invalidates 
iterators in both QList modes, but only invalidates references in vector-with-
padding mode.

I don't like CoW because it creates long-range effects that are also the 
underlying reason we don't like global variables. It also makes any complexity 
specifications moot, because you never know whether you will incur that extra 
O(N) detach.

I don't like QSharedPointer because it does nothing better, and lot of things 
worse, than shared_ptr and was only added (long after boost::shared_ptr and 
tr1::shared_ptr came into existence) because of an overly strict sense of BC 
that extends beyond the Qt libraries (aka "we can't use boost/std in our 
APIs").

As for why I am receiving such heat: I don't. It's the same couple of persons 
every time that troll around. I should get better at not feeding them, sure.

The people that matter in Qt development, however, take this constructively, 
even when they disagree about the whens and hows. I take the extreme pov in 
these discussions, because someone has to. The wider C++ community ignores Qt, 
and I feel that's to the detriment of both. Some try to fork the project. I 
prefer to work within it, as someone who was 

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote:
> Marc Mutz wrote:
> > You can lock a mutex in the function and unlock it in the shared_ptr's
> > deleter.
> 
> How can that possibly be faster than atomic reference counting? You have
> the same cross-thread dependence plus a potential wait for the thread to
> actually do its work. Not to mention that mutexes can cause deadlocks,
> atomic reference counts can't.

Ivan was talking about thread-safe classes. You need to lock a mutex to take 
the copy.

-- 
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] Heads up for Qt Bug Report & Code Review users

[Jokiniva Jukka]

Maintenance break is over and systems are back online. Use your unified Qt 
Account credentials to login from now on.

If you find bugs, please report them here: 
https://bugreports.qt.io/browse/QTJIRA

-Jukka


From: Jokiniva Jukka 
>
Date: Monday 21 December 2015 10:48
To: "development@qt-project.org" 
>
Subject: Heads up for Qt Bug Report & Code Review users


Hi,

Some months ago we asked all Qt users to provide us input on ideas to further 
improve the Qt developer experience. You spoke. We listened. It was 
overwhelmingly clear that single sign-on for all Qt Services was at the top of 
desired features and functionality. Since then, we have been working toward 
providing this to you. As part of this effort, you will now have common 
credentials for all of the following Qt services:


· Qt Account web portal for license management, 
downloads and commercial support

· Qt Forum

· Qt Wiki

· Qt Bug Tracker (NEW)

· Qt Code Review (NEW)

Note: There will be a maintenance break on Tuesday 12 January 2016 from 
07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker 
(https://bugreports.qt.io) and Qt Code Review 
(https://codereview.qt-project.org).

IMPORTANT
The email address that you currently use to log into Bug Tracker and Code 
Review will be associated with Qt account credentials.


· If you don't already have Qt credentials, all you need to do is 
register at https://login.qt.io/register* using the same email address you 
currently use for Bug Tracker and Code Review. If you want to change to a 
different email address for your unified login credentials, you should first 
update the email address in Bug Tracker** to ensure the logins will be merged.

· If you already have Qt account credentials, but use different email 
addresses for each account, you should ensure that your Bug Tracker email 
address is the same as in your Qt account 
profile so that all your account credentials 
will be merged.

* Please be sure to complete the email verification process, which will be 
explained to you in the email sent upon registering.
** To edit your Bug Reports email address, go to 
https://bugreports.qt.io/secure/ViewProfile.jspa profile settings and select 
the pen icon.

We hope you will enjoy this improvement. We will also continue to work toward 
adding more of features and functionality that you all asked for.

Best regards,
The Qt Company

www.qt.io
 |Qt Blog: 
http://blog.qt.io/
 | Twitter: @Qtproject  | Facebook: 
www.facebook.com/qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 05:49:55 Kevin Kofler wrote:
> Marc Mutz wrote:
> > best of three runs, core i7-2720QM, GCC 5.3
> 
> What OS and C library are you running those benchmarks on? The performance
> of realloc is vastly different between operating systems, so this is
> important information.

Debian Wheezy.

kernel: 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u1 x86_64 GNU/Linux
libc6: 2.13-38+deb7u8

-- 
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] What kind of airplane we want to build?

[Bubke Marco]

On January 21, 2016 1:28:58 AM Marc Mutz  wrote:

> On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote:
>> On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote:
>> > Replacing QThread with std::thread? Please don't.
>> 
>> Unlike the containers or even futures/promises vs QtConcurrent, we can
>> easily  argue that QThread provides a lot more functionality than
>> std::thread. In just one word: signals.
>
> What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're 
> supposed to use the signals of QObjects living in that thread, not the 
> QThread 
> itself.
>
> And that's perfectly possible with std::thread, too:
>
>  auto po = new ProcessingObject();
>  connect(po, ...);
>  po->moveToThread(nullptr); // enable "pulling" moveToThread()
>  auto t = std::thread([po, gui = QThread::currentThread()]() {
>  QEventLoop loop;
>  po->moveToThread(QThread::currentThread());
>  connect(po, ..., , ::quit);
>  loop.exec();
>  po->moveToThread(gui);
>  // or: delete po;
>  }
>
> Am I missing something?

The question is if you really want an event loop here. Mostly I want a command 
queue where I can prioritize and merge the commands. I want to poll for cancel 
commands  without much overhead and it should support move only types.

I really think we should step back and look at the broader picture before we 
apply our tools. 

>> We should provide QThread::makeThread() taking a lambda and some other 
>> niceties, 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

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[André Somers]

Op 21/01/2016 om 11:17 schreef Marc Mutz:

On Thursday 21 January 2016 09:14:58 André Somers wrote:

Op 21/01/2016 om 10:02 schreef Marc Mutz:

I'm not saying we don't need new API should we replace QThread with
std::thead. I'm saying that all the hard, impressive, work is already
done. It seems to be mostly a question of API now.

Sorry, but I think API design _is_ the hard work. Not the part that
is/should be the afterthought. And I think that that very thought has
been the basis of the succes of Qt over the years.

I disagree. For anything related to multithreading (and that's what we're
talking about here), implementation is orders of magnitude harder than API.

I beg to differ. QThread being a good example. So many people got it 
wrong when using it, it is obvious the API is just not right. The thing 
worked ok, but it turns out it hard to use it right. You may call the 
implementation orders of magitudes harder, but it was the API that was 
screwed up, not so much the implementation.


André

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

Re: [Development] Binding evaluation during ListView delegate remove animation

[Giuseppe D'Angelo]

On Thu, Jan 21, 2016 at 4:43 PM, André Somers  wrote:
> I was wondering: how do you know when to drop the cached data again?

When the corresponding delegate gets evicted by ListView at the end of
the removal animation.

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

Re: [Development] Binding evaluation during ListView delegate remove animation

[André Somers]

Op 21/01/2016 om 16:13 schreef Stephen Kelly:


On 21/01/16 14:56, Stephen Kelly wrote:


* Something else


As Andre wrote, 'something else' could be 'populate a "memory 
structure" for all roles for the specific rows being removed in 
response to rowsAboutToBeRemoved'.


I would not use all roles, or at least make it tweakable in some way. 
Some models may have a huge number of roles, or roles that are quite 
expensive to get and are simply not needed for the delegate. So if you 
insist in having this "on" by default, perhaps a property you can set 
can have a default signifying "all roles" while you can also set it to a 
set of specific roles (or simply no roles at all).


I was wondering: how do you know when to drop the cached data again?

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

Re: [Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 21/01/16 14:56, Stephen Kelly wrote:


* Something else


As Andre wrote, 'something else' could be 'populate a "memory structure" 
for all roles for the specific rows being removed in response to 
rowsAboutToBeRemoved'.


--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bo Thorsen]

Den 21-01-2016 kl. 14:15 skrev Milian Wolff:

On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:

I consider reserve() to be a technical detail and a micro-optimization I
really should not have to bother with in 99+% of the cases.


That's how it should be.


This is very wrong. In my experience with profiling applications, the most
hotspots can be fixed by adding reserve to loops where the size is known or
can be guessed. This has a tremendous effect on runtime speed, also for
QVector using realloc


And this is how it is.

Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 21/01/16 08:12, André Somers wrote:


Actually, I think it would not need to be quite as bad.
For starters, you really only need to cache the actual items being 
removed. At the moment the model emits the AboutToBeRemoved signal, 
the data should still be there in any well-behaved model, right? 
_That_ is the moment you do your caching.




Even 'reasonable' qaim implementations might not still be able to give 
you data in a handler of rowsAboutToBeRemoved. Consider for example a 
qaim which models a filesystem. If the data() method is written to look 
at the filesystem, and QFSWatcher is used as a trigger to signal removal 
of rows, then by the time the rowsAboutToBeRemoved signal is emitted, 
the file is already gone from the filesystem.


QFileSystemModel solves that with an internal cache of QFileInfo 
instances, but you can imagine reasonable models which don't have an 
internal cache like that.


However, requiring models to have such a cache for exactly that reason 
could be reasonable. It is already kind of an implicit requirement of 
the use case you mention. It would become a more-explicit requirement if 
QML relied on it like that.


While it is possible that because of conditionals in the binding roles 
are accessed only during the removing, it does not sound very likely. 
One could provide an API to specifically add roles to the caching 
manually, but otherwise only cache roles that have been accessed 
already. Or just only set the roles manually and use that as the 
on/off switch for the whole feature that Andrew requested. 
Realistically, for most models, this would be something like perhaps 
an image and a couple of strings for an item. And these would only 
need to live for a short time, because once the remove animation is 
done, the data can be removed again.


I think it is certainly worthwhile to investigate.


That's good.

I think we should really try to make sure there is no API needed to 
enable working behavior. 'Working' should be the default.


Thanks,

Steve.

--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] Qt 5.6.0 header diff

[Frederik Gladhorn]

Hello,

this is an update, the final header diff.
Since we all agree that email is not the perfect medium for the header review 
(I see some open questions in the old thread), I'd thought I'll go for an 
attempt at pushing the diffs to gerrit. I'm not quite satisfied with the 
outcome, ideas for improvement are welcome (as long as they don't mean lots of 
work for me ;))

Here is a change containing all the different diffs:
https://codereview.qt-project.org/#/c/146876/

Cheers,
Frederik


On Thursday, September 17, 2015 12:29:27 PM Frederik Gladhorn wrote:
> Hi all,
> 
> we are getting close to the Qt 5.6 beta and it's time for the header diff.
> 
> >From this point on we should be very careful in adding/changing newly
> 
> introduced API.
> 
> I'll send the actual header diffs as attachments in follow-up mails, it will
> probably take a few hours until they actually get sent.
> As an addition to the previous process, we'll have new headers in existing
> modules included, so that we don't accidentally ship new classes that
> somehow slipped through the cracks earlier.
> 
> For entirely new modules, I don't think that this will work though, so let's
> start one thread for each module that will be added to Qt 5.6 (even for
> tech previews) so that everyone interested in the module is aware of it and
> can chime in to the discussion. For the new modules, use https://code.qt.io
> or git to do the review.
> 
> For Enginio, I just checked manually - there is no change in any headers in
> the 1.2.1 branch vs 5.6.
> 
> Cheers,
> Frederik
> 
> qtsdk/packaging-tools/header-diff.pl origin/5.5.1..origin/5.6
> 
> Found module Qt3DCollision in ./qt3d/src/collision/collision.pro
>  - Module has 7 public headers now
>  - No changes!
> Found module Qt3DCore in ./qt3d/src/core/core.pro
>  - Module has 45 public headers now
>  - Qt3DCore.diff created
>  - New header: src/core/nodes/qabstractnodefactory.h
> Found module Qt3DInput in ./qt3d/src/input/input.pro
>  - Module has 9 public headers now
>  - No changes!
> Found module Qt3DLogic in ./qt3d/src/logic/logic.pro
>  - Module has 3 public headers now
>  - No changes!
> Found module Qt3DRenderer in ./qt3d/src/render/render.pro
>  - Module has 88 public headers now
>  - Qt3DRenderer.diff created
>  - New header: src/render/frontend/qcylindergeometry.h
> Found module QtAndroidExtras in
> ./qtandroidextras/src/androidextras/androidextras.pro
>  - No public headers for module QtAndroidExtras
> Found module QtConcurrent in ./qtbase/src/concurrent/concurrent.pro
>  - Module has 15 public headers now
>  - No changes!
> Found module QtCore in ./qtbase/src/corelib/corelib.pro
>  - Module has 193 public headers now
>  - QtCore.diff created
>  - New header: src/corelib/tools/qhashfunctions.h
>  - New header: src/corelib/tools/qversionnumber.h
> Found module QtDBus in ./qtbase/src/dbus/dbus.pro
>  - Module has 19 public headers now
>  - QtDBus.diff created
> Found module QtGui in ./qtbase/src/gui/gui.pro
>  - Module has 130 public headers now
>  - QtGui.diff created
>  - New header: src/gui/opengl/qopenglextrafunctions.h
>  - New header: src/gui/painting/qrgba64.h
> Found module QtNetwork in ./qtbase/src/network/network.pro
>  - Module has 34 public headers now
>  - QtNetwork.diff created
> Found module QtOpenGL in ./qtbase/src/opengl/opengl.pro
>  - Module has 8 public headers now
>  - QtOpenGL.diff created
> Found module QtOpenGLExtensions in
> ./qtbase/src/openglextensions/openglextensions.pro
>  - Module has 1 public headers now
>  - No changes!
> Found module QtPlatformSupport in
> ./qtbase/src/platformsupport/platformsupport.pro
>  - Module has 4 public headers now
>  - No changes!
> Found module QtPrintSupport in ./qtbase/src/printsupport/printsupport.pro
>  - Module has 9 public headers now
>  - QtPrintSupport.diff created
> Found module QtSql in ./qtbase/src/sql/sql.pro
>  - Module has 14 public headers now
>  - QtSql.diff created
> Found module QtTest in ./qtbase/src/testlib/testlib.pro
>  - Module has 18 public headers now
>  - QtTest.diff created
> Found module QtWidgets in ./qtbase/src/widgets/widgets.pro
>  - Module has 135 public headers now
>  - QtWidgets.diff created
>  - New header: src/widgets/accessible/complexwidgets.h
>  - New header: src/widgets/accessible/itemviews.h
>  - New header: src/widgets/accessible/qaccessiblemenu.h
>  - New header: src/widgets/accessible/qaccessiblewidgets.h
>  - New header: src/widgets/accessible/rangecontrols.h
>  - New header: src/widgets/accessible/simplewidgets.h
> Found module qtmain in ./qtbase/src/winmain/winmain.pro
>  - No public headers for module qtmain
> Found module QtXml in ./qtbase/src/xml/xml.pro
>  - Module has 3 public headers now
>  - QtXml.diff created
> Found module QtBluetooth in ./qtconnectivity/src/bluetooth/bluetooth.pro
>  - Module has 19 public headers now
>  - QtBluetooth.diff created
> Found module QtNfc in ./qtconnectivity/src/nfc/nfc.pro
>  - Module has 12 public headers now
>  - No changes!
> Found 

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 21, 2016 3:51:09 PM Bo Thorsen  wrote:

> Den 21-01-2016 kl. 14:15 skrev Milian Wolff:
>> On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:
>>> I consider reserve() to be a technical detail and a micro-optimization I
>>> really should not have to bother with in 99+% of the cases.
>
> That's how it should be.
>
>> This is very wrong. In my experience with profiling applications, the most
>> hotspots can be fixed by adding reserve to loops where the size is known or
>> can be guessed. This has a tremendous effect on runtime speed, also for
>> QVector using realloc
>
> And this is how it is.
>

make my_work_as_I_am_going_home

I tried it in camel case but that was not working. :-p

> Bo Thorsen,
> Director, Viking Software.
>
> -- 
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Matthew Woehlke]

On 2016-01-20 23:27, Kevin Kofler wrote:
> Thiago Macieira wrote:
>> The copy constructor is called once, then the move constructor. If
>> value_type's move constructor is not noexcept, then it may throw after the
>> container resized.
> 
> Throwing an exception in a move constructor is really, really horrible. I 
> can see why a copy constructor would throw (out of memory, failure to 
> duplicate some other resource), but a move?

Sure... and for the same reason you gave; out of memory. Some classes
have an invariant that involves owning some allocated memory. Thus, even
the move ctor must allocate memory (which is then exchanged with the
instance being moved from) in order to maintain invariants. (This is, of
course, why we need destructive move; we can eliminate the need to
allocate when the moved-from object is also destroyed, because we can
just *take* its memory in that case and not worry about the class
invariants.)

-- 
Matthew

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Matthew Woehlke]

On 2016-01-20 17:43, Giuseppe D'Angelo wrote:
> This poses further questions down the line, such as whether it's "ok"
> having an index API based on signed integers. (It is for convenience, it
> is not for correctness, but I guess that's all the topic here, isn't it?
> :))

As Thiago noted, C++ itself is moving *away* from size_t, even to using
int in some cases.

It's true, it would be nice if Qt (especially e.g. QByteArray) used
ssize_t instead of int, but there are various strong reasons for using a
signed integer rather than unsigned. (It makes 'did you find the index'
checks much less obnoxious, it allows tail-based indexing, ...)

> Qt containers are unsound for general-purpose storage.

...only if you use exceptions. Personally, I'm glad Qt *doesn't*.

-- 
Matthew

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Matthew Woehlke]

On 2016-01-20 23:44, Kevin Kofler wrote:
> Almost all my containers grow with allocations. How should I know in advance 
> how much memory to reserve? It'd just waste an arbitrary amount of memory 
> and then still end up reallocating because it'll inevitably be exceeded at 
> some point. Variable-size containers are variable-size for a reason.
> 
> I consider reserve() to be a technical detail and a micro-optimization I 
> really should not have to bother with in 99+% of the cases.

99% is almost certainly an exaggeration.

There are three categories of containers:
- size is constant and known at compile time
- size is constant and known at run time
- size is variable (e.g. based on user actions)

There are quite a few instances of the second category. For example, in
reading a PLY file, the number of points and faces is (usually) known as
soon as the header is read. Obviously, these depend on what file is
being read, so the size is not a *compile* time constant, but it is
known prior to filling the container, and is for the most part constant.
Cases like these (or filling one container based on the contents of
another) are where reserve() is extremely helpful, and most certainly
more than "a technical detail and micro-optimization".

That's not to say that there aren't *also* instances of the third.

(And, yes, pedantically, in reality it is more like a continuum than
three distinct categories.)

-- 
Matthew

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

[Development] QFont::setFamily("monospace") on OS X

[René J . V . Bertin]

Hello,

Not sure if this is the best place to ask:
I think QFont::setFamily("monospace") should allow to obtain an appropriate 
monospace font on all platforms. It does with the XCB QPA , giving me the 
Consolas font (ideally it should return the fixed-width font that goes with the 
active (platform) style, though).
On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the system 
fallback font.

I suppose that's a bug, or is there a reason why this doesn't work as expected?

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

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> > On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> >> Thiago Macieira wrote:
> >>> The copy constructor is called once, then the move constructor. If
> >>> value_type's move constructor is not noexcept, then it may throw after
> >>> the
> >>> container resized.
> >> 
> >> Throwing an exception in a move constructor is really, really horrible. I
> >> can see why a copy constructor would throw (out of memory, failure to
> >> duplicate some other resource), but a move?
> > 
> > Indeed.
> > 
> > But the class in question may not have a move constructor. In the absence
> > of one, the copy constructor gets called.
> 
> I generally don't care. If I can't copy anymore due to running out of
> memory, I'm pretty much done anyway. No reliable way to recover from
> that. Might as well terminate the program.

Right, _you_ don't care. But as a library one cannot usually make such claims. 
People may want to use it in conditions where they _do_ care, and for good 
reason. It would be a shame if C++ would not be applicable for such scenarios 
just because some people didn't care enough.

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The 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] Binding evaluation during ListView delegate remove animation

[André Somers]

Op 21/01/2016 om 16:55 schreef Giuseppe D'Angelo:

On Thu, Jan 21, 2016 at 4:43 PM, André Somers  wrote:

I was wondering: how do you know when to drop the cached data again?

When the corresponding delegate gets evicted by ListView at the end of
the removal animation.

Of course. Good point.

André

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

Re: [Development] What kind of airplane we want to build?

[Thiago Macieira]

On Thursday 21 January 2016 10:02:41 Marc Mutz wrote:
> Having had to teach this stuff to customers when this came out in Qt 4, I
> can  tell you this distinction will not register with most Qt-newbies.
> Allowing such ease of wrong API use is against my reading Qt's own design
> principles ("make it hard to use an API incorrectly"). That QThread is a
> QObject is a bug, not a featuee. It would be better as a non-QObject,
> adding QThreadWatcher a la QFutureWatcher to enable singals. In that case,
> QThread can be replaced with std::thread without much loss of generality.

It wouldn't be QThread *Watcher* because it needs slots too, like quit() and 
terminate(). It would be more like QThreadManager. At that point, it's QThread 
again.

I agree with you that we should make it harder for people to misuse. With the 
advent of lambdas, we can easily add a QThread::makeThread(lambda) and 
deprecate completely the overriding of virtual run(). That in turn discourages 
adding signals and slots.

> How we'd represent a thread if QThread was dropped is a different question,
> but easily resolved once we get there (QThreadHandle, or even re-using
> QThread, but not as a QObject subclass).

I don't see the point. We already have a threadId(). If we want to return a 
handle, I would call for it to be std::thread. That would imply replacing our 
backends with std::thread.

Maybe in 2020.

-- 
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] QFont::setFamily("monospace") on OS X

[René J . V . Bertin]

On Thursday January 21 2016 20:31:52 Liang Qi wrote:

Possibly, but that function takes a font type, not a family name. So it's 
probably the culprit only if it is called with the FixedFont type after someone 
did setFamily("monospace").

R.

> Perhaps QPlatformTheme::font() is related.
> 
> https://github.com/qtproject/qtbase/blob/5.6/src/gui/kernel/qplatformtheme.h
> 
> Regards,
> Liang
> 
> On 21 January 2016 at 18:29, René J.V.  wrote:
> 
> > Hello,
> >
> > Not sure if this is the best place to ask:
> > I think QFont::setFamily("monospace") should allow to obtain an
> > appropriate monospace font on all platforms. It does with the XCB QPA ,
> > giving me the Consolas font (ideally it should return the fixed-width font
> > that goes with the active (platform) style, though).
> > On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the
> > system fallback font.
> >
> > I suppose that's a bug, or is there a reason why this doesn't work as
> > expected?
> >
> > Cf: https://bugreports.qt.io/browse/QTBUG-50564
> >
> > R.
> > ___
> > 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] Heads up for Qt Bug Report & Code Review users

[Thiago Macieira]

On Thursday 21 January 2016 10:27:06 Jokiniva Jukka wrote:
> Maintenance break is over and systems are back online. Use your unified Qt
> Account credentials to login from now on.
> 
> If you find bugs, please report them here:
> https://bugreports.qt.io/browse/QTJIRA

Looks like I will soon[*] have a problem: I use two different accounts for my 
Qt services. I need to use the account associated with my Intel mail address 
for Code Review, as that's the one associated with the Corporate CLA.

But Intel's mail servers are bad (read: Exchange), so I use my personal 
account on JIRA. All the bug reports I'm associated with and the components 
I'm the default assignee for are with this account. I don't want to change it.

So how do I keep receiving bug report email to my personal inbox while logged 
in to Gerrit with the Intel account?

[*] soon because Gerrit hasn't logged me out yet.
-- 
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] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> I was replying to Kevin. QModelIndex exactly fits his complaints about
> const-&:
> 
> It's a reference used in interfaces. As soon as you store it, though, it
> may become stale at the next opportunity (like when calling a virtual
> function). You're supposed to store them in QPersistentModelIndex in that
> case. But QPMI is extremely expensive.
> 
> Compare that to:
> 
>  const std::vector & foos();
> 
> You can either assign the result to a const-& (=QModelIndex case), get max
> performance, but suffer from possible invalidation if you call out to
> unknown code. Or you store it in a copy, incurring the copy, but
> insulating yourself from changes to the original object
> (=QPersistentModelIndex case).
> 
> They really are two instances of the same class of problem: dangling
> references. And you cannot escape that problem. Not in C++, and not in
> other imperative languages, either. If you replaced QMI with an int, as
> you could, for QAbstractListModels, then you'd have exactly the same
> problems of invalidation (who updates your int if the row it points to
> gets removed?).

And my point is that in most cases, CoW avoids exactly that problem, 
allowing you to safely (and even thread-safely!) return newly-created data 
(i.e. NOT return a dangling reference), without having to deep-copy it. 
Model indexes are a different matter.

> I don't like QList because only experts can tell which guarantees it
> provides for any given type (can I keep references into the container
> across appends?).

Simply assume that you can't.

> It's also the only container in the C++ world where iterator and reference
> validity are not synonyms: An append where capacity() == size()
> invalidates iterators in both QList modes, but only invalidates references
> in vector-with- padding mode.

Again: Consider references always invalidated. The fact that they sometimes 
happen to keep working is an implementation detail that must not be relied 
on. Would you want QList to go out of its way to invalidate references 
somehow (if, due to a performance optimization, the data did not actually 
move)? That would go against the very performance principles you are 
fighting for.

Part of the concept of undefined behavior is that it may also appear to just 
work (and then it may also start breaking at any time). There is no 
guarantee that invoking undefined behavior will crash and burn, that would 
defeat the purpose of undefined behavior. So just consider working with 
dangling references to QList members after modifying the list to be 
undefined behavior.

If you are keeping a reference to an element of QList or QVector across an 
insert / append / prepend / remove, you are doing something wrong! Those 
references are really only intended to be used in lines such as:
myList[i] = foo;
or at most in the equivalent of a "with" block in some higher-level 
languages, i.e., e.g.:
{
  Foo  = myList[i];
  element.foo = foo;
  element.bar = bar;
}
(You can leave off the scope braces if you want, but my point is that at 
that point you should be done using element, so you may as well let it go 
out of scope.)
Everything else is a blatant API abuse.

> I don't like CoW because it creates long-range effects that are also the
> underlying reason we don't like global variables. It also makes any
> complexity specifications moot, because you never know whether you will
> incur that extra O(N) detach.

In many practical cases, the alternative is to ALWAYS deep-copy (plain 
assignment in STL, explicit clone() in Java or Python), so CoW will actually 
SAVE you many of those O(n) deep-copy operations.

> I don't like QSharedPointer because it does nothing better, and lot of
> things worse, than shared_ptr and was only added (long after
> boost::shared_ptr and tr1::shared_ptr came into existence) because of an
> overly strict sense of BC that extends beyond the Qt libraries (aka "we
> can't use boost/std in our APIs").

I consider QSharedPointer good enough, and I really think a complete Qt 
class library should remain a goal. In particular, I also think QtAlgorithms 
should be undeprecated and extended with new algorithms. The goal should be 
that the average Qt-using developer should never have to use any STL class, 
and the Qt ones should have a friendlier API. This was already the case in 
QtAlgorithms compared to the STL algorithms, e.g., qSort had a convenient 
qSort(container) overload whereas std::sort requires you to write the ugly 
and redundant std::sort(container.begin(), container.end(), qLess());. So 
switching to STL algorithms was a huge step backwards in API quality.

The std::sort API is also symptomatic of the main design issue of the STL: 
The STL API is always optimized for the complex corner case (such as wanting 
to sort only an arbitrary subset of a container), neglecting the convenience 
overloads for the common case that will matter in >99% of the cases (sorting 
the whole container). (Having to pass 

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> But the discussions about move ctors that throw aren't even about
> bad_alloc. They are about assertion exceptions.

How is a move constructor an appropriate place for a sanity check? The only 
way the moved object can be invalid is if the original object was already 
invalid. So the sanity check should have been in an appropriate place to 
prevent the original object from becoming invalid in the first place. Any 
properly implemented move satisfies the invariant that the moved object 
satisfies resp. violates exactly the same invariants than the original one.

Kevin Kofler

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Andre Somers]

On 21-1-2016 21:09, Milian Wolff wrote:

On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:

Op 21/01/2016 om 05:35 schreef Thiago Macieira:

On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:

Thiago Macieira wrote:

The copy constructor is called once, then the move constructor. If
value_type's move constructor is not noexcept, then it may throw after
the
container resized.

Throwing an exception in a move constructor is really, really horrible. I
can see why a copy constructor would throw (out of memory, failure to
duplicate some other resource), but a move?

Indeed.

But the class in question may not have a move constructor. In the absence
of one, the copy constructor gets called.

I generally don't care. If I can't copy anymore due to running out of
memory, I'm pretty much done anyway. No reliable way to recover from
that. Might as well terminate the program.

Right, _you_ don't care. But as a library one cannot usually make such claims.
People may want to use it in conditions where they _do_ care, and for good
reason. It would be a shame if C++ would not be applicable for such scenarios
just because some people didn't care enough.

So, please, enlighten me. What would be a realistic way to recover from 
such an exception?


André

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

Re: [Development] What kind of airplane we want to build?

[Simon Everts]

2016-01-20 15:48 GMT+01:00 Ziller Eike :
>
> >  But Qt is available in D and Python, too, so ...
> > why do they use C++ if they so hate it?
>
> Maybe they don’t hate it, but still wished it had a less verbose API if you 
> don’t need the verbosity.

Understanding why people choose c++ and Qt is important when you want
to look at the broader picture.

I work in Industrial Automation business and program mainly in c++/Qt,
c#/.NET/WPF and Js/HTML5/Polymer, targeting windows (WES) as that
seems to be the standard in the PLC / Automation industry. At least on
our branch...
I split them in language / framework / user-interface. As that's is
how I would compare them and choose the stack that's best for the job
that needs to be done.

If I would need to choose 1 stack to do it all it would be Qt, but
that's my personal opinion. For our business C#/.NET is the standard
go-to language on our department for desktop applications, simply
because all our programmers know it (easy to learn?)  and it's easy to
hire programmers to jump-in if required. The same goes for Js/HTML5,
but we use that more for the mobile / crossplatform apps.

C++/Qt is used in our vision software doing image processing. We'd
like to have more control over the compiler / optimizations, no
garbage collector and no marshalling etc.

When I try to use Qt for other apps I'm not making friends with our
other programmers, but I actually find it easier to create small
applications with Qt because of the simple to use and consistant API.
I also find it harder to do things wrong as opposed to .NET. Also in
QtCreator it's very easy and fast to call up the API reference for
classes. With VisualStudio i always have to search, but maybe i'm
doing something wrong here. The point is that in .NET is always need
to look things up. In Qt the API more intuitive. It's important that
I'm comparing Qt and .NET/WPF here, not c++ and c#.

When comparing c++ and c# then I feel there is a large difference in
productivity. When I've done work in C# using VisualStudio with
Resharper or in Javascript/NodeJS, and then go back to c++ in
QtCreater I feel not very productive. Refactoring plays a role here,
but also language features. Downside of using VisualStudio with c++ is
the lack of intellisense for QML (I do love the progress done in
QtCreator though :) )

In C# it can be very productive to use lambda delegates as signal handlers.
Or in NodeJS a lambda as a callback: const client = net.connect({port:
8124}, () => { //'connect' listener }
Yesterday I tried to do something like this in a quick way for a
unit-test with with the connected event of the QWebSocket, Tried
connecting the signal to a lambda expression and it worked, but I
wonder if it saved me time making it :)
The point here is that if the API supports using those new language
features, than that already could make the language feel a lot more
productive.
Another example would be the chaining of promises in javascript (with
.then and.catch, is that possible with QFuture?) and or the
async/awaitable functions in c#.

When writing the user interface I definitely would prefer QML above
fighting browsers with HTML/CSS or chewing XML with XAML. Although I
sometimes would wish to have an easy way of styling standard
components like in CSS using classes and mixins.

Using qmake for small projects is also ok, it's easier to handle than
a visual studio project for version control. But if the project is
larger and needs to use subdirs, than i would have a hard time
explaining it to other programmers. But showing them a CMakeLists.txt
would scare them away i think ;)

These are just some observations from my point of view, maybe some
points are obvious, but I hope it can contribute to this discussion :)

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 22:44:02 Andre Somers wrote:
> On 21-1-2016 21:09, Milian Wolff wrote:
> > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> >> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
>  Thiago Macieira wrote:
> > The copy constructor is called once, then the move constructor. If
> > value_type's move constructor is not noexcept, then it may throw
> > after the
> > container resized.
>  
>  Throwing an exception in a move constructor is really, really
>  horrible. I can see why a copy constructor would throw (out of
>  memory, failure to duplicate some other resource), but a move?
> >>> 
> >>> Indeed.
> >>> 
> >>> But the class in question may not have a move constructor. In the
> >>> absence of one, the copy constructor gets called.
> >> 
> >> I generally don't care. If I can't copy anymore due to running out of
> >> memory, I'm pretty much done anyway. No reliable way to recover from
> >> that. Might as well terminate the program.
> > 
> > Right, _you_ don't care. But as a library one cannot usually make such
> > claims. People may want to use it in conditions where they _do_ care,
> > and for good reason. It would be a shame if C++ would not be applicable
> > for such scenarios just because some people didn't care enough.
> 
> So, please, enlighten me. What would be a realistic way to recover from
> such an exception?

Take a server as an example. All it needs to do is return an error code to the 
client. It can prepare such an error before attempting the operation, so it 
will be able to produce the error message even in the case of bad_alloc.

But the discussions about move ctors that throw aren't even about bad_alloc. 
They are about assertion exceptions.

Kleopatra (KDEPIM), e.g., uses exception for assertions, precisely to be able 
to communicate a proper error code back to the client (Kleopatra is also a UI 
server). It doesn't even matter whether the program then continues to run or 
simply restarts itself. The important bit is to return that error code (and 
cancel any begun transactions) and not just drop out of the connection.

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] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote:
> On 21-1-2016 21:09, Milian Wolff wrote:
> > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> >> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
>  Thiago Macieira wrote:
> > The copy constructor is called once, then the move constructor. If
> > value_type's move constructor is not noexcept, then it may throw after
> > the
> > container resized.
>  
>  Throwing an exception in a move constructor is really, really horrible.
>  I
>  can see why a copy constructor would throw (out of memory, failure to
>  duplicate some other resource), but a move?
> >>> 
> >>> Indeed.
> >>> 
> >>> But the class in question may not have a move constructor. In the
> >>> absence
> >>> of one, the copy constructor gets called.
> >> 
> >> I generally don't care. If I can't copy anymore due to running out of
> >> memory, I'm pretty much done anyway. No reliable way to recover from
> >> that. Might as well terminate the program.
> > 
> > Right, _you_ don't care. But as a library one cannot usually make such
> > claims. People may want to use it in conditions where they _do_ care, and
> > for good reason. It would be a shame if C++ would not be applicable for
> > such scenarios just because some people didn't care enough.
> 
> So, please, enlighten me. What would be a realistic way to recover from
> such an exception?

This of course heavily depends on the actual application and code path. 
Possible scenarios I can imagine:

- drop caches to free up memory
- abort current operation, assuming it will clean up after itself and went 
into an abnormal state, i.e. repeating it may not necessarily result in the 
same error
- abort current operation without taking down other more important operations
- abort whole application in orderly fashion (i.e. not terminate but do a real 
shutdown)
- ...

Be creative, I bet you can come up with realistic recovery situations 
yourself!

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The 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] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> Ivan was talking about thread-safe classes. You need to lock a mutex to
> take the copy.

Returning a QMap instead of a std::shared_ptr would be perfectly 
thread-safe there. The atomic reference counting would ensure that any 
thread that wants to write to the data that another thread still holds would 
detach first.

The only way to be thread-unsafe with a QMap would be to explicitly bypass 
the implicit sharing by using something like std::shared_ptr, which of 
course doesn't make sense.

Kevin Kofler

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

[Development] A simple analysis of apps using qtbase's private headers

[Lisandro Damián Nicanor Pérez Meyer]

I did a **very** simple analysis of apps packaged in Debian using qtbase's 
private headers. My main concern was to see if we (Debian) can avoid having to 
rebuild them every time we push a new version of Qt to our archive.

What I've found seemed interesting so I decided to share it here.

The following three have something in common: they are all apps coded for 
Chinese people. I've been told that they need QPA's private stuff in order to 
have proper input systems, but I haven't checked.

* fcitx-qt5 1.0.5
* gcin 2.8.4
* hime 0.9.10

If people go to the extent of using private headers for this maybe it's a very 
good reason to (somehow) make that part of the API public. It might make a 
difference for chinese coders.

--8<--

The following three seems to be using at least qpa/qplatformtheme.h

* KDE's frameworkintegration 5.16.0
* libqtxdg 1.3.0
* lxqt-qtplugin 0.10.0

Maybe for being able to create it's own theme?

--8<--

And the rest for various reasons:

* KDE's kdeclarative 5.16.0: code says to use QQuickImageProvider

* KDE's kwin 5.4.3: qpa/qwindowsysteminterface.h

* gammaray 2.4.0 I guess it needs to get into internal stuff.

* musescore 2.0.2 An interesting false positive. It embeds Qt's code without a 
namespace so the resulting symbols files get catched by our tools and confuse 
them.

* qtcurve 1.8.18: private/qwidget_p.h (no further digging)

* calibre 2.48.0: quite a lot of stuff, just saw it and left it there.


That's all. I really hope someone finds it interesting.














-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: [Development] Qt 5.6.0 header diff

[Thiago Macieira]

On Thursday 21 January 2016 16:56:56 Frederik Gladhorn wrote:
> Hello,
> 
> this is an update, the final header diff.
> Since we all agree that email is not the perfect medium for the header
> review (I see some open questions in the old thread), I'd thought I'll go
> for an attempt at pushing the diffs to gerrit. I'm not quite satisfied with
> the outcome, ideas for improvement are welcome (as long as they don't mean
> lots of work for me ;))
> 
> Here is a change containing all the different diffs:
> https://codereview.qt-project.org/#/c/146876/

Thanks, Frederik.

I'm reviewing now.

You know, since we're using Gerrit, we could actually *use* Gerrit. If you 
check out v5.5.0, then checkout 5.6's files, commit and push, we'll get an 
actual diff to review, one per file. With some script magic, we can also remove 
noisy changes like copyright header changes and Q_NULLPTR changes.

-- 
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] Heads up for Qt Bug Report & Code Review users

[Jokiniva Jukka]

Unfortunately I can¹t think any optimal solution for this.
Having two emails means that you need to have two Qt Accounts.

I would resolve it by running Jira with my personal account on different
browser.
Not optimal, but works.

‹Jukka



On 22/01/16 01:50, "Development on behalf of Thiago Macieira"
 wrote:

>On Thursday 21 January 2016 10:27:06 Jokiniva Jukka wrote:
>> Maintenance break is over and systems are back online. Use your unified
>>Qt
>> Account credentials to login from now on.
>> 
>> If you find bugs, please report them here:
>> https://bugreports.qt.io/browse/QTJIRA
>
>Looks like I will soon[*] have a problem: I use two different accounts
>for my 
>Qt services. I need to use the account associated with my Intel mail
>address 
>for Code Review, as that's the one associated with the Corporate CLA.
>
>But Intel's mail servers are bad (read: Exchange), so I use my personal
>account on JIRA. All the bug reports I'm associated with and the
>components 
>I'm the default assignee for are with this account. I don't want to
>change it.
>
>So how do I keep receiving bug report email to my personal inbox while
>logged 
>in to Gerrit with the Intel account?
>
>[*] soon because Gerrit hasn't logged me out yet.
>-- 
>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] Heads up for Qt Bug Report & Code Review users

[Thiago Macieira]

On Friday 22 January 2016 07:12:19 Jokiniva Jukka wrote:
> Unfortunately I can¹t think any optimal solution for this.
> Having two emails means that you need to have two Qt Accounts.
> 
> I would resolve it by running Jira with my personal account on different
> browser.
> Not optimal, but works.

Not acceptable since I can't click URLs easily from the mail client.

Is there any way to merge the two accounts, but still keep email delivery the 
way it is?
-- 
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] QFont::setFamily("monospace") on OS X

[Liang Qi]

Perhaps QPlatformTheme::font() is related.

https://github.com/qtproject/qtbase/blob/5.6/src/gui/kernel/qplatformtheme.h

Regards,
Liang

On 21 January 2016 at 18:29, René J.V.  wrote:

> Hello,
>
> Not sure if this is the best place to ask:
> I think QFont::setFamily("monospace") should allow to obtain an
> appropriate monospace font on all platforms. It does with the XCB QPA ,
> giving me the Consolas font (ideally it should return the fixed-width font
> that goes with the active (platform) style, though).
> On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the
> system fallback font.
>
> I suppose that's a bug, or is there a reason why this doesn't work as
> expected?
>
> Cf: https://bugreports.qt.io/browse/QTBUG-50564
>
> R.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



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