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

[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 `::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] 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

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] 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 ,
const QModelIndex ) const
{
 QStyleOptionViewItem optionV4 = option;
 initStyleOption(, index);
 QStyle *style = optionV4.widget ? optionV4.widget->style() : 
QApplication::style();
 QRect textRect = style->subElementRect(QStyle::SE_ItemViewItemText, );
 // Draw the item without any text:
 style->drawPrimitive(QStyle::PE_PanelItemViewItem, , 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]

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

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

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

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

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]

> 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] Convert to QMetaMethod from QObject + const char *

[Volker Hilsheimer]

> On 16 Aug 2022, at 22:39, Scott Bloom  wrote:
> 
> I have a function that takes in a QObject and const char * signal/slot
>  
> void func( …, QObject * target, const char * member )
> {
> …. logic
> QObject::connect( ….., target, member )
> … more logic
> {
>  
>  
> So I can call it via
>  
> ….
> func( …., m_target, SLOT(  )
> …
>  
> it works fine
>  
> I would like to modify the function so it can also take
>  
> func( …., m_target, :: 
>  
> 
> however, I cant for the life of me figure out to convert, if its even possible
>  
> Id prefer not to have to copy all the logic in func
>  
> Is this possible?
> 
> Yes, I know I can use std::enable_if, but that just copies the function logic
> 
> Thanks
> Scott


Check QHostInfo::lookupHost for a Qt API that does that. It relies on private 
Qt APIs though.

There might be C++17-ways to simplify some of that using `if constexpr`, but 
the basics will probably be the same.

Volker

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

Re: [Interest] Proper way to track mouse leaving a widgets boundary

[Volker Hilsheimer]

> On 16 Aug 2022, at 18:45, Scott Bloom  wrote:
> 
> I have a QTextEdit derived class, that sets setMouseTracking( true ) in the 
> constructor.  Note, this isn’t about QTextEdit and should I use QTextBrowser. 
>  Ive had this issue multiple times over the last 20 years of Qt development, 
> and the solution has always been the same and I am not convinced it’s the 
> correct way.
>  
> When there is a mouseMoveEvent in which the anchor at the mouse position is 
> not empty, I override the cursor.
>  
> When the anchor at the point is empty, I restore the cursor
>  
> On mouseReleaseEvent I open the URL from the anchor.  
> 
> All works great (yes I know QTextBrowser should be able to be used, but there 
> are some issues with that, and its not the issue)
>  
> The problem is, when the mouse leaves the widget there isn’t a 
> “mouseLeaveEvent” so if the mouse is able to leave with the cursor 
> overridden, it stays overridden.
>  
> The workaround, I added a eventFilter on the parent widget.  If the parent 
> widget receives any event and the globalPos of the cursor (using 
> QCursor::pos() ) is outside the widget its restores the cursor.  It works, 
> however it seems a bit hackish
>  
> What is the “proper” methodology for tracking when a mouse leaves the widget? 
> Ive tried various methods through the years, and this is the way that I find 
> works
>  
> Full source for the widget can be found here
> https://github.com/towel42-com/SABUtils/blob/trunk/HyperLinkLineEdit.cpp
> https://github.com/towel42-com/SABUtils/blob/trunk/HyperLinkLineEdit.h
>  
> Thanks.
> 
> Scott


Hey Scott,

This should be a job for a QWidget::leaveEvent override:

https://doc.qt.io/qt-6/qwidget.html#leaveEvent


Volker

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

Re: [Interest] Anyway to tell if a QModelIndex's data will be displayed with an elide?

[Volker Hilsheimer]

> On 2 Jun 2022, at 19:31, Scott Bloom  wrote:
> 
> I have a request, to open a dialog without out any eliding, which is easy 
> enough to do via the views textElideMode.
>  
> So I can resize all the columns to fit, pretty straight forward, if I don’t 
> set the textElideMode
>  
> However, they also want no the data to be full visible, and not have to 
> resize the dialog/scroll. 
>  
> However, I cant seem to find a proper “this is the size the treeview (though 
> the same issue exists for any abstractview) minimum size hnt that wont 
> require scrollbars.
>  
> Am I missing something obvious? (I must be)
> 
> Scott


There is no need for QTreeView to calculate a sizeHint for the entire tree, 
because, well, it is a scrollview :) And calculating a sizeHint would also mean 
that the view has to update layouts when data that influences the sizeHint 
changes, and that would be quite expensive (the view does have to do at least 
some of that anyway to adjust the scrollbars, but since scrolling is “per row” 
rather than “per pixel”, we can optimize that a lot; see 
QTreeViewPrivate::updateScrollBars()).

I think the best you can do is to get the visualRect of the last index, and 
then calculate the view’s sizeHint based on that. That means that the tree has 
to be fully expanded.


Volker

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

Re: [Interest] Change modifier for horizontal scrolling with mousewheel

[Volker Hilsheimer]

> On 20 May 2022, at 21:05, Thorsten Glaser  wrote:
> 
> On Fri, 20 May 2022, Volker Hilsheimer wrote:
> 
>> sending a synthesized wheel event with the Alt modifier set to the
>> QWidget will not trigger this behavior, as that never exercises that
> 
> Hmm. I’m on a laptop without scroll wheel, so I bound two keys
> to emulate a mouse wheel:
> 
> https://musescore.org/en/node/165936#comment-1043340
> 
> Does this mean that synthetisising those events would also not work?


That synthesization happens on X11 level, before Qt sees the event in 
QXcbConnection::xi2HandleScrollEvent (or, if no XInput I suppose, in 
QXcbWindow::handleButtonPressEvent).

> (I have not tried; I didn’t know that Alt+scroll scrolls horizontally
> for Qt — that being said, which Alt… I use Alt to enter umlauts… so I
> hope this works with Alt_L as defined by xmodmap(1), not by Alt as on
> the physical keyboard / scancodes…)

Only one way to find out :)

Volker


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

Re: [Interest] Change modifier for horizontal scrolling with mousewheel

[Volker Hilsheimer]

> On 20 May 2022, at 17:26, Sean Murphy via Interest  
> wrote:
> 
> The subject mostly says it all - is there a way to change the modifier used 
> to allow horizontal scrolling with mousewheel?
> 
> By default it appears that Alt + mousewheel in a QScrollArea (and 
> QGraphicsView, etc.) scrolls horizontally, but I have a user that wants that 
> to be Shift + mouse wheel instead... Fine, I'll add some settings in my 
> Options dialog to allow users to customize which key modifiers do what, but 
> then I need to make it happen.
> 
> I think I can accomplish this by adding an event filter. The issue I see is 
> that the existing Alt + mousewheel behaves just like I want - scroll 
> direction sense is the way I want it, scroll size seems sensible for a single 
> mouse wheel bump, and I don't see anywhere in the API where I can query what 
> that scroll step size is to duplicate it.
> 
> Any tips/tricks? Ideally, could I just trap the users actual event, but then 
> turn around and send an Alt+mousewheel event to the widget? That way I get 
> the default scrolling behavior, but I'm just inserting a custom modifier 
> layer over the top?
> 
> Sean

Hi Sean,

The Alt modifier key being pressed while wheeling gets interpreted very far 
down in the Qt stack, when our various QPA plugins translate the native event 
into what ultimately becomes a QWheelEvent. Simply sending a synthesized wheel 
event with the Alt modifier set to the QWidget will not trigger this behavior, 
as that never exercises that QPA code.

What QAbstractScrollArea does by default is that it checks whether the 
angleDelta of the wheel event is mostly in the x- or mostly in the y-direction, 
and then sends the wheel event on to the respective scrollbar:


void QAbstractScrollArea::wheelEvent(QWheelEvent *e)
{
Q_D(QAbstractScrollArea);
if (qAbs(e->angleDelta().x()) > qAbs(e->angleDelta().y()))
QCoreApplication::sendEvent(d->hbar, e);
else
QCoreApplication::sendEvent(d->vbar, e);
}


So, in subclasses of your QAbstractScrollArea widgets you could check whether 
the Shift key is pressed, and then construct a QWheelEvent into which you copy 
all the attributes from the original event, but transpose the angleDelta. Then 
send that event to the respective scroll bar (shift held while angleDelta.y > 
angleDelta.x -> horizontal scroll bar). Remember to accept/ignore the original 
event based on how your synthesized event came back (calling 
QEvent::setAccepted/isAccepted).

If you want to also disable the Alt modifier’s effect, then things get a bit 
trickier (if Alt is held, assume that the original event is flipped, so unflip 
it).

If you want this to be the UX for all your QAbstractScrollArea widgets, then 
you can install an event filter on the viewport of all of them. You could also 
try to override QApplication::notify, and call the parent class implementation 
with your flipped QWheelEvent. In that case, only apply your logic if the 
original event has the QEvent::spontaneous bit set. However, that will then 
also impact widgets such as a tab bar or a spinbox unless you use qobject_cast 
to verify that the receiver’s parent is a QAbstractScrollArea.

Lastly, you probably don’t want to do any of this when the original wheel event 
comes from a kinetic scrolling device (like a track pad), so check 
QWheelEvent::phase and only do this when it’s Qt::NoScrollPhase.

Volker

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

Thanks for a lot of good replies and input to this thread. I’m taking the 
liberty to summarise a bit what I have read, especially from those of you who 
would like to contribute, but have given reasons why you don’t.

Starting with the things that I or we can and should do something about.


1) Difficult contribution process

> * Overly difficult to setup all the needed accounts, git pulls, PRs, Gerrit 
> review processes.

> Unfortunately the process of contributing code to the project feels only a 
> little bit better than eating glass.


I agree that it is a steep learning curve. The pay-off compared to simple PR’s 
using github workflows isn’t always clear, and doesn’t manifest at all for 
casual contributors. Honestly, I hated the process in the beginning, and I’m 
still not at ease with it. I’m always reminded of how complex it is when we 
onboard new people in The Qt Company. git is a complex tool as it is, adding 
the gerrit-specifics makes it really painful unless you have a ton of scripts, 
which then just add to the cognitive overload. The repository structure adds 
more complexity.

I’m sure the documentation isn’t as good as it could be, and perhaps some 
tooling to get started could help lower some of those bars. But in the end: it 
shouldn’t be that hard.

Would it help if we’d accept PRs through the GitHub mirrors? We’d need to 
integrate the CLA workflow into github (see CLA point further down), and 
perhaps implement some integrated review process, but perhaps this can be 
solved.


2) Access to cross-platform testing systems

> * Ensuring it works cross platform when most may not have access to all of 
> the needed testing systems.

First of all, you can’t break anything; our CI system, as challenged as it is 
these days to keep up with the workload, will test your changes on all relevant 
platforms. But I agree that throwing stuff at CI just to see if it builds is 
not a great way of developing software.

Would it help if we would make readily provisioned VMs or docker images (where 
applicable) available? Perhaps as an AMI in AWS (which then takes care of e.g. 
Windows or macOS licensing)? Or at least scripts or Ansible playbooks or 
equivalent stuff that you can run locally to install the tools and dependencies?

If you think this would help, then I might have a solution for you in a bit.


3) Priorities

> * My bugs probably may not align with TQtC priorities
> * An "apparent" lack of interest from Qt in QML for the desktop makes me 
> think "why would i care?"


If you are making a contribution that improves Qt on the desktop (which is what 
this thread is all about), then there are plenty of approvers in the Open 
Source community outside of The Qt Company, and there are plenty of people 
inside that would be happy to work with you as well. TQtC priorities define 
what TQtC employees will spend the majority of their time on; they don’t have 
to be your priorities, and just because your ideas don’t match TQtC’s strategy 
doesn’t invalidate your ideas. Btw, Qt Creator, Qt Design Studio, or Squish are 
desktop applications as well.

Of course, not every idea that comes in via code review or JIRA ticket fits the 
Qt project. But an improvement to widgets or Quick on the desktop will 
generally have my attention.


4) Difficult to find reviewers

> * Finding time in my own schedule to match up with time from a Qt engineers 
> schedule.
> * Nobody looks at contributions


Knowing who might be interested in your change takes a bit of effort, following 
the project, seeing who is active in which area. Getting support for your ideas 
requires an investment and some convincing of people.

The list of maintainers is long, and some of the people on the list haven’t 
been active in the project for a while. The quality of the channels we as a 
community have to find people to help out with code reviews is, frankly, 
sub-par. And on those channels we do have (and that I’m on) there don’t seem to 
be a lot of people looking for reviewers.

Use what we have (perhaps an email to developm...@qt-project.org). And if you 
have improvements to widgets or to Quick Controls, especially on the desktop, 
then I will be very interested in your patches.


5) Writing tests

> * Writing a unit test is always a blast. Again, time waiting for a code 
> review.


While we can all agree that the ideal way of writing code or fixing bugs is to 
do that together with a automated test case, it’s sometimes simply too 
challenging, especially for a casual contributor. Finding someone to work with 
and get support from is not always easy. I personally enjoy writing tests, and 
even if I don’t always have time to do so myself I at least enjoy discussing 
how a test could be written for those areas in Qt that I’m familiar with. I 
know that many of my colleagues feel the same.

So again, if you have something that makes widgets or Quick on the desktop 
better, then add me as a reviewer.



6) Code complexity and lack of 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

Of course; I think there are a number of developers here that use Qt under an 
Open Source license though, and perhaps even a few that, while having various 
reasons not to use Qt under an Open Source license, still wouldn't mind 
contributing with patches.


Volker


> On 24 Feb 2022, at 17:17, Nelson, Michael via Interest 
>  wrote:
> 
> A fair question perhaps for OSS community but many on this list pay for 
> licensing and support precisely because we don't have time to fix everything 
> ourselves.
> 
> MIke
> 
> 
> Confidential - Company Proprietary
> 
> -Original Message-
> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Thursday, February 24, 2022 10:39 AM
> To: Qt Interest 
> Subject: Re: [Interest] Is there a good alternative to the QML Controls in 
> Qt6 for native desktop integration purposes?
> 
>> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
>>>> On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
>>>> Hi,
>>>> 
>>>> I'm facing so many bugs in QML Controls in Qt6 (they used to be
>>>> Controls V2 in the Qt 5.x
>>>> days) that I don't want to use them at all anymore. They are bugged
>>>> beyond repair and downright unusable for native desktop integration 
>>>> purposes.
>>>> 
>>>> Is there another good open source component set out there that
>>>> integrates with the desktop. Specifically with Windows but preferably also 
>>>> with Linux (kde and gnome) and Mac.
>>>> 
>>>> Using QWidgets should not be an alternative as it slows down
>>>> development a lot. But given the crap that QML Controls is makes me 
>>>> consider switching to QWidgets instead.
>>> 
>>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>>  wrote:
>>> Hi,
>>> 
>>> QML is nice for basic applications but widgets is important for
>>> professional, technical and high-density applications.
>>> 
>>> But that doesn't matter. From my point of view Qt stopped being
>>> developed as a desktop framework a long time ago. Other industries seems to 
>>> have priority now.
>> 
>> Well, it was nearly good enough in the Qt5 days with Controls V1.
>> All they needed was a better set of controls to accommodate mobile more and 
>> reduce complexity in V1.
>> 
>> What they did - conceptually - with V2 was good.
>> But it seems like they just left it in alpha quality and call it "ok" to 
>> replace V1.. That was a mistake.
>> It needed much more development time to be a proper replacement.
>> 
>> We're now like ~8 years past the introduction of the V2 set...
>> And it still has really severe bugs that just interrupt usability. 8 years...
>> So I doubt it will be getting any better at all.
>> 
> 
> 
> Hi All,
> 
> Thanks for keeping it civilised.
> 
> Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
> originally designed for mobile and embedded platforms, and indeed, that shows 
> when using them for the desktop.
> 
> I’m happy that at least in The Qt Company we are now in a position that 
> allows us to put more focus on the desktop, and that we are are able to do 
> more than maintenance and catching up with what’s happening on the underlying 
> platforms. That includes the journey of making Qt Quick Controls a great 
> toolkit for the desktop as well. In Qt 6 so far we have had first 
> implementations of the native styles - yes, those require more work; we have 
> made a number of improvements to item views, including a TreeView now in Qt 
> 6.3; a first set of standard dialogs is in Qt 6.2 and more are coming in 6.3. 
> We have worked on some architectural issues that are problematic on the 
> desktop, such as keyboard navigation and focus handling, and there is a fair 
> amount of more work needed there as well.
> 
> I’m not going to claim that all things will be wonderful any moment now; 
> there’s plenty of work that needs to be done. But things do get better, both 
> with Qt Quick Controls, and with Qt Widgets as well.
> 
> What keeps confusing me personally is how few people in the community seem to 
> find it interesting to contribute to either of our UI frameworks in Qt. If I 
> take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 
> 12 years old, has 47 votes”. I sat down on Tuesday evening to check what it 
> would take to implement hiding of rows in a QFormLayout; after a few hours I 
> had a working implementation, which is right now on its way into the dev 
> branch. The hardest part, as it so often is, was writ

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
>>> On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
>>> Hi,
>>> 
>>> I'm facing so many bugs in QML Controls in Qt6 (they used to be Controls V2 
>>> in the Qt 5.x
>>> days) that I don't want to use them at all anymore. They are bugged beyond 
>>> repair and
>>> downright unusable for native desktop integration purposes.
>>> 
>>> Is there another good open source component set out there that integrates 
>>> with the
>>> desktop. Specifically with Windows but preferably also with Linux (kde and 
>>> gnome) and Mac.
>>> 
>>> Using QWidgets should not be an alternative as it slows down development a 
>>> lot. But given
>>> the crap that QML Controls is makes me consider switching to QWidgets 
>>> instead.
>> 
>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>  wrote:
>> Hi,
>> 
>> QML is nice for basic applications but widgets is important for 
>> professional, technical
>> and high-density applications. 
>> 
>> But that doesn't matter. From my point of view Qt stopped being developed as 
>> a desktop
>> framework a long time ago. Other industries seems to have priority now.
> 
> Well, it was nearly good enough in the Qt5 days with Controls V1.
> All they needed was a better set of controls to accommodate mobile more and 
> reduce complexity in V1.
> 
> What they did - conceptually - with V2 was good.
> But it seems like they just left it in alpha quality and call it "ok" to 
> replace V1.. That was a mistake.
> It needed much more development time to be a proper replacement.
> 
> We're now like ~8 years past the introduction of the V2 set...
> And it still has really severe bugs that just interrupt usability. 8 years...
> So I doubt it will be getting any better at all.
> 


Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that allows 
us to put more focus on the desktop, and that we are are able to do more than 
maintenance and catching up with what’s happening on the underlying platforms. 
That includes the journey of making Qt Quick Controls a great toolkit for the 
desktop as well. In Qt 6 so far we have had first implementations of the native 
styles - yes, those require more work; we have made a number of improvements to 
item views, including a TreeView now in Qt 6.3; a first set of standard dialogs 
is in Qt 6.2 and more are coming in 6.3. We have worked on some architectural 
issues that are problematic on the desktop, such as keyboard navigation and 
focus handling, and there is a fair amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem to 
find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing on a 
Tuesday evening. But given the apparently high interest in this feature, that 
nobody seems to have tried to give it a shot in 12 years is really puzzling me. 
When Nokia acquired Trolltech, it didn’t take a crystal ball to see that the 
focus won’t be the desktop. And one answer to this was to move Qt under Open 
Governance so that anyone could contribute to Qt and make sure that it stays 
awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt on 
the desktop to participate in the discussion. And I suppose most of us on this 
list are software engineers, many perhaps for more reasons than to put food on 
the table. My question to you is: how can we make it easier, or more fun, or 
more motivating to contribute to Qt, and to help with making things better?


Volker


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

Re: [Interest] License for Qt6 QtMultimedia module (LGPL?)

[Volker Hilsheimer]

> On 16 Feb 2022, at 09:50, Mike Krus via Interest  
> wrote:
> 
> Hi
> 
> I thought qtshadertools had been relicensed as LGPL for 6.3?
> 
> 
> Mike


That is correct as of:

https://codereview.qt-project.org/c/qt/qtshadertools/+/382923

And it’s also correct that as long as the QtShaderTools is only used as a build 
tool (as done with qtmultimedia), the fact that it’s not LGPL’ed doesn’t matter.

That we have LGPL’ed the module now with Qt 6.3 opens up possibilities to use 
some of that code at runtime. But note that as of now, there are no public APIs 
in the Qt ShaderTools module.

Volker



>> On 15 Feb 2022, at 18:27, Adam Light  wrote:
>> 
>> 
>> 
>> On Tue, Feb 15, 2022 at 10:20 AM Alexey Edelev  wrote:
>> Shadertools module provides an executable that is used by multimedia at 
>> build time only. So there is no runtime dependencies between qtmultimedia 
>> and shadertools, so that's the key, I guess.
>> 
>> OK, that makes sense. Thanks.
>> 
>> Adam 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 
> —
> Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead
> KDAB (UK) Ltd., a KDAB Group company
> Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
> KDAB - The Qt Experts, C++, OpenGL Experts
> 
> 
> ___
> 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] Build Issues with QT 6.2.3

[Volker Hilsheimer]

These are not work arounds, but documented features of ninja :P

I’m not going to reopen the thread from three years ago when the choice of 
build system was made, but that the qmake build system was not sustainable, at 
the very least not for Qt itself, was fairly undisputed.

Back in the days you did

$ cd buildtree
$ ../sourcetree/configure -redo
$ make -j14

and now you can either do

$ cd buildtree
$ ../sourcetree/configure -redo
$ ninja -j14

or, if you configured your build with the Makefile generator,

$ cd buildtree
$ ../sourcetree/configure -redo
$ make -j14


So think about cmake as a replacement for qmake; you didn’t build Qt with 
qmake, you built it with make (or perhaps in Visual Studio or Xcode using the 
respective generators). And you can build Qt with make today if you want (but 
we don’t test the Makefile generator). If you don’t care much for cmake, you 
don’t have to do anything with it to configure and build Qt from source.


Volker



> On 6 Feb 2022, at 16:22, BeneschTech LLC  wrote:
> 
> So you guys put in a work around cmake as well...
> 
> Ill be happy to compile the changes needed once I get linguist building. Just 
> curious why the change? Is there a benefit to these tools?
> 
> On Sun, Feb 6, 2022, 7:59 AM Volker Hilsheimer  
> wrote:
> > On 6 Feb 2022, at 15:37, BeneschTech LLC  wrote:
> > 
> > Thanks! I dont like ruby either lol. I found two more files that broke as 
> > well the fixes were trivial. Havent tried to fix linguist yet.
> > 
> > I have three big problems with the cmake and ninja combo:
> > 1. Ninja uses all the cpu cores +1 by default. Unless you have a water 
> > cooled system you will overheat on a 30k file build like this.
> 
> You can pass -j x to ninja to limit the number of parallel jobs, e.g.
> 
> $ ninja -j 6
> 
> or more flexibly
> 
> $ ninja -j $(( $(nproc) - 2 ))
> 
> 
> > 2 . Cmake does not store your last configuration command anywhere i can 
> > find like autotools does.
> 
> 
> Assuming that your issues are mostly with building Qt (because you’re 
> probably not using cmake for your own project), the Qt configure script does 
> still save the command options, so “configure -redo” will work as before.
> 
> 
> > 3 . During the build you can not see the flags being passed to the 
> > compiler. If you have an odd configuration like I do where I use clangs 
> > polly extension theres no easy way to see that its being used correctly.
> 
> Have you tried 
> 
> $ ninja -v
> 
> ?
> 
> > Qt itself is wonderful well written software and ive only ever encountered 
> > issues with third party code. Indulge us old guys though. We have reasons 
> > we like traditional make and autotools.
> 
> 
> Cheers,
> Volker
> 
> 
> 
> > On Sun, Feb 6, 2022, 7:22 AM Bob Hood  wrote:
> > On 2/5/2022 4:15 PM, BeneschTech LLC wrote:
> > > I have to say, not thrilled with the change to cmake/ninja, but maybe I'm 
> > > just old and not "cool" LOL.
> > 
> > You're not alone.
> > 
> > ___
> > 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] Build Issues with QT 6.2.3

[Volker Hilsheimer]

> On 6 Feb 2022, at 15:37, BeneschTech LLC  wrote:
> 
> Thanks! I dont like ruby either lol. I found two more files that broke as 
> well the fixes were trivial. Havent tried to fix linguist yet.
> 
> I have three big problems with the cmake and ninja combo:
> 1. Ninja uses all the cpu cores +1 by default. Unless you have a water cooled 
> system you will overheat on a 30k file build like this.

You can pass -j x to ninja to limit the number of parallel jobs, e.g.

$ ninja -j 6

or more flexibly

$ ninja -j $(( $(nproc) - 2 ))


> 2 . Cmake does not store your last configuration command anywhere i can find 
> like autotools does.


Assuming that your issues are mostly with building Qt (because you’re probably 
not using cmake for your own project), the Qt configure script does still save 
the command options, so “configure -redo” will work as before.


> 3 . During the build you can not see the flags being passed to the compiler. 
> If you have an odd configuration like I do where I use clangs polly extension 
> theres no easy way to see that its being used correctly.

Have you tried 

$ ninja -v

?

> Qt itself is wonderful well written software and ive only ever encountered 
> issues with third party code. Indulge us old guys though. We have reasons we 
> like traditional make and autotools.


Cheers,
Volker



> On Sun, Feb 6, 2022, 7:22 AM Bob Hood  wrote:
> On 2/5/2022 4:15 PM, BeneschTech LLC wrote:
> > I have to say, not thrilled with the change to cmake/ninja, but maybe I'm 
> > just old and not "cool" LOL.
> 
> You're not alone.
> 
> ___
> 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] QTextLayout::setPreeditArea()

[Volker Hilsheimer]

> On 4 Jan 2022, at 01:33, John Weeks  wrote:
>> On Jan 3, 2022, at 2:31 PM, Joshua Grauman  wrote:
>> 
>> Hi all,
>> 
>> I am working on using QTextLayout and I was wondering if someone could give 
>> me a quick explanation for what preedit text / preedit area was in this 
>> context? There's not much detail in the docs, reading the Qt code and 
>> googling hasn't helped me much.
>> 
>> When/why would you use setPreeditArea(int pos, QString text) vs 
>> setText(QString). What's a preedit area?
>> 
>> Thanks in advance,
>> 
>> Josh
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 
> Maybe something related to an input method? Input methods are used for things 
> like composing Japanese characters.
> 
> -John Weeks
> 


Yes, the preedit-area is the area in which text input widgets display the 
(preedit) text that is being composed, but not yet committed. E.g. with a 
Chinese input method, type “chang”; it will be displayed as a preedit text in 
the preedit area (underlined perhaps, or with a different background color), 
and the compositor window will open to allow you to pick one of the several 
glyphs that can be used (for instance, either 长 or 鬯).

So, this is important for complex input methods; but the preedit area is also 
used for not-so-complex input such as when typing an accented character on some 
platforms, or for auto completion or auto correction.

Volker


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

Re: [Interest] Qt 6.2.2 Webassembly - sign conversion errors

[Volker Hilsheimer]

> On 23 Dec 2021, at 13:39, Thiago Macieira  wrote:
> 
> On Wednesday, 22 December 2021 13:39:24 -03 Axel Spoerl wrote:
>> I using Qt 6.2.2 on OpenSuSE Leap 15.3. and emscripten version 2.0.14 as
>> required according to the documentation. If I install and activate the
>> current latest version (i.e. 3.0.1) of emsdk, I get exactly the same
>> errors.
> 
> Qt is not relevant here. Your C and C++ libraries are incompatible, or you're 
> using flags that cause them to be so.
> 
> Make sure a simple C++ #include  works in C++17 mode. Once that works, 
> we can talk.

Well, Qt is a bit relevant if the qt-cmake of the Qt 6.2.2 WASM installation 
results in broken make files.

So the question is perhaps: Axel, assuming that you installed emscripten 
following the instruction and that you can verify that you can compile basic 
C++ code as Thiago suggested, how do you then generate your make files?

Volker

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

Re: [Interest] win: can't trap WM_ENTER/EXITMENULOOP?

[Volker Hilsheimer]

QMenuBar is not a Win32 native menu bar, and neither is QMenu backed by a 
native win32 menu. Windows knows nothing about their role in the UI (unless it 
asks for it via accessibility infrastructure, but that’s unrelated to those 
messages).

Volker


From: Interest  on behalf of David M. Cotter 

Sent: Monday, October 25, 2021 6:39:40 PM
To: Qt Interest 
Subject: [Interest] win: can't trap WM_ENTER/EXITMENULOOP?


in the documentation 
here, it indicates 
i can get a message when the menu bar starts to be browsed, and another when 
the browsing is completed.

this is exactly what i need (the purpose is unrelated to this post).

So in my QMainWindow derived class, i override the nativeEvent() method, like 
so:

boolQBrowserWindow::nativeEvent(
const QByteArray&   eventType,
void*messageP,
qintptr *resultP)
{
boolhandledB(false);

if (eventType == kWindowsEventType_GENERIC) {
MSG&msg(*(MSG *)messageP);

switch (msg.message) {

default: {
//  nothing else
} break;

case WM_ENTERMENULOOP: {
Log("start menu browsing");
SuspendTableUpdates(true);
} break;

case WM_EXITMENULOOP: {
Log("end menu browsing");
SuspendTableUpdates(false);
} break;
}
}

return handledB;
}


However, those messages are never sent :(

Any idea why not?

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

Re: [Interest] OSX security – allow dialogue

[Volker Hilsheimer]

Hi Alexander,

Fascinating. I can reproduce this. Starting from Terminal doesn’t crash (no 
matter whether with ‘open’ or the binary inside the bundle directly), starting 
camera.app via Finder does. Starting the camera binary inside the camera.app 
bundle via Finder does not crash, it asks for permission and if rejected 
nothing special happens (no video, obviously, also no crash).

The multimedia/declarative-camera example however does start correctly in all 
cases. It doesn’t ask for microphone access, which the multimediawidgets/camera 
example does when launched from Terminal.

The stack trace I get with the widgets example goes to

12  com.apple.avfoundation  0x7fff30bbe7a5 -[AVCaptureSession 
addInput:] + 71
13  org.qt-project.QtMultimedia 0x00010ec99f00 
AVFCameraSession::attachAudioInputDevice() + 176
14  org.qt-project.QtMultimedia 0x00010ec9a190 
AVFCameraSession::updateAudioInput() + 128 (avfcamerasession.mm:487)
15  org.qt-project.QtMultimedia 0x00010ec97dd0 
AVFCameraService::setAudioInput(QPlatformAudioInput*) + 624 
(avfcameraservice.mm:146)
16  org.qt-project.QtMultimedia 0x00010ec65c98 
QMediaCaptureSession::setAudioInput(QAudioInput*) + 56 
(qmediacapturesession.cpp:204)

before disappearing into com.apple.Foundation. Perhaps that helps us figure out 
what’s going on.

From those observations I’d either way think that things should work as you 
expect them to (ie. nothing special needs to be done to trigger those 
permission dialogs).

Filed a JIRA ticket at

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


Thanks,
Volker



> On 9 Oct 2021, at 22:08, Alexander Carôt  wrote:
> 
> P.S.: see below – in that regard I compiled the camera example (Qt6.2) and 
> ran it via clicking on the app icon (rather than running it from the console 
> which per se has cam access). Also here it did not ask for allowing cam 
> access and then the app crashed. Can anyone reconstruct this ?
> 
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> 
>> Gesendet: Samstag, 09. Oktober 2021 um 11:47 Uhr
>> Von: "Alexander Carôt" 
>> An: "qt qt" 
>> Betreff: [Interest] OSX security – allow dialogue
>> 
>> Hej all,
>> 
>> not sure if this is a bug on my end, a bug in Qt or even a bug in OSX:
>> 
>> When I deploy a new release of my software (which uses audio and video 
>> capture) after installation on a user's machine it asks for  permissions to 
>> access the mic and the camera. When not enabled sound capture does not work 
>> and video even crashes – when enabled all is fine. So this dialogue is 
>> really important to the user. 
>> 
>> However, in some cases the new deployed version does not ask this question 
>> anymore and as a result the user manually has to change the security 
>> settings. Otherwise they stick to the previous version.
>> 
>> For some reason I discover this again after deploying with the new Qt6.2 but 
>> (as written above) I don't know if it's related.
>> 
>> Can anyone help in this regard ? Any hint appreciated because for almost one 
>> year I am really confused about this. Maybe there is a way to force the OS 
>> to enable this dialogue ?!
>> 
>> Thanks a lot in advance,
>> best
>> 
>> Alex
>> 
>> --
>> http://www.carot.de
>> Email : alexan...@carot.de
>> Tel.: +49 (0)177 5719797
>> 
>> ___
>> 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] Qt 5.15 LTS vs Qt 6.2 LTS

[Volker Hilsheimer]

> On 30 Sep 2021, at 15:59, Roland Hughes via Interest 
>  wrote:
> On 9/30/21 5:00 AM, interest-requ...@qt-project.org wrote:
>> On Wednesday, 29 September 2021 07:40:11 PDT Rui Oliveira wrote:
>> 
>>> "Both *Windows 7 or 8.x*
>>>  version support will not be available for Qt 6"
>>> 
>> https://support.microsoft.com/en-us/windows/windows-7-support-ended-on-january-14-2020-b75d4580-2cc7-895a-2c9c-1466d9a53962
>> 
>> 
>> "Support for Windows 7 ended on January 14, 2020."
>> 
>> 
>> https://docs.microsoft.com/en-us/lifecycle/faq/windows#windows-8.1
>> 
>> "Windows 8.1 reached the end of Mainstream Support on January 9, 2018, and 
>> will reach end of Extended Support on January 10, 2023."
>> 
> This has never been a valid argument. Vendors don't get to choose when 
> something dies. The customers do.


If you want, or are forced, to run an old OS, then you very likely have similar 
constraints for most of your other software as well. That software might still 
get patched up as a special service, just as Windows is; but it’s certainly not 
ported over to a new runtime environment like a major new .NET or Qt version.

That is, in my experience, a reasonable default assumption. Nobody expects to 
run brand new HMIs or latest versions of productivity software on those OS/2 or 
Windows XP terminals.

But, if you bring enough $$$ to The Qt Company, then I’m sure we can discuss a 
special Qt 6 version for you that runs on Windows 7. It’s not going to be 
cheap, but that’s also a choice a customer has to make.


Cheers,
Volker


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

Re: [Interest] Issue with Qt fonts

[Volker Hilsheimer]

> On 23 Sep 2021, at 14:43, praveen illa  wrote:
> 
> After switching to other language
> 
> On Thu, 23 Sep, 2021, 6:10 PM Crocker, William,  
> wrote:
> Is the include picture before, after or both.
> 
>  
> 
> From: Interest  On Behalf Of praveen illa
> Sent: Thursday, September 23, 2021 8:20 AM
> To: interest@qt-project.org
> Subject: [Interest] Issue with Qt fonts
> 
>  
> 
> [External]
> 
>  
> 
> Hi Team, 
> 
>  
> 
> I am facing an issue with fonts when switching between english and other 
> language. 
> 
> The Qt fonts displaying are not smooth on the target. 
> 
>  
> 
> Can anyone help me on this issue?
> 
>  
> 
> Below are the font libraries am using
> libharfbuzz.so.0.20301.0
> libharfbuzz-subset.so.0.20301.0
> libfontconfig.so.1.10.1
> libfreetype.so.6.16.1
> 
> Thank you
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


Does your default font provides those glyphs? if not, then Qt will try to find 
a font that can and matches the original font in certain attributes (for 
instance, proportional font, or serifed font). The quality of the glyphs in the 
font Qt choses for you might then not be what you expect.

It’s best to explicitly select the fonts you want for the different languages. 
That’s why there’s QFont::setFamilies which takes a list:

https://doc.qt.io/qt-6/qfont.html#setFamilies


Cheers,
Volker

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

Re: [Interest] qt and Windows tolerance heap

[Volker Hilsheimer]

> On 7 Sep 2021, at 11:31, maitai  wrote:
> 
> Hi,
> 
> I have some users (mainly beta testers) that are suffering from "Windows 
> Tolerant Heap" 
> (https://docs.microsoft.com/en-us/windows/win32/win7appqual/fault-tolerant-heap).
>  The consequence of this being activated after some crashes is that the 
> application becomes very slow, plus some mysterious crashes occur randomly 
> deep inside qt event queue manager.
>  
> I know how to remove the app from Tolerant Heap with an elevated command 
> prompt.
>  
> My question is: is there a way from inside the application to detect the app 
> is running in this mode, so I can prompt the user to contact us for instance?
>  
> Thanks for any insight
> Philippe Lelong


Based on

https://stackoverflow.com/questions/5020418/how-do-i-turn-off-the-fault-tolerant-heap

it seems like there’ll be an entry in the registry for your application, such as

HKLM\Software\Microsoft\Windows 
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe

or

HKCU\Software\Microsoft\Windows 
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe


that you can query.

Cheers,
Volker

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

Re: [Interest] Ashamed bug :)

[Volker Hilsheimer]

> On 4 Sep 2021, at 17:41, Bernhard Lindner  wrote:
> 
> 
>> The entire process is either difficult or easy.
> 
> No. Actually it can be both: Difficult for an outsider and easy for a 
> experienced Qt
> developer. 
> 
> -- 
> Best Regards,
> Bernhard Lindner


For someone that develops on Qt every day, applying a patch and pushing it to 
gerrit is of course easy, even though it is a complex process. For someone that 
has never done it, it’s a fairly steep learning curve, and even a simple 
workflow can be daunting.

And even for someone that works on Qt every day and might even be familiar with 
the code in question, developing a reliable unit test can be a very challenging 
task, esp for bugs where the file system is involved. Your unit test must 
establish a file system that can be reliably tested, not leave any stray file 
system entries behind even when failing, etc. It can be very least laborious 
and error prone, especially if you don’t want to use Qt APIs for that in order 
to be able to meaningfully test those Qt APIs.

But that’s missing the point I evidently failed to make.

I’m not a native English speaker myself, and I respect that bug reports, 
comments, emails, or chat messages from folks that don't command the language 
perfectly can come across as harsher than they were perhaps intended.

But when someone claims that a bug in Qt is easy to fix, so easy in fact that 
we should be ashamed (or even perhaps just embarrassed) that it hasn’t been 
fixed yet; if they are even suggesting that they know exactly what calls are 
missing where, but then don't even bother to share this insight with those of 
us in the email so that someone who doesn’t have to climb the contribution 
learning curve can perhaps do something about it… that’s a bit much.


Cheers,
Volker

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

Re: [Interest] Ashamed bug :)

[Volker Hilsheimer]

Appreciated.

For commercial license holders, contacting our support team is the right 
approach to get issues impacting your product flagged.

Cheers,
Volker


> On 3 Sep 2021, at 16:54, Crocker, William  wrote:
> 
> I gave you money. 
> That is my contribution.
> 
>> 
>> 
>> We’re all looking forward to your contribution!
>> 
>> https://urldefense.com/v3/__https://wiki.qt.io/Qt_Contribution_Guidelines__;!!A3Ni8C
>> S0y2Y!pfKZTNY9HoSsx4ICysjigHnt8T5UfDgm7vz9vF_zbwiTUAOveu1JUyFyM-
>> FVnCwjs0-A$
>> 
>> Cheers,
>> Volker
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://urldefense.com/v3/__https://lists.qt-
>> project.org/listinfo/interest__;!!A3Ni8CS0y2Y!pfKZTNY9HoSsx4ICysjigHnt8T5UfDg
>> m7vz9vF_zbwiTUAOveu1JUyFyM-FVnFphJy22$
> ___
> 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] Ashamed bug :)

[Volker Hilsheimer]

> On 3 Sep 2021, at 14:06, Alexander Dyagilev  wrote:
> 
> Hello :)
> 
> I think this bug is easy to fix, but yet, it's still theme for almost of 5 
> years!
> 
> https://bugreports.qt.io/browse/QTBUG-58335
> 
> One just forgot to use encodeURIComponent/decodeURIComponent in proper 
> places...
> 
> I think this is a must to fix bug for upcoming Qt 6.2 :)


We’re all looking forward to your contribution!

https://wiki.qt.io/Qt_Contribution_Guidelines

Cheers,
Volker

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

Re: [Interest] missing modules in Qt6.1

[Volker Hilsheimer]

Hi Alexander,

I recommend the following blog post from Lars about some of the significant 
changes we made to Qt Multimedia for Qt 6:

https://www.qt.io/blog/qt-multimedia-in-qt-6

Cheers,
Volker


> On 25 Aug 2021, at 15:02, Alexander Carôt  wrote:
> 
> Hi Juha and Jérome and all,
> 
> thanks for the info so far that Qt6.1 in not complete !
> 
> Thus, I tried the 6.2 preview which indeed did not complain about the missing 
> modules after using qmake.
> 
> However, it did complain about something which had been working since 5.12:
> 
> ./ui_camera.h:18:10: fatal error: 'qcameraviewfinder.h' file not found
> #include "qcameraviewfinder.h"
> 
> Is this because the preview is of course incomplete and the files are missing 
> or might there be another cause ?
> 
> Thanks again,
> best
> 
> Alex
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> 
>> Gesendet: Mittwoch, 25. August 2021 um 06:04 Uhr
>> Von: "Juha Vuolle" 
>> An: "Alexander Carôt" 
>> Cc: "qt qt" 
>> Betreff: Re: [Interest] missing modules in Qt6.1
>> 
>> Hi Alexander,
>> 
>> Those modules (along with some others) will be released in 6.2 and are
>> not present in 6.1.
>> Please see https://wiki.qt.io/New_Features_in_Qt_6.2
>> 
>> A "beta 3" release of the 6.2 was released ~week ago.
>> 
>> 
>> Juha
>> 
>> ti 24. elok. 2021 klo 21.56 Alexander Carôt (alexander_ca...@gmx.net) 
>> kirjoitti:
>>> 
>>> Hej all,
>>> 
>>> after quite some time I decided to upgrade from Qt5.15 to Qt6.1 (open 
>>> source).
>>> 
>>> For now I still use qmake which, however, told me this:
>>> 
>>> Project ERROR: Unknown module(s) in QT: websockets multimedia 
>>> multimediawidgets
>>> 
>>> and indeed I saw that the frameworks are not there.
>>> 
>>> Is there a way to get them or did I probably miss some information about 
>>> this.
>>> 
>>> Thanks in advance,
>>> best
>>> 
>>> Alex
>>> 
>>> --
>>> http://www.carot.de
>>> Email : alexan...@carot.de
>>> Tel.: +49 (0)177 5719797
>>> 
>>> ___
>>> 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] List traffic disappearing?

[Volker Hilsheimer]

> On 20 Aug 2021, at 10:37, rene.reuc...@batcom-it.net wrote:
> 
> On 2021-08-19 15:37, Murphy, Sean wrote:
>> I've been on this list (and it's predecessor) for a couple of decades,
>> and have noticed that the traffic on it seems to have slowed
>> significantly over the past few months. Is there somewhere else people
>> are going, like https://forum.qt.io/, or have people just stopped
>> discussing Qt for some other reason?
> Yeah, I have the same "issue". Although I didn't watch the list(s) lately, I 
> saw that the traffic went down.
> 
> Cheers, René
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

I suppose the quieting down is to some degree due to summer holidays. However, 
there’s a decent amount of traffic on the IRC/Matrix channels.

These emails, and the “QThreadPool” discussion over the last days, indicate at 
any rate that no traffic is disappearing due to system failures.

Cheers,
Volker

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

Re: [Interest] Text-To-Speech in QT6

[Volker Hilsheimer]

> On 9 Jul 2021, at 15:35, Corentin BACQUÉ-CAZENAVE via Interest 
>  wrote:
> 
> Hi,
> 
> I'm working on an app using Text-To-Speech, but QTextToSpeech isn't not 
> present in QT6 apparently.
> 
> There is plan to add this module to a future QT6 release? Or an alternative 
> module exists?
> 
> Thanks.


Hi Corentin,

I’m not aware of any plans to port QtSpeech to Qt 6 right now. The maintainer 
didn’t give any update at the recent contributors summit. I’m also not aware of 
any significant usage of the module, be it OSS users or customers of the Qt 
Company.

If that’s functionality you care about, then perhaps it’s an opportunity to 
pick it up and see what it takes to port it over.

Cheers,
Volker

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

Re: [Interest] More on table problem

[Volker Hilsheimer]

> 
>>> On Fri, Jun 11, 2021 at 10:05 AM Volker Hilsheimer 
>>>  wrote:
>>> > On 11 Jun 2021, at 13:52, Turtle Creek Software  
>>> > wrote:
>>> > 
>>> > Here's more info on the weird QTableWidget problem we're seeing.
>>> > 
>>> > One of our data entry fields uses combination of widgets:  a QLineEdit 
>>> > subclass with a linked QToolButton subclass next to it, and a QListWidget 
>>> > subclass that drops down underneath.  It acts kinda like a combo box, but 
>>> > better for really long lists. The whole assembly works properly in 
>>> > regular data entry screens.  Clicking on button or list changes values in 
>>> > the line edit field.
>>> > 
>>> > We use setCellWidget to put the same QLineEdit subclass into a 
>>> > QTableWidget cell. The button and list appear properly, but the button 
>>> > does not catch mouse clicks.  They go to the cell behind the button 
>>> > instead.
>>> > 
>>> > We use signals/slots to connect the clicked signal, but don't fiddle with 
>>> > events otherwise. 
>>> > 
>>> > Casey McD
>>> 
>>> 
>>> This works fine:
>>> 
>>> #include 
>>> 
>>> class CellWidget : public QWidget
>>> {
>>> public:
>>> CellWidget()
>>> {
>>> QLineEdit *le = new QLineEdit;
>>> QToolButton *tb = new QToolButton;
>>> QMenu *toolMenu = new QMenu;
>>> toolMenu->addAction(new QAction("Action 1", this));
>>> toolMenu->addAction(new QAction("Action 2", this));
>>> toolMenu->addAction(new QAction("Action 3", this));
>>> tb->setPopupMode(QToolButton::InstantPopup);
>>> tb->setMenu(toolMenu);
>>> 
>>> QHBoxLayout *hbox = new QHBoxLayout;
>>> hbox->addWidget(le);
>>> hbox->addWidget(tb);
>>> setContentsMargins(0, 0, 0, 0);
>>> hbox->setContentsMargins(0, 0, 0, 0);
>>> 
>>> setLayout(hbox);
>>> }
>>> 
>>> QSize minimumSizeHint() const { return QSize(100, 100); }
>>> };
>>> 
>>> int main(int argc, char **argv)
>>> {
>>> QApplication app(argc, argv);
>>> 
>>> QTableWidget table(10, 10);
>>> table.setCellWidget(5, 5, new CellWidget);
>>> 
>>> table.show();
>>> 
>>> return app.exec();
>>> }
>>> 
>>> 
>>> Volker
>> 
>> On 11 Jun 2021, at 17:51, Turtle Creek Software  
>> wrote:
>> 
>> If I understand this code correctly, it's putting the button inside the 
>> cell. Unfortunately, there isn't enough room to do that.
>> The table only shows the QLineEdits.  When you click in a cell to edit, the 
>> button appears next to it, over the neighboring cell(s).
>> However, maybe there is a container we can put the button into, that will 
>> act as a click barrier.  Something less extreme than a dialog.
>> Casey McD


Make sure you create whatever widget you create for editing cells either via an 
item delegate, e.g.

https://doc.qt.io/qt-5/qabstractitemdelegate.html#createEditor

But that’s not the same as using setCellWidget, and indeed, QTableView will 
want to fit the editor widget into the cell, and while you can set a minimum 
width to make the widget reach beyond the cell, that will not work great on the 
edge of the table.

If you do something completely custom, then make sure you create child widgets 
as children of the viewport() of QTableWidget, even if they are popups.


> On 11 Jun 2021, at 18:18, Turtle Creek Software  
> wrote:
> 
> I tried putting the button inside a QFrame, but it has the same problem.  
> Casey McD


Feel free to modify my example to show how and when you are setting up those 
widgets. Otherwise it’s unlikely that we’ll ever end up with the same 
configuration.

Volker


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

Re: [Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

To close this thread, a bunch of changes that fix this in the least intrusive 
way have been merged for Qt 6.2.

In ExtendedSelection, Ctrl+Press does not deselect items that could also be 
dragged, Ctrl+Release does; Ctrl+Press on an unselected item selects the item, 
then you can drag it as part of a previous selection. An equivalent change n 
MultiSelection (minus the Ctrl):

* https://codereview.qt-project.org/c/qt/qtbase/+/351595/8
* https://codereview.qt-project.org/c/qt/qtbase/+/352401

Thanks for the comments and reviews. Qt 6.2 should be available as snapshot 
packages already, and the Alpha is around the corner as well. Early feedback to 
those (and several other changes and fixes to Qt Widgets from the last couple 
of weeks [1]) would be most welcome.


Cheers,
Volker

[1] 
https://codereview.qt-project.org/q/is:merged+branch:dev+path:%255Esrc/widgets/.*+after:2021-05-31


> On 1 Jun 2021, at 21:43, Volker Hilsheimer  wrote:
> 
> But git history will remember the fool that broke all the things :P
> 
> Anyway, a bunch of patches in the chain currently ending at
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/351595/3
> 
> in case anyone wants to give it a swing. MultiSelection is not changed yet, 
> and it looks like we might get away with a minimal change for 
> ExtendedSelection.
> 
> There’s no intention to bring those changes to Qt 5.
> 
> Volker
> 
> 
>> On 28 May 2021, at 19:01, Elvis Stansvik  wrote:
>> 
>> Yea man, just change it. No one remembers a coward! :)
>> 
>> Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter :
>>> 
>>> assuming your change "does the right thing in all cases" then i think it 
>>> should be the default.
>>> 
>>> nobody WANTS the currently-bad behavior.
>>> 
>>> -dave
>>> 
>>>> On May 28, 2021, at 5:55 AM, Volker Hilsheimer  
>>>> wrote:
>>>> 
>>>> Cross-posting from the development mailing list in case any of you have a 
>>>> strong opinion about this.
>>>> 
>>>> Volker
>>>> 
>>>> 
>>>>> On 28 May 2021, at 13:10, Volker Hilsheimer  
>>>>> wrote:
>>>>> 
>>>>> Hey Widget fans,
>>>>> 
>>>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>>>>> 
>>>>> The UX resulting from our (strange) choice to trigger selection changes 
>>>>> on mouse press rather than mouse release is indeed quite horrible, as 
>>>>> explained in the ticket.
>>>>> 
>>>>> The options to fix that seem to be:
>>>>> 
>>>>> 1) change the default behavior - always change selection on mouse release
>>>>> 2) change the default behavior if drag (as per dragDropMode)
>>>>> 3) make the "selection trigger" a property
>>>>> 
>>>>> None of those options would IMHO result in a change that qualifies for 
>>>>> stable branches. I’ve for now implemented option 3. This introduces new 
>>>>> API, so if we agree that this is the way to go then it would ideally be 
>>>>> merged before 6.2 feature freeze next Friday.
>>>>> 
>>>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
>>>>> 
>>>>> However, the possible property values seem oddly specific to this 
>>>>> problem, and give that this is a 6.2 only change anyway, perhaps it would 
>>>>> be best to simply change the default, which would then also make Qt 
>>>>> matching native UIs better (ie Windows Explorer or macOS Finder)?
>>>>> 
>>>>> 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
>>> 
>>> ___
>>> 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

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

Re: [Interest] More on table problem

[Volker Hilsheimer]

> On 11 Jun 2021, at 13:52, Turtle Creek Software  
> wrote:
> 
> Here's more info on the weird QTableWidget problem we're seeing.
> 
> One of our data entry fields uses combination of widgets:  a QLineEdit 
> subclass with a linked QToolButton subclass next to it, and a QListWidget 
> subclass that drops down underneath.  It acts kinda like a combo box, but 
> better for really long lists. The whole assembly works properly in regular 
> data entry screens.  Clicking on button or list changes values in the line 
> edit field.
> 
> We use setCellWidget to put the same QLineEdit subclass into a QTableWidget 
> cell. The button and list appear properly, but the button does not catch 
> mouse clicks.  They go to the cell behind the button instead.
> 
> We use signals/slots to connect the clicked signal, but don't fiddle with 
> events otherwise. 
> 
> Casey McD


This works fine:

#include 

class CellWidget : public QWidget
{
public:
CellWidget()
{
QLineEdit *le = new QLineEdit;
QToolButton *tb = new QToolButton;
QMenu *toolMenu = new QMenu;
toolMenu->addAction(new QAction("Action 1", this));
toolMenu->addAction(new QAction("Action 2", this));
toolMenu->addAction(new QAction("Action 3", this));
tb->setPopupMode(QToolButton::InstantPopup);
tb->setMenu(toolMenu);

QHBoxLayout *hbox = new QHBoxLayout;
hbox->addWidget(le);
hbox->addWidget(tb);
setContentsMargins(0, 0, 0, 0);
hbox->setContentsMargins(0, 0, 0, 0);

setLayout(hbox);
}

QSize minimumSizeHint() const { return QSize(100, 100); }
};

int main(int argc, char **argv)
{
QApplication app(argc, argv);

QTableWidget table(10, 10);
table.setCellWidget(5, 5, new CellWidget);

table.show();

return app.exec();
}


Volker

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

Re: [Interest] Button in front of table

[Volker Hilsheimer]

> On 10 Jun 2021, at 12:55, Turtle Creek Software  
> wrote:
> 
> We have a QTableWidget with cells containing our QWidget subclasses.  One of 
> them adds a temporary popup menu button and a scrolling list when clicked.
> 
> They display OK, but clicking on them falls through to the cell widget behind 
> them. raise() didn't help.
> 
> We can intercept all clicks and figure if they should go to a temporary 
> object, but is there an easier way to put something in front of a 
> QTableWidget and have it accept mouse clicks?
> 
> Thanks, Casey McD

Hey Casey,

Would be good to see some code. I assume your widget subclass handles 
mousePressEvent to show a toplevel QWidget of Qt::Popup type, and that popup 
widget displays a scrolling list (perhaps it is a QListView, or it contains a 
QListView, or it does everything itself)? Mouse events going to that popup 
should not propagate beyond it. Or are you not using a popup-type toplevel 
widget?

If you have a completely custom widget for the scrolling list view, are you 
ignoring any events (they are accepted by default, the default implementation 
of QWidget::mousePress/ReleaseEvent ignores them to let them propagate through 
the hierarchy).

Volker


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

Re: [Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

But git history will remember the fool that broke all the things :P

Anyway, a bunch of patches in the chain currently ending at

https://codereview.qt-project.org/c/qt/qtbase/+/351595/3

in case anyone wants to give it a swing. MultiSelection is not changed yet, and 
it looks like we might get away with a minimal change for ExtendedSelection.

There’s no intention to bring those changes to Qt 5.

Volker


> On 28 May 2021, at 19:01, Elvis Stansvik  wrote:
> 
> Yea man, just change it. No one remembers a coward! :)
> 
> Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter :
>> 
>> assuming your change "does the right thing in all cases" then i think it 
>> should be the default.
>> 
>> nobody WANTS the currently-bad behavior.
>> 
>> -dave
>> 
>>> On May 28, 2021, at 5:55 AM, Volker Hilsheimer  
>>> wrote:
>>> 
>>> Cross-posting from the development mailing list in case any of you have a 
>>> strong opinion about this.
>>> 
>>> Volker
>>> 
>>> 
>>>> On 28 May 2021, at 13:10, Volker Hilsheimer  
>>>> wrote:
>>>> 
>>>> Hey Widget fans,
>>>> 
>>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>>>> 
>>>> The UX resulting from our (strange) choice to trigger selection changes on 
>>>> mouse press rather than mouse release is indeed quite horrible, as 
>>>> explained in the ticket.
>>>> 
>>>> The options to fix that seem to be:
>>>> 
>>>> 1) change the default behavior - always change selection on mouse release
>>>> 2) change the default behavior if drag (as per dragDropMode)
>>>> 3) make the "selection trigger" a property
>>>> 
>>>> None of those options would IMHO result in a change that qualifies for 
>>>> stable branches. I’ve for now implemented option 3. This introduces new 
>>>> API, so if we agree that this is the way to go then it would ideally be 
>>>> merged before 6.2 feature freeze next Friday.
>>>> 
>>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
>>>> 
>>>> However, the possible property values seem oddly specific to this problem, 
>>>> and give that this is a 6.2 only change anyway, perhaps it would be best 
>>>> to simply change the default, which would then also make Qt matching 
>>>> native UIs better (ie Windows Explorer or macOS Finder)?
>>>> 
>>>> 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
>> 
>> ___
>> 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] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

Turns out that the patch that fixed QTBUG-1 introduced that behavior 
change, and - given that I was the one making that patch - I can say that the 
change you are observing is an unintentional side effect.

Created https://bugreports.qt.io/browse/QTBUG-94087 and fix in progress.

Cheers,
Volker


> On 28 May 2021, at 16:00, Volker Hilsheimer  wrote:
> 
> This seems unrelated, since the JIRA ticket predates both 5.11 and 5.15, so 
> while it does sound like a regression that you’re welcome to report, it won’t 
> help me with deciding about this particular issue.
> 
> 
> Cheers,
> Volker
> 
> 
>> On 28 May 2021, at 15:30, Olivier B.  
>> wrote:
>> 
>> Here, we have had an issue when switching from 5.11.1 to 5.15.2, with multi 
>> selection and dragNdrop
>> Now, if we start a drag n drop, but previously clicked on the item a short 
>> time ago (less than the double click delay), then the view starts multi 
>> selection with the mouse moves instead of starting drag n drop, even if the 
>> mouse leaves the widget area.
>> This did not happen in 5.11.1 with same user code, and dragging was enabled 
>> on a double-click+move
>> I'm not sure which behaviour is better, but for our use cases, the former 
>> was more fitted.
>> 
>> Maybe looking at what changed between 5.11.1 and 5.15.2 (and why) could help 
>> your decision?
>> 
>> Le ven. 28 mai 2021 à 14:58, Volker Hilsheimer  a 
>> écrit :
>> Cross-posting from the development mailing list in case any of you have a 
>> strong opinion about this.
>> 
>> Volker
>> 
>> 
>>> On 28 May 2021, at 13:10, Volker Hilsheimer  wrote:
>>> 
>>> Hey Widget fans,
>>> 
>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>>> 
>>> The UX resulting from our (strange) choice to trigger selection changes on 
>>> mouse press rather than mouse release is indeed quite horrible, as 
>>> explained in the ticket.
>>> 
>>> The options to fix that seem to be:
>>> 
>>> 1) change the default behavior - always change selection on mouse release
>>> 2) change the default behavior if drag (as per dragDropMode)
>>> 3) make the "selection trigger" a property
>>> 
>>> None of those options would IMHO result in a change that qualifies for 
>>> stable branches. I’ve for now implemented option 3. This introduces new 
>>> API, so if we agree that this is the way to go then it would ideally be 
>>> merged before 6.2 feature freeze next Friday.
>>> 
>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
>>> 
>>> However, the possible property values seem oddly specific to this problem, 
>>> and give that this is a 6.2 only change anyway, perhaps it would be best to 
>>> simply change the default, which would then also make Qt matching native 
>>> UIs better (ie Windows Explorer or macOS Finder)?
>>> 
>>> 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
> 
> ___
> 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] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

This seems unrelated, since the JIRA ticket predates both 5.11 and 5.15, so 
while it does sound like a regression that you’re welcome to report, it won’t 
help me with deciding about this particular issue.


Cheers,
Volker


> On 28 May 2021, at 15:30, Olivier B.  
> wrote:
> 
> Here, we have had an issue when switching from 5.11.1 to 5.15.2, with multi 
> selection and dragNdrop
> Now, if we start a drag n drop, but previously clicked on the item a short 
> time ago (less than the double click delay), then the view starts multi 
> selection with the mouse moves instead of starting drag n drop, even if the 
> mouse leaves the widget area.
> This did not happen in 5.11.1 with same user code, and dragging was enabled 
> on a double-click+move
> I'm not sure which behaviour is better, but for our use cases, the former was 
> more fitted.
> 
> Maybe looking at what changed between 5.11.1 and 5.15.2 (and why) could help 
> your decision?
> 
> Le ven. 28 mai 2021 à 14:58, Volker Hilsheimer  a 
> écrit :
> Cross-posting from the development mailing list in case any of you have a 
> strong opinion about this.
> 
> Volker
> 
> 
> > On 28 May 2021, at 13:10, Volker Hilsheimer  wrote:
> > 
> > Hey Widget fans,
> > 
> > I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
> > 
> > The UX resulting from our (strange) choice to trigger selection changes on 
> > mouse press rather than mouse release is indeed quite horrible, as 
> > explained in the ticket.
> > 
> > The options to fix that seem to be:
> > 
> > 1) change the default behavior - always change selection on mouse release
> > 2) change the default behavior if drag (as per dragDropMode)
> > 3) make the "selection trigger" a property
> > 
> > None of those options would IMHO result in a change that qualifies for 
> > stable branches. I’ve for now implemented option 3. This introduces new 
> > API, so if we agree that this is the way to go then it would ideally be 
> > merged before 6.2 feature freeze next Friday.
> > 
> > https://codereview.qt-project.org/c/qt/qtbase/+/351595
> > 
> > However, the possible property values seem oddly specific to this problem, 
> > and give that this is a 6.2 only change anyway, perhaps it would be best to 
> > simply change the default, which would then also make Qt matching native 
> > UIs better (ie Windows Explorer or macOS Finder)?
> > 
> > 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

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

Re: [Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Volker Hilsheimer]

Cross-posting from the development mailing list in case any of you have a 
strong opinion about this.

Volker


> On 28 May 2021, at 13:10, Volker Hilsheimer  wrote:
> 
> Hey Widget fans,
> 
> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
> 
> The UX resulting from our (strange) choice to trigger selection changes on 
> mouse press rather than mouse release is indeed quite horrible, as explained 
> in the ticket.
> 
> The options to fix that seem to be:
> 
> 1) change the default behavior - always change selection on mouse release
> 2) change the default behavior if drag (as per dragDropMode)
> 3) make the "selection trigger" a property
> 
> None of those options would IMHO result in a change that qualifies for stable 
> branches. I’ve for now implemented option 3. This introduces new API, so if 
> we agree that this is the way to go then it would ideally be merged before 
> 6.2 feature freeze next Friday.
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/351595
> 
> However, the possible property values seem oddly specific to this problem, 
> and give that this is a 6.2 only change anyway, perhaps it would be best to 
> simply change the default, which would then also make Qt matching native UIs 
> better (ie Windows Explorer or macOS Finder)?
> 
> 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] QOpenGLWindow inside QSplitter horizontal layout ?

[Volker Hilsheimer]

> On 21 May 2021, at 06:02, Nicholas Yue  wrote:
> 
> Hi,
> 
> I am learning about QOpenGLWindow
> 
> I saw examples which utilizes it via
> 
> QWidget::createWindowContainer()
> 
> I am wondering if there is a way to house it as a widget inside a layout ?
> 
> My current attempt is not working.
> 
> ```
> MainWindow::MainWindow(QWidget *parent) :
> QMainWindow(parent),
> ui(new Ui::MainWindow),
> m_myWindow(new MyOpenGLWindow)
> {
> ui->setupUi(this);
> 
> connect(ui->actionQuit, ::triggered, this, 
> ::OnFileClose);
> 
> m_myWindow->create();
> #ifdef ORIGINAL_WORKING_EXAMPLE
> m_myWindow->setMainWindow(this);
> QWidget *w = QWidget::createWindowContainer(m_myWindow);
> 
> takeCentralWidget();
> setCentralWidget(w);
> #else
> m_myWindow->setMainWindow(this);
> QWidget *w = QWidget::createWindowContainer(m_myWindow);
> // delete ui->targetWidget;
> // ui->targetWidget = QWidget::createWindowContainer(m_myWindow);
> // ui->targetWidget->setMinimumSize(400,400);
> w->setMinimumSize(200,200);
> w->setMaximumSize(200,200);
> // ui->targetWidget->createWindowContainer(m_myWindow);
> // takeCentralWidget();
> //setCentralWidget(ui->targetWidget);
> ui->splitter->layout()->addWidget(w);
> #endif
> }
> ```
> 
> Cheers
> -- 
> Nicholas Yue


As the name suggests, QOpenGLWindow is a QWindow, and QWindow’s are designed to 
be top level windows.

To embed an OpenGL rendering surface into a widget-based UI, you should be 
looking at QOpenGLWidget instead:

https://doc.qt.io/qt-6/qopenglwidget.html

Volker


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

Re: [Interest] L Word

[Volker Hilsheimer]

Aren’t there enough other places where subjects that are too off-topic for this 
list can be discussed? Facebook, Twitter, medium, reddit etc. provide ample 
opportunity. I’d at least consider them better places for product-placement :P 
I don’t quite see why the Qt community needs to host a channel for discussions 
that are off-topic for most Qt users.

Nevertheless, honest and constructive discussions, also including some venting, 
about what’s wrong with Qt are welcome here. In particular for technical issues 
there are likely to be people reading list that can do something about it.


Cheers,
Volker


> On 30 Apr 2021, at 17:20, Jason H  wrote:
> 
> Not to Jeffery specifically,
>  
> I have mixed feelings about the whole situation. I think Roland is right, or 
> at least has a valid point most of the time, even if it is technical or 
> limited to a specific use case. However his speech is often hyperbolic, 
> absolutust, and not really tolerant of any other opinion. 
>  
> I think licensing, project direction, and other "soft" discussions ARE 
> appropriate for "qt-interest" mailing list. I don't think the hyperbole is 
> appropriate though.  
>  
> Maybe the answer is another mailing list, "qt-offtopic" or whatever, and we 
> can say that such hyperbole is appropriate there, but not here. I do 
> appreciate the comments that for people looking for a dense, tenchical 
> resource, the hyperbole is diluting. 
>  
> I hope Giuseppe comes back. He's been fantastic. 
>  
> Personally, I don't understand why if he hates it so much he participates the 
> way he does? It seems like ge's mobing away from Qt on his own? I suspect 
> that he probably won't return after the ban.
>  
> Sent: Friday, April 30, 2021 at 10:12 AM
> From: "Jeffrey Brendecke" 
> To: interest@qt-project.org
> Subject: Re: [Interest] L Word
> I, too, am one of those list lurkers looking for interesting information and 
> discussions on Qt, but all too often I instead see posts from one unpleasant 
> person repeatedly dominating discussions with belligerent, non-productive 
> rantings. I wonder why he even uses Qt or even spends time thinking about it.
>  
> Given that there is at least one large development company in the US making 
> money off using Qt on medical devices, among others, I think that this one 
> difficult person is definitely not the sole fountain of knowledge on the 
> subject and should not be given more credence than necessary. If Qt has 
> short-comings in the medical device realm, constructive discussion would 
> bring more than infantile rants. He would have done better to convince the Qt 
> Company to hire him on as a consultant to improve their technology for use on 
> medical devices, as that seems to be something the company wants to be 
> successful in. Instead, I would not want to go anywhere near the guy
>  
> I have experienced Giuseppe D'Angelo as a fabulous, caring instructor and am 
> sorry to see him leave this discussion. All of us are the poorer because of 
> it.
>  
> If any person's postings on this list (or really in any context) are causing 
> excellent contributors like Giuseppe to leave, then that is a very good 
> indication that that person needs to be removed from the list.
>  
> Jeffrey
>  
> -
>  
> On Apr 29, 2021, at 21:30, Rui Oliveira  wrote:
>  
> And so we lost one of the most active, contributing, and knowledgeable 
> members of this mailing list. 
> 
> Cue "the worst trade deal maybe ever signed anywhere" meme. 
> 
> I was thinking of putting him in CC but I don't think I should bother the 
> man. 
> 
> I sure did respect Giuseppe, and I can totally get behind his no-BS 
> personality.
> 
> With wishes of talking about code again,
> Rui
> 
> Às 09:22 de 29/04/2021, Giuseppe D'Angelo via Interest escreveu:
> On 29/04/2021 00:42, Giuseppe D'Angelo via Interest wrote: 
> If the answer is yes, you were lying. If the answer is no, or you don't 
> answer, then you're trolling the mailing list. You'll get my apology; 
> I'll even throw in, for free, my personal congratulations for the long 
> trolling. But, you'll get a nice permanent ban from here. 
> 
> No reply. Yes, you're not the only one who can set arbitrary deadlines for 
> other people, pal. 
> 
> 
> I'll just go with the script then: you DID believe those links to be true. 
> 
> Then, please accept my deepest and most sincere apologies for calling you a 
> liar. 
> 
> I'll state it again, very clearly, all uppercase: 
> 
> YOU NEVER LIED. I WAS WRONG. 
> 
> Please accept the attached fruit basket as a gesture of good will. 
> 
> === 
> 
> Where does this leave us, then? 
> 
> At BEST, you have been trolling the mailing list, sending inflammatory false 
> content with the purpose of getting a strong reaction from the participants. 
> 
> At WORST, you have demonstrated some abysmal gross incompetence, since in 
> order to win an argument you: 
> 
> * googled some keywords; 
> * got the first couple of links that seemed to match 

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

[Volker Hilsheimer]

We currently have no specific plans to make QWidget render through RHI, and 
neither the video nor my earlier emails suggest that this is on the roadmap. It 
generally makes very little sense to draw with a pen into a freshly wiped out 
Vulkan surface 60 times per second.


Cheers,
Volker


> On 22 Apr 2021, at 13:18, Rui Oliveira  wrote:
> 
> This makes me raise the question: then how will you do the RHI backend for 
> Widgets then, if they are so "incompatible"?
> 
> Rui
> 
> Em 22/04/2021 09:50, Volker Hilsheimer escreveu:
>>> On 21 Apr 2021, at 22:39, Bernhard Lindner  
>>> wrote:
>>> 
>>> 
>>>> Personally, I think the exsting QtQuick element should be scrapped and 
>>>> just focus on QML
>>>> versions of the existing Widget functionality. I love the QML syntax, hate 
>>>> that it's not
>>>> just a layer on top of widgets.
>>> +100
>>> 
>>> Why this wasn't done from the start is one of the hardest puzzles! I ask 
>>> myself this
>>> question every time I read the three letters "QML" :-)
>> 
>> Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
>> wondering why there are several UI frameworks.
>> 
>> But there are several reasons why things are as they are. Some of them:
>> 
>> * imperative painting
>> 
>> Paint-event based drawing with a “pen” is not easily reconcilable with how 
>> GPUs like to work. Without a persistent scene graph that is uploaded to the 
>> GPU, much of the performance you get from a GPU is lost. An animation at 
>> 60fps is ideally just a draw call on the GPU with some different 
>> transformations, not a completely new upload of a completely reconstructed 
>> scene graph for each frame.
>> 
>> Widgets can draw into a framebuffer texture that can be used, and that 
>> allows for some integration, but that doesn’t give you great performance.
>> 
>> 
>> * integer coordinates and clipping
>> 
>> Widgets work with integer coordinates, which starts to be problematic now 
>> that we have high-DPI displays. And widgets clip are clipped to their parent 
>> geometry, which was the right choice for those UIs, but is very limiting and 
>> requires a lot of complex code to solve conceptually simple problems. Hello 
>> macOS focus ring.
>> Quick items do not clip and are not clipped, which gives a lot more freedom 
>> in how shapes are combined and structured.
>> 
>> 
>> * declarative vs imperative APIs
>> 
>> Many widget classes don’t have a declarative-friendly API. Plenty of widget 
>> properties have side effects on other properties, so the order in which 
>> properties are set matters. That doesn’t work well in a declarative world.
>> 
>> 
>> * weight
>> 
>> Widgets are heavy, often very complex objects. They often come with all 
>> bells and whistles. QPushButton always has the data structure to support 
>> QPushButton::setMenu, even if probably <1% of buttons out there ever use 
>> that feature. That’s ok on desktop machines, it’s not ok on embedded systems.
>> 
>> 
>> * complexity and hard to customize
>> 
>> Inheritance and reimplementing are nice concepts on paper and works great if 
>> you build your own custom widget from a reasonably abstract base class. But 
>> if you have ever tried to subclass e.g. QTreeWidget to modify how certain 
>> interactions work, then you know how hard it can be to not break the complex 
>> states that the default implementations rely on.
>> 
>> 
>> 
>> So, making widgets work in a declarative, GPU friendly world where ease of 
>> customisation is more important than standard look’n'feel would have 
>> required many changes to widgets. Those would have been impossible to make 
>> without invalidating or breaking a lot of code out there, and still not 
>> given us the UI components we would have needed.
>> 
>> I’m sure there are opportunities to share more code between widgets and 
>> quick world esp on the UI framework classes, and with Qt 6 we have taken 
>> some steps into that direction. But whether the benefits outweigh the risks 
>> and effort requires a case-by-case evaluation.
>> 
>> 
>> 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] Guide me through the Qt offerings for GUIs

[Volker Hilsheimer]

> On 21 Apr 2021, at 22:39, Bernhard Lindner  
> wrote:
> 
> 
>> Personally, I think the exsting QtQuick element should be scrapped and just 
>> focus on QML
>> versions of the existing Widget functionality. I love the QML syntax, hate 
>> that it's not
>> just a layer on top of widgets.
> 
> +100
> 
> Why this wasn't done from the start is one of the hardest puzzles! I ask 
> myself this
> question every time I read the three letters "QML" :-) 


Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
wondering why there are several UI frameworks.

But there are several reasons why things are as they are. Some of them:

* imperative painting

Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs 
like to work. Without a persistent scene graph that is uploaded to the GPU, 
much of the performance you get from a GPU is lost. An animation at 60fps is 
ideally just a draw call on the GPU with some different transformations, not a 
completely new upload of a completely reconstructed scene graph for each frame.

Widgets can draw into a framebuffer texture that can be used, and that allows 
for some integration, but that doesn’t give you great performance.


* integer coordinates and clipping

Widgets work with integer coordinates, which starts to be problematic now that 
we have high-DPI displays. And widgets clip are clipped to their parent 
geometry, which was the right choice for those UIs, but is very limiting and 
requires a lot of complex code to solve conceptually simple problems. Hello 
macOS focus ring.
Quick items do not clip and are not clipped, which gives a lot more freedom in 
how shapes are combined and structured.


* declarative vs imperative APIs

Many widget classes don’t have a declarative-friendly API. Plenty of widget 
properties have side effects on other properties, so the order in which 
properties are set matters. That doesn’t work well in a declarative world.


* weight

Widgets are heavy, often very complex objects. They often come with all bells 
and whistles. QPushButton always has the data structure to support 
QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
feature. That’s ok on desktop machines, it’s not ok on embedded systems.


* complexity and hard to customize

Inheritance and reimplementing are nice concepts on paper and works great if 
you build your own custom widget from a reasonably abstract base class. But if 
you have ever tried to subclass e.g. QTreeWidget to modify how certain 
interactions work, then you know how hard it can be to not break the complex 
states that the default implementations rely on.



So, making widgets work in a declarative, GPU friendly world where ease of 
customisation is more important than standard look’n'feel would have required 
many changes to widgets. Those would have been impossible to make without 
invalidating or breaking a lot of code out there, and still not given us the UI 
components we would have needed.

I’m sure there are opportunities to share more code between widgets and quick 
world esp on the UI framework classes, and with Qt 6 we have taken some steps 
into that direction. But whether the benefits outweigh the risks and effort 
requires a case-by-case evaluation.


Volker

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

Re: [Interest] Question about QtDeclarative Internals

[Volker Hilsheimer]

> On 21 Apr 2021, at 15:48, Alex Shaw  wrote:
> 
> Hello,
> 
> I am relatively new to mailing lists, so if I am doing something wrong here 
> please forgive me.
> 
> Is this the place to ask questions about the internals of Qt modules?
> 
> More specifically:
> In QtDeclarative, can a QV4::ReturnedValue or a QV4::Value be converted into 
> an ExecutableCompilationUnit?
> 
> I'm trying to work on a patch for QJSEngine to allow modules to be registered 
> in C++ (similar to Node.js: import fs from "fs")
> The planned method is something along the lines of:
> void QJSEngine::registerModule(const QString , const QJSValue 
> )
> 
> I can see that behind the scenes, loadModule compiles a URL to an 
> ExecutableCompilationUnit, then saves it to a list of modules for future 
> lookup.
> I thought the easiest way to do what I need is to convert a QJSValue to an 
> internal QV4::Value, and from there into an ExecutableCompilationUnit.
> Is there any way of doing that?
> 

Hi Alex,

Welcome to the list! The “interest" list is primarily useful to discuss 
developing *with* Qt.

The development *of* Qt, which patching of QJSEngine would qualify as, is best 
discussed at

https://lists.qt-project.org/listinfo/development



Cheers,
Volker

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

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

[Volker Hilsheimer]

> Em 15/04/2021 11:57, Volker Hilsheimer escreveu:
>>> On 15 Apr 2021, 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.
>>> 

[…]

>>> In summary, it would seem that my options for the desktop with Qt are two 
>>> self-competing technologies: one "half-dead", one "3/4-baked"... I'd really 
>>> love to be wrong.
>> 
>> TL;DR: Qt Widgets will be with us for a long time, and we’ll continue to 
>> maintain them and make sure that they continue to work and look great on 
>> future versions of the various operating systems as well. There’ll probably 
>> always be applications for which the widget concepts are a perfect fit.
>> 
>> For an increasing amount of applications and environments however, Qt Quick 
>> provides the better architecture, and we see a growing number of Qt Quick 
>> based desktop applications already today, also outside of the KDE 
>> environment. But yes, making Qt Quick a first class toolkit for desktop use 
>> cases is work in progress and there’s a lot of catching up to do. Native 
>> look’n’feel on Windows and macOS was introduced with Qt 6.

> On 15 Apr 2021, at 14:01, Rui Oliveira  wrote:
> You could have sent me the YT link hahah. I already had a Qt account, so 
> whatever. Interesting discussion.

Oh right, I didn’t check YouTube.

> So what do you identify as the missing features of Qt Quick for desktop and 
> what are Qt's priorities and ETAs?

The functionality gap between the ItemViews in Qt Quick and their QWidget-based 
counterparts is something we are working on right now, so expect some 
improvements in Qt 6.2.

A major widget-world feature that is missing in Qt Quick is graphics view. 
That’s not high on our list of priorities right now though, so no ETA.

On the framework side: the layout engine in Qt Quick needs to work better with 
resizable windows. Compared to widgets, what’s missing are thing like 
“minimumSizeHint”, on-demand calculation of sizeHint, height-for-width, size 
policy. Some of that can be done today using attached properties, but it’s not 
a great solution. No immediate plans for that yet, either.


Architecturally, one of the desktop concepts that is challenging in Qt Quick 
are UIs with multiple toplevel windows. This tends to be problematic in a 
GPU-backed scene graph/render loop architecture. Now, most modern desktop 
applications (say, Slack, Spotify, or also Microsoft apps such as Teams or the 
new Outlook) are moving away from “dialogs as toplevel windows”, and even popup 
menus only live within the scene of the main window. That works already with Qt 
Quick as well, but some of the “old way” needs to be possible (for instance, 
app menus on macOS, or system dialogs).

Another challenge is widgets that show content that is significantly larger 
than the viewport. Large text documents for instance. This needs work, the 
scene graph needs to be populated as you scroll through the document, without 
any noticable drop in performance.

We (as The Qt Company at least) plan to spend some time on these architecture 
items after the 6.2 release.


Volker

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

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

[Volker Hilsheimer]

> On 15 Apr 2021, 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.
> 
> 
> 
> And then I looked at Qt, and:
> 
> First thing I have looked at were QWidgets. I feel comfortable staying in the 
> C++ domain. To implement said custom widgets I gave a shot to a class 
> inheriting from QOpenGLWidget. And honestly, the experience wasn't bad at 
> all! 
> 
> But, I feel very hesitant to start a project on QWidgets. It feels like 
> starting a project on dead tech. Although, I did watch Giuseppe D’Angelo's 
> talk in Qt Desktop Days 2020 (slides [1]), and looking at slide 19, there 
> seem to be prospects of evolution. My attention goes especially to 
> "Accelerate widget rendering & compositing through RHI". Will QWidgets really 
> have a RHI backend? And a QRhiWidget option? Or maybe just QWidget and 
> everything HW accelerated? I can dream...
> 
> I know QWidgets are no longer "interesting". Even KDE moved on from them... 
> And I understand that's not where the money is for now... Still, I'd like 
> some comments.
> 
> Now, QML.
> 
> Slide 25 of the same talk mentions native desktop styling for QQC2. I can't 
> find documentations on this. Are they already available yet? Also, in the 
> previous slide, "Planned in Qt 6.x: C++ API for Qt Quick elements". Does this 
> mean Qt Quick *without* QML? 
> 
> Also, in QML it seems to be very hard to have anything native-looking. I 
> looked at Qt Labs Platform [2] and things like the right click menu aren't 
> available on Windows, for example. Are there plans to expand this? 
> 
> 
> 
> Either way, I'm quite divided. I'd like to hear your thoughts and 
> recommendations. 
> 
> In summary, it would seem that my options for the desktop with Qt are two 
> self-competing technologies: one "half-dead", one "3/4-baked"... I'd really 
> love to be wrong.
> 
> 
> 
> Thank you for your time,
> Rui


Hi Rui,

Richard and I had a talk about our plans in that respect at last year’s "Qt 
Goes Virt:Desktop” event. The recording is available here, if you are ok with 
providing your digits to The Qt Company:

https://resources.qt.io/qt-goes-virt-2020/desktop-applications-with-qt-native-styling-and-the-future-3

This outlines the general direction, and the work on this will keep us busy for 
several years to come.

TL;DR: Qt Widgets will be with us for a long time, and we’ll continue to 
maintain them and make sure that they continue to work and look great on future 
versions of the various operating systems as well. There’ll probably always be 
applications for which the widget concepts are a perfect fit.

For an increasing amount of applications and environments however, Qt Quick 
provides the better architecture, and we see a growing number of Qt Quick based 
desktop applications already today, also outside of the KDE environment. But 
yes, making Qt Quick a first class toolkit for desktop use cases is work in 
progress and there’s a lot of catching up to do. Native look’n’feel on Windows 
and macOS was introduced with Qt 6.


Cheers,
Volker


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

Re: [Interest] iOS and openGL

[Volker Hilsheimer]

> On 10 Apr 2021, at 09:02, maitai  wrote:
> 
> Hi,
> 
> I have a QWidget app running on many platforms including iOS, using 
> QGraphicsScene/View, Qt 5.15.2. The scene can contains many items, be 
> rotated, etc.
> 
> We enable openGL QGraphicsview's viewport as it is stated in the 
> documentation, i.e.
> 
>QOpenGLWidget *gl = new QOpenGLWidget();
>QSurfaceFormat format;
>format.setSamples(4);
>gl->setFormat(format);
>setViewport(gl);
> 
> That works pretty well on all platforms and improves the performances, except 
> on iOS (tested on iOS 14), where it is exactly the opposite: all become very 
> very slow even in not complicated situations.
> 
> Is there something we can do to about that?
> 
> I know openGL is deprecated on iOS (replaced by Metal) does Qt supports that?
> 
> Thanks
> Philippe.


Qt 6 supports Metal as one of the backends of the new Qt Rendering Hardware 
Interface (RHI) architecture that the Qt Quick scene graphs uses for rendering.

Qt Widgets (which QGraphicsView is a part of) will continue to use procedural 
painting using the existing paint engines, and not use QRhi.

So the best option for you is to not use the QOpenGLWidget viewport on iOS, 
based on your experience that it’s slower than the default software rasteriser.

Regards,
Volker


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

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Volker Hilsheimer]

> On 1 Apr 2021, at 14:47, Roland Hughes  wrote:
>> PS: Roland, I was looking at your 
>> https://www.theminimumyouneedtoknow.com/agile_book.html page, and judging by 
>> this sentence, I think your review process is broken. You should probably 
>> ask for your money back from your professional editors, or something… :P
>> 
>> "The author of this title has spent over 30 years in IT working on 
>> multi-country corporate applications before there was an Interent, to stock 
>> exchange trading floor systems, desktop applications, and even multiple 
>> medical devices."
>> 
> The book was professionally edited. I put the page together with far less 
> thought than I put into a post on here. You think it is a run-on sentence, so 
> what?

I assume you mean “Internet” when your page says “interent”.


> The book still sells and I've done very little marketing. Other than the 
> occasional mention when answering a question for free, none really.

Congratulations.


> When the justification for letting 12 year old bugs exist in the bug database 
> is:
> 
> that the code was too complex or that fixing the old bug would create new bugs
> 
> The code had just as much review before check-in as the page that you looked 
> at.


That’s probably true; 12 years ago Qt was GPL/commercial only and not an open 
source project with contributors outside of Trolltech. The Windows port was 
commercial only, and we used perforce for version control. We didn’t do any 
formal code reviews.

Yes, there are bugs in Qt where a fix would break existing code that relies on 
current behavior. And yes, there is code in Qt that is fragile, for different 
reasons. The code I wrote 15+ years ago to support Windows XP menu animations 
in Qt is probably not a shiny example of robustness.

But most of it is pretty good, even some of mine, and it makes me proud to have 
been able to contribute to Qt and to work with the incredibly talented people 
in the Qt community for most of my professional career. I’m sorry that you 
don’t like it.


Cheers,
Volker

PS: yes, the oldest open bug in Qt is 
https://bugreports.qt.io/browse/QTBUG-255, reported in 2006.

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

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Volker Hilsheimer]

> On 1 Apr 2021, at 11:55, Roland Hughes  wrote:
> On 4/1/21 12:40 AM, Thiago Macieira wrote:
>> Dropping old platforms has been done since the early 2000s. Everyone who
>> adopted Qt since 3.0 has known of this. It's was not news then and it's not
>> now.
> 
> It is news now.
> 
> During Qt 3.x there were only a few customers, OS/2, and the KDE desktop on 
> fledgling Linux distros.
> 
> Since then, Qt actively pursued the medical device and industrial controls 
> markets. Currently it appears QtC is pursing the automotive market to the 
> exclusion of all else. Despite someone ranting and calling that hearsay 
> that's exactly what it looks like to the customers in the other markets.
> 
> When Qt pursued and penetrated these other markets it had to adjust to the 
> time lines of those markets. These are very long timelines. Fifteen years on 
> average.
> 
> Had Qt only pursued the phone and auto markets, it could have continued on 
> its merry way dropping things whenever the mood struck. The phone and auto 
> markets have about a six month life span before everything is abandoned for 
> the next platform.
> 
> They didn't. The medical device and industrial controls had the deeper 
> pockets. The means the policies and practices of the Qt project must adapt to 
> the market it pursued.


As *The Qt Company* we need to adapt our service offerings to the market we 
want to sell Qt into. We could for instance provide extended lifetime support 
for old Qt versions, and maintain special long-term-support branches of Qt that 
continue to build on old OS versions or hardware platforms or whatever for 
those customers that have deep enough pockets. Perhaps we do that already today 
(I know, I know, it’s April 1st...). Last year we made a reasonably recent Qt 5 
work on a rather ancient Windows XP Embedded setup. It might not have been 
cheap.

But why should the Qt Project have to care? The Qt Project doesn’t sell into 
the medical or industrial automation market.

If a medical device manufacturer makes a technology decision and choses Qt 
based on the policies of Qt "the Open Source” Project, then I’ll trust that 
they know what they are doing. And if they are not happy with how Qt “the Open 
Source” Project operates, then I’m sure they’ll check what The Qt Company can 
provide as a commercial service that fits their needs.

Perhaps that happens frequently already. That would explain the recent 
development of the Qt Company stock price...


Volker


PS: Roland, I was looking at your 
https://www.theminimumyouneedtoknow.com/agile_book.html page, and judging by 
this sentence, I think your review process is broken. You should probably ask 
for your money back from your professional editors, or something… :P

"The author of this title has spent over 30 years in IT working on 
multi-country corporate applications before there was an Interent, to stock 
exchange trading floor systems, desktop applications, and even multiple medical 
devices."

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

Re: [Interest] The willy-nilly deletion of convenience, methods

[Volker Hilsheimer]

> On 24 Mar 2021, at 15:06, eric.fedosej...@gmail.com wrote:
> 
> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Wednesday, March 24, 2021 4:06 AM
> 
>> For feedback regarding the licensing changes made that context (including 
>> 5.15), I’d suggest you go back to the respective email thread if you just 
>> want to vent, or call your sales rep in The Qt Company.
> 
> Translation: open source users should just shut up and go away. Bold move, 
> let's see how it works out for you.


I think it would work quite wonderfully if the licensing discussion would 
happen in the thread with “license” in the subject, while the discussion about 
perhaps overzealous deletion of methods would happen in the thread that has 
“deletion of methods” in the subject.


Cheers,
Volker

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

Re: [Interest] The willy-nilly deletion of convenience,, methods

[Volker Hilsheimer]

> On 24 Mar 2021, at 13:20, Roland Hughes  wrote:
>>> Who said anything about "ever?"  Or even "last year."  Have you never built 
>>> anything that is actually finished, and stays finished, and relevant, and 
>>> functional for 10, 20, 30 years?  Granted, if I get 10 years of use out of 
>>> anything built in this century, I do consider it a minor victory.  So maybe 
>>> that's my answer.
>>> 
>> There are evidently (form what has been written here, and from my personal 
>> experience of working in and with financial, medical, and telko) industries 
>> that prefer 30 year old security issues in their devices over establishing a 
>> process that allows them to continuously update their software stack. In 
>> which case, yes I personally do think they are missing the point of 
>> “software”, and I’m happy that our way of developing Qt is not constrained 
>> by those industries.
> Those would be your customers. 30 year old security issues tend to be easily 
> plugged or otherwise defended against. There is no defense against the 
> relentless stream of new security vulnerabilities, bugs, and crashes brought 
> about by continuous integration and deployment.


The research done by e.g. DORA around continuous deployment, including in 
safety critical environments, tells a different story than your anecdotes.

https://www.devops-research.com/research.html


>>  To be honest, many of those bugs are really hard to fix without breaking 
>> anything else, so often we decide that a known, well-documented bug is 
>> preferable to a bunch of new, unknown bugs that a fix might introduce.
>> 
> You knowingly create 30 year old security issues and you diss your customers 
> who have worked around theirs.
> 
> :P


Knowingly? That’s a bit much, even from you, Roland.


>> FWIW, so far the substance of this discussion seems to boil down to
>> 
>> * the old QList implementation being gone
>> * toContainer convenience methods removed
>> * references to QHash entries no longer stable when the hash is mutated
>> 
> You forgot customer abandonment

Talk to your sales rep.

> death of OpenSource LTS

Get the patches you need from the dev branch.

> Qt 6 being useless
> QML needing to be ripped out.

Don’t use it.

I don’t consider this substance. Go back to the original thread if you want to 
spread FUD, Roland.

I started a new one were we can focus on substantial and constructive 
conversation about what needs to be brought back to make Qt 6 better and 
porting easier.


Volker





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

Re: [Interest] The willy-nilly deletion of convenience, methods

[Volker Hilsheimer]

> On 24 Mar 2021, at 08:43, Max Paperno  wrote:
> On 3/23/2021 11:44 AM, Volker Hilsheimer wrote:
> ...
>> I personally wonder why people that never want to change what they built 
>> last year want to develop software development. Isn’t that what makes 
>> building stuff out of bits and ideas so much more interesting  than building 
>> stuff out of sticks and stones?
> 
> Wow. Really?  First of all, sheesh, generalize much?


Yes, isn’t that what this thread is for?

“Qt never fixes any bugs”
“QML is horrible, we need to rip it out”
“None of the people that have worked on Qt for the last 25 years can be part of 
this"
“Every change is harmful"

:P

> Who said anything about "ever?"  Or even "last year."  Have you never built 
> anything that is actually finished, and stays finished, and relevant, and 
> functional for 10, 20, 30 years?  Granted, if I get 10 years of use out of 
> anything built in this century, I do consider it a minor victory.  So maybe 
> that's my answer.


There are evidently (form what has been written here, and from my personal 
experience of working in and with financial, medical, and telko) industries 
that prefer 30 year old security issues in their devices over establishing a 
process that allows them to continuously update their software stack. In which 
case, yes I personally do think they are missing the point of “software”, and 
I’m happy that our way of developing Qt is not constrained by those industries.

Yes it’s great if stuff that some of the stuff I built 30 years ago still works 
(at least I assume it does; I’d have to find a working floppy drive, and a DOS 
emulator with Turbo Pascal). But then I don’t expect it to look and feel great 
on the latest macOS version.

I am pretty certain that - as long as you don’t upgrade any part of your 
software stack including the OS - then the Qt application you build today will 
run just as fine in 30 years as it does today.


> Clearly Qt devs don't find fixing 5000+ outstanding P2+ bugs all that 
> interesting either.

According to JIRA, we (the entire community of contributors) addressed 240 
issues reported to us by customers through our support team in the last 90 
days. And a whole bunch more that were reported by Open Source users.

Yes there are plenty more to go around. Yes, some of them are pretty old. To be 
honest, many of those bugs are really hard to fix without breaking anything 
else, so often we decide that a known, well-documented bug is preferable to a 
bunch of new, unknown bugs that a fix might introduce.


> And I personally find building things out of "sticks and stones" immensely 
> interesting and satisfying (assuming it works in the end :). There's no undo 
> or backups, just your skill in the moment. Not to mention very practical, as 
> all those bits and ideas would have nowhere to go otherwise. Comparing 
> physical building to digital creation (which I also enjoy a lot) is only 
> relevant in the most basic sense of "building" in that both require some 
> plan/vision and tools/skills to execute it (and in the end hopefully you get 
> something useful or enjoyable). Otherwise, not even close.


Same here. Just digging a hole in the garden can be very satisfying after a day 
of writing (code, or emails) :P


> I'd go on to explain that not everyone who uses Qt, lives and breathes Qt, 
> finds it endlessly fascinating, nor has time to conform to your strict and 
> relentless release schedule to evaluate every nuance of massive API changes, 
> etc, etc.


Apropos generalising. Are we still talking about the first release in 7 years 
where APIs were changed?

FWIW, so far the substance of this discussion seems to boil down to

* the old QList implementation being gone
* toContainer convenience methods removed
* references to QHash entries no longer stable when the hash is mutated


> You rushed Qt6 out the door, contrary to what even some of your core 
> contributors suggested, with the premise that "now we'll get some feedback."  
> Well there you go, you're getting it now. For many/most I think Qt is a tool, 
> like a very fancy hammer. If Estwing decided to remove the claw from their 
> "new streamlined" framing hammers, then made the clawed hammers cost $1000, I 
> bet they'd get about the same reaction as you're getting now.


Maurice gave the rationale on why Qt 6 was released with a subset of core 
modules. For the technical side of things, we are getting feedback, it’s 
useful, and it’s mostly encouraging.

For feedback regarding the licensing changes made that context (including 
5.15), I’d suggest you go back to the respective email thread if you just want 
to vent, or call your sales rep in The Qt Company.


Cheers,
Volker

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

Re: [Interest] The willy-nilly deletion of convenience, methods

[Volker Hilsheimer]

> On 23 Mar 2021, at 15:49, Matthew Woehlke  wrote:
> 
> On 23/03/2021 10.36, Benjamen Meyer via Interest wrote:
>> On 3/23/21 10:09 AM, Matthew Woehlke wrote:
>>> Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any
>>> change, not just on a mailing list, but in person. Anyone can, in theory
>>> (in practice, depending on where you live, there may be a non-trivial
>>> membership fee required) *vote* against a change. We, as the committee,
>>> generally try to be considerate of the community when making changes,
>>> and there is quite a lot of emphasis on not breaking existing code, even
>>> as far back as C++98.
>> How many C++ devs are on those?
> 
> Hundreds, which is probably more than the number of people making decisions 
> for Qt.
> 
>> Likely only those whose companies are paying them to be, and a few
>> that got there via academics (I've personally known and worked with
>> one person; outside of the folks I've seen here on the Qt lists.)
> 
> Even so, that's a lower bar than "you must be an employee of TQtC" (and even 
> that is probably not sufficient). The bar also happens to be much lower right 
> now due to COVID, since there are no in-person meetings happening.


I wished I had seen the level of energy y’all are putting right now into this 
email thread over the last two years when we discussed where to go with Qt 6, 
and when the work actually happened. Code and header reviews are all done in 
public, and it’s usually the same small handful of people that put an effort 
into those. And I’m extremely grateful to those people who do, and there were 
tons of occasion during the Qt 6 development where someone outside The Qt 
Company criticised a change, perhaps even -2’ed it, and made things better by 
putting their git (or at least gerrit) credentials next to their opinion.


Of course, The Qt Company paying several dozens of software engineers to work 
full-time on the various parts of Qt (the framework, the tools, the CI system) 
has a big momentum, and yes we have colleagues that can approve changes 
quickly. But the deprecations that seem to cause the most controversy right now 
- like removing toContainer helpers - were not implemented by a TQtC employee, 
and neither is the maintainer of the Qt Core module on TQtC payroll.

As the one who killed QDesktopWidget and a bunch of other, previously 
deprecated APIs for Qt 6 - I personally prefer to not have my code compile 
anymore if it wouldn't work as it needs to anyway. That’s better than code that 
builds, but doesn’t work, or doesn’t scale, or prevents long-term improvements. 
Yes, that’s to some degree my personal opinion, but it’s evidently also the 
general principle of The Qt Project (even if not written down in some quip or 
manifest) and it’s also the opinion of the folks in the Qt Project that +2’ed 
my changes.


Maybe ideally nobody would have to change anything ever, and we only get to use 
new things that work perfectly with the old stuff all the time. But knowing 
about what it costs to build software this way, we have decided that this is 
not how we are building Qt. This is not exactly a surprise, after 25 years and 
6 major Qt releases, all of which have removed old APIs.


> In any case, you've made an unsubstantiated allegation that the committee 
> does not care about C++ users.


And you have made the unsubstantiated claim that people outside of The Qt 
Company have no influence on the direction The Qt Project is (technically) 
taking - yes, the licensing shenanigans excluded.


> Please provide evidence to back that up. So far, all I've seen is "C++ also 
> deprecates stuff". You haven't shown that the deprecations are actually 
> *harmful* to the C++ community on anything like the scale to which Qt's 
> recent changes have been harmful.


Personally, I’m siding with those folks in the committee that believe that not 
changing things (ref ABI discussion) is more harmful than if we’d be able to 
fix now and again what is objectively broken.


> Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, 
> however, have caused major pain. Now you are apparently claiming that C++ is 
> "just as bad", but I have yet to see that claim substantiated.


I personally wonder why people that never want to change what they built last 
year want to develop software development. Isn’t that what makes building stuff 
out of bits and ideas so much more interesting  than building stuff out of 
sticks and stones?


Volker


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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Volker Hilsheimer]

> On 20 Mar 2021, at 14:22, Roland Hughes  wrote:
> 
> I grepped the archive this morning. Hopefully Andre's email still works. I 
> had hoped he was still watching on here and would pipe up. Maybe he and his 
> company abandoned Qt as well after the June 2020 exchange?
> 
> Here is a scrape of one of the messages in the thread from the archive.
> 
> Subject: [Interest] Set manipulation in Qt 6
> In-Reply-To: <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
> References: 
> 
>  <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
> Message-ID: <20200621172617.GB11000@klara>
> 
> On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest 
> wrote:
> > With my hat of the guy going around and deprecating toSet() and friends: the
> > rationale for these deprecations is the terrible code that those methods
> > encourage, and the
> 
> While I sympathize to some degree with the performance motivation behind this
> kind of removal of convenience functionality this has to be put into 
> perspective
> of the price you charge:
> 
> We had to spent a significant amount of our time during the last year to
> keep up with the deprecations within the last releases in the 5.x series.
> This includes re-inventing parts of the abandoned qalgorithm as part of
> our code base.
> 
> The toSet/toList changes alone involved touching 200+ locations in the code
> base and I am not aware of even a single noticable performance improvement
> as a result.
> 
> A back-of-the-envelope calculation with generous assumptions on user count and
> usage frequency makes me believe that the accumulated win on saved computer
> time does not even offset the amount of manual work that had to be spent
> on these changes.
> 
> On top of that goes the more complex and consequently harder to read 
> re-written
> code, plus the chance of introduction of actual regressions in the code.
> 
> The latter is btw not just theoretical, I noticed only last Friday the hard
> way that blindly replacing QLinkedList by std::list can transform previously
> correct and working code into a crash. Having to thoroughly check each and
> every such replacement only to get in the best case the same functionality
> as before is an awful value proposition.
> 
> To summarize: If you despise wasting cycles for convenience that's fine.
> Assuming that everyone else shares this preference is already odd. Making
> other people pay for this is simply wrong.
> 
> > (Which brings me to my second crusade, try stop encouraging the usage of Qt
> > containers, as their API is full of holes and doesn't play nice with
> > algorithms or ranges. But it's enough for this mail.)
> 
> If you want to use Qt without Qt that's fine. But please stop making other
> people suffer from your choices.
> 
> Andre'


Andre being one of the Qt Creator developers is of course in a very special 
place. Not only because the Qt Creator team has decided that they want a single 
code base that builds against both Qt 5 and Qt 6. Doing so as Qt 6 was being 
developed of course resulted in more churn - but also in good feedback. Either 
way, it is perhaps not the most representative porting experience.

Roland, if you have specific 1st hand porting experience to share and 
constructive contributions to make about which APIs we should bring back 
because, then please do so.

Cheers,
Volker


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

Re: [Interest] The willy-nilly deletion of convenience methods

[Volker Hilsheimer]

> On 20 Mar 2021, at 01:14, Thorsten Glaser  wrote:
> 
> On Fri, 19 Mar 2021, Volker Hilsheimer wrote:
> 
>> Do you have any particular classes in mind?
> 
> There’s the deprecation of QApplication::desktop()->screen()->winId()
> which is necessary for command-line programs accessing the KDE wallet
> I wrote about in November assuming that someone here has connections
> to the KDE project and could find out how to best fix this together.
> For now, the program in question ignores that deprecation warning :/
> plus there won’t be a Qt 6 in Debian in near future anyway.
> 
> bye,
> //mirabilos


My gut feeling is that esp for command line applications, a call equivalent to

$ xwininfo -d $DISPLAY -root

will be a better solution than creating a QApplication (rather than a 
QCoreApplication) to query the root window ID.

Alternatively, use Xlib APIs.

If there’s really no other way than adding something like 
QScreen::rootWindowId()  to Qt, then we can evaluate that, but it’s a niche 
problem that didn’t justify that we keep the outdated QDesktopWidget, or 
concepts that don’t translate well to other platforms around for now.


Cheers,
Volker

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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Volker Hilsheimer]

> On 19 Mar 2021, at 14:34, Roland Hughes  wrote:
> 
> 
> On 3/19/21 7:51 AM, Volker Hilsheimer wrote:
>>> On 19 Mar 2021, at 12:12, Roland Hughes  wrote:
>>> 
>>> 
>>> 
>>> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
>>>> Il 18/03/21 12:41, Christian Gagneraud ha scritto:
>>>> 
>>>>> My main grief is that Qt doesn't seem to care about C++.
>>>>> What was their last contribution to the standard?
>>>>> 
>>>> Apart from hiring the ex-chair of the WG21 Evolution Working Group?
>>>> 
>>>> (Can we stop with the FUD please?)
>>>> 
>>> Can we stop the willy-nilly deletion of existing convenience methods 
>>> currently used in products in the field?
>>> -- 
>>> Roland Hughes, President
>> Hey Roland,
>> 
>> Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the 
>> API from bloating too much. We can add convenience wrappers and overloads 
>> when we see that they are really needed.
>> 
>> We might have gone a bit far in some cases, but the porting experiences I’ve 
>> read so far suggest that by and large it has been a rather decent experience.
>> 
>> Do you have any particular classes in mind?
>> 
>> Volker
>> 
> I'm sure the person who was complaining repeatedly to Giuseppe will pipe up 
> if they are still using Qt. That was a long thread in here last year. It lead 
> to other long threads.
> 
> You cannot remove existing functionality without surveying the user base to 
> find out if it is used. That person took a big hit with a lot of needless 
> retesting and coding because of a willy-nilly removal.
> 
> Once you ship it, you can't remove it, until __after__ it dies on the field. 
> Doesn't matter what "it" is. This is called product stability. I do not know 
> if it was an FDA regulated product that impacted. I do know that if it was 
> FDA regulated the odds of them being able to slip it through the "minor 
> enhancement" (don't remember the official name) testing and approval path 
> with that level of modification would be slim. That would mean lots of 
> additional expense for them and everyone else impacted by the removal.
> 
> This also lead to a lengthy discussion about API stability. You can also find 
> that in the archives for last year and probably in 2019 as well.
> 
> For the SAFETY world where human/animal life is at Risk, LTS is roughly 20 
> years (over 30 in some markets) and STS (Short Term Support) is 7-10 years.
> 
> Thinning out the API may have been a conscious decisions, but I never saw any 
> messages on this list about things you were thinking about killing. Granted I 
> get this in digest form and mostly skim the subjects for something of 
> interest to me. Judging from the shock and length of that previous discussion 
> nobody on here saw any such messages either. From a customer base perspective 
> these decisions were made in a vacuum and are helping to speed the complete 
> abandonment of Qt.


Ok. API stability on the one hand, and keeping things maintainable and 
un-bloated over a long time on the other, is of course a tradeoff. Different 
industries will have different preferences, but the path we have chose for Qt 
over the last 25 years seems to not have been completely wrong, even for folks 
building safety critical systems.

That there are long threads on controversial topics is often a good thing. esp 
if they are followed by code contributions from the people that care. Many of 
the discussions we had last year about e.g. the APIs of container and string 
classes (most of those on the development list where the development OF Qt is 
discussed [1]) have definitely resulted in better decisions for Qt 6.0.

Volker

[1] https://lists.qt-project.org/listinfo/development

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

[Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Volker Hilsheimer]

> On 19 Mar 2021, at 12:12, Roland Hughes  wrote:
> 
> 
> 
> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
>> Il 18/03/21 12:41, Christian Gagneraud ha scritto:
>> 
>>> My main grief is that Qt doesn't seem to care about C++.
>>> What was their last contribution to the standard?
>>> 
>> Apart from hiring the ex-chair of the WG21 Evolution Working Group?
>> 
>> (Can we stop with the FUD please?)
>> 
> Can we stop the willy-nilly deletion of existing convenience methods 
> currently used in products in the field?
> -- 
> Roland Hughes, President

Hey Roland,

Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the 
API from bloating too much. We can add convenience wrappers and overloads when 
we see that they are really needed.

We might have gone a bit far in some cases, but the porting experiences I’ve 
read so far suggest that by and large it has been a rather decent experience.

Do you have any particular classes in mind?

Volker



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

Re: [Interest] Unable to drag scrollbar in scroll area in Qt 5.6.3 widgets application

[Volker Hilsheimer]

Drag events are related to Drag’n’Drop, and you rarely drag from or drop onto a 
scroll bar.

The Qt documentation is quite clear about the role of those event types, I 
think:

https://doc.qt.io/qt-5/qevent.html#Type-enum
https://doc.qt.io/qt-5/qdropevent.html


Volker


> On 24 Nov 2020, at 11:48, Ramakanth Kesireddy  wrote:
> 
> One question..Found dragging scrollbar triggers MouseMove instead of drag 
> events..When we drag scrollbar, is it expected to trigger 
> DragEnter,DragMove,DragLeave instead(as verified in the event filter) in the 
> custom QTableView which sets QScrollbar? 
> 
> Best Regards,
> Ramakanth
> 
> On Tue, 24 Nov, 2020, 14:38 Ramakanth Kesireddy,  wrote:
> Sure.. Thanks for your mail. Shall test on the latest Qt.
> The issue is reproduced on both X11(ubuntu desktop) and linuxFB with tslib as 
> backend.
> 
> On Tue, 24 Nov, 2020, 13:16 Thiago Macieira,  
> wrote:
> On Monday, 23 November 2020 21:32:10 PST Ramakanth Kesireddy wrote:
> > UI Application is Qt 5.6.3 widgets based on 4.14 linux kernel built with
> > yocto meta-qt5 recipes.
> 
> Please retest with the latest first (latest Qt and latest Yocto).
> 
> And if you're not using X11, please be explicit on what backend it is and 
> what 
> mouse input driver you're using.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] Window ID of the current screen (root window)?

[Volker Hilsheimer]

> On 20 Nov 2020, at 03:42, mirabilos  wrote:
> 
> On Thu, 19 Nov 2020, Thiago Macieira wrote:
> 
>> Then pass nothing.
> 
> That reportedly causes problems with kwallet.
> 
>> If the application is run non-interactively and possibly 
>> without GUI, then it doesn't have access window IDs.
> 
> It does run with a GUI, but the only UI elements it has are those
> rendered by the kwallet service (things like the unlock prompt);
> it requires a GUI display even if itself only uses stdio and command
> line arguments.
> 
>> What application are you launching? Because KWallet is a D-Bus service and 
>> kwalletmanager doesn't require window IDs.
> 
> http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/code/kwalletcli/kwif5.cc?rev=1.2
> 
> Search for openWallet there.
> 
> The window ID was added by the person who ported this to KDE 5;
> apparently, this is necessary now.
> 
> Thanks,
> //mirabilos


In Qt 6 there is no more Qt API to get the X11 root window for a display (also 
note that QDesktopWidget as a whole is gone).

So, you either have to go native if you rely on X11 specific data structures 
(which the code does anyway, in verifying that there is a DISPLAY environment 
variable), or pass a pointer to (or index of) a QScreen if you want to place a 
UI on a specific display.


Volker

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

Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)

[Volker Hilsheimer]

> On 25 Sep 2020, at 21:26, Giuseppe D'Angelo via Interest 
>  wrote:
> 
> Il 24/09/20 17:55, Rainer Wiesenfarth ha scritto:
>> - if I take the application built and running without this issue with Qt 
>> 5.12.5 and replace the DLLs with those from Qt 5.15.0, the issue appears. 
>> That means there is a change in the event handling between 5.12.5 and 5.15.0 
>> that causes the issue to appear.
> 
> It's super hard telling what might be going wrong without a testcase.
> 
> I'd anyway start by using 5.15.1/2 (not 0) and actually recompiling the 
> application, just to exclude subtle binary compatibility breaks.
> 
> You may also want to inspect the event posting and delivery (e.g. by 
> overriding QCA::notify(); and/or by using ETW tracing; and/or by posting and 
> dispatching your custom "metacall" events instead of using a queued 
> invocation in the same thread).
> 
> HTH,
> 
> -- 
> Giuseppe D’Angelo


If none of the previous hints help, can you share more info about the event 
loop of the thread in which the receiving object lives?

There have been changes to the event loop implementation on Windows in Qt 5.15, 
such as

* 81408c0e76616b127c46779dc14bbcf084a3d87b
* e0d80167c18b5a71acf4dac59f3e6f37292fa397

to better the integration with foreign event loops, but you should updating to 
5.15.1 which has e.g

fb6f62354ff8d29152db7cfa479b2689a25ae7a9 which fixes 
https://bugreports.qt.io/browse/QTBUG-85981

to fix one reported regression in such a scenario.

Volker

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

Re: [Interest] Three-file modules vs. moc

[Volker Hilsheimer]

> On 27 Aug 2020, at 14:42, Bernhard Lindner  
> wrote:
> 
> Hi!
> 
>> Can you make an example of your structure (what's exactly in each of the 
>> three files)? It's not entirely clear.
> 
> Ok, I attached an example of a module containing some pseudo code. Please 
> tell me if you
> need more information.
> 
>> You might also use a custom extra compiler -- that still invokes moc, 
>> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
>> and so on...
> 
> Hm, I see. Has something like that been done before, is there code I could 
> reuse?

I wonder how clients of the class declared in the .hpp file can use that class 
at all. Unless I am missing something, they won’t be able to (at least not in 
the general case) unless they also include the .inl file.

Wouldn’t it be simplier to #include the inl file in the hpp file? That way you 
still have separation of declaration and definition on a file-level, but don’t 
expose users of your C++ headers (including moc) to your way of organizing 
things.


Volker

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

Re: [Interest] adding widget into a mousePressEvent

[Volker Hilsheimer]

You have to show widgets that you add to parents that are already visible.
Cheers,
Volker



From: Interest  on behalf of Carlos Agon 

Sent: Saturday, June 20, 2020 10:28:46 AM
To: interest@qt-project.org 
Subject: [Interest] adding widget into a mousePressEvent

Hello

I would like to add a button to my view at each time I click, but my code 
doesn't work, it prints the message "click enter" but nothing is added. What is 
wrong with this code ?

thanks

Carlos (newbie at this list)

==

class ShView :public QFrame {
protected:
   void mousePressEvent(QMouseEvent *event) override;
}

void ShView::mousePressEvent(QMouseEvent *event) {
   std::cout << " click enter " << std::endl;
   QPushButton * child = new QPushButton ("push",this);
}
___
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