Re: [Interest] "QXcbClipboard::setMimeData: Cannot set X11 selection owner"

[Thiago Macieira]

On Wednesday, 7 March 2018 07:36:43 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Obviously no GTK application is going to print something about
> > "QXcbClipboard".
> 
> Yeah, DOH :) I don't have the GTk sources on my system currently but it's
> likely that somewhere there will be a call to xcb_set_selection_owner() in
> there too, no? That's where the error message I see comes from: the call
> fails (doesn't have the expected effect).

Yes, it's likely. That doesn't mean GTK prints something as a result of that.

> > Can you see any other symptom besides the warning?
> 
> Sadly, yes. Copying to the clipboard no longer works in affected
> applications. Instead I get that error message.

And this symptom doesn't happen with GTK?

> Fortunately this doesn't happen often, but that's also annoying for
> debugging. I'm now dumping the immediately relevant variables when the
> error does occur, and also use xcb_set_selection_owner_checked() and
> xcb_request_check() in hope that will tell us what really goes wrong.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
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?

[Jason H]

> Sent: Wednesday, March 07, 2018 at 8:10 AM
> From: "Uwe Rathmann" 
> To: interest@qt-project.org
> Subject: Re: [Interest] How to render small Images decently on non retina 
> displays with QtQuick?
>
> Hi Shawn,
> 
...
> 
> I once derived a small class from QQuickImage ( https://github.com/uwerat/
> qskinny/blob/master/playground/images/Image.h ), to avoid some of these 
> issues, but I never used it as we later decided to go with writing our 
> own code for displaying images.
> 
> This code uses a class that is called QskGraphic, what in the end is a 
> record/replay paint device - similar to QPicture, but tailored for 
> scalable vector graphics.

How is QPicture not appropriate for SVG?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] KDE's qqc2-desktop-style

[Jason H]

> Sent: Wednesday, March 07, 2018 at 8:53 AM
> From: "Nikos Chantziaras" 
> To: interest@qt-project.org
> Subject: Re: [Interest] KDE's qqc2-desktop-style
>
> On 06/03/18 19:45, Jason H wrote:
> > https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
> > So this combines QStyle with QML, so QML can be more widget like. Can this 
> > be a part of Qt?
> 
> This is just for KDE though, right? Interestingly, KDE is the only 
> platform where my Qt applications don't look native, unless they compile 
> it themselves (which they can't do in closed source applications; and 
> most people don't compile applications themselves anyway.)

The line QT_QUICK_CONTROLS_STYLE=org.kde.desktop is only needed to it's not any 
of the other styles so that this style gets used. Sine it uses QStyle, which is 
already aware of platform styles, it should "just" work on all platforms where 
QStyle is supported! Yee-haw!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] "QXcbClipboard::setMimeData: Cannot set X11 selection owner"

[René J . V . Bertin]

Thiago Macieira wrote:


> Yes, it's likely. That doesn't mean GTK prints something as a result of that.

No, but I don't care about the error message in itself.

> And this symptom doesn't happen with GTK?

And no, which is what I meant when I said that those applications aren't 
affected (I use a minimal XCFE desktop, so always have a couple of GTk-based 
applications running).

R.

___
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?

[Uwe Rathmann]

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. 

Uwe

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

Re: [Interest] KDE's qqc2-desktop-style

[Nikos Chantziaras]

On 07/03/18 18:21, Sérgio Martins wrote:

On 2018-03-06 17:45, Jason H wrote:

https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
So this combines QStyle with QML, so QML can be more widget like. Can
this be a part of Qt?


Only if you give reasons for it to be in qt-project rather than in KDE 
(assuming the maintainer accepts).


Is it due to lack of binaries for platform X, hard to build KDE software 
or ?


As I see it, it's because nobody knows about it, and as a result, Qt 
Quick results in your application not looking like a native one. (Which 
is my reason for sticking to Widgets and avoiding QML UIs.)




Many of the reasons people usually give should be tackled directly by KDE.
The software is great and already works in "non-KDE programs", so I 
assume it's some minor process that needs improving so people use it more.


If it's not in Qt, people just don't know it's there. Windows or macOS 
developers who use Qt don't have any reason to know what "KDE" even is.


IMO, Qt should make Qt Quick look native without requiring 3rd-party 
libraries for it.


Now that I know this exists, this is no longer an issue for me, I guess. 
But if I didn't read this mailing list, I'd never have known this even 
exists. I now might actually use QML for UIs (depending on how well this 
thing works; haven't tried it yet.)


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

Re: [Interest] Qt/Mac : what about a (the) Window menu?

[René J . V . Bertin]

Here's a small PoC patch to the Cocoa QPA (5.9) which adds a Windows (sic) menu:

https://github.com/RJVB/osx-integration/blob/qt590/src/qcocoa-qpa/patches/33-patch-add-windows-submenu.diff

I don't think it will be trivial to create the standard Window menu that sits 
just left of the Help menu in the menubar (where is that menu created??). 
Instead the patch just adds a submenu to the Application menu and makes this 
the application's window menu, activating it when a NSWindow instance is 
allocated. The system then takes care of the rest.

Evidently this isn't in accordance with HIG and tradition, but IMHO the 
location I use isn't otherwise really out of place, just above the application 
visibility controls. :)


R.
___
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?

[Nuno Santos]

Uwe,

Thanks for things insight!

Regards,

Nuno

> On 7 Mar 2018, at 08: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.
> 
> Uwe
> 
> 
> 
> 
> ___
> 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?

[Uwe Rathmann]

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.

Uwe




___
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?

[Xavier Bigand]

This is good to know, I personally never fall in a such case, but I will
keep that in a corner of my head.

Thank you.

2018-03-07 9:08 GMT+01:00 Uwe Rathmann :

> 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.
>
> Uwe
>
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



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

Re: [Interest] KDE's qqc2-desktop-style

[Nikos Chantziaras]

On 06/03/18 19:45, Jason H wrote:

https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
So this combines QStyle with QML, so QML can be more widget like. Can this be a 
part of Qt?


This is just for KDE though, right? Interestingly, KDE is the only 
platform where my Qt applications don't look native, unless they compile 
it themselves (which they can't do in closed source applications; and 
most people don't compile applications themselves anyway.)


___
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?

[Uwe Rathmann]

Hi Shawn,

> It should also be considered a bug IMO.

The only obvious part of the whole disaster that IMO qualifies as a "bug" 
is the fact, that binding a size ends up in 2 calls - but AFAIK this is 
not specific to QQuickImage.

Maybe one could say, that QQuickImage shouldn't do any updates before 
updatePolish, but this would be the opposite of the overall "as soon as 
much as possible" caching strategy implemented in Qt/Quick.

I once derived a small class from QQuickImage ( https://github.com/uwerat/
qskinny/blob/master/playground/images/Image.h ), to avoid some of these 
issues, but I never used it as we later decided to go with writing our 
own code for displaying images.

This code uses a class that is called QskGraphic, what in the end is a 
record/replay paint device - similar to QPicture, but tailored for 
scalable vector graphics.

This way we can precompile our SVGs at build time into QPainter commands 
and store them into as something we call a qvg file. As we have small 
iconic graphics only we can load those files from disk in updatePolish 
and replay the commands in updatePaintNode without needing any cache at 
all.

( If you are interested: the qvgviewer example in qskinny uses it. )

Maybe a side node: IIRC creating a QImage and translating it into a FBO 
seems to be faster - when having simple icons - than creating the FBO 
directly. Looks like the tesselation done inside the OpenGL paint engine 
is as expensive as what the raster paint engine has to do for pixeling 
down the RGB values.

( But this is something I noticed 2 year ago and might have changed in 
the meantime ? )

Uwe 


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

[Interest] "QXcbClipboard::setMimeData: Cannot set X11 selection owner"

[René J . V . Bertin]

Hi,

Apologies if I've asked this before: any idea what could cause this error 
message?

QXcbClipboard::setMimeData: Cannot set X11 selection owner

I'm seeing this sporadically in applications connected to an XQuartz X11 server 
that has been running for a certain time. It always seem to affect all the 
applications that are currently connected, but doesn't persist after an 
application restart (= I don't have to restart the server).

Hoping for some insight(s); I'm pretty certain that the issue is caused by 
something odd in XQuartz but cannot ignore the fact that it affects only Qt 
applications (GTk-based applications are not affected).

Thanks,
René


___
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] "QXcbClipboard::setMimeData: Cannot set X11 selection owner"

[Thiago Macieira]

On Wednesday, 7 March 2018 03:21:45 PST René J.V. Bertin wrote:
> QXcbClipboard::setMimeData: Cannot set X11 selection owner
> 
> I'm seeing this sporadically in applications connected to an XQuartz X11
> server that has been running for a certain time. It always seem to affect
> all the applications that are currently connected, but doesn't persist
> after an application restart (= I don't have to restart the server).
> 
> Hoping for some insight(s); I'm pretty certain that the issue is caused by
> something odd in XQuartz but cannot ignore the fact that it affects only Qt
> applications (GTk-based applications are not affected).

Obviously no GTK application is going to print something about 
"QXcbClipboard". Can you see any other symptom besides the warning?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

Re: [Interest] "QXcbClipboard::setMimeData: Cannot set X11 selection owner"

[René J . V . Bertin]

Thiago Macieira wrote:

> Obviously no GTK application is going to print something about
> "QXcbClipboard".

Yeah, DOH :) I don't have the GTk sources on my system currently but it's 
likely 
that somewhere there will be a call to xcb_set_selection_owner() in there too, 
no? That's where the error message I see comes from: the call fails (doesn't 
have the expected effect).

> Can you see any other symptom besides the warning?

Sadly, yes. Copying to the clipboard no longer works in affected applications. 
Instead I get that error message.

Fortunately this doesn't happen often, but that's also annoying for debugging. 
I'm now dumping the immediately relevant variables when the error does occur, 
and also use xcb_set_selection_owner_checked() and xcb_request_check() in hope 
that will tell us what really goes wrong.

R.

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

Re: [Interest] KDE's qqc2-desktop-style

[Jean-Michaël Celerier]

> This is just for KDE though, right?

No, it works pretty much everywhere and has no kde dependencies in the
plug-in code : https://github.com/KDE/qqc2-desktop-style/tree/master/plugin



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

On Wed, Mar 7, 2018 at 2:53 PM, Nikos Chantziaras  wrote:

> On 06/03/18 19:45, Jason H wrote:
>
>> https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
>> So this combines QStyle with QML, so QML can be more widget like. Can
>> this be a part of Qt?
>>
>
> This is just for KDE though, right? Interestingly, KDE is the only
> platform where my Qt applications don't look native, unless they compile it
> themselves (which they can't do in closed source applications; and most
> people don't compile applications themselves anyway.)
>
>
> ___
> 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] Qt/Mac : what about a (the) Window menu?

[René J . V . Bertin]

Nikos Chantziaras wrote:

> In other words, don't use QML for desktop applications if you can avoid
> it :-/

I wouldn't...

> It looks like the standard Windows menu to me in Assistant (Qt 5.8)? We
> get the standard menu in our application too, which is exactly what we want.


I suppose that's not an open source application?

In the Assistant that menu is created explicitly and populated with the 
Minimise 
and Zoom actions. The menu itself is held by a local variable and thus isn't 
referenced anywhere else. AFAICT that means it will only ever contain those 2 
items, which seems to be confirmed in practice.

There is a design difference that's relevant here: Qt applications tend to use 
tabs or subwindows in a single (or handful) of main windows; native Mac 
applications tend to use more individual windows, and that's what the automatic 
Window menu we're used to works with (see also NSApplication(NSWindowsMenu) ).

I don't see any evidence (in Qt 5.9 and earlier) of an explicit deactivation of 
the window menu (there's a call to exclude specific NSWindows from it), but I 
also don't see any evidence that a Window menu is created and declared (via 
NSApplication:setWindowsMenu). I added a debug probe at an appropriate location 
in the Cocoa QPA and indeed, `[NSApp windowsMenu]` returns NULL in random 
applications. 

R.

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

Re: [Interest] KDE's qqc2-desktop-style

[Sérgio Martins]

On 2018-03-06 17:45, Jason H wrote:

https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
So this combines QStyle with QML, so QML can be more widget like. Can
this be a part of Qt?


Only if you give reasons for it to be in qt-project rather than in KDE 
(assuming the maintainer accepts).


Is it due to lack of binaries for platform X, hard to build KDE software 
or ?


Many of the reasons people usually give should be tackled directly by 
KDE.
The software is great and already works in "non-KDE programs", so I 
assume it's some minor process that needs improving so people use it 
more.



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

Re: [Interest] KDE's qqc2-desktop-style

[Nikos Chantziaras]

On 07/03/18 17:49, Jean-Michaël Celerier wrote:

 > This is just for KDE though, right?

No, it works pretty much everywhere and has no kde dependencies in the 
plug-in code : https://github.com/KDE/qqc2-desktop-style/tree/master/plugin


That does sound like a good solution for Qt Quick desktop apps! I wasn't 
sure what this meant:


  QQuickStyle::setStyle("org.kde.desktop");

The "org.kde.desktop" part made it look like this is tied to KDE.

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