Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

> On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote: > > On Monday 09 February 2015 09:54:12 Smith Martin wrote: >> This is the kind of thing we should add to the documentation, but can you >> elaborate? I mean, illustrate the meaning of "locality of reference," >> "wildly mixing insertions, lookups,

Re: [Development] Deprecating modules with 5.5

On Monday 09 February 2015 22:52:34 Kevin Kofler wrote: > Guido Seifert wrote: > > Did something like that happen before? > > Yes, RHEL has never shipped QtWebKit, as far as I know because of support > (especially with security updates) concerns. (They're likely to also not > ship QtWebEngine, but

Re: [Development] Status of Qt3D in 5.5

On 10 February 2015 at 00:55, Sean Harmer wrote: > > On Monday 09 Feb 2015 08:44:34 Thiago Macieira wrote: > > On Monday 09 February 2015 16:15:42 Sean Harmer wrote: > > > Trying to come up with a generic way to manage all this whilst making good > > > use of n cores is a good fit for ThreadWeave

Re: [Development] Deprecating modules with 5.5

Guido Seifert wrote: > Did something like that happen before? Yes, RHEL has never shipped QtWebKit, as far as I know because of support (especially with security updates) concerns. (They're likely to also not ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did not exist yet w

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote: > On Monday 09 February 2015 22:10:09 André Pönitz wrote: > > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > > > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > > > I don't think the argument of whitesp

Re: [Development] Deprecating modules with 5.5

Lisandro Damián Nicanor Pérez Meyer wrote: > The real answer is simple: all of them. We do our best to avoid embedded > libraries (and yes, we sometimes fail to do it, and that's a bug for us). +1, same here (Fedora). > If I where to start at some place I would choose V8 and ffmpeg, but the > rea

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 22:10:09 André Pönitz wrote: > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > > I don't think the argument of whitespace changes making the history > > > hard to read carries a lot of weight

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote: > On Monday 09 February 2015 21:21:12 André Pönitz wrote: > > I don't think the argument of whitespace changes making the history > > hard to read carries a lot of weight in a git world. > > Whitespaces can be ignored in git diff and

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 21:21:12 André Pönitz wrote: > I don't think the argument of whitespace changes making the history > hard to read carries a lot of weight in a git world. Whitespaces can be ignored in git diff and git blame. You can't do that with C++ keywords. -- Thiago Macieira - thi

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 09:11:54PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 19:49:19 André Pönitz wrote: > > I am fairly sure that we won't reach consensus on what the set of such > > selected places exactly look like, that's why the plan to reach some > > conclusion was to restrict a p

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 09:05:09PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 20:10:44 André Pönitz wrote: > > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I > > > know at some point we will be able

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 19:49:19 André Pönitz wrote: > I am fairly sure that we won't reach consensus on what the set of such > selected places exactly look like, that's why the plan to reach some > conclusion was to restrict a part of the discussion to one case where I > think there's a chance

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 20:10:44 André Pönitz wrote: > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I > > know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's > > not possible with 0 (not

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I know > at some point we will be able to just s/Q_NULLPTR/nullptr/. That's not > possible with 0 (not even with NULL (could be C code)), so I don't see the > point in

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 08:36:53AM +0100, Bo Thorsen wrote: > > > > For the sake of keeping this part of the discussion simple, I specifically > > mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the > > context of initializing a local pointer variable. So: Any advantage? Any >

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 12:07:15AM +0100, Allan Sandfeld Jensen wrote: > On Sunday 08 February 2015, André Pönitz wrote: > > On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote: > > > What would be the point of macros if they always expanded? The entire > > > point and usefulness

Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

Am 09.02.2015 um 15:35 schrieb Friedemann Kleint: > Hi, > > >we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to > have lost the ability to display something on another screen than the > default > > QMainWindow *wm = new QMainWindow(dw->screen(1)); > > Change https://codereview

Re: [Development] Status of Qt3D in 5.5

On Monday 09 Feb 2015 08:44:34 Thiago Macieira wrote: > On Monday 09 February 2015 16:15:42 Sean Harmer wrote: > > Trying to come up with a generic way to manage all this whilst making good > > use of n cores is a good fit for ThreadWeaver or Intel TBB or something > > else along the same lines. >

Re: [Development] Status of Qt3D in 5.5

On Monday 09 February 2015 16:15:42 Sean Harmer wrote: > Trying to come up with a generic way to manage all this whilst making good > use of n cores is a good fit for ThreadWeaver or Intel TBB or something > else along the same lines. Wouldn't TBB be an acceptable dependency? -- Thiago Macieira

Re: [Development] Status of Qt3D in 5.5

On Monday 09 Feb 2015 07:25:38 Thiago Macieira wrote: > On Monday 09 February 2015 13:55:29 Sean Harmer wrote: > > * Replacement for Threadweaver to allow commercial licensing. This is > > underway thanks to Mika and is under review on gerrit at present. > > (As discussed in the release team meet

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 Feb 2015 16:12:06 Marc Mutz wrote: > On Monday 09 February 2015 15:56:28 Sean Harmer wrote: > [...] > > > I guess depending upon the sizes of your key and value types and number of > > elements and typical frequencies of operations (inserts vs lookups vs > > removals) it may also poss

Re: [Development] Status of Qt3D in 5.5

On Monday 09 February 2015 13:55:29 Sean Harmer wrote: > * Replacement for Threadweaver to allow commercial licensing. This is > underway thanks to Mika and is under review on gerrit at present. (As discussed in the release team meeting) The rest sounds like API reviews and only the above is a g

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 15:56:28 Sean Harmer wrote: [...] > I guess depending upon the sizes of your key and value types and number of > elements and typical frequencies of operations (inserts vs lookups vs > removals) it may also possibly be better to use two vectors, one for the > keys and one

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 Feb 2015 09:49:08 Marc Mutz wrote: > On Monday 09 February 2015 09:32:56 Marc Mutz wrote: > > > Something like this should work just as well on QVector, right? If you > > > are doing multiple inserts, perhaps you should keep the inserts outside > > > the main vector while you make them

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote: > > But the advantage of Qt data structures is the implicit sharing. > > Cough, cough. > > http://www.gotw.ca/publications/optimizations.htm (watch the publication date) > and w

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 09.02.2015 um 15:40 schrieb Marc Mutz: > On Monday 09 February 2015 09:54:12 Smith Martin wrote: >> This is the kind of thing we should add to the documentation, but can you >> elaborate? I mean, illustrate the meaning of "locality of reference," >> "wildly mixing insertions, lookups, and remo

Re: [Development] Feature freeze approaching

I'd also like to mention those patches improving anti-aliasing and providing the option to use FreeType for text rendering on OSX: https://codereview.qt-project.org/#/c/105258/ https://codereview.qt-project.org/#/c/105225/ https://codereview.qt-project.org/#/c/105226/

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 09:54:12 Smith Martin wrote: > This is the kind of thing we should add to the documentation, but can you > elaborate? I mean, illustrate the meaning of "locality of reference," > "wildly mixing insertions, lookups, and removals," and "batch updates and > separate them fro

Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

Hi, >we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to have lost the ability to display something on another screen than the default > QMainWindow *wm = new QMainWindow(dw->screen(1)); Change https://codereview.qt-project.org/#/c/105285/ for https://bugreports.qt.io/browse

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote: > But the advantage of Qt data structures is the implicit sharing. Cough, cough. http://www.gotw.ca/publications/optimizations.htm (watch the publication date) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a K

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015, Mathias Hasselmann wrote: > Am 09.02.2015 um 00:07 schrieb Allan Sandfeld Jensen: > > I am not a big fan of nullptr, > > Out of curiosity: What's wrong with nullptr in your opinion? > Nothing, except it is just usually not needed, so coding styles that enforce it are

[Development] Problem porting app from Qt4 to Qt5 with multiple X-screen

Hi,   I'm trying to port a Qt4 application to Qt5. All works fine except two points: - we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to have lost the ability to display something on another screen than the default - embedding an application window into another application do

[Development] Status of Qt3D in 5.5

Hi all, Although we are closing in on a stable API for Qt3D there are still a few of areas that we'd like to change/expand upon a little. These are: * Mouse input. At present this is a bit of a hack (via a Configuration{} element) used to get the mouse to control a camera. Of course the mouse m

Re: [Development] qmake bug 17533

On Mon, Feb 09, 2015 at 02:19:05PM +0100, Bo Thorsen wrote: > On 02/09/2015 02:07 PM, Oswald Buddenhagen wrote: > > it may be that i replace that code wholesale in the next weeks. code > > already exists (since five years ...), but it wasn't developed in a very > > cooperative way, and nobody bothe

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On 9 Feb 2015, at 13:42, Smith Martin wrote: >>> Everyone wishing to use a QMap should implement one before >>> using it for the first time. Then you'd see what you inflict on the world. > > If that sentiment is valid, then we owe it to our users who are contemplating > using a QMap to explain

Re: [Development] qmake bug 17533

On 02/09/2015 02:07 PM, Oswald Buddenhagen wrote: > On Mon, Feb 09, 2015 at 01:34:55PM +0100, Bo Thorsen wrote: >> I have been working on trying to fix >> https://bugreports.qt.io/browse/QTBUG-17533. >> >> The fix itself is really simple: [...] >> > riight ... Well, it is. But it showed other

Re: [Development] qmake bug 17533

On Mon, Feb 09, 2015 at 01:34:55PM +0100, Bo Thorsen wrote: > I have been working on trying to fix > https://bugreports.qt.io/browse/QTBUG-17533. > > The fix itself is really simple: [...] > riight ... > Does anyone here know this code? > no > It feels like an area where there could be dra

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

>>Everyone wishing to use a QMap should implement one before >>using it for the first time. Then you'd see what you inflict on the world. If that sentiment is valid, then we owe it to our users who are contemplating using a QMap to explain to them when and why a QMap should be used and when and

[Development] qmake bug 17533

I have been working on trying to fix https://bugreports.qt.io/browse/QTBUG-17533. The fix itself is really simple: Remove line 559 of qmake/generators/makefiledeps.cpp. But when I tried compiling Qt itself with the modified qmake, I got a compile error. The bug is that qmake doesn't set main.m

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On 02/09/2015 09:54 AM, Smith Martin wrote: > > "In the vast majority of cases, a sorted vector is much faster, due to > locality-of-reference. A RB-tree is optimized for wildly mixing > insertions, > lookups, and removals. When you can batch updates and separate them from > lookups, t

Re: [Development] Deprecating BlackBerry Playbook support

+1 This was in discussion for a while anyway... -- vm On 09/02/15 08:19, Knoll Lars wrote: > No objections from my side. Unless someone else raises a very good > argument (I can’t see what that would be) within the next 48 hours, please > go ahead. > > Cheers, > Lars > > On 06/02/15 16:55, "Rafa

[Development] Item creation time in QML

Hi, Thought I would share a couple of benchmark numbers for item creation time in QML. The sources are found here: https://github.com/sletta/stuff/tree/master/qml/benchmarks . The motivation is that we can generally animate a large nu

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Hi, just my 2 cents: just coding some database stuff using QVariants, and invariably (especially Monday mornings) it takes me a couple of milliseconds extra to comprehend what the tooltip for QVariant's toInt() means: int toInt(bool *ok = 0) const; instead, if qvariant.h could be written

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

"In the vast majority of cases, a sorted vector is much faster, due to locality-of-reference. A RB-tree is optimized for wildly mixing insertions, lookups, and removals. When you can batch updates and separate them from lookups, time-wise, then a sorted vector is usually preferrable." Th

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Am 09.02.2015 um 08:48 schrieb André Somers: > Mathias Hasselmann schreef op 8-2-2015 om 22:28: >> >> Am 08.02.2015 um 14:28 schrieb Marc Mutz: >> >>> c. Using QMap. As Alex Stepanov put it: every use of a map should be >>> discussed >>> in a face-to-face meeting with your manager. Since we

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 09:32:56 Marc Mutz wrote: > > Something like this should work just as well on QVector, right? If you > > are doing multiple inserts, perhaps you should keep the inserts outside > > the main vector while you make them, and only at the end do a single > > std::merge. > > B

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Sunday 08 February 2015 21:47:35 André Pönitz wrote: > On Sun, Feb 08, 2015 at 09:08:01PM +0100, Marc Mutz wrote: > > On Sunday 08 February 2015 20:06:14 André Pönitz wrote: > > > > 3. nullptr - On top of the warning, which I wasn't aware about, I > > > > find the > > > > > > > >code easier

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On Monday 09 February 2015 08:48:06 André Somers wrote: > Mathias Hasselmann schreef op 8-2-2015 om 22:28: > > Am 08.02.2015 um 14:28 schrieb Marc Mutz: > >> c. Using QMap. As Alex Stepanov put it: every use of a map should be > >> discussed > >> > >> in a face-to-face meeting with your manag

Re: [Development] Deprecating modules with 5.5

Well start with the easiest understanable reasons. People come from old platforms whith old applications and they don't know what their upcoming hardware platforms will be, so they decide why not go to Qt first and then decide, which platform is usable for us. Thats a pretty common theme and if