Re: [Development] Repository Request: qt/licensing

On Thu, May 24, 2018 at 12:58:43PM +, Kai Koehne wrote: > > -Original Message- [...] Can .pro files test for commercial > > vs. oss licenses? If so, and you create a non- Qt project repo, > > couldn't some .pro in qtbase retrieve licheck, like QtCreator does > > here: http://code.qt.io

Re: [Development] clang-format

On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote: > > > > On 19 Jun 2018, at 18:19, Ville Voutilainen > > wrote: > > > > On 19 June 2018 at 19:13, Philippe wrote: > >>> For the above reasons I'd lean towards not running it globally and > >>> just using it on new changes. > >> > >> +

Re: [Development] Dropping file in Qt Linguist window is not allowed everywhere

On Fri, Jul 06, 2018 at 11:47:21PM +0200, scootergrisen wrote: > If i drag a file i want to open into Qt Linguist i would like the window to > accept the fil nomatter where i drop i. > > It seems the drop it only allowed in three panes. Context, string and > translation panes. The best place for

Re: [Development] Qt Linguist should tell how many strings are in a file

On Wed, Jul 18, 2018 at 03:30:14PM +0200, Jason H wrote: > It was unfortunately a combination of lokalise.co and my scripts. The > owner/opertator/developer of lokalise was very helpful in adjusting > his service which apparently supported Qt 3 to Qt4's format. He > complained about issues with the

Re: [Development] gsl::owner (Was: Setters: Clarifying the ownership)

On Tue, Jul 31, 2018 at 02:51:41PM +0200, Giuseppe D'Angelo via Development wrote: > Hi, > > On 31/07/18 13:11, Sérgio Martins via Development wrote: > > I would recommend however that our docs show T* instead of gsl::owner > > and continue to include "Takes ownership of foo" in the text. > > Whi

Re: [Development] Symbol clashes with static Qt libraries

On Fri, Aug 03, 2018 at 08:27:50AM +0200, Olivier Goffart wrote: > > The problem we had with a namespaced Qt were: using external Qt > > based libraries, which never tried to use a namespaced build, did > > not build due to forward declarations, so I had to patch some of > > them. But then, not al

Re: [Development] Naming convention for (scoped) enums

On Wed, Aug 15, 2018 at 07:32:48AM +, Alex Blasche wrote: > I don't think we have ever not permitted exceptions to official > policy. Therefore, take it for granted that the policy can be ignored > such as in the case presented by Allan. Having said that the default > should be the use of scope

Re: [Development] override keyword on destructors

On Mon, Aug 20, 2018 at 01:08:36PM +0100, Sérgio Martins via Development wrote: > Hi, > > Looks like some 'override' keywords crept into a few destructors. This is > probably because clang-tidy warns about it (and now QtCreator). > > IMO we should avoid it, as it's misleading. Dtors are a special

Re: [Development] Windows 7 support future removal

On Thu, Aug 23, 2018 at 11:03:43PM -0700, Thiago Macieira wrote: > Since we're talking about macOS 10.11 and I came across the Windows support > lifetime pages, I'm posting this for future reference. > > https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet > > Windows 7 en

Re: [Development] Windows 7 support future removal

On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > On Sunday, 26 August 2018 23:39:03 PDT André Hartmann wrote: > > Am 24.08.2018 um 10:58 schrieb André Pönitz: > > > "Being out of support by Microsoft" seems to be for quite a few people > > > a

Re: [Development] Submitting Qt to oss-fuzz

On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via Development wrote: > I made a local test run of the undefined sanitizer and it found > https://paste.kde.org/prkox41mx in a few seconds, so "it works" > > If you want to test it locally you can do python infra/helper.py > build_fuzzer

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

On Wed, Sep 05, 2018 at 09:55:41AM -0700, Thiago Macieira wrote: > On Wednesday, 5 September 2018 02:29:15 PDT Uwe Rathmann wrote: > > I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I > > understand, that reverting a decision is not stuff for big announcements, > > but for suc

Re: [Development] Using #pragma once

On Sun, Oct 07, 2018 at 08:56:47AM +, Lars Knoll wrote: > Hi, > > Just a quick question: Does anybody have any good arguments against us > starting to use #pragma once instead of header guards throughout our > code base? Not me. > I’ve started using it implicitly when updating 3rd party cod

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

On Sun, Oct 21, 2018 at 04:15:58PM +0200, Elvis Stansvik wrote: > In order to try out the unsafe usage you suggested in your other mail, > and also another unsafe usage pointed out in an SO question > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#3

Re: [Development] QUIP 12: Code of Conduct

On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote: > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > > > I am whole-heartedly against a Code of Conduct. [...] > > > > > > Hi, > > > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > > well as at the Contri

Re: [Development] QUIP 12: Code of Conduct

On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > led to abuse of power, suppression of free speech, racism against white > people > or whatever other nonsense people seem to attribute to

Re: [Development] QUIP 12: Code of Conduct

On Sat, Oct 27, 2018 at 01:09:45PM +, Martin Smith wrote: > >Well, then let me give you my simple minded opinion on this topic, an > >engineers > >opinion: > >Do not introduce a CoC. > > In that case, if a contributor is mistreated by another contributor, > what recourse does the victim have?

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > > > Hi all (first post), > > Welcome :) > > > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > > who are not on C++17 yet, which is convenient for i

Re: [Development] QUIP 12: Code of Conduct

On Sat, Oct 27, 2018 at 05:34:30PM +, Martin Smith wrote: > >Actions that are considered offenses by a society are typically mentioned > >in its laws. If something is not forbidden by law it usually means that > >there is no majority, let alone consensus in that society that this action > >is a

Re: [Development] QUIP 12: Code of Conduct

On Sun, Oct 28, 2018 at 08:34:40AM +, Martin Smith wrote: > And because we are online and spread all around the world, there is > currently no way for us to stop and prevent abusive behavior. That would be a valid reason in case there had been or we would expect to be unstoppable abusive behav

Re: [Development] QUIP 12: Code of Conduct

On Mon, Oct 29, 2018 at 02:25:20PM +, Ulf Hermann wrote: > > But then you make a statement in your post script that demonstrates > > exactly what I'm talking about. You stated "some emails in this > > thread sadly make me see part of the project in a different light. I > > fear I'm not the on

Re: [Development] Build system for Qt 6

On Tue, Oct 30, 2018 at 02:44:03PM -0700, Thiago Macieira wrote: > On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote: > > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the > > plug. > > As I saw it: qbs folks have finally started doing the correct thiing (th

Re: [Development] Build system for Qt 6

On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote: > > >From the same email perhaps it's also worth quoting the first paragraph: > " > > first things first: If you're happy with cmake, you can stop reading now. > Nobody is proposing that LLVM moves off cmake, and nobody is proposing

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote: > What do we do? > > Option 1: do nothing, wait for Qt 6 and do the change then > Option 2: insert #if in our API, starting now > Option 3: use #if per class, starting now > Option 4: create a central #if and use this new type, start

Re: [Development] Qt6 source changes

On Thu, Nov 01, 2018 at 08:45:58PM -0700, Thiago Macieira wrote: > On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote: > > Thiago Macieira wrote: > > > We're studying what to do with QList, but the idea is that the name > > > "QList" will be completely ok and identical to QVector. The tec

Re: [Development] Qt6 source changes

On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote: > > Depends on usage. > > > > See e.g. 551efd91990e07902e5324f720cf5585865c323d > > > > QmlProfiler: Use QList for QmlRange container when loading .qtd > > > > As we are using this as a queue, with many calls to takeFirst(

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

On Fri, Nov 02, 2018 at 08:52:07AM +, Lars Knoll wrote: > > On 2 Nov 2018, at 09:02, André Pönitz wrote: > > > > On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote: > >> What do we do? > >> > >> Option 1: do nothing, wait for Qt 6

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

; Option 2: insert #if in our API, starting now > >>>> Option 3: use #if per class, starting now > >>>> Option 4: create a central #if and use this new type, starting now > > On 2 Nov 2018, at 09:02, André Pönitz wrote: > >>> Option 5: Leave as-is,

Re: [Development] Suggestion - Remove Windows 7 as supported development host

On Tue, Nov 13, 2018 at 01:13:28PM +, Harald Kjølberg wrote: > Hi, > > > Referring to: https://bugreports.qt.io/browse/QTBUG-70891 > > The suggestion is to remove Windows 7 as a supported development host, > but keep it as a target. From the numbers I have access to, more than > 55% of the u

Re: [Development] automated bulk change closing old issues in the "Need more info" state

On Mon, Nov 19, 2018 at 04:36:45PM +, Shawn Rutledge wrote: > [...] > I suspect the reason people don’t hit that button is that it’s at the > top, whereas when you add a normal comment, you press the comment > button at the bottom. And if you are actually answering the question > with your com

Re: [Development] Missing documentation in Qt 5.12

On Tue, Dec 18, 2018 at 11:49:22AM +, Eike Ziller wrote: > > > > On Dec 18, 2018, at 11:25, Konstantin Shegunov > > wrote: > > > > On Tue, Dec 18, 2018 at 9:39 AM Martin Smith > > wrote: I'll argue with you about it being a p1. If the problem is > > confined to the all-members list, it's n

Re: [Development] Build system for Qt 6

On Tue, Dec 18, 2018 at 12:20:37PM -0800, Thiago Macieira wrote: > On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote: > > If Qt maintainers says that they will not remove the QtCreator && QBS > > integration in future (I'm about QBS project manager plugin), then I > > will not worry (d

Re: [Development] [Qt-creator] Stepping down as maintainer of project management in Qt Creator

On Wed, Dec 19, 2018 at 03:43:43PM +, Tobias Hunger wrote: > Hello everybody, > > not having lived up to the role of maintainer of the project management > code in Qt Creator for a while now, I would like to formally step down. > > It has been an honor to work in this role in such a central

Re: [Development] Missing documentation in Qt 5.12

On Wed, Dec 19, 2018 at 12:38:48PM +, Martin Smith wrote: > I found the problem. > > There are a few ways I can fix it. Which is preferred. > > 1. Simply merge the inherited members into the list that is already there. > 2. Merge the inherited members into the list but qualified with their ba

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

On Tue, Jan 15, 2019 at 10:44:45PM +0100, Allan Sandfeld Jensen wrote: > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote: > > Hi, > > > > With every Qt release we see how the new release improved over previous > > releases in terms of speed, memory consumption, etc. > > > > Any chan

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

On Wed, Jan 23, 2019 at 05:40:33PM +0300, Konstantin Tokarev wrote: > 23.01.2019, 16:55, "Edward Welbourne" : > > All of this discussion ignores a major elephant: QString's indexing is > > by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode > > for a couple of decades now. > > > >

Re: [Development] Proposal: New branch model

On Wed, Jan 23, 2019 at 06:36:43PM +, Alex Blasche wrote: > At the end of the day each cherry-pick is a merge too and they can > conflict too. The conflict resolution process is still the same. if > everything is conflict free then a git merge would be no more > difficult than a cherry-pick. C

Re: [Development] Proposal: New branch model

On Mon, Jan 28, 2019 at 12:54:58PM +, Volker Hilsheimer wrote: > > Wouldn't we expect those external patchers to submit changes to dev > > only? Then the module maintainer, or an LTS version maintainer (is > > there a maintainer for each LTS version?) would decide whether the > > change should

Re: [Development] On deprecating functions

On Mon, Mar 04, 2019 at 05:51:08PM +0100, Christian Ehrlicher wrote: > Hi, > > I recently introduced some new signals > (Q(Double)SpinBox::textChanged, QComboBox::textActivated) as > replacements for old ones to be able to avoid the use of > QOverload<>::of in Qt6 and to better match their respect

Re: [Development] On deprecating functions

On Mon, Mar 04, 2019 at 12:21:09PM -0800, Thiago Macieira wrote: > On Monday, 4 March 2019 10:46:00 PST Christian Ehrlicher wrote: > > You know what happens in this case - nothing since noone > > notices... see all the usages of deprecated functions within > > QtBase which have been unrecognized fo

Re: [Development] On deprecating functions

On Mon, Mar 04, 2019 at 03:12:33PM -0800, Thiago Macieira wrote: > On Monday, 4 March 2019 13:48:25 PST André Pönitz wrote: > > The proposed model would effectively introduce another user-visible > > level including associated period of time between "alternative > > so

Re: [Development] On deprecating functions

On Mon, Mar 04, 2019 at 03:18:16PM -0800, Thiago Macieira wrote: > On Monday, 4 March 2019 13:27:42 PST André Pönitz wrote: > > Truly personally, I'd even go for > > "no deprecation at all *for purely cosmetical reasons*" as I've seen > > too many taking

Re: [Development] CMake branch

On Thu, Mar 21, 2019 at 03:06:18PM +, Mikhail Svetkin wrote: > > I find it hard to believe that this improves the quality of Qt 5.14 or 5.15. > > Effectively you are proposing that we don't have any blocking CI for those > > two > > Qt releases. Otherwise you would have to implement very intri

Re: [Development] A deployment tool for Linux

On Wed, Apr 10, 2019 at 08:13:01AM +, Mitch Curtis wrote: > What do people think about having a deployment tool for Linux? I, as a person, think that a "deployment tool for Linux" is something that spits out packages in half a dozen "native" distribution package formats. Collecting "resource

Re: [Development] A deployment tool for Linux

On Wed, Apr 10, 2019 at 09:44:45PM +0300, Konstantin Tokarev wrote: > 10.04.2019, 21:38, "André Pönitz" : > > On Wed, Apr 10, 2019 at 08:13:01AM +, Mitch Curtis wrote: > >>  What do people think about having a deployment tool for Linux? > > > > I, as a p

Re: [Development] Qt 5.13.0 Beta2 released

On Tue, Apr 16, 2019 at 08:39:32PM +0300, NIkolai Marchenko wrote: > you are using gmail so it's trivially simple to set up a filter that will > automatically junk all the mail from this mailing list That's bad advice. Proper advice is contained in each and every email send to the list: List-Uns

Re: [Development] Qt online SDK security problems

On Thu, Apr 18, 2019 at 10:24:24AM +0300, BogDan Vatra via Development wrote: > Hi, > > Long time ago the Qt online SDK used to help the users to use the > latest and the safest Qt version all the time. There is no latest *and* safest version of any non-trivial code base that's under active f

Re: [Development] Qt online SDK security problems

On Thu, Apr 18, 2019 at 10:24:24AM +0300, BogDan Vatra via Development wrote: > [...] > As I commented in > https://blog.qt.io/blog/2019/04/11/updated-qt-installer-released/, > as a Qt maintainer, I wonder quite often, if it's worth to spend > time to fix bugs that will go in revision/micro

Re: [Development] Qt Static Package

On Fri, Apr 26, 2019 at 03:42:17PM -0400, Carlos Enrique Pérez Sánchez wrote: > I'm using qmake because there is not Qbs option in Qt 5.12 (at least on > Linux, opensource license). I have difficulties to follow here. Could you expand? I.e. why is QBS not an option, how is that related to a spec

Re: [Development] unique_ptr and Qt, Take 2

On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote: > > On 6 May 2019, at 09:30, Christian Kandeler > > wrote: > > > > On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen > > wrote: > > > >> On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: > >>> On Friday, 3 May 2019 13

Re: [Development] FP calculations and stability in Qt

On Mon, May 13, 2019 at 12:53:42PM +0300, Konstantin Shegunov wrote: > On Mon, May 13, 2019 at 12:42 PM Konstantin Ritt wrote: > > > Writing and proposing a patch would take less time than discussing pros > > and cons here. > > Which I had in a minute fraction done, as a pass-by in the comments.

Re: [Development] Views

On Thu, May 16, 2019 at 06:31:13PM +, Paolo Angelelli wrote: > i think you and alex stephanov are wrong. if QMap API is convenient, > but does not perform for the few elements use case, optimize QMap for > that use case, And then everybody else pays with cycles for the detection of the special

Re: [Development] What's the status of a moved-from object?

On Mon, May 20, 2019 at 01:56:56PM +, Lars Knoll wrote: > > On 20 May 2019, at 14:51, Mutz, Marc via Development > > wrote: > > > > On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote: > >> Hi, Il 19/05/19 18:54, Thiago Macieira ha scritto: > >>> But I think all Qt classes should go

Re: [Development] Views

On Fri, May 17, 2019 at 07:47:55AM +0200, Mutz, Marc via Development wrote: > On 2019-05-16 23:41, Konstantin Shegunov wrote: > > you end up where the STL is - so convoluted it's hardly worth making > > anything with it. > > Qt is a C++ library. If you don't like C++, either stay in QML or use Jav

Re: [Development] Views

On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote: > [...] There is no readability difference between the use of a Qt container and > that of an STL container. Exhibit A: foo().contains(x) Exhibit B: { ... container = foo(); std::find(contai

Re: [Development] Views

On Mon, May 20, 2019 at 08:44:47PM +, Marco Bubke wrote: > On May 20, 2019 22:16:11 André Pönitz wrote: > > > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote: > >> [...] There is no readability difference between the use of a Qt container >

Re: [Development] Views

On Mon, May 20, 2019 at 10:48:29PM +0200, Mutz, Marc via Development wrote: > On 2019-05-20 22:18, André Pönitz wrote: > > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development > > wrote: > > > [...] There is no readability difference between the use of

Re: [Development] What's the status of a moved-from object?

On Mon, May 20, 2019 at 11:58:49PM +0300, Konstantin Shegunov wrote: > I agree as well, although I have a minor nitpick. Q_ASSERT works only if it > was not stripped while building Qt. Meaning that I'm often working, as I'm > sure other users, on Linux especially, with the default (i.e. release) >

Re: [Development] Views

On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development wrote: > On 2019-05-20 23:21, André Pönitz wrote: > > > > Exhibit A: > > > > > > > > foo().contains(x) > > > > > > > > > > > > Exhibit B: > >

Re: [Development] Views

On Tue, May 21, 2019 at 08:32:07AM +0200, Mutz, Marc via Development wrote: > > By that line of reasoning, the change from > >Q3Slider *sl = new Q3Slider(0, 100, 50, 10, 1, this); > > to > >Q4Slider *sl = new Q4Slider(this); >sl->setRange(0, 100); >sl->setValue(50); >sl->set

Re: [Development] Views

On Tue, May 21, 2019 at 04:41:42PM +0300, Danila Malyutin wrote: > Exhibit C: > > foo().contains(x) > > https://godbolt.org/z/KlIcFc -std=c++2a But yes, I am aware of that, and I am perfectly happy with the tendency to chose practically sensible approaches in Standard C++ for a while now. Bu

Re: [Development] QList for Qt 6

On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote: > > > 22.05.2019, 19:38, "Philippe" : > >>  People tend to use QList as a deque because of the fast prepend/take first > > > > Simply, QArrayList should not be deprecated. > > It is also useful to store large objects that needs t

Re: [Development] QList for Qt 6

On Wed, May 22, 2019 at 09:02:13PM +0300, Konstantin Tokarev wrote: > > > 22.05.2019, 20:55, "André Pönitz" : > > On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote: > >>  22.05.2019, 19:38, "Philippe" : > >>  >>  Peop

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

On Wed, May 29, 2019 at 02:44:31PM +0200, Mutz, Marc via Development wrote: > On 2019-05-29 13:52, Konstantin Tokarev wrote: > > 29.05.2019, 13:56, "Mutz, Marc via Development" > > : > > > Hi, > > > > > > Here's a list of stuff I consider has served it's purpose and is no > > > longer needed, with

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

On Fri, May 31, 2019 at 11:22:03AM +0200, Tobias Hunger wrote: > Hi Thiago, > > On Thu, May 30, 2019 at 8:18 PM Thiago Macieira > wrote: > > On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development > > wrote: > > > 2) should QRegExp stay in bootstrap? I have no idea of what's happ

Re: [Development] Deprecation/removal model going into Qt 6

On Fri, May 31, 2019 at 02:50:45PM +0200, Giuseppe D'Angelo via Development wrote: > I guess that the idea is that the port to Qt 6 can then happen in multiple > steps: > > 1) port to Qt 5.latest; > 2) (enable and) fix all deprecation warnings; > 3) port to Qt 6. > If this is still the plan, I m

Re: [Development] Deprecation/removal model going into Qt 6

On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote: > The overall goal here is to make sure that we don’t have to carry > poorly designed architecture or APIs around with us throughout the Qt > 6 series, and as long as we care about binary and source compatibility > within a major se

Re: [Development] Deprecation/removal model going into Qt 6

On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote: > = The meaning of deprecation > > I think of deprecation as a means to tell users that the designers of the > deprecated API think that there is some deep flaw in the API that makes it > harder to use correctly or easier

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

On Tue, Jun 04, 2019 at 09:58:18PM -0700, Thiago Macieira wrote: > On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote: > > You talk about a particular incarnation of stdlibs, I was talking about > > the general case. Yes, in the case you describe, and _if_ libc++ is > > configure

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

On Wed, Jun 05, 2019 at 01:41:25PM +0200, Mutz, Marc via Development wrote: > On 2019-06-05 10:40, Edward Welbourne wrote: > [...] > > If some things are deprecated and never removed (QRegEx springs to > > mind), while others get removed (comparably) soon after deprecation > > (e.g. everything we'r

Re: [Development] Views

Иван Комиссаров wrote: > I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should > perform well. > Take a look at Qt Item Views. They really sucks in terms of performance. > QAbstractItemModel can have any number of rows/columns (that fits in MAX_INT), > but which view can r

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

On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development wrote: > On 05/06/2019 23:01, André Pönitz wrote: > > As a matter of fact, some of the previous deprecations, e.g. the removal > > of qalgorithm, triggered re-implementing the deprecated function

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

On Sat, Jun 08, 2019 at 10:39:09PM +0300, Konstantin Tokarev wrote: > > What about https://valdyas.org/fading/hacking/happy-porting/ > > > >    "[...] none, not a single one of all of the reasons you want to > > deprecate    Q_FOREACH is a reason I care even a little bit about. > > It’s going to   

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

On Sun, Jun 09, 2019 at 12:30:23AM +0200, Иван Комиссаров wrote: > No, they should not. > > C++ committee understands the problem of ugly iterators and it seems they > have a solution - ranges. > > Why do you want to use qSort instead of std::ranges::sort? Because the compiler might not suppor

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

On Sun, Jun 09, 2019 at 10:10:36AM +0200, Allan Sandfeld Jensen wrote: > On Sonntag, 9. Juni 2019 00:09:30 CEST Kevin Kofler wrote: > > QtAlgorithms should just be undeprecated. I don't care whether std::sort is > > faster. If the version of Qt I tested with was fast enough, then I'm > > perfectly

Re: [Development] Views

On Tue, Jun 11, 2019 at 11:42:32AM +0300, Konstantin Shegunov wrote: > On Tue, Jun 11, 2019 at 11:31 AM Ulf Hermann wrote: > > > I imagine that a vector which automatically sorts itself on the first > > lookup after any changes if it's larger than X items could be a drop-in > > replacement for mo

Re: [Development] How to port from Q_FOREACH to range-based for

On Tue, Jun 11, 2019 at 11:49:11AM +0200, Giuseppe D'Angelo wrote: > On 11/06/2019 09:17, Lars Knoll wrote: > > So, is removing it worth all the hassle to us and our users? Q_FOREACH is > > a macro and it doesn’t really cost us anything to keep it around. Yes, it > > has issues with non Qt containe

Re: [Development] How to port from Q_FOREACH to range-based for

On Tue, Jun 11, 2019 at 08:47:12PM +0200, Mutz, Marc via Development wrote: > On 2019-06-11 09:48, Lars Knoll wrote: > > > On 11 Jun 2019, at 09:35, Olivier Goffart wrote: > > > > > > On 11.06.19 09:17, Lars Knoll wrote: > > > > So, is removing it worth all the hassle to us and our users? > > > >

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

On Tue, Jun 11, 2019 at 12:36:12AM +0200, Giuseppe D'Angelo via Development wrote: > Il 10/06/19 23:45, Kevin Kofler ha scritto: > > Perhaps you forgot to read the part where I said: > > > > > I, for one, don't give a darn about all those new C++11/14/whatever STL > > > features. > > That's a st

Re: [Development] How to port from Q_FOREACH to range-based for

On Thu, Jun 20, 2019 at 08:44:40AM +, Frederik Gladhorn wrote: > On tirsdag 11. juni 2019 09:48:00 CEST Lars Knoll wrote: > > > On 11 Jun 2019, at 09:35, Olivier Goffart wrote: > > > > > > On 11.06.19 09:17, Lars Knoll wrote: > > > > > >> So, is removing it worth all the hassle to us and our

Re: [Development] Assistant WebKit/WebEngine support

On Fri, Jun 21, 2019 at 01:05:32PM +, Simon Hausmann wrote: > Would we provide a menu in the start menu for "Qt documentation" that > would launch the web server and then the user preferred web browser with > that url? How is the server terminated? > > > Either way, this requires developing

Re: [Development] Assistant WebKit/WebEngine support

On Fri, Jun 21, 2019 at 01:42:16PM +, Volker Hilsheimer wrote: > Personally I think the “external browser”, as in “the browser that I > read all other development documentation in”, should be a first choice > for displaying Qt documentation. Personally I think a combination of “external browse

Re: [Development] Assistant WebKit/WebEngine support

On Mon, Jun 24, 2019 at 04:37:16PM +0300, Konstantin Tokarev wrote: > > I have two more numbers to add: Compressed (7z) the download size would > > be around ~44 MB. I measured on Windows with a Qt Creator built with > > WebEngine support and surfed a little through the docs. The memory > > consump

Re: [Development] Assistant WebKit/WebEngine support

On Mon, Jun 24, 2019 at 01:49:12PM +, Palaraja, Kavindra wrote: > +1, because: > > * It's 2019, we need to change with the times as documentation, especially > how content looks and feels, has come really far from those days. > * Almost 1:1 appearance of documentation in Creator vs. Browser.

Re: [Development] Assistant WebKit/WebEngine support

On Tue, Jun 25, 2019 at 10:52:29AM +0300, Konstantin Tokarev wrote: > > It worked up to a certain degree nicely in the build system by > > de-selecting options, than quite a bit more by actually removing code. > > Getting rid of all of JS was not obviously possible. > > Removing code makes result

Re: [Development] Assistant WebKit/WebEngine support

On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote: > > On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote: > > > > Pardon my lingo, > > You should be able to communicate your points without that kind of lingo. Try > better. > > > It is documentation for developers for crying out lou

Re: [Development] Assistant WebKit/WebEngine support

On Tue, Jun 25, 2019 at 08:58:07PM +, Tor Arne Vestbø wrote: > > > > On 25 Jun 2019, at 22:53, André Pönitz wrote: > > > > On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote: > >>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote: > >

Re: [Development] Assistant WebKit/WebEngine support

On Thu, Jun 27, 2019 at 01:47:32AM +, Lars Knoll wrote: > Yes, Webengine uses some memory. But is that really a problem on > developer machines? On three out of four machines that I use with Qt Creator regularly have limitations that make the presence of WebEngine undesirable. These three mig

Re: [Development] Assistant WebKit/WebEngine support

On Thu, Jun 27, 2019 at 06:57:08AM +0200, Richard Weickelt wrote: > Is it well known, how many QtCreator users are even using the integrated > help functionality? How many Qt users are using QtAssistant and how many > prefer the online documentation? The exact numbers are not known (to me), but th

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

On Fri, Jun 28, 2019 at 09:32:43AM +, Cristian Adam wrote: > Hi, > > Some of you might have been familiar with white papers such as Qt QML v HTML5 > – > a practical > comparison. > > Qt Creator a

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

On Fri, Jun 28, 2019 at 11:37:57AM +, Cristian Adam wrote: > > -Original Message- > > From: André Pönitz > > Sent: Friday, 28 June 2019 13:23 > > To: Cristian Adam > > Cc: development@qt-project.org > > Subject: Re: [Development] HTML5/CSS

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

On Fri, Jun 28, 2019 at 11:25:27AM +, Jedrzej Nowacki wrote: > On Friday, June 28, 2019 11:32:43 AM CEST Cristian Adam wrote: > > Hi, > > > > Some of you might have been familiar with white papers such as Qt QML v > > HTML5 – a practical > > comparison

Re: [Development] Moving to Gerrit 2.16.9

On Mon, Jul 01, 2019 at 02:43:43PM +, Frederik Gladhorn wrote: > > > and I'll give Gravatar a spin: > > > https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravata > > > r > > It's there, enjoy and put your avatar up at https://gravatar.com . I know it's a bit late and it won

Re: [Development] char8_t summary?

On Wed, Jul 10, 2019 at 11:29:15AM +0200, Mutz, Marc via Development wrote: > On 2019-07-10 10:50, Arnaud Clere wrote: > > Hi all, > > > > So, do I understand correctly that: > > 1. QUtf8String may be required in Qt7 to solve problems due to C++2x > > char8_t > > I wouldn't say required. I also d

Re: [Development] char8_t summary?

On Wed, Jul 10, 2019 at 10:01:04PM -0300, Thiago Macieira wrote: > On Wednesday, 10 July 2019 09:55:02 -03 André Pönitz wrote: > > As far as I understand there's a perceived need to have "full" utf8 > > literals, and there's a need to have ASCII literals. Firs

Re: [Development] char8_t summary?

On Sun, Jul 14, 2019 at 08:28:58AM +0200, Mutz, Marc via Development wrote: > > As I understood the template suggestion, it’s more about not having to > > add 64 different overloads (or several more string classes) to the Qt > > API, and less about unifying all implementations into a single set of

Re: [Development] Request a new branch for Qt Creator

On Mon, Aug 05, 2019 at 10:35:37AM +, Stottlemyer, Brett (B.S.) wrote: > Hi, Hi Brett. > I’d like to request a new branch (“acme”) on QtCreator. Would it be possible to use a less overloaded name? After a bit of search I think I get now what it refers to, but it surely was not my first gu

Re: [Development] Request a new branch for Qt Creator

d require significant > development effort to replicate independently. Such context is always good. > On 8/5/19, 1:39 PM, "André Pönitz" wrote: > Would it be possible to use a less overloaded name? After a bit of > search I think I get now what it refers to, but it surely was

Re: [Development] HEADS-UP: QStringLiteral

On Wed, Aug 21, 2019 at 10:01:29AM +, Tor Arne Vestbø wrote: > > On 21 Aug 2019, at 11:50, Bogdan Vatra via Development > > wrote: > > > > Am I the only one which finds situations silly ? Of course there are more > > examples > > with the other String wrappers/functions in Qt, but I think is

Re: [Development] HEADS-UP: QStringLiteral

On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote: > I'm sorry if I sound blunt, but this is just nonsense. What you call > optimisation, isn't. Using QStringLiteral or QLatin1String is equally > readable. As is just using "". I am not sorry to sound blunt here, but callin

  1   2   3   4   5   >