Re: [Development] Assistant WebKit/WebEngine support

25.06.2019, 10:48, "André Pönitz" : > 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 >

Re: [Development] Assistant WebKit/WebEngine support

24.06.2019, 15:46, "Simon Hausmann" : > Am 24.06.19 um 12:31 schrieb Eike Ziller: >>>  * What exactly is so big about WebEngine? What is this size that many are >>> hinting at but won't provide the number? >>  My numbers on macOS: >> >>  WebEngineCore.framework = 145 MB >>  Current Qt Creator

Re: [Development] Assistant WebKit/WebEngine support

24.06.2019, 12:23, "Eike Ziller" : >>  On 24. Jun 2019, at 08:20, Palaraja, Kavindra wrote: >> >>  Hi Andre, >> >>  I'm really curious -- why is it bad to make WebEngine mandatory for >> anything that passes as "Qt Creator's Help Integration”? > > - QtWebEngine is a big beast > - and browsing

Re: [Development] Assistant WebKit/WebEngine support

21.06.2019, 17:36, "Simon Hausmann" : > Am 21.06.19 um 15:42 schrieb Volker Hilsheimer: >>>  To me it seems easier to solve this first by making the Qt Assistant use >>>  WebEngine and when we later have a better doc "frontend" (as web app) >>>  switch to that and potentially an external

Re: [Development] Assistant WebKit/WebEngine support

21.06.2019, 17:06, "Bastiaan Veelo" : > On 21/06/2019 15:47, Konstantin Tokarev wrote: >>  21.06.2019, 16:40, "Bastiaan Veelo" : >>>  On 21/06/2019 14:57, Volker Hilsheimer wrote: >>>>    I’m not Jarek, but I recall that Eddy made a suggest

Re: [Development] Assistant WebKit/WebEngine support

21.06.2019, 16:40, "Bastiaan Veelo" : > On 21/06/2019 14:57, Volker Hilsheimer wrote: >>  I’m not Jarek, but I recall that Eddy made a suggestion [1] which I >>  think has been prematurely dismissed or at least not been discussed >>  sufficiently, which is: >> >>  * move the Qt Assistant

Re: [Development] Assistant WebKit/WebEngine support

21.06.2019, 16:07, "Simon Hausmann" : > Am 21.06.19 um 14:57 schrieb Volker Hilsheimer: >>>  On 21 Jun 2019, at 11:08, Bastiaan Veelo >>  > wrote: >>> >>>  On 21/05/2019 12:24, Kai Köhne wrote: >  -Original Message- >  From: Development  

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

17.06.2019, 19:09, "Konstantin Tokarev" : > 17.06.2019, 18:43, "Thiago Macieira" : >>  On Monday, 17 June 2019 08:16:38 PDT Konstantin Tokarev wrote: >>>   17.06.2019, 18:15, "Thiago Macieira" : >>>   > On Monday, 17 June

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

17.06.2019, 19:08, "Bogdan Vatra" : > [...] >>  > >>  > [...] >>  > >>  > Are you seriously thinking that Qt is going to use scripts from some >>  > random >>  > github projects ?!?!? >> >>  There is a choice: with cmake you either spend hours yourself developing >>  stuff, or reuse results of

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

17.06.2019, 19:08, "Bogdan Vatra" : > [...] >>  > >>  > [...] >>  > >>  > Are you seriously thinking that Qt is going to use scripts from some >>  > random >>  > github projects ?!?!? >> >>  There is a choice: with cmake you either spend hours yourself developing >>  stuff, or reuse results of

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

17.06.2019, 18:43, "Thiago Macieira" : > On Monday, 17 June 2019 08:16:38 PDT Konstantin Tokarev wrote: >>  17.06.2019, 18:15, "Thiago Macieira" : >>  > On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote: >>  >> I think that

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

17.06.2019, 18:51, "Bogdan Vatra via Development" : > Hi, > > [...] >>  > qnx >> >>  you mean like software companies using Qt do, today ? >>  https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake >>  > vxworx >> >>  VxWorks ships with CMake so there must be at least some

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

17.06.2019, 18:17, "Matthew Woehlke" : > On 17/06/2019 08.44, Konstantin Tokarev wrote: >>  Also, are you trying to say that cmake's configuration system is >>  more user friendly than Qt's configure > > Yes. Very much so. > >>  (or for, that matter

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

17.06.2019, 18:15, "Thiago Macieira" : > On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote: >>  I think that automatic generation of PCH is a bad idea, leading to wasting >>  build time. > > Like we do in Qt today? Yep. Approach of Qt Creator is much b

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

17.06.2019, 12:48, "Mark De Wit" : >>  -Original Message- >>  From: Development On Behalf Of >>  Konstantin Tokarev >>  Sent: 06 June 2019 14:30 >>  To: Simon Hausmann ; Bogdan Vatra >>  ; development@qt-project.org >>  Subject: Re:

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

17.06.2019, 12:15, "Christian Gagneraud" : > On Mon, 17 Jun 2019, 21:13 Konstantin Tokarev, wrote: >> 17.06.2019, 12:07, "Christian Gagneraud" : >>> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik, wrote: >>>> Den mån 17 juni 2019 kl 09:12 skrev Chr

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

17.06.2019, 12:07, "Christian Gagneraud" : > On Mon, 17 Jun 2019, 20:15 Elvis Stansvik, wrote: >> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud : >>> >>> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, wrote: On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:

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

15.06.2019, 05:29, "Thiago Macieira" : > I wonder if Assistant as a standalone application still makes sense. Do we have another standalone qch viewer application? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

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

16.06.2019, 00:22, "Thiago Macieira" : > On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote: >>  > Why must they be built in one go? Why can't they be separate builds >>  > stitched together? Or even completely separate builds as on Linux and all >>  > the other Unix? >>

Re: [Development] unique_ptr and Qt, Take 2

14.06.2019, 00:14, "Christian Ehrlicher" : > Am 13.06.2019 um 22:09 schrieb Ville Voutilainen: >>>  That's one of the things I love about Qt; object hierarchies give me >>>  working dynamic memory management without needing even smart pointers. >>  That's the one thing that makes me queasy about

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

10.06.2019, 14:48, "Giuseppe D'Angelo" : > (Changing the subject to be on topic) > > On 10/06/2019 13:27, Konstantin Tokarev wrote: >>>  At the cost of saying for the 100th time, before this stuff ends up >>>  indexed by Google: you can port away from Q_

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

10.06.2019, 13:10, "Giuseppe D'Angelo" : > On 08/06/2019 21:39, Konstantin Tokarev wrote: >>>  What abouthttps://valdyas.org/fading/hacking/happy-porting/ >>> >>>  "[...] none, not a single one of all of the reasons you want to >>>

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

09.06.2019, 01:26, "Konstantin Tokarev" : > 09.06.2019, 01:02, "Kevin Kofler" : >>  Giuseppe D'Angelo via Development wrote: >>>   In other words, the advantages of keeping the Qt equivalents start to be >>>   (seriously) questioned. We're there

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

09.06.2019, 01:02, "Kevin Kofler" : > Giuseppe D'Angelo via Development wrote: >>  In other words, the advantages of keeping the Qt equivalents start to be >>  (seriously) questioned. We're therefore left with the question of what >>  to do with these equivalents. >> >>  * We could play the

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

08.06.2019, 19:16, "Giuseppe D'Angelo via Development" : > 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 functionality >>  downstream, effectively shifting the

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

08.06.2019, 21:33, "André Pönitz" : > 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

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

06.06.2019, 17:01, "Lars Knoll" : >> On 6 Jun 2019, at 15:33, Иван Комиссаров wrote: >> >> Sorry, but the iOS should be properly supported before making the final >> decision. >> Building something on macOS is easy, building smth for iOS is harder. From >> the top of my head it is code

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

06.06.2019, 16:25, "Simon Hausmann" : > Hi, > > 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. Yet another

Re: [Development] Views

06.06.2019, 15:43, "Elvis Stansvik" : > Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik : >>  Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development >>  : >>  > >>  > On 2019-06-06 12:24, Lars Knoll wrote: >>  > >> On 6 Jun 2019, at 11:08, Simon Hausmann >>  > >> wrote: >>  > >> >>  

Re: [Development] Configure command lines of official Qt releases

06.06.2019, 11:12, "Richard Weickelt" : > On 05.06.2019 21:28, Иван Комиссаров wrote: >>  AFAIK -R . is used to load that icu libraries I told you about in Gerrit. >> >>  Otherwise it will try to load the system ones instead of the shipped ones >> with Qt. > > Thanks, Ivan. While this is true

Re: [Development] Gerrit: Sanity-Review is lost after moving changes

04.06.2019, 19:40, "André Hartmann" : > Hi all, > > I just stumbled about the problem, that the new Gerrit removes the > sanity review vote after a change was moved to a new destination branch. > > While it's probably good to remove code review votes on branch change, > the sanity review should

Re: [Development] Configure command lines of official Qt releases

04.06.2019, 17:01, "Volker Hilsheimer" : >> 04.06.2019, 16:41, "Volker Hilsheimer" : On 3 Jun 2019, at 20:15, Elvis Stansvik wrote: Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik : > Hi Richard, > > I think this was asked on the interest list back in January [1].

Re: [Development] Configure command lines of official Qt releases

04.06.2019, 16:41, "Volker Hilsheimer" : >> On 3 Jun 2019, at 20:15, Elvis Stansvik wrote: >> >> Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik : >>> Hi Richard, >>> >>> I think this was asked on the interest list back in January [1]. >>> >>> The answer is here: >>> >>>

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

03.06.2019, 21:01, "Thiago Macieira" : > On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote: >>  03.06.2019, 09:06, "Thiago Macieira" : >>  > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >>  >> I also managed

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

04.06.2019, 04:41, "Thiago Macieira" : > On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote: >>  This script takes a hideously enormous amount of time to run. I hope it's >>  because that's just a really long line. Found this script that seems to >>  break every 16 bytes: >>  

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

03.06.2019, 09:06, "Thiago Macieira" : > 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 > > Yup,

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

03.06.2019, 02:10, "Manuel Bergler" : > Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler > : > >>  What you call "obsolete functionality" is functionality that existing code >>  relies on and rightfully expects to remain there. >> >>  I'd rather get fewer (or even no) new features than

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

02.06.2019, 17:30, "Jean-Michaël Celerier" : >>  If existing package of application cannot be rebuilt from source with >>updated > Qt version, it's a sure no-go for distibution. Either Qt update will be > blocked, or > application will be thrown away (or application will be somehow patched by

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

02.06.2019, 17:03, "Manuel Bergler" : > Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev > : >>  02.06.2019, 16:34, "Manuel Bergler" : >>  > Due to Hyrum's law [0], even with stricter guarantees there will >>  > always be someone f

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

02.06.2019, 16:34, "Manuel Bergler" : > Due to Hyrum's law [0], even with stricter guarantees there will > always be someone for which migration is a non-trivial amount of work. > The only way to avoid that is to change nothing, ever. I personally > also don't understand why people would expect

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

31.05.2019, 12:37, "Tobias Hunger" : > On Fri, 2019-05-31 at 01:37 +0300, Konstantin Tokarev wrote: >>  > I understand, but aside from qmake, I don't know of any build system that >>  > allows for building both host and target in the same build. That means >&

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

31.05.2019, 00:57, "Thiago Macieira" : > On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote: >>  > 3) all tools in cross builds link to a host QtCore that must be >>  > preinstalled Preferably, reuse the tools from that host build instead of >>

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

31.05.2019, 00:57, "Thiago Macieira" : > On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote: >>  > 3) all tools in cross builds link to a host QtCore that must be >>  > preinstalled Preferably, reuse the tools from that host build instead of >>

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

31.05.2019, 00:19, "Thiago Macieira" : > On Thursday, 30 May 2019 11:43:54 PDT Konstantin Tokarev wrote: >>  Does it mean that moc will be reimplemented to avoid using Qt classes? > > No, but moc should be the only bootstrapped tool. My point is that we should >

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

30.05.2019, 21:18, "Thiago Macieira" : > 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 happening >>  regarding to that in Qt 6. > > Bootstrap needs to go away in Qt 6. Does it mean that moc

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

29.05.2019, 15:52, "Mutz, Marc via Development" : > 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 purp

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

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 respective replacements: > > = Priority 1 = > > == QSharedDataPointer / QExplicitlySharedDataPointer == It seems like you've forgotten migration

Re: [Development] Proposal: Using Gerrit for new approver proposals?

  22.05.2019, 15:54, "Florian Bruhin" :> On Wed, May 22, 2019 at 08:09:59AM +, Alex Blasche wrote:>>  It is readable for all just not editable: https://codereview.qt-project.org/admin/groups/12,members>> What's up with "removed " in that list? It sounds like the> user isn't interested in

Re: [Development] Gerrit is back

24.05.2019, 10:07, "Jukka Jokiniva" : > About contribution to Gerrit, > > Our Gerrit customization has two parts: >   * Most of the logic is in a qt specific plugin which is hosted at > https://codereview.qt-project.org/gitweb?p=qtqa/gerrit-plugin-qt-workflow.git >   * Then we have some forks

Re: [Development] QList for Qt 6

24.05.2019, 14:27, "Konstantin Tokarev" : > Actually, clazy provides related checks "inefficient-qlist". I think > following plan can work: > > 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy > which finds QList > w

Re: [Development] QList for Qt 6

24.05.2019, 13:32, "Konstantin Tokarev" : > 24.05.2019, 13:06, "NIkolai Marchenko" : >>  All of the back and forth on this issue recently and over the years really >> make want to ask this question: >> >>  Is the promise of SC worth all the p

Re: [Development] QList for Qt 6

24.05.2019, 13:06, "NIkolai Marchenko" : > All of the back and forth on this issue recently and over the years really > make want to ask this question: > > Is the promise of SC worth all the potenital pitfalls? There seems to be no > end to the discussion with every solution requiriring hair

Re: [Development] Qt XML and Qt Xml Patterns

24.05.2019, 12:44, "Kai Köhne" : >>  -Original Message- >>  From: Development On Behalf Of >>  Bernhard Lindner >>  Subject: Re: [Development] Qt XML and Qt Xml Patterns >> >>  > It's good that Bernhard has received an official statement. >> >>  I agree! Thank you! > > Indeed, thanks

Re: [Development] QList for Qt 6

22.05.2019, 21:19, "Giuseppe D'Angelo" : > Il 22/05/19 20:14, Konstantin Tokarev ha scritto: >>>>    FWIW, std::deque is implemented as a peculiar data strucutre which is >>>> not really contiguous, and it may perform worse than QList in certain cases >&g

Re: [Development] QList for Qt 6

22.05.2019, 21:10, "Giuseppe D'Angelo via Development" : > Il 22/05/19 18:32, Konstantin Tokarev ha scritto: >>>  What about fast prepend in that case? People tend to use QList as a deque >>> because of the fast prepend/take first >>  FWIW, std::de

Re: [Development] QList for Qt 6

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" : >>  >>  People tend to use QList as a deque because of the fast prepend/take >> first >>

Re: [Development] QList for Qt 6

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 to be sorted. In the latter QList can be replaced with std::vector> or QVector>

Re: [Development] QList for Qt 6

22.05.2019, 19:28, "Иван Комиссаров" : >> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) >> and Foo is movable > > What about fast prepend in that case? People tend to use QList as a deque > because of the fast prepend/take first FWIW, std::deque is implemented as a

Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)

21.05.2019, 19:03, "Bastiaan Veelo" : > [skipping many interesting points, sorry] > > On 21/05/2019 16:06, Shawn Rutledge wrote: >>  Anyway I think Assistant is one of those cases where I would prefer to >>  keep using QTextBrowser and fix it up a bit more to suit, rather than >>  switching to a

Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)

21.05.2019, 18:01, "Jean-Michaël Celerier" : >> (of all Qt applications, only a minority use either QSS or CSS) > > Are there sources for that ? From what I can see it has plenty of usage. > https://github.com/search?l=C%2B%2B=setStyleSheet=Code Also, it's possible to start any Qt application

Re: [Development] Assistant WebKit/WebEngine support

21.05.2019, 15:47, "Bastiaan Veelo" : > On 20/05/2019 19:02, Konstantin Tokarev wrote: >>  20.05.2019, 19:58, "Bastiaan Veelo" : >>>  On 20/05/2019 17:56, Konstantin Tokarev wrote: >>>>    20.05.2019, 18:27, "Bastiaan Veelo&qu

Re: [Development] Assistant WebKit/WebEngine support

20.05.2019, 19:58, "Bastiaan Veelo" : > On 20/05/2019 17:56, Konstantin Tokarev wrote: >>  20.05.2019, 18:27, "Bastiaan Veelo" : >>>  On 20/05/2019 16:51, Konstantin Tokarev wrote: >>>>    Note that it should be possible to rebuild QtTool

Re: [Development] Assistant WebKit/WebEngine support

20.05.2019, 18:27, "Bastiaan Veelo" : > On 20/05/2019 16:51, Konstantin Tokarev wrote: >>  20.05.2019, 16:02, "Bastiaan Veelo" : > > [...] >>>  Qt Assistant officially only renders content with QTextBrowser >>>  currently, which is too l

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

20.05.2019, 18:21, "Thiago Macieira" : > On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote: >>  I actually think we should consider getting rid of shared_null and instead >>  have d == nullptr as the null/default constructed state of the object. Yes, >>  that means we need to check for d ==

Re: [Development] Assistant WebKit/WebEngine support

20.05.2019, 16:02, "Bastiaan Veelo" : > Hi, > > I am prepared to do some work on Qt Assistant, and I'd like to know how > that will be received. > > Qt Assistant officially only renders content with QTextBrowser > currently, which is too limited for many of us[1]. There are still > traces of

Re: [Development] Views

17.05.2019, 00:44, "Konstantin Shegunov" : > User story: > The API is always going to rule supreme over any implementation detail or > efficiency. The API is what you present to the user, not the implementation. > The moment you start sacrificing good API, one that's fleshed out and >

Re: [Development] unique_ptr and Qt, Take 2

>> Can you explain what you mean with “understands the parent/child-ownership >> model”? >> >> Are you suggesting a unique_ptr-like template class that doesn’t destroy the >> object in its destructor if that object still has a parent? > > It could be something like that. One option could be to

Re: [Development] Gerrit Upgrade

Are we planning to use Polymer-based UI, as currently used by Chromium and Android, or the "old" one (which is probably still a default)? I believe "old" one has a horrible UX, while Polymer one is a bit nicer. Also, Polymer's patch viewer plays nicely with X selection buffer, while "old" does

Re: [Development] unique_ptr and Qt, Take 2

03.05.2019, 23:31, "Иван Комиссаров" : > By forcing usage of smart pointers, of course. > The moment you start writing > > QWidget w1; > QWidget w2; > w1.setParent(QObjectSmartPointer()); > > It’s time to stop and think if you’re doing the right thing=) It is possible > to pass an object on a

Re: [Development] Qt Static Package

26.04.2019, 22:47, "Carlos Enrique Pérez Sánchez" : >> This sounds very similar to what I saw with linuxdeployqt a while back > Currently, I can link dynamically on Linux (using qmake to generate the > makefile) and make a standalone executable with linuxdeployqt and it works > well. I do have

Re: [Development] Gitlab at qt.io

10.04.2019, 09:29, "Kari Oikarinen" : > On 9.4.2019 17.02, Richard Weickelt wrote: >>  Hi, >> >>  I would like to know more about https://git.qt.io >> >>  - What's the purpose and the future plan? > > It's an internal Gitlab instance for The Qt Company. It's mostly a place for > people to put

Re: [Development] A deployment tool for Linux

11.04.2019, 04:05, "Richard Weickelt" : > On 10.04.2019 23:21, Marco Bubke wrote: >>  Sounds you want flatpak. ;-) > > All those run-time extracted application container formats might be nice > solutions for GUI applications which is apparently the main target of Qt. > But my observation is that

Re: [Development] A deployment tool for Linux

10.04.2019, 23:09, "Konstantin Tokarev" : > 10.04.2019, 22:43, "Richard Weickelt" : >>  I would be interested to know how easy it is to release a >>  Qt-based application with a bleeding edge Qt version (or with a patched one) >>  to the official Debia

Re: [Development] A deployment tool for Linux

10.04.2019, 22:43, "Richard Weickelt" : > I would be interested to know how easy it is to release a > Qt-based application with a bleeding edge Qt version (or with a patched one) > to the official Debian repositories. The only possible way to add package to the official Debian repositories is

Re: [Development] A deployment tool for Linux

10.04.2019, 22:43, "Richard Weickelt" : > Nothing stops me from publishing a self-containing .deb, .rpm, .whatever on > my website. If there was a one stop shop tool that produces a collection > like this with very little effort: https://speedcrunch.org/download.html I > would be sold. Maybe

Re: [Development] A deployment tool for Linux

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 person, think that a "deployment tool for Linux" is > something that spits out packages in half a dozen "native" >

Re: [Development] QVariant container API

01.04.2019, 13:43, "Vasily Pupkin" : > Thanks for the answers. > >> I'm not sure I want to see more Datastream-based serialisation. The code >> there >> is too fragile and not compatible enough with standards. I recommend you >> reconsider and think about a more standard format. > > Just wanted

Re: [Development] Does iMX6 support EGL on X11 feature?

BTW, if your main concern is the performance of real-time plotting, it's extremely unlikely that you'll get better results on EGL/X11 than on EGLFS or EGL/Wayland. Note that you can use QWidgets on any of these platforms without restrctions. -- Regards, Konstantin

Re: [Development] Does iMX6 support EGL on X11 feature?

22.03.2019, 22:21, "Denis Shienkov" : > Yes, it was 'wayland'.. I tried with any options.. E.g. with X11 it fails as: > > main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to > 'EGLNativeDisplayType {aka _FBDisplay*}' in initialization >>  EGLNativeDisplayType egldpy =

Re: [Development] Does iMX6 support EGL on X11 feature?

22.03.2019, 19:11, "Denis Shienkov" : > Hi all, > > I'm trying to build a Yocto image, but the config tests fails on 'executing > config test egl-x11' test with: > >> In file included from main.cpp:7:0: >> main.cpp: In function 'int main(int, char**)': >> main.cpp:15:20: error: cannot convert

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

22.03.2019, 19:22, "Denis Shienkov" : > Hmmm.. thanks.. it is very bad... :( > > My goal it is to accelerate my QWidget application in some way... I use the > QWT library to render a curves.. > > That ~30% CPU loading occured even at a low "frame-rate" (about ~2 updates > per second)... But I

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

22.03.2019, 19:08, "Allan Sandfeld Jensen" : > On Freitag, 22. März 2019 12:46:59 CET Denis Shienkov wrote: >>  Hi guys. >> >>  I have iMX6 board with Qt 5.11.2 and Qt-widgets based application. I have >>  compiled my Qt with an 'xcb_native_painting' option. >> >>  I was hoping that this would

Re: [Development] Deprecating the static QProcess::startDetached() overloads

27.02.2019, 19:00, "Thiago Macieira" : > On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote: >>  Is it technically possible to start() and then detach()? > > No, because the way to start changes. The detached mode requires a double fork > and the actual detaching from the TTYs. > > You

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

25.01.2019, 23:33, "Thiago Macieira" : > On Friday, 25 January 2019 04:54:22 PST Edward Welbourne wrote: >>  we >>  fail to properly support cultures whose scripts are relegated to the >>  outer planes of Unicode - as, for example, the Chakma language's number >>  system > > All living languages

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

25.01.2019, 01:02, "Thiago Macieira" : > On Thursday, 24 January 2019 05:06:58 PST Konstantin Tokarev wrote: >>  I will be officially pissed off if possibility to access raw data of QString >>  without extra copy is gone It would be better if there is a way to figure

Re: [Development] Qt modules, API changes and Qt 6

25.01.2019, 18:11, "Allan Sandfeld Jensen" : > I think for something like qt6, I would like to suggest I think I have brought > up before in relation to testing qt5.git changes on more platforms or > configuations: A system for non blocking CI failures. > > In WebKit they what they called the

Re: [Development] Proposal: New branch model

24.01.2019, 17:13, "Jedrzej Nowacki" : > Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze: >>  On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote: >>  >> I think that’s fine. What’s much worse is having a fix in 5.12 and not >>  >> knowing how to deal with the

Re: [Development] Proposal: New branch model (part: new contributors)

24.01.2019, 17:09, "Ville Voutilainen" : > With the proposed model I push into trunk like in every other project. Why every other? Quite a few projects have different policies, e.g. in some of them master is always in more-or-less ready for release state and new changes go to staging branch

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

24.01.2019, 10:34, "Olivier Goffart" : > On 23.01.19 23:15, André Pönitz wrote: >>  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 elep

Re: [Development] Proposal: New branch model

23.01.2019, 21:38, "Alex Blasche" : >> >> From: Martin Smith >> If you make all patches in dev and then cherrypick them back to earlier >> versions that need them, why would you ever do a merge? > > At the end of the day each cherry-pick is a merge too

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

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. > > We *should* have a string type (I don't care what you call it) that acts >

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

15.01.2019, 23:13, "Alexander Akulich" : > Cristian, > > the previous discussion is "Why can't QString use UTF-8 internally?" > There is something wrong with our maillist, the best link I found is > [1]. For some reason link to the thread head [2] is broken. > > [1] >

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

15.01.2019, 21:45, "Cristian Adam" : > Hi, > > With every Qt release we see how the new release improved over previous > releases in terms of speed, memory consumption, etc. > > Any chance of having UTF-8 storage support for QString? > > UTF-8 is native on Linux and other *NIX platforms, Qt

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

16.01.2019, 00:46, "Allan Sandfeld Jensen" : > 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 chance of having UTF-8 storage

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

14.12.2018, 16:04, "Kevin Kofler" : > Also, do not understimate what CMake can do, especially with functions, > which make it theoretically Turing-complete. (That said, you might actually > want to restrict or ban the use of recursive (or all) functions in your > CMakeLists.txt coding style if

Re: [Development] QUIP 12: Code of Conduct

25.10.2018, 20:56, "Thiago Macieira" : > The Qt Project has no voting. Nitpick: there is voting in privilege revocation procedure. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

Re: [Development] QUIP 12: Code of Conduct

25.10.2018, 13:01, "NIkolai Marchenko" : >> And btw, we have had a clear majority in favour of adding a CoC at the >> Contributor Summit > > It seems very wrong to make such decisions at conventions where only a small > part of the contributors can participate. > Especially for something as

Re: [Development] Qt 6 buildsystem support requirements

02.08.2018, 19:50, "Thiago Macieira" : > On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote: >>  Unfortunately, Debian does not use cross-compilation for building packages > > Which is unfortunately the case for most (if not all) Linux distributions

Re: [Development] Qt 6 buildsystem support requirements

02.08.2018, 16:58, "Christian Kandeler" : > On Thu, 2 Aug 2018 10:23:12 -0300 > Lisandro Damián Nicanor Pérez Meyer wrote: > >>  El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió: >>  [snip] >>  > > > As for java in the loop - this is a a build system, how much does it >>  

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

31.07.2018, 21:35, "Иван Комиссаров" : > I prefer the solution from the thread "unique_ptr and Qt" about using smart > pointers for transferring ownership explicitly. We can use std::observer_ptr > from c++20 to indicate the places that do not take ownership. > I think, using gsl::owner is a

<    1   2   3   4   5   6   7   >