Re: [Development] gerrit : using branches

Op 30/03/2016 om 19:09 schreef René J.V. Bertin: On Wednesday March 30 2016 15:51:49 Welbourne Edward wrote: I met such a review tool once. It was actually horribly frustrating. I'd much sooner be using critic [0]. I am a regular user of KDE's Reviewboard. It's undoubtedly not ideal, but I

Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]

Op 21/03/2016 om 14:25 schreef Marc Mutz: On Monday 21 March 2016 13:38:43 Sean Harmer wrote: On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: It's to support one-to-many delivery of an event-like object to backends potentially running on multiple threads concurrently. The type is not a

Re: [Development] Qt Coding Guidelines

Op 18/03/2016 om 18:54 schreef Allan Sandfeld Jensen: On Friday 18 March 2016, André Somers wrote: Op 18/03/2016 om 09:24 schreef Rutledge Shawn: Forcing it on everyone that way will be controversial, because there is still some leeway in formatting, whereas automation would remove any

Re: [Development] Qt Coding Guidelines

Op 18/03/2016 om 09:24 schreef Rutledge Shawn: Forcing it on everyone that way will be controversial, because there is still some leeway in formatting, whereas automation would remove any chance of personal preference, and probably screw up in some cases. But we could at least start by

Re: [Development] Qt Coding Guidelines

Op 16/03/2016 om 16:14 schreef Koehne Kai: Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing

Re: [Development] Qt Coding Guidelines

Op 16/03/2016 om 20:47 schreef Ziller Eike: On Mar 16, 2016, at 20:33, André Somers <an...@familiesomers.nl> wrote: Op 16/03/2016 om 16:14 schreef Koehne Kai: Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailin

Re: [Development] Qt Coding Guidelines

Op 17/03/2016 om 11:24 schreef Mathias Hasselmann: Am 17.03.2016 um 10:01 schrieb Sorvig Morten: How about treating the coding guidelines as \internal documentation? We could then at some point build and publish it together with the rest of the \internal's. (suitably separated from the

Re: [Development] Programmitcally putting widget on X display

Hi, I think you are on the wrong list. This one is for the development _of_ Qt. For questions on how to develop _with_ Qt, the inter...@qt-project.org list is more suitable. André Op 11/03/2016 om 08:15 schreef Shiva sitamraju: Hi, I am trying to put widget on X display from Qt (on

Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties

Op 07/03/2016 om 21:21 schreef Curtis Mitch: Thanks guys. Is this worth mentioning in the documentation? It already says so, right? I don't think it is needed to specify exactly what breaks. André From: Development

Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties

Op 07/03/2016 om 20:55 schreef Curtis Mitch: Recently I noticed this sentence in QObject's documentation [1]: We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may

Re: [Development] Supported platforms for Qt 5.8

Op 20/02/2016 om 08:38 schreef Petroules Jake: "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev branches. However, I wholeheartedly approve bumping it to 7. This puts us at a minimum of "last four releases" (by the time 5.8 is released) for both OS X and iOS. However I'd

Re: [Development] platform neutrality in Qt

QPA (lighthouse) is a major factor in that. Other than that: lots of hard work. André Op 26/02/2016 om 14:52 schreef ravi kumar verma: Hi, Can anyone please elaborate how Qt framework achieves platform netrality? I mean what feature in it makes it platform neutral. regards

Re: [Development] Units in QML

Op 25/02/2016 om 12:49 schreef Alberto Mardegan: On 25/02/2016 13:20, Welbourne Edward wrote: André Somers used m* for minutes and metres, footnoting: )* Note the first clash already... I think it is fairly sane to just insist that SI units take precedence, especially given that we support

Re: [Development] Units in QML

Op 25/02/2016 om 11:20 schreef Welbourne Edward: André Somers used m* for minutes and metres, footnoting: )* Note the first clash already... I think it is fairly sane to just insist that SI units take precedence, especially given that we support multi-letter unit names (e.g. pt, px, mm, cm

[Development] Units in QML (was: Re: Scalable UIs in QtQuick (take 2))

Op 25/02/2016 om 01:41 schreef Michael Brasser: Hi, Regarding (2), last time around I had concerns about the proposed limitations associated with language-level unit support (see some of the discussion at https://codereview.qt-project.org/98288). I'd be interested to hear the particulars

Re: [Development] Scalable UIs in QtQuick (take 2)

Op 18/02/2016 om 11:50 schreef Hausmann Simon: Hi, A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical

Re: [Development] RFC: lambda or lambda return from lambda?

Op 01/02/2016 om 15:16 schreef Marc Mutz: On Monday 01 February 2016 10:18:25 Jędrzej Nowacki wrote: So it would look like that: fields.erase(std::remove_if(fields.begin(), fields.end(), [](const QPair )

Re: [Development] Modify QLibraryInfo to support any default location of qt.conf

Op 28/01/2016 om 13:00 schreef Maximilian Hrabowski: Why isn't this first ? I would generally expect an environment variable to take precedence over all other configuration options except command-line options. You are right, that an environment variable should be considered first. But I

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

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

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

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

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

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

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

Op 21/01/2016 om 16:55 schreef Giuseppe D'Angelo: On Thu, Jan 21, 2016 at 4:43 PM, André Somers <an...@familiesomers.nl> 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 ani

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

Op 21/01/2016 om 08:00 schreef 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

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

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.

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

Op 21/01/2016 om 00:45 schreef Andrew den Exter: 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

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

Op 20/01/2016 om 15:48 schreef Ziller Eike: On Jan 20, 2016, at 3:12 PM, Marc Mutz wrote: On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as

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

Op 19/01/2016 om 13:15 schreef Marc Mutz: On Tuesday 19 January 2016 11:13:16 Harri Porten wrote: On Tue, 19 Jan 2016, Marc Mutz wrote: I think we agree that std containers are in many cases faster than the Qt containers. But they are harder to use and especially developers that come from

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

Op 20/01/2016 om 06:47 schreef Thiago Macieira: On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote: Thiago Macieira wrote: foreach copies; ranged for doesn't. … unless you try to use it on a non-const Qt container with usage count >1, then it will even deep-copy (detach) it! (I know

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

Op 20/01/2016 om 08:18 schreef Knoll Lars: Where is this qAsConst coming from? When was it introduced? Where is it documented? I can't find it in my Qt documentation. It just got added some weeks ago, after we realised that range-for would lead to our containers detaching. So it'll be in

Re: [Development] Design choice of QFileSystemModel

Op 08/01/2016 om 21:40 schreef Javier Jaramago Fernandez: Anyone knows about the issue related to this thread? qt-forum . In concrete I wanted to know about this statement: "I can tell you that the filter is not being

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

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

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

-- Original Message -- From: "Thiago Macieira" <thiago.macie...@intel.com> 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:

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

Op 03/12/2015 om 12:18 schreef Mark De Wit: Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing

Re: [Development] How does mktime() handle DST transitions ?

Op 5-11-2015 om 00:06 schreef Kevin Kofler: Welbourne Edward wrote: I'm looking into QTBUG-49008 and need to work out how diverse implementations of mktime handle DST transitions: at one end of the year there's a gap (where 1:59 is followed by 3:00), at the other end there's a duplicated hour

Re: [Development] How does mktime() handle DST transitions ?

Op 5-11-2015 om 00:06 schreef Kevin Kofler: Welbourne Edward wrote: I'm looking into QTBUG-49008 and need to work out how diverse implementations of mktime handle DST transitions: at one end of the year there's a gap (where 1:59 is followed by 3:00), at the other end there's a duplicated hour

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 19-10-2015 om 17:54 schreef Thiago Macieira: > First of all, QStringRef keeps a pointer to the original QString, so it isn't > as fragile as QStringView. In fact, during the development of the XML stream > classes, there was a QSubString class that did more or less what QStringView > would do.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 20-10-2015 om 11:08 schreef Иван Комиссаров: > Btw, isn't the QStringView is the same as Range > { Container::Iterator begin; Container::Iterator end; } ? > Why we introduce only QStringView/QByteArrayView? Maybe we should > think about adding range API to all containers? > > Alexandrescus

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 19-10-2015 om 22:31 schreef Bubke Marco: > For example the highlighting can show that the parameter is an in or in/out > parameter so you don't need to use pointers anymore for in/out parameters > etc. But it is getting off topic. https://bugreports.qt.io/browse/QTCREATORBUG-14468 André

Re: [Development] QTime microsecond support

Op 15-10-2015 om 14:18 schreef Edward Sutton: > +1 for naming QTimeSpan with support for arithmetic operators. -1 for that one. To me QTimeSpan is something else. I have an old WIP lying around with exactly that name. It does not model a specific time, it models a duration. André

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 15-10-2015 om 14:52 schreef Konstantin Ritt: > > > For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 > (feel free to compare their complexity against UTF-32). > And why "pure Chinese signs" again? Did you ever look into the > Unicode's Scripts.txt [1], for example? It

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 14-10-2015 om 15:59 schreef Matthew Woehlke: > >>> Yes, signed please. We can discuss whether it should be 64bit for Qt 6. >> The current std API uses size_t. Do you (= both of you) expect that ever to >> change? If it doesn't, Qt will forever be the odd one out, until we finally >> drop

Re: [Development] New Qt Modules

Op 13-10-2015 om 12:22 schreef Oswald Buddenhagen: > On Tue, Oct 13, 2015 at 09:52:54AM +, Knoll Lars wrote: >> The only one I could see that could make sense in an existing repo is the >> dbus qml integration, but then again, this one can’t live in qtbase where >> the rest of the dbus code

Re: [Development] 0 vs. NULL

Op 8-10-2015 om 11:27 schreef René J.V. Bertin: > Hi, > > A bit of a generic question, for my personal education. I saw a comment in a > code review recently (one related to making Qt build on OS X 10.11, probably) > about the preferred use of 0 instead of NULL. > > I didn't realise at first why

Re: [Development] QML import versions

Op 21-9-2015 om 13:08 schreef Filippo Cucchetto: > I agree with most of what has been said by everyone here. > What i see it's there're two problems: > 1) A way to specify a QML module version based on a Qt release > 2) A way to decentralize the version used in several .qml files or of > an

Re: [Development] Qt 5.6.0 header diff: QtQuick.diff

Op 18-9-2015 om 09:59 schreef Albert Astals Cid: > >> New classes: >> >> * QQuickImageResponse >> >> Isn’t this class missing some way to get the status of the response? It >> only has an errorString() method, but no simple way to query whether it >> was successful or not when finished() gets

Re: [Development] Enhancement to QIODevice?

Op 14-9-2015 om 12:25 schreef Andrzej Ostruszka: > Hello all, > > I'd like to ask for possibility to enhance a bit QIODevice. > > My problem/wish is following. I'm using QSerialPort and (as all > QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine > since most of the time this

Re: [Development] MSVC2015 and Qt5.5 -- dot release plans?

Op 23-7-2015 om 19:13 schreef Thiago Macieira: On Thursday 23 July 2015 07:09:05 Tom Isaacson wrote: I don't know whether we'll be able to produce binaries for it for 5.5.1. That depends on how soon we can bring it up in the old CI. Any idea when 5.5.1 is due now? The Wiki says the original

Re: [Development] New Module Request: QtGeniviExtras

IMHO the users of QtGeniviExtras and the DLT logging are totally aware of how the system works and want to have full control over it. DLT is only known in the automotive space and there it's only used for GENIVI linux based systems. So i think we talk about a logging solution which 90% of

Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum values

Op 12 aug. 2015 om 19:52 heeft Keith Gardner kreios4...@gmail.com het volgende geschreven: On Wed, Aug 12, 2015 at 11:54 AM Denis Shienkov denis.shien...@gmail.com wrote: skips three making Four == 3. yes, and what? :) This obviously needs to be: Four = 4 Ok, seems it

Re: [Development] QString behavior change

Op 31-7-2015 om 09:48 schreef Oswald Buddenhagen: On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote: On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote: On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote: Hi The behavior of QString::trimmed has changed from 5.3.2 to

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

Op 31-7-2015 om 09:20 schreef Knoll Lars: Anything except 1e will still change C:\Users to C:\\Users in the output, which was one of the complaints listed. Yes, but this is unavoidable. We need to escape non printable characters and quote, and this implies we also need to escape the

Re: [Development] Qt LTS C++11 plans (CopperSpice)

Op 27-7-2015 om 03:47 schreef Ansel Sermersheim: On 7/26/15 3:01 PM, Kevin Kofler wrote: Ansel Sermersheim wrote: We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Op 21-7-2015 om 11:55 schreef Bubke Marco: From: development-bounces+marco.bubke=theqtcompany@qt-project.org development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of Kevin Kofler kevin.kof...@chello.at If you have large objects, and insert or remove items within the

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Mark Gaiser schreef op 17-7-2015 om 13:44: You can use std::find_if for that on any container. Works for C++11 and even before that. C++11 gives the benefit of using a lambda in the std::find_if UnaryPredicate. Sure, but wouldn't that revert you back to a linear search? That sounds like

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Marc Mutz schreef op 17-7-2015 om 11:09: On Thursday 16 July 2015 23:09:55 Gunnar Roth wrote: About QFastHash: that is WIP. It's the very rudimentary beginnings of an open- addressing hash container (a hash container using consecutive memory, not nodes). What was the idea behind it? Is so

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Marc Mutz schreef op 17-7-2015 om 12:21: What might also be a consideration when making a container like this, is that I find the key is often (not always of course) already part of the value data structure. For instance, if I store employee records and key them by id, that id is also in the

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Sune Vuorela schreef op 12-7-2015 om 20:37: On 2015-07-12, Andre Somers an...@familiesomers.nl wrote: become easier to make the transition in user code? Then, if Qt itself changes its API in Qt 6 to use QVector instead of QList, the users' code will just work :-) In Qt6, QList can be fixed.

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Smith Martin schreef op 10-7-2015 om 13:27: I think the impedance mismatch here is that you use list to mean the same thing as array or vector (in STL terms, not mathematically) while I only use it to mean linked list, in accordance with the STL. I actually just mean it's a list, and I don't

Re: [Development] QVersionNumber: someone to polish and finish the API

Thiago Macieira schreef op 7-7-2015 om 01:13: There are about a dozen changes pending between refactorings that I've done and those of Marc on top of mine. The class needs those cleanups before it becomes public API. If there's no interest in reviving the API in the until feature freeze for

Re: [Development] Some Qt3D feedback

Simon Hausmann schreef op 18-6-2015 om 09:08: * metatype registration is problematic with namespaced types, as the macro extracts the name of the type through the preprocessor. People can very easily end up registering the type multiple times with different (qualified vs non qualified) names.

Re: [Development] QtCS: Long Term Release discussion

Thiago Macieira schreef op 16-6-2015 om 22:49: Last year's notes[1] Qt 5.5 will be the last release to support: * GCC 4.6 * OS X 10.7 * Windows Vista * WIndows Embedded Compact 7 * QNX 6.5 * Qt WebKit, Qt Script, Qt Quick 1 Ok, I understand that

Re: [Development] QtCS: Long Term Release discussion

Thiago Macieira schreef op 17-6-2015 om 09:15: On Wednesday 17 June 2015 09:01:19 André Somers wrote: Does the CI infrastructure depend on the Qt version then? What is it about 5.5 that prevents the CI from being upgraded? Two different CI implementations. The new CI is being developed

Re: [Development] QtCS: Long Term Release discussion

Thiago Macieira schreef op 17-6-2015 om 08:57: On Wednesday 17 June 2015 08:33:50 Giuseppe D'Angelo wrote: On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira thiago.macie...@intel.com wrote: Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for longer. So we're targetting

Re: [Development] QtCS: Long Term Release discussion

Knoll Lars schreef op 17-6-2015 om 12:27: * We’d still remove the deprecated modules from our Qt 5.6 release (maybe with the exception of Qt Script). Is that really needed? For all of the modules? Could Quick 1 stay too?* André *) Yes, we have a stake in that: The printing case.

Re: [Development] QtCS: Long Term Release discussion

Giuseppe D'Angelo schreef op 17-6-2015 om 10:34: I would also push the C++11 in our API to 5.7 to minimise the risks. Cheers, C++11 in our API was to be taken slowly anyway, according to the session at QtCS. We would start with using it in the implementation to gain some experience first.

Re: [Development] Some Qt3D feedback

Marc Mutz schreef op 16-6-2015 om 15:41: On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote: Note that in a world of auto variables, class names are no longer _that_ important. Functions are important, they are still visible. But other than at initial creation, class names fade to be

Re: [Development] Some Qt3D feedback

Marc Mutz schreef op 15-6-2015 om 22:26: On Monday 15 June 2015 21:01:54 André Pönitz wrote: if so: Please explain how that avoids name clashes. You only need to add the prefix when the compiler tells you. E.g. if you use QtGui::QTransform in one file and Qt3D::QTransform in another, in

[Development] QtCS: Notes from Modern C++ session

Hi, I made notes in the Modern C++ session. You can also find them on the Wiki here: https://wiki.qt.io/QtCS2015_ModernCpp but I was requested to also post them here on the ML. If you were there and remember things differently, please edit and post a reply with corrections. == Sunday

Re: [Development] Qt 5.5.0 header diff

Marc Mutz schreef op 11-6-2015 om 16:33: BTW: Can someone send a summary of Qt 5.6 vs. C++11 to the ML, for those that couldn't attend? I made notes. Available from here: https://wiki.qt.io/QtCS2015_ModernCpp André ___ Development mailing list

Re: [Development] date/time adjust for (auto) testing

Bo Thorsen schreef op 3-6-2015 om 11:44: Den 03-06-2015 kl. 08:38 skrev André Somers: We have applications that use the current date and time at places spread around the code. For normal operations, that works very nicely. However, we find that for (auto) testing, it would be very convenient

Re: [Development] date/time adjust for (auto) testing

Curtis Mitch schreef op 3-6-2015 om 10:00: -Original Message- From: development-bounces+mitch.curtis=theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of André Somers Sent: Wednesday, 3 June 2015 8:39 AM

[Development] date/time adjust for (auto) testing

Hi, We have applications that use the current date and time at places spread around the code. For normal operations, that works very nicely. However, we find that for (auto) testing, it would be very convenient if we could trick the application into believing it is some other date/time, so

Re: [Development] Imageformats v2

Иван Комиссаров schreef op 19-5-2015 om 19:43: Let me describe current API and the ideas behind it. The core class is the ImageDocument - this is the replacement of the QImageReader/QImageWriter. Reader and writer has similar API and implemented in the same way, so i’ve decided to merge them

Re: [Development] Fwd: Imageformats v2

Иван Комиссаров schreef op 20-5-2015 om 12:45: Hm, i pressed wrong button when replying to the letter:) As did I. I intended for it to be send to the list. Have done that now. André ___ Development mailing list Development@qt-project.org

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

Giuseppe D'Angelo schreef op 17-5-2015 om 21:57: On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35: 2015-05-18 11:10 GMT+02:00 Christian Kandeler christian.kande...@theqtcompany.com mailto:christian.kande...@theqtcompany.com: On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 9:55 PM, Smith Martin

Re: [Development] Future of Qt Quick 1 in Qt 5

André Somers schreef op 11-5-2015 om 08:26: Bo Thorsen schreef op 10-5-2015 om 09:43: You are aware of http://doc.qt.io/qt-5/qquickpainteditem.html, right? This makes it pretty trivial to port painter based items to QtQ2. Did you actually read the use case? I am rendering both custom

Re: [Development] Future of Qt Quick 1 in Qt 5

Bo Thorsen schreef op 10-5-2015 om 09:43: You are aware of http://doc.qt.io/qt-5/qquickpainteditem.html, right? This makes it pretty trivial to port painter based items to QtQ2. Did you actually read the use case? I am rendering both custom and standard elements to QPainter based devices

Re: [Development] Future of Qt Quick 1 in Qt 5

Simon Hausmann schreef op 11-5-2015 om 09:21: On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote: On 8-5-2015 18:47, Hausmann Simon wrote: Hi, If the public API would allow you to implement what the folks at KDAB did at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ ‎,

Re: [Development] Future of Qt Quick 1 in Qt 5

Albert Astals Cid schreef op 8-5-2015 om 15:58: On Fri, May 8, 2015 at 3:53 PM, Frederik Gladhorn frederik.gladh...@theqtcompany.com wrote: Absolutely. But you can migrate to Qt 5.5 which has Qt Quick 1 support and later to 5.6 and onwards. Not if you're using the Qt that comes with your

Re: [Development] Future of Qt Quick 1 in Qt 5

Frederik Gladhorn schreef op 8-5-2015 om 14:39: Hi, I think the dust has settled quite a bit and the declarative module is becoming better by the day. We have seen it evolve and the new Java Script engine is running smoothly (and actively worked on, sadly it will have one known crasher in

Re: [Development] Qt XML patterns

Frederik Gladhorn schreef op 8-5-2015 om 14:32: Hello all, I’ve just looked a bit at the QtXmlPatterns module. The module has a few issues and is not actively maintained. I wonder if it should see improvements or if there are good alternatives which might be more spec compliant which people

Re: [Development] Rotating JPEG images by default

Alberto Mardegan schreef op 23-4-2015 om 13:20: On 04/23/2015 01:36 PM, Gunnar Sletta wrote: I think we should strive to not introduce regressions on purpose. Hence: - Revert the behavioral change in 5.4 which adds rotation to JPEGs - Have opt-in rotation in QImageReader. - Keep TIFF

Re: [Development] Rotating JPEG images by default

Alberto Mardegan schreef op 21-4-2015 om 17:24: On 04/17/2015 11:48 AM, Allan Sandfeld Jensen wrote: If we go with the QImageReader level, it could be an QImageIOHandler::Option, and possibly be set different between JPEG and TIFF by default. The real problem is what we decide the default for

Re: [Development] Rotating JPEG images by default

Alberto Mardegan schreef op 22-4-2015 om 13:32: It may be that we disagree because we have a different view of what is the goal of QImage and friends. To me, what matters is not the pixel data, but how the image looks like when I blit it. I'm writing an image viewer using QML, and I just

Re: [Development] RFC: RAII for property changes

Hi Marc, Thank you for responding. Marc Mutz schreef op 15-4-2015 om 16:43: Hi André, On Wednesday 15 April 2015 11:49:56 André Somers wrote: void MyClass::setFoo(QString value) { PropertyGuard guard(this, foo); //foo is the name of the Q_PROPERTY Q_UNUSED(guard); m_foo

[Development] RFC: RAII for property changes

a mechanism like this? I have not found it in Qt itself, but perhaps others here are already using similar methods or perhaps very different methods to tackle the issues I described? Looking forward to your comments, André Somers ___ Development mailing list

Re: [Development] Allowing event delivery prior to and after QCoreApplication

Knoll Lars schreef op 15-4-2015 om 11:39: Well, I’d say we should try to see how much this is being used. I don’t think we ourselves use it at all. How much is this used in other projects? The central notify() hook is something I don’t like at all. It’s very easy to mess things up using it,

Re: [Development] Are SiCs through #include cleanups considered acceptable?

Marc Mutz schreef op 11-4-2015 om 14:33: On Friday 10 April 2015 14:06:18 André Somers wrote: Marc Mutz schreef op 10-4-2015 om 13:29: [...] For one, you're not supoosed to inherit from value classes. For another... Oh, I think that's enough reasons :) That a religious argument instead

Re: [Development] Are SiCs through #include cleanups considered acceptable?

Simon Hausmann schreef op 9-4-2015 om 10:39: On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: Hi, I have in the past fixed #include mistakes such as #include qsharedpointer.h for QSharedDataPointer, and even though each time the

Re: [Development] Mime database size

Mathias Hasselmann schreef op 23-2-2015 om 07:48: Am 17.02.2015 um 14:36 schrieb Cristian Adam: One could rewrite this small utility into Qt and then it would be available everywhere. Somehow I thought that one of the big benefits of free software and open source is, that you _don't_ have to

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Olivier Goffart schreef op 20-2-2015 om 11:38: On Friday 20 February 2015 11:26:31 Daniel Teske wrote: [...] That's one area. The others are too replace trivial interfaces with a low amount of virtual functions by a std::function properties. This can simplify code if e.g. the different

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Olivier Goffart schreef op 20-2-2015 om 12:32: On Friday 20 February 2015 11:15:32 BogDan wrote: I fully agree with you, but, sadly, I think it will not be possible in 5.x. We started supporting C++98 during the course of Qt 4.x. We dropped MSVC 6, in Qt 4.5 (despite there was still people

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Olivier Goffart schreef op 20-2-2015 om 12:22: On Friday 20 February 2015 11:38:21 André Somers wrote: Olivier Goffart schreef op 20-2-2015 om 11:38: On Friday 20 February 2015 11:26:31 Daniel Teske wrote: [...] That's one area. The others are too replace trivial interfaces with a low

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Bo Thorsen schreef op 20-2-2015 om 09:03: Andrés question about how this would change the API is a lot more interesting. I so far haven't seen a single case where someone has described how access to lambdas might improve the API. If they are there, I'd love to see them, because maybe this

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Daniel Teske schreef op 19-2-2015 om 13:29: Hi, Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and C++14 added a lot of new good features. C++17 is planned to be a big step again. Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in a

Re: [Development] JSON 64 bit int

Marc Mutz schreef op 11-2-2015 om 16:11: On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote: Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo: On 11 February 2015 at 12:12, Bo Thorsen b...@vikingsoft.eu wrote: It's so easy to say we just follow the standard. But I have two current

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

Marc Mutz schreef op 10-2-2015 om 14:19: On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote: I think using a QMap is fine in most case. Sorry, no. I know you don't believe me. Maybe you believe your own eyes: https://www.youtube.com/watch?v=ApLLVY6MZaIlist=PLHxtyCq_WDLXFAEA-

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

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 don't have that, I'd change this to: Everyone wishing to

<    1   2   3   4   >