Re: [Development] Assistant WebKit/WebEngine support

[Thiago Macieira]

On Tuesday, 25 June 2019 18:08:28 PDT Thiago Macieira wrote:
> > Are you worried about the lack of security patches? I can see how that
> > matters for an ordinary browser implemented with Qt, but for Assistant
> > and Creator that exclusively display locally installed generated
> > compressed help files, security concerns are a lot lower.
> 
> Sure, but the fact that Qt Creator is using it could lead people to trying
> for a web browser.
> 
> Not to mention that even if Qt's help documents are safe, other documents
> you may want to view may not be so.

Actually, let me be even more clear: shipping software with known security 
issues that have been fixed elsewhere is unacceptable.  Please don't try to 
say "but this code isn't used in this application", it's very hard to prove 
that and obtain security exceptions in many companies.

At Intel, we simply can't. If Qt Creator begins depending on a version of a 
web engine that has open security issues whose fixes are available but not 
applied, we cannot ship it in our Linux distribution (Clear Linux). Other 
Linux distributions may have similar policies.

If the affected code isn't exercised, please prove so by removing the code 
from the build. This is usually more effort than applying the fix.

-- 
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] Assistant WebKit/WebEngine support

[Thiago Macieira]

On Tuesday, 25 June 2019 17:07:20 PDT Bastiaan Veelo wrote:
> > at this point, what's speaking againt qtwebkit is its track record of
> > release. Until it starts making regular releases again, I can't recommend
> > it. And Qt Creator (or any other application) shouldn't begin using it
> > again until those regular releases resume.
> 
> Are you worried about the lack of security patches? I can see how that
> matters for an ordinary browser implemented with Qt, but for Assistant
> and Creator that exclusively display locally installed generated
> compressed help files, security concerns are a lot lower.

Sure, but the fact that Qt Creator is using it could lead people to trying for 
a web browser.

Not to mention that even if Qt's help documents are safe, other documents you 
may want to view may not be so.

-- 
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] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 25/06/2019 18:16, Thiago Macieira wrote:

On Tuesday, 25 June 2019 09:05:21 PDT Konstantin Tokarev wrote:

It hasn't been updated in years. Don't use it, since it's clearly not
getting security updates.

New version is currently in development, and should be ready in time frame
of Qt 5.14 (at least functionality required for displaying help)

5.212 branch should be fine for use with local help files, e.g. you can take
fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/

Konstantin,

at this point, what's speaking againt qtwebkit is its track record of release.
Until it starts making regular releases again, I can't recommend it. And Qt
Creator (or any other application) shouldn't begin using it again until those
regular releases resume.


Are you worried about the lack of security patches? I can see how that 
matters for an ordinary browser implemented with Qt, but for Assistant 
and Creator that exclusively display locally installed generated 
compressed help files, security concerns are a lot lower.


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

Re: [Development] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 26/06/2019 00:15, Jean-Michaël Celerier wrote:
There's also Zeal which is a nice Qt-based documentation browser which 
covers much more than the current .qch offering: https://zealdocs.org/ 
& https://github.com/zealdocs/zeal


I see it used more and more.

Best,
Jean-Michaël

That's QWebView based (WebKit) pre Qt 5.6. Back then Assistant was great 
as well.


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

Re: [Development] Assistant WebKit/WebEngine support

[Jean-Michaël Celerier]

> Feel free to correct/critique my assessment and to add more options if
you see any. Otherwise: chose your poison.

There's also Zeal which is a nice Qt-based documentation browser which
covers much more than the current .qch offering: https://zealdocs.org/ &
https://github.com/zealdocs/zeal

I see it used more and more.

Best,
Jean-Michaël


On Tue, Jun 25, 2019 at 11:54 PM Konrad Rosenbaum  wrote:

> Hi,
>
> On 6/25/19 9:59 PM, Tor Arne Vestbø wrote:
> > On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
> >> Pardon my lingo,
> > You should be able to communicate your points without that kind of
> lingo. Try better.
> >
> >> It is documentation for developers for crying out loud! Its purpose is
> not to win any design prices, but to educate the developers.
> > Please stop putting up straw-men, it’s not helping this discussion at
> all.
>
> Okay, let's formulate this in a way that hopefully doesn't offend you
> and doesn't seem like a straw-man to you.
>
>
> Qt6 has a couple of options for documentation, none of them are ideal:
>
>
> Option 1: leave everything as is with a QTextBrowser based assistant and
> some tweaks in the qch files.
> Pros: no additional work required; all current features and use cases
> stay supported; good enough for a lot of developers
> Con: looks ugly enough to actually offend visually sensitive developers.
>
>
> Option 2: put some elbow grease into QTextBrowser and make it understand
> some more tags and more CSS.
> Pros: documentation becomes visually more pleasing; minimal dependencies
> by assistant - easy to build and easy to bundle with applications;
> embedding in Creator or KDevelop etc. stays easy to do
> Positive side effect: users will love it, since it becomes much easier
> and flexible to use QTextBrowser in their own applications
> Con: someone actually has to put in the work
>
>
> Option 3: bring back WebKit
> Pros: looks beautiful; uses up less memory than WebEngine
> Cons: someone has to put up lots of work to actually support WebKit;
> uses up lots more memory than QTextBrowser; adds a dependency to
> assistant (makes it less useful for redistribution); embedding in IDEs
> is slightly more complex and adds a dependency
>
>
> Option 4: convert to WebEngine
> Pros: looks great; currently supported browser engine, only little
> porting work
> Cons: horrible memory footprint; acute terminal featuritis; adds lots of
> dependencies (disqualifies it for most/many people redistributing it);
> does not work on all platforms supported by Qt (makes assistant less
> useful or even useless to those users); embedding in IDEs becomes much
> more difficult (dependencies and #ifdef's for unsupported platforms)
>
>
> Option 5: use WebView
> Pros: might look good
> Cons: either looks bad or adds whatever component WebView wants to use
> as a dependency; unpredictable results
>
>
> Option 6: use plain platform browser to show local files
> Pros: minimal footprint; assistant can be retired; guaranteed good
> rendering
> Cons: you never know which browser the user installs; abandon QCH
> format; implementing search becomes a horrible mess of JS and other
> files - requires extensive tool support to generate this - doubtful that
> it will always work; forget embedded viewers - this would require
> WebEngine or WebKit again; some users will hate the fact that assistant
> is missing or at least unsupported
>
>
> Option 7: platform browser plus server process to deliver help via local
> HTTP
> Pros: like Option 6, but search becomes easier to implement
> Cons: like Option 6, except search; someone needs to implement a simple
> HTTP server (not that hard, but requires some work) and a search engine
> (slightly harder, but solvable)
>
>
> My personal favorite would be Option 2 (better QTextBrowser), followed
> by Options 1 (status quo) and 3 (WebKit) in no particular order. But
> since I'm not willing to put in any serious work or pay for it - my vote
> does not count - I'm just a user. ;)
>
> Feel free to correct/critique my assessment and to add more options if
> you see any. Otherwise: chose your poison.
>
>
>
> Konrad
>
>
> ___
> 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

[Konrad Rosenbaum]

Hi,

On 6/25/19 9:59 PM, Tor Arne Vestbø wrote:
> On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
>> Pardon my lingo,
> You should be able to communicate your points without that kind of lingo. Try 
> better.
>
>> It is documentation for developers for crying out loud! Its purpose is not 
>> to win any design prices, but to educate the developers.
> Please stop putting up straw-men, it’s not helping this discussion at all.

Okay, let's formulate this in a way that hopefully doesn't offend you
and doesn't seem like a straw-man to you.


Qt6 has a couple of options for documentation, none of them are ideal:


Option 1: leave everything as is with a QTextBrowser based assistant and
some tweaks in the qch files.
Pros: no additional work required; all current features and use cases
stay supported; good enough for a lot of developers
Con: looks ugly enough to actually offend visually sensitive developers.


Option 2: put some elbow grease into QTextBrowser and make it understand
some more tags and more CSS.
Pros: documentation becomes visually more pleasing; minimal dependencies
by assistant - easy to build and easy to bundle with applications;
embedding in Creator or KDevelop etc. stays easy to do
Positive side effect: users will love it, since it becomes much easier
and flexible to use QTextBrowser in their own applications
Con: someone actually has to put in the work


Option 3: bring back WebKit
Pros: looks beautiful; uses up less memory than WebEngine
Cons: someone has to put up lots of work to actually support WebKit;
uses up lots more memory than QTextBrowser; adds a dependency to
assistant (makes it less useful for redistribution); embedding in IDEs
is slightly more complex and adds a dependency


Option 4: convert to WebEngine
Pros: looks great; currently supported browser engine, only little
porting work
Cons: horrible memory footprint; acute terminal featuritis; adds lots of
dependencies (disqualifies it for most/many people redistributing it);
does not work on all platforms supported by Qt (makes assistant less
useful or even useless to those users); embedding in IDEs becomes much
more difficult (dependencies and #ifdef's for unsupported platforms)


Option 5: use WebView
Pros: might look good
Cons: either looks bad or adds whatever component WebView wants to use
as a dependency; unpredictable results


Option 6: use plain platform browser to show local files
Pros: minimal footprint; assistant can be retired; guaranteed good rendering
Cons: you never know which browser the user installs; abandon QCH
format; implementing search becomes a horrible mess of JS and other
files - requires extensive tool support to generate this - doubtful that
it will always work; forget embedded viewers - this would require
WebEngine or WebKit again; some users will hate the fact that assistant
is missing or at least unsupported


Option 7: platform browser plus server process to deliver help via local
HTTP
Pros: like Option 6, but search becomes easier to implement
Cons: like Option 6, except search; someone needs to implement a simple
HTTP server (not that hard, but requires some work) and a search engine
(slightly harder, but solvable)


My personal favorite would be Option 2 (better QTextBrowser), followed
by Options 1 (status quo) and 3 (WebKit) in no particular order. But
since I'm not willing to put in any serious work or pay for it - my vote
does not count - I'm just a user. ;)

Feel free to correct/critique my assessment and to add more options if
you see any. Otherwise: chose your poison.



    Konrad




pEpkey.asc
Description: application/pgp-keys
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Giuseppe D'Angelo via Development]

Il 25/06/19 16:30, Palaraja, Kavindra ha scritto:

The idea is to have parity in the sense of 1:1 appearance of how the 
documentation looks like.

Here's a ticket that hasn't gone very far:

https://bugreports.qt.io/browse/QTCREATORBUG-15887

Can we keep the personal attacks out of this and perhaps stick to the issue? 
I'm definitely not lying. I don't see any tables being rendered the way tables 
should be rendered in HTML. Unless I'm losing my eyesight?

You could check:https://doc.qt.io/QtApplicationManager/manifest.html  none of 
that alternating row color or design shows up. As a Technical Writer, I expect 
the output to look like that. So why doesn't it? I'm not attached to WebEngine, 
I just want to get the expected output.


Because the Qt text document classes (*) don't support that kind of styling:


https://doc.qt.io/qt-5/richtext-html-subset.html


They *do* support tables, and I'll grant, they look horrible. And they 
do support background colours for table cells, meaning that a table with 
alternating row colours could in principle be produced, albeit not by 
using fancy CSS nth-odd/even selectors.


(By the way, I have no idea how the Assistant docs are currently 
generated and styled.)




Anyhow, let me raise some further questions:

* Is the whole idea of moving to a web browser driven exclusively by 
these missing features in terms of styling / HTML / JS support, that 
prevent more unification between content offered on the web vs. the one 
integrated in QtHelp?


** Have such missing features been identified, in the first place? At 
least the ones we care about w.r.t. Qt's own help.


** Have feature requests been filed against QTextDocument? Have their 
costs then been estimated? (Again, in the principle of EYODF)


** Have workarounds been discussed?

** Was it simply deemed not worth doing such work when we have another 
working solution, "easy" to reach, and that will survive any 
redesign/restyling of the docs that is going to happen every now and then?



* Is the whole idea part of a bigger plan of further improving QtHelp, 
e.g. make it possible to load external resources through it such as 
videos, community forums, PDFs, you name it? Basically, out of reach for 
any effort at possibly improving QTD.




The thing is, the arguments _against_ this move are many. If you combine 
them with the ordinary human behaviour where "fear of change" trumps 
"perceived benefits" every single time, you'll get a very agitated audience.



(*) you're officially a Qt old-school if you remember the codename for them.

--
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] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 25/06/2019 21:30, Konrad Rosenbaum wrote:


It is documentation for developers for crying out loud!



No it is not. Assistant is distributed as a help viewer, to be 
distributed along with applications for use by the customers of your 
customers. As soon as QTextBrowser in its current sorry state of 
rendering HTML became the sole supported browser, it completely FAILED 
that purpose. Not just "a little bit more Spartan but we can live with 
it", no, it leaves out *critical* information! It is completely 
undistributable in our case.


Firstly the fonts are a complete mess, with different elements having 
unrelated sizes, weights and types. If you zoom, only the headings zoom!


We use styled  to accomplish frames around labels to refer to 
elements in screen shots[1] that vanish in QTextBrowser.


We use CSS styled tables to render hyperlinked menus that occur in the 
user interface, and the borders should be there because they are there 
in the UI; they are not in QTextBrowser. We have hundreds of these menus 
in multiple translations, and screen shots are just not going to work in 
a 400-page manual. Try keeping those up to date. And what about those 
hyperlinks? Don't you dare suggest those HTML 1.0 tables.


We use CSS styles description links to highlight call-outs[2]. They 
don't work in QTextBrowser.


Deciding that it was okay to drop Qt WebKit in Qt Assistant because with 
some tweaking of your content the Qt documentation for Qt developers 
could be made kind of acceptable to some people was a complete let down 
and Qt's biggest mistake so far. Pardon my lingo.


Bastiaan.

[1] 
https://www.sarc.nl/images/manuals/pias/htmlEN/loading_module_gui.html#loading_gui_layout

[2] https://www.sarc.nl/images/manuals/pias/htmlEN/fwy_export.html

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

Re: [Development] Assistant WebKit/WebEngine support

[Tor Arne Vestbø]

> On 25 Jun 2019, at 22:53, André Pönitz  wrote:
> 
> On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote:
>>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
>>> 
>>> Pardon my lingo,
>> 
>> You should be able to communicate your points without that kind of lingo. Try
>> better.
>> 
>>> It is documentation for developers for crying out loud! Its purpose is not 
>>> to
>>> win any design prices, but to educate the developers.
>> 
>> Please stop putting up straw-men, it’s not helping this discussion at all.
> 
> I find it actually quite helpful and to the point.

Huh? You find straw-men helpful and to the point?

> 
>>> As a developer I expect it to frigging be there, no matter the look. That's
>>> it.
>> 
>> As a developer I expect documenation on par with other projects we like to
>> compare ourselves with, both in terms of features/usability and visual
>> asthetics. 
> 
> So we have different kinds of developers, and that's fine and expected.

Exactly my point. I wanted to add another data point.

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

Re: [Development] Assistant WebKit/WebEngine support

[André Pönitz]

On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote:
> > On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
> > 
> > Pardon my lingo,
> 
> You should be able to communicate your points without that kind of lingo. Try
> better.
> 
> > It is documentation for developers for crying out loud! Its purpose is not 
> > to
> > win any design prices, but to educate the developers.
> 
> Please stop putting up straw-men, it’s not helping this discussion at all.

I find it actually quite helpful and to the point.
 
> > As a developer I expect it to frigging be there, no matter the look. That's
> > it.
> 
> As a developer I expect documenation on par with other projects we like to
> compare ourselves with, both in terms of features/usability and visual
> asthetics. 

So we have different kinds of developers, and that's fine and expected.

Also, different people have different ideas on what is usable, or
aethetic. E.g. the animations build into doc.qt.io are quite the opposite
of what I consider usable or even aesthetic. Already the idea to have
animated help in Creator makes me cringe.

The discussed idea to make the WebEngine dependency mandatory would
effectively mean that some people will not be able to use the help plugin
at all anymore, and for me personally that I will stop building and
consequently occasionally using ("testing") it. That's definitely an
disadvantage for me, which I dislike.

Creator so far tried to be usable for a large audience, and even if clearly
not perfect I think we are on track there. The problem is there's no
obvious "one size fits all", especially when it comes to aestetics.  The
current state of the code base allows in principle "full webbrowser for
beefy machines" usecase as well as getting most of the functionality in
restricted setups, and I find it somewhat strange that a party that
ships a custom Creator built anyway pushes so hard on a solution that
is harmful for some instead of simply building their help plugin in
their favourite configuration.

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

Re: [Development] Assistant WebKit/WebEngine support

[Tor Arne Vestbø]

> On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
> 
> Pardon my lingo,

You should be able to communicate your points without that kind of lingo. Try 
better.

> It is documentation for developers for crying out loud! Its purpose is not to 
> win any design prices, but to educate the developers.

Please stop putting up straw-men, it’s not helping this discussion at all.

> As a developer I expect it to frigging be there, no matter the look. That's 
> it.

As a developer I expect documenation on par with other projects we like to 
compare ourselves with, both in terms of features/usability and visual 
asthetics. 

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

Re: [Development] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 21/06/2019 11:08, Bastiaan Veelo wrote:
[...] The best solution would therefore be, in my opinion, to change 
the order of compilation, apply the existing patch, and consider 
refactorings and unifications thereafter.


I went ahead and did this. https://github.com/veelo/qttools is a fork of 
qttools for the sole purpose of compiling Qt Assistant against a stock 
binary distribution of Qt as an independent application. It compiles 
quickly and conveniently using Qt Creator. The 5.13_assistant_webengine 
branch contains the WebEngine support by Allan Sandfeld Jensen and 
several additional fixes of my own. At least I have a working solution 
without the need to wait until the next morning for compilation of Qt 
and WebEngine to complete, with reasonable odds of being able to keep in 
sync with upstream and future releases.


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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

25.06.2019, 22:32, "Bastiaan Veelo" :
> On 21/05/2019 14:50, Konstantin Tokarev wrote:
>>  21.05.2019, 15:47, "Bastiaan Veelo" :
>>>  On 20/05/2019 19:02, Konstantin Tokarev wrote:
    [...] 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
>
> I decided not to compile Qt myself any more, because I can't wait until
> the next day for it to finish each time. Therefore I have forked qttools
> and am compiling Assistant separately using a stock binary Qt
> distribution. For some reason though, 5.10 is completely absent from the
> installer. I'll have to let the WebKit approach rest for the time being.

You can use these binaries with Qt 5.12:

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


-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Konrad Rosenbaum]

Hi,

...my 2 cents or so...

On 6/25/19 4:30 PM, Palaraja, Kavindra wrote:
> No, parity isn't Google's search box. There's already a search feature in 
> Creator.
>
> No, not "The Qt Company is hiring" either.
>
> The idea is to have parity in the sense of 1:1 appearance of how the 
> documentation looks like.

Pardon my lingo, but I do not give a rats furry behind about how it
looks and whether it is on full parity with the way it is shown in a
browser as long as I have all the content.

It is documentation for developers for crying out loud! Its purpose is
not to win any design prices, but to educate the developers.

> Here's a ticket that hasn't gone very far:
>
> https://bugreports.qt.io/browse/QTCREATORBUG-15887
>
> Can we keep the personal attacks out of this and perhaps stick to the issue? 
> I'm definitely not lying. I don't see any tables being rendered the way 
> tables should be rendered in HTML. Unless I'm losing my eyesight?

Sorry, but I just tried a very simple example with QTextBrowser:

In my book this is exactly like a table should be rendered. Granted it
is not very flashy looking, but it is definitely a table and it has borders.

Source:

#include 
#include 

int main(int ac,char**av)
{
  QApplication a(ac,av);
  QTextBrowser tb;
  tb.setHtml("helloworldwoohoo!");
  tb.show();
  return a.exec();
}

(embedding 

Re: [Development] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 21/05/2019 14:50, Konstantin Tokarev wrote:

21.05.2019, 15:47, "Bastiaan Veelo" :

On 20/05/2019 19:02, Konstantin Tokarev wrote:

  [...] 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



I decided not to compile Qt myself any more, because I can't wait until 
the next day for it to finish each time. Therefore I have forked qttools 
and am compiling Assistant separately using a stock binary Qt 
distribution. For some reason though, 5.10 is completely absent from the 
installer. I'll have to let the WebKit approach rest for the time being.


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

Re: [Development] Failing auto-tests (SSL)

[Timur Pocheptsov]

Thanks to all who helped resolve the merge conflicts, and Liang who helped with 
5.12->xxxs merges. Ah, and of course Mårten,  the author of original patches.

Best regards,
Timur.



From: Volker Hilsheimer
Sent: Tuesday, June 25, 2019 8:55 PM
To: development@qt-project.org
Cc: Timur Pocheptsov
Subject: Re: [Development] Failing auto-tests (SSL)

Great work resolving this issue!

Volker


On 25 Jun 2019, at 20:13, Timur Pocheptsov 
mailto:timur.pochept...@qt.io>> wrote:

5.13 is also good now.

Best regards,
Timur.

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Timur Pocheptsov 
mailto:timur.pochept...@qt.io>>
Sent: Tuesday, June 25, 2019 6:51 PM
To: development@qt-project.org
Subject: Re: [Development] Failing auto-tests (SSL)

Update: 5.9 and dev are fixed now. Merge 5.12->5.13 is still integrating.

Best regards,
   Timur.

From: Timur Pocheptsov
Sent: Tuesday, June 25, 2019 10:23 AM
To: development@qt-project.org
Subject: Failing auto-tests (SSL)

Hi all,

The soon-expiring apache's certificate on our network test server was replaced 
yesterday.
This was done too fast without properly fixing our tests/replacing the certs we
have locally. The affected tests are tst_qsslsocket/tst_qnetworkreply. As of 
now - we fixed
the problem in 5.12 and staging in 5.9. 5.13/dev are still affected/broken. We 
working
on this and I'll provide more info when it's done (and Liang can tell us then 
the changes from
5.12 are in 5.13)

Best regards,
   Timur.
___
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] Failing auto-tests (SSL)

[Volker Hilsheimer]

Great work resolving this issue!

Volker


On 25 Jun 2019, at 20:13, Timur Pocheptsov 
mailto:timur.pochept...@qt.io>> wrote:

5.13 is also good now.

Best regards,
Timur.

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Timur Pocheptsov 
mailto:timur.pochept...@qt.io>>
Sent: Tuesday, June 25, 2019 6:51 PM
To: development@qt-project.org
Subject: Re: [Development] Failing auto-tests (SSL)

Update: 5.9 and dev are fixed now. Merge 5.12->5.13 is still integrating.

Best regards,
   Timur.

From: Timur Pocheptsov
Sent: Tuesday, June 25, 2019 10:23 AM
To: development@qt-project.org
Subject: Failing auto-tests (SSL)

Hi all,

The soon-expiring apache's certificate on our network test server was replaced 
yesterday.
This was done too fast without properly fixing our tests/replacing the certs we
have locally. The affected tests are tst_qsslsocket/tst_qnetworkreply. As of 
now - we fixed
the problem in 5.12 and staging in 5.9. 5.13/dev are still affected/broken. We 
working
on this and I'll provide more info when it's done (and Liang can tell us then 
the changes from
5.12 are in 5.13)

Best regards,
   Timur.
___
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] Failing auto-tests (SSL)

[Timur Pocheptsov]

5.13 is also good now.

Best regards,
Timur.

From: Development  on behalf of Timur 
Pocheptsov 
Sent: Tuesday, June 25, 2019 6:51 PM
To: development@qt-project.org
Subject: Re: [Development] Failing auto-tests (SSL)

Update: 5.9 and dev are fixed now. Merge 5.12->5.13 is still integrating.

Best regards,
   Timur.

From: Timur Pocheptsov
Sent: Tuesday, June 25, 2019 10:23 AM
To: development@qt-project.org
Subject: Failing auto-tests (SSL)

Hi all,

The soon-expiring apache's certificate on our network test server was replaced 
yesterday.
This was done too fast without properly fixing our tests/replacing the certs we
have locally. The affected tests are tst_qsslsocket/tst_qnetworkreply. As of 
now - we fixed
the problem in 5.12 and staging in 5.9. 5.13/dev are still affected/broken. We 
working
on this and I'll provide more info when it's done (and Liang can tell us then 
the changes from
5.12 are in 5.13)

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

Re: [Development] Assistant WebKit/WebEngine support

[André Pönitz]

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

Sure, that's understood. I wanted to get a gut feeling on how
much gain will there for how much gain.

> while minimal configuration with existing options makes a good
> balance IMO.

That's probably easiest, but leaves e.g. the whole JS machinery intact
which I do not really want to have for a QTextBrowser-with-table-borders
replacement.

Of course, the situation is in no way worse than what WebEngine would
provide.

> > The result was ok-ish size-wise (and for me definitely preferable over
> > WebEngine) but the question is where to put to cut. In some setups
> > ("Want to see DevDays videos") even cutting multimedia plugins won't be
> > accepted by everyone. I.e. the "need" for a "full browser" is likely
> > to always exist, and that's currently served by "use external help".
> 
> We have MediaFoundation player on Windows these days so it can work
> without pulling in Qt Multimedia

> and uses system-provided codecs, so
> enabling multimedia won't add that much. However, for multimedia content
> there is always an option to add external link, as this is not the kind of
> documentation you really need to have inside your IDE or in similar context.

Definitely not. But it's a point that some people tend to cite as
an "advantage", nightmare or not...

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

Re: [Development] Failing auto-tests (SSL)

[Timur Pocheptsov]

Update: 5.9 and dev are fixed now. Merge 5.12->5.13 is still integrating.

Best regards,
   Timur.

From: Timur Pocheptsov
Sent: Tuesday, June 25, 2019 10:23 AM
To: development@qt-project.org
Subject: Failing auto-tests (SSL)

Hi all,

The soon-expiring apache's certificate on our network test server was replaced 
yesterday.
This was done too fast without properly fixing our tests/replacing the certs we
have locally. The affected tests are tst_qsslsocket/tst_qnetworkreply. As of 
now - we fixed
the problem in 5.12 and staging in 5.9. 5.13/dev are still affected/broken. We 
working
on this and I'll provide more info when it's done (and Liang can tell us then 
the changes from
5.12 are in 5.13)

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

Re: [Development] Assistant WebKit/WebEngine support

[Thiago Macieira]

On Tuesday, 25 June 2019 09:05:21 PDT Konstantin Tokarev wrote:
> > It hasn't been updated in years. Don't use it, since it's clearly not
> > getting security updates.
> 
> New version is currently in development, and should be ready in time frame
> of Qt 5.14 (at least functionality required for displaying help)
> 
> 5.212 branch should be fine for use with local help files, e.g. you can take
> fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/

Konstantin,

at this point, what's speaking againt qtwebkit is its track record of release. 
Until it starts making regular releases again, I can't recommend it. And Qt 
Creator (or any other application) shouldn't begin using it again until those 
regular releases resume.

-- 
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] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

25.06.2019, 19:01, "Thiago Macieira" :
> On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote:
>>  What is the state of QtWebKit(2)
>
> It hasn't been updated in years. Don't use it, since it's clearly not getting
> security updates.

New version is currently in development, and should be ready in time frame of
Qt 5.14 (at least functionality required for displaying help)

5.212 branch should be fine for use with local help files, e.g. you can take 
fresh\
from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Thiago Macieira]

On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote:
> What is the state of QtWebKit(2)

It hasn't been updated in years. Don't use it, since it's clearly not getting 
security updates.

-- 
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] Assistant WebKit/WebEngine support

[Palaraja, Kavindra]

No, parity isn't Google's search box. There's already a search feature in 
Creator.

No, not "The Qt Company is hiring" either.

The idea is to have parity in the sense of 1:1 appearance of how the 
documentation looks like.

Here's a ticket that hasn't gone very far:

https://bugreports.qt.io/browse/QTCREATORBUG-15887

Can we keep the personal attacks out of this and perhaps stick to the issue? 
I'm definitely not lying. I don't see any tables being rendered the way tables 
should be rendered in HTML. Unless I'm losing my eyesight?

You could check: https://doc.qt.io/QtApplicationManager/manifest.html none of 
that alternating row color or design shows up. As a Technical Writer, I expect 
the output to look like that. So why doesn't it? I'm not attached to WebEngine, 
I just want to get the expected output.

Kavindra.

On 25.06.19, 16:12, "Development on behalf of Giuseppe D'Angelo via 
Development"  wrote:

Hi,

Il 25/06/19 14:28, Palaraja, Kavindra ha scritto:
>
> Hi Kirill,
>
> I can’t speak for the size of WebEngine or the complexity of this
> solution, but I can speak for the look & feel of the documentation.
>
> The current situation with Qt Creator’s documentation is not about how
> wonderful the content would look like. It’s about the basics of what
> developers expect to get when they look at the documentation. It’s to
> match what we have on https://doc.qt.io in the first place. I’m talking
> about _/parity/_. I’m not asking for some crazy animation – just a 1:1
> with the official Qt documentation that’s published online.

Sorry, but now I have to play devil's advocate:

Does that parity include things like Google search integration, or the
current ads like "The Qt Company is hiring", not  and so on? The moment
you start customizing things


>
>   * We can’t display a real code blocks in Creator – you don’t get that
> black box with syntax highlighted code snippets in Creator. When you
> document this, you use \code, \endcode, or \badcode in qdoc. None of
> this is actually being displayed as expected in Creator.

Is this a limitation of QTextBrowser or is the style applied for the
docs there stripping out code highlighting? I know for a fact that
 works in QTextBrowser.

> If source code was not behaving as expected when compiled, you’d
> consider it a bug right? So why is this different because it’s
> documentation? Because it’s less important?
>
>   * We can’t display a proper table with the borders in Creator – try it
> out, search for QObject, look at the API reference, there’s actually
> no table there. Just some indentation with white background. Now
> compare it to this: https://doc.qt.io/qt-5/qobject.html

Are you referring to the 1px table wrapping the list of members, etc.?

Saying that we want to move to a full blown browser for that makes me
think that this is a case of Qt not eating its own dogfood. Is it
impossible to fix QTextDocument to support them properly?


> You say:
>
> “Nowadays help/doc search activities is much more than just open offline
> page with descriptions of classes and methods with examples.”
>
> Exactly. I’d like to have more than this – but we don’t even have basic
> HTML. Remember, a table doesn’t render at all. It’s not possible with
> regular Creator docs. It’s possible to have better documentation, but we
> need something more than just QTextBrowser.

"A table does not render at all" is a lie.

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






This e-mail and any attachment(s) are intended only for the recipient(s) named 
above and others who have been specifically authorized to receive them. They 
may contain confidential information. If you are not the intended recipient, 
please do not read this email or its attachment(s). Furthermore, you are hereby 
notified that any dissemination, distribution or copying of this e-mail and any 
attachment(s) is strictly prohibited. If you have received this e-mail in 
error, please immediately notify the sender by replying to this e-mail and then 
delete this e-mail and any attachment(s) or copies thereof from your system. 
Thank you.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Nils Jeisecke via Development]

Am 25.06.2019 um 16:11 hat Giuseppe D'Angelo via Development geschrieben:
Saying that we want to move to a full blown browser for that makes me 
think that this is a case of Qt not eating its own dogfood. Is it 
impossible to fix QTextDocument to support them properly?

https://codereview.qt-project.org/c/qt/qtbase/+/126950 could be a start.

Still needs some work though.

Nils


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

Re: [Development] Assistant WebKit/WebEngine support

[Giuseppe D'Angelo via Development]

Hi,

Il 25/06/19 14:28, Palaraja, Kavindra ha scritto:


Hi Kirill,

I can’t speak for the size of WebEngine or the complexity of this 
solution, but I can speak for the look & feel of the documentation.


The current situation with Qt Creator’s documentation is not about how 
wonderful the content would look like. It’s about the basics of what 
developers expect to get when they look at the documentation. It’s to 
match what we have on https://doc.qt.io in the first place. I’m talking 
about _/parity/_. I’m not asking for some crazy animation – just a 1:1 
with the official Qt documentation that’s published online.


Sorry, but now I have to play devil's advocate:

Does that parity include things like Google search integration, or the 
current ads like "The Qt Company is hiring", not  and so on? The moment 
you start customizing things





  * We can’t display a real code blocks in Creator – you don’t get that
black box with syntax highlighted code snippets in Creator. When you
document this, you use \code, \endcode, or \badcode in qdoc. None of
this is actually being displayed as expected in Creator.


Is this a limitation of QTextBrowser or is the style applied for the 
docs there stripping out code highlighting? I know for a fact that 
 works in QTextBrowser.


If source code was not behaving as expected when compiled, you’d 
consider it a bug right? So why is this different because it’s 
documentation? Because it’s less important?


  * We can’t display a proper table with the borders in Creator – try it
out, search for QObject, look at the API reference, there’s actually
no table there. Just some indentation with white background. Now
compare it to this: https://doc.qt.io/qt-5/qobject.html 


Are you referring to the 1px table wrapping the list of members, etc.?

Saying that we want to move to a full blown browser for that makes me 
think that this is a case of Qt not eating its own dogfood. Is it 
impossible to fix QTextDocument to support them properly?




You say:

“Nowadays help/doc search activities is much more than just open offline 
page with descriptions of classes and methods with examples.”


Exactly. I’d like to have more than this – but we don’t even have basic 
HTML. Remember, a table doesn’t render at all. It’s not possible with 
regular Creator docs. It’s possible to have better documentation, but we 
need something more than just QTextBrowser.


"A table does not render at all" is a lie.

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] Gerrit Upgrade

[James McDonnell]

On 2019-05-06, 8:16 AM, "Development on behalf of Frederik Gladhorn" 
 wrote:

Hello,

We've been working on the Gerrit Upgrade for a while now and we are finally 
getting ready to deploy the new goodness.

We have all patches in our fork (yes, sadly we continue diverging a bit 
from 
mainstream, adding our own state handling for the CI).
The good news is that there are very few changes to Gerrit itself and most 
of 
the code is now in a self-contained plugin.

We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, 
that's 
a Monday, we assume Gerrit will be down for the full day that day).
The plan is to not actually take that long, but we want to make sure things 
actually work after the long wait and there are one or two things we cannot 
test very well without the right domain and everything in place.
Things look good though and I'm fairly confident that we'll manage the 
upgrade 
in May.

We will collect some documentation here, currently it's just a placeholder 
page, not yet worth visiting, unless you know the newer Gerrit and want to 
help out documenting what is new:
https://wiki.qt.io/Gerrit_Upgrade_2019

Cheers,
Frederik



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

Is HTTPS access still supposed to work?

git push gerrit HEAD:refs/for/5.12
fatal: https://jmcdonn...@codereview.qt-project.org/p/qt/qtbase/info/refs not 
valid: is this a git repository?

Did the paths change?
  

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

Re: [Development] Assistant WebKit/WebEngine support

[Eike Ziller]

> On Jun 24, 2019, at 22:44, Lars Knoll  wrote:
> 
> 
>> On 24 Jun 2019, at 21:54, Tor Arne Vestbø  wrote:
>> 
>> 
>> 
>>> On 24 Jun 2019, at 14:43, Simon Hausmann  wrote:
>>> 
>>> I have two more numbers to add: Compressed (7z) the download size would 
>>> be around ~44 MB. I measured on Windows with a Qt Creator built with 
>>> WebEngine support and surfed a little through the docs. The memory 
>>> consumption of the web engine process weighed in between 14-20 MB of RAM.
>>> 
>>> So it looks like this AFAICS:
>>> 
>>>   * We would be adding 145 MB of additional disk usage
>>> 
>>>   * We would add ~44 MB to the download size of Qt Creator
>>> 
>>>   * We would eat ~14-20 MB of additional RAM (not quite fair though, 
>>> as we'd have to subtract the QTextDocument memory usage for a diff).
>>> 
>>> 
>>> I don't quite share the opinion that these are "beastly" numbers for 
>>> desktop machines running C++ development environments. I think that they 
>>> are worth it. In exchange we can show external content like cppreference 
>>> or cmake docs without having to worry about their rendering, we can get 
>>> rid of our separate style sheets and workarounds and we can render the 
>>> Qt documentation the same way as on the website. We can eliminate an 
>>> entire class of problems, and we can still prevent such content from 
>>> accessing remote websites.
>>> 
>>> 
>>> We've had this situation for a long time now and I think that we should 
>>> finally move forward and give our users better quality at the expense of 
>>> their disk space, memory consumption and download size.
>>> 
>> 
>> I fully agree with this. Thanks for the numbers Simon!
> 
> Another +1 from me. Let’s stop fighting this. We need something that can 
> properly display any HTML content (and maybe PDF and things as well) that we 
> throw at it.

PDFs (and things) can be opened in external applications which then can provide 
whatever other related features the user might want. We really need something 
that can properly render HTML + CSS + images.

> Not having a fully working engine will always lead to issues where this 
> causes lots of additional work in other places, e.g. for the documentation 
> team that has to tweak the content of our qch files. Currently our inline 
> docs in Creator look a lot worse than the web version and lack many features 
> that we have on the web based docs. How come we accept that?

Using QtWebEngine for that means that 30-40% of Qt Creator is just for viewing 
help. And 70% or so of that actually would actually not be required for 
rendering beautiful help pages like in a browser (QtWebKit was ~40 MB back in 
the days, and was technically already more than needed).

> We do want integrated help and we want it to look good. That means we have to 
> simply accept the fact that we’ll need an integrated browser.

What is the state of QtWebKit(2) ? Do we have that on CI ? Can we have an 
export?

> Cheers,
> Lars

-- 
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] Assistant WebKit/WebEngine support

[Eike Ziller]

> On Jun 25, 2019, at 10:26, Simon Hausmann  wrote:
> 
> 
> Am 25.06.19 um 10:10 schrieb Morten Sørvig:
>> I’m not sure if it has been mentioned; we have another option which is to 
>> use the OS web browser component via the Qt WebView module.
>> 
>> The benefits would be
>> 
>> * up-to-date web browser (and someone else keeps it up to date for us)
>> * insignificant additional download size
>> * no trouble with restricted platforms where shipping a full web browser is 
>> not feasible (but then maybe creator isn’t going to run on those platforms, 
>> anyway)
>> 
>> QWebView’s platform coverage may be insufficient for Creator, which means
>> 
>> * no html docs on those platforms :(
>> * or, we expand QWebView platform coverage
>> * or, QT WebView does have a WebEngine backend
> 
> 
> I think that would indeed be desirable in the long run. At the moment 
> this is limited to macOS (and from the looks of it, Qt Creator has 
> direct support for using WebKit on macOS, but oddly my build doesn't 
> have it enabled?).

It is there, but not used by default. You can switch between different backends 
(that are supported in your build) with e.g. QTC_HELPVIEWER_BACKEND=native (for 
the native webview backend) or =textbrowser for the QTextBrowser fallback.
It has issues though. Which is why it is not default. Embedding the native view 
into Qt Creator so far didn’t work reliably, with different issues depending on 
Qt version.
The collection of issues I had so far, never all together though ;)
- blank webview
- working webview but blank QML views (possibly fighting over OpenGL contexts?)
- mouse hover not working 
- last time I checked the webview was scaled x2 when it first opened

> I'm quite excited about Microsoft's WebView2 
> development that could become a very nice backend for QWebView on 
> Windows. I played with it the other day and it looks quite nice. The 
> deployment model is not suitable for us at the moment (nuget only) and 
> it's still in an early release phase. However it comes with a powerful 
> API and an opt-in evergreen distribution model.
> 
> QWebView would also need to be improved to support feeding custom data 
> into it, unless somebody implements serving via a local http server.
> 
> 
> I think these are all options in the future.
> 
> 
> Simon
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
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] Assistant WebKit/WebEngine support

[Palaraja, Kavindra]

…

I don't think that a lot of developers really care about how wonderful help 
module looks like as long as it answers development related questions clearly 
and precisely. Nowadays help/doc search activities is much more than just open 
offline page with descriptions of classes and methods with examples. We search 
through QA web sites and dev forums, tutorials and videos, source repositories, 
social discussion platform. Why not to delegate all those activities to proper 
browser environment of choice with all its extensions and custom setups? And 
just improve query part of qtc help (index, content seaches) to speed up simple 
Qt and c++ related queries and fall back to proper web search engines outside 
of ide for anything more complex. Embedding browser into ide seems to me like a 
huge misdirection.


Hi Kirill,

I can’t speak for the size of WebEngine or the complexity of this solution, but 
I can speak for the look & feel of the documentation.

The current situation with Qt Creator’s documentation is not about how 
wonderful the content would look like. It’s about the basics of what developers 
expect to get when they look at the documentation. It’s to match what we have 
on https://doc.qt.io in the first place. I’m talking about _parity_. I’m not 
asking for some crazy animation – just a 1:1 with the official Qt documentation 
that’s published online.


  *   We can’t display a real code blocks in Creator – you don’t get that black 
box with syntax highlighted code snippets in Creator. When you document this, 
you use \code, \endcode, or \badcode in qdoc. None of this is actually being 
displayed as expected in Creator.

If source code was not behaving as expected when compiled, you’d consider it a 
bug right? So why is this different because it’s documentation? Because it’s 
less important?

  *   We can’t display a proper table with the borders in Creator – try it out, 
search for QObject, look at the API reference, there’s actually no table there. 
Just some indentation with white background. Now compare it to this: 
https://doc.qt.io/qt-5/qobject.html

You say:

“Nowadays help/doc search activities is much more than just open offline page 
with descriptions of classes and methods with examples.”

Exactly. I’d like to have more than this – but we don’t even have basic HTML. 
Remember, a table doesn’t render at all. It’s not possible with regular Creator 
docs. It’s possible to have better documentation, but we need something more 
than just QTextBrowser.


Kavindra.




This e-mail and any attachment(s) are intended only for the recipient(s) named 
above and others who have been specifically authorized to receive them. They 
may contain confidential information. If you are not the intended recipient, 
please do not read this email or its attachment(s). Furthermore, you are hereby 
notified that any dissemination, distribution or copying of this e-mail and any 
attachment(s) is strictly prohibited. If you have received this e-mail in 
error, please immediately notify the sender by replying to this e-mail and then 
delete this e-mail and any attachment(s) or copies thereof from your system. 
Thank you.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Kirill Burtsev]

Hello,

That for sure doesn't account for complexity of what we are getting with this 
move. Quite heavily stripped down version of chromium inside webengine has ~20M 
loc, that is 10x times more than whole qtc. The actual browser is twice as big 
in terms of loc. Official doc page for building Qt suggests to skip webengine. 
Number of supported compilers and environments is also limited. MSYS2 
environment has latest mingw and clang, and this environment is sufficient to 
build whole Qt (and libraries are there except, of course, webengine). 
WebEngine doesn't only display fancy looking htmls with styles, it is almost 
full-blown browser. Why is it needed this way in ide?

Qt Creator is not a light-weight ide already. Popularity of editors-ides like 
vscode, sublime, vim/emacs-based envs clearly shows how important this factor 
is. Will it run fine on 5-6 years old laptops or on recent phones and tables 
with desktop features and arm cpus?

I don't think that a lot of developers really care about how wonderful help 
module looks like as long as it answers development related questions clearly 
and precisely. Nowadays help/doc search activities is much more than just open 
offline page with descriptions of classes and methods with examples. We search 
through QA web sites and dev forums, tutorials and videos, source repositories, 
social discussion platform. Why not to delegate all those activities to proper 
browser environment of choice with all its extensions and custom setups? And 
just improve query part of qtc help (index, content seaches) to speed up simple 
Qt and c++ related queries and fall back to proper web search engines outside 
of ide for anything more complex. Embedding browser into ide seems to me like a 
huge misdirection.



From: Development  on behalf of Simon 
Hausmann 
Sent: Monday, June 24, 2019 14:43
To: development@qt-project.org
Subject: Re: [Development] Assistant WebKit/WebEngine support


Am 24.06.19 um 12:31 schrieb Eike Ziller:
>> * What exactly is so big about WebEngine? What is this size that many are 
>> hinting at but won't provide the number?
> My numbers on macOS:
>
> WebEngineCore.framework = 145 MB
> Current Qt Creator application = 430 MB (and about 60 MB of this we currently 
> try to get rid off again because it’s actually duplicate binary code)


I have two more numbers to add: Compressed (7z) the download size would
be around ~44 MB. I measured on Windows with a Qt Creator built with
WebEngine support and surfed a little through the docs. The memory
consumption of the web engine process weighed in between 14-20 MB of RAM.

So it looks like this AFAICS:

 * We would be adding 145 MB of additional disk usage

 * We would add ~44 MB to the download size of Qt Creator

 * We would eat ~14-20 MB of additional RAM (not quite fair though,
as we'd have to subtract the QTextDocument memory usage for a diff).


I don't quite share the opinion that these are "beastly" numbers for
desktop machines running C++ development environments. I think that they
are worth it. In exchange we can show external content like cppreference
or cmake docs without having to worry about their rendering, we can get
rid of our separate style sheets and workarounds and we can render the
Qt documentation the same way as on the website. We can eliminate an
entire class of problems, and we can still prevent such content from
accessing remote websites.


We've had this situation for a long time now and I think that we should
finally move forward and give our users better quality at the expense of
their disk space, memory consumption and download size.


Simon

___
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] New repository request (qtplatformdefinitions)

[Jedrzej Nowacki]

On Tuesday, June 25, 2019 12:23:55 PM CEST Tor Arne Vestbø wrote:
> The name qtplatformdefinitions will likely quickly be wrong once something
> else needs to be dumped in there. How about just qtinfra?
 
> Tor Arne 
> 

I'm not really asking for "catch all" repository. I do not know why anything 
else that I mentioned in the bug tracker would be needed to be dumped there. I 
just need a repository with no dependencies following qt branching model to 
store build instructions, specifying CI tested platforms and probably storing 
some provisioning scripts. All CI related. It can be named qtinfra, 
qtinfrastructure, qtci, qtplatformdefinitions or even qtfoobar I will accept 
anything without a fight :-)

Jędrek


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

Re: [Development] New repository request (qtplatformdefinitions)

[Tor Arne Vestbø]

Or qtqainfra 

> On 25 Jun 2019, at 12:23, Tor Arne Vestbø  wrote:
> 
> The name qtplatformdefinitions will likely quickly be wrong once something 
> else needs to be dumped in there. How about just qtinfra?
> 
> Tor Arne 
> 
>> On 25 Jun 2019, at 12:18, Jedrzej Nowacki  wrote:
>> 
>> As in: https://bugreports.qt.io/browse/QTQAINFRA-3068
>> 
>> We need a repository for infrastructure, so we do not need to abuse qt5 
>> repository anymore.
>> 
>> Cheers,
>> Jędrek
>> 
>> 
>> ___
>> 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] New repository request (qtplatformdefinitions)

[Tor Arne Vestbø]

The name qtplatformdefinitions will likely quickly be wrong once something else 
needs to be dumped in there. How about just qtinfra?

Tor Arne 

> On 25 Jun 2019, at 12:18, Jedrzej Nowacki  wrote:
> 
> As in: https://bugreports.qt.io/browse/QTQAINFRA-3068
> 
> We need a repository for infrastructure, so we do not need to abuse qt5 
> repository anymore.
> 
> Cheers,
>  Jędrek
> 
> 
> ___
> 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

[Development] New repository request (qtplatformdefinitions)

[Jedrzej Nowacki]

As in: https://bugreports.qt.io/browse/QTQAINFRA-3068

We need a repository for infrastructure, so we do not need to abuse qt5 
repository anymore.

Cheers,
  Jędrek


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

Re: [Development] Assistant WebKit/WebEngine support

[Simon Hausmann]

Am 25.06.19 um 10:10 schrieb Morten Sørvig:
> I’m not sure if it has been mentioned; we have another option which is to use 
> the OS web browser component via the Qt WebView module.
>
> The benefits would be
>
> * up-to-date web browser (and someone else keeps it up to date for us)
> * insignificant additional download size
> * no trouble with restricted platforms where shipping a full web browser is 
> not feasible (but then maybe creator isn’t going to run on those platforms, 
> anyway)
>
> QWebView’s platform coverage may be insufficient for Creator, which means
>
> * no html docs on those platforms :(
> * or, we expand QWebView platform coverage
> * or, QT WebView does have a WebEngine backend


I think that would indeed be desirable in the long run. At the moment 
this is limited to macOS (and from the looks of it, Qt Creator has 
direct support for using WebKit on macOS, but oddly my build doesn't 
have it enabled?). I'm quite excited about Microsoft's WebView2 
development that could become a very nice backend for QWebView on 
Windows. I played with it the other day and it looks quite nice. The 
deployment model is not suitable for us at the moment (nuget only) and 
it's still in an early release phase. However it comes with a powerful 
API and an opt-in evergreen distribution model.

QWebView would also need to be improved to support feeding custom data 
into it, unless somebody implements serving via a local http server.


I think these are all options in the future.


Simon

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

[Development] Failing auto-tests (SSL)

[Timur Pocheptsov]

Hi all,

The soon-expiring apache's certificate on our network test server was replaced 
yesterday.
This was done too fast without properly fixing our tests/replacing the certs we
have locally. The affected tests are tst_qsslsocket/tst_qnetworkreply. As of 
now - we fixed
the problem in 5.12 and staging in 5.9. 5.13/dev are still affected/broken. We 
working
on this and I'll provide more info when it's done (and Liang can tell us then 
the changes from
5.12 are in 5.13)

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

Re: [Development] Assistant WebKit/WebEngine support

[Giuseppe D'Angelo via Development]

Il 25/06/19 10:12, Simon Hausmann ha scritto:
I think you're right, the linkage appears to be due to the use of 
QQuickWidget as child widget of QWebEngineView. Do you think that's a 
problem?


I don't really know :)

I was asking about feedback regarding reintroducing a mandatory Qt Quick 
dependency after Creator decided to drop it in certain parts. (Didn't 
want to answer "works for me so I don't see the problem").


My 2 c,
--
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] Assistant WebKit/WebEngine support

[Simon Hausmann]

Hi,


I think you're right, the linkage appears to be due to the use of QQuickWidget 
as child widget of QWebEngineView. Do you think that's a problem?



Simon



From: Giuseppe D'Angelo 
Sent: Tuesday, June 25, 2019 10:02
To: Simon Hausmann; development@qt-project.org
Subject: Re: [Development] Assistant WebKit/WebEngine support

Hi,

Il 25/06/19 09:26, Simon Hausmann ha scritto:
>
> QtQuick 2 is not required for using WebEngine and there is support for
> software rendering. The existing Qt Creator integration as well as the
> proposed patch to Qt Assistant to use Web Engine is using the widgets
> integration.
>
> To put it to a test, I just installed a fresh Windows 10 in VirtualBox
> on my Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the
> web engine widgets simple browser example. It built and ran out of the
> box inside the virtual machine and I could browser qt.io and doc.qt.io.


[citation needed], though: why is QtWebEngine linking against Qt Quick?

> $ readelf -d libQt5WebEngineWidgets.so
>
> Dynamic section at offset 0x3eab0 contains 46 entries:
>   TagType Name/Value
>  0x0001 (NEEDED) Shared library: 
> [libQt5WebEngineCore.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Quick.so.5]
>  0x0001 (NEEDED) Shared library: 
> [libQt5PrintSupport.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Widgets.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Gui.so.5]
>  0x0001 (NEEDED) Shared library: 
> [libQt5WebChannel.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Qml.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Network.so.5]
>  0x0001 (NEEDED) Shared library: 
> [libQt5Positioning.so.5]
>  0x0001 (NEEDED) Shared library: [libQt5Core.so.5]
>  0x0001 (NEEDED) Shared library: [libpthread.so.0]
>  0x0001 (NEEDED) Shared library: 
> [libQt5QuickWidgets.so.5]
>  0x0001 (NEEDED) Shared library: [libGL.so.1]
>  0x0001 (NEEDED) Shared library: [libstdc++.so.6]
>  0x0001 (NEEDED) Shared library: [libm.so.6]
>  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
>  0x0001 (NEEDED) Shared library: [libc.so.6]
>  0x000e (SONAME) Library soname: 
> [libQt5WebEngineWidgets.so.5]
>  0x001d (RUNPATH)Library runpath: [$ORIGIN]
[snip]

The software renderer path should be discussed with the authors of the
other Qt Quick-based plugins inside Creator (as currently the decision
of using software rendering is process-wide).



My 2 c,
--
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] Assistant WebKit/WebEngine support

[Morten Sørvig]

> On 24 Jun 2019, at 22:44, Lars Knoll  wrote:
> 
> 
>> On 24 Jun 2019, at 21:54, Tor Arne Vestbø  wrote:
>> 
>> 
>> 
>>> On 24 Jun 2019, at 14:43, Simon Hausmann  wrote:
>>> 
>>> I have two more numbers to add: Compressed (7z) the download size would 
>>> be around ~44 MB. I measured on Windows with a Qt Creator built with 
>>> WebEngine support and surfed a little through the docs. The memory 
>>> consumption of the web engine process weighed in between 14-20 MB of RAM.
>>> 
>>> So it looks like this AFAICS:
>>> 
>>>   * We would be adding 145 MB of additional disk usage
>>> 
>>>   * We would add ~44 MB to the download size of Qt Creator
>>> 
>>>   * We would eat ~14-20 MB of additional RAM (not quite fair though, 
>>> as we'd have to subtract the QTextDocument memory usage for a diff).
>>> 
>>> 
>>> I don't quite share the opinion that these are "beastly" numbers for 
>>> desktop machines running C++ development environments. I think that they 
>>> are worth it. In exchange we can show external content like cppreference 
>>> or cmake docs without having to worry about their rendering, we can get 
>>> rid of our separate style sheets and workarounds and we can render the 
>>> Qt documentation the same way as on the website. We can eliminate an 
>>> entire class of problems, and we can still prevent such content from 
>>> accessing remote websites.
>>> 
>>> 
>>> We've had this situation for a long time now and I think that we should 
>>> finally move forward and give our users better quality at the expense of 
>>> their disk space, memory consumption and download size.
>>> 
>> 
>> I fully agree with this. Thanks for the numbers Simon!
> 
> Another +1 from me. Let’s stop fighting this. We need something that can 
> properly display any HTML content (and maybe PDF and things as well) that we 
> throw at it.
> 

I’m not sure if it has been mentioned; we have another option which is to use 
the OS web browser component via the Qt WebView module.

The benefits would be

* up-to-date web browser (and someone else keeps it up to date for us)
* insignificant additional download size
* no trouble with restricted platforms where shipping a full web browser is not 
feasible (but then maybe creator isn’t going to run on those platforms, anyway)

QWebView’s platform coverage may be insufficient for Creator, which means

* no html docs on those platforms :(
* or, we expand QWebView platform coverage
* or, QT WebView does have a WebEngine backend

Cheers,
Morten







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

Re: [Development] Assistant WebKit/WebEngine support

[Giuseppe D'Angelo via Development]

Hi,

Il 25/06/19 09:26, Simon Hausmann ha scritto:


QtQuick 2 is not required for using WebEngine and there is support for 
software rendering. The existing Qt Creator integration as well as the 
proposed patch to Qt Assistant to use Web Engine is using the widgets 
integration.


To put it to a test, I just installed a fresh Windows 10 in VirtualBox 
on my Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the 
web engine widgets simple browser example. It built and ran out of the 
box inside the virtual machine and I could browser qt.io and doc.qt.io.



[citation needed], though: why is QtWebEngine linking against Qt Quick?


$ readelf -d libQt5WebEngineWidgets.so

Dynamic section at offset 0x3eab0 contains 46 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: 
[libQt5WebEngineCore.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Quick.so.5]
 0x0001 (NEEDED) Shared library: 
[libQt5PrintSupport.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Widgets.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5]
 0x0001 (NEEDED) Shared library: [libQt5WebChannel.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Qml.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Network.so.5]
 0x0001 (NEEDED) Shared library: 
[libQt5Positioning.so.5]
 0x0001 (NEEDED) Shared library: [libQt5Core.so.5]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: 
[libQt5QuickWidgets.so.5]
 0x0001 (NEEDED) Shared library: [libGL.so.1]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x000e (SONAME) Library soname: 
[libQt5WebEngineWidgets.so.5]
 0x001d (RUNPATH)Library runpath: [$ORIGIN]

[snip]

The software renderer path should be discussed with the authors of the 
other Qt Quick-based plugins inside Creator (as currently the decision 
of using software rendering is process-wide).




My 2 c,
--
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] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

25.06.2019, 10:48, "André Pönitz" :
> On Mon, Jun 24, 2019 at 04:37:16PM +0300, Konstantin Tokarev wrote:
>>  > I have two more numbers to add: Compressed (7z) the download size would
>>  > be around ~44 MB. I measured on Windows with a Qt Creator built with
>>  > WebEngine support and surfed a little through the docs. The memory
>>  > consumption of the web engine process weighed in between 14-20 MB of RAM.
>>  >
>>  > So it looks like this AFAICS:
>>  >
>>  >  * We would be adding 145 MB of additional disk usage
>>  >
>>  >  * We would add ~44 MB to the download size of Qt Creator
>>  >
>>  >  * We would eat ~14-20 MB of additional RAM (not quite fair though,
>>  > as we'd have to subtract the QTextDocument memory usage for a diff).
>>
>>  For comparison, numbers for QtWebKit are: 84 MB of disk space (of which
>>  26 MB is taken by ICU data), and 20 MB when compressed to 7z archive.
>>  I didn't measure RAM consumption, but I'm sure it won't take more than
>>  you've measured.
>>
>>  This is full build with all features enabled; it's possible to make reduced
>>  build without multimedia support, JavaScript JIT and other features not 
>> needed
>>  for help browser.
>
> I actually tried that a while ago (i.e. clone Qt Webkit and throw out
> everything that's not needed to display Qt's help) when the shift to
> WebEngine was looming.
>
> It worked up to a certain degree nicely in the build system by
> de-selecting options, than quite a bit more by actually removing code.
> Getting rid of all of JS was not obviously possible.

Removing code makes result unmaintainable, while minimal configuration with
existing options makes a good balance IMO.

>
> The result was ok-ish size-wise (and for me definitely preferable over
> WebEngine) but the question is where to put to cut. In some setups
> ("Want to see DevDays videos") even cutting multimedia plugins won't be
> accepted by everyone. I.e. the "need" for a "full browser" is likely
> to always exist, and that's currently served by "use external help".

We have MediaFoundation player on Windows these days so it can work
without pulling in Qt Multimedia and uses system-provided codecs, so
enabling multimedia won't add that much. However, for multimedia content
there is always an option to add external link, as this is not the kind of
documentation you really need to have inside your IDE or in similar context.

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Simon Hausmann]

Hi,

I don't think that support for x86 macOS will be retroactively added, 
especially since upstream as well as Apple are dropping x86.

MinGW is also not a supported compiler, but it's possible to build with 
clang-cl, which is what upstream is using. (Interestingly, Safari, FireFox and 
Chrome are all built using clang these days)

Simon

From: Development  on behalf of Konrad 
Rosenbaum 
Sent: Tuesday, June 25, 2019 7:50
To: development@qt-project.org
Subject: Re: [Development] Assistant WebKit/WebEngine support

Hi,

On 6/24/19 2:43 PM, Simon Hausmann wrote:
> We've had this situation for a long time now and I think that we should
> finally move forward and give our users better quality at the expense of
> their disk space, memory consumption and download size.

...at the risk of making enemies: so the platform issues(*) will be
solved till Qt 6.0?

So, even if I try to compile Qt myself on, say MinGW or 32bit MacOS - I
will end up with a (fully?) functional Assistant?

(*)https://doc.qt.io/qt-5/qtwebengine-platform-notes.html


Konrad


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

Re: [Development] Assistant WebKit/WebEngine support

[Simon Hausmann]

Hi,

QtQuick 2 is not required for using WebEngine and there is support for software 
rendering. The existing Qt Creator integration as well as the proposed patch to 
Qt Assistant to use Web Engine is using the widgets integration.

To put it to a test, I just installed a fresh Windows 10 in VirtualBox on my 
Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the web engine 
widgets simple browser example. It built and ran out of the box inside the 
virtual machine and I could browser qt.io and doc.qt.io.


Simon

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Monday, June 24, 2019 15:52
To: development@qt-project.org
Subject: Re: [Development] Assistant WebKit/WebEngine support

Here's a third question:

On 24/06/2019 11:42, Palaraja, Kavindra wrote:
> Two further questions:
>
> * What exactly is so big about WebEngine? What is this size that many are 
> hinting at but won't provide the number?
> * Doesn't WebEngine have a feature where you can completely lock it out of 
> the Internet?

Does using QtWebEngine still mean firing QQ2 under the hood and the
subsequent OpenGL integration? That's known to be extremely flaky (and
one of the reasons why Qt Creator dropped QQ2 for its welcome screen),

My 2 c,
--
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