Re: [Development] Issues (temporary) with gerrit and code.qt.io

[Jukka Jokiniva]

Thanks for bringing this up,

It looks like when we finally got the sync to work yesterday, it has only been 
syncing new changes.
I just run a full sync and now everything should be uptodate.

Sorry for the delay.

 --Jukka


From: "Stottlemyer, Brett (B.S.)" 
Date: Tuesday, 21 May 2019 at 19.26
To: "'development@qt-project.org'" 
Cc: Jukka Jokiniva 
Subject: Issues (temporary) with gerrit and code.qt.io

Hi all,

Passing this one for general awareness.  I’ve been hit by 
https://bugreports.qt.io/browse/QTQAINFRA-2980.

The referenced issue is closed but with a note “I assume it will take awhile to 
finish.”  The symptoms, as I understand it, are that various mirrors are not 
current.

I was able to run `git pull` and get the current HEAD correctly from code.qt.io 
from the command line, but a coworker is only getting 
fa84f22bfd5500550f26f544f6905ac89e60716f (missing two commits).

This commit is 
listed as merged in Gerrit, but as of this moment, it isn’t listed in 
https://code.qt.io/cgit/qt/qtremoteobjects.git/log/.  The website’s log (like 
the `git pull` result) is a few commits behind.

Just an FYI in case others see the same issue.

Regards,
Brett
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

> I think both XML and XMLPatterns are Done, not Deprecated.

What a relief!

> Reasoning: only the former has an explicit note in the documentation 
> (can't find an equivalent for the latter):
> 
> > https://doc.qt.io/qt-5/qtxml-index.html
> > https://doc.qt.io/qt-5/qtxmlpatterns-index.html
> 
> But especially: neither is marked as deprecated in
> 
> > https://doc.qt.io/qt-5/qtmodules.html

Never noticed the "deprecated" tags.
Do you think a separate, more detailed status column would be useful for that 
table? Plus
Thiagos status explanations?

> So where and when exactly it has been decided that XML patterns is 
> getting deprecated in 5.13? 

There is a second very interesting question:
Why does the "explicit note" in the documentation recommend replacement classes 
(i.e. the
streaming classes) for Qt Xml if it is "Done" and not "Deprecated"? Appart from 
the fact
that this is technically suspect, now it seems completely wrong in regard to 
the status. 

It appears Qt Xml actually was marked deprecated in code once which was 
reverted later. 

I just browsed the web a little.
It is deprecated:
https://wiki.qt.io/XML
https://lists.qt-project.org/pipermail/interest/2013-August/008183.html
https://community.kde.org/Qt5/Documentation/OverviewClassification#QtXML_.28deprecated.29
https://bugreports.qt.io/browse/QTBUG-71784
It is done:
https://bugreports.qt.io/browse/QTBUG-32926

The confusion is perfect. Especially notice issue 71784 above. That is what I 
talked about
earlier when I said without clean documentation you can not do clean Qt6 
planning.

-- 
Best Regards,
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Giuseppe D'Angelo via Development]

Il 21/05/19 16:58, Thiago Macieira ha scritto:

On Tuesday, 21 May 2019 00:15:04 PDT Bernhard Lindner wrote:

Unlucky me. Deprecation of these two components literally broke every
application I have ever written using Qt. I hope they will have new
maintainers some day.

Note I said QtXml is deprecated, but it might actually be in Done state. I
don't remember. Does anyone? Where's our authoritative source?

The difference between Done and Deprecated is whether we're telling you to
start porting code away.


I think both XML and XMLPatterns are Done, not Deprecated.

Reasoning: only the former has an explicit note in the documentation 
(can't find an equivalent for the latter):



https://doc.qt.io/qt-5/qtxml-index.html
https://doc.qt.io/qt-5/qtxmlpatterns-index.html


But especially: neither is marked as deprecated in


https://doc.qt.io/qt-5/qtmodules.html



So where and when exactly it has been decided that XML patterns is 
getting deprecated in 5.13? Was it ever brought up in the mailing lists? 
It's not listed as such in the 5.13.0 changelog, it's not in the docs, 
the only reference is 5.13.0 is



https://codereview.qt-project.org/c/qt/qt5/+/256261


Which landed over two months after the feature freeze. The only note I 
can find in the documentation has been _just_ added for 5.13.1:



https://codereview.qt-project.org/c/qt/qtxmlpatterns/+/256597


And similarly no note has been added to the overall Qt modules page:


https://doc-snapshots.qt.io/qt5-5.13/qtmodules.html



Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

> Qt modules and features can be in one of 5 states:
> 
> - Active Development
>  Receiving new features, changing quickly, bugs fixed
> - Maintained
>  Receives occasional features, changes slowly, bugs fixed
> - Done
>  No new features, changes very slowly, P2 bugs and up fixed only
> - Deprecated
>  No new features, almost no changes, P1 and security fixes only,
>  new code should not use it, old code should begin porting away
> - Removed
>  Self-explanatory and not coming back

Very helpful! Thanks a lot!

This is exactly what should have been written at that Wikipage.

Maybe the documentation would be an even better place. People would
get a component status update with each Qt update: Component status 
table plus the above description how to interpret the status. 
I mean, that is really important. Why not placing it in the 
documentation instead of ambiguous sentences like the one I cited?

-- 
Best Regards,
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Thiago Macieira]

On Tuesday, 21 May 2019 08:55:34 PDT Bernhard Lindner wrote:
> I heared about "deprecated" and, well, not deprecated. I had no idea there
> is such a state like "Done".

Qt modules and features can be in one of 5 states:

- Active Development
 Receiving new features, changing quickly, bugs fixed
- Maintained
 Receives occasional features, changes slowly, bugs fixed
- Done
 No new features, changes very slowly, P2 bugs and up fixed only
- Deprecated
 No new features, almost no changes, P1 and security fixes only,
 new code should not use it, old code should begin porting away
- Removed
 Self-explanatory and not coming back

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

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 real browser engine. Light weight is a real advantage.
>>  Creator already takes up enough memory as it is, with its code model
>>  especially. And documentation doesn’t need most of the fancy HTML
>>  features either.
>
> A better QTextBrowser would be very much welcomed, but there may still
> be cases where Assistant needs more features.
>
> The question of what HTML features are necessary depends on the
> application. In user applications, Assistant is not used to display code
> documentation (which is quite simple) but help files, which may require
> a much greater feature set. If it were possible, it could even be
> desirable to include small video clips as instructions for performing
> certain tasks. So there may still be applications where a full browser
> stack would be desirable. One could argue that one should spawn a real
> browser instead, but the index and search facilities in Assistant are
> invaluable.

FWIW, size-optimized build of QtWebKit with minimal feature set resulted in ~20M
binary here, though I've disabled video. While it can be seen aas bloated when
compared to QTextBrowser, it includes much more advanced HTML/CSS renderer,
supports JavaScript, and includes full-fledged SVG renderer.

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

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 with -stylesheet, and there are 
users
which use this feature even if application author never envisioned this.


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

> Yes, they were done, not deprecated. See 
> https://wiki.qt.io/Qt_Modules_Maturity_Level

That is good news! 

In https://wiki.qt.io/New_Features_in_Qt_5.13 it says Qt XmlPatterns would be 
deprecated.
Somebody in the interest list pointed me there.
Also I heard a lot (and it is written in the documentation) that Qt Xml should 
not be used
anymore, but the stream classes. If the state is "done", not "deprecated", 
there is no
reason for that!

Maybe this should be communicated and documented more clearly. Such news have a 
user side
impact like a nuke!

> I don't think the "Done" nomenclature stuck though. In half the cases it 
> just meant unmaintained rather than actually done.

That document should be revised. It obviously is very important. How can you 
even do
strategical planing without such a fundamental document?

-- 
Best Regards, 
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Sérgio Martins via Development]

On 2019-05-21 15:58, Thiago Macieira wrote:

On Tuesday, 21 May 2019 00:15:04 PDT Bernhard Lindner wrote:

Unlucky me. Deprecation of these two components literally broke every
application I have ever written using Qt. I hope they will have new
maintainers some day.


Note I said QtXml is deprecated, but it might actually be in Done 
state. I

don't remember. Does anyone? Where's our authoritative source?


Yes, they were done, not deprecated. See 
https://wiki.qt.io/Qt_Modules_Maturity_Level


I don't think the "Done" nomenclature stuck though. In half the cases it 
just meant unmaintained rather than actually done.


That page should probably be archived, as it's not much of an authority 
anymore.


Some random incorrect statements:

"
QtSVG (Deprecated)
Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in
Qt WebKit, which should be used instead;


Qt Designer (Done)
Reasoning: Qt Quick is recommended for developing UIs from now on, so
the new Qt Quick Designer should take over the capabilities of the 
classic Qt Designer.

"





https://doc.qt.io/qt-5/qtmodules.html seems to more accurate nowadays




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[André Pönitz]

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.

But please don't spoil this debate with evidence that certain people consider
"container.contains(X)" a sensible API.

Andre'

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Issues (temporary) with gerrit and code.qt.io

[Stottlemyer, Brett (B.S.)]

Hi all,

Passing this one for general awareness.  I've been hit by 
https://bugreports.qt.io/browse/QTQAINFRA-2980.

The referenced issue is closed but with a note "I assume it will take awhile to 
finish."  The symptoms, as I understand it, are that various mirrors are not 
current.

I was able to run `git pull` and get the current HEAD correctly from code.qt.io 
from the command line, but a coworker is only getting 
fa84f22bfd5500550f26f544f6905ac89e60716f (missing two commits).

This commit is 
listed as merged in Gerrit, but as of this moment, it isn't listed in 
https://code.qt.io/cgit/qt/qtremoteobjects.git/log/.  The website's log (like 
the `git pull` result) is a few commits behind.

Just an FYI in case others see the same issue.

Regards,
Brett
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[André Pönitz]

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->setPatheStep(10);
>sl->setStep(1);
> 
> was also wrong. I now need to check that the calls on the slider are always
> on the same object.

Right, but in this case most of the 'sl' are vertically aligned,
which makes them easily comparible. While that repetition is indeed
a minor nuisance it is more than compensated by the advantage of
having a name for the individual parameter. So overall, the Qt 4
version is much better, despite of the repetition.

This is also not a counter-argument to the STL containedness problem
we were "discussing" as the overall benefit of the Qt 4 version
are *not* due to the repetition, in fact it's there *despite* of
the repetition.

> You are confusing familiarity with simplicity.

I think I can perfectly decide myself what I confuse.

> It's simple that in the STL I can search for a value or a predicate
> condition at the change of just an '_if'. Container::contains(), OTOH,
> is just familiar (from previous Qt versions or other languages).

It's not familiarity, it's the natural question:

  "Container: Do you contain element X?"

vs

  "World: If I were to check all handles starting at something that's
  (sometimes...) a handle to a kind of 'first' element of this container
  (ignoring that you might be unordered, and having an order is something 
  that isn't natural for it), and check all elements refered to by those
  handles whether they equal X, would the algorithm I use return me
  something else that that exceptional (non-)handle that (also...)
  signifies "didn't really find it"?

So no: it's completely the other way round: I *am* familiar with the
Standard Library way to check for containedness, but it's *not simple*
and I am very well aware of the reasons I do not like it: It is a
ridiculously complex and superfluous stanza that leaks implementation
details of the underlying containers (e.g. having some kind of order,
even when the container nominally unordered).

It's something that I do not want to see and nobody should be 
required to use in "normal" code.

> QVector::contains() is not overloaded on QLatin1String, e.g.
> Std::find(), OTOH, will transparently use the QLatin1String, avoiding the
> creation of a temporary QString. 

And then what? A GUI application waiting for the next key press that
will happen 100ms later will spent 1 cycles on a 1GHz core for the
"useless" conversion?  There's *quite* some room until this gets even
close to being noticable.

> If contains() turns out to be a performance bottleneck in profiling,
> the user can't do anything about it and needs to go to the universal
> mechanism (std::find).

And if it turns out to be a bottleneck, code can be changed.
This happens, but it does not happen often. E.g. all those "wrong"
usages of QList do not appear in any profile of a Qt Creator run.

> This does not make the API simple to use. Maybe for people coming from other
> languages. It introduces two different ways to do essentially the same
> thing, advocating the ways that only works in a particular corner-case and
> refusing to show the universal way
> (https://doc.qt.io/qt-5/qvector.html#indexOf). But eventually, these
> developers _will_ need to search by a predicate, too, and then they will
> fall back to a raw loop, sometime,

Uhuh... raw loops! And that when you can clutter your code with all
those non-sensical unordered.begin() and unordered.end() iterators.
What a loss of laughableness!

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[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 real browser engine. Light weight is a real advantage. 
Creator already takes up enough memory as it is, with its code model 
especially. And documentation doesn’t need most of the fancy HTML 
features either.


A better QTextBrowser would be very much welcomed, but there may still 
be cases where Assistant needs more features.


The question of what HTML features are necessary depends on the 
application. In user applications, Assistant is not used to display code 
documentation (which is quite simple) but help files, which may require 
a much greater feature set. If it were possible, it could even be 
desirable to include small video clips as instructions for performing 
certain tasks. So there may still be applications where a full browser 
stack would be desirable. One could argue that one should spawn a real 
browser instead, but the index and search facilities in Assistant are 
invaluable.


--
Bastiaan.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

> > Unlucky me. Deprecation of these two components literally broke every
> > application I have ever written using Qt. I hope they will have new
> > maintainers some day.
> 
> Note I said QtXml is deprecated, but it might actually be in Done state. I 
> don't remember. Does anyone? Where's our authoritative source?
> 
> The difference between Done and Deprecated is whether we're telling you to 
> start porting code away.

Heck, yes, that would be a big difference.

Documentation says about Qt Xml "not actively maintained anymore"… whatever 
that means.

I heared about "deprecated" and, well, not deprecated. I had no idea there is 
such a state
like "Done". 

I could live with "Done". But a "deprecated" component makes me lamenting when 
I relied on
it.

Is there some document describing the states and their meaning? Is there a 
component/state
table where we could lookup the specific states?

-- 
Best Regards, 
Bernhard Lindner


signature.asc
Description: This is a digitally signed message part
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Uwe Rathmann]

On 5/21/19 4:58 PM, Thiago Macieira wrote:

Note I said QtXml is deprecated, but it might actually be in Done 
state. I don't remember. Does anyone? Where's our authoritative 
source?


The difference between Done and Deprecated is whether we're telling 
you to start porting code away.


My use case is SVG, that depends on XML - using vector graphics is
something we are doing since many years all the time. F.e our current
project uses > 1000 SVGs.

I remember, that there once was a page in the Qt docs that
explicitly recommended layouts + vector graphics being the solution to
make an application independent from the specific screen resolution.

F.e QSkinny is based on a class QskGraphic (
https://github.com/uwerat/qskinny/blob/master/src/graphic/QskGraphic.h
), what is a QPainter record/replay paint device - similar to QPicture
-  that can be used like QPixmap/QImage, but for vector graphics.

Our instances if QskGraphic were initially created from SVGs using this
precompiler (
https://github.com/uwerat/qskinny/blob/master/tools/svg2qvg/main.cpp )
based on QSvgRenderer. Of course I could use a different SVG parser to
create the QPainter commands, but for what ...

So please don't consider removing SVG/XML - I would even suggest the
opposite: improve Widgets + Quick towards vector graphics.

Uwe




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Nils Jeisecke via Development]

Am 21.05.2019 um 14:06 hat Shawn Rutledge geschrieben:

I wish that were true for me. We need colours in table cell borders
and SVG images (and better CSS support would be real nice). This
might help, but is stalled:
https://codereview.qt-project.org/c/qt/qtbase/+/177256


I was just putting some thought into CSS over the last few days, but
wasn’t aware of that patch.


Yes, I was always hoping to get it into the next Qt release (so I don't
always have to patch Qt for my projects where this code is in use for
years now). But it looks like there's not too much interest.

I really wouldn't mind getting more reviewers for this so please feel
invited ;-)

Nils


signature.asc
Description: PGP signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Qt World Summit 2019 - CfP

[Thiago Macieira]

On Tuesday, 21 May 2019 00:54:49 PDT Kai Köhne wrote:
> Hi,
> 
> The deadline for submissions indeed got extended to * 2nd of June *... which
> is already end of next week!
 
> So feel free to still submit proposals, but hurry up 
> 
> https://www.surveymonkey.com/r/K7PMKC8

Do we have an idea whether the Contributor Summit will be co-located with the 
World Summit? Or will it be co-located with Akademy in Milan (September)?

I get to go to the Contributor Summit only, so I need to know that before I 
submit a talk.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Thiago Macieira]

On Tuesday, 21 May 2019 00:15:04 PDT Bernhard Lindner wrote:
> Unlucky me. Deprecation of these two components literally broke every
> application I have ever written using Qt. I hope they will have new
> maintainers some day.

Note I said QtXml is deprecated, but it might actually be in Done state. I 
don't remember. Does anyone? Where's our authoritative source?

The difference between Done and Deprecated is whether we're telling you to 
start porting code away.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[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

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, May 21, 2019 at 4:07 PM Shawn Rutledge  wrote:

>
> > On 20 May 2019, at 18:56, Bastiaan Veelo  wrote:
> >
> > 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:
> >>> ...
> >> However, it would better to avoid duplicating work with Qt Creator,
> >> which also implements HelpViewer interface with different backends.
> >> Some time ago there was a discussion that such shared interface & plugin
> >> system should belong to Qt Web View module. But that would  probably
> >> require more work to be done.
>
> If there is really a need to use WebEngine, a plugin makes sense.  Sharing
> a plugin between Creator and Assistant makes sense.  But I do worry about
> the runtime memory bloat that it will introduce.
>
> >>> Or do you think that removing WebKit support from Assistant completely
> >>> would be better, if WebEngine shows to be working well?
> >> As for me, I'm totally fine with QTextBrowser
> >
> > I wish that were true for me. We need colours in table cell borders and
> SVG images (and better CSS support would be real nice). This might help,
> but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256
>
> I was just putting some thought into CSS over the last few days, but
> wasn’t aware of that patch.
>
> I don’t like the limitation we have, that CSS can be applied only while
> parsing HTML, because after the parsing is done, there is no DOM: a lot of
> structural information from HTML is lost.  This is a limiting factor for my
> work with supporting Markdown in QTD lately: after you have read HTML, not
> enough information is saved to be able to write markdown as nicely as I’d
> like (it’s mostly possible to work around, but e.g.  results in a
> separate block per line, and  results in an indented plain
> paragraph, so the markdown writer has to reconstruct some of the structure
> by detecting those idiosyncrasies).  And of course there’s no support for
> applying CSS to markdown, precisely because of the fact that it can be
> applied only while the HTML parser is running, and in the markdown case
> there’s no HTML parser instance.  I’m loathe to take the same approach with
> markdown (apply CSS only while parsing), but I’d like to have CSS support
> for it.  For both HTML and Markdown it would be nice if CSS could be
> applied dynamically to an existing QTextDocument.  I don’t see a real
> reason why we shouldn’t be able to, as long as QTD stores enough
> information about the original structure (i.e.  is not just a block
> with a particular font size and style:
> 310daae53926628f80c08e4415b94b90ad525c8f took care of that, because I
> couldn’t realistically get started with markdown support unless the heading
> blocks could at least remember their own heading levels).  Similar fixes
> could gradually turn QTD into something almost like a DOM, and could also
> turn the HTML-writing support into a lot less of a mess (be able to write
> out HTML that looks more like what you read in).  But it’s kindof
> frustrating work: I just keep wondering why stuff like that still needs to
> be done in 2019.
>
> So I wonder if we should gradually fix that, or we would be better off
> replacing the guts of QTD with a proper DOM of some sort.  But of course
> it’s a slippery slope: QTextBrowser should never be as complex as a real
> browser.  So the knee-jerk reaction is to say “forget about it, use
> webengine”; but the other side of the argument is that it’s quite nice to
> have such a compact implementation as QTD/QTB are, and there are so many
> applications where a real browser engine is such terrible overkill.  I
> suspect that Konqueror must have had a time period where it had a suitably
> compact but architecturally better design, but I haven’t dug in deep enough
> to figure that out; several people should already know, anyway.
>
> BTW, there is a movement to ditch qtxmlpatterns and replace it in the one
> use case that matters to Qt Quick (XmlListModel) with some other XML
> parser, something good enough for all use cases in the rest of Qt.  (Based
> on libxml2 maybe?)  So can we perhaps say these things are related: it’s OK
> to support only well-formed XHTML, not loosely-structured HTML, maybe we
> could use the same XML parser for both use cases, to reduce the code size
> and get a real DOM at the same time?  But it doesn’t make the CSS work any
> easier; the question is how much would QTD change if we take that
> approach.  And the DOM in qtxmlpatterns seems kindof cool too
> (feature-wise, although I don’t know much about the implementation); it’s
> just that nobody wants to support it.  But libxml2 has a DOM too, they
> say.  (I haven’t 

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

[Shawn Rutledge]

> On 20 May 2019, at 18:56, Bastiaan Veelo  wrote:
> 
> 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:
>>> ...
>> However, it would better to avoid duplicating work with Qt Creator,
>> which also implements HelpViewer interface with different backends.
>> Some time ago there was a discussion that such shared interface & plugin
>> system should belong to Qt Web View module. But that would  probably
>> require more work to be done.

If there is really a need to use WebEngine, a plugin makes sense.  Sharing a 
plugin between Creator and Assistant makes sense.  But I do worry about the 
runtime memory bloat that it will introduce.

>>> Or do you think that removing WebKit support from Assistant completely
>>> would be better, if WebEngine shows to be working well?
>> As for me, I'm totally fine with QTextBrowser
> 
> I wish that were true for me. We need colours in table cell borders and SVG 
> images (and better CSS support would be real nice). This might help, but is 
> stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256

I was just putting some thought into CSS over the last few days, but wasn’t 
aware of that patch.

I don’t like the limitation we have, that CSS can be applied only while parsing 
HTML, because after the parsing is done, there is no DOM: a lot of structural 
information from HTML is lost.  This is a limiting factor for my work with 
supporting Markdown in QTD lately: after you have read HTML, not enough 
information is saved to be able to write markdown as nicely as I’d like (it’s 
mostly possible to work around, but e.g.  results in a separate block per 
line, and  results in an indented plain paragraph, so the markdown 
writer has to reconstruct some of the structure by detecting those 
idiosyncrasies).  And of course there’s no support for applying CSS to 
markdown, precisely because of the fact that it can be applied only while the 
HTML parser is running, and in the markdown case there’s no HTML parser 
instance.  I’m loathe to take the same approach with markdown (apply CSS only 
while parsing), but I’d like to have CSS support for it.  For both HTML and 
Markdown it would be nice if CSS could be applied dynamically to an existing 
QTextDocument.  I don’t see a real reason why we shouldn’t be able to, as long 
as QTD stores enough information about the original structure (i.e.  is not 
just a block with a particular font size and style: 
310daae53926628f80c08e4415b94b90ad525c8f took care of that, because I couldn’t 
realistically get started with markdown support unless the heading blocks could 
at least remember their own heading levels).  Similar fixes could gradually 
turn QTD into something almost like a DOM, and could also turn the HTML-writing 
support into a lot less of a mess (be able to write out HTML that looks more 
like what you read in).  But it’s kindof frustrating work: I just keep 
wondering why stuff like that still needs to be done in 2019.

So I wonder if we should gradually fix that, or we would be better off 
replacing the guts of QTD with a proper DOM of some sort.  But of course it’s a 
slippery slope: QTextBrowser should never be as complex as a real browser.  So 
the knee-jerk reaction is to say “forget about it, use webengine”; but the 
other side of the argument is that it’s quite nice to have such a compact 
implementation as QTD/QTB are, and there are so many applications where a real 
browser engine is such terrible overkill.  I suspect that Konqueror must have 
had a time period where it had a suitably compact but architecturally better 
design, but I haven’t dug in deep enough to figure that out; several people 
should already know, anyway.

BTW, there is a movement to ditch qtxmlpatterns and replace it in the one use 
case that matters to Qt Quick (XmlListModel) with some other XML parser, 
something good enough for all use cases in the rest of Qt.  (Based on libxml2 
maybe?)  So can we perhaps say these things are related: it’s OK to support 
only well-formed XHTML, not loosely-structured HTML, maybe we could use the 
same XML parser for both use cases, to reduce the code size and get a real DOM 
at the same time?  But it doesn’t make the CSS work any easier; the question is 
how much would QTD change if we take that approach.  And the DOM in 
qtxmlpatterns seems kindof cool too (feature-wise, although I don’t know much 
about the implementation); it’s just that nobody wants to support it.  But 
libxml2 has a DOM too, they say.  (I haven’t looked at the API yet.)

Another reason CSS came up is in the context of what to do with QStyle in Qt 6. 
 QSS is another thing that Qt developers have always been loathe to support, 
and yet the users keep on using it.  But there is a case where CSS can really 
be applied at runtime.  It has a reputation for being terrible for performance, 
but I didn’t really understand why until looking at a bug a couple of 

Re: [Development] Views

[Danila Malyutin]

Exhibit C:

foo().contains(x)

https://godbolt.org/z/KlIcFc

пн, 20 мая 2019 г. в 23:14, André Pönitz :

> 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(container.begin(), container.end(), x) !=
> container.end();
>  }
>
>
> Andre'
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

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" :
>    On 20/05/2019 16:51, Konstantin Tokarev wrote:
>>  Note that it should be possible to rebuild QtTools with QtWebKit 
>> support,
>>  for example this configuration is supported in Gentoo out of the 
>> box.
>
> [...]
>  But not on Windows, am I right?
>>  Why not? Current version of QtWebKit from 5.212 works on Windows,
>>  there are binaries at
>>
>>  http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/
>
> Extracted into qtbase and Assistant builds like a charm! However running
> it gives
>
> "The procedure entry point
> ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in
> the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll".
>
> I have checked out the Qt dev branch from May 11, which I can imagine
> could cause problems. Do you happen to know which Qt version those
> QtWebKit binaries are known to work with?

5.10

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[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" :

  On 20/05/2019 16:51, Konstantin Tokarev wrote:

    Note that it should be possible to rebuild QtTools with QtWebKit support,
    for example this configuration is supported in Gentoo out of the box.
  

[...]

But not on Windows, am I right?

Why not? Current version of QtWebKit from 5.212 works on Windows,
there are binaries at

http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/


Extracted into qtbase and Assistant builds like a charm! However running 
it gives


"The procedure entry point 
?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in 
the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll".


I have checked out the Qt dev branch from May 11, which I can imagine 
could cause problems. Do you happen to know which Qt version those 
QtWebKit binaries are known to work with?


Thanks,
Bastiaan.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Ritt]

вт, 21 мая 2019 г., 14:25 Mutz, Marc via Development <
development@qt-project.org>:

> On 2019-05-21 13:03, Konstantin Ritt wrote:
> > вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
> > :
> >
> >> And while the partially-formed
> >> state can be extended to non-pimpled classes easily:
> >>
> >> class QRect {
> >> int x, y, w, h;
> >> public:
> >> QRect() = default;
> >> };
> >> QRect r; // partially-formed
> >> r.x();   // compilers _already_ warn about this
> >> QRect r = {}; // zero-initialized
> >>
> >> That
> >> should be modelled by optional, not by QRect itself.
> >
> > Whilst the statement feels reasonable, this will require tons of API
> > changes and double checks on the user side:
>
> There are no double-checks. If the old code didn't check the rect before
> using it, it was a bug.
>

the first one is "does returned optional contain a rect?"
the second one "is rect empty?" // <- same check that was done in the "old"
code


> > optional Item::childrenRect() const
> > {
> > if (hasChildren()) {
> > QRect r = {};
> > for (auto *child : children())
> > r.unite(child->boundingRect().value_or({});
>
>for (auto *child : children())
>if (auto rect = child->boundingRect())
>r.unite(*rect);
>
> > return r;
> > }
> > return nullopt;
> > }
> >
> > QRect r = item->boundingRect().value_or({});
> > if (!r.isEmpty())
> > ~~~
>
> if (auto r = item->boundingRect())
>  use(*r);
>

there is nothing to use if 'r' has no value.
> The behavior is undefined if *this does not contain a value.
-- so value_or({}).
and then one would have to check if '*r' is valid/empty/normalized, just
like (s)he did before.


> > Note that I'm ok with that, but should we enforce such a huge efforts
> > all over Qt API just for making the default-constructible QRect a
> > no-op?
>
> This is not proposed for Qt 6. Not by me, at least. But it's the logical
> extension and once Qt can depend on C++17, iow: std::optional, it's the
> correct way forward, IMNSHO.
>
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 21/05/2019 12:24, Kai Köhne wrote:


-Original Message-
From: Development  On Behalf Of
Subject: [Development] Assistant WebKit/WebEngine support

Hi,

I am prepared to do some work on Qt Assistant, and I'd like to know how that
will be received.

Cool, great you want to tackle this 

I'm sure Jarek (the official maintainer) will also share his thoughts, but he's 
out
of office this week.


Thanks for letting me know.




[...]
I have been looking into the plugin idea, and although it is not straight 
forward
I think it is doable. Some larger refactoring is needed to achieve a clean 
border
between Assistant and the viewer plugin interface. My goal is to eliminate calls
from the viewer plugin back into the Assistant application, which would
otherwise require some classes to be in a common shared library. I can
implement the QTextBrowser based viewer in a plugin that is statically linked,
so that Assistant will work out of the box whether it is being deployed with or
without WebEngine. Plugins can be selected based on priority.

That sounds like a good approach to me.

Another abstraction you might consider is using Qt WebView as universal backend:

https://doc.qt.io/qt-5/qwebengineview.html

Qt WebView is an abstraction for showing web content, using different backends
on different platforms.  It is currently geared towards the mobile platforms, 
using
Qt WebEngine as default backend on the desktop. Anyhow, it has already an
(experimental) backend on macOS using Safari, and my hope is that we can make
it also work with the new Chromium based Edge browser on Windows,
see  https://bugreports.qt.io/browse/QTBUG-75747 .
Anyhow, I'm not sure the QtWebView API is actually capable enough to cater for
Qt Assistant. One obvious challenge is that you've to pass a url to the engine 
that
it can actually resolve. This probably means either extracting the html in the
.qch files to a local directory, or even running a minimal local web server. 
There
might be even more functionality missing ...

But Qt WebView has already a plugin infrastructure, so you can at least take
inspiration from there 


Although I haven't looked at QtWebView's API yet, it seems that indeed 
the best solution would be to add support for the qthelp scheme to 
QtWebView, possibly in a plugin to it? Konstantin mentioned that this 
has been discussed before. I think the abstraction could be taken from 
Qt Creator, 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/webenginehelpviewer.cpp#n123, 
class HelpUrlSchemeHandler. I just had a glance at Qt Creator like 
Konstantin suggested. From what I can see, the help viewer itself is 
implemented as a Creator plugin, but the backend is determined at 
compile time much like Assistant is doing it currently. There is a lot 
of code duplication between Assistant and Creator, so it would be good 
to unify that code somewhere.


Assistant's challenge compared to Creator is the build order. Creator is 
built independently from Qt so it has no problems using QtWebEngine. 
Within a clean Qt clone however, Assistant is built before QtWebEngine, 
which is the main reason why 
https://codereview.qt-project.org/c/qt/qttools/+/111559 can't be pulled. 
So that is the main motivation for a plugin system. I am assuming that 
the same issue would exist if Assistant were to use QtWebView, as I 
assume the latter depends on QtWebEngine as well? In that case there 
would still be a build order problem. Can you confirm that?


I don't know enough about Qt's build system to know what is necessary to 
defer the build of Qt Assistant until after QtWebEngine/QtWebView has 
finished building. If that's necessary for using QtWebView then it would 
be good to focus on that first. When that's done then the existing 
WebEngine support PR can simply be merged into Assistant, which would 
close the long standing issue 
https://bugreports.qt.io/browse/QTBUG-55866. Then refactoring backend 
details from Creator and Assistant into WebView could be done at leisure.


[...]



Also, would you mind creating a JIRA item for this ? This way it's easier to 
track...


There's this: https://bugreports.qt.io/browse/QTBUG-55866, that will do, 
right?


Thanks,
Bastiaan.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mutz, Marc via Development]

On 2019-05-21 13:03, Konstantin Ritt wrote:

вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
:


And while the partially-formed
state can be extended to non-pimpled classes easily:

class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x();   // compilers _already_ warn about this
QRect r = {}; // zero-initialized

That
should be modelled by optional, not by QRect itself.


Whilst the statement feels reasonable, this will require tons of API
changes and double checks on the user side:


There are no double-checks. If the old code didn't check the rect before 
using it, it was a bug.



optional Item::childrenRect() const
{
if (hasChildren()) {
QRect r = {};
for (auto *child : children())
r.unite(child->boundingRect().value_or({});


  for (auto *child : children())
  if (auto rect = child->boundingRect())
  r.unite(*rect);


return r;
}
return nullopt;
}

QRect r = item->boundingRect().value_or({});
if (!r.isEmpty())
~~~


if (auto r = item->boundingRect())
use(*r);


Note that I'm ok with that, but should we enforce such a huge efforts
all over Qt API just for making the default-constructible QRect a
no-op?


This is not proposed for Qt 6. Not by me, at least. But it's the logical 
extension and once Qt can depend on C++17, iow: std::optional, it's the 
correct way forward, IMNSHO.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mutz, Marc via Development]

On 2019-05-21 12:52, Julien Cugnière wrote:

Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
 a écrit :
It is, however, be an acceptable stop-gap measure, and here a 
compromise

may emerge, for keeping old code working while preparing for a
fully-implemented partially-formed state. This would mean we do assign
meaning to a nullptr d consistent with the documented default value in
Qt 5, but deprecate the use of the default ctor for establishing said
value in the docs and warn about the use of a default-constructed 
object

other than for destruction and assignment at runtime, even in release
mode. In Qt 7, we then crash, as we do for some moved-from objects
already.


Hi, I'm just a bystander, but I'm curious about this, and I wonder if
I misunderstood.

Are you saying that in modern C++, the recommendation is that the
default constructor of classes should leave the object in an
uninitialized state, where most member functions called will crash or
lead to undefined behavior? Do you have any links on the subject?


This has nothing to do with 'Modern C++'. It's how an int behaves since 
the dawn of time:


   int i; // uninited, can only be assigned to, or go out of scope 
(destroyed)

   int i = {}; // zero-initialized

In 2009 Alex Stepanov et al. wrote a little book called Elements of 
Programming in which they formalized this behaviour, calling it the 
Partially-Formed State, and extending it to all other value classes. 
Crucially, this was before C++ got move semantics. To my knowledge, 
https://www.kdab.com/stepanov-regularity-partially-formed-objects-vs-c-value-types/ 
is the first treatise that extends EoP's notion to C++11 and, in 
particular, move semantics.


A type doesn't need to establish just the partially-formed state. But 
users of types (and generic algorithms) may not assume more than that, 
either.



Are you suggesting that in Qt 7, we will have the following :

QRect r;
qDebug() << r.width(); // random value


No: UB. But also:

Compiler warning: r.m_w might be used uninitialised in this function.


QRect r = {};
qDebug() << r.width(); // OK, prints 0



QVector v;
qDebug() << v.size(); // crash


No. QVector is a container, their default is empty, and that's all 
right, because their default ctor already does the minimum amount of 
work necessary for the dtor to run. There's also no extra runtime check 
involved: size() { return begin() - end(); } where begin() == nullptr 
and end() == nullptr. And yes, just as now, v.front() invokes UB.


std::list is more interesting...


QString s;
qDebug() << s.indexOf("foo"); // crash


No the second. QString, too, is a container.


What about std::string and std::vector ?


They, too, are containers. And no, the standard does not use the 
partially-formed state. As a consequence, we have now 
std::variant::valueless_by_exception.


For more info, read EoP (it's out of print, though, and my copy ain't 
for sale) or my article linked above.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Ritt]

вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development <
development@qt-project.org>:

> And while the partially-formed
> state can be extended to non-pimpled classes easily:
>
>  class QRect {
> int x, y, w, h;
>  public:
> QRect() = default;
>  };
>  QRect r; // partially-formed
>  r.x();   // compilers _already_ warn about this
>  QRect r = {}; // zero-initialized
>
> That
> should be modelled by optional, not by QRect itself.
>

Whilst the statement feels reasonable, this will require tons of API
changes and double checks on the user side:

optional Item::childrenRect() const
{
if (hasChildren()) {
QRect r = {};
for (auto *child : children())
r.unite(child->boundingRect().value_or({});
return r;
}
return nullopt;
}

QRect r = item->boundingRect().value_or({});
if (!r.isEmpty())
~~~


Note that I'm ok with that, but should we enforce such a huge efforts all
over Qt API just for making the default-constructible QRect a no-op?



Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Julien Cugnière]

Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
 a écrit :
> It is, however, be an acceptable stop-gap measure, and here a compromise
> may emerge, for keeping old code working while preparing for a
> fully-implemented partially-formed state. This would mean we do assign
> meaning to a nullptr d consistent with the documented default value in
> Qt 5, but deprecate the use of the default ctor for establishing said
> value in the docs and warn about the use of a default-constructed object
> other than for destruction and assignment at runtime, even in release
> mode. In Qt 7, we then crash, as we do for some moved-from objects
> already.

Hi, I'm just a bystander, but I'm curious about this, and I wonder if
I misunderstood.

Are you saying that in modern C++, the recommendation is that the
default constructor of classes should leave the object in an
uninitialized state, where most member functions called will crash or
lead to undefined behavior? Do you have any links on the subject?

Are you suggesting that in Qt 7, we will have the following :

QRect r;
qDebug() << r.width(); // random value

QVector v;
qDebug() << v.size(); // crash

QString s;
qDebug() << s.indexOf("foo"); // crash

What about std::string and std::vector ?

-- 
Julien Cugnière
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Subject: [Development] Assistant WebKit/WebEngine support
> 
> Hi,
>
> I am prepared to do some work on Qt Assistant, and I'd like to know how that
> will be received.

Cool, great you want to tackle this 

I'm sure Jarek (the official maintainer) will also share his thoughts, but he's 
out 
of office this week.

> [...]
> I have been looking into the plugin idea, and although it is not straight 
> forward
> I think it is doable. Some larger refactoring is needed to achieve a clean 
> border
> between Assistant and the viewer plugin interface. My goal is to eliminate 
> calls
> from the viewer plugin back into the Assistant application, which would
> otherwise require some classes to be in a common shared library. I can
> implement the QTextBrowser based viewer in a plugin that is statically linked,
> so that Assistant will work out of the box whether it is being deployed with 
> or
> without WebEngine. Plugins can be selected based on priority.

That sounds like a good approach to me.

Another abstraction you might consider is using Qt WebView as universal backend:

https://doc.qt.io/qt-5/qwebengineview.html

Qt WebView is an abstraction for showing web content, using different backends
on different platforms.  It is currently geared towards the mobile platforms, 
using
Qt WebEngine as default backend on the desktop. Anyhow, it has already an
(experimental) backend on macOS using Safari, and my hope is that we can make  
it also work with the new Chromium based Edge browser on Windows, 
see  https://bugreports.qt.io/browse/QTBUG-75747 .

Anyhow, I'm not sure the QtWebView API is actually capable enough to cater for
Qt Assistant. One obvious challenge is that you've to pass a url to the engine 
that 
it can actually resolve. This probably means either extracting the html in the
.qch files to a local directory, or even running a minimal local web server. 
There
might be even more functionality missing ... 

But Qt WebView has already a plugin infrastructure, so you can at least take
inspiration from there  

> Having the viewer back end be separated from the application with a plugin
> interface may be an advantage regardless, whether WebKit comes back or
> WebEngine is being removed from the Qt distribution in the future. At least
> users will have a possibility to replace the default viewer with whatever
> alternative is available.
> 
> Does this sound like a good idea?

I think your approach makes sense, but I'd wait for Jarek to comment first.

Also, would you mind creating a JIRA item for this ? This way it's easier to 
track...

Regards

Kai 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Elvis Stansvik]

Den tis 21 maj 2019 kl 10:57 skrev Giuseppe D'Angelo via Development
:
>
> Il 21/05/19 10:26, Elvis Stansvik ha scritto:
> > They will not show up in the web search (I think).
> >
> > They are however available in the debian-debug archive, see
> > https://wiki.debian.org/AutomaticDebugPackages
>
> [snip]
>
> Genuine question, are those just the debug builds of a release build, or
> are those debug builds? There is a difference when compiling Qt itself
> (amongst other things, release builds do not have Q_ASSERTs in them).

I'm not 100% sure, I think they are just packages containing symbols,
so the build is the same (a release build). I think Debian packagers
hang on this list so they would know for sure.

That would mean Q_ASSERT is a no-op then, even with those packages
installed, so they are just good for getting better backtraces.

Elvis

>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Eike Ziller]

> On 21. May 2019, at 08:32, Mutz, Marc via Development 
>  wrote:
> 
> On 2019-05-20 23:43, André Pönitz wrote:
>> 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:
>>> > > >
>>> > > >  {
>>> > > >  ... container = foo();
>>> > > >  std::find(container.begin(), container.end(), x) !=
>>> > > > container.end();
>>> > > >  }
>>> > >
>>> > > And now do the same thing [...]
>>> >
>>> > No, I won't.
>>> >
>>> > You were claiming something universally valid (\forall x "There is
>>> > no difference ...")
>>> I never said that there's no difference. I said there's no difference in
>>> readability. Don't confuse familiarity with simplicity (or readability).
>> Indeed, you claimed only "no difference in readability".
>> But I wouldn't agree that there is "no difference in readabilty" between
>> Exhibit A and B above.
>> In case B one e.g. would need to check whether all _four_ occurances of
>> 'container' are actually the same. An issue that does not exist in case A.
> 
> 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->setPatheStep(10);
>   sl->setStep(1);
> 
> was also wrong. I now need to check that the calls on the slider are always 
> on the same object.

Readability is a thing of many aspects, so you cannot take a single aspect and 
use that to compare completely different pieces of code that do completely 
different things.

You’ll have to stay at the specific example and explain why there is “no 
difference in readability” in _that_ example.

> You are confusing familiarity with simplicity.

You are mixing together readability and (some definition of) simplicity.

> It's simple that in the STL I can search for a value or a predicate condition 
> at the change of just an '_if'. Container::contains(), OTOH, is just familiar 
> (from previous Qt versions or other languages). It's neither simple in the 
> sense that it would be universal (as find/find_if is) nor is it efficient: 
> QVector::contains() is not overloaded on QLatin1String, e.g. 
> Std::find(), OTOH, will transparently use the QLatin1String, avoiding the 
> creation of a temporary QString. If contains() turns out to be a performance 
> bottleneck in profiling,

> the user can't do anything about it and needs to go to the universal 
> mechanism (std::find).

Good. Use the API that is most readable for the use case.

> This does not make the API simple to use. Maybe for people coming from other 
> languages. It introduces two different ways to do essentially the same thing, 
> advocating the ways that only works in a particular corner-case and refusing 
> to show the universal way (https://doc.qt.io/qt-5/qvector.html#indexOf). But 
> eventually, these developers _will_ need to search by a predicate, too, and 
> then they will fall back to a raw loop, sometime, in the case of removing, 
> introducing quadratic complexity. Had the Qt API and the docs not lied to 
> them by permanently showing contains() without mentioning that it's but a 
> short-cut for a corner-case, but shown them std::find or std::remove instead, 
> the developer would have been empowered.

That is a nice suggestion on how to improve the documentation. Which doesn’t 
have much to do with readability or simplicity of the API.

> As-is, Container::contains() dumbs the novice down by telling him a 
> fairy-tale that isn't applicable to actual professional work.

And yet std maps and sets will have Container::contains in C++20.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Marco Bubke]

On 20/05/2019 23:11, André Pönitz wrote:
> 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 
 and
 that of an STL container.
>>>
>>> Exhibit A:
>>>
>>>  foo().contains(x)
>>>
>>>
>>> Exhibit B:
>>>
>>>  {
>>>  ... container = foo();
>>>  std::find(container.begin(), container.end(), x) != 
>>> container.end();
>>>  }
>>
>> AFAIK contains is now part of the STL.
> 
> Define "now"...
> 
>> But to show a pattern I see often with Qt container is the use of contains 
>> and
>> then access the element with a key again. I that case the STL with iterators
>> leads you to better performing code. Ranges hopefully make much of this code
>> even more readable and performant.
> 
> Performance is always a combination of "raw run-time performance" and "time to
> market".

Yes, it is an economic decision too but there is not only "time to 
market" but "stay in the market" too. So you have be careful with your 
investments but if you do not invest enough you will loose too.

> There's no point in saving 30 processor cycles a day, even for a million 
> users,
> if that takes one hour of developer time to implement in a desktop 
> application.
> 
> People who disagree wouldn't ever touch Java or JS or any interpreted 
> language.
> Or std::ostream for that matter.
> 
> You know as well as I do that e.g. QList is heavily used in e.g. the Qt 
> Creator
> code base, and that this is absolutely *no* performance problem. Sure, it's 
> not
> used in *really* time-critical parts, but for the 100%-\epsilon 
> non-exceptional
> stuff it's just "good enough".
> 

I would agree that we have not much performance problems because most 
containers use only few entries but I ran in some. What I want to say is 
that there are solutions to that problem. For example with ranges you 
get readability and performance in many cases but if you are not 
familiar with that patter it looks strange. Very often the first 
reaction is to reject something because it looks unfamiliar as 
unreadable. Yes it is as you encounter it the first time but maybe it 
will be more readable in the long run.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Giuseppe D'Angelo via Development]

Il 21/05/19 10:26, Elvis Stansvik ha scritto:

They will not show up in the web search (I think).

They are however available in the debian-debug archive, see
https://wiki.debian.org/AutomaticDebugPackages


[snip]

Genuine question, are those just the debug builds of a release build, or 
are those debug builds? There is a difference when compiling Qt itself 
(amongst other things, release builds do not have Q_ASSERTs in them).


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
That's a hard one. Especially since very few could keep in their brain a 
list of the sizes of each and every one class from Qt. It also differs 
depending on architecture.


I know. That's my point: we can't just break this level of source 
compatibility.


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Tue, May 21, 2019 at 11:26 AM Elvis Stansvik  wrote:

> They will not show up in the web search (I think).
>
> They are however available in the debian-debug archive, see
> https://wiki.debian.org/AutomaticDebugPackages


Oh! You got me there. I was not aware of that. Thanks for pointing it out!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Tue, May 21, 2019 at 11:04 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> which ones of the following guarantee
> integrity of references, i.e., _heap allocate every single element?
>

That's a hard one. Especially since very few could keep in their brain a
list of the sizes of each and every one class from Qt. It also differs
depending on architecture.
For example:
QList may (does on x86, doesn't on x64),
while
QList for sure does.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mutz, Marc via Development]

Hi Lars,

There is a fine line between a proper partially-formed state and 
basically folding std::optional into every value class.


The former is a compile-time state. It is not observable at runtime, 
because any code which would observe a difference invokes UB. This is 
the same principle as C++11 data races, btw: Sequential Consistency for 
Data-Race-Free Programs.


The latter is a run-time property. As such, it will cost cpu cycles, 
death by a thousand paper cuts, sure, but cost. The cost is not 
necessarily in the extra branch, it's mostly in impairng the compiler's 
ability to optimize on the impossiblity of UB, which is important for, 
amongst other things, dead code removal. And while the partially-formed 
state can be extended to non-pimpled classes easily:


class QRect {
   int x, y, w, h;
public:
   QRect() = default;
};
QRect r; // partially-formed
r.x();   // compilers _already_ warn about this
QRect r = {}; // zero-initialized

QRect::isValid() has always been weird API, since it needs to reserve 
some valid, but non-normalized, values (remember, there's 
QRect::normalize()), to implement an optional absence of a rect. That 
should be modelled by optional, not by QRect itself.


To summarize: the partially-formed state is a compile-time only concept 
with no runtime cost and is applicable to all C++ types (from int over 
structs to Qt classes). It is consistent across all types, improves 
performance as well as readability of source code, and can be detected 
both at runtime (with asserts) and compile time (with static analysis).


A d == nullptr state as a valid value is a runtime property, has 
associated costs, and makes source code harder to understand.


It is, however, be an acceptable stop-gap measure, and here a compromise 
may emerge, for keeping old code working while preparing for a 
fully-implemented partially-formed state. This would mean we do assign 
meaning to a nullptr d consistent with the documented default value in 
Qt 5, but deprecate the use of the default ctor for establishing said 
value in the docs and warn about the use of a default-constructed object 
other than for destruction and assignment at runtime, even in release 
mode. In Qt 7, we then crash, as we do for some moved-from objects 
already.


Would that find your approval?

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Elvis Stansvik]

Den tis 21 maj 2019 kl 09:55 skrev Konstantin Shegunov :
>
> On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development 
>  wrote:
>>
>> Oh, a nullptr deref is pretty clear in a backtrace.
>
>
> Indeed, but my point is that it's relatively useless for the user (or for the 
> developer for that matter). As you pointed out the dev sees the nullptr 
> dereferencing instantly, the user just gets a crash. The assert is just 
> superfluous is what I'm saying.
>
>>
>> Even in a release
>> build, if you installed the debug symbol package that does with the
>> distribution's version of Qt.
>
>
> Humor me, will you? [1]

They will not show up in the web search (I think).

They are however available in the debian-debug archive, see
https://wiki.debian.org/AutomaticDebugPackages

"The automatic dbgsym packages are available from a separate archive.
Please fetch these from http://deb.debian.org/debian-debug/ (backed by
http://debug.mirrors.debian.org/debian-debug/). They are also
available on http://snapshot.debian.org/. They are only available for
stable, proposed-updates, backports, testing, unstable and
experimental at this point in time, optionally also under the
release's codename. "

E.g. I if you run testing, think you would add:

deb http://deb.debian.org/debian-debug/ testing-debug main

to your sources.list.

For Ubuntu, I think the archive is called http://ddebs.ubuntu.com. E.g. I have

deb http://ddebs.ubuntu.com bionic main restricted universe multiverse
deb http://ddebs.ubuntu.com bionic-updates main restricted universe multiverse

here on Kubuntu 18.04, and I have e.g:

[estan@newton ~]$ apt-cache policy libqt5widgets5-dbgsym
libqt5widgets5-dbgsym:
  Installerad: 5.9.5+dfsg-0ubuntu2
  Kandidat:5.9.5+dfsg-0ubuntu2
  Versionstabell:
 *** 5.9.5+dfsg-0ubuntu2 500
500 http://ddebs.ubuntu.com bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 5.9.5+dfsg-0ubuntu1 500
500 http://ddebs.ubuntu.com bionic/main amd64 Packages
[estan@newton ~]$

Cheers,
Elvis

>
>>
>> Please, you debug against a release build, and complain that you don't
>> get debug checks?
>
>
> To take your previous example.
>
> QPen pen1 = ~~~;
> QPen pen2 = std::move(pen1);
>
> // ... Some code
>
> pen1.color(); // Ooops
>
>> You're missing out on 4000 other checks that way, too!
>
>
> Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If 
> not, I get segfault. And as it happens I have enough builds, so even if that 
> happens and I can't switch kits and step into Qt, not every one user does 
> have that at their fingertips, however.
> Having documentation that spells such behaviour clearly, would be 
> satisfactory to me, that's why I was inquiring on *how* the problem, which is 
> a real one, can be mitigated.
>
>>
>> That said, I'm pretty sure that a static analyzer can find uses of
>> objects in partially-formed state with local analysis.
>
>
> QPen pen;
> QColor color = pen.color();
>
> If the analyzer can see the above as dangerous, i.e. touching an object with 
> an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied.
>
> [1]: 
> https://packages.debian.org/search?suite=testing=all=any=names=libqt5core
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Tue, May 21, 2019 at 9:34 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> [...]
> This does not make the API simple to use.


Actually it does. Simple, as "easily understood or done" and
self-explanatory, which isn't the case for the Q3Slider's constructor. Yes,
familiarity plays a role in that, but doesn't conflict with simplicity.


> It introduces two different ways to do essentially the
> same thing


So? The standard does that too. Before the lambda from c++11 we implemented
that idiom as a function object. We had the tools to do it and it worked
just as well. It can still be done instead of using the shorthand syntax.
I, personally, have found it rather curious that each new revision of the
language claims more expressiveness and simplicity, while the STL on the
other hand is restricted to the box of "universality"; in the end there's
nothing more universal than a naked C-style array.


> advocating the ways that only works in a particular
> corner-case and refusing to show the universal way
>

To paraphrase: You're confusing universality with simplicity.


> Had the Qt API and the docs not lied to them by
> permanently showing contains() without mentioning that it's but a
> short-cut for a corner-case, but shown them std::find or std::remove
> instead, the developer would have been empowered.


I object to the "corner-case" description, otherwise I'm with you
(partially). There should be some promotion in the docs of the iterators,
for example with regards to find-and-erase vs. remove() (e.g. QHash, QMap).
Especially whenever you actually need to get the value before removing.


> As-is, Container::contains() dumbs the novice down by telling him a
> fairy-tale
> that isn't applicable to actual professional work.
>

Actually it doesn't. I continue to claim that contains() is a convenient
shorthand when you are only interested whether something has something,
which if I had to pull a number off thin air probably constitutes ~5% up to
~10% of the cases where you search. This doesn't qualify for an edge-case,
and most certainly doesn't exclude professional work.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 20/05/19 19:08, NIkolai Marchenko ha scritto:
This rather nicely proves my point. Jason isn't even new to this list 
and he didn't realize the problems.
No, community as a whole did _not _ have "years and years" to port away 
from QList


Here's the practical QList test: which ones of the following guarantee 
integrity of references, i.e., _heap allocate every single element? (The 
problem is that someone may rely on this property. __Qt itself_ has 
codepaths relying on it.)


1) QList
2) QList
3) QList
4) QList
5) QList
6) QList
7) QList // where: struct MyPoint { int x, y; };
8) QList>
9) QList>
10) QList
11) QList
12) QList
13) QList
14) QList
15) QList
16) QList>
17) QList>

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Qt World Summit 2019 - CfP

[Kai Köhne]

Hi,

The deadline for submissions indeed got extended to * 2nd of June *... which is 
already end of next week!

So feel free to still submit proposals, but hurry up 

https://www.surveymonkey.com/r/K7PMKC8

Regards

Kai

> -Original Message-
> From: Interest  On Behalf Of Giuseppe
> D'Angelo via Interest
> Sent: Thursday, May 2, 2019 11:01 AM
> To: inter...@qt-project.org
> Subject: Re: [Interest] Qt World Summit 2019 - CfP
> 
> Hi,
> 
> On 23/04/2019 11:49, Kai Köhne wrote:
> > For Berlin, we (again) have an open Call for Presentations. The deadline for
> submissions is already *3rd of May* - that is, Friday next week!
> >
> >
> > https://blog.qt.io/blog/2019/03/27/qt-world-summit-2019-call-presentat
> > ions-open/
> >
> > Check out above link for the details.
> 
> Looks like the deadline has been moved to June, 2nd (quietly, haven't seen any
> announcement, and the blog post above has been silently patched).
> 
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
> http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Oh, a nullptr deref is pretty clear in a backtrace.


Indeed, but my point is that it's relatively useless for the user (or for
the developer for that matter). As you pointed out the dev sees the nullptr
dereferencing instantly, the user just gets a crash. The assert is just
superfluous is what I'm saying.


> Even in a release
> build, if you installed the debug symbol package that does with the
> distribution's version of Qt.
>

Humor me, will you? [1]


> Please, you debug against a release build, and complain that you don't
> get debug checks?
>

To take your previous example.

QPen pen1 = ~~~;
QPen pen2 = std::move(pen1);

// ... Some code

pen1.color(); // Ooops

You're missing out on 4000 other checks that way, too!
>

Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If
not, I get segfault. And as it happens I have enough builds, so even if
that happens and I can't switch kits and step into Qt, not every one user
does have that at their fingertips, however.
Having documentation that spells such behaviour clearly, would be
satisfactory to me, that's why I was inquiring on *how* the problem, which
is a real one, can be mitigated.


> That said, I'm pretty sure that a static analyzer can find uses of
> objects in partially-formed state with local analysis.
>

QPen pen;
QColor color = pen.color();

If the analyzer can see the above as dangerous, i.e. touching an object
with an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied.

[1]:
https://packages.debian.org/search?suite=testing=all=any=names=libqt5core
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Lars Knoll]

> On 20 May 2019, at 20:18, Mutz, Marc via Development 
>  wrote:
> 
> On 2019-05-20 17:16, Thiago Macieira wrote:
>> On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
>>> Or maybe we don't disagree at all and Thiago would accept allocating
>>> memory (or, by extension, anything that's noexcept(false)) as a very
>>> good reason to have a nullptr d?
>> I hadn't thought of noexcept, but let's be clear: yes, move constructors must
>> be noexcept. That might be the good reason why it can't reset to a valid
>> state.
> 
> What a feat it would be if Qt celebrated the 10th anniversary of the 
> publication of Elements of Programming with embracing the partially-formed 
> state :)
> 
> So, we seem to agree that moved-from objects may have d == nullptr. In the 
> following, let this be our premiss.

I fully agree with this/
> 
> Where we still, maybe, disagree, is whether d == nullptr is a valid state. 
> The difference is whether member functions other then destruction and 
> assignment check for a nullptr d. I'd propose that on classes under the above 
> premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the best balance 
> between safety and speed. I think it's important to make using moved-from 
> objects an error, because it is. Trying to pamper it over by assigning some 
> magic meaning to a nullptr d is going to cause more problems than it solves 
> (std::variant::valueless_by_exception, anyone?).

If the default constructed object has a pointer to a shared_null or similar, I 
agree that Q_ASSERT(d) is the best option. But I’d like to question that. IMO 
we should reconsider that and change the default constructor to also set d to a 
nullptr.
> 
> If and when we accept this as policy going forward, the next question 
> becomes: What does the default ctor do? I fully realize that after decades of 
> constructing magic values at default construction time, Qt is in no position 
> to make default constructors set d = nullptr.

Why? I see no reason why we couldn’t do this and stay 100% source compatible. 
Yes, it would require checking d for nullptr in all methods, but I don’t think 
that’s costing a lot. And we gain something because default constructed objects 
don’t require a relocation to find the shared_null.

> For existing classes, the documented behaviour of the default constructor is 
> to establish a particular state (cf. QPen). But at least for new classes, we 
> should really think about having the default ctor do nothing more than d = 
> nullptr. And maybe deprecate the default constructor's value for Qt 7 or 8.

Agree with new classes, but as said above, I think we should strongly consider 
doing this for existing classes as well.
> 
> Why is a almost-no-op default ctor so important? Performance, yes. Noexcept, 
> yes. And there's need for this. Grep Qt::Initialization. People _need_ the 
> default ctors to do less work. Let's give it to them.

Fully agree here.
> 
> But I'd like to focus on something else here: Qt likes to pride itself for 
> good API design. So let's look at it from that angle:
> 
>   QPen pen1 = ~~~;
>   QPen pen2 = std::move(pen1);
>   QPen pen3;
> 
> What's the state of 'pen1' now? Well, QPen is actually a class that sets d = 
> nullptr in the moved-from object. So pen1 does not represent a value. This 
> behaviour is in Qt for ten(!) minor releases now. I didn't find a bugreport 
> about that. What about pen3? Well, black, solid, width=1 pen. Why do I know? 
> Because I looked it up. It makes the code hard to understand, because for 
> each class, you need to know what the default constructor does. Worse: We 
> don't know what the intent of the developer is here. Does she want to create 
> (a) a black pen, or does she (b) simply want to have _a_ pen, so she can 
> specify later what it should be? We don't know. We need to scan the code 
> further.

Having the default constructor set d to a nullptr nicely solves that. Pen1 and 
pen3 will have the same state, namely the one you get with a default 
constructor.

Cheers,
Lars

> 
> What is striking here is that a moved-from pen is _different_ than a 
> default-constructed one. Wouldn't it be ore intuitive if the states were the 
> same?
> 
> Under Stepanov's model
> 
>   QPen pen1 = Qt::black; // clearly (a)
>   QPen pen2; // clearly (b)
> 
> it's 100% clear that pen2 is just there to be assigned to later. So, (b). It 
> cannot possibly be (a), because a default-constructed QPen object does not 
> represent a valid pen. Furthermore, when pen1 is moved from, it will end up 
> in the same state as pen2 - partially-formed.
> 
> Can it get any simpler?
> 
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

Hi Thiago!

Thanks a lot for the information!

However, the streaming classes are absolutely no replacement for the DOM 
classes. In
theory yes, they both read and write XML. In reality they are different to a 
degree that
it is practically impossible to replace DOM by stream. For legacy code anway. 

Even for new code the stream API is simply to bad to use it. Appart from speed, 
DOM is far
superiorer for every use case. The resulting code is, compared to the DOM 
solution,
impractical and maintaining it is a pain.

Unlucky me. Deprecation of these two components literally broke every 
application I have
ever written using Qt. I hope they will have new maintainers some day.

> > Is it correct that the Qt XML and Qt Xml Patterns components are both
> > deprecated?
> 
> Yes, they are.
> 
> > 
> > If yes, are there any details known like:
> > - How long or up to which Qt version will these components be part of Qt?
> > - Will replacment components be available?
> 
> The replacement for QtXml are the streaming classes in QtCore. They've been 
> available for 10 years.
> 
> There is no replacement for the XMLPatterns module.
> 
> > - Are security fixes still be implemented?
> 
> Yes, definitely, for as long as we ship them plus 5 years.
> 
> > - Are the deprecations irrevocable?
> 
> No. Deprecations are only irrevocable when we want to get rid of code that is 
> in the way of making progress, such as the QList discussion. Those two 
> modules 
> are not in the way of anything else, so the decision can change.
> 
> All it takes is someone stepping up to maintain either or both of them.
> 

-- 
Best Regards, 
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HDR Support in Qt

[Boudewijn Rempt via Development]

On dinsdag 21 mei 2019 02:04:42 CEST Quinn Romanek via Development wrote:

> Is there any current support/plan to support HDR pixel formats within Qt?

Dmitry prepared a number of patches to make it possible to display HDR images 
in Qt:


Implement openGL surface color space selection in Angle 
https://codereview.qt-project.org/#/c/252177/

Implement color space selection for QSurfaceFormat 
https://codereview.qt-project.org/#/c/253242/

Implement color conversion for the backing store texture (conflicts with 
the work by Allan) https://codereview.qt-project.org/#/c/252179/

Return QScreen's HMONITOR handle via QPlatformNativeInterface 
https://codereview.qt-project.org/#/c/252181/

Implement a manual test for checking is HDR features work 
https://codereview.qt-project.org/#/c/252812/

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mutz, Marc via Development]

On 2019-05-20 22:58, 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) version of Qt from the repo. Granted it may be
my own fault, but in this case the assert isn't tripped and this code
simply segfaults for reasons that aren't so obvious.


Oh, a nullptr deref is pretty clear in a backtrace. Even in a release 
build, if you installed the debug symbol package that does with the 
distribution's version of Qt.



Any suggestions
how to mitigate that? Somehow *suggest* to the user that [s]he's
supposed to build in debug mode otherwise they're on their own?


Please, you debug against a release build, and complain that you don't 
get debug checks?


marc:~/Qt/qt5/qtbase$ git grep -we Q_ASSERT -- src | grep .cpp: | wc -l
3907

You're missing out on 4000 other checks that way, too!

And I'm pretty sure that there's a way to keep the Q_ASSERTs in release 
mode.


That said, I'm pretty sure that a static analyzer can find uses of 
objects in partially-formed state with local analysis. Proof:


   const char *p;

    complicated code ~

   char ch = *p; // WARNING: p might be used uninitialized in this 
function


I guess what's missing is a way to tag processes in which 
partially-formed states are created for the compiler.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Mutz, Marc via Development]

On 2019-05-20 23:43, André Pönitz wrote:
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:
> > >
> > >  {
> > >  ... container = foo();
> > >  std::find(container.begin(), container.end(), x) !=
> > > container.end();
> > >  }
> >
> > And now do the same thing [...]
>
> No, I won't.
>
> You were claiming something universally valid (\forall x "There is
> no difference ...")

I never said that there's no difference. I said there's no difference 
in
readability. Don't confuse familiarity with simplicity (or 
readability).


Indeed, you claimed only "no difference in readability".

But I wouldn't agree that there is "no difference in readabilty" 
between

Exhibit A and B above.

In case B one e.g. would need to check whether all _four_ occurances of
'container' are actually the same. An issue that does not exist in case 
A.


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->setPatheStep(10);
   sl->setStep(1);

was also wrong. I now need to check that the calls on the slider are 
always on the same object.


You are confusing familiarity with simplicity. It's simple that in the 
STL I can search for a value or a predicate condition at the change of 
just an '_if'. Container::contains(), OTOH, is just familiar (from 
previous Qt versions or other languages). It's neither simple in the 
sense that it would be universal (as find/find_if is) nor is it 
efficient: QVector::contains() is not overloaded on 
QLatin1String, e.g. Std::find(), OTOH, will transparently use the 
QLatin1String, avoiding the creation of a temporary QString. If 
contains() turns out to be a performance bottleneck in profiling, the 
user can't do anything about it and needs to go to the universal 
mechanism (std::find).


This does not make the API simple to use. Maybe for people coming from 
other languages. It introduces two different ways to do essentially the 
same thing, advocating the ways that only works in a particular 
corner-case and refusing to show the universal way 
(https://doc.qt.io/qt-5/qvector.html#indexOf). But eventually, these 
developers _will_ need to search by a predicate, too, and then they will 
fall back to a raw loop, sometime, in the case of removing, introducing 
quadratic complexity. Had the Qt API and the docs not lied to them by 
permanently showing contains() without mentioning that it's but a 
short-cut for a corner-case, but shown them std::find or std::remove 
instead, the developer would have been empowered. As-is, 
Container::contains() dumbs the novice down by telling him a fairy-tale 
that isn't applicable to actual professional work.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Mutz, Marc via Development]

On 2019-05-20 23:14, Konstantin Shegunov wrote:

On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development
 wrote:


All I'm saying is that there are tons of examples (QGradient) where
the
use of an owning container in the API is just a very bad idea and
limits
the implementor's freedom and/or performance. E.g. QGradient could
have
inline storage for two or three stops to avoid allocating memory for
the
most-common cases. I mean, QPainter is full of (QPoint *, int
nPoints)
APIs that surely were added just for performance. Ditto for QString,

btw. Nowadays, with views, we can have the same API, but have it
accept
many owning containers transparently. I'm not saying that there must
be
no owning containers in the API. But there is a lot of low-hanging
fruit
out there.


Okay, I can live with that, and I do see why it'd make sense in some
cases to iterate the data directly. But then as a container can have
many different iterables, it seems reasonable to consider adding a
couple of methods that return views and take it from there. Why the
push to remove the owning container(s) API? In time it may prove
you're right, so then we can migrate the getters to the view API and
eventually deprecate these methods. Or they could coexist, or w/e. The
point is why reach for the top if there's low-hanging fruit?


You need to have an idea where you'd like to go before you go there. The 
problem with co-existence is that you impose the lowest common 
demoninator of both methods on the class implementation. If you have a 
view, the impl needs to store the data, if you have an owning container 
API, it needs to store it (assuming CoW) in that exact container. So, 
yes, co-existence as a path to the goal of no raw containers in APIs, 
but not as the end state.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development