Re: [Interest] Is 6.x finally there ??

[Volker Hilsheimer via Interest]

> On 20 Oct 2022, at 22:35, Scott Bloom  wrote:
> 
> I haven’t been following the 6.x progress very much.  Only because it was 
> clear 6.0 and 6.1 were not ready to replace all the functionality of 5.x
>  
> However, with 6.4 it appears that all functionality that is going to be 
> brought forward, has been completed.  Is that true? Or is there sill chunks 
> of 5.x missing (that will be brought forward) ?
>  
> Scott

Hi Scott,


The only module that is not officially available in Qt 6 yet, and that we still 
want to bring back in some form, is Qt Location. Work is progressing on that 
module [1].

[1] https://bugreports.qt.io/browse/QTBUG-96795

There are some modules that currently live only in Qt5Compat, such as Qt 
Graphical Effects. We’re working on a replacement for that as well [2], 
addressing some of the deficiencies of it Qt Graphical Effects, but if you were 
happy with things in Qt 5, then the types in Qt5Compat as they are are 
perfectly fine to use.

[2] https://www.qt.io/blog/introducing-qt-quick-effect-maker


So, unless you depend on Qt Location, there’s no point in waiting. And if you 
do - we’ll soon share more updates on our blog.

Volker

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

Re: [Interest] Is 6.x finally there ??

[Volker Hilsheimer via Interest]

Thanks for pointing those out Bill, I did not have those helpers from the Qt 5 
Extras on my radar. Will check where we are with those.


Volker


> On 21 Oct 2022, at 23:18, Bill Jones  wrote:
> 
> Hi Volker,
> 
> Another missing module in Qt 6.x that is very important to desktop 
> applications is clipboard support. 
> 
> https://bugreports.qt.io/browse/QTBUG-93632
> 
> Without cross platform (at least MacOS and Windows) we will never be able to 
> move from 5.15.x to Qt 6. This is an absolute necessity for us and I have not 
> seen any progress on this issue. I apologize if I seem a little strident, but 
> my questions to support have not gotten any movement on this.
> 
> Bill
> 
> 
>> On Oct 21, 2022, at 10:00 AM, Volker Hilsheimer via Interest 
>>  wrote:
>> 
>>> On 20 Oct 2022, at 22:35, Scott Bloom  wrote:
>>> 
>>> I haven’t been following the 6.x progress very much.  Only because it was 
>>> clear 6.0 and 6.1 were not ready to replace all the functionality of 5.x
>>> 
>>> However, with 6.4 it appears that all functionality that is going to be 
>>> brought forward, has been completed.  Is that true? Or is there sill chunks 
>>> of 5.x missing (that will be brought forward) ?
>>> 
>>> Scott
>> 
>> Hi Scott,
>> 
>> 
>> The only module that is not officially available in Qt 6 yet, and that we 
>> still want to bring back in some form, is Qt Location. Work is progressing 
>> on that module [1].
>> 
>> [1] https://bugreports.qt.io/browse/QTBUG-96795
>> 
>> There are some modules that currently live only in Qt5Compat, such as Qt 
>> Graphical Effects. We’re working on a replacement for that as well [2], 
>> addressing some of the deficiencies of it Qt Graphical Effects, but if you 
>> were happy with things in Qt 5, then the types in Qt5Compat as they are are 
>> perfectly fine to use.
>> 
>> [2] https://www.qt.io/blog/introducing-qt-quick-effect-maker
>> 
>> 
>> So, unless you depend on Qt Location, there’s no point in waiting. And if 
>> you do - we’ll soon share more updates on our blog.
>> 
>> Volker
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 

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

Re: [Interest] Is 6.x finally there ??

[Volker Hilsheimer via Interest]

Yo Roland,

> On 26 Oct 2022, at 20:52, Roland Hughes via Interest 
>  wrote:
>>> On 20 Oct 2022, at 22:35, Scott Bloom 
>>>  wrote:
>>> 
>>> I haven?t been following the 6.x progress very much.  Only because it was 
>>> clear 6.0 and 6.1 were not ready to replace all the functionality of 5.x
>>>  
>>> However, with 6.4 it appears that all functionality that is going to be 
>>> brought forward, has been completed.  Is that true? Or is there sill chunks 
>>> of 5.x missing (that will be brought forward) ?
>>>  
>>> Scott
>>> 
> Hello Scott,
> 
> I feel compelled to point out only developers creating Qt responded with 
> "Good to Go!". In particular the sticky wicket would be this quote
> 
> "and that we still want to bring back in some form"
> 
> Qt 6 has become the rental car company definition of "full sized" which now 
> fits in the trunk of what most customers would call "full sized." They 
> mentioned QtLocation and Bill Jones brought up
> 
> "Another missing module in Qt 6.x that is very important to desktop 
> applications is clipboard support."
> 
> I don't know how anyone could create a desktop application without any form 
> of clipboard support since users like to select from text file and paste 
> answers into fields, especially if they are scraping answers out of an email 
> or something like that.


What makes you think that Qt 6 has no clipboard support? You obviously didn’t 
bother with opening the referenced JIRA ticket.

What Bill pointed out as missing are the platform-specific classes that 
facilitate the integration of platform specific clipboard formats on Windows 
and macOS into Qt’s mime-based framework. Qt supports clipboard operations for 
common mime types just fine.


> You should probably also check here:
> 
> https://blog.basyskom.com/2021/porting-a-qt-5-application-to-qt-6/


Note that the basyskom blog is based on Qt 6.0. We are at Qt 6.4 now, and I 
would anyway almost think that you didn’t read it, given your implication that 
it must have been somehow difficult to port to this trunk-sized, clipboard-less 
Qt 6.


> Not that it matters to you, but not one of my clients is moving to Qt 6. 
> Legacy products will continue to be maintained with Qt 4.8 custom spins as 
> well as Qt 5.x custom spins but no new development will occur using Qt. That 
> has been the feedback from one and all.


Indeed, what your clients do or don’t do would be a lot more interesting if we 
could assume that they get their information from someone who’s at least trying 
to keep up ;)


Cheers,
Volker

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

Re: [Interest] Is 6.x finally there ??

[Volker Hilsheimer via Interest]

Rejoice!

Once https://codereview.qt-project.org/c/qt/qtbase/+/443474 has merged 
succesfully there’ll be a public API again that allows applications to extend 
the list of supported clipboard formats with Windows and mac/iOS specific 
converter implementations.

Feedback very much welcome.

Volker


> On 23 Oct 2022, at 21:29, Volker Hilsheimer via Interest 
>  wrote:
> 
> Thanks for pointing those out Bill, I did not have those helpers from the Qt 
> 5 Extras on my radar. Will check where we are with those.
> 
> 
> Volker
> 
> 
>> On 21 Oct 2022, at 23:18, Bill Jones  wrote:
>> 
>> Hi Volker,
>> 
>> Another missing module in Qt 6.x that is very important to desktop 
>> applications is clipboard support. 
>> 
>> https://bugreports.qt.io/browse/QTBUG-93632
>> 
>> Without cross platform (at least MacOS and Windows) we will never be able to 
>> move from 5.15.x to Qt 6. This is an absolute necessity for us and I have 
>> not seen any progress on this issue. I apologize if I seem a little 
>> strident, but my questions to support have not gotten any movement on this.
>> 
>> Bill
>> 
>> 
>>> On Oct 21, 2022, at 10:00 AM, Volker Hilsheimer via Interest 
>>>  wrote:
>>> 
>>>> On 20 Oct 2022, at 22:35, Scott Bloom  wrote:
>>>> 
>>>> I haven’t been following the 6.x progress very much.  Only because it was 
>>>> clear 6.0 and 6.1 were not ready to replace all the functionality of 5.x
>>>> 
>>>> However, with 6.4 it appears that all functionality that is going to be 
>>>> brought forward, has been completed.  Is that true? Or is there sill 
>>>> chunks of 5.x missing (that will be brought forward) ?
>>>> 
>>>> Scott
>>> 
>>> Hi Scott,
>>> 
>>> 
>>> The only module that is not officially available in Qt 6 yet, and that we 
>>> still want to bring back in some form, is Qt Location. Work is progressing 
>>> on that module [1].
>>> 
>>> [1] https://bugreports.qt.io/browse/QTBUG-96795
>>> 
>>> There are some modules that currently live only in Qt5Compat, such as Qt 
>>> Graphical Effects. We’re working on a replacement for that as well [2], 
>>> addressing some of the deficiencies of it Qt Graphical Effects, but if you 
>>> were happy with things in Qt 5, then the types in Qt5Compat as they are are 
>>> perfectly fine to use.
>>> 
>>> [2] https://www.qt.io/blog/introducing-qt-quick-effect-maker
>>> 
>>> 
>>> So, unless you depend on Qt Location, there’s no point in waiting. And if 
>>> you do - we’ll soon share more updates on our blog.
>>> 
>>> Volker
>>> 
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> https://lists.qt-project.org/listinfo/interest
>> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

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

Re: [Interest] synchronous use of Qt state machine

[Volker Hilsheimer via Interest]

On 2 Feb 2023, at 20:27, Stefan Seefeld  wrote:

Hello,

I haven't got any response to my question, but as the answer may really help us 
simplify our code I'm sending it again.
Thanks for any help !

On Tue, Nov 22, 2022 at 9:02 AM Stefan Seefeld 
mailto:ste...@seefeld.name>> wrote:
Hello,
we are using Qt State Machines in a number of places in our applications to 
manage object states for certain types of objects. Occasionally I would like to 
use and manipulate such objects in a non-event-driven context, i.e. without a 
running event loop.
Short of a StateMachine function that allows me to wait for outstanding 
transitions to be completed, I wrote a little helper function that instantiates 
a `QEventLoop`, then calls `processEvents(QEventLoop::ExcludeUserInputEvents)` 
to drain the event queue and thus make sure that all in-flight transitions have 
been completed.
While this appears to be working fine, I'm not sure this is the best way (or at 
the very least, a particularly elegant way) to achieve what I want.

Is the above a "correct" way to get what I want ? Is there a better way ?

--

On 4 Feb 2023, at 20:11, Stefan Seefeld  wrote:

Hi Roland,

thanks for your feedback !
I partially agree with your analysis. In particular, I'm not entirely sure why 
the entire application logic needs to gravitate around a single event loop. For 
user-input events this of course makes sense, as they are naturally ordered and 
so conceptually we don't need concurrency to model the related control-flow. 
(We do need asynchrony, though !)

My main puzzlement stems from the fact that the event loop is used in places 
where I don't expect it, such as in the handling of state machines. Of course, 
state changes may well be triggered by user input (or some other events), but 
they don't have to, so it seems questionable why the entire state machine 
architecture has to be founded on the event loop as well. It could be 
independent, with some mix-in classes that allow state machines to interact 
with the event loop, without forcing such a dependency on everyone.

But to get back to the smaller scope of my original question, users don't even 
have to access the main event loop via the `QApplication::processEvents()` 
function; they can just create their own local `QEventLoop` instance and use 
that. (Of course, under the hood that has to interact with the main event loop, 
which is why this only works in the presence of a global `QApplication` 
instance, but that interaction is luckily already hidden from the user.)

My question is: Is it OK to use my own local `QEventLoop` to drain events to 
render state-change requests synchronous. And furthermore, if the answer is 
"yes", is there a reason why such a facility isn't already offered by the Qt 
API itself ?

I'd really like to hear what Qt developers have to say about this, and, as you 
suggest, about the broader question of how to scale Qt applications to modern 
many-core platforms. How would users write modern C++-2x applications while 
using `co_await` ? There already are adapters for the Python equivalent, using 
`QEventLoop` instances to manage events and dispatch control flow to multiple 
threads (e.g. https://github.com/CabbageDevelopment/qasync). It seems to me 
what I'm asking for is something similar, if not much simpler).

Thanks,

Hi Stefan,


Where do you see the advantages of synchronously waiting for a state to be 
reached, when instead you can connect to the respective state’s entered() 
signal? The former might make your code look more linear of course, with less 
complexities due to object lifetimes etc.

When the QtState Machine framework was added it was done so in the context of a 
UI framework, so a core design choice was to drive the state machine 
asynchronously so that the UI doesn’t freeze. And since then, we had no 
compelling reason to modify that architecture. It seems to work well enough in 
the context of a UI framework, where state transitions are triggered by events. 
Or maybe people have silently migrated to alternative state machine frameworks.

QStateMachine could live in it’s own thread which can run its own event loop. 
States emit signals, so objects interesting in state enter/exit notifications 
can connect to those signals even if they live in threads other than the state 
machine. And a QSignalTransition could operate on a sender living in a 
different thread as well (QEventTransition can’t support that though). So 
asynchronicity could be achieved that way as well, but it doesn’t solve your 
problem of stopping your code until a state has been reached. The design of Qt 
State Machine is that you put that code into a callable connected to the 
respective signals.

That is a general question. We probably don’t want more waitFor… style APIs in 
Qt. If we would add such APIs, they might very well be implemented by a local 
QEventLoop that runs until the signal you are waiting for gets emitted. So your 
solution is reasonable. Why is it

Re: [Interest] Ability to pass UIA property to object

[Volker Hilsheimer via Interest]

On 1 Mar 2023, at 13:14, Corentin BACQUÉ-CAZENAVE via Interest 
 wrote:


Hi,

I reported that a UIA property is missing on some Qt components here:

[QTBUG-104569] UIA Level property is missing for tree items - Qt Bug 
Tracker

Unfortunately, this has not been fixed yet. So, I'm wondering if a way exists 
to manually pass a UIA property to an object.

Does anyone has any idea on ability to do this?

Commented on the ticket, with some hints on where to start looking if you want 
to give a patch a shot. There’s no way for an application to add such a 
property to an object (and an item in a tree is generally not represented by an 
object, it’s just data provided by the model).

Volker

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

Re: [Interest] Weird assert, how to debug?

[Volker Hilsheimer via Interest]

It’s reliably reproducible with dev on macOS. It seems to be related to the 
introduction of the “compound widget” notion in Qt 5.10 (so this should in 
principle not be a new bug, but we had a few follow-up patches after the 
introduction of that concept).

A widget that has a child as its focusProxy is considered a compound widget. 
When the compound widget’s position in the tab chain is changed, then the 
entire “compound” changes position in the tab order. By that definition, a 
QTabWidget is always a compound widget, as it sets the tab bar as their proxy 
(and the tab bar’s focus policy is NoFocus on macOS, unless I enable 
keypadNavigation, which impacts the behavior in the reproducer).


The conflated meaning of focusProxy is making this rather messy. The original 
idea of focus proxy was to enable building of widgets out of several widgets, 
where the widget inside is just an implementation detail. Ie the lineedit in a 
spinbox or editable combobox should not be visible to the application wrt 
focus. The combobox has focus. And so the outer widget is the focus proxy for 
the inner widget, and forwards key events to the inner widget (e.g. 
QAbstractSpinBox::keyPressEvent passes most events on to the editor).

But focusProxy also gets used for compound widgets, where the outer widget is 
just a container with no focus policy, but with (several, perhaps) focusable 
widgets inside. QTabWidget is one example - it’s just a container, but the tab 
bar has keyboard navigation, and pages inside have keyboard navigation. That’s 
the use case that the QWidget::setFocusProxy suggests for UI development 
(rather than when authoring widgets), where it would be very impractical to 
have to overwrite keyPress/ReleaseEvent to redirect from container to inner 
widget.

With the second use case, tab ordering was messy, as changing the tab order of 
the compound wasn’t possible - you had to change the order for each widget 
inside. Until 5.10.


So, your tab widget is a compound, and the QLineEdit “dataFile" is part of that 
compound, by being a child of the tab widget.

Your reproducer sets the tab order to go from line edit to tab widget. That 
results in a loop - the tab widget (or it’s tab bar) should come after the line 
edit, but since the line edit is the last focusable child in the tab widget 
compound, we end up with a situation where some widgets are no longer part of 
the focus chain.

I’m having a look. The question is: what should happen here - no assert of 
course, at least not in the QWidget destructor. But if you set the tab order so 
that you tab from lineEdit back into the parent tab widget, then you are 
somewhat asking for a loop (because the lineEdit is also after the tab widget). 
And we need to allow that as a temporary state.

So as a stop-gap, don’t set the tab order to move from line edit to tab widget.

Volker




On 3 Mar 2023, at 19:42, Scott Bloom  wrote:

Qt Creator? Never heard of it 😊  I use Visual Studio, but I did already try 
this.

The assert kicks off directly from the command line as well.

Scott

From: Interest  On Behalf Of Axel Spoerl via 
Interest
Sent: Friday, March 3, 2023 9:43 AM
To: interest@qt-project.org
Subject: Re: [Interest] Weird assert, how to debug?

Hi Scot,
Please try running the executable from outside Qt Creator to eliminate its 
debugger as the troublemaker.
Cheers
Axel


On 3 Mar 2023, at 18:33, Scott Bloom 
mailto:sc...@towel42.com>> wrote:

As you can see by the sample, Im not doing anything special, not changing any 
ownership, and not doing any individual deletes + deleteLaters with a 
processEvents (The root cause of many a “double delete in my experience”), so 
Im really stumped on this one.

Something in designer with the UI file is causing this.

Scott

From: Interest 
mailto:interest-boun...@qt-project.org>> On 
Behalf Of Axel Spoerl via Interest
Sent: Thursday, March 2, 2023 10:09 PM
To: interest@qt-project.org
Subject: Re: [Interest] Weird assert, how to debug?

Hi Scott,

I can't make the reproducer crash on Qt 5.15.9 or on the latest dev (6.6).
The assertion happens in QWidget's destructor, when it wants to exit from the 
focus list.
I can imagine two cases, how this assertion kicks in.

  1.  The code path in the if statement right after the assertion has been 
reached before:
if (d->focus_next != this) {
d->focus_next->d_func()->focus_prev = d->focus_prev;
d->focus_prev->d_func()->focus_next = d->focus_next;
d->focus_next = d->focus_prev = nullptr;
}

=> An already deleted widget is deleted a second time.

  1.  Focus chain has changed without events having been processed, so the 
destroyed widget doesn't know about it.
Happens in the debugger (e.g. Qt Creator) sometimes, because debugging output 
is a notirious focus thief.

Option 2 seems more likely to me, since the assertion doesn't shout in release 
builds.
Updating to the latest Qt Creator version may help. If it doesn't please fil

[Interest] Meeting C++ "Ask Me Anything" session with Qt Chief Maintainer

[Volker Hilsheimer via Interest]

Hi,

I hope some of you might be interested in joining this and, well, ask anything:

https://www.meetup.com/meeting-cpp-online/events/291796153/


Cheers,
Volker

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

Re: [Interest] QMultiMap as QVariant

[Volker Hilsheimer via Interest]

> On 14 Apr 2023, at 23:11, Thomas Sevaldrud  wrote:
> 
> Hi, in my code I have a hierarchical QMultiMap of QVariants, where a map 
> value can be a new multimap of variants. This does not compile anymore in Qt 
> 6. I.e. something like this:
> 
>   QMultiMap varMap;
>   QMultiMap subMap;
>   varMap.insert("key", subMap); // Compile error here, since there is no 
> conversion to QVariant
> 
> This worked in 5.15, but not in 6.5
> 
> If I change it to QMap it works, but I need multimap for this. Is this change 
> by design, or is it an omission? Any ideas for a workaround?
> 
> Cheers,
> Thomas


In Qt 5, QMultiMap was a subclass of QMap, so implicitly constructing a 
QVariant from a QMultiMap was possible because it was possible from a QMap. 
That happened to work because QMultiMap just added API on top of a QMap, and 
QMap’s data structure could handle multiple values for the same key. So no 
slicing occurred. However, if you run:

#include 

int main(int argc, char *argv[])
{
QMultiMap varMap;
QMultiMap subMap;
varMap.insert("key", subMap);
qDebug() << varMap.value("key").typeName();

return 0;
}

then you would get QVariantMap (ie a QMap), not QMultiMap. 
So modifying the value you got out of the map would not give you multi-map 
semantics.


In Qt 6, QMultiMap is not a QMap subclass anymore (and that was a design 
decision), and since it’s such a rarely used type there is also no implicit 
constructor or conversion operator, and no built-in metatype defined for 
QMultiMap.

But since QVariant can be constructed from custom types via the fromValue 
template, you can use:

varMap.insert("key", QVariant::fromValue(subMap));

and now you can’t get it out as a QVariantMap anymore, and the code above will 
print “QMultMap”, like it should.

Volker


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

[Interest] Fwd: [Development] Qt TextToSpeech API review for Qt 6.6

[Volker Hilsheimer via Interest]

Cross-posting from the development list: anyone with an interest in Qt 
TextToSpeech is welcome to the API review session on Monday 22nd afternoon, 
16:00 Oslo time (CEST). Link to the MS Teams meeting, and to the new APIs we 
plan to have in Qt 6.6, below.

Volker


> On 13 May 2023, at 14:08, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> I’d be happy for comments and feedback to the C++ and QML APIs we added to 
> the Qt TextToSpeech module for Qt 6.6.
> 
> https://doc-snapshots.qt.io/qt6-dev/whatsnew66.html#qt-texttospeech-module
> https://doc-snapshots.qt.io/qt6-dev/newclasses66.html (new member function in 
> the QTextToSpeech class)
> 
> 
> Link to Microsoft Teams video meeting: 
> https://teams.microsoft.com/l/meetup-join/19%3ameeting_ODhiM2Q1ZGItODQ2Ny00ZjExLWI1YzMtOTM0MjEzNmNjNzdk%40thread.v2/0?context=%7b%22Tid%22%3a%2220d0b167-794d-448a-9d01-aaeccc1124ac%22%2c%22Oid%22%3a%22de5b241e-f1fd-4127-965f-ca90b3f70722%22%7d
> 
> If you have comments or improvement suggestions before, then you’re of course 
> welcome to share them here!
> 
> Cheers,
> Volker
> 
> -- 
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development


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

Re: [Interest] Qt 6.5 NOT supporting Dark mode on Windows

[Volker Hilsheimer via Interest]

On 2 Jun 2023, at 17:26, David C. Partridge  
wrote:

I am most unhappy to have to report that I  just had a bug report 
https://bugreports.qt.io/browse/QTBUG-112653 closed WON’T DO for a problem I 
reported with handling of Dark/Light mode switching.

The reason given was that Qt 6.5 won’t support Dark mode on Windows.

This seems more than a bit out of order given the fanfare about support of Dark 
Mode in Qt 6.5 in the announcement and the blog e.g.: 
here

David


Hi David,

We do support dark mode on Windows, but not if the native (UxTheme based) style 
is used as that style doesn’t use the palette to render controls, and instead 
relies on the UxTheme system library, which never provides dark-mode assets. 
That’s what Axel tried to communicate in the comment. As you are using Fusion 
as the application style, this limitation doesn’t apply to you, and you will 
get the dark palette in dark mode, and the light palette in light mode.

However, the signal you are handling gets emitted to inform clients that the 
system theme (as seen by the QStyleHints) has changed. The palette changes in 
response to that (often asynchronously, and after giving the current style a 
chance to polish and override the system palette). By the time the signal gets 
emitted, the palette is still the old one. This is by design - the theme 
changes, and the palette changes in response to it.

To do what you intend to do, handle the ApplicationPaletteChange event in your 
UI. You can then evaluate the value of QStyleHints::colorScheme API to decide 
how you want to modify your style sheet.

Volker

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

Re: [Interest] Void pointers for Mac ARM

[Volker Hilsheimer via Interest]

(bringing this back to the original thread rather than the digest)

On 20 Jun 2023, at 14:54, Turtle Creek Software  wrote:
On 19 Jun 2023, at 17:30, Thiago Macieira  wrote:

On Monday, 19 June 2023 04:13:51 PDT Turtle Creek Software wrote:
The debugger showed the correct address but failed to cast a
parameter.

Can the ARM compiler handle #pragma pack (2) ?

What does this have to do with casting? It would really help if you gave exact
error messages. That includes warnings about ignored / unrecognised pragmas.

Anyway, why do you want #pragma produce_slow_memory_accesses?



Our code has structs that were set up in 16-bit processor days, and it uses an 
object database library that probably started for 8-bit.  Most structs were 
easy to revise for 4 and 8 byte alignments, but some parse data from disk. 
Those are the ones that get #pragma pack (2).  Any speed hit is tiny compared 
to disk access time.

We still need those old structs for a one-time file conversion of user data 
that may date back to the 90s. The code reads old structs, then writes newer 
ones with modern alignment. Sometimes arrays of them.

It worked fine in Qt5.  In Qt6 for ARM, 2-byte aligned structs mostly work, but 
if they go through a void pointer they don't cast back properly.  No specific 
system error, just our code sanity-checking and reporting the nullptr.

There's only a few places where we use function pointers with void parameters.  
They are hard to debug so it's fine to rewrite the last of them.

But that database library also loses structs when coming back from (the) void. 
It also worked in Qt5, but breaks for Qt6 on ARM. Their code is a nightmare, 
and we only need it once to read old files.  A rewrite would take years.

Does that make sense?

We haven't built with Qt6 for Windows yet but will do that soon. It may help 
narrow down where the problem lies.


I’m trying to understand what the differences are between “works” and “doesn’t 
work”. You have both Qt 5 vs Qt 6, and you have Intel vs ARM macs. So far you 
are saying that it works with Qt 5 on Intel, and that it doesn’t work with Qt 6 
on ARM. Do things work with Qt 6 on Intel macs? Do things work with Qt 5 on 
ARM? Are you building with the same toolchain versions, or are the clang 
versions different?

You’re also saying that this is all plain C/C++ code.

I’m not quite seeing yet what role Qt is playing in this - and maybe it doesn’t 
have any, in which case it’s still fine to consult this mailing list of course, 
but it would help to get this clarified :)

Either way, it would perhaps help to boil all this down to some minimal code; 
you have a 2-byte aligned struct that you cast to and from void *, this should 
be reproducible with small bit of code. And if you have that, then comparing 
the assembly you get out of your compiler when targeting Intel vs ARM might 
give some hints.


Volker

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

Re: [Interest] The incredible shrinking dialogue

[Volker Hilsheimer via Interest]

On 13 Oct 2023, at 09:36, David C. Partridge  
wrote:

An application I own has a custom dual progress dialogue.It has worked 
without problem since 15.5 up until 6.5.1 inclusive.

If we build using 6.5.3 (or 6.6), and run the application, then when we 
minimise/restore the main window the dlg vertical size is reduced, clipping the 
content.  If you repeat the minimise/restore a couple of times, then all the is 
left of the dlg is the title bar.

We’re prepared for it to be our problem rather than a Qt problem, but haven’t 
any ideas on how to determine what’s causing this strange behaviour.

Suggestions of how we can debug this will be most welcome.  Trivial test cases 
don’t appear to show the problem.

Thanks, David


Hi David,

Which platform is this one, and what window flags are you using? Given that 
behavior changed between Qt releases, a JIRA ticket with the relevant details 
would be good.


Cheers,
Volker


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

Re: [Interest] QEvent::Quit vs. QEvent::Close

[Volker Hilsheimer via Interest]

> On 23 Oct 2023, at 22:30, Hamish Moffatt via Interest 
>  wrote:
> 
> On 24/10/23 06:10, Alexander Dyagilev wrote:
>> I would prefer for an additional event to be used when the user triggers 
>> Quit. E.g. something like QEvent::QuitByUser.
>> 
>> For now, it seems I will have to involve some additional ugly logics 
>> (something like setting a global variable) More code more complexity for 
>> such a simple situation. Not good, IMO. 
> 
> 
> Does QEvent::spontaneous() tell you anything about the two different quit 
> events?
> 
> Hamish



They should; the window system event is handled as a spontaneous event and 
should reach Q(Gui)Application::event with the spontaneous flag set; a call to 
Q(Core)Application::quit sends (or posts, depending on the thread) the event as 
a synthetic event to the qApp instance, so the spontaneous flag will not be set.

Volker

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

Re: [Interest] QEvent::Quit vs. QEvent::Close

[Volker Hilsheimer via Interest]

Indeed, you are right. I missed that QCoreApplicationPrivate::quit is virtual 
and overridden in QGuiApplicationPrivate to go through the QPA layer, which 
then looks for Qt like any other spontanous event. Created 
https://bugreports.qt.io/browse/QTBUG-118533

Not a high priority, as you can know when you call QApplication::quit() 
yourself, I suppose.

Volker


> On 24 Oct 2023, at 20:30, Alexander Dyagilev  wrote:
> 
> Hello,
> 
> No, it returns true always.
> 
> On 10/23/2023 11:30 PM, Hamish Moffatt via Interest wrote:
>> On 24/10/23 06:10, Alexander Dyagilev wrote:
>>> I would prefer for an additional event to be used when the user triggers 
>>> Quit. E.g. something like QEvent::QuitByUser.
>>> 
>>> For now, it seems I will have to involve some additional ugly logics 
>>> (something like setting a global variable) More code more complexity 
>>> for such a simple situation. Not good, IMO. 
>> 
>> 
>> Does QEvent::spontaneous() tell you anything about the two different quit 
>> events?
>> 
>> Hamish
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

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

Re: [Interest] QGraphicsView and OpenGL in Qt6

[Volker Hilsheimer via Interest]

Hi Calogero,

QGraphicsView is still supported, and, like all of Qt Widgets, is in no danger 
of being deprecated. If you think that you are experiencing a bug in Qt, please 
report as usual, with a reproducer that is ideally not your pretty complex 
application :)

Interesting information might be which platform you see this on, and whether 
you are running your UI on a display with a fractional scale level, as that 
might result in rounding errors in the integer-based painting architecture of 
Qt Widgets and QGraphicsView.

Volker


On 23 Nov 2023, at 16:28, Calogero Mauceri  wrote:

Hi Shawn,

Thanks for your exhaustive explanation.
As I mentioned the application is pretty complex, it is not only showing tiles 
but much more items the user can interact with. Reimplementing it would be a 
huge amount of work that would require too much time and resources and be bug 
prone.

I am looking for a fix/workaround with the current QGraphicsView, if there is 
one. If using OpenGL rendering is safe enough I'm OK in enabling it. The fact 
that Graphics View is not supported anymore (and possibly at risk of 
deprecation in future Qt releases) does not make me feel so good though.

On Thu, Nov 23, 2023 at 3:40 PM Shawn Rutledge via Interest 
mailto:interest@qt-project.org>> wrote:

On 23 Nov 2023, at 02:37, Calogero Mauceri 
mailto:mauc...@actgate.com>> 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&D 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

Re: [Interest] Item / Views: QLabel delegate

[Volker Hilsheimer via Interest]

Hi László,

On 2 Dec 2023, at 07:39, Tony Rietwyk  wrote:
On 2/12/2023 12:06 am, Laszlo Papp wrote:
Hi everyone,

I am not able to render a custom widget, like a QLabel in a QTreeView cell with 
a custom delegate. The delegate code is this:


[…]


But I am seeing my QTreeView cell empty instead of seeing the above "This a 
test message" in there. Do you know what I may be doing wrong?

I took this idea from here:
https://groups.google.com/g/python_inside_maya/c/FXB_V0llUpY/m/mpJOQkyJCgAJ


This is not only quite expensive (depending on how many delegates you plan to 
instantiate), you are also making a lot of assumptions about what the widget is 
doing. Ie. does the widget have a meaningful size? Has it laid out its content 
while it’s not visible (many widgets postpone heavy work until they get 
polished, just before being shown)? You can't know any of this, and even if 
things might happen to work with some widgets (or if you manage to make them 
work by some explicit event posting or processing) you shouldn’t rely on these 
behaviours. They are often implementation details and might change from one Qt 
version to the next.

In short: don’t use widgets as an off-screen component to render stuff.

What Justin on the Google group is suggesting as the first option, and what 
Tony is doing in his snippet below, is the correct way: use the QStyle API and 
QTextDocument to draw the various elements, and to calculate size requirements 
and such.


Hi Laslo,

In my delegate, I use a QTextDocument instead and I also override sizeHint:

void MessagesDelegate::paint(
QPainter *painter,
const QStyleOptionViewItem &option,
const QModelIndex &index) const
{
 QStyleOptionViewItem optionV4 = option;
 initStyleOption(&optionV4, index);
 QStyle *style = optionV4.widget ? optionV4.widget->style() : 
QApplication::style();
 QRect textRect = style->subElementRect(QStyle::SE_ItemViewItemText, &optionV4);
 // Draw the item without any text:
 style->drawPrimitive(QStyle::PE_PanelItemViewItem, &optionV4, painter, 
optionV4.widget);
 _doc.setTextWidth(-1);
 _doc.setHtml("This is a test message");
 QAbstractTextDocumentLayout::PaintContext ctx;
 ctx.palette = optionV4.palette;
 // TODO:  Change ctx.palette according to cell being disabled and/or selected.
 painter->save();
 painter->translate(textRect.topLeft());
 painter->setClipRect(textRect.translated(-textRect.topLeft()));
 doc.documentLayout()->draw(painter, ctx);
 painter->restore();
}


QSize MessagesDelegate::sizeHint(
const QStyleOptionViewItem& option,
const QModelIndex& index) const
{
 _doc.setTextWidth(-1);
 _doc.setHtml("This is a test message");
 return QSize(_doc.idealWidth(), _doc.size().height());
}


Sorry I can't release the full code as it does lots of other things like icon 
decoration role, clicking on links in the HTML, etc.

Hope that helps,

Tony


Best regards,

Volker

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

Re: [Interest] QGraphicsView and OpenGL in Qt6

[Volker Hilsheimer via Interest]

> On 30 Nov 2023, at 12:16, Filippo Rusconi via Interest 
>  wrote:
>> I know things change but after that little exercise I am not sure anyone
>> would ever convince me to try QML on the desktop again. Period. If QWidgets
>> goes away we would probably just move to another language all together
>> rather than try QML. QML on Phones and tablets? Sure. Go for it. Desktop,
>> stay away. Far Far away.
> 
> +1000
> 
> It is some time now that I feel like Qt going the Qml route in a preferred
> manner with respect to the QWidget route (more revenues, I guess). I hope I am
> wrong with this feeling. I would be terribly sorry to have to adopt a new
> library set for widgetry…



First of all: yes, we know that there is still a bit of a way to go before Qt 
Quick can support everything we want to be able to do on the desktop. What was 
broken or missing a few years ago might be available, or work better, today.

But QML vs C++ and Qt Quick vs Qt Widgets is not at all about revenue, it’s 
about technology.

QML is a better language for building UIs than C++.
And the modular, scene-graph based and hardware accelerated rendering 
architecture of Qt Quick is a better architecture than the comparatively 
monolithic, CPU-bound approach of Qt Widgets.

Of course, you might disagree with those statements. But if those two 
statements are true for mobile and embedded, then they are - in principle - 
also true for the desktop. Again, we know there’s work to be done to improve 
desktop-specific use cases.

So yes, our focus is on making Qt Quick better, and new UI solutions will be 
designed primarily for Qt Quick. But our focus is also on the technologies that 
allow mixing the two, so that you don’t have to pick one or the other. You can 
keep your widget code and add Qt Quick via QQuickWidget to it already today.

Volker


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

Re: [Interest] Qt uses fontconfig on Linux, but what about Windows?

[Volker Hilsheimer via Interest]

On 18 Dec 2023, at 11:20, Allan Sandfeld Jensen  wrote:
On Montag, 18. Dezember 2023 05:14:38 CET Thomas Larsen Wessel wrote:
So in short, if I want to find a generic way of getting / querying /
installing fonts across OS'es (including Windows), fontconfig is probably
not the way to go, though it may technically be possible.

Yeah, that is complicated. I think you can do it with Qt APIs, but I wouldn't
know how myself.


For getting/querying, QFontDatabase is your friend.

For installing a font: if it’s enough to add the font so that your application 
can use it, then QFontDatabase::addApplicationFont, with a font file you ship 
separately or as a resource.

There's no API in Qt to install a font file with the system. Your application 
might not have the privileges to do so, so if you need that, then you’d 
probably best do that as part of your installation routine.


Volker

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

[Interest] Binary Compatibility breakage in Qt Multimedia 6.7.0

[Volker Hilsheimer via Interest]

Hi,

I managed to break binary compatibility in the Qt Multimedia module of the 
6.7.0 release :(

https://bugreports.qt.io/browse/QTBUG-123997

TL;DR: Qt 6.7.1 will be binary compatible with older Qt 6 versions again, but 
you will have to rebuild code using QAudioSink or QAudioSource when moving from 
earlier releases to Qt 6.7.0, and also rebuild when moving from Qt 6.7.0 to Qt 
6.7.1. Qt 6.7.1 is as of now scheduled for 2nd half May [1], but we will 
reevaluate that given this breakage, depending on what other feedback we get to 
the Qt 6.7.0 release.

[1] https://wiki.qt.io/Qt_6.7_Release

The fix is in https://codereview.qt-project.org/c/qt/qtmultimedia/+/553006 
(merged into dev at time of writing, and on it’s way into the Qt 6.7 branch).

Some more details:

Qt namespaces are named “QtSomething”, and the QAudio namespace in Qt 
Multimedia is named inconsistently - `Q` instead of `Qt`. This became more 
obvious when we introduced a namespace QtVideo for video related stuff, so we 
wanted to fix that. This resulted in a change that unfortunately broke binary 
compatibility by changing the stateChanged() signal’s signature in both 
QAudioSink and QAudioSource. Qt 6.6 exports this symbol as 
`stateChanged(QAudio::State)`, while in Qt 6.7.0 it’s exported only as 
`stateChanged(QtAudio::State)`.

Unfortunately, adding the signal with the old signature back turned out to be 
impossible. We’d have to have two signals, 
`QAudioSource::stateChanged(QtAudio::State)` and 
`QAudioSource::stateChanged(QAudio::State)` exported as symbols. But we cannot 
have both signals in the API, as otherwise `&QAudioSource::stateChanged` would 
be ambiguous and break compilation. And if we export the old signal function as 
a symbol that is not exposed to the public API, then already compiled code 
making connections to the signal member function (using PMF syntax) will fail - 
they would still be different functions, after all.

Apologies for the inconvenience this causes. We are following up to make sure 
that the tests that we run regularly to verify binary compatibility catch this 
next time.

Volker

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

Re: [Interest] Update widget geometry BEFORE window shown

[Volker Hilsheimer via Interest]

On 24 May 2024, at 00:52, David M. Cotter  wrote:

I need to do something like this:

windowP->layout()->updateGeometry(); // causes all widget geometry to update
DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do 
something with the geometry of a widget (which must be up to date)
windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now based on 
the fact that we KNOW the geometry of one of the widgets BEFORE the window is 
shown
windowP->show(); // only NOW show the window, NOT before now

How do I do something like the first line? Cause all widget geometry 
(Recursively), to know / figure out its size AND position? And this BEFORE the 
window or any widget is “shown”  via the windowP->show() command?

Please don’t try to tell me to do it differently. If you don’ know how to 
answer it, please don’t chime in, thanks.

-Dave

Hi David,

QLayout::activate should do what you are looking for. And QLayout::sizeHint 
should give you the size the layout would the window to have. You might be able 
to just call windowP->sizeHint() though.

It might depend on what your various functions do, though. If any of them 
changes any widget’s content in such a way that the widget’s sizeHint would 
change (in which case that widget is supposed to call QWidget::updateGeometry, 
which posts a layout requests event), then you are back in some asynchronous 
situation where the processing of events will result in the layout activating 
again, after you showed the window. Forcing the processing of 
QEvent::LayoutRequest with QCoreApplication::sendPostedEvents before calling 
windowP->show() might help then. Or you can deactivate the layout, or give 
windowP a fixed size based on its sizeHint, when you are confident that future 
changes should be ignored.


Volker

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

Re: [Interest] QTableView Column Width and Headers

[Volker Hilsheimer via Interest]

On 24 May 2024, at 20:39, Michael Jackson  wrote:

I have a question about how the column widths of a QTableView are calculated? 
How can I have the QTableView set the column with “to contents” that includes 
the QHeader also? For example I have a QHeaderView with the first “section” 
that has text “This is a really really really long header”, but the actual data 
that is in the QTableView under that header are short values such as “100” or 
“2” or “1.231”. When the QTableView is rendered the the column with is only as 
wide as the QTableView. It is like the QHeaderView is not taken into account 
when calculating the width of the column.

This is with Qt 6.5.3 and 6.6.3.

--
Mike Jackson


Hi Mike,

you should be able to reimplement 
https://doc.qt.io/qt-6/qtableview.html#sizeHintForColumn and 
https://doc.qt.io/qt-6/qtableview.html#sizeHintForRow to take the 
https://doc.qt.io/qt-6/qheaderview.html#sectionSizeHint into account.

Cheers,
Volker


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

Re: [Interest] QAccessibleAnnouncementEvent on a non-object class

[Volker Hilsheimer via Interest]

I don’t think I understand the problem.

Are you not able to instantiate QAccessibleAnnouncementEvent because you are 
not in C++? Or do you not have access to Qt APIs?

If adding QAccessibleAnnouncementEvent::setMessage would help, then how do you 
get hold of the QAccessibleAnnouncementEvent instance to call that method on?


FWIW, QAccessibleAnnouncementEvent, is a new type in Qt 6.8, and we are still 
in beta, so if there’s anything missing from that class to make it usable, then 
there’s still time to add it.

Volker

 
> On 13 Jun 2024, at 12:28, Corentin Bacqué-cazenave  
> wrote:
> 
> Hi,
> yes, I understand, but in this case, how should we make to send a 
> notification from everywhere. In the project I'm contributing to, we have to 
> send notification for some events (E.G. by an user send a message, or when we 
> change the volume), so we have just a method to send a text to speech 
> message, but this method can be called from any object class.
> A solution could be to extern the QAccessibleAnnouncementEvent, but 
> unfortunately we don't have a setMessage method so we can't do this :(
> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission Cécité & 
> Co et Mandataire CNCPH à la commission Accessibilité Universelle - Fédé 100% 
> Handinamique
> Le 13/06/2024 à 12:14, Volker Hilsheimer a écrit :
>>> On 13 Jun 2024, at 11:48, Corentin Bacqué-cazenave via Interest 
>>>  wrote:
>>> 
>>> Hi,
>>> I'm trying to implement the new QAccessibleAnnouncementEvent in my project. 
>>> However, I have a class to hander some TTS functions, and this class is not 
>>> derived from QObject.
>>> Is there a way to use QAccessibleAnnouncementEvent to send a notification 
>>> to screenreaders without a QObject class? I saw we can also use a 
>>> QAccessibleInterface but it seams we also need a QObject for this.
>>> Does anyone have a solution?
>>> Thanks.
>>> -- 
>>> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission Cécité 
>>> & Co et Mandataire CNCPH à la commission Accessibilité Universelle - Fédé 
>>> 100% Handinamique
>>> 
>> Hi Corentin,
>> 
>> 
>> Qt's accessibility framework is based on a tree of QAcessibleInterfaces. For 
>> most cases, that tree mirrors the corresponding QObject trees. Only QObjects 
>> can respond to events (which is required to handle incoming calls), so an 
>> introspection through accessibility technology has to start with something 
>> that is a QObject (typically a widget).
>> 
>> But e.g. an item view’s items are not QObjects, so the implementation of 
>> QAccessibleInterface for an item view returns interfaces for items based on 
>> their position in the view. To raise an event for such an item, you have to 
>> get the interface for that item, and then you can construct a 
>> QAccessibleAnnouncementEvent with that interface.
>> 
>> Alternatively, if you have only one level of children and already have the 
>> QObject that they belong to, then you can create the event with the QObject, 
>> and the child index by calling QAccessibleEvent::setChild.
>> 
>> 
>> Volker
>> 
>> 
>> 

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

Re: [Interest] QAccessibleAnnouncementEvent on a non-object class

[Volker Hilsheimer via Interest]

> On 13 Jun 2024, at 11:48, Corentin Bacqué-cazenave via Interest 
>  wrote:
> 
> Hi,
> I'm trying to implement the new QAccessibleAnnouncementEvent in my project. 
> However, I have a class to hander some TTS functions, and this class is not 
> derived from QObject.
> Is there a way to use QAccessibleAnnouncementEvent to send a notification to 
> screenreaders without a QObject class? I saw we can also use a 
> QAccessibleInterface but it seams we also need a QObject for this.
> Does anyone have a solution?
> Thanks.
> -- 
> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission Cécité & 
> Co et Mandataire CNCPH à la commission Accessibilité Universelle - Fédé 100% 
> Handinamique

Hi Corentin,


Qt's accessibility framework is based on a tree of QAcessibleInterfaces. For 
most cases, that tree mirrors the corresponding QObject trees. Only QObjects 
can respond to events (which is required to handle incoming calls), so an 
introspection through accessibility technology has to start with something that 
is a QObject (typically a widget).

But e.g. an item view’s items are not QObjects, so the implementation of 
QAccessibleInterface for an item view returns interfaces for items based on 
their position in the view. To raise an event for such an item, you have to get 
the interface for that item, and then you can construct a 
QAccessibleAnnouncementEvent with that interface.

Alternatively, if you have only one level of children and already have the 
QObject that they belong to, then you can create the event with the QObject, 
and the child index by calling QAccessibleEvent::setChild.


Volker


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

Re: [Interest] QAccessibleAnnouncementEvent on a non-object class

[Volker Hilsheimer via Interest]

Your MainWindow::slotOnAnnouncement(const QString &msg)

does the right thing: create the event with the message string, and send it to 
the accessibility system via updateAccessibility(&event).

You can call that function from any code where you have access to your 
MainWindow instance; and you can add a second (possibly defaulted) “QObject *” 
parameter if other code needs that announcement to be made on behalf of other 
objects. Or you can just as well use those exact two lines of code anywhere 
else you need to make an announcement.

I don’t think keeping making the QAccessibleAnnouncementEvent object accessible 
for other code to modify it before you send it with updateAccessibility() would 
be an improvement.

Volker


> On 13 Jun 2024, at 13:32, Corentin Bacqué-cazenave  
> wrote:
> 
> My idea is to instantiate QAccessibleAnnouncementEvent in the main window 
> class of the app, and then exteren this instance to use in other class. Then, 
> we can just call the instance with setMessage.
> For now I tried to extern a QObject of my main window and use this object in 
> my non object class, but it seams to be not working.
> So, yes, probably add a setMessage method can help.
> If it can helps to understand what I'm trying to do, you can check here:
> WIP: Support Qt Accessibility Announcement for TTS events by CoBC · Pull 
> Request #2366 · BearWare/TeamTalk5 (github.com)
> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission Cécité & 
> Co et Mandataire CNCPH à la commission Accessibilité Universelle - Fédé 100% 
> Handinamique
> Le 13/06/2024 à 13:27, Volker Hilsheimer a écrit :
>> I don’t think I understand the problem.
>> 
>> Are you not able to instantiate QAccessibleAnnouncementEvent because you are 
>> not in C++? Or do you not have access to Qt APIs?
>> 
>> If adding QAccessibleAnnouncementEvent::setMessage would help, then how do 
>> you get hold of the QAccessibleAnnouncementEvent instance to call that 
>> method on?
>> 
>> 
>> FWIW, QAccessibleAnnouncementEvent, is a new type in Qt 6.8, and we are 
>> still in beta, so if there’s anything missing from that class to make it 
>> usable, then there’s still time to add it.
>> 
>> Volker
>> 
>> 
>> 
>>> On 13 Jun 2024, at 12:28, Corentin Bacqué-cazenave 
>>>  wrote:
>>> 
>>> Hi,
>>> yes, I understand, but in this case, how should we make to send a 
>>> notification from everywhere. In the project I'm contributing to, we have 
>>> to send notification for some events (E.G. by an user send a message, or 
>>> when we change the volume), so we have just a method to send a text to 
>>> speech message, but this method can be called from any object class.
>>> A solution could be to extern the QAccessibleAnnouncementEvent, but 
>>> unfortunately we don't have a setMessage method so we can't do this :(
>>> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission Cécité 
>>> & Co et Mandataire CNCPH à la commission Accessibilité Universelle - Fédé 
>>> 100% Handinamique
>>> Le 13/06/2024 à 12:14, Volker Hilsheimer a écrit :
>>> 
> On 13 Jun 2024, at 11:48, Corentin Bacqué-cazenave via Interest 
>  wrote:
> 
> Hi,
> I'm trying to implement the new QAccessibleAnnouncementEvent in my 
> project. However, I have a class to hander some TTS functions, and this 
> class is not derived from QObject.
> Is there a way to use QAccessibleAnnouncementEvent to send a notification 
> to screenreaders without a QObject class? I saw we can also use a 
> QAccessibleInterface but it seams we also need a QObject for this.
> Does anyone have a solution?
> Thanks.
> -- 
> Corentin : expert certifié 2022 et Sponsor NVDA, Référent commission 
> Cécité & Co et Mandataire CNCPH à la commission Accessibilité Universelle 
> - Fédé 100% Handinamique
> 
> 
 Hi Corentin,
 
 
 Qt's accessibility framework is based on a tree of QAcessibleInterfaces. 
 For most cases, that tree mirrors the corresponding QObject trees. Only 
 QObjects can respond to events (which is required to handle incoming 
 calls), so an introspection through accessibility technology has to start 
 with something that is a QObject (typically a widget).
 
 But e.g. an item view’s items are not QObjects, so the implementation of 
 QAccessibleInterface for an item view returns interfaces for items based 
 on their position in the view. To raise an event for such an item, you 
 have to get the interface for that item, and then you can construct a 
 QAccessibleAnnouncementEvent with that interface.
 
 Alternatively, if you have only one level of children and already have the 
 QObject that they belong to, then you can create the event with the 
 QObject, and the child index by calling QAccessibleEvent::setChild.
 
 
 Volker
 
 
 
 
>> 

___
Interest mailing list
Interest@qt-project.or

Re: [Interest] QMediaCaptureSession capture from QGraphicsScene?

[Volker Hilsheimer via Interest]

> On 19 Jun 2024, at 20:14, David M. Cotter  wrote:
> 
> If i have a QGraphicsScene (not necessarily connected to a view, or if 
> required, an OFFSCREEN view), can i set its output as the input to a 
> QMediaCaptureSession?
> I see i can connect a QWindowCapture, but must that window be showing? can 
> that window be invisible? eg: h.264 output in the background, unrelated to 
> the showing (visible) windows?
> I had asked this question a couple years ago, but times have changed and i 
> wonder if it is now possible?
> if it is not possible from QGraphicsScene directly, then how about a 
> temporary buffer of QImage? Can i feed QMediaCaptureSession a QImageCapture 
> class, then feed the QImageCapture class a series of QImage or QVideoFrame 
> refs?
> is there sample code for sending in-memory images into QMediaCaptureSession ?
> 
> -Dave


Hi Dave,

Forwarding Artem’s reply (which went to development@):


Thanks for the questions! 

In 6.8, we added QVideoFramesInput, and QAudioBufferInput, which can be 
connected toQMediaCaptureSession as inputs.
Let's go through the questions.

>  If i have a QGraphicsScene (not necessarily connected to a view, or if 
> required, an OFFSCREEN view), can i set its output as the input to a 
> QMediaCaptureSession?

You cannot set QGraphicsScene as an input to QMediaCaptureSession. Instead, you 
may render QGraphicsScene to QImage, construct QVideoFrame from the image, and 
send your sequence of images to QVideoFrameInput, connected to 
QMediaCaptureSession.


> I see i can connect a QWindowCapture, but must that window be showing? can 
> that window be invisible? eg: h.264 output in the background, unrelated to 
> the showing (visible) windows?

It’s platform-dependent. E.g. on Windows, we cannot capture invisible windows. 
On other platforms, it’s to be double-checked and documented, the ticket is 
https://bugreports.qt.io/browse/QTBUG-126552. 
In general, the result of QWindowCapture::capturableWindows is designed to 
represent the windows we can capture. If the list contains an invisible window 
that QtMM cannot capture, a ticket might be reported.


> if it is not possible from QGraphicsScene directly, then how about a 
> temporary buffer of QImage? Can i feed QMediaCaptureSession a QImageCapture 
> class, then feed the QImageCapture class a series of QImage or QVideoFrame 
> refs?

QImageCapture is rather an output for capturing image shots from cameras, 
screens, windows, so it doesn’t cover your needs. Please use QVideoFrameInput. 
In 6.8, you may create video frames from QImage or from your custom data via 
QAbstractVideoBuffer, see the constructors of QVideoFrame.


> is there sample code for sending in-memory images into QMediaCaptureSession ?


There are no code samples in the public documentation yet. We have a ticket for 
writing them:https://bugreports.qt.io/browse/QTBUG-126319.
Until we add the snippets or examples, you may take a look at the tests:
An early tests revision with a straight-forward flow.
The current tests revision is a bit harder to learn from. 



Regards
Artem


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

Re: [Interest] Support of ChromeOS

[Volker Hilsheimer via Interest]

> On 24 Jun 2024, at 14:21, A. Klitzing  wrote:
> 
> Hi there!
> 
> The list of supported platforms [1] shows that Qt does not officially
> supports ChromeOS. We tried our Qt application for Android on ChromeOS
> and found that it works good with some rough edges here and there.
> 
> Is it planed to support ChromeOS someday or accept bug reports for
> Android applications on ChromeOS?
> 
> Best regards André Klitzing
> 
> [1] https://doc.qt.io/qt-6/supported-platforms.html


Hi André,


I’m not aware of any plans from the Qt Group to invest into building CI or 
software engineering capacity into supporting ChromeOS.

But if this is an important platform for your product, then you can of course 
contribute at least with the latter, and perhaps set up a test environment to 
verify those modules that are relevant for you. We run CI tests on Android 
through the emulator, and only release smoke-testing on device; so 
theoretically, the plumbing in the Qt build system should just work if your 
emulator has a ChromeOS image.

And you can of course file bug reports, but they might only get attention if 
the issue is reproducible on regular Android as well.


Cheers,
Volker


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

Re: [Interest] Qt 6.8.0 Win: no longer links to MFC ?

[Volker Hilsheimer via Interest]

Qt has never linked to MFC.

Perhaps with VS2022, the path to relevant headers and libraries is no longer 
implicitly added to the INCLUDE and LIB environment variables.

Volker


> On 2 Jul 2024, at 07:56, Axel Spoerl via Interest  
> wrote:
> 
> Good morning David,
> 
> the problem doesn't reproduce on a fresh Windows VM with VS 2022 installed 
> from scratch.
> As you report to have used VS 2019 until recently, a build tools version 
> mismatch comes to mind.
> 
> Latest build tools can be downloaded 
> here:https://aka.ms/vs/17/release/vs_BuildTools.exe
> 
> When escalating a Qt Forum thread to the mailing list, please add a reference 
> to the thread in your e-mail.
> Saves the time of everyone involved.
> 
> https://forum.qt.io/topic/157515/qt-6-8-0-upgrade-windows-no-longer-links-to-mfc
> 
> Cheers
> Axel
> 
> 
> Von: Interest  im Auftrag von David M. 
> Cotter 
> Gesendet: Dienstag, 2. Juli 2024 04:55
> An: interest@qt-project.org Interest 
> Betreff: [Interest] Qt 6.8.0 Win: no longer links to MFC ?
>  On Windows, using Qt 6.7.1 (with VS2019), in my project I was able to do this
> > #include  // MFC core and standard components
> 
> and that header would be "found" by the compiler, and the linker would link 
> to mfc140u(d).lib just fine.
> BUT: When i upgraded to Qt 6.8.0, (meaning i had to upgrade to VS2022), now 
> the compiler is no longer able to "find" afxwin.h, nor link to MFC.  ??!?
> 
> Okay, so, if i now add these lines to my .pro file:
> 
> > versionAtLeast(QT_VERSION, 6.8.0) {
> >DIR_ALTMFC = C:\Program Files\Microsoft Visual 
> > Studio\2022\Community\VC\Tools\MSVC\14.29.30133\atlmfc\
> > 
> >INCLUDEPATH += $${ALTMFC_PATH}include
> >LIBS += -L$${ALTMFC_PATH}lib\x64 -lmfc140ud
> > }
> 
> It will now compile (ie: it FINDS the header file) but it still won't link, 
> says:
> > LINK1104: cannot open file 'mfc140ud.lib'
> 
> note that the LIBS path definitely HAS that .lib file RIGHT THERE:
> <6255a32a-a8ba-4aa4-b20b-c2999304f1b9.png>
> 
> Why did it work without effort in VS2019, but just utterly fails regardless 
> of my solution attempts, with vs2022 ??!?
> why should i have to specify the paths and lib at all? i didn't have to do 
> that when i was on VS2019 ??
> 
> anyone know what's going on here?
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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