Re: [Development] QList for Qt 6

(Sorry for not chiming in earlier, this was hidden wy at the top of my spool where I didn't notice there were unread messages.) On 22/05/2019 09.49, Lars Knoll wrote: > Let’s conclude the topic of QList. I do see the concern about silent > source breakages. Here’s what we’ll (I’ll) do then

Re: [Development] unique_ptr and Qt, Take 2

On 03/05/2019 15.13, Thiago Macieira wrote: > On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote: >> Anyhow, I too feel that we may need a dedicated smart pointer class for >> this, to catch all the corner cases and allow the existing flow of >> >> 1) create something >> 2)

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 11/06/2019 15.35, Danila Malyutin wrote: > вт, 11 июн. 2019 г. в 22:22, Matthew Woehlke: >> On 04/06/2019 16.41, Mutz, Marc via Development wrote: >>> How do you intend to address the problem that QHash/QMap are all but >>> unusable in C++11 ranged for

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 04/06/2019 16.41, Mutz, Marc via Development wrote: > On 2019-06-03 11:26, Lars Knoll wrote: >>> == QSharedDataPointer / QExplicitlySharedDataPointer == >> >> I see no reason at all for removing those, quite to the contrary. They >> are very helpful for building refcounted classes (explicitly

Re: [Development] From whence cometh Q_NAMESPACE?

On 11/06/2019 13.58, Giuseppe D'Angelo via Development wrote: > On 11/06/2019 19:24, Matthew Woehlke wrote: >> So, my questions are: >> >> 1. Is it really Qt's intent that using Q_NAMESPACE, etc. requires >> including ? >> >> 2. If not, is it worth tweaki

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 30/05/2019 04.12, d3fault wrote: > On 5/29/19, Mutz, Marc via Development wrote: >> == QSharedDataPointer / QExplicitlySharedDataPointer == >> >> These are basically Qt-internals, and should never have been public in >> the first place. > > I disagree (unless there's some replacement you

Re: [Development] From whence cometh Q_NAMESPACE?

On 11/06/2019 12.30, Giuseppe D'Angelo via Development wrote: > Il 11/06/19 17:28, Matthew Woehlke ha scritto: >> [...] would it make sense to move the documentation [of >> Q_NAMESPACE, Q_ENUM, etc.] to QMetaObject? > > Well, also Q_OBJECT itself, Q_SIGNALS/Q_SLOTS, etc. appe

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 05/06/2019 10.23, Elvis Stansvik wrote: > Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development: >> [...] This, and many other such instances, show me that the Qt >> containers are considered good enough [...] > > I guess that is the case. At least I haven't craved for any of the >

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 03/06/2019 01.49, Thiago Macieira wrote: > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >> I also managed to get that done with a <10 lines of "plain cmake": >> >> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05 >> 7/src/CMakeLists.txt#L46-L54 > >

Re: [Development] Proposing CMake as build tool for Qt 6

On 06/06/2019 09.23, Simon Hausmann wrote: > Regarding PCH, it seems that right now it would be easiest to > include something like https://github.com/sakra/cotire . Patches are > welcome to integrate this or alternatively work with upstream CMake > for a built-in solution. Considering that

[Development] From whence cometh Q_NAMESPACE?

A coworker just pointed out something interesting... the documentation of Q_NAMESPACE is in qobject.cpp, which causes it to be documented under the documentation for QObject. However, the *definition* comes from qobjectdefs.h, which is roughly QMetaObject, and indeed it seems like one should not

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

On 05/04/2019 10.49, Matthew Woehlke wrote: > IMNSHO, I think Qt would do well to take a close and careful look at > Google Test, which IMO has a much better design, at least as far as how > test assertions are handled. > > In particular, I miss having a distinction between fata

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

On 02/04/2019 11.14, Mitch Curtis wrote: > As described in https://bugreports.qt.io/browse/QTBUG-66320, > currently Qt users are on their own if they want to call helper > functions that can fail a test. The reason is documented: > > Note: This macro can only be used in a test function that is

Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)

On 16/03/2019 12.13, Giuseppe D'Angelo via Development wrote: > What I meant is this: during phase 5 and 6, are string literals > simply sequences of symbols from a set, or are they already encoded > in some encoding? From my reading, it's the former (the execution > character set is just this

Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)

On 15/03/2019 08.27, Giuseppe D'Angelo via Development wrote: > Il 14/03/19 22:48, Thiago Macieira ha scritto: >> For >> >>    char16_t text1[] = u"" "\u0102"; >> >> It produces, without /utf-8 (seehttps://msvc.godbolt.org/z/EvtKzq): >> >> ?text1@@3PA_SA DB '?', 00H, 00H, 00H    ;

Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)

On 14/03/2019 16.50, Matthew Woehlke wrote: > While working on some modernization of my application — in particular, > converting some UTF-8 literals to use QStringLiteral — I noticed a > concerning compiler warning: > > warning C4566: character represented by universal

[Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)

While working on some modernization of my application — in particular, converting some UTF-8 literals to use QStringLiteral — I noticed a concerning compiler warning: warning C4566: character represented by universal-character-name '\u' cannot be represented in the current code page

Re: [Development] CMake Workshop Summary

On 13/02/2019 05.06, Simon Hausmann wrote: > We briefly discussed the topic and it's my understanding that an agreement > exists to support two types of builds: > > (1) Build a repo, install it, build the next repo, install it, etc. > (2) Have a super-project that allows building all of

Re: [Development] Enum classes in signals?

On 05/02/2019 11.58, Thiago Macieira wrote: > On Tuesday, 5 February 2019 08:43:03 PST Jason H wrote: >> Should all new connections be in the modern syntax? > > Yes, if you can. On that note, will uic in Qt6 finally use the new PMF syntax? -- Matthew

Re: [Development] Qt6: Adding UTF-8 storage support to QString

On 18/01/2019 11.09, Thiago Macieira wrote: > As for strings, the QString constructor takes UTF-8 input, but however fast > the decoder is, it's still slightly slower than the Latin1 decoder. So if > your > string is purely US-ASCII, using QLatin1String is recommended. ...but I assume

Re: [Development] Build system for Qt 6

On 16/12/2018 12.00, Denis Shienkov wrote: > As we all can see, the CMake loses even QBS. We need to spent a tens of > hours/days to find out the solution, using CMake's , but with QBS same > issue solves for 30 mins or work immediatelly.  Its very funny. Really? Because *I* don't see that. This

Re: [Development] Build system for Qt 6

On 16/12/2018 08.21, Ray Donnelly wrote: > In particular ide generators cannot express complex build > dependencies very well and any use of scripts will tend not to work unless > you hardcore them for each one. Scripts can be problematic if they need to run stuff that is part of the build,

Re: [Development] Build system for Qt 6

On 15/12/2018 15.49, Ray Donnelly wrote: > Do you know for example that cmake will find dlls in C:\Windows\System32, Uh... yeah? I think most people *expect* that... Would you also rather CMake didn't look in /usr/lib[64] on Linux systems? *Why*? > find_package is still inscrutable, and it's

Re: [Development] Build system for Qt 6

Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote: >> For that matter, what happens to namespacing? Can I do this? >> >> find_package(Qt 5.8 COMPONENTS Core Gui) >> find_package(Qt 2.1 COMPONENTS WebEngine) > > sure you can. I suspect that would requ

Re: [Development] Build system for Qt 6

On 01/11/2018 08.10, Oswald Buddenhagen wrote: > no, instead i told you that your premise of needing a _global_ solver is > wrong. ...but you have failed to explain how dependency resolution will succeed in a scenario such as I have outlined. Actually, I realize now there is a possible answer:

Re: [Development] Build system for Qt 6

On 31/10/2018 14.26, Oswald Buddenhagen wrote: > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote: >> Again, how then does the consuming tool know which qt.core and which >> qt.gui are compatible with each other? How does it handle the case of >> finding a qt.

Re: [Development] Build system for Qt 6

On 31/10/2018 12.46, Oswald Buddenhagen wrote: > On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote: >> On 30/10/2018 17.51, Oswald Buddenhagen wrote: >>> after much thinking about the matter, i concluded that the interface >>> files should correspond t

Re: [Development] Build system for Qt 6

On 30/10/2018 17.51, Oswald Buddenhagen wrote: > for starters just some food for thought: > QBS-995 should be implementable on top of it. > if you want to go full monty, QBS-942 is your target. What are those? Can you provide links? > one thing i noticed is that you multiplex build variants and

Re: [Development] Build system for Qt 6

On 30/10/2018 14.25, Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: >> In order to actually implement the ability to read CMake interface >> files (without corner cases), you basically have to *be* CMake. >> If you assume th

Re: [Development] Build system for Qt 6

On 30/10/2018 14.30, Edward Welbourne wrote: > Painful as [CMake's] syntax is (I've begun reviewing the work for it), it's > there, someone else is supporting it, and the expected time to the final > demise of qmake does look shorter than our other options. FWIW, I don't think anyone is praising

Re: [Development] Build system for Qt 6

On 30/10/2018 13.17, Oswald Buddenhagen wrote: > it's much easier to make qbs generate **and even read** cmake > interface files than to re-architect cmake to make it, well, sane. (Emphasis added.) No, really, it isn't. A CMake interface file is Turing-complete and can do anything that CMake can

Re: [Development] Build system for Qt 6

On 30/10/2018 13.26, Konstantin Shegunov wrote: > [CMake is] powerful, even to the point of being dangerous (I've seen > quite the abominations). It's know to be Turing-complete. 'Nuff said ;-). -- Matthew ___ Development mailing list

Re: [Development] Build system for Qt 6

On 30/10/2018 04.21, resurrect...@centrum.cz wrote: > Christian Gagneraud wrote: >> On Tue, 30 Oct 2018 at 18:29, wrote: >>> set(var1 "Hello") >>> set(var2 "Hello") >>> >>> if(var1 EQUAL var2) >>>     message("They are equal") >>> endif() >>> >>> Guess what, it prints NOTHING despite docs

Re: [Development] Build system for Qt 6

On 30/10/2018 12.40, Oswald Buddenhagen wrote: > all the promotion qbs would need is being used to build qt. If that's the case, please name a few projects that are using bjam or boost.build. -- Matthew ___ Development mailing list

Re: [Development] Build system for Qt 6

On 30/10/2018 07.23, Christian Gagneraud wrote: > CMake is not even aware that they are other OS behind WIndows and > Linux Desktop Have you looked at CMake's dashboards? Maybe you are confusing "supported platforms" with "platforms for which pre-built binaries are provided"? Support, much

Re: [Development] Improving CMake support for static builds

On 12/10/2018 15.11, Kyle Edwards wrote: > New Qt developer here. I'm trying to improve Qt's support for static > builds using CMake [...] See also https://bugreports.qt.io/browse/QTBUG-38913. This has been languishing for entirely too long; it will be great if someone can finally fix it!

Re: [Development] Using #pragma once

On 08/10/2018 02.23, Henry Skoglund wrote: > So, what about a new preprocessor command: > > __has_same_md6_digest See also http://wg21.link/p0538 and note that EWG rejected it. The general consensus, AFAICT, is that modules is expected to make all this stuff irrelevant, and therefore EWG does

Re: [Development] override keyword on destructors

On 2018-08-20 09:58, Kevin Funk wrote: > IMO, it would also be nice to get a compiler warning/error if a > base class' destructor is changed from virtual to non-virtual which may cause > subtle behavioral changes such as memory leaks. You mean something like -Wnon-virtual-dtor? Granted, it's

Re: [Development] Qt 6 buildsystem support requirements

On 2018-08-02 09:03, Oswald Buddenhagen wrote: > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote: >> On 2018-08-01 04:24, Jason Newton wrote: >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >>>> Persistent build server? Java? No, thanks.

Re: [Development] Qt 6 buildsystem support requirements

On 2018-08-01 04:24, Jason Newton wrote: > On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >> On 2018-07-21 19:52, Jason Newton wrote: >>> I wanted to mention that this is on my mind alot for a few years days >>> as a user for a plethora of libraries. My conclusi

Re: [Development] Qt 6 buildsystem support requirements

On 2018-07-21 19:52, Jason Newton wrote: > I wanted to mention that this is on my mind alot for a few years days > as a user for a plethora of libraries. My conclusion for the build > system with the brightest future is bazel [...] No. Just, *no*. Persistent build server? Java? No, thanks.

Re: [Development] Repository request: MaterialWidgets

On 2017-10-30 09:04, iman ahmadvand wrote: > But we've some new widgets beside the existing widgets, for example: > > Switch: https://material.io > /guidelines/components/selection-controls.html#selection-controls-switch Why not add this to Qt? Personally, I am not convinced that UI elements

Re: [Development] Future of QBS

On 2017-10-17 05:49, Konstantin Tokarev wrote: > 17.10.2017, 05:06, "Kevin Kofler" wrote: >> Konstantin Tokarev wrote: >>>  * It is target-oriented from the start and is not so burdened by legacy >>>  ways of doing things wrong, which plague old CMake projects and confuse >>>  newcomers >> >>

Re: [Development] Future of QBS

On 2017-10-16 22:05, Kevin Kofler wrote: > Konstantin Tokarev wrote: >> I have no real experience with Meson, but at least it has following >> advantages: >> >> * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., > the variables you can set

Re: [Development] CSPRNG vs DPRNG

On 2017-10-12 13:06, Thiago Macieira wrote: > libstdc++'s LCG does: > _M_x = __detail::__mod<_UIntType, __m, __a, __c>(_M_x); > return _M_x; > > which is > > _M_x = (__a * _M_x + __c) % __m; ...and yet, for some reason when I tested it, it was *quite* slow. Noticeably slower than

Re: [Development] CSPRNG vs DPRNG

On 2017-10-11 12:12, Thiago Macieira wrote: > I created a better option: QPseudoRandomGenerator (name bikeshedding later) > on the flight home from QtCS. It's a simple wrapper around the Mersenne > Twister > provided by the Standard C++ Library The last time I found myself in need of a

Re: [Development] Introducing discussion about QStringFormatter

On 2017-08-10 22:20, Thiago Macieira wrote: > On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote: >> On 10 August 2017 at 20:41, Mårten Nordheim wrote: >> IMHO, "QFormat" isn't a suitable name. First, this class itself does >> not describe a format,

Re: [Development] implicit sharing and iterators in qt containers

On 2017-07-31 17:36, Mandeep Sandhu wrote: >> I'd expect to be able to use keys that do not define qHash or qLess. > > Why? Why not? >> Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? It's still a key-value store in which items are retrieved by key,

Re: [Development] implicit sharing and iterators in qt containers

On 2017-07-31 13:11, Mandeep Sandhu wrote: > Right now, I'm detaching the linked list during copy-construction (and > assignment). Detaching here means re-populating the LL with same entries > and then storing the new LL iterator's in the hash. > > For implicit sharing, I'll have to this instead

Re: [Development] QList

On 2017-04-25 09:48, Thiago Macieira wrote: > Basically the discussion is: what should happen to QArrayList or > QArrayList? > > a) fail to compile > b) become an array list > c) become a vector > > I point out that (c) is what QList does, and we don't need the same behaviour > as QList

Re: [Development] QHash iteration vs std::unordered_map

On 2017-04-20 13:18, Sergio Martins wrote: > On 2017-04-20 18:06, Matthew Woehlke wrote: >> for (auto i : qtEnumerate(my_hash)) >> do_stuff(i.key(), i.value()); > > That doesn't work with temporaries, does it ? No. Neither does std::add_const / qAsConst. > Maybe s

Re: [Development] QHash iteration vs std::unordered_map

On 2017-04-16 10:44, Corentin wrote: > If you want the same behavior, you can create a proxy for your associative > container instance, with a custom iterator whose operator*() returns a std > pair ( or a QPair ) - quite a bit of boilterplate code. ...or use

Re: [Development] Passing QSize, QPoint, QTime and other small structs by value

On 2017-04-07 06:40, Sergio Martins wrote: > Some time ago I documented the guidelines on passing by value vs > const-ref: > https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value > > But the reality is that passing small structs by value is not very > popular and Qt's

Re: [Development] QList

On 2017-03-29 14:11, Marc Mutz wrote: > On 2017-03-29 18:57, Matthew Woehlke wrote: >> I think the main reason some many people disagree with you on CoW and >> related subjects is because you put performance above all else, >> including correctness and ease of use. > >

Re: [Development] QList

; On 2017-03-29 16:41, Matthew Woehlke wrote: >> On 2017-03-29 07:26, Marc Mutz wrote: >>> (I just had to review _another_ pimpl'ed class that contained >>> nothing but two enums) >> >> ...and what happens if at some point in the future that class needs >>

Re: [Development] QList

On 2017-03-29 07:26, Marc Mutz wrote: > That brings us straight back to the fundamental question: Why can the C++ > world at large cope with containers that are not CoW and Qt cannot? The only > answer I have is "because Qt never tried". And that's the end of it. I have > pointed to Herb's

Re: [Development] OT: English phonetic spelling

On 2017-03-27 12:44, Konrad Rosenbaum wrote: > [quite OT, but I'll pile on... - just for fun] > > On Mon, March 27, 2017 17:43, Matthew Woehlke wrote: >> Iä, thät güst lûks wrå. Yf wi wÿr tu ëvÿr du süch thyz, ai >> wûd müch > > Let me propose the more "Jusfull&q

[Development] OT: English phonetic spelling (was: QList)

On 2017-03-27 03:43, Marc Mutz wrote: > And "debt" should be spelled "det". It should. It isn't. You can start > writing > det everywhere now, and maybe in a generation you will have collected enough > mindshare that the Oxford Dictionary contains it as an alternative spelling. > Your

Re: [Development] Use of std::function in Qt API

On 2017-03-17 12:17, Thiago Macieira wrote: > Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu: >> A distribution will not update the standard c++ library within a distro >> release. >> Neither will a distribution upgrade Qt minor versions within a >> distro release. >

Re: [Development] Use of std::function in Qt API

On 2017-03-14 13:33, André Pönitz wrote: > In general, I am not overly sold on ABI compatibility promises. I personally > could live without and find SC of more practical value. The most important > "feature" of ABI compatibility guarantee for me is that it limits people from > doing overly

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

On 2017-01-30 12:29, André Pönitz wrote: > *If* it turns out to be a problem elsewhere, which I don't expect, > there needs to be an explanation why a transcription of "ä" can be > considered a more severe "legal issue" than the "legal issue" > originating from transcribing "©" as "(C)" in the

Re: [Development] A new approach for Qt main()

On 2016-12-09 19:43, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke > escreveu: >> On 2016-12-09 16:23, Thiago Macieira wrote: >>> That's a valid concern, but not one that warrants a QApplication subclass. >> >

Re: [Development] A new approach for Qt main()

On 2016-12-09 16:23, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke > escreveu: >> I can work around that, though it's obnoxious. I'm more concerned about >> not being able to tinker with the CLI arguments before Qt gets them. &

Re: [Development] A new approach for Qt main()

On 2016-12-09 12:10, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke > escreveu: >> Also, how does this work if someone wants to subclass Q*Application? >> (Again, I have projects that do that...) > > But why do they do

Re: [Development] A new approach for Qt main()

On 2016-12-09 04:35, Morten Sorvig wrote: > We should consider changing the way Qt initialization and startup works. > This is something I’ve personally been wanting to do for some time, and > a recent offline discussion pushed it on my stack again. > > Currently, Qt and application startup looks

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

On 2016-11-22 06:25, Marco Bubke wrote: > On November 22, 2016 08:17:57 Thiago Macieira wrote: >> Theming and styling is a complex operation. It's not just "propagating >> values". Reading config files will at best get you the right font, correct >> icon >> set, and somewhat correct colours.

Re: [Development] Naming of path/directory-related environment variables in Qt

On 2016-11-11 10:13, Mitch Curtis wrote: > I'd like to establish some kind of convention for naming > path/directory-related environment variables in Qt, with the hope > that it could be set in stone with e.g. one of these newfangled > QUIPs. [...] So, can we all agree on using "PATH" when naming

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

On 2016-09-22 16:58, André Pönitz wrote: > There is not much of a choice. An equivalence relation is reflexive, > i.e. at least Foo(a) == Foo(a) must be true. JFTR... auto nan = qNaN(); assert(nan != nan); // okay assert(!(nan == nan)); // okay -- Matthew

Re: [Development] QUuid documentation

On 2016-09-08 05:35, Benjamin TERRIER wrote: > As of Qt 5.7, QUuid::createUuid() documentation is: > >> On any platform other than Windows, this function returns a new UUID with >> variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device >> exists, then the numbers used to

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-20 15:18, Konstantin Tokarev wrote: > 20.09.2016, 22:11, "Matthew Woehlke" <mwoehlke.fl...@gmail.com>: >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS *is* >

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-15 02:57, Oswald Buddenhagen wrote: > On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: >> I want to understand Qbs and what it can do with a dynamic build graph >> which CMake can't do. > > there is no such thing, as after full expansion the graph has to be

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-08 07:41, Bo Thorsen wrote: > Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >>> As an incredibly simple example, make is inherently limited in that it >>> cannot even represent a rule with multiple outputs (there are some >>> workarounds, but they are hacky and rather limited in how they

Re: [Development] Notes on QtCore session @ QCS2016

On 2016-09-05 20:02, Thiago Macieira wrote: > Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo > escreveu: >> Il 02/09/2016 17:01, Thiago Macieira ha scritto: >>> https://wiki.qt.io/QtCS2016_QtCore >>> >>> * Deprecation of APIs >>> >>> * qrand/qsrand -> replacement

Re: [Development] Use of Standard Library containers in Qt source code

On 2016-07-02 02:42, Marc Mutz wrote: > The STL has a great API. push_back() / back() vs. append() / last(), e.g. It > just happens to be largely consistent with itself instead of with Qt. But > camelCase is not intrinsically "better" than underscored_names, and I also > fail to see why first()

Re: [Development] Use of Standard Library containers in Qt source code

On 2016-07-01 17:56, Thiago Macieira wrote: > On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote: >> Even today: where is QList::push_back(T&&)? Where are our emplacement >> functions and their try versions? Where are our exception guarantees?) > > We don't care about

Re: [Development] Use of Standard Library containers in Qt source code

On 2016-07-01 16:13, Giuseppe D'Angelo wrote: > Even today: where is QList::push_back(T&&)? Where are our emplacement > functions and their try versions? Where are our exception guarantees?) ...what's an exception? ;-) Never heard of those in Qt... -- Matthew

Re: [Development] clang-format config file.

On 2016-06-30 06:52, Olivier Goffart wrote: > [clang-format] follows the style closely, but there are some cases > that might not be following existing practices. The question is if we > want to try to fix clang-format to be able to cope with them, or > simply adapt the coding style to fit

Re: [Development] std::chrono getters in our API

On 2016-06-10 19:27, Thiago Macieira wrote: > On sexta-feira, 10 de junho de 2016 16:12:10 PDT Matthew Woehlke wrote: >> On 2016-06-10 13:53, Thiago Macieira wrote: >>> I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and >>> we're hitting a snag

Re: [Development] std::chrono getters in our API

On 2016-06-10 13:53, Thiago Macieira wrote: > I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and > we're hitting a snag on what to name the getters. The setters are fine > because > they're just overloads: > > timer.setInterval(3); // Qt; milliseconds >

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

On 2016-04-26 08:08, Shawn Rutledge wrote: > If the application does not handle high-frequency events (mouse > movements and window moves/resizes) quickly enough, some events will > be dropped. Do you really mean dropped? Or do you mean merged? There is a HUGE difference... Please don't EVER

Re: [Development] QColor and HSL's hue

On 2016-04-09 09:02, Curtis Mitch wrote: > Is there any technical reason (besides compatibility) why QColor::hslHueF() > can't return a value between 0 and 1? > > If the colour being represented by QColour is black, QColor::hslHueF() will > return -1: I think there is a misunderstanding

Re: [Development] gerrit : using branches

On 2016-04-04 08:49, René J.V. Bertin wrote: > [...] there's no way to obtain the branch from a given commit? There is `git name-rev`, but it may or may not work or give you the "best" answer. At least it should give you *a* branch name if a SHA is the tip of a local branch. I'm not sure offhand

Re: [Development] What qtbase looks like with extensive use of auto

On 2016-03-19 14:02, Stephen Kelly wrote: > In case you missed it, I wrote an auto-modernizer > > https://steveire.wordpress.com/2016/03/19/aaargh Thanks for sharing. I admiringly adore all the abounding (and artistic) alliteration adorning the article. (Sorry, couldn't think how to avoid "the"

Re: [Development] some questions about QtGamePad

On 2016-02-16 12:08, Nichols Andy wrote: > I’m sorry if my mail came off as obstructionist as it was not intended in > this way. Not at all :-). (Opinionated, perhaps, but I wouldn't say "obstructionist". I have no philosophical problem with strongly held opinions, being one who often holds

Re: [Development] some questions about QtGamePad

On 2016-02-16 04:31, Curtis Mitch wrote: >> How do you even handle hats??? This, for the record, was an expression of confusion. (Since alleviated, though you'll notice from my latter post that I don't particularly agree with this part of the design either.) >> If you supported arbitrary axes,

Re: [Development] some questions about QtGamePad

On 2016-02-15 15:23, Matthew Woehlke wrote: >> So I do not support expanding the scope of QtGamepad in the way you >> propose, as I think if it belongs anywhere it is in a generic input API >> (or you can always still just wrap SDL's input module pretty easily). > >

Re: [Development] some questions about QtGamePad

On 2016-02-15 14:46, Nichols Andy wrote: > QtGamepad is intentionally limited to gamepads, and does not include support > for joysticks, or generic devices with an arbitrary number of axes/buttons. That's... stupid IMNSHO. Especially since... > The design was primarily inspired by the HTML 5

Re: [Development] some questions about QtGamePad

On 2016-02-15 13:04, Matthew Woehlke wrote: > On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote: >> Looking at the API it seems it has a very hard assumption on 2 sticks and >> 18 buttons. > > Please support arbitrary axes and buttons, as done in e.g. SDL. I wrote a joyst

Re: [Development] some questions about QtGamePad

On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote: > Looking at the API it seems it has a very hard assumption on 2 sticks and > 18 buttons. Please support arbitrary axes and buttons, as done in e.g. SDL. Hard-coding this stuff is a terrible idea, as even devices with similar physical

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

On 2016-01-22 13:02, Bubke Marco wrote: > Actually what is happen if I am in the middle of changing a qvector, and > then copying the vector in an other thread? Are you concurrently modifying and copying *the same* vector, or a shallow copy that, under the hood, happens to be shared? The

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

On 2016-01-22 05:00, Marc Mutz wrote: > On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: >> Why? In case of QMap, we have no need to use operator= to change the map. >> We simply detach and insert new data in it. >> Of course, in case of multiple changes, the map can reach some "invalid

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

On 2016-01-21 17:35, Milian Wolff wrote: > On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote: >> So, please, enlighten me. What would be a realistic way to recover from >> such an exception? > > [...] > - abort whole application in orderly fashion (i.e. not terminate but do a > real

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

On 2016-01-22 13:13, Marc Mutz wrote: > On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: >> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: >>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: What i'm missing? >>> >>> You haven't done the exercise with the int

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

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,

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

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

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

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.

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

On 2016-01-20 15:08, Pau Garcia i Quiles wrote: > Replacing QThread with std::thread? Please don't. Uh... that had *better* not happen, come to think of it. QThread is a QObject, which means it has signals/slots and an event loop. It is a LOT more featureful than std::thread, which is (mostly)

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

On 2016-01-19 12:34, Thiago Macieira wrote: > On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote: >> - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) > > Done in QGenericArray, but not really relevant since we don't support move- > only types. I'd somewhat disagree; it can still be more

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

On 2016-01-19 05:51, Marc Mutz wrote: > So... is realloc actually the optimisation everyone (incl. me) expected it to > be? It really *ought* to be, at least in the right cases. Let's say I have a type that stores a buffer, which, for whatever reason, is not movable (i.e. no move-ctor or

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

On 2016-01-19 07:50, Marc Mutz wrote: > Status quo in libraries equals bit-rot. The containers are _not_ "good > enough". E.g. QVector seriously needs to support move-only types (like > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... How do STL containers deal with this? I

<    1   2   3   4   >