Re: [Interest] QGraphicsView and OpenGL in Qt6

[Shawn Rutledge via Interest]

On 23 Nov 2023, at 02:37, Calogero Mauceri  wrote:

Hi all,

We finally decided to port our Qt5 based application to Qt6.
It is a pretty complex application. The main view is a QGraphicsView with 
multiple items: images, paths, possible animations and so on.

I remember in Qt5 OpenGL rendering was experimental with lots of issues. My 
question is, is QGraphicsView OpenGL rendering more stable in the Qt6 era? or 
even better, is it suggested to render using OpenGL? (note: it is a cross 
platform application that should run on Windows, Mac or Linux machines).

To be more specific. The QGraphicsView shows a map. The map is made up of 
multiple tiles that should align perfectly. Each tile is a QGraphicsPixmapItem. 
After porting to Qt6, it sometimes happens that when applying a scale to the 
tiles, then there are gaps between them. It does not always happen, but it can.
I'm pretty sure the QGraphicsPixmapItems are properly scaled and positioned. It 
was working as expected in Qt5.

Depending on how much you want to invest in porting, maybe it’s time to check 
whether you can use Qt Quick now?

I have also wondered if we need explicit support for large tiled images.  We 
need tiles in Qt Location for example, but in that case it’s already 
conventional to download pre-rendered fixed-size tiles, so that’s what we do; 
and the implementation is a C++ one-off, not depending on any reusable tiling 
implementation, since we don’t have one yet.  I also wondered how many people 
will want to use QtPDF to render very large pages (architectural drawings, 
electrical schematics, maps and so on), so I figured the tiling mechanism might 
be useful there too, if we had one.  But I tried using TableView for that, and 
it was reasonably successful.  TableView does a good job with instantiating the 
tiles just-in-time: you only get as many tiles as you can see onscreen, and an 
extra “border” of spare tiles in case you then pan the view by small 
increments.  In the PDF case, rendering tiles is the bottleneck, because QtPDF 
uses the same raster engine that Chrome does to render PDF pages, and it's not 
multi-thread-capable; so tiling with TableView made it possible to render large 
pages at a higher resolution than you could fit into a single GPU texture, but 
caused a big slowdown (rendering each tile took almost as long as rendering the 
whole page at maximum texture size: just a demonstration of what’s wrong with 
CPU-based raster engines).  But if you can get your tiles quickly, I think 
TableView is great for that.  The tiles can fit together perfectly with no gap, 
and you get the advantage of its well-maintained dynamic loading mechanism.  
Each tile is a Qt Quick Item-based delegate though (at least an Image, plus 
whatever else you declare there), so as with item views in general, you should 
avoid making your delegates too complex (interactive per-tile features), 
because the overhead gets multiplied by the number of delegates.

Graphics View on the other hand has not been getting much attention in R for 
over a decade already: only bug fixes.  (Many of us haven’t used it much 
ourselves, aren’t very familiar with the implementation, and haven’t learned 
all the lessons that we could from it.  This includes me, although I had a 
simple use case for it once in an application.)  We hope it will eventually be 
obsolete when we’ve developed solutions for the known use cases in Qt Quick, 
but we also know that we’re not there yet.  I suspect that tiling could be 
considered just a specialization of a more general spatial-instantiation 
architecture: if you have a big collection of 2D assets with random sizes and 
positions, stored in some kind of model (QAIM or hopefully something better?), 
can we propose a standard API to figure out which views of them (delegates) 
will intersect the viewport?  (Obviously, without instantiating all the 
delegates just to find out)  One big difference between CPU-based rendering and 
Qt Quick is that you have to create scene-graph nodes now: avoid procedural 
rendering, don’t make your own draw calls; so for efficiency, you have to 
decide which ones to create.  (The rendering code will cull the SG nodes that 
are currently out-of-bounds, but they still take memory.)  But in Qt Quick, 
scene graph nodes are usually instantiated by Items; so probably you want to 
decide which of those to create.  Thus most applications are working 2 layers 
away from the actual rendering nowadays.  (Alternatively, one big smart 
QQuickItem subclass can selectively populate SG nodes within its own bounds 
rather than having an Item per asset that needs to be drawn, but you probably 
have to write more and less-reusable code that way.  You’ll need the 
QQuickItem::ItemObservesViewport flag to find out what region of your big item 
is actually visible in the viewport.)

Maybe that’s part of what the replacement for Graphics View needs to eventually 
do.  (And should we extend it to 3D too?)  We can 

Re: [Interest] Qt classes to print email to pdf from message in mbox format?

[Shawn Rutledge via Interest]

> On 7 Nov 2023, at 09:28, Jeffrey Walton  wrote:
> 
> Hi Everyone,
> 
> I've been lurking a while to collect information for an upcoming
> project. I have not seen a similar topic, so I'm going to ask...
> 
> I have a collection of email messages in mbox format. I obtain them
> from GMail, and Export Data operation. I can parse them into
> individual messages. For each message, I need to virtually display
> them in a Html-like view, and then print them to a pdf.
> 
> Lurking and Google search is not turning up useful results. I saw KDE
> has some gear, like KMBox::MBox, but I want to stay in Qt.
> 
> My question is, does Qt offer any support for mbox format?

Not that I know of, but I’m sure you can find some C++ code somewhere.

>  Or rich
> email messages?
> Or do I need to extract the html parts of the message, and then supply
> a string to QTextBrowser?

QTextBrowser’s HTML support is not very modern or complete.  If you are not 
satisfied with the rendering, maybe it’s better to use Qt Webengine.  On the 
other hand, in that case let’s hope you trust the senders.  It’s becoming 
rather insecure to let a browser download every remote image etc. that is 
referenced in every HTML email; so in my mail clients I usually have that 
feature turned off by default, so that there’s a button to optionally download 
inline images only occasionally.

This sounds like something to try in Python rather than C++: it sounds like a 
“scripty” thing to do rather than a long-lived application, you can use Qt, and 
you can probably find code for mbox pretty easily too.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Wayland: handle one or two displays like Weston does

[Shawn Rutledge via Interest]

> On 19 May 2023, at 16:02, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> Hi!
> 
> Is there any example of QtWayland's compositor handling one or two monitors 
> like Weston does?
> 
> To be more precise: my hardware, iMX8M-PLUS based, has an LVDS display and an 
> HDMI output.
> 
> The LVDS display is always connected, and if weston is started it will set 
> the shell to be as big as the LVDS display itself.
> 
> Now if an HDMI monitor gets attached Weston will expand the shell to the 
> right with the new display's size...

As far as I know, we have not yet implemented display hotplugging.  The main 
use case so far for QtWayland compositors is embedded: you might have multiple 
screens on one GPU in your car, but they are fixed and configured at the 
factory.  I would also like to have hotplugging in eglfs though, because it’s 
one of the obstacles in the way of using QtWayland on laptops and such (don’t 
want to have to restart the compositor if I connect a second monitor); but I 
think this involves more work with libdrm to achieve.  (I've spoken to 
colleagues about it a few years ago, so I’m just remembering what was said at 
the time, but didn’t get around to trying to implement it.)

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Embedding a QTextBrowser in a QML application: QObject: Cannot create children for a parent that is in a different thread

[Shawn Rutledge]

On 2022 Mar 30, at 03:03, Jeffrey Brendecke 
mailto:jeffrey.brende...@gmail.com>> wrote:

For an app I am working on I need a component for displaying HTML rich text. 
TextEdit does not provide an important feature I need present in QTextEdit and 
QTextBrowser: scrollToAnchor( const QString& ).

So you went and wrote up a feature request at 
bugreports.qt.io about that, first thing, right?  ;-)  
Please do, because we know that Qt Quick cannot be taken seriously for desktop 
development unless we add missing features like this over time; and that’s 
really a goal.

Since TextEdit doesn’t have scrolling built-in (the separation of concerns 
principle was followed there at least), you’d need to put it in a Flickable, 
and then you’d need a way to find the y coordinate of the anchor location so 
that you can set Flickable’s contentY.  And we don’t have API for dealing with 
anchors AFAIK.  Probably we should, but it needs a bit of brainstorming about 
what that should look like; e.g. we could have a function to look up the 
position by name, like anchorPosition(string); but maybe you first need a list 
of anchors.  (Even the name could be a matter for discussion since “anchors” 
usually mean something different in Qt Quick.)  If you are getting a list, 
should it be only a QStringList or should we provide all the necessary 
information at once, somehow?  QVariantList?  Or would a QAIM be useful?  
Something like 
https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/pdf/qpdflinkmodel_p.h but 
maybe that’s overkill for this case.  Anyway if you wanted to show a sidebar 
with a “table of contents” or list of link destinations (ListView or TreeView?) 
some sort of model would be useful.  (I will soon try to use TreeView in QtPDF, 
although in that context, links and bookmarks are different things.)  Even 
better if the same model could be used both in Quick and widget-based 
applications; maybe it could be done if it would work only with QTextDocument 
and QTextLayout objects, and the view’s job is to keep it updated whenever the 
text layout is done or redone; but I’m not sure.  Having complete information 
about anchors and their locations at startup would be in conflict with the idea 
of doing text layout lazily, to save time and memory when the text is large 
(like a document containing a whole book).

Does anybody have any better ideas?

The app will have to work on iOS, so WebEngine is out of the question, and I 
would not want to have all the overhead of having a web browser in the app 
anyways.

Given the text itself is fairly simple (no images, just formatted text), 
QTextBrowser gives me what I need.

I have been looking into trying to embed a QTextBrowser into a QML application 
using the approach in this project:

https://www.alex-spataru.com/blog/using-qt-widgets-in-your-qmlqtquick-applications.
 (QmlPlainTextEdit)

A similar approach is used here:

https://github.com/mosolovsa/qmlplot

Data visualization with QPainter…  I guess they don’t expect real-time…

This involves:
* Creating a class deriving from QQuickPaintedItem
* Encapsulating an instance of QTextBrowser instantiated with a nullptr parent 
as a member in that class
* Rendering from the QTextBrowser into the QQuickPaintedItem derivative
* Hooking up the necessary events between the QQuickPaintedItem and the 
QTextBrowser instance

That all seems to be no problem. The problem I get results in a segmentation 
fault:

“””
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QTextDocument(0x5617e2ebed80), parent's thread is 
QThread(0x5617e2958860), current thread is QSGRenderThread(0x5617e2d18400)
“”"

I’d have to use the debugger to understand what threads are involved and where 
is this child being created from, but yes thread ownership of objects is a 
thing.  https://doc.qt.io/qt-6/qobject.html#moveToThread or try to figure out 
how to get the child creation into the correct thread, or...

You could alternatively go the other way around: write a widget application and 
use QQuickWidget for the Quick contents.  (Hopefully only one of those.) And 
perhaps run into different bugs… but we are porting QQuickWidget to RHI for 
6.4, and hopefully looking at some old bugs there while we’re at it.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Shawn Rutledge]

On 2022 Jan 6, at 10:35, Ulf Hermann 
mailto:ulf.herm...@qt.io>> wrote:

To be frank it's been an annoyance for me that gadgets can't be instantiated 
the same way the QObject can within the QML document/tree. Is there a good 
reason to disallow this or is it simply not implemented? Am I missing some odd 
use/corner case why it's not a good idea?

It's not implemented yet, and there are some questions surrounding the desired 
syntax.

We already have group properties. So, if you have a property font of some value 
type, you can already do this:



MyObject {

   font {

   pointSize: 14

   bold: true

   }

}



That is very similar in syntax to what you would do with a full value type 
construction. Therefore, the extra syntax required for full value type 
construction seems some
what redundant. I've chosen the familiar "font" value type as example but you 
can do the same with custom value types.

What is missing is value types as default properties and value types in lists 
and JavaScript objects. Yet, declaratively putting QML types in lists and 
objects is already a rather buggy affair with object types. This needs to be 
fixed first.

Then there is the issue that you cannot have named custom value types at all so 
far (you can have anonymous custom value types, though). All of the currently 
available named value types are hardcoded. That has to be fixed eventually.

Finally, we will probably run into some grammatical ambiguities when we allow 
lower-case names on the left side of "object" intializers.

It’s good to hear that there might be hope still.  I was assuming we won't 
because it’s a value type, can be stack-allocated, cannot be passed by pointer, 
and needs to be copied or moved every time, i.e. even after instantiating 
declaratively, you’d have to move or copy at least once to put it into a 
destination, whatever that is.

https://bugreports.qt.io/issues/?jql=text%20~%20%22gadget%20qml%22
 finds a bunch of related requests like 
QTBUG-54983 
QTBUG-79330 
QTBUG-56484 
QTBUG-72223 
QTBUG-73399
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Are there limits to the number of vertices that can be allocated on a QSGGeometry?

[Shawn Rutledge]

> On 2021 Oct 20, at 18:11, Nuno Santos  wrote:
> 
> Hi Shawn,
> 
> Thank you very much for your reply and clarification.
> 
> My next question is, what is the best way to work around this?
> 
> Should I create a QSGGeometryNode that draws an element and then create a 
> node for each element?
> 
> Do you think this will degrade the performance?
> 
> Is there any other way of making it more performant?

Probably the ideal thing to do is break up the vertices into chunks somewhere 
around the 64k limit, but maybe the graphics guys will have something else to 
suggest.  I was just working on Text recently: each character is a quad (so the 
limit is 16k characters per node); and if you render too much text in one Text 
item, the first node creates more, as children of itself.  That was already 
working since early Qt 5 releases; I just did some optimizations recently to 
save memory and time while generating those; and now in 6.2 all the children 
are direct children rather than being recursively nested.  So that’s one way to 
break it up when you have too many vertices.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Are there limits to the number of vertices that can be allocated on a QSGGeometry?

[Shawn Rutledge]

> On 2021 Oct 20, at 17:36, Nuno Santos  wrote:
> 
> Hi,
> 
> I have a custom QSGGeometryNode that renders several elements using triangles.
> 
> Each element is composed by 4 rectangles, this means that each element needs 
> 6x4=24 vertices.
> 
> If there are more than a certain number of elements to be drawn, artefacts 
> pop up. This artefacts are characterised by lines that connect to the origin, 
> or with vertices on other elements.
> 
> I have stumbled on this issue when rendering a scene with roughly 3800 
> elements, which require 91200 vertices. I’m using colored point 2d vertices. 
> 
> 
> Are there limits to the number of vertices that can be allocated on a 
> QSGGeometry?

Yes: it uses 16-bit indices, and the last index is reserved to indicate 
primitive restart.  So you can have up to 65534 vertices per node. 

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Transparent rectangle with radius in one side

[Shawn Rutledge]

Try QtQuick.Shapes; you can get any shape you want.  However those don’t do 
vertex antialiasing, so you might need to turn on MSAA to get rid of the 
jaggies.  So it would be best to try to put all the shapes as children of one 
item (or children of a root shape) so that you only need to set layer.samples 
in one place, which will be more efficient.

Canvas just uses QPainter to do cpu rendering (pixel by pixel).  So there will 
be a texture the size of the canvas, and again it would be best to do as little 
of that as possible: put them all into one canvas.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Compile Qt 6.2.1 from source

[Shawn Rutledge]

On 2021 Sep 30, at 19:21, joao morgado via Interest 
mailto:interest@qt-project.org>> wrote:

Hi

I have a commercial Qt license, can I compile Qt 6.2.1 branch from source ?
I have reported some bugs that are now fixed in that branch, would like to try 
it.
I've been searching codereview repositories, but I'm a bit lost.

Just build the 6.2 branch from git.  https://wiki.qt.io/Building_Qt_6_from_Git
Of course by the time 6.2.1 is released, it will have many more changes.  You 
can keep pulling periodically to follow along.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML: support both Qt5 and Qt6

[Shawn Rutledge]

> On 2021 Sep 7, at 22:13, Alexander Dyagilev  wrote:
> 
> For example, we do use MessageDialog component. In Qt5, it requires import 
> QtQuick.Dialogs 1.3, and in Qt6 - import Qt.labs.platform 1.1.

You can use Qt.labs.platform in both versions.

> Is it possible to import different modules depending on the current Qt 
> version?

You can use different QML files and switch them with QQmlFileSelector; or use 
some build system technique, like pre-processing, or putting different qml 
files into resources depending on the version.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML: Image is blurred when rotated

[Shawn Rutledge]

> On 2021 Jul 29, at 19:45, Alexander Dyagilev  wrote:
> 
> Hello,
> 
> I have an SVG image which is drawn fine.
> 
> But if I rotate it (i.e. change its rotation property to some value) it is 
> drawn blurry.

How blurry?

Image.sourceSize is useful when working with SVG, to render at a specific pixel 
resolution.  But that might not be the problem, if you just mean that pixels 
are pixel-grid-aligned to begin with, and then of course they are not anymore 
when it’s rotated.

You can also try Image.antialiasing.  That may make it more blurry in a good 
way (because blur is better than jaggies: AA means fuzzy edges).

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Shawn Rutledge]

> On 2021 Apr 22, at 10:47, Rui Oliveira  wrote:
> What doesn't make sense, to me at least, is how QQC*1* seemed to have had a 
> better feature set for the desktop than QQC*2*.

The focus was on high-performance embedded use cases at first.  Now we are 
working again on making QQC2 better for desktop applications.  

> QML/Quick, for me, seems to need a lot of work for the desktop. Also, it 
> seems it's make for "flat", low density UIs. Yesterday I was presented with 
> this: https://ossia.io/ . Look how good it looks 
> (https://ossia.io/assets/score.png)! Holy damn, an that's widgets. And that's 
> a proper desktop productivity application. I mean, if we look at like NeoChat 
> (https://matrix.org/docs/projects/client/neo-chat/), which is made with KDE 
> Kirigami (a Qt Quick framework extension), or the Telegram desktop 
> application, they look all nice and all, but they lack the density.

That example looks like it has a lot of custom graphics.  For some, you could 
use QQuickPaintedItem (as long as the repaint rate is not too high); for some, 
it would make sense to break it down into static image assets, and use 
BorderImage to make them stretch.  Ultimately when you want complex and fluid 
graphics on the GPU, you need to educate yourself about the modern techniques 
(writing shaders and all the data that feeds into them).  It’s such a learning 
curve that many of us still don’t know the best way to build everything we 
want; I’ve done some of that work, and I want to learn to do more, because it’s 
exciting to leverage the GPU to such an extent that the CPU is nearly idle, 
free to just take care of the business logic and the setup work.  The “turtle 
graphics” approach is not going to get us there, but we know many programmers 
don’t know any other way.  It’s only good enough for mostly-static graphics.

I agree with the sentiment: don’t waste window space with whitespace, don’t 
oversimplify, don’t hide functionality that a lot of users need, don’t spread 
out conversations in chat apps just to make it look more “relaxed” at the 
expense of information density.  But you can realize dense designs with Qt 
Quick too.

When it comes to Controls 2 styles: we followed open, published design 
guidelines, which were made by contemporary designers with contemporary taste.  
But you can make your own style, and make it as dense as you want.  Controls 2 
consists of behavioral C++ code, with the rendering being done by instantiating 
Qt Quick items rather than by imperative QPainter code.  Different styles have 
different sizes for each control.

Using Controls 2 is not mandatory: you can build a whole set of controls from 
scratch using plain Qt Quick, that way you have as much design freedom as you 
want.  Before Controls 1, it had to be done that way, so it’s been done plenty 
of times here and there.  Some examples and manual tests in qtdeclarative have 
custom controls; the newest ones are in 
qtdeclarative/tests/manual/pointer/content.  They were written to validate that 
Pointer Handlers could be used for that, not to make a complete set of 
controls; but you could learn from those and make more.  The more customized 
you want it, the more I would recommend doing it that way.

Controls 1 was also built that way (but without the benefit of pointer 
handlers): pure component architecture with as little custom C++ as possible.  
Certain mistakes led to performance problems, but IMO it does not invalidate 
the concept: it’s possible to write simple sets of controls that have most of 
the functionality and also good performance, especially if the control has only 
a built-in style rather than trying to load various styles.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Shawn Rutledge]

> On 2021 Apr 15, at 12:25, Rui Oliveira  wrote:
> 
> Hey,
> As per the title implies, I would like some comments on the GUI offerings Qt 
> currently has. 
> 
> I'll share my own assessments and needs, and I'd like very much to hear your 
> comments.
> 
> So:
> 
> I want to write a desktop application. This desktop application would not 
> involve displaying lists of things, which seems to be what all 
> tutorials/guides/courses are about, especially on the QML side. This 
> application would involve some "custom graphics", namely a FFT display, and a 
> "waterfall" display. You can google for "GQRX" and you'll know what I want.
> 
You probably want to go with a shader-based solution for rendering those 
displays really fast on the GPU, without a high CPU load, assuming that you are 
rendering them from raw data, not generating images with some other library, 
and assuming that your users tend to have GPUs.  I think Qt Quick (and 
Controls) is a good fit, but check out the 
qtdeclarative/examples/quick/scenegraph/graph example and see if you’d like to 
render your displays like that.  It is more work than using QPainter, but 
probably worth it if the data is updating quickly.

If it turns out that you need to use QPainter for some reason, it’s going to be 
slower, higher CPU load, even higher if you want antialiasing; in that case, 
widgets are OK, or you can still use Qt Quick and subclass QQuickPaintedItem to 
do the custom rendering.  But it wouldn’t be my first choice.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 for Linux/X11 : "-qt-xcb" no longer supported?

[Shawn Rutledge]

> On 2020 May 22, at 16:25, Florian Bruhin  wrote:
> 
> Hey,
> 
> On Wed, May 13, 2020 at 05:48:09PM +, Kai Köhne wrote:
>> And indeed the linux documentation wasn't updated yet :/
>> 
>> https://codereview.qt-project.org/c/qt/qtdoc/+/300239
> 
> Is there some good place to start documenting what packages are needed for the
> XCB platform plugin? It took me a while to find out this is what I needed to
> install on Ubuntu (and I'm guessing Debian) so that my tests worked again on
> Travis CI:
> 
> - libxkbcommon-x11-0 (since 5.12 already)
> - libxcb-icccm4
> - libxcb-image0
> - libxcb-keysyms1
> - libxcb-randr0
> - libxcb-render-util0
> - libxcb-xinerama0

https://wiki.qt.io/Building_Qt_5_from_Git#Linux.2FX11

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 for Linux/X11 : "-qt-xcb" no longer supported?

[Shawn Rutledge]

> On 2020 May 13, at 16:57, Viet-Tam Luu via Interest  
> wrote:
> 
> Hi folks,
> 
> we've long used the -qt-xcb configure option to build Qt XCB support without 
> supplying the boatload of pesky dependencies, but contrary to what the Qt 
> 5.15 "Requirements" page 
> (https://doc-snapshots.qt.io/qt5-5.15/linux-requirements.html 
> ) says, it no 
> longer appears to be supported, now instead being a boolean argument 
> according to the configure error message I get when I try to specify it, and 
> confirmed by looking in qtbase/src/gui/configure.json.
> 
> Were the Qt-supplied XCB libraries removed from the Qt sources (and the 
> documentation is just out of date), or is the option still supported except 
> for a bug in the configure scripts?

They were removed in this patch: 
https://codereview.qt-project.org/c/qt/qtbase/+/253905


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtWayland Compositor cannot start from tty

[Shawn Rutledge]

> On 2020 May 8, at 19:55, Selastin George  wrote:
> 
> I built a qtWayland compositor and I was able to run it from my desktop 
> session.
> 
> Is there any way to start my compositor from tty (like just after boot)?.
> 
> When I tried to run it with --platform eglfs it gives error like
> 
> Unable to initialize egl display.

Yes that should work in general.  Something is wrong with your system 
apparently.

https://doc.qt.io/qt-5/embedded-linux.html 


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Handling stylus input on a tablet in QML/QtQuick

[Shawn Rutledge]

> On 19 Apr 2020, at 01:16, Thorsten Hofer-Schmitz 
>  wrote:
> 
> Hi
> 
> I'm trying to handle the input of a stylus on a tablet. Qt has an example on 
> how to do this using a QWidget-based application. I tested it on my tablet 
> and everything works fine.
> 
> I would like to do this in QML/QtQuick. The documentation suggests that 
> PointHandler, like this:
> 
> import QtQuick 2.14
> import QtQuick.Window 2.14
> 
> Window {
>visible: true
>width: 640
>height: 480
>title: qsTr("Hello World")
> 
>PointHandler
>{
>acceptedDevices: PointerDevice.Stylus
>acceptedPointerTypes: PointerDevice.Pen
>onActiveChanged: console.log("Pen Input")
>}
> 
> }

It should work in 5.15: see also QTBUG-79660 and the tablet manual test in 
qtdeclarative/tests/manual/pointer.

> I experimented with eventFilter's to intercept QTabletEvent's before they are 
> converted into mouse events by the QQuickWindow (as far as I can tell). But 
> unless there is a QWidget with WA_TabletTracking=true as target (and some 
> other options as it seems, because just a QMainWindow with a widget isn't 
> enough) I can't recieve TabletEnterProximity-events for hovering.

Those are currently not delivered to the main window, only to the application.  
So you still need a C++ subclass in Qt 5, as in 
qtbase/examples/widgets/widgets/tablet/tabletapplication.cpp.  I’m hoping to 
get more complete proximity event delivery in place in Qt 6.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will Qt6 end this enum issue? (or even 5.15?)

[Shawn Rutledge]

> On 19 Mar 2020, at 15:04, Jason H  wrote:
> It seems that enums should be class with a value and label
> console.log(camera.position.label) => "BackFace"
> console.log(camera.position.value) => 1

Yes I have often wished for a way to do that too.  qDebug() << enumValue works 
so well in C++ as long as you used the Q_ENUM macro, so it would be nice to 
have an idiomatic way to access the same debug operator in JS.  Then again, I 
wish we had ubiquitous toString() like Java has, instead of the debug operators 
only being accessible when you’re using qDebug.  (I think the reason we don’t 
is that people might think of toString() as a serialization mechanism?  But I’m 
not sure.). Maybe there’s another idiom on JS that I don’t know about.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QQuickImageProvider for PDF rendering

[Shawn Rutledge]

> On 11 Feb 2020, at 15:38, Neubert Stefan  wrote:
> 
> Hi list,
> 
> we are using a QQuickImageProvider to load and render PDF pages through qtpdf 
> to display the pages in QtQuick.
> Right now we use an additional qmlExtentionPlugin to get the information 
> about a pdf document, like page count
> and request the page images in a QtQuick Image by setting the source property 
> to something like
> "image:://ProviderName/PathToPDF/pageNumber". The image provider has some 
> queues holding the last
> requested documents and pages to avoid reloading the pdfs all the time. This 
> is working quite fine.
> 
> We are searching for an approach how to avoid the double loading, in our 
> extention plugin and in the image provider.
> 
> One idea was to extend an image provider with Q_PROPERTY or something else to 
> access the meta data of the loaded
> pdfs, like accessing a singleton object in QtQuick, but we don´t know if this 
> would be the right approach or even possible.
> The qt blog about qtpdf in 2017 said something about adding QtQuick support, 
> but there has not been any work on it.
> 
> Any suggestion on how to properly implement qtpdf in QQuick or how to extend 
> an image provider with additional
> meta data is welcome.

I’m working on the QtQuick feature set now.  You can get the latest unfinished 
code from the wip/qtpdf branch in the qtwebengine repo.  We moved qtpdf there 
because of the build system, mainly (chromium switching build systems made it 
difficult to upgrade the pdfium version in the old qtpdf repo, but the work was 
already mostly done in the webengine repo).

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Tooltips and Anchors with QSyntaxHighlighter

[Shawn Rutledge]

> On 21 Jan 2020, at 13:21, Jonathan Purol  wrote:
> 
> Hello everyone,
> 
> I should note this is my first time posting to a mailing list, so apologies 
> if I'm messing up something.
> 
> We're currently trying to write an editable text editor which has two modes, 
> edit and view. In edit mode you can make changes using a specific syntax, and 
> in view mode that is rendered with your usual text-editor things.
> The following features ought to be supported:
> 
> * Bold, Italic, Underlined, and strikethrough text
> * Different font sizes
> * Lists
> * Table Of Contents (i.e. hyperlinks that jump to some place in the text)
> * Coloured Text
> * Aligned Text (horizontal alignment suffices)
> * And two special features:
> --> Links written in markdown format [display text](link) should be clickable 
> and emit a signal `linkClicked(QString const& text)` | Note: They will not be 
> opened in the browser, but rather link to something else in the application

Well if you wanted just a markdown editor, it would be easy with Qt 5.14 since 
we just added that as a feature.  But your special syntax is different?

> --> Hovering those links should open a tooltip which is able to render the 
> HTML4 subset QT provides for all tooltips

I didn’t get around to trying to implement tooltips in my markdown editor yet, 
but that sounds nice to have.

> I was delighted to see that QTextCharFormat 
> (https://doc.qt.io/qt-5/qtextcharformat.html) already ships with `setTooltip` 
> and `setAnchor`/`setAnchorHref`/`setAnchorNames`, however once I tried to use 
> those, nothing happened.
> I scoured around online and found two bug reports, both either unanswered, or 
> closed. Digging a bit through the source, it seems that those exact two 
> features are not implemented yet:
> https://github.com/qt/qtbase/blob/bef74b6c3a0a9c8649ea8eb333d80015f76863e4/src/gui/text/qtextodfwriter.cpp#L751
> 
> The two bugreports:
> https://bugreports.qt.io/browse/QTBUG-21553
> https://bugreports.qt.io/browse/QTBUG-80524
> 
> 
> My questions now are:
> 1. Is that a really bug, i.e. was it just forgotten? The first bug report 
> exists since 2011, though I'm unsure of how common it is for TODOs to exist 
> that long in QTs code base.
> 2. If not, is there an ETA for those features, or a plan for when they'll be 
> released?
> 3. If the answer to 2. is not "very soon", what approach should I take to 
> implement those features manually. The timeplan for the document editor was 
> around a month - or at most two, and I'm the sole developer on it, so I'm 
> looking for something that's doable in that time frame (I.e. not having to 
> write everything from scratch).

I doubt there was any plan, but if it turns out not to be too hard to fix, 
maybe there’s still time for 5.15.  I don’t know if I will have time to look at 
it anytime soon, but maybe.  (The highest priority bugs are the ones from 
paying customers who have been nagging Qt Support.  As you can see, these bugs 
have not been prioritized.  Yes we have a lot of such bugs that we haven’t 
found time to fix, unfortunately.)

I also didn’t get around to trying syntax highlighters for code blocks in 
markdown, but I’d like to.  It’s a matter of finding spare time for that, since 
I have plenty of other things to keep me busy.

> I'm aware of `QTextBrowser`, so combining that with `QTextDocument::setHtml` 
> would be one option, though I'm unsure if that would suffice/scale, as we 
> would have to manually reparse user input into HTML, doable, but certainly 
> not as performant.

You could reparse it to markdown if that’s easier.

Or write your own importer.  You can look at 
qtbase/src/gui/text/qtextmarkdownimporter.cpp and see if you want to write 
something similar for your syntax.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] android: QStorageInfo::mountedVolumes does not "see" SD card

[Shawn Rutledge]

On 16 Sep 2019, at 16:56, Alexander Dyagilev 
mailto:alervd...@gmail.com>> wrote:

On my android 9.0 phone it returns one "/" volume only. But I have SD card 
installed.

Is it a bug? Should I file a report?

Back when we implemented QStorageInfo it looked like this for me on one device 
that I tested (not sure if that was after the patches were actually committed 
though):

http://ecloud.org/misc/android-volumes.png

I wonder if they have changed how mounting is done in newer Android versions.  
(Yeah I could build that example and test again.  It’s 
qtbase/examples/widgets/itemviews/storageview BTW.)

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] My first 5 years with Qt and 2 suggestions

[Shawn Rutledge]

> On 10 May 2019, at 01:20, Hamish Moffatt  wrote:
> 
> Actually, I'd turn this around and say shame on the Qt project for not 
> publishing packages, at least for the major distributions.
> 
> It's Debian's policy to publish stable releases which don't change except for 
> security and other essential updates. There is no argument for updating Qt in 
> a stable release.

So “stable” just means old in practice, and thus uninteresting for developers.  
Same thing with Ubuntu and Raspbian and others that have been influenced by 
this belief that older software has fewer bugs by definition, or that known 
bugs with known workarounds are better than fewer bugs.  But Qt 5.12 is LTS, so 
I think every contemporary LTS distro ought to be using it, because it will 
still be getting fixes for about as long as the distro is supported.

What reminded me again most recently was the announcement that brand-new Gnu 
GUIX 1.0 was just released a few days ago:

https://www.gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released/

“Guix follows a so-called 'rolling release' model, so you can run guix pull at 
any time to get the latest and greatest bits of free software.”  But Qt 5.11.3 
… ugh.  https://www.gnu.org/software/guix/packages/Q/  One would think if their 
goal is a rolling release that they probably have tried to automate building 
newer stuff and trying to upgrade continuously.  (Maybe it will get ramped up 
soon?)  For Arch on the other hand it just doesn’t seem to be a big deal: Qt 
gets released almost simultaneously with our releases, the applications that 
depend on it are getting rebuilt pretty often too, and it almost always just 
works.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] My first 5 years with Qt and 2 suggestions

[Shawn Rutledge]

> On 9 May 2019, at 02:09, Henry Skoglund  wrote:
> 
> Hi, 5 years ago I started with Qt, it's been a very nice ride, thank you! 
> Looking forward to the next 5. Got 2 suggestions:
> 
> 
> 1) Make Qt more easily accessable for first timers:
> 
> Why not introduce a Qt Starter Pack?
> 
> I'm thinking of an *extremely* simplified installation tool. For Windows, it 
> could be Qt LTS version bundled with the 32-bit MinGW compiler.

That’s suitable for C++ developers.  There are other ideas in the works about 
how to use standard C++ package management tools (like conan) to find and 
install Qt.  Of course on Linux there are usually distro packages so it’s 
already easy (as long as you don’t mind them often being a bit outdated: shame 
on distros who still didn’t upgrade to 5.12 yet).  And macOS has brew.

Another thing I wish we would get done is to make qml (the runtime tool) 
available as a package, including at least Qt Quick and Controls 2, and get it 
into the OS-specific app stores.  So you could run “pure QML” apps without 
needing a compiler at all.  It’s for end users, and also for very 
beginner-level developers who only know a bit of JS (or could learn) and are 
still intimidated by C++.  We should be more consistent about OS integration of 
QML: make it as easy to run qml files from the file manager as any other 
scripting language is, by default.  (The installer should register the file 
type in the right way.)

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] TapHandler tapped coordinates not accessible

[Shawn Rutledge]

> pon., 6 maj 2019 o 21:56 Shawn Rutledge  napisał(a):
> 
> > On 6 May 2019, at 16:30, Tomasz Olszak  wrote:
> > 
> > Hi,
> > 
> > I use Qt 5.12.3 and I'm trying to use TapHandler. For some reason though in 
> > onTapped handler point is already reset.
> > I see that point is valid when reading it from onPressedChanged. Is it a 
> > bug? Seems like docs miss explicit example of reading point coordinate.
> > 
> > This is snippet I use to test.
> > https://pastebin.com/h8PneRDB
> 
> You can use eventPoint instead of point: it is the signal parameter, and it 
> does have correct position etc.

> On 6 May 2019, at 22:11, Tomasz Olszak  wrote:
> 
> I would like to move to new input handling from old pinch area etc.
> 
> Shawn that was what I was looking for. Any idea why it is not documented?

Yes it really should be.  https://codereview.qt-project.org/#/c/261101/

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] TapHandler tapped coordinates not accessible

[Shawn Rutledge]

> On 6 May 2019, at 16:30, Tomasz Olszak  wrote:
> 
> Hi,
> 
> I use Qt 5.12.3 and I'm trying to use TapHandler. For some reason though in 
> onTapped handler point is already reset.
> I see that point is valid when reading it from onPressedChanged. Is it a bug? 
> Seems like docs miss explicit example of reading point coordinate.
> 
> This is snippet I use to test.
> https://pastebin.com/h8PneRDB

You can use eventPoint instead of point: it is the signal parameter, and it 
does have correct position etc.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Track global mouse position in QML

[Shawn Rutledge]

> On 21 Mar 2019, at 15:05, Jérôme Godbout  wrote:
> 
> Why not use a MouseArea or the new HoverHandler.

Yes HoverHandler should work, as long as event propagation doesn’t stop before 
it gets there… i.e. if you have trouble with that, put it inside an Item that 
is on top of the rest.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtLocation MapPolyLine and MouseArea

[Shawn Rutledge]

> On 8 Mar 2019, at 11:29, maitai  wrote:
> 
> Yes with anchors.fill:parent, Pressed/Released works only if the mouse is 
> exactly on the line, while hover seems to use the bounding rect of the 
> polyline...
> 
> But anyway with containmentMask: polyline, all is OK and hover occurs only 
> exactly on the line.
> 
> The only thing one could hope for is a possibility to make the mouse area a 
> bit thicker than the line width, because with thin lines it is difficult to 
> be exactly on it.

You could maybe use an invisible polyline (zero opacity?) just to define the 
mask?  But it will waste memory of course, if you need to have a lot of 
selectable polylines.  The Event Handlers (like HoverHandler and TapHandler) 
have a margin property, but so far we have not made it apply to the mask, but 
rather override the mask (it will hit-test the rectangular bounds with a margin 
applied, i.e. it will test a larger rectangle if the margin is positive).  It 
might be nice to have it check the mask with a margin applied, but that might 
be expensive, and would anyway involve creating an extra QPainterPath to 
represent the “expanded hull” of the shape (or maybe just the stroke of the 
shape if that’s what you want).  For now we are looping and checking contains() 
on every QPainterPath from which the Shape is composed… which has its own 
expense (memory vs. CPU trade-off).  ContainsMode could have a new value 
HullContains or something like that.  See the implementation in 
QQuickShape::contains():

bool QQuickShape::contains(const QPointF ) const
{
Q_D(const QQuickShape);
switch (d->containsMode) {
case BoundingRectContains:
return QQuickItem::contains(point);
case FillContains:
for (QQuickShapePath *path : d->sp) {
if (path->path().contains(point))
return true;
}
}
return false;
}

That’s just an idea… I haven’t tried to implement it.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtLocation MapPolyLine and MouseArea

[Shawn Rutledge]

> On 7 Mar 2019, at 18:32, maitai  wrote:
> 
> Hi,
> 
> I need to trigger various actions whenever a MapPolyLine is hovered or 
> pressed, such as displaying a tooltip, a menu, etc.
> 
> I have put a MouseArea on it with anchors.fills: parent, but the problem is 
> that the mouse area does not represent the line, but the polygon made by the 
> line. For instance if you have a L shape, entered event and so on is 
> triggered when you enter the bounding rectangle of the line, not when you 
> hover over the line itself.
> 
> On a QGraphicsScene we had the shape() protected method for that kinds of 
> case, for instance with a QPainterPathStroker to give some thickness to the 
> line's "mousearea".
> 
> I will probably end with a custom property that will carry the pixel distance 
> between the line segments and the mouse coordinates, but this is going to be 
> heavy to compute (I have potentially hundreds of complicated lines on the 
> map).
> 
> Is there a better way or even better a standard way to do that?

Check out containmentMask: that’s how you can redefine the behavior of 
MouseArea’s contains() method in QML.

You could use HoverHandler and/or TapHandler though, and then perhaps set 
containmentMask on the polyline itself if behavior is still not what you want 
(I haven’t tried it with MapPolyLine myself, only with QtQuick.Shapes).

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Shawn Rutledge]

> On 22 Feb 2019, at 13:24, Bernhard B  wrote:
> 
> Many thanks to Tuukka for the Qt Roadmap 2019 blog post 
> (https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much 
> appreciated! 
> 
> As the mobile part was not explicitly mentioned, I assume that it won't be a 
> focusing area for 2019 then? :/

Well-bounded features like notifications can still be done if somebody finds 
the time to do it.  I think that one is good to get done, whether it’s on the 
roadmap or not, as a cross-platform feature.  I’m kindof interested because I 
worked on Linux D-Bus support for QSystemTrayIcon a while back, and I think 
that’s related to desktop notifications.  I think someone else is interested in 
working on it too.  But I won’t realistically get around to it anytime soon 
unless a good reason comes up (like having it be a priority either for the 
company or for a personal project).

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] vs. Flutter

[Shawn Rutledge]

On Feb 18, 2019, at 17:18, René Hansen 
mailto:ren...@gmail.com>> wrote:

On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge 
mailto:shawn.rutle...@qt.io>> wrote:

> On 18 Feb 2019, at 15:40, René Hansen 
> mailto:ren...@gmail.com>> wrote:

> Achitecturally it's similar to Qt, in that they've build a custom renderer on 
> top of Skia, so the whole scene is basically just OpenGL, which makes it 
> really fast.
>
> Component wise, their UI library offers bother Cupertino and Material design 
> out of the box, and from initial impressions, looks to be closer to the 
> original design guidelines than Qt Quick Controls for. e.g. Material.

In what way?

This might just be my own personal experience, but I've run into weird and 
"finicky" behaviours with Qt Quick Controls, quite a number of times and so 
far, from the admittedly smaller sample size, I've not seen the same issues 
with widgets in Flutter.

That still sounds vague.  I hope you will write up bugs with concrete examples 
of what’s weird.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] vs. Flutter

[Shawn Rutledge]

> On 18 Feb 2019, at 15:40, René Hansen  wrote:
> 
> I've not come across any myself, and have only built a few small things with 
> it a bit for now.
> 
> Initial reactions was that it is *leagues* ahead of Qt with regards to 
> developer experience. You're not locked to an IDE, like with QtCreator,

Strictly speaking you’re not locked into using QtCreator either: I've done 
command-line builds of Android apps once in a while.  You can watch what 
Creator does and do the same yourself.  But it’s not as straightforward as it 
could be, and the script I made to automate it needs to change since earlier Qt 
versions.  Something like

qmake
make install INSTALL_ROOT=.
androiddeployqt --input something.so-deployment-settings.json --output 
/path/to/android-build --android-platform android-27 --jdk /usr/lib/jvm/default 
--gradle

I wish we would make it a universal one-liner without having to find paths to 
things first.  Perhaps someone could figure out how to do that with cmake 
eventually.

> and the ui live updates across device, simulators, emulators etc. when you 
> write changes. No need to build and .apk and wait for a build+deploy.

I wonder how well-understood that mechanism is, so that someone could even try 
to get that working with Qt?  If it should not be part of the IDE, it would 
have to be some daemon that watches the filesystem, recompiles and re-deploys 
classes, right?  But at this point it’s up to someone to volunteer to figure 
that out I suppose.

> There's no JS involved. It's Dart all the way. It doesn't even ship with a 
> web runtime afaik.

In other words it’s another new language all the way, but the advantage is it 
gets compiled to native code.  But QML can be compiled, and anyway doesn’t 
depend on a web runtime.  I doubt you can say that Dart has no runtime at all?  
If there is garbage collection, there’s a runtime; the question is which one, 
how big is it and what does it provide.

An advantage when a phone or OS vendor decides to support a particular 
development framework is that they can ship parts of it pre-installed.  So the 
best phone for Qt applications is one that’s built with Qt in the first place; 
but the Big Two didn’t make that choice, so we can only hope that some 
not-so-small player will eventually do that (again).  I recently tried Ubuntu 
Touch (yeah, better late than never): it seems quite nice, it’s just missing a 
lot of apps.  There is Jolla.  And there is Plasma Mobile… and maybe the Librem 
5 will end up with Qt in some way?  We’ll see.

> Achitecturally it's similar to Qt, in that they've build a custom renderer on 
> top of Skia, so the whole scene is basically just OpenGL, which makes it 
> really fast.
> 
> Component wise, their UI library offers bother Cupertino and Material design 
> out of the box, and from initial impressions, looks to be closer to the 
> original design guidelines than Qt Quick Controls for. e.g. Material.

In what way?

> I haven't tried it out myself yet, but you should be able to reach into 
> native world by using platform channels:
> 
> https://flutter.io/docs/development/platform-integration/platform-channels
> 
> It's seems like it's quite a ways worse than with Qt though, so there's at 
> least that.

What do you mean?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Work for hire to solve a Qt bug that's been a thorn in our side.

[Shawn Rutledge]

> On 15 Feb 2019, at 21:24, Paul Knopf  wrote:
> 
> Are there any experienced Qt developers out there interested in solving this 
> bug that my company is experiencing? Maybe you know someone who is interested?
> 
> https://bugreports.qt.io/browse/QTBUG-73830
> 
> It is easy to reproduce with any Qt version, on Linux.

It’s a bug that needs to be fixed; we have paying customers asking about it 
too.  I’ll have a look.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crazy idea 2019-1

[Shawn Rutledge]

> On 7 Jan 2019, at 17:27, Jason H  wrote:
> 
> I'm now numbering my crazy ideas. That may in itself be a crazy idea, if so, 
> that's 2019-0.
> 
> 2019-1 is that Qt Blog posts (blog.qt.io) should be included in the 
> documentation ,cross-referenced with the classes mentioned within. For 
> example, 
> http://blog.qt.io/blog/2017/01/20/inside-qimage-touch-qt-quick-opengl/ gives 
> some _very_ useful information about QImage formats. I would suggest this be 
> included and cross-lined in the docs for QImage. It also mentions QPainter, 
> and OpenGL. I've come to this suggestion because a lot of times when people 
> are asking about Qt, there is a blog post that covers what they are looking 
> for. Similar to QtQuartely (anyone remember that?) they contain a lot of good 
> information. The problem is they just don;t the rource exists and what its 
> covered.
> 
> So that's my idea. I'd expect it implemented as a section before "Detailed 
> Description" as "Relevant Articles" which is a link of the title to the 
> content (contained in Qt, not online, because we change domains too often).

It sounds like a good idea to me.  You can write it up as a suggestion for the 
docs team if you like on bugreports.qt.io.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Android IRC channels

[Shawn Rutledge]

I would suggest switching to #qt-android permanently, because it follows the 
pattern (we have a lot of #qt-foo channels), whereas necessitas was the name of 
the Qt 4 port to Android.  https://necessitas.kde.org/ says "Necessitas project 
was completely 
merged
 into Qt project and KDE Free Qt Foundation 
Agreement was 
amended to cover Qt for Android 
Port.
  We suggest you all to to switch to Qt5.” So it seems to me the name is 
obsolete for us, but people could still hang out there and discuss issues with 
other versions (such as the Qt 4 version).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] efficient natural sorting

[Shawn Rutledge]

> On 14 Nov 2018, at 03:28, Frank Rueter | OHUfx  wrote:
> 
> Hi,
> 
> I need to use the QSortFilterProxyModel to sort strings with numbers in them, 
> i.e. perform natural sorting.

Another idea is to add a different role to your model, have data() return the 
original number (int or qreal or whatever) in the variant for that role, and 
call setSortRole() to tell QSFPM which role to use.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] new TableView columns hiding

[Shawn Rutledge]

> On 24 Oct 2018, at 09:24, Vlad Stelmahovsky  
> wrote:
> 
> Hi all
> 
> investigating new TableView, added to 5.12 and have a question: is it 
> possible to hide some columns dynamically w/o modify model?
> 
> bruteforce way to set column width to 0 doesnt works, because its checking 
> width and force set it to some minimal value (have no idea, why)

Why: because the layout algorithm could have a bad edge case if some columns 
are zero-width.  (It keeps trying to fill the width of the view, but maybe it 
will never get there?)

I ran into that while preparing for my QtWS talk about TableView.  But I needed 
to subclass QSortFilterProxyModel anyway, to have sorting and filtering; so it 
was also not too hard to change the columns there by overriding mapFromSource 
and mapToSource.  You could think of your QSortFilterProxyModel subclass as a 
“view model”, and use it do whatever corrections you need to make to the 
original model to make it presentable.  At least that’s what I came up with for 
now.

https://github.com/ec1oud/qps/blob/unsquashed/qtquick/sortfilterprocessmodel.cpp

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Can't receive released/clicked correctly from touch screen

[Shawn Rutledge]

> On 28 Sep 2018, at 11:10, nus1998  wrote:
> 
> Hi All,
> 
> I'm testing on a dialog with a touch screen, for mouse event, sometimes there 
> is only "pressed" event, or only "released" and "clicked" events. but when 
> checking the touch event, each timeTouchBegin and TouchEnd events are 
> received.
> I have tried set Qt::AA_SynthesizeMouseForUnhandledTouchEvents but doesn't 
> work.
> 
> PS: the Qt version is 5.9.6 with linuxfb platform.
> 
> B.R.
> Nus

If you have some example code that demonstrates the problem, I’d like to have a 
look.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Best practices on pinch-zoomable item container with non-zoomable item attached

[Shawn Rutledge]

> On 13 Sep 2018, at 16:13, Alexander Ivash  wrote:
> 
> What I meant is rather anchors.centerIn: child (so that child would
> free-zoom relatively center, and parent would center itself relatively
> center of the child)

Since the child’s coordinate system is relative to its parent, I don’t think it 
makes sense to anchor a parent to a child.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Priority of bugs

[Shawn Rutledge]

> On 21 Sep 2018, at 01:07, Nyall Dawson  wrote:
> 
> FWIW, I've also encountered some serious issues with this
> functionality under gnome, where floating docks will get stacked under
> main windows if they were previously tabbed and restoreState is
> called. The only "fix" is to disable this feature by not setting
> QMainWindow::GroupedDragging.

I noticed in Creator that if I have a file dialog open, it’s possible to put 
the main window on top of the dialog.  Sounds like maybe it’s related...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Pointer Handlers: how to use 'GrabPermissions'

[Shawn Rutledge]

> On 18 Sep 2018, at 18:48, Shawn Rutledge  wrote:
> Because it accepts the point, that means the event will not propagate to the 
> other TapHandler.  

Oops that’s quite a wrong explanation… after more debugging and reading the 
code yet again, now I realize I was right the first time when I said that even 
when the TapHandler that takes an exclusive grab, it "doesn’t stop delivery to 
other handlers”.

While QQuickWindowPrivate::deliverPressOrReleaseEvent() iterates all the target 
items: if after visiting one item and its handlers, all points are accepted, it 
does NOT stop: it merely stops delivering directly to Items, but continues 
delivering to the remaining target Items’ Handlers.  
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquickwindow.cpp?h=5.12#n2554
  So it does propagate to the other TapHandler.  But if the point already has 
an exclusive grabber at the time that the underlying TapHandler sees it, then 
wantsPointerEvent() returns false (see 
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/handlers/qquicksinglepointhandler.cpp?h=5.12#n113
 ) with the result that the underlying TapHandler will not handle the event.  
But if the gesturePolicy of the topmost TapHandler is DragThreshold, then that 
one only takes a passive grab, so the underlying TapHandler does handle the 
event.  (A passive grab means the top one is “just lurking”, watching what will 
happen.)

So currently Pointer Handlers don’t have the ability to stop propagation to 
other handlers, but they do honor the intention of the exclusive grab.

Based on that, the question of whether TapHandler should have a property to 
control whether or not it accepts the point is less relevant.  In general, 
handlers accept the points that they’ve decided to handle, and it’s documented 
that they should.  (One exception is PointHandler, because it’s nothing more 
than a lurker: its goal is never to interfere, only to monitor the movements of 
the event points.)

It’s still confusing that you have to change gesturePolicy to get what you want 
though.

For a while, the default gesturePolicy was ReleaseWithinBounds, so it would 
have taken an exclusive grab on press, and you would have gotten the behavior 
you wanted by default.  We changed it because of how handlers interact with 
QtQuick.Controls and other event-handling Items ( 
https://codereview.qt-project.org/#/c/217632/ ).  You shouldn’t normally need 
to pile up MouseAreas or TapHandlers on top of existing controls, because 
Controls are supposed to work well already, and they are designed to handle all 
the events for all supported use cases in C++ rather than by composition of 
handlers… but people keep trying to do that anyway.  If you put a TapHandler on 
a Button, and then you can’t click the Button anymore, you might report a bug 
about it.  To stave that off, and because we can expect that Handlers and 
event-handling Items have to coexist in many cases, we tried to go towards an 
architecture where events propagate further.  (I think it might be quite useful 
to put a DragHandler on any kind of Control to be able to drag it around, 
because dragging is not a feature that most Controls have built-in.  But again, 
putting a DragHandler in a Button should not prevent you from clicking it.)  So 
it seemed appropriate at the time that TapHandler should only take a passive 
grab by default, because that works well enough in many single-layer simple use 
cases too.  And giving the handlers full control to decide when an event is 
relevant or not, rather than cutting off delivery before some of them are 
visited, ought to be more flexible, right?

You still have grabPermissions as a workaround in case too much grab-stealing 
is going on.

And maybe there will be an Item.modal property eventually…  that’s intended to 
be a way to absolutely stop propagation of all events at a particular layer of 
your Item hierarchy, for example, the parent frame of some sort of in-scene 
dialog or popover.  But it didn’t get done in time for 5.12.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Pointer Handlers: how to use 'GrabPermissions'

[Shawn Rutledge]

> On 18 Sep 2018, at 14:36, Alexander Ivash  wrote:
> 
> Hi Shawn,
> 
> I'm still curious about best practices on implementing use case I
> mentioned previously: To refresh memory I need a 'canvas' with some
> 'items' inside. Simplified version looks like this:
> 
> ApplicationWindow {
>visible: true
>width: 640
>height: 480
> 
>ScrollView {
>anchors.fill: parent
> 
>Flickable {
>Rectangle {
>anchors.fill: parent
>color: 'yellow'
> 
>TapHandler {
>onTapped: {
>console.debug('item deselected');
>}
>}
>}
> 
>Rectangle {
>width: 50
>height: 50
>color: 'green'
> 
>TapHandler {
>onTapped: {
>console.debug('item selected');
>}
>}
>}
>}
>}
> }
> 
> Tapping canvas should result in item de-selection, tapping item should
> result in item selection. So I need item's tap handler to do not
> propagate tap (although maybe wouldn't mind propagating long presses).

I tried: if you change the small green rectangle's TapHandler to have either 
gesturePolicy: TapHandler.ReleaseWithinBounds, or TapHandler.WithinBounds, it 
works.  Because it accepts the point, that means the event will not propagate 
to the other TapHandler.  But that’s unintuitive API for this use case.  So we 
should try to come up with something more sensible I suppose.

There is https://codereview.qt-project.org/#/c/227659 which proposed to add a 
TapHandler property called blocksTaps.  I didn’t think that was the right name 
for it.  But I think it was intended to solve the opposite problem: a 
TapHandler is somehow on top of a MouseArea, and we want both of them to get 
the event.  If you have set gesturePolicy: TapHandler.ReleaseWithinBounds, and 
that stops propagation, maybe you need a way to continue propagation instead.

An Item can either accept or reject an entire event.  When multiple touchpoints 
are pressed, we deliver a custom event to each Item, an event that has only the 
touchpoints that are inside the Item’s bounds.  So accepting that custom event 
means accept all the touchpoints, excluding the touchpoints which are not part 
of that event.  But for Handlers, we want to deliver the entire event to each 
handler, because that improves flexibility (PinchHandler can react to points 
slightly outside the item bounds, for example); therefore Handlers accept 
individual points, not the whole event.  In general, accepting all points 
_implies_ accepting the entire event, but it may be that one handler accepts 
some points while another accepts other points.  This is how it’s now possible 
to interact with multiple handlers at the same time, but delivery is not “done” 
until all the points are accepted.

So if we add another property to QQuickPointerHandler, it would be to control 
whether a particular handler instance will accept the subset of points that it 
determined were relevant to it.  What should it be named then?  acceptPoints?  
greedy?  stopPropagation?  Do any of those make sense to designers, or to 
anyone who doesn’t understand event delivery?  I suppose changing gesturePolicy 
should automatically change the default value of that property too (because 
otherwise people will complain that changing gesturePolicy does not change 
behavior), while setting both properties could be allowed, but some 
combinations might be dysfunctional.

Also, we have properties like acceptedMouseButtons, acceptedModifiers and so 
on, but there “accept” means “react to an event”, not “stop propagation”.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Best practices on pinch-zoomable item container with non-zoomable item attached

[Shawn Rutledge]

> On 13 Sep 2018, at 14:41, Alexander Ivash  wrote:
> 
> I need pinch-zoomable item container with non-zoomable item container
> attached to the bottom. Like this:
> 
> Item {
>   id: item
>   Item {
> id: zoomable
>}
> 
>   Item {
> id: nonzoomable
>   }
> }
> 
> (anchoring, geometry omitted for simplicity)
> 
> I see at least the following solutions:
> 
> 1. Change 'scale' of the whole item (zoomable + non-zoomable), then
> change 'scale' of non-zoomable to compensate parent scaling. It feels
> a bit wrong so I'd like to avoid it. Also doing in this way leads to
> some issues with anchoring non-zoomable item to zoomable one properly.
> 
> 2. Change 'scale' of the zoomable part only. But in this case I need
> to adjust x/y of 'item', otherwise scaling will always be happening
> relatively top/left (and I need relatively to the center)

PinchArea only sets the scale property of the zoomable item directly, and that 
is relative to the Item transformOrigin which defaults to center.

PinchHandler zooms relative to the centroid between the touchpoints, which is 
more typical behavior like what you get in most non-Qt interfaces (you need to 
be able to zoom into a particular geographical area of a map, or an interesting 
part of some drawing, for example).  It normally does that by setting the scale 
and the x and y properties at the same time.  But it’s not overriding 
anchors.centerIn: parent, so you can still use that to keep your item centered.

If yours is always zooming toward the top left, it must be because of your 
anchors or bindings, or because of setting  transformOrigin to TopLeft.

You could use another wrapper item to hold the place in the layout, and then 
add your zoomable item to that.  If it has no bindings or anchors, it can be 
free to zoom and move around within that space.  If you want to disable 
movement, or allow movement only within certain confines, you can try the 
minimumX/Y and maximumX/Y properties.

> Is there better way to do it?
> 
> If there would be a way to center parent in child - I could anchor
> 'item' to the center of 'zoomable' and everything would work
> magically. But such kinds of anchors are not supported.

anchors.centerIn: parent

What I sometimes wish we had is _bindable_ centerX/Y properties.  But at least 
we have anchors.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Pointer Handlers: how to use 'GrabPermissions'

[Shawn Rutledge]

> On 2 Sep 2018, at 18:52, Alexander Ivash  wrote:
> 
> Is there any example of usage 'GrabPermissions' from QML ? 

So far we don’t have many examples with pointer handlers in general (we need to 
work on that for 5.12 and onwards) but the manual tests cover some of the 
initial obvious use cases:  qtdeclarative/tests/manual/pointer

> I've tried to do this:
> 
> TapHandler {
> grabPermissions: GrabPermissions.CanTakeOverFromHandlersOfSameType |
> GrabPermissions.CanTakeOverFromItems |
> GrabPermissions.CanTakeOverFromHandlersOfDifferentType |
> GrabPermissions.ApprovesTakeOverByAnything
> onTapped: {
> console.debug('text tap handler')
> }
> }
> 
> but it resulted in syntax errors.

The enum is nested in the PointerHandler base class, so at the moment you can 
use whatever scoping is convenient, the base or any subclass:

grabPermissions: PointerHandler.CanTakeOverFromHandlersOfSameType | 
TapHandler.CanTakeOverFromItems | 
PinchHandler.CanTakeOverFromHandlersOfDifferentType | 
PointHandler.ApprovesTakeOverByAnything

Yeah that’s silly (in practice you’d probably use either PointerHandler or 
Handler scoping consistently).  Does anybody think we could or should try 
to lock it down further somehow?  (Omitting the scoping altogether might be 
nice, wouldn’t it?  But we probably can’t.)

> Btw, documentation seems to be broken - it shows 'grabPermissions' as boolean 
> property

Yes that’s wrong.  https://codereview.qt-project.org/#/c/239399/

> Also, do I understand correctly that grabPermissions is the only way to make 
> one TapHandler to consume events so that other TapHandler will not get any?

I was hoping that conflicts between handlers will be rare, because you have 
more declarative control over the geometry within which a handler handles 
events, which device type the event can come from, which buttons are allowed, 
modifiers etc., and therefore the need to use grabPermissions should also be 
rare.  But of course we can’t imagine all the use cases either.  So how did you 
get into the situation that two TapHandlers are grabbing from each other?  They 
are on different Items, I suppose?  A parent and a child?  Do you have a simple 
testable example to show?

There are two kinds of grabs now, and gesturePolicy controls which kind of grab 
TapHandler will take.  As the docs explain, if the TapHandler that gets the 
event first (the top one in effective “Z-order” [even though only Items have a 
z property]) has gesturePolicy set to WithinBounds or ReleaseWithinBounds, then 
it needs to take an exclusive grab on press (same thing that MouseArea would 
do) to get the intended behavior.  That means it will get the updates and the 
release.  However it doesn’t stop delivery to other handlers, so yeah, another 
handler which receives that same press event can steal from the handler that 
just took the grab.  You can use grabPermissions to make the topmost handler 
“more greedy” (refusing to give up its grab) or to make the second one “more 
polite” (refusing to steal).  I would suggest trying to build your UI as 
cleanly and tersely as possible and then see how few places you can use 
grabPermissions to fix the remaining conflicts, not sprinkle them all over.

On the other hand if gesturePolicy is DragThreshold, it only takes a passive 
grab on press.  This doesn’t obstruct the delivery process to Items (or other 
handlers) at all: it means the handler will get any future events involving the 
same point (the moves and the release) _in addition to_ any other grabbers that 
get them.  So it can see when the point is released and emit tapped(); and it 
can also see if the point moves past the drag threshold (and gives up the 
passive grab in that case), so that tapped() will not be emitted.  Passive grab 
works well enough to implement that behavior, so it doesn’t bother with an 
exclusive grab.

The purpose of tech preview in 5.10 and 5.11 was in the hope that there would 
be some experience with using handlers before the 5.12 LTS release, and some 
interesting cases would emerge so that they could be solved in time.  But now 
we already have an API freeze for 5.12.  But maybe there is still a little time 
for some small tweaks if necessary.

I’m not 100% sure that accepting the event _should_ mean “stop delivery to 
everyone else”.  But it’s traditional.  (Is it common in non-Qt APIs too?)  You 
have to understand delivery order a little for the idea of accepting individual 
events to make sense, so I have doubts that it’s a friendly API; for UI 
designers and QML newbies it would be better if they never had to think about 
that.  Delivery of events to items and handlers is interleaved according to 
effective Z order, and we have to keep the traditional behavior when delivering 
to Items to keep source compatibility.  But when architecting the handlers we 
figured we could change the rules a little in that context, because it’s new 
API.  And there is the goal to have mostly declarative API: setting 

Re: [Interest] Qt Bluetooth a2dp/hfp

[Shawn Rutledge]

> On 9 Aug 2018, at 07:39, Akın Gümüşkavak  wrote:
> 
> Hello, 
> 
> I'm working with Qt bluetooth to implement a2dp/hfp connection. I have 
> successfully implemented so I can connect to my phone. 

Cool!  What platform are you on?
> 
> Now I would like to show my media information which I play from my phone in 
> my Qt application and I would like to control it like play/pause/stop/next vs.
> 
> I couldn't find any examples until now. So if you can show me a way to start 
> or any example, that would be so helpful.

The relevant profile would be AVRCP (Audio Video Remote Control Profile); 
metadata (transferring the “what’s playing” info back to the remote control 
device) was added as an extension to that in the 1.3 revision; and it looks 
like BlueZ on Linux added support for that around 2011:  
http://www.politreco.com/2011/10/11/avrcp-1-3-on-bluez/  But I don’t think the 
work has been done to add it to QtConnectivity yet.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth on Qt on Pi (for real this time)

[Shawn Rutledge]

> On 29 Jun 2018, at 08:27, Tomasz Siekierda  wrote:
> 
> On Thu, 28 Jun 2018 at 22:40, Jason H  wrote:
> I've used bluetoothctl to pair to my mac, but when I try to get local 
> adapters on the Pi from Qt, there are none:
> 
> log:
> Local Adapters:
> ASSERT: "!isEmpty()" in file 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qlist.h, line 294
> 
> 
> code: 
> auto localAdapters = QBluetoothLocalDevice::allDevices();
> qDebug() << "Local Adapters:";
> for (const auto : localAdapters) {
> qDebug() << adapter.address().toString() << adapter.name(); 
> // < }
> 
> bool result = listen(localAdapters.first().address());
> 
> Any ideas on what it takes to get it working on a Pi? When I run it on my 
> mac, it is fine.
> 
> BT on Raspberry Pi is very unstable. I've tried to work with it 6 months ago 
> and actually abandoned the project because it was practically unusable. 
> However, I've noticed they have released a lot of software and firmware 
> updates since then. So my first suggestion: upgrade Raspbian (if you are 
> using it) to newest version.

Have they updated their Qt version yet?  Last time I tried Bluetooth on the Pi, 
a few months ago, they still had 5.7, which is ridiculous IMO.  I wanted to try 
BLE, so had to recompile Qt on the Pi.  And yeah, BT wasn’t stable either.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Disabling mysql support in build

[Shawn Rutledge]

configure -no-sql-mysql I think

If you think we have a bug, you can report one, of course; but mysql doesn’t 
ship with macOS so I guess it came from brew or some such, so maybe it’s more a 
matter of the Qt build process not finding everything?

> On 19 Jun 2018, at 08:38, Patrick Stinson  wrote:
> 
> Is there any way to prevent qt from building the mysql plugin? I am getting 
> the following compile errors in qt-5.11.0 on macOS-10.13.5.
> 
> Disabling would be ideal because it would solve another problem that the 
> mysql plugin is causing as well.
> 
> Thanks!
> -Patrick
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to determine whether QML item is anchored?

[Shawn Rutledge]

But I wanted to query anchors at runtime once too, a few years ago; I think 
I’ve forgotten why.

> On 6 Apr 2018, at 13:58, Mitch Curtis  wrote:
> 
> https://bugreports.qt.io/browse/QTBUG-66264 is semi-related to this, or at 
> least explains why we can’t really return null if they’re not set.
>  
> Without having more information about your use case, it seems like quite a 
> corner case.
>  
> From: Alexander Ivash [mailto:elder...@gmail.com] 
> Sent: Friday, 6 April 2018 1:41 PM
> To: Mitch Curtis 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] How to determine whether QML item is anchored?
>  
> Thanks, I'm aware of this, but this is a bit different.. Would be great to 
> get ability to compare against something like anchors.defaultLeft or 
> anchors.NoAnchor in future.
>  
> Sent from Mailspring, the best free email app for work
> On Apr 6 2018, at 2:38 pm, Mitch Curtis  wrote:
>  
> I’m not sure if it helps in your situation, but perhaps you could take a look 
> at AnchorChanges:
>  
>  
>  
> http://doc.qt.io/qt-5/qml-qtquick-anchorchanges.html
>  
>  
>  
> When the item is in an “anchored” state:
>  
>  
>  
> states: [
>  
> State {
>  
> name: "anchored"
>  
>
>  
> AnchorChanges {
>  
> target: myRect
>  
> anchors.top: window.top
>  
> anchors.bottom: window.bottom
>  
> }
>  
> PropertyChanges {
>  
> target: myRect
>  
> color: "green"
>  
> }
>  
> },
>  
> State {
>  
> name: "not-anchored"
>  
>
>  
> AnchorChanges {
>  
> target: myRect
>  
> anchors.top: undefined
>  
> anchors.bottom: undefined
>  
> }
>  
>
>  
> PropertyChanges {
>  
> target: myRect
>  
> color: "red"
>  
> }
>  
> }
>  
> ]
>  
>  
>  
> This assumes that you have control over the anchors, though.
>  
>  
>  
> From: Alexander Ivash [mailto:elder...@gmail.com]
> Sent: Friday, 6 April 2018 1:23 PM
> To: Mitch Curtis 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] How to determine whether QML item is anchored?
>  
>  
> Let's say I'm trying to make the logic like this: "If parent component is 
> anchored, make a child green, otherwise make it red"
>  
>  
> Sent from Mailspring, the best free email app for work
> On Apr 6 2018, at 2:20 pm, Mitch Curtis  wrote:
>  
>  
> What are you trying to do?
>  
>  
>  
>  
>  
> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org] On 
> Behalf Of Alexander Ivash
> Sent: Friday, 6 April 2018 11:40 AM
> To: interest@qt-project.org
> Subject: [Interest] How to determine whether QML item is anchored?
>  
>  
>  
> What I'm missing? It seems like even not anchored item has 
> anchors.right/left/top/bottom set, so it is not possible to compare with 
> 'undefined' or something. Of course introducing change handler allows to 
> track moment of anchoring (although still no way to track un-anchoring), but 
> this is a bit ugly and not 'Qt-way'.
>  
>  
>  
> Sent from Mailspring, the best free email app for work
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Shawn Rutledge]

> On 15 Mar 2018, at 15:58, Nikolai Tasev <niko...@nand.bg> wrote:
> 
> On 3/15/2018 4:26 PM, Shawn Rutledge wrote:
>> In the future I think it will make sense to use PDF for vector icons too (in 
>> color, even). (Some frameworks already can do this.) Then instead of an icon 
>> font, you could have one PDF file with all the icons for your app, one icon 
>> per “page”. I hope to eventually support using a PDF file with an ordinary 
>> Image in QML, but we have to add API for selecting the page, and there are 
>> other issues with caching and so on. I had patches to get it mostly working 
>> a couple of years ago, it just wasn’t 100% ready for integration.
> 
> The PDF format specification is even more complex than the SVG one аs it is 
> used also to control printing output. The good PDF RIPs are all proprietary. 
> I had quite a lot difficulties using Ghostscript and Poppler until I switched 
> to  a library with a paid license. So it will be again limited to a subset of 
> the specification and maybe slow.
 
QtPDF is using pdfium.  http://code.qt.io/cgit/qt-labs/qtpdf.git  It is complex 
third-party code (but open source), and the rendering is again done in 
software, but it seems fast enough.  I haven’t tried to compare rendering 
times: the same drawing in SVG vs. PDF.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Shawn Rutledge]

> On 15 Mar 2018, at 14:20, Shantanu Tushar  wrote:
> 
> On 6 March 2018 at 22:15, Xavier Bigand  wrote:
> Hi,
> 
> If your sample picture is relevant I can suggest you to convert it as SVG 
> (vectoring it) or using distance field technique.
> 
> I had this question for a while now - if we can use SVGs for showing 
> application icons (which will then look good with any dimensions / DPI), why 
> is it common to use images instead? There's obviously some benefit to images 
> as people take pains to bundle multiple versions for different DPIs, I wanted 
> to know what they are. Most of the stuff I can find online is always talking 
> about websites and "web apps" which might not all apply to desktop 
> applications.
> 
> I see that Uwe has pointed out a performance issue which can happen because 
> of multiple renderings due to size changes. Is that it? Or are there other 
> reasons behind preferring PNG icons over SVG?

I think it’s mainly that SVG rendering is slow because it’s done in software, 
and also that qtsvg only supports SVG Tiny, so it can’t render everything that 
you can design in Inkscape, for example.  You have keep the SVGs simple and 
avoid features that we don’t support (blurs, gradients, line endings/arrowheads 
and lots more).  If you want full SVG support you can use webkit/webengine, but 
that’s overkill in many applications.

Speaking of distance field: If your icons are monochrome, you might consider 
making a custom icon font for your application.  You can start with something 
like Font Awesome, edit it to include only the icons you need, and add more 
custom-designed icons as necessary.  Then you can render an icon with a Text 
element.  But finding a suitable icon editing program is up to you in that 
case.  I did it with FontForge once a couple of years ago.

In the future I think it will make sense to use PDF for vector icons too (in 
color, even).  (Some frameworks already can do this.)  Then instead of an icon 
font, you could have one PDF file with all the icons for your app, one icon per 
“page”.  I hope to eventually support using a PDF file with an ordinary Image 
in QML, but we have to add API for selecting the page, and there are other 
issues with caching and so on.  I had patches to get it mostly working a couple 
of years ago, it just wasn’t 100% ready for integration.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Shawn Rutledge]

> On 8 Mar 2018, at 07:18, Uwe Rathmann  wrote:
> 
> On Wed, 07 Mar 2018 20:55:03 +0100, Jason H wrote:
> 
>> How is QPicture not appropriate for SVG?
> 
> At the time, when Qt changed its APIs from integers to doubles ( Qt 4 ) 
> QPicture::boundingRect() was forgotten, what makes layouting of scaled 
> pictures too inaccurate.
> 
> Another important detail are non cosmetic pens. You need to know about 
> them as they might grow outside the bounding rectangle.
> 
> Beyond that QPicture stores painter commands in a platform-independent 
> format, what makes it less performant and the file sizes are larger.
> 
> In the end ( not yet implemented ) I want to mmap my precompiled SVGs 
> into memory. Then, copying all precompiled SVGs at boot time into a RAM 
> drive and you have almost zero overhead for IO. 

That sounds interesting.  What format do you want to precompile them to?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Shawn Rutledge]

> On 7 Mar 2018, at 09:08, Uwe Rathmann  wrote:
> 
> On Tue, 06 Mar 2018 16:55:23 +, Nuno Santos wrote:
> 
>> I just had to add it to resources and pass it to the image element.
> 
> Using Image works, but its implementation is far from being optimal in 
> combination with SVGs. For small applications with only few SVGs this 
> might be no problem, but when having many of them it is often a serious 
> performance killer for the startup time.
> 
> In short: the overall strategy of Qt/Quick is to cache as much and as 
> early as possible - in case of the Image/SVG too early:
> 
> it loads and renders the SVG according to its sourceSize as soon as it 
> sees the URL. But in case of scalable graphic formats the sourceSize 
> ( usually the viewBox of the SVG ) does only provide the aspect ratio, 
> but not the size that is needed to be rendered.
> 
> This is usually solved by binding the sourceSize to the size being 
> calculated from the layout code, but ...
> 
> When having a layout system that relies on binding the implicit sizes the 
> geometry of each item changes several times until it reaches its final 
> size - each time re-rendering the SVG.
> 
> ( In fact it gets re-rendered twice each time, because binding a size 
> leads to separate updates of width and height )
> 
> I remember an application, where SVGs have been re-rendered more than 10 
> times before they had their final size. This application had more than 
> 1000 SVGs and - even if only few of them were visible in the beginning 
> the caching strategy of Qt/QQuickImage lead to more than 1 image re-
> rendering operations.
> 
> So I would recommend for every application having many SVGs: never ever 
> use Image and always go with QQuickPaintedItem.

It should also be considered a bug IMO.  Do you know of any reported bugs about 
this?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Shawn Rutledge]

> On 15 Feb 2018, at 12:23, René Hansen  wrote:
> 
> In my opinion Qt, (as a company), is directly responsible for the mess that 
> is Electron and todays scape of the app-world. I worked for Nokia back in 
> 2011, when they were trying to build, and miserably failed, the next-gen 
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick 
> approach on top of Meego was such an improvement in speed and overall 
> resource usage. Being able to natively bridge with ease, while still keeping 
> the door open for Javascript devs. was, and still is the single most killer 
> combo out there.

That phone can still be built, and it’s what I want too.  Ubuntu’s version 
looked promising until they dropped it.  Jolla did their version.  (Now if only 
they could ship their tablet, and refresh the phone hardware, and sell lots of 
them.)  Next puri.sm is up to bat.  Everyone is finding it hard to compete with 
the duopoly though, so far.

> As an engineer, being witness to the rise of Electron based apps, has left me 
> completely baffled so many times. How could Qt have such a major head start 
> and still fail to position themselves, as the de facto cross platform 
> development framework. I mean, they even *had* Javascript, fer crying out 
> loud! I've never been able to come up with a good reason for this. I've 
> resorted to thinking that, either, A, Qt didn't *want* to be dominant in that 
> space, and has spent efforts expanding in other markets or B, they've had one 
> of the worst marketing divisions in modern tech history.

OK, from your perspective are there a few small, achievable features we are 
still missing?  Or mostly just marketing focus?

> Imo building native apps completely on top of a web-runtime, will *never* be 
> a good idea. I don't care how much Javascript developers, are a dime a dozen, 
> it's just plain bad engineering and I weep a salty tear, when I see something 
> like Atom take a good 6 seconds to launch on my 2015 MacBook Pro, while 
> eating away 359MB of memory, before even opening the first file. (I'm not an 
> Atom user, this is just an example)
> 
> How can that be acceptable, in, any, way?

IMO it isn’t acceptable, and so far it’s still possible to pretend those apps 
don’t exist.  I hope that continues.

> I know, QtQuick does ship a web-runtime in order to execute JS, but go and 
> try to open the "texteditor" example from QtCreator. It flies open even in 
> Debug mode, and consumes about 24MB on launch. It is an entirely different 
> beast!
> 
> How on earth could Qt drop the ball so hard on this one…

OK so maybe you are kindof focused on text editors or apps that contain editors 
along with other stuff?

I think maybe a fancier editor (like Creator’s) should be available as a 
reusable component: as easy as importing it and using it in any QML app.  But 
management probably doesn’t expect us to make a lot more money by getting us 
ready for the 1980’s like that (even though text editing is still just as 
relevant as it was then).

> Every single time I have to run an Electron, or 
> insert-name-of-other-js-based-app, I get that sour grape taste in my mouth, 
> because it didn't have to come to this. I really do blame Qt.

Well the idea that the browser could be used to build applications goes way 
back… Active Desktop is about the earliest attempt I can remember.  I think the 
web needs re-architecting too, so having one efficient platform for 
applications regardless whether they are online or locally hosted is not 
impossible… but we’re too dependent on the existing web.  Incremental 
improvements are easier, but won't make it more elegant as long as every layer 
must remain, for backwards compatibility.  As long as the current web 
architecture continues, the temptation to make apps portable via browser-based 
UIs will continue.

You could also blame Java for not becoming the eternal universal platform.  In 
one way, that game was over way before Qt Quick got started.  And yet it lives 
on in Android, despite taking so long to get there, and no longer being “cool” 
by then.

(disclaimer: opinions are my own)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] simulating pinch

[Shawn Rutledge]

On Jan 9, 2018, at 18:21, Christopher Probst 
> wrote:

Hello,

I am trying to use the QML test framework to simulate a pinch. The API which is 
here

http://doc.qt.io/qt-5/qml-qttest-testcase.html

does not provide any methods to simulate a pinch. This seems like an oversight.

There is code that shows how to do this here:

http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/quick/qquickpincharea/tst_qquickpincharea.cpp

A pinch is a touch event with two touch points.  You can see how 
QTest::touchEvent is started on line 222 for example, on line 234 it moves both 
touch points simultaneously, etc.  So that’s an example of how to write a pinch 
test in C++ (which I recommend, if you can: mainly because the C++ debugger is 
nicer to use than the QML one, IMO, and tests always seem to end up needing 
debugging at some point).

If you want to write the test in QML, see 
http://doc.qt.io/qt-5/qml-qttest-testcase.html#touchEvent-method and 
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qmltest/events/tst_touch.qml#n146

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is there a QML way for doing web requests? Just for data, not for rendering.

[Shawn Rutledge]

On 22 Dec 2017, at 23:19, Mark Gaiser  wrote:
> 
> Hi,
> 
> You know those fancy REST api's out there.
> How does one use them in QML?
> 
> For websockets the answer is simple: QML WebSocket.
> But i didn't find a way to just do a web request to some url and get it's 
> data, at least not a way that seems "QMLified".
> 
> Sure, javascript can be used with it's XMLHttpRequest which will work just 
> fine, but using it seems so.. not QML like. So is there a QML way to do such 
> things?

Not AFAIK, except for anything (like Image) which has a source URL.

Why don’t you like XMLHttpRequest?  How would you want the QML API to look 
then? Do you expect to do some data processing in JS after you fetch the data, 
or just looking for a way to pass the data to some C++ code?  If the latter, 
why not do the loading in C++ too?

(at least some of those are rhetorical questions… ;-)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QT QFontMetrics boundingRect failed to textwordwrap, thanks!

[Shawn Rutledge]

> On 28 Nov 2017, at 02:06, sq  wrote:
> 
> painter.drawText(textBoundingRect,Qt::TextWordWrap,text);

Try Qt::TextWrapAnywhere.  Those numbers get concatenated into one long “word”.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] minimum macOS runtime version for Qt 5.9+

[Shawn Rutledge]

> On 29 Nov 2017, at 04:46, Jake Petroules  wrote:
> 
>> http://doc-snapshots.qt.io/qt5-5.10/supported-platforms.html suggests that 
>> 5.10 will increase this requirement further to 10.11+. Why is this?
> 
> We decided it wasn't worth the resources to continue testing with 10.10. 
> macOS upgrades are now free and the overwhelming majority of users are on the 
> latest version.
> 
> Why do you need to support older versions?

Because of perfectly good hardware that Apple has decided is now too old to 
upgrade the OS any further.  Or because of a perception that newer OSes have 
more bugs, or are slower, or the UI design isn’t as nice…  people have their 
reasons, just like there are still die-hard 10.6 users out there.

I see the other side of it too: when supporting old APIs makes Qt code ugly and 
hard to maintain, or when the Xcode version has a compiler that is not meeting 
our needs, that plus obsolescence together are good reasons to upgrade the 
minimum requirement.  But I think we should be sure how much better we are 
making it, not just assume it’s normal that the latest Qt only builds on the 
latest macOS versions.

I now have two dual-Xeon MacPro’s at work (different ages) which are powerful 
enough for development but can’t be upgraded any further, therefore can’t get 
the latest Xcode, and so on.  (One at least has 10.12, so this problem will 
arise later when 10.13 is the minimum requirement.)  And I see this as a 
symptom of the planned-obsolescence treadmill, nothing more.  Apple wants to 
sell hardware, we help them do it (but they don’t pay us to), our company has 
to keep paying for new hardware, our customers have to do the same, and the 
older machines pile up because they are too beautiful and work too well to 
throw out.  I really don’t see anything fundamentally good about that, unless 
it helps us improve our code enough to be worth it.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Packet arrival-time resolution? QUdpSocket

[Shawn Rutledge]

On 27 Nov 2017, at 16:45, Konrad Rosenbaum  wrote:
> 
> Yes, the NTP people have done this. Extensively over several decades.
> Please defer to their expertise and use NTP for time sync. ;-)
> 
> Using TCP for this purpose is really a bad idea too - because of the built
> in delays and repeat intervals.
> 
> As for estimates of accuracy:
> 
> If you are not a real-time process you can rely on 100ms accuracy 99% of
> the time if the system load is low; anything below 10ms is simply noise.

NTP works fine for most purposes.  But you can get the clocks synced to a 
higher accuracy with PTP: https://en.wikipedia.org/wiki/Precision_Time_Protocol 
 It can be worthwhile for a sensor network with multiple controller CPUs, where 
you want to make sure all the sensor readings have really accurate timestamps, 
so that they mesh together into a single timeline.  In such a case you might 
want to use PTP to sync them all to an accurate master clock (such as from a 
GPS receiver).

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt iOS - HowTo get access to Images stored at device

[Shawn Rutledge]

> On 26 Oct 2017, at 17:02, ekke <e...@ekkes-corner.org> wrote:
> 
> Am 26.10.17 um 16:11 schrieb Shawn Rutledge:
>>> On 26 Oct 2017, at 15:12, ekke <e...@ekkes-corner.org>
>>>  wrote:
>>> 
>>> Jeffrey,
>>> 
>>> thx
>>> 
>>> at the moment it's ok for me to use 
>>> QStandardPaths::standardLocations(QStandardPaths::PicturesLocation).last()
>>> 
>>> Using Objective-C++ Photos framework would give some more comfort,
>>> but wouldn't help to access these Photos from QML
>>> 
>> >From QML, the QtQuick.Dialogs FileDialog has special support for getting a 
>> >native photo picker:
>> 
>> 
>> http://doc.qt.io/qt-5/qml-qtquick-dialogs-filedialog.html#folder-prop
> if I understood it right, to use FileDialog I must add 
> QT += widgets
> also https://doc.qt.io/qt-5/qml-qt-labs-platform-filedialog.html needs 
> widgets and QApplication instead of QGuiApplication.

That’s not necessary on iOS AFAIK.  Widget-based dialogs are an option on 
desktop systems.  The priority is: native dialog if possible (and on iOS, if 
you are choosing a picture, we treat the photo picker as a native dialog); if 
not, then use a widget dialog if possible (and if it’s not a QApplication, it’s 
not possible); if not, then fall back to a plain QML implementation 
(DefaultFileDialog.qml).

(Disclaimer: I haven’t tested that on iOS for quite some time.  I hope it still 
works.  ;-)

> want to avoid this because my mobile apps are using QtQuickControls2 only 

The work of porting over to Controls 2 dialogs is not done yet.

>>> it seems that there's no way to construct an URL in QML to access files 
>>> from assets-library
>>> so probably the best way is to write an ImageProvider to access these 
>>> Images from QML
>>> 
>> After you choose the photo, you will get a URL which works AFAIK.
> in forum I read that this URL works from C++ but not from QML

Not sure about that… I guess I need to test it again.  I thought it was 
possible to set an Image.source property to that URL, for example, but we don’t 
have much file-reading support in QML otherwise.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt iOS - HowTo get access to Images stored at device

[Shawn Rutledge]

> On 26 Oct 2017, at 15:12, ekke  wrote:
> 
> Jeffrey,
> 
> thx
> 
> at the moment it's ok for me to use 
> QStandardPaths::standardLocations(QStandardPaths::PicturesLocation).last()
> 
> Using Objective-C++ Photos framework would give some more comfort,
> but wouldn't help to access these Photos from QML

>From QML, the QtQuick.Dialogs FileDialog has special support for getting a 
>native photo picker:

http://doc.qt.io/qt-5/qml-qtquick-dialogs-filedialog.html#folder-prop

> it seems that there's no way to construct an URL in QML to access files from 
> assets-library
> so probably the best way is to write an ImageProvider to access these Images 
> from QML

After you choose the photo, you will get a URL which works AFAIK.

The code is in 
qtbase/src/plugins/platforms/ios/optional/nsphotolibrarysupport/qiosfileengineassetslibrary.mm
 (called from qiosfiledialog.mm)

> Am 26.10.17 um 14:52 schrieb Jeffrey Brendecke:
>> 
>>> On 26. Oct 2017, at 13:10, interest-requ...@qt-project.org wrote:
>>> 
>>> ...
>> 
>> Hello Ekke,
>> 
>> It looks like the Asset Library Framework has been deprecated as of iOS 9:
>> 
>> https://developer.apple.com/documentation/photos/phasset?language=objc
>> 
>> The new way to access the assets is through the Photos framework. The above 
>> link contains links to the relevant classes. The Photos framework is feature 
>> rich and allows you to access images separate from their adjustment data or 
>> with the adjustments applied.

If you think Qt is using the deprecated API, and needs to be updated, you can 
write up a bug about it.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Improve Sharpness of Qml Text Item text rendering

[Shawn Rutledge]

> On 25 Oct 2017, at 11:54, Nuno Santos  wrote:
> 
> Shawn,
> 
> Thanks for your reply.
> 
> It actually got worst with this setting.

In what way?

The downside of native text is that it’s a bit less efficient, and is rendered 
exactly at the declared font size, so transforms such as scaling and rotation 
look terrible.  We don’t use it by default because QtQuick is for fluid 
applications, but static text looks “more native” with NativeRendering.

Here’s a little torture-test you can try (with the qml runtime):

import QtQuick 2.0
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.1

Rectangle {
width: 900
height: 480

GridLayout {
width: parent.width
columns: 3
flow: GridLayout.TopToBottom

Repeater {
model: 10
Text {
text: "default rendering"
font.pixelSize: sizeSlider.value * (index + 1)
transformOrigin: Item.TopLeft
scale: scaleSlider.value
rotation: rotationSlider.value
}
}

Repeater {
id: nrRepeater
model: 10
Text {
renderType: Text.NativeRendering
text: "native rendering"
font.pixelSize: sizeSlider.value * (index + 1)
Layout.column: 1
Layout.row: index
transformOrigin: Item.TopLeft
scale: scaleSlider.value
rotation: rotationSlider.value
}
}

Repeater {
model: 10
Canvas {
width: 300
height: fontSize
property real fontSize: sizeSlider.value * (index + 1)
onPaint: {
var ctx = getContext("2d");
ctx.clearRect(0, 0, width, height);
ctx.fillStyle = Qt.rgba(0, 0, 0, 1);
ctx.font = fontSize + 'px Helvetica';
ctx.textBaseline = 'top';
console.log("painting " + index + " , height " + height + " 
font " + ctx.font + " based on " + sizeSlider.value)
ctx.fillText('canvas rendering', 0, 0);
}
Layout.column: 2
Layout.row: index
transformOrigin: Item.TopLeft
scale: scaleSlider.value
rotation: rotationSlider.value
}
}
SequentialAnimation on y {
id: jumper
running: cbAnimate.checked
loops: Animation.Infinite
NumberAnimation { from: 0; to: amplitudeSlider.value }
NumberAnimation { to: 0; from: amplitudeSlider.value }
}
}

Column {
anchors.bottom: parent.bottom
Row {
spacing: 6
Text { text: "Pixel size"; anchors.verticalCenter: 
parent.verticalCenter }
Slider { id: sizeSlider; from: 2; to: 5 }
CheckBox { id: cbAnimate; text: "Jumpy"; checked: true }
Slider { id: amplitudeSlider; from: 1; to: 10; value: 1; 
onValueChanged: jumper.restart() }
}
Row {
spacing: 6
Text { text: "Scale"; anchors.verticalCenter: parent.verticalCenter 
}
Slider { id: scaleSlider; from: 0.5; to: 2; value: 1 }
Text { text: "Rotation"; anchors.verticalCenter: 
parent.verticalCenter }
Slider { id: rotationSlider; from: -10; to: 10; value: 0 }
Button { text: "Reset"; onClicked: { scaleSlider.value = 1; 
rotationSlider.value = 0 } }
}
}
}

> So I assume there aren’t any other alternatives.

There’s some work in progress toward rendering with contours eventually: 
https://bugreports.qt.io/browse/QTBUG-61933 but that’s intended for larger text 
sizes.

You could try using QPainter (make a custom C++ Item which renders words to 
textures and then creates QSGImageNodes for them), but I think that would look 
about the same as native text.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Improve Sharpness of Qml Text Item text rendering

[Shawn Rutledge]

> On 25 Oct 2017, at 10:08, Nuno Santos  wrote:
> 
> Hi,
> 
> Which variables affect the sharpness of the Qml Text item rendering? 

renderType: Text.NativeRendering

This comes up quite often.  Distance field text rendering will always be a bit 
blurry like that.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qml MessageDialog not centered over window

[Shawn Rutledge]

> On 25 Sep 2017, at 13:17, Murphy, Sean  wrote:
> 
> And in my real main.cpp I have
>  QApplication app(argc, argv);
>  QQmlEngine engine;
>  QQmlComponent component(, QUrl("qrc:/qml/dashboard.qml"));
>  component.create();
> Whereas the project that was generated by Creator when I was testing your 
> example is
>  QGuiApplication app(argc, argv);
>  QQmlApplicationEngine engine;
>  engine.load(QUrl(QStringLiteral("qrc:/main.qml")));

Aha, it happens when using a QApplication; the MessageDialog is actually a 
QMessageBox in that case.  I can get the same result with the test qml like 
this:

qml -apptype widget messagedialog.qml

(that makes the qml runtime use a QApplication instead of QGuiApplication) and 
maybe we have some trouble making a QWidget dialog transient for a QWindow.  In 
 QMessageBoxHelper::show(), it does try to set its transient parent:

 virtual bool show(Qt::WindowFlags f, Qt::WindowModality m, QWindow 
*parent) {
m_dialog.winId();
QWindow *window = m_dialog.windowHandle();
Q_ASSERT(window);
window->setTransientParent(parent); 
 qDebug() << window << "transient for" << parent;
… }

QMessageBoxHelper::show - QWidgetWindow(0x7fcf52d80a40, 
name="QMessageBoxClassWindow") transient for QQuickWindowQmlImpl(0x7fcf54a192c0)

I wrote it up as QTBUG-63406.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] propagateComposedEvents-like behavior with qt controls 2 components (no C++)

[Shawn Rutledge]

> On 25 Sep 2017, at 09:28, Daniel d'Andrada  wrote:
> 
> Hi All,
> 
> I wanna have the following (A):
> 
> Foo {
>Button {}
> }
> 
> or (B):
> 
> Item {
>Button {}
>Foo {}
> }
> 
> Where "Foo" is an item that is interested only in drag gestures. So when
> one is performed it does its thing. It ignores clicks, letting them go
> to the Button element inside/behind it.

> So A is a QQuickItem::filtersChildMouseEvents way of doing things (like
> Flickable), whereas B is a MouseArea::propagateComposedEvents approach.
> 
> B is not an option as QtQuick.Controls2 are not MouseArea based, so it
> just won't work.

So you just want a draggable Button, right?

If Foo is MouseArea, it must grab the press in order to get updates at all.  If 
it does not grab, then Button grabs.  It can work if MouseArea is a filtering 
parent, as documented for MouseArea’s drag.filterChildren property:

import QtQuick 2.0
import QtQuick.Controls 2.2

Item {
width: 200; height: 200
MouseArea {
width: button.width; height: button.height
drag.target: button
drag.filterChildren: true
Button {
id: button
text: "Drag me"
onClicked: console.log("clicked")
}
}
}

although ATM I’m seeing a bug that it only works once.  The documented way, 
having a wrapper item so that you can set drag.target: parent, works better:

import QtQuick 2.0
import QtQuick.Controls 2.2

Item {
width: 200; height: 200
Item {
width: button.width; height: button.height
MouseArea {
anchors.fill: parent
drag.target: parent
drag.filterChildren: true
Button {
id: button
text: "Drag me"
onClicked: console.log("clicked")
}
}
}
}

> To implement Foo as in option A I would have to resort to C++. But I
> would like a pure-QML solution for this. Is it possible?

A nicer way: theoretically you ought to be able to do

import QtQuick 2.0
import QtQuick.Controls 2.2
import Qt.labs.handlers 1.0

Item {
Button {
DragHandler { }
}
}

on 5.10 branch; but ATM if you do that, you can drag the button, but you can’t 
click it.

IMO we need to make that work in 5.10.  But we still have some trouble with 
grab conflict: the DragHandler gets a passive grab on press, which is fine, and 
is intended to mean that it will get the updates without preventing the Button 
from grabbing; but it also accepts the press event, and therefore Button 
doesn’t see it.  If we make it so that Button does see the press (keep 
delivering even though the event was already accepted), then Button does an 
exclusive grab, and then DragHandler doesn’t get the updates when you start 
dragging.  So I’ve been trying to sell the idea for several months that events 
need to be delivered to passive grabbers regardless of the exclusive grab.  The 
patches languish because people aren’t convinced yet that it’s the right 
approach.

The alternative I can see is for the DragHandler not to accept the event, so 
that it keeps propagating.

QTBUG-63395 to keep track of that.

I hope we get it fixed soon one way or another.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qml MessageDialog not centered over window

[Shawn Rutledge]

> On 24 Sep 2017, at 02:00, Murphy, Sean  wrote:
> The documentation states that " A MessageDialog window is automatically 
> transient for its parent window. So whether you declare the dialog inside an 
> Item or inside a Window, the dialog will appear centered over the window 
> containing the item, or over the Window that you declared.”

Yes, it should be automatically transient for its parent.  For me it works on 
Linux and macOS.  So I wonder if we have a bug about this transient-parenting 
in general on Windows.  Have you tried any older Qt versions?

import QtQuick 2.6
import QtQuick.Window 2.1
import QtQuick.Dialogs 1.2

Window {
visible: true
MessageDialog {
id: errorDialog
objectName: "errorDialog"
title: "Error"
text: ""
modality: Qt.NonModal // optional, to make it a separate window on macOS
}
Item {
id: functionItem
objectName: "item"

function receivedError(text) {
console.log("Error received: " + text);
errorDialog.text = "Error, " + text;
errorDialog.open();
}
}
Timer {
interval: 5000; running: true
onTriggered: functionItem.receivedError("timer fired")
}
}

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Eclipse plug-in status - QtCreator on KDE Neon

[Shawn Rutledge]

> On 16 May 2017, at 02:19, Roland Hughes  wrote:
> 
> Granted, it sounds like this person did things in the wrong order, installing 
> Qt last, but, creator is broken

Really, on a distro that’s trying to use Qt for everything?  Well, I installed 
it on a spare partition recently (mainly to check out the new global-menu 
feature), checking...

$ sudo apt-get install qtcreator
...
The following packages have unmet dependencies:
 qtcreator : Depends: qtbase-abi-5-5-1
 Depends: qtdeclarative-abi-5-5-0
 Recommends: qmlscene
 Recommends: qt5-qmake
 Recommends: qtbase5-dev-tools
 Recommends: qtcreator-doc but it is not going to be installed
 Recommends: qtdeclarative5-dev-tools
 Recommends: qtxmlpatterns5-dev-tools

Wow, how embarrassing.  Why are they stuck with 5.5-something?

https://forum.kde.org/viewtopic.php?f=309=136886

Well, at least you can download and install the Qt SDK.  I tried; it runs.  
Somebody suggested that there too.

> so Eclipse is next best option. No, KDevelop does things completely different 
> from Qt

What does that mean?

> so not an option...unless they've completely up-ended how they do things via 
> KDevelop now. If Eclipse plug-in officially dead

I wasn’t really aware of it before… don’t think I ever tried it.

>  I'm told the library issue is an actual problem

Why?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.7 QuickControls 2 are not multitouch??

[Shawn Rutledge]

> On 1 May 2017, at 08:24, J-P Nurmi  wrote:
> 
> PS. Unlike for QWidgets and QGraphicsItems, there is no need to explicitly 
> enable touch events for QQuickItems.

That has been the case, but I want to change it (adding 
acceptTouchEvents/setAcceptTouchEvents) to make it more consistent, to enable 
some optimizations, and make it easier to keep the autotests passing.  I’m 
hoping that the applications which use touch events directly are rare enough 
that it won’t be a burden for anyone.

https://codereview.qt-project.org/#/c/190757/

(that’s on a branch which isn’t merged to dev branch yet, so probably 5.10 
material)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Shawn Rutledge]

> On 20 Apr 2017, at 11:31, Alexandru Croitor  wrote:
> 
> So I found out about this recently as well, but touch events are not sent to 
> QQuickItems on macOS by default, because QNativeGestures are sent instead, 
> due to receiving high-precision gestures from the OS itself.
> 
> To receive touch events you need to use private API at the moment. Have a 
> look at the implementation of
> void QQuickMultiPointTouchArea::setTouchEventsEnabled(bool enable)
> 
> You would need to get the relevant function pointer and call 
> registerTouchWindow on your custom QQuickItem.

Right, that’s because of an unfortunate OS limitation that you can either get 
touchpoints from the trackpad, or gesture events (pinches, swipes, etc.), but 
not both.  A trackpad isn’t a touchscreen.  The first finger which you lightly 
put down on the surface moves the virtual mouse cursor, and generates only 
mouse move events.  The second finger doesn’t generate a touchpoint, because 
the OS is trying to detect 2-finger gestures (there are so many, and it’s not 
practical to disable that).  When you do the 2-finger flick, you normally get 
QWheelEvents in Qt, and those can drive the Flickable, so that it has a fairly 
native feel, like flicking text in Mail or Safari or whatever.  But because 
MultiPointTouchArea enables touch events via that private API, that disables 
the gesture detection just for that one NSView (which is normally the window 
containing the whole QtQuick scene), and that means you can get the touchpoints 
when you place 2 or more fingers on the trackpad.  It's not a direct touch 
device, so you know where the first point is (it’s the cursor), and the 
remaining ones will be nearby, based on how far away they are on the trackpad.  
But you will have trouble trying to tap on something onscreen with the second 
or third finger, say, because there is no visual feedback about where that 
finger is onscreen until you put down the finger - and then the feedback is up 
to the application.  And if you have some 3-finger OS gestures enabled in 
Preferences, those will occur simultaneously when you have 3 fingers in play, 
and interfere with what you are trying to do in the MPTA.

With all those limitations, MPTA isn’t actually that useful (except to just 
visualize the finger positions for a demo), and most likely you’re not going to 
have a great experience with a custom Item either (if you enable touchpoints 
via the private API, and thus disable gestures, that applies to the whole 
scene).  We prefer to have the OS-generated gesture events by default, because 
they enable smoother interaction with a native feel.  PinchArea works great 
with gesture events, and it doesn’t even have to do as much calculation, 
because the pinch event tells it exactly what to do: how much to zoom and how 
much to rotate.  (It may be that later on we will prefer native gesture events 
whenever possible on other platforms, but we were practically forced to do it 
on macOS.)

What I wish Apple would have done instead is send tentative touchpoints right 
away, then recall them whenever a gesture is detected, and let you either veto 
the recall to keep getting touchpoints, or accept the recall to switch over to 
gesture events for the duration of the gesture.  Then we could have quality 
data either way; it would be more flexible, but more complex.  If done right, 
an API like that could maybe even be portable between iOS and macOS.  But the 
trackpad evolved as more of a mouse-with-gestures than a touch device.  
Touchpad drivers on other platforms tend to be that way too, for that matter, 
with some exceptions.

On iOS the native APIs are different; you’ve got a real touchscreen after all.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Q_GADGET vs Q_OBJECT

[Shawn Rutledge]

You got an answer on StackOverflow already, but to repeat: he’s right, a 
QObject is always passed from C++ to QML by pointer, and a Q_GADGET is always 
passed by value.  That means Q_GADGET is only suitable for smallish 
self-contained classes, because it will always be copied.

> On 13 Apr 2017, at 20:31, Russell, Matthew  wrote:
> 
> Why can my Q_GADGET be read perfectly in QML (JS) but not my Q_OBJECT?
>  
> I created a class, registered it (Q_DECLARE_METATYPE), and then push 
> instances of it into a QVariantMap.  If the object is a Q_GADGET my JS can 
> read it perfectly, but when I switch it to a Q_OBJECT, the objects are blank.
>  
> I placed some code examples on SO here: 
> http://stackoverflow.com/questions/43398740/qml-can-see-my-q-gadget-but-not-q-object
>  
> Basically I’ve narrowed it down to Q_GADGET vs Q_OBJECT, nothing else seems 
> to make any difference.  I’d prefer to use Q_OBJECT so that I can use signals 
> and other objects in the QML/JS can bind to them.
>  
> Thanks.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] macOs maximize button in Qt Quick 2 application

[Shawn Rutledge]

You need Window { flags: Qt.Window | Qt.WindowFullscreenButtonHint; … }

Have a look at the qtdeclarative/examples/quick/window, which additionally 
demonstrates how to control window states (visibility) programmatically.

But it’s a good question whether it’s a bug that that behavior is not the 
default on newer versions of macOS though.  Are you sure whether developers 
need to enable the feature somehow in native applications too?

> On 10 Apr 2017, at 00:14, Alexandre Ribeiro  
> wrote:
> 
> Hi,
> 
> In macOs Sierra clicking on a window's maximize button makes it fullscreen by 
> default. If a user presses Alt, hovering over the maximize button transforms 
> it to a "normal" maximize button.
> 
> I've just compiled a Qt Quick 2 application under Qt Creator (Qt 5.8) and I'm 
> not seeing this behaviour. All I'm seeing is the "normal" maximize, with no 
> full screen support.
> 
> How can I add the fullscreen native support?
> 
> Cheers,
> Alex
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] context menu shortcut?

[Shawn Rutledge]

> On 16 Jan 2017, at 20:51, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I presume that Qt opens the currently defined/available context menu in 
> reaction to pressing the corresponding key on MS Windows and possibly on 
> Linux too.
> 
> Is there a way to assign a shortcut to this action on Mac too (and on Linux, 
> if not already the case)?

It’s not in QKeySequence::StandardKey.  There is a table in the QKeySequence 
docs which shows the standard key assignments on each platform.

Personally I don’t miss that on Linux… it’s just an extra key available for 
some other purpose (I’ve used it as a compose key sometimes, for example).

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Needed working stop/start for animated SVG

[Shawn Rutledge]

> On 11 Jan 2017, at 13:43, Serge K via Interest  
> wrote:
> 
> I am not sure about patch. I'm going distribute my product using Ministro to 
> reduce space used by Qt libraries. There will be several "parts" of this 
> product distributed separately. But they will use same Qt libs set. Without 
> Ministro each part will have copy of all used Qt libs. But with Ministro 
> parts will share one set of libs. Qt libs will be downloaded by Ministro from 
> Qt repository. Therefore I cannot be sure if patch will be applied before I 
> start distribution. That means I should wait for it. No. I cannot be limited 
> by this.

That’s a very typical problem almost everyone runs into… you need a workaround 
for now, but it would still be nice to get it fixed in Qt eventually, even if 
it takes a year, right?  Then eventually you won’t need your workaround 
anymore, when Ministro gets updated to the Qt version which has the fix.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Needed working stop/start for animated SVG

[Shawn Rutledge]

> On 10 Jan 2017, at 20:14, Serge K via Interest  
> wrote:
> 
> 
> May be - then this is a bug in Qt for Android. Right now I found another bug 
> - QSound::play() in Android stops playing WAV after several times if playing 
> fast.

You can write them both up at bugreports.qt.io.  Be sure to provide an example. 
 SVG animation is pretty rarely used AFAIK… I don’t remember hearing of anybody 
using it before, so it’s not surprising if there are bugs.  You can also write 
a patch if you know what to do about it, and submit it to 
codereview.qt-project.org

> Вторник, 10 января 2017, 21:56 +03:00 от "Jason H" :
> 
> Well android wasn't around in 4.1 days... it seems the Android drawable 
> system is running the animation, not Qt. 
>  
> Sent: Tuesday, January 10, 2017 at 12:55 PM
> From: "Serge K via Interest" 
> To: interest 
> Subject: Re: [Interest] Needed working stop/start for animated SVG
> 
> SVG animation appeared first in Qt 4.1. I used it in Qt 5.
> 
> Just needed stop and start timer with two methods. WHY THIS WAS NOT DONE 
> BEFORE??? IN FIRST 4.1 RELEASE? :-(((
>  
> Вторник, 10 января 2017, 20:41 +03:00 от Konstantin Tokarev 
> :
>  
> 
> 
> 10.01.2017, 20:37, "Serge K via Interest" :
> > I created widget with animated SVG for my projects. It starts after loading 
> > if signal svg->repaintNeeded() is connected to update() of my widget. To 
> > stop and restart it I found a hack - disconnect this signal and reload SVG 
> > image. In Windows and Linux this stops animation. Stupid but working. But 
> > now I use this widget for project on Andriod (using QML is not the way, QML 
> > is too weak and lame for me). But I cannot stop SVG animation on Android. 
> > It runs always. It does not depend from any connections, framerate, 
> > reloading, so on. Of course I can use another hack - to stop animation I 
> > can load non-animated image and to start I can load animated again.
> >
> > BUT... This looks too much "micro$oftish" and stupid. NOT A Qt WAY. And 
> > with this hack animation won't stop in it's "current" position - it will 
> > always start from beginning. I do not need this.
> >
> > Of course I could patch Qt code and rewrite QSvgRenderer class. I could add 
> > start() and stop() functions to control internal d->timer - it emits ticks 
> > for animation frames. BUT WHY THIS WAS NOT DONE BEFORE??? :-(((
> 
> Because you haven't done it
> 
> >
> > --
> > Serge K ,
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> --
> Regards,
> Konstantin
> 
> ___ Interest mailing list 
> Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] SVG2 Mesh Gradient - will be implemented? When?

[Shawn Rutledge]

> On 9 Jan 2017, at 16:04, Serge K via Interest  wrote:
> 
> This feature existed in Inkscape for long time before but was "hidden" 
> (possible open by editing some config files). In latest version of Inkscape 
> 0.92 this very useful feature appeared as open. And it existed in Adobe 
> Illustrator for years. This is a standard svg2 feature allowing create 
> "conical" gradients in single closed objects. Even it allows create curved 
> gradients. This helps draw many 3D-like looking objects, natural looking dial 
> knobs and so on. But current QSvgRenderer does not support this feature. I 
> just tested - it draws nothing if Mesh gradient is used. So... Are there 
> plans for this feature in QSvgRenderer? Does anybody work on it?

No, nobody is working on QtSvg, unfortunately.  SVG Tiny is supported, and lots 
of other cool stuff is omitted.

If you want a real up-to-date SVG renderer you’ll have to look elsewhere… 
webengine for example.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 16:19, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Tuesday January 3 2017 13:57:51 Shawn Rutledge wrote:
> 
>>> As to remote use: I thought that wasn't the point of Wayland at all?
>> 
>> They keep saying to go on using X11 or VNC or whatever existing solution you 
>> like. 
> 
> They could implement their own VNC compositor then ;)

If nobody has done that yet, it’s quite predictable that someone will pretty 
soon.  (googles) ok maybe https://github.com/RealVNC/wayland-developer-preview 
but I haven’t tried it...

>> Personally I think a good eventual solution would be to leverage the 
>> application server's GPU (the client machine in X terminology) both for 
>> rendering and for compression, and send compressed frames (or frame diffs) 
>> over the network, using some compression technique which both runs well on 
>> the GPU and is as close to lossless as possible.  But it won’t scale to lots 
>> of users either, if the GPU usage ends up being too high.
> 
> That sounds reasonable. It bit far from the original topic, but who cares :)
> As to GPU usage: one important and vocal class of users doing remote 
> displaying (*with* OpenGL if you please) are scientists who do heavy 
> calculation on big headless clusters. I don't think local GPU usage is an 
> issue for them.

Right, but frame rate and bandwidth and latency do matter.  It’s a different 
use case anyway.  I guess some combination of Wayland + OpenGL could be sent 
across the network in the same way as X11 + GLX can be, but when googling about 
remote Wayland it looks like people seem to think mainly of sending 
pre-rendered frames.  Both could be useful depending on speed and latency of 
the network and availability of the local GPU.

>> Another alternative of course is to use some other client-server protocol 
>> such that only the “model” of MVC is on the server, and UI rendering 
>> instructions are sent across the network instead of actual rendered 
>> graphics.  
> 
> Erm, that's what X11 does traditionally, no?

No, because you can’t send any complete objects from the view layer across to 
the X server.  When you write the view in an OO language you’d probably include 
some imperative code to assemble the widgets and to handle low-level events and 
to fetch and format values from the model - it's more than just the elements 
which are rendered.  X protocol is not programmable.  (OTOH anything that is 
programmable is exploitable, so I guess that’s why X servers aren’t known for 
having security holes left and right like browsers do.)

https://en.wikipedia.org/wiki/X_Window_System says "X also lacks native support 
for user-defined stored procedures on the X server, in the manner of NeWS – 
there is no Turing-complete scripting facility.” Exactly - NeWS was based on 
Postscript, so it was superior in this regard.  (At some point ages ago, I 
tentatively started a little project to recreate something like NeWS, but 
didn’t get very far before I realized I’m not so fond of stack-based languages 
that I want to write a lot of code that way, despite having used Postscript in 
anger on more than one occasion.  ;-)  And nowadays a stack-based language  is 
not the highest-performing VM that you could build upon, if you want to 
translate some other language to it.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 15:07, Ulf Hermann  wrote:
>> Another alternative of course is to use some other client-server protocol 
>> such that only the “model” of MVC is on the server, and UI rendering 
>> instructions are sent across the network instead of actual rendered 
>> graphics.  For example load QML over the network and run it locally.  For 
>> some reason we aren’t putting much emphasis on that as a primary use case 
>> yet, but I wonder if anybody in the field is doing much of that?
> 
> It's called "The Web" and there are many reasons to hate it. However, one 
> thing the relevant people in the field got somewhat right (IMO) is the level 
> of coupling between the "model" and the rest of the application.

It’s just that QML rendering is more efficient than any browser… that’s what we 
keep telling people anyway.  ;-)  So I think we need to focus a bit on 
QML-based web applications at some point.  If you use http to load the QML 
(which we have already been able to do for years) then you’ve got the same 
model / view separation that the web has, and can easily rewrite the 
front-end without changing whatever REST services (preferably) that it depends 
on.  Even since the late 90’s or so, people have been saying that it makes more 
sense to write new applications with HTML rather than widgets; so if we leave 
ourselves out of that, well...

BTW now that https://codereview.qt-project.org/#/c/181098/ is integrated, it so 
happens that you can use the qml runtime as a “browser” for qml files on a web 
server.  As in

qml http://ecloud.org/expt/qtquick/multiparticles.qml

(And that wasn’t even the point of that patch.)  Hmm, seems that it still needs 
work to be able to load dependencies beyond that first qml file though…

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 12:45, René J.V. Bertin  wrote:
> I haven't given that much thought, but yes, I think the idea would be to have 
> a "rootless" Wayland compositor that displays windows alongside native 
> windows, much like Xquartz can do. An important appeal to the XQuartz 
> maintainer I spoke with is that it would make XQuartz obsolete because it 
> could in principle be replaced by XWayland. Done right that should provide a 
> more complete X11 implementation requiring less maintenance effort.
> As to remote use: I thought that wasn't the point of Wayland at all?

No they keep saying it’s not the point (optimizing for that would impose 
limitations).  They keep saying to go on using X11 or VNC or whatever existing 
solution you like.  But then, if Wayland will eventually make X11 obsolete, 
that will be impractical at some point, right?  Besides the fact that 
X11-over-network doesn’t work well with every application anyway.  (The best 
applications for that are old-school: using X resources sparingly and reusing 
them properly, sending text across and asking the X server to render it, and so 
on.  Qt hasn’t been optimized for that in ages.)  Personally I think a good 
eventual solution would be to leverage the application server's GPU (the client 
machine in X terminology) both for rendering and for compression, and send 
compressed frames (or frame diffs) over the network, using some compression 
technique which both runs well on the GPU and is as close to lossless as 
possible.  But it won’t scale to lots of users either, if the GPU usage ends up 
being too high.

Oh well, maybe X11 will realistically be around for another couple of decades 
anyway.

Another alternative of course is to use some other client-server protocol such 
that only the “model” of MVC is on the server, and UI rendering instructions 
are sent across the network instead of actual rendered graphics.  For example 
load QML over the network and run it locally.  For some reason we aren’t 
putting much emphasis on that as a primary use case yet, but I wonder if 
anybody in the field is doing much of that?

> It's still using the adapted KDE platform plugin which makes it possible to 
> map KDE's font roles to different font sizes so applications automatically 
> stop using the same (big!) font size for most of the GUI if they don't 
> explicitly specify smaller font sizes. This is on 10.9, so the system font is 
> Lucida Grande. The platform theme also adds the XDG icon directory to the 
> icon theme search path, and that makes icons appear in the native widget 
> style dialog buttons because the code only checks if the buttons have an icon 
> set or not, and render it if they do. That should probably be corrected one 
> way or another but I'm not yet sure how.
> 
> Shawn, do you think it's worth reporting this on the bug tracker? I would 
> guess that the same happens however you make an icon theme available, be it 
> through an embedded resource or an XDG-style icon directory, no?

Sure, but it will get triaged to a pretty low priority if it only affects this 
unusual setup of yours.  But anyone can write a patch for it anyway, especially 
if the fix is straightforward and doesn’t break anything.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 10:37, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Tuesday January 3 2017 08:55:13 Shawn Rutledge wrote:
>> Are there obstacles to getting it working without the X server?
> 
> I'm not sure I understand what you mean?

Just not sure what you are trying to achieve and why… but you explained more 
below.

> What I'm doing is the apparently really not supported approach: 
> 
> - build Qt5 as normal on Mac (though patched to include the qgenericunix* 
> stuff)
> - build QtBase configured for XCB (and patched so it works); still using a 
> frameworks build
> - install the xcb qpa plugin and its dependencies, as well as the QtX11Extras 
> component
> - start applications with -platform xcb or using the corresponding env. 
> variable.
> 
> This means I do not have any of the X11 specific stuff in the QtBase 
> component except for X11Extras, and dependent code can be built as usual. The 
> QtCurve style for instance is built without any X11 specific code.
> 
> It probably also answers your question:  I don't need to have the X server 
> running to use Qt5 apps, and everything also works as usual on Mac when I do 
> have the X server running. Evidently I get the expected error when I try to 
> use the xcb QPA and the X server is not running, though on a standard XQuartz 
> set-up the X server would probably be started on-demand.

> BTW, I didn't show it, but with this kind of build the Macintosh application 
> style is available also with the xcb QPA. I rarely use it, but it *is* cool :)
> 
> There is only 1 real issue that I've seen until now: some OpenGL applications 
> lock up on exit with an error message about not releasing a GL context. I 
> don't know if that's a real problem though. Remote displaying doesn't always 
> work as expected either because of XQuartz lacking some key functionality in 
> that domain (both incoming and outgoing), but Qt apps aren't that suitable 
> for remote execution anyway. That *was* a bit my motivation to start 
> tinkering with the xcb  QPA, but I've since discovered that it's very nice 
> for local use, too. Esp. being able to run Konsole on all my desktops.

Why doesn’t it run with just the cocoa plugin?

Does middle-mouse-paste end up interoperating between plain X11 and Qt apps 
then?

> As a side-note: I've been discussing Wayland on Mac with one of the XQuartz 
> maintainers. He likes the idea, but there's no one working on it right now, 
> and the Wayland libraries depend on a couple of functions that aren't 
> available on Mac (signalfd(), timerfd()).

Hmm, interesting.  But I guess it makes less sense to composite an overlay 
desktop, as opposed to having application windows which use the Wayland QPA 
plugin simply showing up as regular windows, right?  Especially if it 
eventually ends up providing another way of using applications remotely.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Shawn Rutledge]

> On 2 Jan 2017, at 22:46, René J.V. Bertin  wrote:
> 
> Best wishes for 2017!
> 
> Accompanied by a "postcard" from the realm of the impossible, just because 
> I'm quite auto-satisfied with the result: a KDE's KDevelop 5.3 and Konsole 
> 16.12 running with Qt 5.7.1 and the XCB QPA on Mac OS X 10.9 (and the 
> application style dialog running with the Cocoa QPA). Not officially 
> supported, but with a few minor patches it just works.
> 
> https://trac.macports.org/attachment/wiki/KDEProblems/KF5-Mac.png

Cool!

Are there obstacles to getting it working without the X server?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtDesigner needs redesign.

[Shawn Rutledge]

> On 2 Jan 2017, at 14:15, Thiago Macieira  wrote:
> 
> On segunda-feira, 2 de janeiro de 2017 13:55:43 BRST Serge K via Interest 
> wrote:
>> Is there anybody now creating NEW QtDesigner? Are there at least plans for
>> it? WHEN???!!
> 
> No, no one is working on that, as far as I know.

I used it extensively in previous jobs, and my experience then was that it 
worked well enough to use, and boosts productivity a lot compared to writing 
all the widget-construction code by hand.  It got even better with the Creator 
integration.  If there are some bugs and usability problems, they could be 
fixed, so I don’t see a need for a rewrite of the same functionality.  But the 
Qt Company has not been focused on widget issues for several years now, because 
of QtQuick.  So, the new designer is effectively the QtQuick designer.  But if 
anyone feels like fixing any annoying usability issues in the old designer, 
patches are welcome.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] initialising a dictionary-type container instance with a static table?

[Shawn Rutledge]

> On 2 Jan 2017, at 13:02, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I must be overlooking or even forgetting something: is there a way to 
> initialise a QMap or QHash instance with a static table, say when you're 
> creating a fast lookup dictionary mapping enums or preprocessor tokens to a 
> QString?
> 
> That's information known a compile time so I was expecting to be able to 
> avoid adding each mapping explicitly with a sequence of
> 
> map[token] = "token";
> 
> statements. If that's indeed possible, the documentation doesn't really 
> showcase it.

It has operator<< and operator>> so I guess you could load it from a file.

It’s an interesting point though, if you have a fixed set of data then you 
could use a perfect hash and a perfect number of buckets.  There’s undoubtedly 
some other library which can do that.  I googled and found stuff like 
https://news.ycombinator.com/item?id=10745194 and 
http://stevehanov.ca/blog/index.php?id=119 which have more links to things like 
cmph and gperf.

But for tokenizing, maybe just use lex/flex?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Compiling for Pi Zero

[Shawn Rutledge]

> On 5 Dec 2016, at 14:32, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 05.12.2016, 16:30, "Shawn Rutledge" <shawn.rutle...@qt.io>:
>>>  On 4 Dec 2016, at 18:17, Jason H <jh...@gmx.com> wrote:
>>> 
>>>  I am trying a naive compile of Qt 5.7.0 (from source tarball) on a Pi zero 
>>> (no cross compile) I've got all the dependencies installed and Jessie is up 
>>> to date.
>>>  I keep running into GCC 4.9 compiler errors. Not that the Qt code is bad, 
>>> but that the compiler bombs out saying it's a bug in GCC. Originally I saw 
>>> it in qsvgcontext.cpp, but after updating and trying to fix it, I get it in 
>>> sax/qxml.cpp.
>>> 
>>>  It doesn't give me a lot of idea on what exactly is wrong.
>>> 
>>>  Anyone have any tips?
>> 
>> I wouldn’t be surprised if it runs out of memory, but I guess you would see 
>> something about that in the error message. You could run top in another 
>> shell session and see if it gets close to running out.
> 
> GCC can print something like 
> 
>internal compiler error: Killed (program cc1plus)
> 
> in case of OOM, so it can be confused with real ICE by newbie :)

Yep that’s what I was thinking of… even on my laptop with 4GB and no swap, if I 
run make -j with too high a number, that happens sometimes (but I didn’t have 
the exact error message handy).  And forget about running Creator at the same 
time.

Newer compilers take more memory, and especially the linker.  At some point it 
becomes impractical to compile anything significant on an embedded processor at 
all, just for this reason, even if you don’t mind it taking all day, or even if 
you have a cluster of machines available.  I think the gcc folks should try to 
figure out some kind of workaround: maybe detect that there is not enough 
memory and make the usual speed-memory tradeoff in the other direction (cache 
less and compute more); work on building a distributed linker (if that’s even 
possible?) so that you can use a cluster of little machines; etc.  (But at 
least maybe omitting -O would help.)  Aren’t the Debian folks demanding such 
things, if they continue to build the arm distro on arm-based machines?

But most people will say stop doing that and just cross-compile it.  But then 
we paint ourselves into a corner if that’s the only solution.  My first Linux 
box was a 386 with 5 or 6 megs of RAM (1+4 I think), and it didn’t have any 
trouble building a kernel for itself.  (I don’t think I was building Qt that 
far back, but it was probably small enough to run on that machine.)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Compiling for Pi Zero

[Shawn Rutledge]

> On 4 Dec 2016, at 18:17, Jason H  wrote:
> 
> I am trying a naive compile of Qt 5.7.0 (from source tarball) on a Pi zero 
> (no cross compile) I've got all the dependencies installed and Jessie is up 
> to date.
> I keep running into GCC 4.9 compiler errors. Not that the Qt code is bad, but 
> that the compiler bombs out saying it's a bug in GCC. Originally I saw it in 
> qsvgcontext.cpp, but after updating and trying to fix it, I get it in 
> sax/qxml.cpp.
> 
> It doesn't give me a lot of idea on what exactly is wrong.
> 
> Anyone have any tips?

I wouldn’t be surprised if it runs out of memory, but I guess you would see 
something about that in the error message.  You could run top in another shell 
session and see if it gets close to running out.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [5.8] how to use qml caching?

[Shawn Rutledge]

> On 11 Nov 2016, at 10:53, Tim Blechmann  wrote:
> 
> hi all,
> 
> i've read a lot about qml caching in qt-5.8. however i didn't find any
> documentation on how to use it.
> 
> is there any documentation on how we can use it from a cmake
> buildsystem? i suppose somehow the qrc files need to be pre-processed to
> generate the qmlc/jsc files?

They are created when you run the application.  It’s analogous to Python’s pyc 
files: just a cache of the compiled source file, which will make it load faster 
the second time.  On different OSes there are different storage locations. 

The Qt commercial compiler is different - in that case you do pre-compile.

(Disclaimer: I’m telling what I remember from this session:  
https://conf.qtcon.org/en/qtcon/public/events/430 and I don’t think there is 
video from that one)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Quick Controls 2] Best way to add binding arrow tip to Popup?

[Shawn Rutledge]

> It probably wasn't mentioned because it's got a bad reputation as being slow. 
> It's easy to abuse it and end up with crappy performance. As long as you 
> limit the amount of painting you do and how often you do it, I don't think 
> using it is really an issue in practice.
...
> like Canvas is not the really good solution - just a workaround. That is, it 
> not claims to be "support for arbitrary shapes in QtQuick".

Yes Canvas uses QPainter to render a texture on the CPU, which is then uploaded 
to the GPU.  Besides the drawing commands being in Javascript.

It’s not that bad in practice, just not as efficient as it could be.  You might 
not be able to redraw it at 60FPS.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Shawn Rutledge]

On Sep 20, 2016, at 22:52, Rob Allan  wrote:
> My biggest gripe is that the Qt Quick object model seems to be much more 
> poorly supported in C++ than it is in QML. For example, in C++ you really 
> only have access to QQuickItem - none of its derived classes are documented, 
> and their interfaces are private - so the only way to manipulate items is 
> using a generic "setProperty" syntax. This is in stark contrast to QML where 
> all the QML types, methods and properties are available to you. When you have 
> an app that builds most of its UI dynamically from C++ code (as ours does), 
> this makes life pretty difficult. I guess this is one area where widgets 
> would score better than Qt Quick (but we still prefer Qt Quick for a number 
> of reasons).

It’s intentional though: we don’t have to worry about binary compatibility that 
way, or even source compatibility to an extent - it’s only the QML API that we 
have to keep compatible.  We don’t strictly even need PIMPLs (and I wonder if 
we could get any speedup or memory savings if we didn’t have them), but most of 
the classes have them anyway.  I guess maybe the original authors were 
anticipating that the C++ API might become public some day, so they have 
private objects just in case.  But making more of them public is the same as 
locking the API and reducing flexibility.  If there are any API warts, they 
become difficult to fix after that.  (E.g. the restriction that we can neither 
add nor remove virtual functions is downright crippling sometimes.)

I think that there should be a more extensive C++ interface to the scene graph 
itself.  People complain that QtQuick is bloated: you have to create too many 
QObjects and too many bindings; so what’s the difference if you do it in C++ 
instead of QML?  But the scene graph nodes are fundamental and inescapable - 
hopefully not as bloated either.  (Why must they exist?  Because batching is 
fundamental to get good performance in OpenGL: you use a scene graph because 
you don’t want to make thousands of draw calls to draw the UI each time it 
changes.)  If you don’t like Javascript, there isn’t yet a good way to omit the 
whole engine from your build; but I think there should be, and then it might be 
practical to use the scene graph directly.  But that would be a static scene; 
to make it dynamic and interactive you'd have to re-invent some difficult 
things: event delivery, (most types of) animations, layouts, etc.  If you want 
to bind another language to the scene graph though, and use 
different/functional/more-elegant paradigms for the interactive stuff, it’s not 
a bad place for the boundary, right?

Some people think that making more scene graph stuff public is also not worth 
the trouble, and would tie down existing internal APIs too much.  Especially 
when it comes to text rendering.  But in the meantime you can use private APIs 
when public ones are missing.

If you just want to write custom items which populate scene graph nodes, and 
still use QML in general, it’s already not so bad (as long as your custom items 
don’t include text).  If you want to mix OpenGL and QtQuick in layers, no 
problem.  (Qt3D made sure of that.)  

> I would still rather put up with a rich C++ interface that had breaking 
> changes at new releases, than the relative limited C++ interface we have now.

If you are really OK with that, then use private APIs.  Probably better to 
start with 5.8 since there were big changes from 5.7 to 5.8.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Shawn Rutledge]

> On 18 Sep 2016, at 02:37, Xavier Bigand  wrote:
> 
> I am using Qt for my day job,
> 
> Our first difficulty with Qt is the release cycle that is really long and the 
> difficulty to test the futur versions.
> As we often need the latest features or bug fixes, waiting 3-4 month isn't 
> possible, and some times we just implement our self features or use 
> workaround for bugs.
> Alpha and Beta versions aren't accessible on the Qt maintenance tool that we 
> use, and compiling Qt from the source is to much work for every platforms we 
> use,...
> 
> We'll certainly don't use an Alpha or Beta version of Qt for production, but 
> it is interesting to be able to report bug on upcoming version as soon as 
> possible (especially for new features as Qt3D,...).

Then you should use git.  Yes it’s bleeding edge, but CI helps to make it more 
stable than it otherwise would be.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Shawn Rutledge]

> On 19 Jul 2016, at 16:44, Uwe Rathmann  wrote:
> 
> On Tue, 19 Jul 2016 15:45:44 +0200, Jean-Michaël Celerier wrote:
> 
>> Is there some code somewhere ?
> 
> Sure on my disk ;)
> 
> Being serious: the code is supposed to be available under an Open Source 
> License, but it needs to have an initial level of quality first. And 
> there is still a long way to go.

Working on the Qt Project may have affected your instincts (we have inhibitions 
baked into the process because of long-term API support, we don’t have quite 
the right solution for hosting experimental git repos, and in the past we have 
been afraid to open-source too much), but in actual normal open source 
development I think “release early, release often” is still a good mantra.  If 
it’s just an experiment, it won't need a fixed API just yet, right?

Otherwise someone else who is interested in doing similar things is going to 
either waste time redoing your work, or else feel that it’s better to wait - 
which may also be a waste of time and especially energy.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[Shawn Rutledge]

> On 6 Jul 2016, at 08:34, André Somers  wrote:
> 
> Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:
>> 
>> -Original Message-
>> From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
>> Behalf Of Thiago Macieira
>> Sent: Tuesday, July 5, 2016 5:42 PM
>> To: interest@qt-project.org
>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>> 
>> On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
>>> How does one get Qt widgets to take advantage of a GPU?  If this
>>> question seem naïve, it is because it is.
>>> 
>>> With my application, I am displaying different types of media —
>>> mp4 (using QMedia Player)
>>> Html (folders containing a "mini-site” using QWebView) Images (using a
>>> Qlabel)
>>> 
>>> This Qt 5.5, Windows7/10, running on a low end compute stick.

Hmm, how low-end can it be if it can run Windows?

Why 5.5?  At least 5.6 is LTS, so if you find any bugs, they’d have a chance of 
getting fixed in future 5.6 releases.

>>>  The CPU
>>> seems to take the brunt of the performance.  Just wondering how to
>>> offload some of that?
>> Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
>> Quick instead. Qt Quick uses the GPU, QtWidgets do not.
>> ==
>> 
>> That’s a pretty horrible answer... There are MANY of us, who prefer for all 
>> sorts of reasons, to use C++ as our primary development language.

Yeah we hear that feedback a lot.

>> Is there no outlook for QtWidgets to start using the GPU?
>> 
> No, there is not. Not realisticly. First of all, widgets are "done", so not 
> much development is going on there. But more important is that the way 
> widgets are rendered simply doesn't suit the way modern GPU's work. It is the 
> main reason Quick (2) was created in the first place: render the contents in 
> such a way that it can utilize the GPU the way its meant to be used. That 
> can't be retrofitted to the widgets world.

What that means (from my understanding so far) is that if you try to render 
widgets with OpenGL, you will end up with a lot of draw calls, because widgets 
are rendered individually, in paint order (bottom up).  So there might not be a 
worthwhile speedup.  Whereas OpenGL works better to render a larger number of 
vertices in one draw call, which is why the QtQuick scene graph uses batching 
to group together items which use the same shaders and same uniforms, and which 
aren’t separated by other different items at intervening Z layers.  But it 
doesn’t sound like rendering the widgets themselves is going to be the 
bottleneck in your application anyway, as long as you can prevent the widgets 
themselves from being re-rendered too often.  I.e. no animations, and no widget 
overlays on top of the dynamic content.

Multimedia and web rendering are a different story.  Others are better 
qualified to comment on the details of how WebEngine, QtMultimedia, and the 
older alternatives are implemented - but they are all wrappers around other 
libraries.  Just because widgets don’t render their own pixels on the GPU 
doesn’t mean those libraries can’t render the framed content on the GPU, AFAIK. 
 At least theoretically, but I’m not up-to-date on whether the widget 
implementations are currently doing that efficiently.

> Note that even if you define your GUI in QML, you can still do everything 
> else in C++. The QML doesn't have to be much more than what you already have 
> as .ui files now, and they are not C++ either are they? Difference is of 
> course that they get compiled into C++, where QML is not.

But you can use the QML compiler.  It translates the QML to C++ and compiles 
that.

It doesn’t hurt to try QtQuick, anyway.  If your UI is not complex, you can 
throw together a QML prototype in a few hours and see whether it performs 
better.  We have examples for both media-playing and web browsing, so you could 
start by checking performance of those.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.8 Features?

[Shawn Rutledge]

> On 28 Jun 2016, at 08:15, Marco Piccolino  wrote:
> 
> would be great to collect and exchange this to help each other - don't know 
> where's the best place and it should be promoted by Qt
> 
> Several packages which improve using Qt on mobile (and elsewhere!) are 
> currently published on qpm (http://qpm.io), with the sources available on 
> github. Currently there are just a couple of projects tageting native parts 
> but that should change if more people invest their time and energy.

Legally we can’t just snarf code from github - the authors would have to 
contribute it to Qt.  And there are probably some things there that could be 
added to Qt if they would like to make the contribution.

> Most of the mobile app developers who provide these meet and discuss 
> regularly on http://slackin.qtmob.org as well as on the regular channels. 
> Everyone is welcome to join so that efforts are not duplicate.

Is it mirrored to IRC?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.8 Features?

[Shawn Rutledge]

> On 23 Jun 2016, at 07:15, ekke  wrote:
> 
> thx Maurice,
> 
> Am 22.06.16 um 12:22 schrieb Maurice Kalinowski:
>> > Highest prio from my personal perspective:
>> > >> - Background processing API
>> > >> - In-app Notifications: local, remote
>> > + add Windows Store to Qt Purchasing module
> there's more missing:
> - avoid flicker for android apps out-of-the-box

What does that mean, just the initial appearance at startup?  My pet peeve is 
that startup of Qt Android apps takes too long, compared to Java apps.  
Ironically it's Java apps that are too slow on desktop platforms.  So I just 
wish I had a modern Qt-based phone, so that there’s one copy of the libs in 
memory already.  Apps would be small and fast.

> - easy way to 'share' content with/from other apps (Intents, Deep Linking) 
> Android, iOS
> such common use-cases should be abstracted and available via Qt API

Yes but it should be good, portable, future-proof API, to be worthwhile.  
Ideally even portable between desktops and mobiles.  It’s hard to predict the 
future, too.  There is a disconnect that on desktop platforms you share by 
saving files in one application and re-opening in another, or via the 
clipboard, or drag-and-drop, whereas on mobile platforms this stuff got 
re-invented.  I’m not sure if it’s an improvement: applications seem mostly 
isolated now, effectively.  Not that I’ve tried very hard to use a tablet for 
office-y stuff, but I’m not sure if everything that was possible on the desktop 
is possible on those platforms.  If you extend the platform to include cloud 
services (since not all data is even stored locally, I guess it’s supposed to 
mean that inter-app sharing must include sharing of access to data which is 
stored only on the cloud), do you trust them: are they secure? are they going 
to still be there in a few years?  will they continue to have a gazillion 
non-interoperable ways to do similar stuff?  How much abstraction can we do, to 
make sharing locally or via the cloud look similar?  Would you dare to start a 
university degree program for example, and do all your work only on a tablet?  
If you do that, can you still open anything that you did in a decade or two?  
If the inter-app sharing mechanisms are hindering people from getting work 
done, maybe they will be re-invented again?  So it seems hard to create APIs 
now that won’t look foolish in retrospect later on.

The file abstraction is nice because of being so universal.  Even cloud storage 
(with offline caching) can be done by making it a virtual filesystem.  Yet the 
file abstraction does seem long in the tooth, because we no longer rely on hard 
disks as much, and installing flash memory as a “disk” instead of “memory” is 
so arbitrary - it will end some day, especially if most memory ends up being 
non-volatile eventually.  But what is the long-term-stable replacement for the 
hierarchical filesystem?  Will we keep using it just because it’s such a 
human-friendly metaphor?  Or will sharing between all apps end up looking more 
like today’s mobile APIs, where you first have to open one app, and select the 
data, and “send” it to another; or, one app invokes another to “pull” 
something?  I guess the reason is that active transfer between apps which are 
both running at the same time is deemed more secure than passive file-reading.  
Or is there another reason?  But the protocols for that data transfer seem like 
shifting sand to me.
 
https://bugreports.qt.io/browse/QTBUG-36015 has links to some lower-level tasks 
like support for intents, anyway.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Drawing dashed line with QSGSimpleMaterialShader

[Shawn Rutledge]

> On 6 Jun 2016, at 12:29, Gunnar Sletta  wrote:
> 
>> On 06 Jun 2016, at 09:27, Artem Fedoskin  wrote:
>> Another question - is there any way to draw text solely in Scene Graph using 
>> QSG classes? I need to draw a lot of text labels and what only came to my 
>> mind is to draw them using QPainter on a QImage and store it as a 
>> QSGSimpleTextureNode in the node itself.
> 
> Nope, the text API is all internally, unfortunately. Going through the QImage 
> + texture node code path shouldn't be too bad though.

It’s not impossible to put text into the scenegraph from C++, but you will need 
to use private APIs, so you will be tied to a range of Qt versions where those 
private APIs don’t change.  You can use QTextLayout to generate QGlyphRuns, and 
create a QSGGlyphNode for each.  Some other QSG stuff is public (and there are 
examples in qtdeclarative/examples/quick/scenegraph), but QSGGlyphNode isn't.

It may turn out that rendering textures with QPainter, as you suggest, is 
faster anyway.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Role of `qmlscene` and `qml` command line tools

[Shawn Rutledge]

> On 06 May 2016, at 15:16, Elvis Stansvik  wrote:
> 
> Alright, I see. There's probably some JS lib out there I could use,
> after stripping everything after Qt.application.arguments[0] up to and
> including the '--'.
> 
> The point about trust is valid for any application though, isn't it?
> What's special about "here you go, run `qml main.qml`" compared to
> "here you go, compile main.cpp and run it"? In both cases the user
> must choose to trust the code. Or maybe I misunderstood you?

Yes.  There were various Windows viruses and worms that spread around by 
emailing scripts (and scripts packaged into other kinds of documents), so we 
hope that doesn’t tend to happen with QML.  If everyone was using QML as a 
scripting language, it would tend to happen.  But at least you can read the 
QML, as opposed to QML packaged up in resources in an .exe.  But the user would 
have to get qml.exe somehow to run it, and trust that too.  And besides, it’s 
often hard to put a whole application into a single QML file (although it can 
be done).  And we don’t have a .qar archive format or some such, like the Java 
ecosystem has.  So commercial software, for convenience, can be packaged as an 
exe with QML resources inside, and then you have to trust the whole thing.  
Maybe some users have been educated not to install exe’s from unknown sources.  
Maybe a tiny percentage of them would even verify a hash provided by the 
author.  Whereas if you send a user a QML file in an email, they might just 
click on it.  (And for that matter, some will click on emailed exe’s too.)  So 
there has been some worry, whether we will be in danger of repeating that part 
of history which has already been seen with other scripting languages, if we go 
too far down this path.

Whereas on Linux, if it became common practice to ship some “pure QML” apps as 
distro packages, at least on some distros they would be signed, and wouldn’t 
install if the signatures didn’t match, and the package system would make sure 
the application’s Qt-version requirements are satisfied.  So then you might as 
well not use resources, but let the package install the QML in some known 
location; and then it’s easier for the (super)user to make modifications if 
they want to, in the spirit of free software.

> Another thing I realized is that my instructions to other devs for
> working with Qt Creator becomes slightly more complicated. They'll go
> from just
> 
> 1. Open foo.pro in Qt Creator.
> 2. Edit the Run Environment to set PYTHONPATH.
> 3. Ctrl+R
> 
> to
> 
> 1. Open foo.pro in Qt Creator.
> 2. Add a new Custom Executable run configuration under Projects ->
> Run, to run `qml main.qml`.
> 3. Edit the Run Environment to set PYTHONPATH
> 4. Uncheck [X] Always build project before deploying it in Option ->
> Build & Run.
> 5. Ctrl+R

You can use a .qmlproject instead of a .pro.

> 
> But it's not that bad.
> 
> Anyway, thanks for the input. I also had a look at the config file
> that `qml` uses, and it seems that what is shown in the default config
> is pretty much all there is.
> 
> Elvis

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Role of `qmlscene` and `qml` command line tools

[Shawn Rutledge]

> On 6 May 2016, at 13:07, Elvis Stansvik  wrote:
> 
> [estan@pyret ~]$ qml test.qml -- --foo bar
> qml: /usr/lib/qt/bin/qml,test.qml,--,--foo,bar
> [estan@pyret ~]$
> 
> Do you know if there's any QML API to get just the arguments following
> "--"? Or I'll have to parse that out myself?
> 
> In general, is there any convenient QML API for command line parsing?
> (e.g. like QCommandLineParser on the C++ side)

Not really, AFAIK.  QCommandLineParser is kindof new itself (umm since 5.2… 
tempus fugit).  It would be interesting to come up with a nice declarative API 
for that.  It would probably need a QObject or Q_GADGET wrapper since 
QCommandLineParser isn’t either one, and has an imperative API.  But I wonder 
how many people would use it.

Running any kind of script directly without looking at it first requires some 
trust, so maybe that’s why it hasn’t been in high demand to use QML that way, 
so far.  Or else it’s just lack of habit, and lack of advertising that you 
could do that.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Role of `qmlscene` and `qml` command line tools

[Shawn Rutledge]

> On 6 May 2016, at 11:36, Elvis Stansvik  wrote:
> 
> Hi all,
> 
> Since some time, the `qmlscene` command has been available for
> debugging QML applications:
> 
> …
> Recently, the `qml` command is also available:
> 
> The tools seem quite similar. What was the rationale for introducing
> `qml`? The old `qmlscene` is described in the docs [1] as:
> 
> "The qmlscene utility is meant to be used for testing your QML
> applications, and not as a launcher in a production environment. To
> launch a QML application in a production environment, develop a custom
> C++ application or bundle the QML file in a module. See Deploying QML
> applications for more information."
> 
> Is there a similar page describing the `qml` tool somewhere (I can't
> see it mentioned anywhere)? Is the `qml` tool also meant only for
> testing/debugging, and not for production use?

The QML tool is a bit more flexible, makes fewer assumptions (e.g. it doesn’t 
use a QApplication by default, so you don’t end up loading the widgets module 
into memory if you don’t need it) and is meant as the long-term replacement for 
qmlscene.  QML can be used for non-graphical purposes if your root object is a 
plain QObject, not an Item or Window; that’s only practical with the qml tool, 
not qmlscene.  It is more directly analogous to other language interpreters 
like python and perl (which also do not load graphical libraries unless you 
import the relevant modules in your script), and you can even use the shebang 
mechanism, so that qml files can be marked executable and run from the command 
line.  You can configure your window system to use it as the default 
application with which to run any file with the qml extension (e.g. when 
double-clicking a qml file in your file manager/finder), if you like.  
(QTBUG-33659 is a request to set up that association when you install the SDK, 
but that never got done AFAIK.  It requires someone with Qt Installer 
expertise, I think.)

Here’s one of Alan’s talks, shortly after he wrote it:

https://www.youtube.com/watch?v=2nnrl1v7LcE

So you could nearly forget about qmlscene, except that it has a few handy 
command-line options that qml still doesn’t.  OTOH qml can be configured via 
config files.  And yes I think that should be documented better.  You can see 
the default configuration in tools/qml/conf/configuration.qml, but it’s not 
clear enough what else could be declared in your custom config file.

> The reason I'm asking is I'm building a QML application for embedded
> use. The app is QML only, apart from some calls from QML into Python
> using pyotherside [2] when interfacing with the hardware. So in theory
> I could launch my app using `qmlscene` or `qml`, which would free me
> from having to build and distribute a little C++ launcher application
> to launch the app.

That’s what the qml tool is intended for.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [QtQuick] Interaction with user from C++

[Shawn Rutledge]

> On 26 Apr 2016, at 10:02, Sina Dogru  wrote:
> 
> On the Widgets world, some of the static functions of QMessageBox and 
> QFileDialog (eg getSaveFileName and warning) are so handy and necessary, 
> IMHO. I do mimic this behaviour with a QML function, which opens a file 
> dialog or a message box with the function arguments, connected to a signal of 
> a C++ class. So whenever I need to interact with the user from C++ I just 
> emit this signal with the proper arguments. For example when I need to say to 
> user that his/her input was incorrect, I just emit warning signal. But the 
> problem is when I need to get the user respond to this warning box. Beauty of 
> the QMessageBox and QFileDialog's static functions are they creates their own 
> event loop and they just returns the data that needed.

You shouldn’t need to do this.  Just write onAccepted/onRejected handlers which 
call back to QML and/or C++ code as necessary.  Is there some reason why that 
is difficult?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest