Re: [Interest] Update widget geometry BEFORE window shown

[John Weeks]

Well, I wasn't going to say anything ("If you don’ know how to answer it, 
please don’t chime in, thanks.")

In my experience, Qt doesn't maintain a good notion of a window's size until 
it's shown. But you are guaranteed a Resize event as the window is being shown, 
so if you can manage it, you need to handle the Resize event and do your 
polishing and layouting there.

In fact, I had for a while a function called ShowAndHideInvisibly(); the 
important part of it was like this:
>   getQWidget()->setAttribute(Qt::WA_DontShowOnScreen, true);
>   WMshow();
>   WMhide();
>   getQWidget()->setAttribute(Qt::WA_DontShowOnScreen, false);

Maybe that helps. Setting the attribute prevents the screen flash.

-John Weeks
WaveMetrics, Inc.

> On May 23, 2024, at 3:52 PM, 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
> ___
> 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] spurious breakpoints in Qt Creator

[John Weeks]

I haven't done any Qt development for Linux, but I know on other platforms it's 
possible to set a preference to break on exceptions, or module loads and 
unloads, and other such events. Somewhere I believe you can request a break 
when main() is entered, too.

> On May 15, 2022, at 12:44 PM, Matej Košík  wrote:
> 
> Hi,
> 
> While using Qt Creator, I noticed that it generates "spurious breakpoints".
> 
> How to reproduce:
> - I start Qt Creator
> - I generate a new project
>  (Qt Widgets Application with QMainWindow as a base class)
> - from the menu I choose
>  - Debug
>- Start Debugging
>  - Start debugging of startup project
> 
> then the debugged project first stops in "gtk3/main.cpp" and then stops
> in other places.
> 
> When I let the program continue, it then stops again in the file
> "ico/main.cpp".
> 
> When I let the program continue, it then stops again in the file
> "pdf/main.cpp".
> 
> I guess that I am doing something wrong, but I am unable to figure out
> what. Any help is welcome. I would like the program to stop only in
> breakpoints defined by me.
> 
> I am using:
> - Linux (version 5.10.0-14-amd64)
> - GNOME (version 3.38.5)
> - Qt Creator (4.14.1)
> - Qt (version 6.3 compiled from source)
> _______
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John Weeks

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

[Interest] fixit in Creator 7.01

[John Weeks]

Our old code has tons of assignments inside if statements, like:
if (err = somefunction())
return err;

These are flagged by the clangd suggesting that it should be either
if ( (err = somefunction()) )
or
if (err == somefunction())

In the past, if you left-clicked on the little light bulb at the end of the 
line, it would put up a menu of fixits, offering a choice of those two fixes. 
In 7.01, when I left-click, it simply goes ahead and applies the *second* fix 
without presenting a choice. That, of course, creates a very hard-to-see bug.

I can just barely see where someone might think this change is a good idea, but 
it seems more likely to be a bug. Thought I would ask before filing a bug, as 
I'm not very good at searching the bugs data base.

At one point, I clicked on the yellow triangle in the left margin and got the 
little fixit widget. I clicked on the one I wanted (adding parens) and it 
applied BOTH fixes!

-John Weeks

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

[Interest] debugging on Macintosh

[John Weeks]

I recently lost the ability to debug on my Macintosh. To be sure, we are 
building with an oldish Xcode and a new Qt Creator. This morning, though, I 
downloaded Qt Creator 7.01. For a brief, shining moment, I was able to break at 
a breakpoint, single-step and all the rest. Then I tried again. Gone again. The 
breakpoints while running still have the X on them.

Mac OS: 10.14.6
Xcode: 10.3
Qt Creator: 7.01

What should I be checking? The fact that I was able to debug briefly today 
suggests that there is some setting or, or... something that could be changed 
to restore my ability to debug.

-John Weeks

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

[Interest] alphabetize the symbol menu?

[John Weeks]

With the clangd code model in the latest versions of Qt Creator, we seem to 
have lost the ability to order the menu of symbols in an editor window 
alphabetically. That would be the menu in the bar above the area holding editor 
windows and views.

Am I missing something?

-John Weeks

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

Re: [Interest] QTextLayout::setPreeditArea()

[John Weeks]

Maybe something related to an input method? Input methods are used for things 
like composing Japanese characters.

-John Weeks

> 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

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

Re: [Interest] semi-modal dialog

[John Weeks]

We do something similar- we make it possible to put up a control panel (a 
special type of window in our application) that allows the user to interact in 
certain ways with one other window and no others. We do it with some very hairy 
code that probably would make Thiago throw up.

We fake the modal nature of this partially modal window by installing an event 
filter on the application. Then we just block all the events that shouldn't get 
through. Getting the choice of events right can be very tricky! The ugliest bit 
is responding to window activation to force the active window back to the one 
we want to be active.

Hopefully, someone has a better solution to this problem!

> On Jul 29, 2021, at 3:21 PM, Scott Bloom  wrote:
> 
> Here is my problem.
>  
> I have a progress dialog, that I need to be able to use as a modal dialog 
> with respect to the main window (a QMainWindow class, which is also its 
> parent widget).
>  
> But, I need to still be able to minimize the main application and even move 
> it.
>  
> Any ideas on the best way to implement something like this?
> 
> Scott
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John Weeks

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

Re: [Interest] qSort replacement

[John Weeks]

Lambdas as predicates are supported in C++11, too.

> On Jul 21, 2021, at 9:22 AM, Rainer Wiesenfarth 
>  wrote:
> 
> On Wed, Jul 21, 2021 at 6:07 PM Joshua Grauman  wrote:
> [...] I can't figure out how to 
> use std::sort to sort a QList with a custom compare function. [...]
> bool variantLessThan(const QVariant , const QVariant )
> {
> return v1.toString() < v2.toString();
> }
> 
> qSort(fieldsList.begin(), fieldsList.end(), variantLessThan);
> [...]
> 
> If you are using C++17 you may also use lambdas:
> 
> std::sort(fieldsList.begin(), fieldsList.end(), [](const QVariant , const 
> QVariant ) {
> return v1.toString() < v2.toString();
> });
> 
> (untested)
> 
> Cheers, Rainer
> 
> -- 
> Software Engineer | Trimble Imaging Division
> Rotebühlstraße 81 | 70178 Stuttgart | Germany
> Office +49 711 22881 0 | Fax +49 711 22881 11
> http://www.trimble.com/imaging/ | http://www.inpho.de/
> 
> Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
> Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
> Geschäftsführer: Rob Reeder, Jürgen Kesper
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John Weeks

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

[Interest] Security message when I download Qt Creator?

[John Weeks]

I just downloaded the latest Qt Creator (I keep hoping a new update will fix 
the Application Output pane's buffering problem). Chrome on Mac OS 10.14.6 
wouldn't download it because "the file cannot be downloaded securely". Is this 
a Chrome issue, or was the dmg not marked properly, or perhaps this happens 
with any dmg these days? I did ultimately manage to download it by 
right-clicking, selecting Save Link As and then clicking the status tile at the 
bottom of the window, where there was a choice to go ahead anyway.

-John Weeks

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

Re: [Interest] Qt Creator debugger does not flush "Application Output" on every log call?

[John Weeks]

Yay I've posted about this myself...

I wish I could vote for your bug report many times.

> On Sep 20, 2020, at 1:13 PM, David M. Cotter  wrote:
> 
> Do you develop on mac?
> 
> Do you print stuff to console (qDebug) to aid with debugging?
> 
> When you hit a breakpoint, do you find that, quite often, your log hasn't 
> been flushed? ie: you can't see the latest logging, the "Application Output" 
> is stuck somewhere in the past...
> 
> Does this happen to you? Seems like a bug.
> 
> If this drives you nuts, please upvote this bug i've filed. Thanks.
> 
> 
> -dave
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John Weeks
WaveMetrics, Inc.

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

[Interest] Bug in QCodoaWindow?

[John Weeks]

Isn't this a bug?

 bool QCocoaWindow::isTransitioningToFullScreen() const
{
NSWindow *window = m_view.window;
return window.styleMask & NSWindowStyleMaskFullScreen && 
!window.qt_fullScreen;
}

Seems like the bitwise & needs parens.

This is from Qt 5.12.9. Haven't checked Qt 5.15.

-John Weeks
WaveMetrics, Inc.

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

Re: [Interest] macOS Big Sur ARM Build

[John Weeks]

At the point where Apple almost released 64-bit Carbon, but reversed course and 
made us all switch to writing things with funny square brackets instead, Carbon 
had been largely ported to 64 bits. There is still quite a bit of Carbon under 
the hood in Cocoa.

-John Weeks
WaveMetrics, Inc.

> On Jun 24, 2020, at 8:50 AM, David M. Cotter  wrote:
> 
>> Apple ... said that they are still supporting carbon ... on the ARM based 
>> Macs
> 
> wait what?
> 
> reference please?
> 
> carbon is 32bit. 32bit is dead on Catalina, right? and Big Sur is 
> post-catalina.  so... have i missed something?
> ___
> 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] how to get 3 pixel focus ring?

[John Weeks]

One thing to be aware of when using QMacStyle or QWindowsStyle is that they are 
trying to emulate the Macintosh or Windows mandated look. The blue focus ring 
is a Macintosh thing, and like many things Apple, it comes in one size. The 
width of the blue line is mandated.

On Windows, when I ran your test, it looks like you are getting the standard 
Windows dotted-line focus ring. Usually it's a bit inset from the edges of the 
edit box, though. Once again, QWindowsStyle is giving you the Windows look, and 
that's it.

You might try Fusion style, we have found that the look isn't bad, but it 
doesn't look like either Windows or Macintosh.

Hope this helps

-John Weeks

> On Jun 8, 2020, at 12:48 PM, David M. Cotter  wrote:
> 
> can anyone explain why tree view looks fine but  table view only has 1 pixel?
> 
> @adam did you download the example project? it's trivial to run and you can 
> test several implementations.  which impl would be used with your suggestion 
> of PM_FocusFrame margins?
> and do you have maybe example code to implement your suggestion?  
> 
> part of my question is: is this a bug in Qt ? because IMHO "QFocusFrame" 
> should "just work", and why does it NOT?
> 
> or setting the style to 3 px should "just work" and why does it NOT work but 
> only for certain widgets?
> 
> you'd think that QFocusFrame would *manage* the clipping properly?
> 
> or the doc should be more clear, with sample code, cuz i've read the doc 
> several times and am no further along :(
> 
> any help would be greatly appreciated!  if you like karaoke, i have an app 
> for you ;-)
> 
> -dave
> 
>> On Jun 8, 2020, at 5:18 AM, Adam Light  wrote:
>> 
>> On Sun, Jun 7, 2020 at 2:21 PM David M. Cotter  wrote:
>> i have an example project (see below), that tries 6 different 
>> implementations, attempts to make the focus ring 3 pix wide. None of them 
>> work on windows, and only one of them PARTIALLY works on mac. What i want is 
>> the style you get around a text edit on mac, but i want that style on ALL 
>> widgets, and i want it on windows too.
>> 
>> anyone have any idea how i can accomplish this?
>> 
>> It might be as simple as returning a different value for 
>> QStyle::PM_FocusFrameHMargin and QStyle::PM_FocusFrameVMargin in a 
>> QStyle::pixelMetric or QProxyStyle::pixelMetric implementaton. If you're 
>> using one of the standard styles then it's pretty simple to create and use a 
>> QProxyStyle class to tweak pixel metrics and other aspects of the style.
>> 
>> If that doesn't work you may be able to reimplement 
>> Q[Proxy]Style::drawControl for element QStyle::CE_FocusFrame and handle the 
>> drawing of the focus frame itself.
>> 
>> One thing to watch out for is that making QStyle::PM_FocusFrameHMargin and 
>> QStyle::PM_FocusFrameVMargin larger than default can result in the focus 
>> frame getting clipped in some situations. We see this using persistent 
>> editors in itemviews sometimes, and I think we also sometimes see this when 
>> certain widgets are in splitters.
>> 
>> Adam
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest



-John

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

[Interest] Qt Creator Application Output window

[John Weeks]

Using Qt Creator 4.11.1 on Mac OS 10.14.6 with an Address Sanitizer build of 
our application.

As y'all may know, if you hit a problem in an Address Sanitizer build, the 
output from AS can be quite extensive. But very useful! Unfortunately, in the 
environment summarized above, the Application Output view in Qt Creator often 
fails to flush the output to the display, making it impossible to get all that 
useful information. See sample output copied from a recent run below. Looks 
like a buffering issue?

1) Is there a work-around? Some way to force the output to flush to the display?

2) Do others see this too?


-John Weeks

 =
==2501==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300112fe40 
at pc 0x0001052ca5ac bp 0x7ffeefbfa430 sp 0x7ffeefbfa428
READ of size 8 at 0x60300112fe40 thread T0
2020-04-22 09:14:45.998305-0700 atos[2944:31382] examining 
/Users/USER/Documents/*/Igor64.app/Contents/MacOS/Igor64 [2501]
2020-04-22 09:14:46.168427-0700 atos[2945:31394] examining 
/Users/USER/Documents/*/Igor64.app/Contents/MacOS/Igor64 [2501]
#0 0x1052ca5ab in GetRawWaveUnits(waveHdr**, int, char*, int) 
WaveUnits.cpp:203
#1 0x1052ca7d8 in GetWaveUnits(waveHdr**, int, char*, int) WaveUnits.cpp:263
#2 0x104538c2e in GetUnits(std::__1::shared_ptr, char*) 
axislabel.cpp:116
#3 0x1044ad071 in IsDateAxis(std::__1::shared_ptr) axis.cpp:6000
#4 0x104c0d95b in SetAxisInfo(grafRec*, std::__1::shared_ptr, int) 
plotdata.cpp:2559
#5 0x104c173a2 in UpdateGrafAxes(grafRec*, int) plotdata.cpp:2979
#6 0x104c1f714 in UpdateGraf(grafRec*) plotdata.cpp:3459
#7 0x104c2342c in DoUpdtDisplay(int) plotdata.cpp:3706
#8 0x104c22cb7 in UpdtDisplay(int) plotdata.cpp:3761
#9 0x1002190e1 in IgorAppObject::doIdleEvent(bool) IgorAppObject.cpp:4222
#10 0x100217a98 in IgorAppObject::timerEvent(QTimerEvent*) 
IgorAppObject.cpp:3704
#11 0x117dec5e5 in QObject::event(QEvent*) qobject.cpp:1228
#12 0x11752211a in QGuiApplication::event(QEvent*) (QtGui:x86_64+0x3011a)
#13 0x116d08802 in QApplication::event(QEvent*) qapplication.cpp:2022
#14 0x100217474 in IgorAppObject::event(QEvent*) IgorAppObject.cpp:3697
#15 0x116d09fdc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
qapplication.cpp:3722
#16 0x116d0b347 in QApplication::notify(QObject*, QEvent*) qapplication.cpp
#17 0x1001ff3ca in IgorAppObject::notify(QObject*, QEvent*) 
IgorAppObject.cpp:914
#18 0x117dc3563 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
qcoreapplication.cpp:1024
#19 0x117e19313 in QTimerInfoList::activateTimers() qcoreapplication.h:233
#20 0x11f0fe261 in 
QCocoaEventDispatcherPrivate::activateTimersSourceCallback(void*) 
qcocoaeventdispatcher.mm:124
#21 0x7fff460bce32 in 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 
(CoreFoundation:x86_64h+0x57e32)
#22 0x7fff460bcdd8 in __CFRunLoopDoSource0 (CoreFoundation:x86_64h+0x57dd8)
#23 0x7fff460a079a in __CFRunLoopDoSources0 (CoreFoundation:x86_64h+0x3b79a)
#24 0x7fff4609fd64 in __CFRunLoopRun (CoreFoundation:x86_64h+0x3ad64)
#25 0x7fff4609f66d in CFRunLoopRunSpecific (CoreFoundation:x86_64h+0x3a66d)
#26 0x7fff452fe1aa in RunCurrentEventLoopInMode (HIToolbox:x86_64+0xb1aa)
#27 0x7fff452fdee4 in ReceiveNextEventCommon (HIToolbox:x86_64+0xaee4)
#28 0x7fff452fdc75 in _BlockUntilNextEventMatchingListInModeWithFilter 
(HIToolbox:x86_64+0xac75)
#29 0x7fff4369577c in _DPSNextEvent (AppKit:x86_64+0x1a77c)
#30 0x7fff4369446a in -[NSApplication(NSEvent) 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] (AppKit:x86_64+0x1946a)
#31 0x7fff
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Wrong position QStyleOptionProgressBar on macOS

[John Weeks]

Roman-

Alot of QStyle code seems to think that all drawing will be done in a widget 
solely occupied by whatever it is that QStyle is drawing. I guess folks like 
you and me who try to use QStyle to get cross-platform control appearance for 
sub-rects of a widget aren't very common.

I finally did this for QStyleProgressBar:
QStyleOptionProgressBar options;
painter->translate(r.left, r.top);
options.rect.moveTo(0,0);

A few QStyle things mess with the QPainter transformation matrix. In that case, 
the only thing I can find to work around the problems is to paint the QStyle 
object into a QImage or QPixmap, then draw that image wherever you need it.

I have filed bugs against some of these problems, and gotten very little 
attention.

-John Weeks

> On Mar 20, 2020, at 12:02 PM, Roman Wüger  wrote:
> 
> Hello,
> 
> I use QStyleOptionProgressBar on macOS Catalina with Qt 5.14.1 and tried 
> versions back to 5.11.3. 
> 
> In a Table the progressbar is always displayed in row 0 and column 0 which is 
> wrong even the current row is 6 or something like that and column is 1 or 
> similar.
> 
> Any hints on this issue?
> 
> Best Regards
> Roman 
> ___
> 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] Q_NAMESPACE is not portable?

[John Weeks]

And I was taught in middle school that such a "for instance" should have commas 
before and after:

"This is useful, for instance, if the object needs to be exported from a 
dynamic library."

> On Aug 27, 2019, at 12:58 AM, Kai Köhne  wrote:
> 
> 
> 
>> -Original Message-
>> From: Interest  On Behalf Of Jason H
>> Sent: Monday, August 26, 2019 10:33 PM
>> To: Andy 
>> Cc: Qt Project 
>> Subject: Re: [Interest] Q_NAMESPACE is not portable?
>> 
>> That's what I was attempting to point out.
>> I think "for instance" should be written out in this case, or use an 
>> established
>> abbreviation, or dropped entirely:
> 
> I had the same thought 
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/271615
> 
> Kai
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John

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

[Interest] Troubles with debugging

[John Weeks]

On Macintosh OS X 10.14.5, Qt 5.12.5, and Qt Creator 4.9.2 I keep getting a 
crash while stepping through code. I get a stack trace that looks something 
like this:

1   _os_unfair_lock_recursive_abort 

(x86_64) /usr/lib/system/libsystem_platform.dylib  0x7fff64dac1c2 
2   _os_unfair_lock_lock_slow   

(x86_64) /usr/lib/system/libsystem_platform.dylib  0x7fff64da8caa 
3   look_up_class   

(x86_64h) /usr/lib/libobjc.A.dylib 0x7fff633e6774 
4   QMacAutoReleasePool::QMacAutoReleasePool()  

qcore_mac_objc.mm 169  0x111cd1dc5
5   QMacAutoReleasePool::QMacAutoReleasePool()  

qcore_mac_objc.mm 140  0x111cd1ec5
6   QMacStyle::styleHint(QStyle::StyleHint, QStyleOption const *, QWidget const 
*, QStyleHintReturn *) const
qmacstyle_mac.mm  2602 0x11c53c5e2
7   QProxyStyle::styleHint(QStyle::StyleHint, QStyleOption const *, QWidget 
const *, QStyleHintReturn *) const  
qproxystyle.cpp   290  0x10f7adea6
8   IgorProxyStyle::styleHint(QStyle::StyleHint, QStyleOption const *, QWidget 
const *, QStyleHintReturn *) const  
 IgorProxyStyle.cpp250  0x1002c2191
9   QFocusFrame::setWidget(QWidget *)   

qfocusframe.cpp   187  0x10f830bba
10  QMacStyle::event(QEvent *)  

qmacstyle_mac.mm  6517 0x11c55e379
<.. Lots of other stuff removed here ...>

Plain debug build, turned on the checkbox for loading the debug Qt frameworks. 
The styleHint and AutoReleasePool stuff seems to be a constant part of the 
problem.

That bit at line 2 about "slow" suggests that OS X got tired of waiting for my 
stepping through the code and decided to abort. This makes it really hard to 
debug certain parts of the code. Is this anything that y'all have seen? Is 
there a solution? Do I just have to use QDebug() statements liberally sprinkled 
about my code to debug?

Any insight greatly appreciated.

-John Weeks

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

[Interest] Two different layouts?

[John Weeks]

I have a moderately complex window (more than 50 QWidget- and QLayout-derived 
components). I have decided that it would be nice to have two versions: a 
vertical layout and a horizontal layout. But it's not just a matter of 
QVBoxLayout vs QHBoxLayout.

I have developed a new .ui file with the vertical layout and the appropriate 
rearrangement of the widgets. All the widgets are the same, with the same 
names. The QLayout-derived items are different, but my code doesn't need to 
access them.

It would be great if I could instantiate one or the other of these layouts at 
run-time and get back a pointer (or something?) that I could use instead of the 
usual ui-> pointer. The members that I need to reference all have the same 
names in the two .ui files. Seems like there should be a C++ template way to do 
this, but I'm not as clever with that kind of stuff as I might be.

Has anyone developed a solution to this? Or do I need to make a wrapper class 
that has an accessor function for each of the widgets? That would be a pain to 
implement, and a source of bugs in the future when I change the layouts.

Any ideas greatly appreciated.

-John Weeks

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

Re: [Interest] Qt free software policy

[John Weeks]

We are a small company selling a very large and complex application which is 
now based on Qt open source. At the time we first considered porting to Qt 
(version 4.3?) the license was very expensive for small company (six 
programmers) and the evaluation period simply wasn't adequate to deciding if it 
was the right way to go. So we went open-source when it became available when 
Nokia took over.

Since then, we have wished that we had a commercial license in order to get a 
bit more traction on some bugs. The Qt Company wanted us to pay for all the  
licensing that had accrued since we started using the LGPL version. That 
up-front cost is prohibitive, so we haven't done it.

Perhaps, if you are trying to nudge folks toward commercial licensing, you 
could provide a path that isn't so expensive. Or maybe you have? We haven't 
bothered to look into it lately.

-John

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

Re: [Interest] Finish QLineEdit editing when user clicks anywhere outside the QLineEdit

[John Weeks]

Ah. In our case, the QLineEdit is inside (and parented by) a widget that 
provides the background of the window. That parent widget can accept focus, so 
I guess our cases are not quite the same.

> On Aug 14, 2019, at 9:35 AM, Murphy, Sean  wrote:
> 
>> I used the QLineEdit  focusOutEvent() event.
> 
> Can you elaborate on that? Because when I tested yesterday, if the user 
> clicks on something that does NOT grab focus (for example, any whitespace 
> that exists in the layout between widgets), the line edit never gets a 
> focusOutEvent().
> 
> I need it to work if the user clicks ANYWHERE outside the QLineEdit, and 
> there's no way for me to predict/guarantee what the user is going to click 
> on...
> 
> Sean
> 
> 
> This message has been scanned for malware by Forcepoint. www.forcepoint.com
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John

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

Re: [Interest] Finish QLineEdit editing when user clicks anywhere outside the QLineEdit

[John Weeks]

I used the QLineEdit  focusOutEvent() event.

> On Aug 13, 2019, at 1:21 PM, Murphy, Sean  wrote:
> 
>> Hmm, about that extra step, to remember the filter stuff, since you already
>> have a custom line edit class, why not embed the MouseFilter class inside it?
>> I mean, the filter does not have to reside in MainWindow, it needs only the
>> qApp pointer, so you could wire it up in your custom line edit's ctor 
>> instead.
>> Thus making it an integrated part of your custom class :-)
> 
> Already planning on attempting that once I can get back around to this issue! 
> As often happens, something else is pulling my attention away at the 
> moment, but I'll give it a shot when I have time and report back.
> 
> Sean
> 
> 
> This message has been scanned for malware by Forcepoint. www.forcepoint.com
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-John

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

Re: [Interest] Odd crash with QPainter + QOpenGLWidget

[John Weeks]

I can't really answer your exact question, but I can tell you that we render 
QPainter drawing (including text) onto a QOpenGLWidget this way (not the real 
code...):

QOpenGLWidget::paintGL()
{
QPainter painter(this);

painter->beginNativePainting();
 do your OpenGL drawing here ...
painter->endNativePainting();

... do your QPainter drawing here ...

return true;
}

But in fact, the part  that says, "... do your QPainter drawing here ..." is 
actually done by creating an appropriately-sized QImage, doing the QPainter 
drawing in that, then drawing the QImage into the original QPainter. There is a 
comment in the code:

// JW 161012 This next block is a work-around for what appears 
to be a Qt bug in drawing
// text into a QOpenGLWidget that contains a texture (?). Text 
drawn here comes out sheared
// in a strange way (you may be able to still see this in the 
drag image when dragging an
// annotation). Details of the bug depend on the font and which 
characters are being drawn.

My vague recollection is that we did it this way because using paintEvent() 
requires some slight of hand to sync the GL buffers. Maybe the crash is a 
result of something like that.

-John Weeks

> On Mar 27, 2019, at 2:48 PM, Matthew Woehlke  wrote:
> 
> I've cargo-culted some code to render text over a QOpenGLWidget from
> another project:
> 
>  void MyWidget::paintEvent(QPaintEvent* event)
>  {
>QOpenGLWidget::paintEvent(event);
> 
>auto const& text = /* elided */;
> 
>QPainter painter{this};
>painter.setPen(Qt::white);
>painter.setFont(font());
>painter.drawText(rect(), Qt::AlignCenter, text);
>painter.end();
>  }
> 
> In the "donor" project, this works fine, but the "recipient" project is
> crashing on exit:
> 
> ==12997== Invalid read of size 8
> ==12997==at 0x5D204E4: QObject::thread() const (qobject.cpp:1420)
> ==12997==by 0x598A728: QOpenGLVertexArrayObjectPrivate::destroy()
> (qopenglvertexarrayobject.cpp:212)
> ==12997==by 0x598A9AA:
> QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
> (qopenglvertexarrayobject.cpp:392)
> ==12997==by 0x5987286:
> QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
> (qopengltextureglyphcache.cpp:87)
> ==12997==by 0x59872AC:
> QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
> (qopengltextureglyphcache.cpp:93)
> ==12997==by 0x576ADAB: ~QLinkedListNode (qlinkedlist.h:69)
> ==12997==by 0x576ADAB:
> QLinkedList::freeData(QLinkedListData*)
> [clone .isra.119] (qlinkedlist.h:345)
> ==12997==by 0x5BB10E8: QHashData::free_helper(void
> (*)(QHashData::Node*)) (qhash.cpp:572)
> ==12997==by 0x576A9BA: freeData (qhash.h:585)
> ==12997==by 0x576A9BA: ~QHash (qhash.h:254)
> ==12997==by 0x576A9BA: QFontEngine::~QFontEngine() (qfontengine.cpp:271)
> ==12997==by 0x18C155FC: QFontEngineFT::~QFontEngineFT()
> (qfontengine_ft.cpp:794)
> ==12997==by 0x576AAE4: QFontEngineMulti::~QFontEngineMulti()
> (qfontengine.cpp:1792)
> ==12997==by 0x18C1E41C:
> QFontEngineMultiFontConfig::~QFontEngineMultiFontConfig()
> (qfontenginemultifontconfig.cpp:57)
> ==12997==by 0x575F25E: QFontCache::clear() (qfont.cpp:2796)
> ==12997==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
> 
> Any ideas why? Is this a reasonable approach to rendering text in a
> QOpenGLWidget, or is there a better way? (I am "fairly confident" that
> the problem is the text rendering, above, since the crash goes away if I
> comment out said code.)
> 
> -- 
> Matthew
> ___
> 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 iOS / App Groups / NSUserDefaults initWithSuiteName / Not persisting (Nuno Santos)

[John Weeks]

> I feel stupid! :D

Heh. You can join the elite group of, what, nearly 100% of coders who have had 
this experience? :)

Those that haven't are probably not doing serious work.

-John Weeks
WaveMetrics, Inc.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Calling QMainWindow::close() vs. clicking on close button in title bar

[John Weeks]

Our application needs to control how windows close pretty carefully- we handle 
QEvent::close by ignoring it, then doing whatever we feel like we need to do. 
That is, we take over management of the situation.

-John Weeks
WaveMetrics, Inc.

> On Oct 30, 2018, at 5:53 AM, Andy  wrote:
> 
> Turns out that if you have a QMainWindow containing a QWindow (e.g. by using 
> QWidget::createWindowContainer()):
> 
>   - if you call QMainWindow::close(), the QWindow receives QEvent::Hide and 
> does the right thing
>   - if you click the close button in the title bar, the QWindow receives 
> QEvent::Close which calls QWindow::destroy()
> 
> This is not what I would expect. Is this by design?
> 
> The QWidget::createWindowContainer docs don't mention this as a limitation.
> 
> I haven't yet found a way around it, so suggestions appreciated.
> 
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney
> 
> 
> On Tue, Oct 30, 2018 at 7:24 AM Andy  wrote:
> Setup:
> 
> - two QMainWindows - "main" and "viewer"
> - "viewer" uses Qt3D via QWidget::createWindowContainer()
> - shortcut "cmd-w" (Qt::ApplicationShortcut) set up to call close() on 
> "viewer" if it is the activeWindow()
> - "viewer" does not have WA_DeleteOnClose set, so the window is only hidden
> 
> Problem:
> 
> - if I close the viewer via the shortcut and reopen it, the 3D view is fine
> - if I close it via the close button in the title bar (macOS or Windows) and 
> reopen it, the 3D view is blank
> 
> Any idea why my 3D view is getting killed in the second case?
> 
> This may be a red-herring, but I've traced both through to 
> QWidgetPrivate::close_helper() and each is called with a different mode. The 
> first is called with "CloseWithEvent" and the second with 
> "CloseWithSpontaneousEvent". Could this be a factor?
> 
> I have another window which uses a QGraphicsView set up exactly the same way 
> and it works fine, so maybe Qt3D is doing something I'm not expecting based 
> on a CloseWithSpontaneousEvent?
> 
> Thanks for any ideas/suggestions.
> 
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-John

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

Re: [Interest] Find frontmost widget of specific type?

[John Weeks]

We faced pretty much exactly this issue when we ported our very large 
application to Qt, starting with Qt 4.8. We have many places where we expect to 
be able to walk a window list in Z order. I wound up using Activate/Deactivate 
events to keep the list myself. I can't really recommend it- it has been pretty 
much of a nightmare to make it robust and bug-free, especially as Qt has a 
couple of bugs in their own notion of window activation. You can't really use 
the debugger to debug these issues, as the activation of the debugger changes 
the activation of the application's windows.

I have made it work pretty well, but I quake in my boots whenever I get a bug 
report about window order.

We are now using Qt 5.9 and don't have any sort of replacement for my delicate 
and difficult code.

-John Weeks
WaveMetrics, Inc.

> On Oct 22, 2018, at 11:37 AM, Israel Brewster  wrote:
> 
> I have an application (Qt 5.9) that has a variety of different types of 
> windows you can open. If a user selects to open a type of window that is 
> already open, I want to position the new  window relative to the existing 
> one. I can easily find any existing windows of a given type by going through 
> the list of widgets in QApplication::allWidgets(), doing a qobject_cast to 
> the proper type, and checking the result, but is there a way to determine 
> which of these is the frontmost of that type? QApplication::ActiveWindow() 
> doesn't help, because the activeWindow may not be of that type.
> 
> ---
> Israel Brewster
> Systems Analyst II
> 5245 Airport Industrial Rd
> Fairbanks, AK 99709
> (907) 450-7293
> ---
> 
> 
> 
>   
> 
> 
> 
> 
> 
> 
>   
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] Can't debug on Android device anymore

[John Weeks]

Yes. My recollection is that it happened when I upgraded Xcode and the Xcode 
command line tools. I think I resolved it by shutting down Creator, trashing 
the built application bundle and the build folders. You might even want to 
restart your computer. It's also possible that all that is a red herring and 
that I solved it accidentally in some way that I can't recall :)

-John Weeks

> On Jun 11, 2018, at 6:56 AM, René Hansen  wrote:
> 
> Hi,
> 
> 
> Has anyone else starting seeing this error, when trying to run in debug mode 
> on device?
> 
> "Can't find C++ debugger."
> 
> It seems to have started just recently and I haven't made any changes to my 
> ndk afaict.
> 
> QtCreator 4.6.2 on macOS.
> 
> 
> /René
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] Singleton application

[John Weeks]

We derive our application from QtSingleApplication (it derives from 
QApplication). We acquired the code some time ago, no doubt URLs have changed 
since then... We are presently using Qt 5.9.5. I had compile errors when I 
first downloaded it, described in https://bugreports.qt.io/browse/QTSOLBUG-171. 
I see this in my bug report:

I cloned it from http://qt.gitorious.org/qt-solutions August 6, 2013.

Five years later it's still working for us.

-John Weeks

> On Apr 17, 2018, at 5:26 AM, Samuel Gaist <samuel.ga...@edeltech.ch> wrote:
> 
> 
>> On 17 Apr 2018, at 12:33, Hamish Moffatt <ham...@risingsoftware.com> wrote:
>> 
>> Is there any support built-in for making an application a singleton (ie you 
>> can't launch multiple instances), or does anyone have a recipe?
>> 
>> I'd actually like a second launch to signal the first, passing on any 
>> parameters, much like the web browsers do. (eg link clicked from an 
>> application creates new tab in existing browser instance.).
>> 
>> I need this to work on Windows and Mac.
>> 
>> 
>> Hamish
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> Hi,
> 
> Just in case, the qtsolution module is available at 
> http://code.qt.io/cgit/qt-solutions/qt-solutions.git/ with build fixes for Qt 
> 5.
> 
> The QtSingleApplication module is working with Qt 5. However it doesn’t 
> provide support for QGuiApplication but it’s not hard to add it if needed.
> 
> Cheers
> Samuel
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] High-dpi fixing for Qt 5.5

[John Weeks]

Do it in the showEvent()?

> On Mar 2, 2018, at 8:16 AM, Elvis Stansvik  wrote:
> 
> 2018-03-02 16:26 GMT+01:00 Martins, Sérgio :
>> On 2018-03-02 15:21, Elvis Stansvik wrote:
>>> 
>>> 2018-03-02 16:18 GMT+01:00 Elvis Stansvik :
 
 2018-03-02 15:54 GMT+01:00 Nikos Chantziaras :
> 
> On 02/03/18 16:37, Elvis Stansvik wrote:
>> 
>> 
>> [...]
>> How can I (as application developer) get notified of screen changes of
>> non-QWindow-backed widgets?
> 
> 
> 
> There seems to be two ways to do this. One is using one of the QScreen
> signals:
> 
>  http://doc.qt.io/qt-5/qscreen.html
 
 
 Hm, I should have made my question more clear.
 
 The typical way I've seen is to connect to the screenChanged signal of
 the closest ancestral QWindow (window()->windowHandle()).
 
 But, I've found that it's not reliable for certain widgets/certain
 platforms to do e.g:
 
QTimer::singleShot(0, [this]() {
connect(window()->windowHandle(), ::screenChanged,
this, ::handleScreenChanged);
});
 
 in my constructor, because depending on how the widget is constructed,
 the parentage up to a top-level window may not have been established
 yet, even if I do it in a single-shot timer like this.
>>> 
>>> 
>>> I should clarify this: What I mean is that I've seen situations when
>>> window()->windowHandle() is 0 here, even if the widget is constructed
>>> with a full parentage up to a top-level widget.
>> 
>> 
>> Hi,
>> 
>> Call QWidget::create() on your top-level constructor, and it will ensure it
>> it has a QWindow
> 
> Thanks, that's one way of doing it, but reading further, it seems
> QWidget delays doing this for a reason. E.g. see the docs for
> Qt::AA_ImmediateWidgetCreation, which I could also use to tell Qt to
> call create(..) immediately during construction. That attribute is due
> to be removed in Qt 6 though.
> 
> I don't think I like the idea of jumping the gun on QWidget here and
> calling create(..) myself.
> 
> Surely there must be some way to reliably know when a widget is moved
> to another screen (or anoter top-level window), short of hooking up to
> internal events?
> 
> Elvis
> 
>> 
>> 
>> Regards,
>> --
>> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-Johnm Weeks

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

[Interest] SVG Full

[John Weeks]

QSvgRenderer implements SVG Tiny 1.2, which means that it can't reliably render 
Inkscape drawings. I have just had a query from a customer about this.

The advice for rendering SVG Full is to use QtWebKit. This seems like using a 
sledgehammer to drive finishing nails.

Is there a way to do this? Might QSvgRenderer one day implement SVG Full?

Thanks for any insights.

-John Weeks

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

Re: [Interest] Qt Charts questions

[John Weeks]

That can really distort the shape of a curve in often misleading ways.
And if the sensors can be truly zero, you have another, bigger problem.

> On Jan 4, 2018, at 2:11 PM, william.croc...@analog.com wrote:
> 
> Use a single, logarithmic Y axis.
> (I have never use Qt Charts so I do not know if they support logarithmic 
> axes.)

-John Weeks

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

Re: [Interest] QDockWidgets: how to get regular windows in detached (floating) mode?

[John Weeks]

You may need to call setVisible(true). IIRC, changing window flags makes the 
widget invisible.

-John Weeks

> On Oct 11, 2017, at 2:36 PM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> Hi,
> 
> Dock widgets are very useful, but there are cases where I'd like to be able 
> to detach them to a regular window, because
> 
> - regular windows stay visible when the application focus changes
> - regular windows can do stacking
> - regular windows can be put (partly) off the screen
> 
> The latter 2 are practical when using a smaller screen size, all three are 
> useful for, say, a documentation browser.
> 
> How can one achieve this? I see that QDockWidget::setFloating(true) 
> ultimately just sets the Qt::Tool window flag, so I tried unsetting that. At 
> the moment, I have
> 
>connect(this, ::topLevelChanged, this, [this] (bool floating) {
>if (floating) {
>setTitleBarWidget(0);
>setWindowFlags(Qt::Window);
>updateGeometry();
>activateWindow();
>raise();
>}
>} );
> 
> which probably has a number of redundant calls, doesn't handle the case when 
> a QDockWidget is created in "floating" mode and also isn't reliable.
> 
> Most of the time, the window simply disappears when the above lambda is 
> triggered. In addition, under X11 the window will have the regular titlebar 
> provided by the WM but looks as if there's a regular window with the floating 
> dock window inside, tiny titlebar included.
> 
> What am I missing here?
> 
> Thanks,
> René
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

[Interest] WindowStaysOnTopHint on Windows always on top?

[John Weeks]

We have a QWidgets application that uses  WindowStaysOnTopHint for certain 
windows. My expectation is that when the application isn't the active 
application, the floating windows should not be visible. But in our application 
they are visible always. Is this expected? Maybe I should file a bug on this 
behavior.

Qt 5.6.3
Windows 10

-John Weeks
WaveMetrics, Inc.

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

Re: [Interest] QAudioDecoder mp3 problem

[John Weeks]

> On Aug 31, 2016, at 1:28 AM, Alexander Dyagilev <alervd...@gmail.com> wrote:
> 
> Hello,
> 
> I'm trying to decode an mp3 file. Getting ServiceMissingError ("The 
> QAudioDecoder object does not have a valid service").
> 
> At the same time QMediaPlayer can play the file.
> 
> Am I doing something wrong?
> 
> The code:
> 
> QSharedPointer decoder(new QAudioDecoder());
> 
> decoder->setSourceFilename("1.mp3");
> 
> decoder->start();

On what platform? QAudioDecoder depends on both support on the platform and on 
the presence of a Qt plug-in that uses the platform support. The support on OS 
X is so minimal that we wound up writing a platform-specific bit of code using 
Core Audio (which is not pleasant!).

It's also hard to figure what support is actually available on a given 
platform, and now I've forgotten how I figured it out!

-John Weeks

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

[Interest] debugger thread display

[John Weeks]

I'm working on a Macintosh running OS X 10.11.4, using Qt Creator 3.6.0.

I have been trying to debug a crash in threaded code, but Qt Creator (or my 
debugger? It's lldb) won't cooperate fully. When the crash occurs, I see the 
stack trace for the crashed thread. I can choose another thread from the 
Threads menu, and I see the locals and expressions view change, but the stack 
trace remains showing the crashed thread.

Do I simply need to get a newer Qt Creator? Or is there something I need to do 
differently?

Thanks for any insight.

-John Weeks

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

Re: [Interest] Design Issue with QAbstractItemModel & QTreeView

[John Weeks]

> But when childAdded is called… child already has been added. That's the 
> issue, model is not manipulating data, it's just supposed to react on their 
> changes

OK, I finally decided to look at our code and the documentation :)

QAbstractItemModel has protected functions beginInsertRows and endInsertRows, 
as well as a few other beginXxx and endXxx functions. When data is added to the 
underlying data set, you call beginInsertRows(), do your work of packaging up 
QModelIndexes and inserting them, then call endInsertRows(). Since your 
subclass of QAbstractItemModel is only a representation of the data, not the 
data itself, you don't care of the childAdded signal comes after a data item 
has been added. At that point you prepare a new row in your QAbstractItemModel 
subclass.

Where does your data come from? How do you know when new data is added to the 
underlying data set?

-John Weeks

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

Re: [Interest] Design Issue with QAbstractItemModel & QTreeView

[John Weeks]

> On Aug 4, 2016, at 2:19 PM, Sébastien Le Ray <sebastien...@orniz.org> wrote:
> 
> That's what I do, but the signal says childAdded, where model needs 
> childWillBeAdded and childHasBeenAdded to handle 
> beginInsertRows/endInsertRows, same for the removal so that's not working. 
> Worst case is for the removal, since beforeRemoveRows triggers accesses to 
> the to-be-removed rows you can run into serious issues if the child has been 
> delete'd

If I recall correctly, you would respond to childAdded by first calling 
childWillBeAdded, doing the work of adding the child, then calling 
childHasBeenAdded. The WillBe and HasBeen functions are used to inform the base 
class of what your code is doing.

-John Weeks

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

Re: [Interest] Relationship between a QEventLoop and QCoreApplication::exec().

[John Weeks]

> On Aug 4, 2016, at 10:04 AM, Thiago Macieira <thiago.macie...@intel.com> 
> wrote:
> 
> Starting an event loop from inside another event loop.
> 
> exec() → some slot or event handler → exec()

OK, so that would cover any use of QEventLoop::exec() in the main thread.

It would also seem to cover any use of QDialog::exec() in the main thread, and 
QDialog can be used only in the main thread.

-John Weeks

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

Re: [Interest] Relationship between a QEventLoop and QCoreApplication::exec().

[John Weeks]

At the risk of displaying my ignorance...

Having followed this thread with great interest, I have come to the conclusion 
that perhaps I'm not really certain what you mean by "nested". Any chance of an 
example?


> On Aug 3, 2016, at 10:31 PM, Thiago Macieira  
> wrote:
> 
> I disagree. You should try to split. Lambdas might help.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

Lambdas have always seemed like a great way to write large blocks of obscure 
code, but it seems like I'm missing something. Another example?

-John

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

Re: [Interest] Problem with ^ on a Macintosh with German keyboard layout

[John Weeks]

> On Jun 14, 2016, at 2:31 PM, Thiago Macieira <thiago.macie...@intel.com> 
> wrote:
> 
> On terça-feira, 14 de junho de 2016 13:58:47 PDT John Weeks wrote:
>> On a German keyboard on Macintosh, shift+6 is a combining (or dead key) ^
>> character. If you hit, for instance, shift+6 then "e", you get ê. In some
>> applications, but not in a Qt application, you can enter a non-combining ^
>> using control-shift-option-6. In Qt, the character doesn't make it through
>> because the QKeyEvent::text() function returns an empty string.
> 
> Try pressing ^ followed by space. That's how deadkeys are entered in all OSes 
> and have been since the late 1980s.

Thanks. On my keyboard and Macintosh and also on my (foul language) Dell 
keyboard on Windows this works.

> I can't reproduce your Control+Shift+Option+6 shortcut in Terminal.app either.

Nor can I consistently. I'm trying figure this out from my own US keyboard with 
a German layout selected. That's not a great way to do it... But I've always 
considered TextEdit to be the True Standard :)
> 
>> On Windows, the ^ dead key is where a US keyboard has ` and ~. If you hold
>> down Alt and hit that key twice, it enters a non-combining ^. And this
>> works in Qt.
> 
> I can't reproduce this. If I do that, I get "66" in some places and the 
> equivalent for Alt+6 in others. If you meant AltGr instead of Alt, then I get 
> ¼¼.

No AltGr on my Dell keyboard (also no Break key, but that's another story!).

I think the ^ dead key followed by space is what I'm looking for.

And the bottom line is that trying things on one keyboard doesn't even scratch 
the surface as far as international keyboards or text entry.

-John

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

[Interest] Problem with ^ on a Macintosh with German keyboard layout

[John Weeks]

On a German keyboard on Macintosh, shift+6 is a combining (or dead key) ^ 
character. If you hit, for instance, shift+6 then "e", you get ê. In some 
applications, but not in a Qt application, you can enter a non-combining ^ 
using control-shift-option-6. In Qt, the character doesn't make it through 
because the QKeyEvent::text() function returns an empty string.

On Windows, the ^ dead key is where a US keyboard has ` and ~. If you hold down 
Alt and hit that key twice, it enters a non-combining ^. And this works in Qt.

I'm thinking of filing a bug, but thought I might solicit some comment from the 
European folks using Qt, who might be more expert on this sort of issue!

-John Weeks
WaveMetrics, Inc.

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

[Interest] QSvgRenderer::defaultSize() is wrong?

[John Weeks]

I have an SVG file (that happens to have been generated using QSvgGenerator) 
that has this at the start:

 values will be interpreted as if the system is 90 DPI. My 
reading here: http://www.w3.org/TR/SVG/coords.html#Units seems to indicate that 
unitless width and height should indicate some sort of "pixels".

This seems wrong. It seems likely that the 90 DPI thing comes from 
http://www.w3.org/TR/SVG/coords.html#Units where 90 DPI is used *as an 
example*. But maybe it's I that is wrong- is there somewhere in the SVG 
standard that indicates that these should be interpreted at 90 DPI units?

So, finally, my questions:

1) Am I right that this is wrong?

2) If it is just an assumption used to produce a consistent answer internally, 
then can I assume that QSvgRenderer::defaultSize() will always embody that 
assumption? If so, then I can scale my pictures based on a 90 DPI unit and be 
assured that it will always be that way.

-John Weeks

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

Re: [Interest] Qt5.6: Mouse clicks on ScrollBars also gets passed to widgets behind them

[John Weeks]

See https://bugreports.qt.io/browse/QTBUG-49549

> On May 19, 2016, at 1:40 PM, Chris Gripeos <chris.grip...@harmonixmusic.com> 
> wrote:
> 
> 
> Hello,
> 
> I'm not sure if this is the right place to ask this question. 
> 
> I just noticed that when I click on a Scrollbar of a Widget, any child 
> Widgets that might be right behind the scroll bar at the position of the 
> mouse click, will also get the mouse click event. 
> 
> So, if you have a QTextEdit behind the Scrollbar and you click on the 
> Scrollbar right where the Scrollbar overlaps the QTextEdit, the QTextEdit 
> widget will come to focus. 
> 
> Is this the defined behavior? Or is it perhaps a bug?
> 
> If this is the defined behavior, is there a way to disable it so that the 
> scroll bar consumes the event and prevents it from getting passed to any 
> widgets behind it?
> 
> Thanks in advance for any help.
> 
> cg

-John Weeks
WaveMetrics, Inc.

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

[Interest] Menu causes problems on OS X

[John Weeks]

The very simple application posted below (it is a complete runnable example) 
creates a window that puts up a menu on clicking in the window. If you select 
"Open File..." it then puts up a QFileDialog to choose a file. Upon returning, 
the window no longer appears to active. Experience with our real application 
where we observe this behavior suggests that Qt thinks the window is still 
active, but OS X does not. This causes other strange problems.

Application works as expected on Windows.

I am inclined to believe this is a Qt bug. But I would be interested to know 
what others think, and if you might know of a work-around.

Thanks!

-John Weeks

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

class MainWindow : public QMainWindow
{
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();

protected:
voidmouseReleaseEvent(QMouseEvent * event);

private:
};

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent)
{
}

MainWindow::~MainWindow()
{
}

void MainWindow::mouseReleaseEvent(QMouseEvent * event)
{
QMenu menu;
menu.addAction("Open File...");
QAction * selectedAction = menu.exec(event->globalPos());

if (selectedAction)
{
QFileDialog::Options options = 0;
// options |= QFileDialog::DontUseNativeDialog;
QString fullQtPath = QFileDialog::getOpenFileName(NULL, 
QStringLiteral("Dialog Caption"), QString(), QString(), nullptr, options);
qDebug() << fullQtPath;
}
}

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();

return a.exec();
}


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

Re: [Interest] "Internal mouse button tracking invalid" messages

[John Weeks]

> On Mar 22, 2016, at 5:30 AM, René J. V. Bertin <rjvber...@gmail.com> wrote:
> 
> Any idea if the proposed changes in the code reviews are in any way 
> backportable 
> to 5.6?

No idea at all. I only know about the bug because it affects us.

-John Weeks

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

Re: [Interest] "Internal mouse button tracking invalid" messages

[John Weeks]

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

> On Mar 21, 2016, at 6:09 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> Hi,
> 
> Qt 5.6.0 prints out message about invalid internal mouse button tracking 
> situations in the QNSview class. Are those indicative of errors in user code, 
> or are they internal debugging messages that shouldn't really be printed in 
> production code?
> 
> R.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-John Weeks

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

Re: [Interest] Are slots even needed these days?

[John Weeks]

Nobody's mentioned the fact that an overridden virtual slot requires an 
absolutely horrid cast in order to use the new PMF syntax.

-John Weeks

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

Re: [Interest] [OS X] maintaining a list of own WIds

[John Weeks]

> On Mar 4, 2016, at 11:24 AM, René J. V. Bertin  wrote:
> 
> Indeed. But it seems it *is* possible to be notified when the widget 
> (finally) 
> does become visible using something like

Which is exactly what we do because we need to know *before* a window is 
minimized:

 void IgorNormalWindow::showEvent(QShowEvent *event) {
QWidget::showEvent(event);
emit windowVisibilityChanged(this, true);
TellIgorWindowStatus(this, WINDOW_STATUS_DID_SHOW, 0);

#ifdef MACIGOR
if (!igorNSWindowNotifier)
{
if (!IgorApp()->IsMDI())
{
igorNSWindowNotifier = 
CreateMinimizeNotification(reinterpret_cast(effectiveWinId()), 
reinterpret_cast(this));
SetNSWindowParticipatesInCycle(this, false);
}
}
else
{
if (IgorApp()->IsMDI())
{
DeleteIgorCocoaWindowNotifier(igorNSWindowNotifier);
igorNSWindowNotifier = NULL;
}
}
#endif

}

The CreateMinimizeNotification() function wraps Objective C++ code that 
ultimately does this:

[[NSNotificationCenter defaultCenter]
addObserver:self

selector:@selector(handleMinimizationNotification:)

name:@"NSWindowWillMiniaturizeNotification"
object:cocoaWindow];

 

-John

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

Re: [Interest] [OS X] maintaining a list of own WIds

[John Weeks]

> Actually, I'm also seeing QNSWindows (even the occasional QNSPanel). I'm not 
> perfectly sure if I've ever seen instances of those because of a WId I 
> received; 
> can you be that all WIds are always and exclusively of the (Q)NSView 
> persuasion?

Well, my experience is only with our application that doesn't use sheets, 
drawers or other such things. When we get a wID, it is always an NSView.

> internalWinId() is defined as `inline WId internalWinId() const { return data-
>> winid; }` in the QWidget class definition, so I doubt that calling the 
>> function 
> will have a lot of side-effects if no winid was created yet ;)

Right- which is exactly why we use it. Calling QWidget::winID() will create the 
wID if it doesn't already exist, and that's not necessarily a good thing!

> That's what I was really asking about: how 
> to get notified each time something is created that has a WId.

Which is complicated by Qt's insistence on creating the platform-specific thing 
(wID as NSView, HWND, etc.) only when the QWidget becomes visible.

Or are you writing a plug-in using Qt that is to work with a non-Qt application?

This: 

http://stackoverflow.com/questions/20453965/how-to-get-notified-when-nswindow-opens

seems to indicate that you're not the only one that can't figure this out.

-John Weeks

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

Re: [Interest] [OS X] maintaining a list of own WIds

[John Weeks]

> This is on OS X, so I could also use a native API like KVO on [NSApp windows] 
> but that doesn't seem to work as I'd like, possibly because that's not an 
> observable property and undoubtedly also because not all WIds are NSWindows.

On OS X with Qt 5, WId's are NSViews. You can get the NSWindow from [NSView 
window]. And, of course, Qt doesn't create the NSWindow until the top-level 
widget is shown for the first time, but calling winID() will cause Qt to create 
an NSView even for non-top-level widgets. We call internalWinId() and we're 
prepared to get back nullptr. internalWinId() is undocumented, but a public API 
used lots of places in Qt code, so it's probably not going anywhere soon.

-John Weeks
WaveMetrics, Inc.

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

[Interest] Drawing in a high DPI QImage on Windows

[John Weeks]

We have a number of places in our code where we draw into an image (QImage, 
QPixmap, or a native image type) in order to improve performance.

On Macintosh, we can call QWindow::devicePixelRatio() to find a scale factor 
for figuring out the dimensions of the image from the size of feature we need 
on the screen in device-independent points.

We also need to do this on Windows. But Windows doesn't have the luxury of 
controlling the hardware, so the appropriate scale factor might not be 2.0 as 
it is on a Retina screen. In fact, we are now in possession of a Dell laptop 
with Windows scale factor set by default to 2.5.

Can someone show some example code or suggest API's to use for this? It appears 
that devicePixelRatio() will only return integer values.

We are currently building against a pretty recent build of Qt 5.6.

Thanks!
-John Weeks


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

Re: [Interest] Putting a define with spaces in the .pro file?

[John Weeks]

Our .pro files have things like this:
 DESTDIR = $$quote(../IgorPhoenixFolder)

Does that provide any traction?

-John Weeks
WaveMetrics, Inc.

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

Re: [Interest] qSwap or std::swap?

[John Weeks]

> Both are correct, since one is implemented in terms of the other. That means 
> they MUST expand to exactly the same assembly (and they do, I've just tested).
> 
> If you're seeing something different, the problem is probably your code. And 
> that's why Marc is recommending qSwap: because people don't know how to use 
> std::swap. There's a big gotcha: you MUST NOT write the "std::" part of 
> std::swap.

At the risk of making a fool of myself, what is the difference? I thought I had 
learned that namespaces were just a scoping mechanism for names to avoid name 
collisions. Why does this make such a difference in the generated code?

I'm old enough now that the risk of making a fool of myself is a small price to 
pay in order to learn something.

-John Weeks

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

Re: [Interest] qSwap or std::swap?

[John Weeks via Interest]

Thank you, Konstantin and Thiago.

> Don't worry. ADL is one of the most complex and obscure corners of C++. It's 
> several pages long in the standard, all started from an innocent-looking 
> idea, 
> "wouldn't it be nice if f(x) called N::f(N::X)?".
> 
> I think it's only less complex than overload resolution, but overloads are 
> better understood (you can't live without them). I mean, overloads without 
> templates... that gets complex again.

Right. That's why Scott Meyers devotes quite a lot of space to it. And in C++11 
with rvalue references it gets even more complex.

-John Weeks

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

Re: [Interest] Keeping track of a QDialog position

[John Weeks]

Are you on a Macintosh using the Cocoa-based Qt? If so, that's what you get. 
Cocoa simply doesn't send move events very often.

We have small tool windows and info windows that are supposed to follow graph 
windows around as they are dragged. More than one customer has complained that 
they don't follow, but only snap into position after a delay.

-John Weeks
WaveMetrics, Inc.


> On Oct 19, 2015, at 12:36 PM, Rollastre Prostrit <rollas...@gmail.com> wrote:
> 
> Hello.
> 
> I am trying to keep track of the position of a QDialog as the user 
> clicks on the title and moves it around the desktop. At most, the only 
> thing I manage is to get a move event when the user releases the mouse. 
> But I need to keep track of the position to perform some operations 
> (somewhat like docking).
> 
> After some research performed, I learned about the 
> NonClientAreaMouseButtonPress, NonClientAreaMouseButtonRelease, and 
> NonClientAreaMouseButtonMove events which I can play with and would 
> suffice for my use case. But I'm not getting such events in Linux (KDE) 
> so this solution seems to not be portable.
> 
> Can anybody suggest any way to solve this?
> 
> Thanks
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] Odd new-style connect()/disconnect() error with Qt 5.5.0

[John Weeks]

> On Oct 14, 2015, at 11:37 AM, Bob Hood <bho...@comcast.net> wrote:
> 
> Well, disregard that question.  I can use use the static_cast<> in these 
> instances.  They'll be rare enough, I suppose.

I ran into the overloaded slot problem myself and concluded that the 
compile-time error checking wasn't worth the incredibly obscure cast required 
to make the new syntax work.

-John Weeks

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

Re: [Interest] geometry() for a widget that hasn't been shown

[John Weeks]

Thanks, André.

I had considered that but was having trouble with the retching feeling in my 
stomach. I may just do that after taking some dramamine!

-John Weeks
WaveMetrics, Inc.

> On Sep 23, 2015, at 1:00 AM, André Somers <an...@familiesomers.nl> wrote:
> 
> In the past, I have resorted to first showing the window off-screen, 
> getting its measurements, do my thing, and only then move it to the 
> visible area of the screen. It works, but it is a drag. In my case it 
> was needed in order to make a dialog that nicely resizes using an 
> animation when different options are selected.
> 


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

Re: [Interest] geometry() for a widget that hasn't been shown

[John Weeks]

Thanks, Jan. I thought the same thing, but it didn't help. I even called 
EnsurePolished() first, having seen such things in the Qt source. But it 
appears that adjustSize() adjusts child widgets for the current window 
geometry, and doesn't try to determine an accurate window geometry first.

The fundamental problem is that Qt puts off creating the native window 
representation (NSWindow or NSView or HWND, etc.) until it is first shown. So 
until then, there is nothing to measure.

But it does seem as though the cached geometry could be used to return an 
accurate value. I guess its JIRA bug time...

-John Weeks


> On Sep 22, 2015, at 4:31 AM, Jan Dasselaar <j...@altus-escon.com> wrote:
> 
> Maybe the QWidget::adjustSize() function is what you are looking for.
> I think after calling adjustSize() the geometry() function should give a 
> up to date result.

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

[Interest] geometry() for a widget that hasn't been shown

[John Weeks]

If this is a repeat, my apologies. I can't tell if I saw this arrive on the 
list!



In general a QWidget that hasn't been made visible yet gives bogus results for 
QWidget::geometry(). Qt only guarantees that a call to setGeometry() will 
result in a Resize event when the window is made visible. But we often need to 
ask a window or child widget how big it is before it is made visible in order 
to do various kinds of calculations. These calculations are sometimes used for 
things that preclude waiting for the window to become visible.

Is there a way to force the Resize events (and all the layout calculation 
machinery that goes with it) before it is visible? Using Qt 5.5, I see that if 
you call QWidget::grab(), it will call a static function sendResizeEvents() 
that does exactly what I want:

QPixmap QWidget::grab(const QRect )
{
   Q_D(QWidget);
   if (testAttribute(Qt::WA_PendingResizeEvent) || 
!testAttribute(Qt::WA_WState_Created))
   sendResizeEvents(this);

Is there some other way to get this to happen? I suppose I could just call 
grab() and throw away the QPixmap, but that seems like an awful kludge...

-John Weeks

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

[Interest] geometry() for a widget that hasn't been shown

[John Weeks]

In general a QWidget that hasn't been made visible yet gives bogus results for 
QWidget::geometry(). Qt only guarantees that a call to setGeometry() will 
result in a Resize event when the window is made visible. But we often need to 
ask a window or child widget how big it is before it is made visible in order 
to do various kinds of calculations. These calculations are sometimes used for 
things that preclude waiting for the window to become visible.

Is there a way to force the Resize events (and all the layout calculation 
machinery that goes with it) before it is visible? Using Qt 5.5, I see that if 
you call QWidget::grab(), it will call a static function sendResizeEvents() 
that does exactly what I want:

 QPixmap QWidget::grab(const QRect )
{
Q_D(QWidget);
if (testAttribute(Qt::WA_PendingResizeEvent) || 
!testAttribute(Qt::WA_WState_Created))
sendResizeEvents(this);

Is there some other way to get this to happen? I suppose I could just call 
grab() and throw away the QPixmap, but that seems like an awful kludge...

-John Weeks

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

Re: [Interest] Qt 5.5.x

[John Weeks]

> On Sep 11, 2015, at 8:46 AM, Thiago Macieira <thiago.macie...@intel.com> 
> wrote:
> 
>> But that is not the case, they both perform a complete recompile on code
>> that was not touched.
> 
> My guess is that you're wrong. Code was touched.

Or a dependency was touched. If you touch a header file it will recompile all 
the .cpp files that include that header.

If you're using precompiled headers and you touch one of the headers included 
in the precompiled headers, then it will re-build everything.

-John Weeks

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

Re: [Interest] QFileSystemWatcher and accesing files in monitored directory...

[John Weeks]

> On Aug 31, 2015, at 9:54 AM, Igor Mironchik <igor.mironc...@gmail.com> wrote:
> 
> But this file nobody axcept my application is trying to read.

Do you have virus protection software on your machine? We have had to implement 
a system of re-tries to get around the fact that virus protection software will 
often open and check a file right after the file is created.

-John Weeks

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

Re: [Interest] QFileSystemWatcher and accesing files in monitored directory...

[John Weeks]

> On Aug 31, 2015, at 12:49 PM, Igor Mironchik <igor.mironc...@gmail.com> wrote:
> 
> Pixmap is not null... Image was saved for the half and I read it... Pixmap 
> successfully loaded but draws only first part of the image while the next one 
> is grey...

I forget how Linux works- can you try opening for write? On the systems I know, 
you can't open for write from two different processes. If you get an error for 
writing then the file is still being filled.

Seems like I recall that Linux allows two processes write to file. There must 
be some way to open a file that excludes other processes, and that it would 
fail if already open elsewhere.

(Horrible hack ahead) Or get the number of bytes in the file, wait a bit and 
get the number again. If it changes, it's still being filled.

-John Weeks

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

Re: [Interest] Mac with Retina Display - Look is Pixilated with Qt-5.4.2

[John Weeks]

 On 26 Jul 2015, at 3:04 am, Robert Iakobashvili corobe...@gmail.com wrote:
 
 The look of images is not changes/improves even if the names of
 the 2x images are passed explicitly. They are loaded, but still not looking
 differently from 1x.

Do you have a second monitor at standard resolution? You may be experiencing 
this bug:

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

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

[Interest] Audio file metadata?

[John Weeks]

Does anyone know if it's possible to use QAudio to get metadata from an audio 
file? Info like the channel layout or embedded comments?

-John Weeks

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

Re: [Interest] Dockwidgets as non-children

[John Weeks]

 On 14 May 2015, at 8:43 am, Scott Aron Bloom sc...@towel42.com wrote:
 
 I have a request from a customer, he loves our docked layout.. However, there 
 are times when he wants to undock a window, and just make it a peer window.  
 Ie, not a child that is always on top of the mainwindow.
  
 Is there any way to do this directly in Qt?
 
 Scott

The only way I know of is to create a new QWidget with no parent, and then 
re-parent the wrapped widget in the new QWidget. It will require an annoying 
amount of code to handle re-docking if that is desirable.

-John Weeks

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

Re: [Interest] Survey: do you override QCoreApplication::notify? Why?

[John Weeks]

 On 17 Apr 2015, at 2:46 pm, Alejandro Exojo s...@badopi.org wrote:
 4) filter events being delivered (remove from queue / compress)?
 
 We do this.
 
 Could you elaborate a bit on how do you do it?

My answer was a bit short, wasn't it? I was responding to the part about 
filtering. We use only the ability to return true from the notify() function to 
mean block this event. We don't try to remove anything from the queue.

In fact, sometimes this isn't enough- at least on Macintosh, a click in a 
window's title bar that activates a window doesn't pass through notify(), you 
only see the resulting windowActivated and windowDeactivated events.

We have a feature in which our customers can create an almost modal window- 
it's modal except that some other window is allowed interaction. This was done 
so that a customer can create a control panel (window with controls, like a 
modeless dialog) that allows the user of his control panel to interact with a 
graph window and with the control panel, in an otherwise modal state. So we 
filter mouse events (and other UI events) for windows other than the control 
panel or graph window.

Also, code in our internal language prevents UI interaction, except that 
certain keys or a click on an Abort button can cancel execution. That allows 
stopping an infinite loop, or a complex computation that might go on for a long 
time (one of our customers was asking for optimization tips because his code 
ran all night and didn't finish).

-John Weeks

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

Re: [Interest] Survey: do you override QCoreApplication::notify? Why?

[John Weeks]

 4) filter events being delivered (remove from queue / compress)?

We do this.
We also maintain our own z-order window list and use the notify event to 
intercept WindowActivated and WindowDeactivated events.
The application includes a programming language that users can use to create, 
destroy and modify objects and do arbitrary computations. It's sufficiently 
powerful that our customers often implement scientific computations for things 
that aren't provided as built-ins, and they create their own GUIs for various 
kinds of scientific endeavors. During user code execution we need fine-grained 
control of events, and it's not always possible to identify an object to which 
a filter can be attached.

The decision to use notify() was made very early in our use of Qt- it's 
conceivable that we would have designed it differently if we were starting from 
our present knowledge of Qt. But maybe not. It was based in part on reading C++ 
GUI Programming with Qt 4.

 2) use it to catch exceptions and continue execution?
 or use it to catch and abort?

This too.

 And additional question: do you need this for the main thread only, for 
 auxiliary threads only or for all threads?

Main thread only. Much of our use of notify() is for more fine-grained control 
of event delivery, where QEventLoop::ExcludeUserInputEvents excludes too much.

-John Weeks

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

Re: [Interest] QAudioDecoder

[John Weeks]

 I fed it a .wav file. QAudioFormat told me it was a signed 8-bit file. But a 
 .wav file is apparently always unsigned if it is 8-bit.
 
 Question 2: Hm... I guess there is no question, it's just a bug.

I reported it yesterday: https://bugreports.qt.io/browse/QTBUG-45540

It's fixed today!

Now for my other question...

-John Weeks

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

[Interest] QAudioDecoder

[John Weeks]

I've accepted the fact that QAudioDecoder has no backend support on Macintosh, 
so now I'm working on Windows. I have successfully decoded a .mp3 and a .wav 
file. A couple of issues:

I fed the decoder a .aif file. I'm prepared to learn that it isn't supported on 
Windows. After calling QAudioDecoder::start(), I called QAudioDecoder::error() 
and got back QAudioDecoder::NoError. But then nothing else happens. No 
bufferReady() signal, no finished() signal, no error signal.

Question 1: how can I determine that a given file will be decodable? Is there a 
call I can make to find out if my file is supported? Or do I have to just know 
from the file extension and my extensive (hah!) knowledge of Qt Multimedia 
backend plug-ins?




I fed it a .wav file. QAudioFormat told me it was a signed 8-bit file. But a 
.wav file is apparently always unsigned if it is 8-bit.

Question 2: Hm... I guess there is no question, it's just a bug.


Thanks all!

-John Weeks


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

[Interest] QAudioDecoder class on Macintosh?

[John Weeks]

I have a use for QAudioDecoder to load sound files into our numerical analysis 
program as data. I found Qt Multimedia and the QAudioDecoder. I wrote some 
trial code and got this message in my Creator console:

 defaultServiceProvider::requestService(): no service found for - 
org.qt-project.qt.audiodecode

I Googled that, and ultimately found this page:

http://wiki.qt.io/Qt_Multimedia_Backends

that shows that there are almost no platforms where QAudioDecoder actually 
works. So...

1) It would have been nice if the QAudioDecoder documentation actually 
documented the fact that it depends on a backend plug-in, and that there are 
hardly any that actually work. The Detailed Description has two paragraphs! 
Clearly a work in progress, but this: 
http://doc.qt.io/qt-5/multimediaoverview.html doesn't seem to indicate that it 
is anything but a finished module.

2) I would love to know if this is a work in progress, or will I wait in vain 
for a Macintosh backend plug-in that supports QAudioDecoder?

Thanks all!


Ah, ha! I just noticed the static function QAudioDecoder::hasSupport(). Of 
course, I still have to write code before I can discover that there isn't any 
support.

-John Weeks

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

Re: [Interest] QAudioDecoder class on Macintosh?

[John Weeks]

Thanks, Oliver and René.

Maybe I should just skip QAudioDecoder and go with FFMpeg!

-John Weeks

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

Re: [Interest] Do I need to build Qt from the source to have an app compile in 32 bit?

[John Weeks]

 What you do need though is the OS X 10.6 SDK, and I'm not sure if systems 
 more recent than OS X 10.7 can be used to build applications targeting 10.6.

I am building a non-Qt application against the 10.6 SDK on Yosemite using Xcode 
6. I got the 10.6 SDK from a previous version of Xcode and installed it in 
the Xcode 6 bundle. It's not supported by Apple, and we're not using a set-up 
like that for our shipping release, but it seems to work on my machine for 
debug builds. Don't blame me, though, if it doesn't work for you :)

-John Weeks

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

[Interest] QSvgRenderer has a strange coordinate system

[John Weeks]

Sizing in QSvgRenderer class is set by the function convertToPixels() in 
qsvghandler.cpp, which I have pasted below. That function always converts to 
units of 1/90 inch.

I wonder why; it seems from the name that it should be converting to screen 
resolution, or whatever the resolution is of the paint device it renders to. 
This not only affects the internal coordinate system, it affects the size of 
the image returned by QSvgRenderer::defaultSize(), where the coordinates are 
perversely not documented.

Does anyone know why this is? It seems like a bug to me.

-John Weeks


---
 static qreal convertToPixels(qreal len, bool , QSvgHandler::LengthType type)
{

switch (type) {
case QSvgHandler::LT_PERCENT:
break;
case QSvgHandler::LT_PX:
break;
case QSvgHandler::LT_PC:
break;
case QSvgHandler::LT_PT:
return len * 1.25;
break;
case QSvgHandler::LT_MM:
return len * 3.543307;
break;
case QSvgHandler::LT_CM:
return len * 35.43307;
break;
case QSvgHandler::LT_IN:
return len * 90;
break;
case QSvgHandler::LT_OTHER:
break;
default:
break;
}
return len;
}
--
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [OSX/iOS] Garbage collection still in place in Qt?

[John Weeks]

 This does not prevent applications from using ARC since it can be enabled per 
 translation unit. We would like to start using ARC internally in Qt as well, 
 but the requirement to drop 32-bit support may be too steep at this point in 
 time. (Question for interest@: is 32-bit support important?)

Adam has already answered this for our company.

 Carbon: Qt links against the Carbon framework and uses some functions still 
 available in 64-bit mode. Using the Carbon headers as the authoritative 
 source, these are not deprecated. One example is 
 GetCurrentEventKeyModifiers().

I note also that QMacStyle uses HITheme API's as well. I haven't been able to 
find NSThis or NSThat replacements for drawing pictures of controls and window 
elements, either.

-John Weeks

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

[Interest] Hidden application showing itself

[John Weeks]

Macintosh, Qt 5.4

I have a complaint from a customer who is alpha testing our application port to 
Qt. He uses the Application Menu Hide Others item to hide our application while 
he does other work in other applications. Since our application is scriptable 
and can do computations that literally take hours or days, he wants to set the 
application running his script while does other work in other applications. To 
avoid the flashing windows while his script runs, he uses the Hide Others to 
hide our application.

But QWidget::show() causes the application to un-hide. So two questions:

1) Is there a way to tell Qt that it should honor the application being hidden?

2) Is there a way to ask Qt if the application is hidden? If I could find that 
out, I could manage the visibility of our windows myself.

Thanks,

-John Weeks

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

[Interest] Qt::WA_NoMouseReplay? Extra mouse clicks during contextual menus.

[John Weeks]

We have code conceptually like this (but more complicated :) --

void MainWindow::mousePressEvent(QMouseEvent *e)
{
if (hotRect.contains(e-pos()))
{
QMenu aMenu(The Menu, 0);
aMenu.addAction(Action 1);
aMenu.addAction(Action 2);
QAction * action = aMenu.exec(e-globalPos());
if (action)
qDebug()  Selection:  action-text();
else
qDebug()  No selection;
}
}

The problem is that once the menu is shown, if you click outside the menu in 
order to cancel the menu, the mouse click is propagated to the widget under the 
mouse. If it's the widget containing my hotRect, it can put up the menu again.

First question: How can this possibly be useful behavior?

Tracing through Qt source, I found the attribute  WA_NoMouseReplay. I can set a 
filter on the QMenu and set that attribute on the mouse click:

 bool MainWindow::eventFilter(QObject *obj, QEvent *e)
{
if (e-type() == QEvent::MouseButtonPress /*|| e-type() == 
QEvent::MouseButtonRelease*/)
{
QMenu * menu = qobject_castQMenu *(obj);
if (menu)
menu-setAttribute(Qt::WA_NoMouseReplay, true);
}

return false;
}

But the documentation of WA_NoMouseReplay says, The flag is set by the 
widget's author and cleared by the Qt kernel every time the widget receives a 
new mouse event. This suggests that I shouldn't be using this attribute in the 
way I'm using it.

Second question: Is my filter safe? That is, can I count on this to continue 
working in the future?

Third question: Is there a better way to prevent the extra mouse click? Or a 
better way to present my menu?

Thanks!

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

[Interest] hi-res drawing on Windows

[John Weeks]

Is there a comprehensive overview of drawing for monitors at various 
resolutions on Windows?

I am trying to get our application to work correctly on a hi-res monitor on 
Windows. In particular, I have a QToolButton-derived class that makes a button 
that is just the icon, with no visible frame. It overrides sizeHint(), 
maximumSize() and paintEvent() to do this. Instances of the button are given 
icons from PNG resources that have  both standard and @2x versions.

One point of this class is to size the button based on the size of the icon. 
Thus, sizeHint() and maximumSize() both return iconSize(). In the paintEvent(), 
I get the icon out of the button using icon(), get the QWindow for the window 
hosting the button and then use QIcon::pixmap(QWindow *, iconSize(), ...) to 
get the appropriate QPixmap to draw.

On Macintosh this works great. On my 5k iMac I get the correct size and hi-res 
pixmap. Slide the window over to my external standard-res monitor and it 
redraws with the standard res pixmap.

On Windows, I don't have a hi-res monitor. I'm faking it by setting Change the 
size of all items to Larger 150%. That's another way to say, Make my large 
monitor small :) Not ideal, and it's not 2x, so I don't really expect the 2x 
icons. What I DO expect is the QWindow::devicePixelRatio() might return 1.5, 
but all I get is 1.0 at all settings of size of all items.

I found this:
http://doc-snapshot.qt-project.org/qt5-5.4/highdpi.html

Since I'm on Windows 8.1 I should be in Per-Monitor DPI Aware mode. It seems 
like I shouldn't have to intervene in order to get resolution-independent pixel 
drawing.

If I do this before creating my QApplication instance:
qputenv(QT_DEVICE_PIXEL_RATIO, 2)
then I get 2.0 from devicePixelRatio(), as expected. I also get my hi-res icons.

If I do this instead:
qputenv(QT_DEVICE_PIXEL_RATIO, 1.5)
then devicePixelRatio returns 1.0, not 1.5.

And it doesn't seem like I should have to set this myself, anyway.

Thanks for any insight you might be able to offer!

-John Weeks

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

Re: [Interest] hi-res drawing on Windows

[John Weeks]

 On Feb 5, 2015, at 3:03 PM, Jason H jh...@gmx.com wrote:
 int
 That pixelRatio is either 1 or 0, I don't think it is ever in between.

Well, during development of my button class, when I had bugs :) I saw QPixmap 
return devicePixelRatio between 1.0 and 2.0. Maybe that's just QPixmap, though.

-John Weeks

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

Re: [Interest] Qt 5 Creator 3.3 (Mac) Debugger locks up with endless error logging of DW_AT_specification(address) has no decl

[John Weeks]

How does Xcode do it? Xcode is quite reliable stepping through code.

 On Feb 3, 2015, at 10:37 AM, André Pönitz apoen...@t-online.de wrote:
 
 In any case, that's not really caused by Qt, and there's also not much Qt
 Creator can do about.

-John Weeks

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

[Interest] Confusing activation behavior of floating windows

[John Weeks]

I am seeing confusing QEvent::WindowActivate events associated with floating 
windows on Macintosh. I wonder if someone can give me an explanation. Please 
excuse the length...

The code here is a vastly simplified version of actual application code.

I use code like this to make three floating windows. Note that each code block 
makes a floating window, shows it and activates it. There is also code to name 
everything so you can tell what you're seeing, and qDebug() statements so that 
I can tell the order of what's happening. (hope it comes through readable):
 void MainWindow::onGoButton()
{
Qt::WindowFlags qtflags = Qt::Tool | Qt::WindowStaysOnTopHint;
qtflags = qtflags | Qt::CustomizeWindowHint | Qt::WindowTitleHint | 
Qt::CustomizeWindowHint | Qt::WindowTitleHint |
  Qt::WindowMinimizeButtonHint | 
Qt::WindowMaximizeButtonHint;

qDebug()  About to create Window A;
QWidget * wa = new QWidget(0, qtflags);
wa-setObjectName(Window A);
wa-setWindowTitle(Window A);
qDebug()  About to show Window A;
wa-show();
qDebug()  About to activate Window A;
QApplication::setActiveWindow(wa);

qDebug()  About to create Window B;
QWidget * wb = new QWidget(0, qtflags);
wb-setObjectName(Window B);
wb-setWindowTitle(Window B);
qDebug()  About to show Window B;
wb-show();
qDebug()  About to activate Window B;
QApplication::setActiveWindow(wb);

qDebug()  About to create Window C;
QWidget * wc = new QWidget(0, qtflags);
wc-setObjectName(Window C);
wc-setWindowTitle(Window C);
qDebug()  About to show Window C;
wc-show();
qDebug()  About to activate Window C;
QApplication::setActiveWindow(wc);
}

I also use QApplication::notify() to monitor QEvent::WindowActivate:

 bool myApp::notify(QObject *object, QEvent *event)
{
if (event-type() == QEvent::WindowActivate)
{
qDebug()  Window activate:  object-objectName()  and 
the active window is  QApplication::activeWindow()-objectName();
}
return QApplication::notify(object, event);
}

On Macintosh using Qt 5.4 RC (which means Cocoa) on OS X 10.9.5 I get this 
output:

About to create Window A
About to show Window A
About to activate Window A
Window activate: Window A and the active window is Window A
About to create Window B
About to show Window B
About to activate Window B
Window activate: Window B and the active window is Window B
Window activate: Window A and the active window is Window B
About to create Window C
About to show Window C
About to activate Window C
Window activate: Window B and the active window is Window C
Window activate: Window A and the active window is Window C
Window activate: Window C and the active window is Window C

Note that the target for the event isn't always the same as what Qt thinks is 
the active window.
On Windows I get more reasonable output:

About to create Window A
About to show Window A
About to activate Window A
Window activate: Window A and the active window is Window A
About to create Window B
About to show Window B
About to activate Window B
Window activate: Window B and the active window is Window B
About to create Window C
About to show Window C
About to activate Window C
Window activate: Window C and the active window is Window C

Am I just seeing Cocoa weirdness? It looks like some of the time Qt is lying to 
me about the activating window. But if it's a Qt bug, then it's been there a 
long time- I also see it when building with Qt 4.8.6.

Thanks for any insight that can be offered!

-John Weeks

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

Re: [Interest] QWindow::setTransientParent()

[John Weeks]

 renderPixmap() can be replaced with a call to grabFramebuffer(). They both 
 perform (potentially expensive) readbacks.

Thanks Laszlo.

The expense is probably OK, since this is for exporting graphics as a file or 
on the clipboard. But grabFramebuffer() gives you the same resolution as on 
screen, and we need hi-res export.

I ran across some code in a JIRA bug using QGLFramebufferObject; I see there is 
also QOpenGLFramebufferObject so I guess we can use the same technique.

-John Weeks

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

Re: [Interest] QWindow::setTransientParent()

[John Weeks]

Shawn-

 QGLWidget is obsolete, because it has the disadvantage of requiring its own 
 platform window for the GL content to render into, which has caused various 
 problems over the years.  QOpenGLWidget (new in Qt 5.4) simplifies some 
 things: Qt uses FBO tricks to composite the OpenGL content and the other 
 widgets into a single window.  So you should probably try to switch from 
 QGLWidget to QOpenGLWidget.

We have now done this, and it has solved a nagging problem we were having. 
Thank you!

There are a couple of things missing from QOpenGLWidget compared to QGLWidget: 
renderText() and renderPixmap().

We were using renderPixmap() to export graphics at resolution higher than what 
is displayed on-screen. And renderText() was being used for plotting data with 
text as the data point markers.

Are there alternatives to these for QOpenGLWidget?

-John Weeks


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

[Interest] QWindow::setTransientParent()

[John Weeks]

Can anyone tell me about  QWindow::setTransientParent()? When building with Qt 
5 I keep seeing warnings:

 void QWindow::setTransientParent(QWindow *) QWidgetWindow(0x118c39a10, name = 
QWidgetClassWindow) must be a top level window.

One situation where I see it is on Macintosh:

Our application can make a 3D graph window that uses OpenGL calls to draw. The 
OpenGL context is implemented via a QGLWidget. The  QGLWidget is contained in a 
QWidget that is itself contained in a QWidget that is (usually) a top-level 
window.

I see the warning when calling new QMenu(QGLWidget *). Here's a (truncated) 
stack trace (GizmoWD is our class, of course):

0   QWindow::setTransientParent(QWindow*)   qwindow.cpp 1131
0x10969ac1a 
1   QWidgetPrivate::setParent_sys(QWidget*, QFlagsQt::WindowType) 
qwidget.cpp 10516   0x10898b528 
2   QWidget::setParent(QWidget*, QFlagsQt::WindowType)qwidget.cpp 
10375   0x108971b07 
3   QWidgetPrivate::init(QWidget*, QFlagsQt::WindowType)  qwidget.cpp 
11790x10896fe3c 
4   QWidget qwidget.cpp 10260x1089701a9 
5   QMenu   qmenu.cpp   13330x108b3468f 
6   QMenu   qmenu.cpp   13360x108b3460d 
7   GizmoWD::init(char const*, int) GizmoWD.cpp 90  0x100cb58f9 
8   doNewGizmo(GizmoWD**, char const*, char*, wDataClass*, 
wdChildInfo::hostRectType, WMRect*, int, int, int)   GizmoBuiltInOps.cpp
 279 0x100c81f7a 

In tracing into this, I see that QGLWidget requires a WinID. The QWindow * 
being passed to setTransientParent() is the QGLWidget. The QWindow whose 
setTransientParent() method was called is the QMenu.

I haven't seen any obvious problems that I can trace to this, but maybe I'm 
missing something.


I also see it on Windows in some other situations.


My apologies for a somewhat vague and abstruse question. I'm trying to 
understand the warning, but I don't have an obvious place to start. Thanks for 
any light you can shed!

-John

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

Re: [Interest] How can I block the WindowActivate and FocusIn events when showing window programmatically

[John Weeks]

It's the same situation with Move and Resize events. In Qt 4, you could do this:

bool myclass::eventFilter(QObject * target, QEvent *event)
{
static bool moving = false;

case QEvent::move:

// In Qt 4, the move event comes synchronously, so we know that 
only our call to QWidget::move
// can cause a reentrant call here.
if (moving)
return;

moving = true;
... call QWidget::move 
moving = false;
}


But in Qt 5 the Move event is put on the queue and delivered asynchronously. So 
now I have this sort of code:

class myclass
{
...

private:
bool moving;
QWidget * movedWidget;
};

bool myclass::eventFilter(QObject * target, QEvent *event)
{
somewidget = qobject_castQWidget *(target);

case QEvent::move:
// in Qt 5, the call to QWidget::move doesn't cause a reentrant 
call here, it triggers
// another move event later on. So we have to store away info 
on this call to QWidget::move,
// and detect that move event later on when it looks like other 
move events.
if (moving  somewidget == movedWidget)
{
moving = false;
movedWidget = NULL; // not at C++11 yet!
return false;
}

moving = true;
movedWidget = somewidget;
somewidget-move();
return whatever;
}

I put in a check on the widget that was moved out of paranoia that some other 
move event could sneek in while I was waiting. In our case, we have the same 
filter on multiple widgets.

Warning: I could have made some typo in the process of abstracting the method 
from much more complex code...

-John Weeks

On Oct 31, 2014, at 7:35 AM, Yili Pan pyl0...@gmail.com wrote:

 Hi Bo:
 
 Thank you for the reply! 
 
 I do not want to filter out all the WindowActivate or FocusIn event tough, 
 only these are triggered by calling QWidget::show(). But because the events 
 are processed asynchronously in Qt5, when I catch them in the eventfilter, I 
 don't know whether they are originated from calling show() or they are 
 spontaneous event caused by manual interaction. I also tried to filter out 
 the event by telling whether they are spontaneous, but unfortunately no 
 matter where they originate from, they are spontaneous (could this be a 
 bug??). Any thoughts or suggestion :)
 
 Thank you!
 
 -Yili
 
 On Fri, Oct 31, 2014 at 4:01 AM, Bo Thorsen b...@vikingsoft.eu wrote:
 Den 30-10-2014 20:30, Yili Pan skrev:
  Hi:
 
  We want to block the widget's WindowActivate and FocusIn event
  triggered by calling its show() function, with Qt4,  we used to do
  that by setting flag before and after show() and filter out the event
  in eventfilter based on the flag.  But with Qt5, the events are
  processed asynchronously, we cannot block the event in the same way
  anymore.
 
  Any ideas how I can identify those events that are caused by calling
  QWdiget::show() and filter them out?
 
 You can use an event filter for this. Take a look at the documentation
 for QObject::installEventFilter, it should be simple to follow.
 
 Bo.
 
 --
 Viking Software
 Qt and C++ developers for hire
 http://www.vikingsoft.eu
 
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest
 
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

-John

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

Re: [Interest] [osx] cmd-period mapping

[John Weeks]

Tim-

On Macintosh, cmd-. is the cancel signal, like ctrl-break in Windows, or Ctrl-C 
for Linux. In fact, when building with Qt and Cocoa, you don't get it at all 
because Cocoa eats it up. We went to somewhat extreme lengths to intercept 
cmd-. so that we can use it to cancel user programs (our application includes a 
user programming language).

You really should NOT use cmd-. as anything other than a cancel signal.

Here is what we did to get access to cmd-. key events:

In a .mm file:

 bool WMNSEventIsCmdPeriodKeyDown(void * event)
{
NSEvent * nsevent = reinterpret_castNSEvent *(event);
if ([nsevent type] == NSKeyDown)
{
if ([nsevent modifierFlags]  NSCommandKeyMask)
{
NSString * chars = [nsevent 
charactersIgnoringModifiers];
return [chars characterAtIndex:0] == 0x2E;  
// Unicode encoding for period
}
}
return false;
}

bool WMNSEventIsCmdPeriodKeyUp(void * event)
{
NSEvent * nsevent = reinterpret_castNSEvent *(event);
if ([nsevent type] == NSKeyUp)
{
if ([nsevent modifierFlags]  NSCommandKeyMask)
{
NSString * chars = [nsevent 
charactersIgnoringModifiers];
return [chars characterAtIndex:0] == 0x2E;
}
}
return false;
}

Then, with Qt 5, we define a macintosh event filter class:

class macEventFilterClass : public QObject, public 
QAbstractNativeEventFilter
{
Q_OBJECT

public:
bool
nativeEventFilter(const QByteArray, void* message, long*);

signals:
void
caughtCancelEvent(bool isDown);
};

 bool macEventFilterClass::nativeEventFilter(const QByteArray , void * 
message, long *)
{
bool result = false;

if (WMNSEventIsCmdPeriodKeyDown(reinterpret_castvoid *(message)))
{
emit caughtCancelEvent(true);
result = true;
}
else if (WMNSEventIsCmdPeriodKeyUp(reinterpret_castvoid *(message)))
{
emit caughtCancelEvent(false);
result = true;
}

return result;
}

and in our QApplication-derived class constructor, we install it on the 
application:

_macEventFilterObject = new macEventFilterClass;
connect(_macEventFilterObject, 
SIGNAL(caughtCancelEvent(bool)), this, SLOT(_caughtMacCancelEvent(bool)));
installNativeEventFilter(_macEventFilterObject);


On Sep 3, 2014, at 2:38 PM, Tim Blechmann t...@klingt.org wrote:

 hi all,
 
 i wonder, does ctrl-. (as in cmd-.) have any special treatment in qt5?
 i'd like to use it a shortcut of an action which is available from the
 menu bar, but it does not get triggered. otoh, in QFileDialog and the
 like get seem to trigger the cancel button.
 
 any idea how use it for application-defined shortcuts?
 
 thnx,
 tim
 
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

Regards,
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax   (503) 620-6754
email   supp...@wavemetrics.com

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

Re: [Interest] QScrollBar shift-click on Windows

[John Weeks]

On Jul 24, 2014, at 11:50 PM, Bo Thorsen b...@vikingsoft.eu wrote:

 You should open a feature request in the bug tracker.

Thanks, Bo:

https://bugreports.qt-project.org/browse/QTBUG-40439

-John Weeks

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

[Interest] QTextLayout::isValidCursorPosition() gives different result in Qt 5.3.0 vs Qt 4.8.6?

[John Weeks]

I don't know very much about QTextLayout...

With this code copied from our very large application, when qtext contains A:

QTextLayout qLayout(qtext, f);
qLayout.beginLayout();
QTextLine qLine= qLayout.createLine();  // If there is no text left to 
be inserted into the layout, the QTextLine returned will not be valid 
(isValid() will return false).
haveLine= qLine.isValid();
if( haveLine ) {
qreal width= std::numeric_limitsdouble::infinity();   
//INFINITY;
qLine.setLineWidth(width);  // everything on one line.
qLine.setPosition(QPointF(xPos, yPos)); // top/left of first 
character
}
qLayout.endLayout();

qDebug()  qLayout.isValidCursorPosition(0) =  
qLayout.isValidCursorPosition(0);
qDebug()  qLayout.isValidCursorPosition(1) =  
qLayout.isValidCursorPosition(1);
qDebug()  qLayout.isValidCursorPosition(2) =  
qLayout.isValidCursorPosition(2);

When built with Qt 4.8.6, I get 
qLayout.isValidCursorPosition(0) = true 
qLayout.isValidCursorPosition(1) = false 
qLayout.isValidCursorPosition(2) = false 

whereas with Qt 5.3.0 I get
qLayout.isValidCursorPosition(0) = true
qLayout.isValidCursorPosition(1) = true
qLayout.isValidCursorPosition(2) = false

It seems like the Qt 5 output makes sense- the position after the last (only) 
character on the line should be a valid cursor position (that's where the next 
character typed will go, right?). But just in case this is a bug in Qt 5, I'd 
like to avoid changing the code to accommodate a bug...

-John Weeks

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

Re: [Interest] Calling reject() on a QFileDialog on Macintosh

[John Weeks]

On Jun 25, 2014, at 11:03 PM, Rutledge Shawn shawn.rutle...@digia.com wrote:

Thanks Shawn.

 That sounds like a bug.  

Perhaps I will build a sample application and file a bug.

 What do you mean about the modal state, the window is active but you can’t 
 interact with anything in it?  Or it’s not active?

The dialog disappears, but the menus are all disabled. Some things work- I can 
click in another window and type. But the disabled menus are a problem. We have 
a call to re-set the menus; I called it and it didn't seem to help.

-John Weeks

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

[Interest] Calling reject() on a QFileDialog on Macintosh

[John Weeks]

We use QFileDialog::getOpenFileName() to get the native file dialog on 
Macintosh. If you hit Escape, the dialog closes (as it should).

If I call QDialog::reject() or even if I use this code:

 QFileDialog * dialog =  qobject_castQFileDialog 
*(activeModalWidget);
QKeyEvent * event = new QKeyEvent(QEvent::KeyPress, 
Qt::Key_Escape, Qt::NoModifier, QString(),0,0);
QApplication::postEvent(dialog, event);
event = new QKeyEvent(QEvent::KeyRelease, 
Qt::Key_Escape, Qt::NoModifier, QString(),0,0);
QApplication::postEvent(dialog, event);
the dialog closes, but with Qt 5.3 it leaves the application in some sort of 
modal state. This puzzles me- hitting the Escape key works fine. What's the 
difference?

By the way, this works as I expect with Qt 4.8.6.

-John Weeks

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

Re: [Interest] dependent foo.cpp does not exist.

[John Weeks]

I forget the exact symptoms, be we've had strange problems like that if there 
are two different files in the project that have the same names.

-John Weeks

On May 27, 2014, at 7:50 AM, Thomas Sevaldrud tho...@silentwings.no wrote:

 Hi,
 
 I'm getting these strange errors all the time when trying to build my 
 projects now... I'm using shadow building and I get these dependent 
 somefile.cpp does not exist. In some cases the problem goes away when 
 deleting the entire build folder and re-configuring, but not always... I 
 can't see any particular pattern in these errors, other than that the file it 
 complaints about definitely exists in the location pointed to by the error 
 message. For example:
 
 16:42:48: Running steps for project SilentToolkit...
 16:42:48: Configuration unchanged, skipping qmake step.
 16:42:48: Starting: C:\Qt\Tools\QtCreator\bin\jom.exe
 cd StkMeshGraphicsModel\  ( if not exist Makefile 
 C:\Qt\5.2.1\msvc2012\bin\qmake.exe 
 C:\Projects\MARIA\Branches\Development\MariaNG1.0\Native\ThirdParty\SilentToolkit\tests\libs\StkScene\StkMeshGraphicsModel\StkMeshGraphicsModel.pro
  -spec win32-msvc2012 CONFIG+=debug CONFIG+=declarative_debug 
 CONFIG+=qml_debug -o Makefile )  C:\Qt\Tools\QtCreator\bin\jom.exe -f 
 Makefile
 C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Debug
 Error: dependent 
 '..\..\..\..\..\..\MARIA\Branches\Development\MariaNG1.0\Native\ThirdParty\SilentToolkit\tests\libs\StkScene\StkMeshGraphicsModel\tst_StkMeshGraphicsModelTest.cpp'
  does not exist.
 jom: 
 C:\Projects\builds\SilentToolkit-Desktop_Qt_5_2_1_MSVC2012_32bit-Debug\tests\libs\StkScene\StkMeshGraphicsModel\Makefile
  [debug] Error 2
 jom: 
 C:\Projects\builds\SilentToolkit-Desktop_Qt_5_2_1_MSVC2012_32bit-Debug\tests\libs\StkScene\Makefile
  [sub-StkMeshGraphicsModel-make_first] Error 2
 16:42:48: The process C:\Qt\Tools\QtCreator\bin\jom.exe exited with code 2.
 Error while building/deploying project SilentToolkit (kit: Desktop Qt 5.2.1 
 MSVC2012 32bit)
 When executing step 'Make'
 16:42:48: Elapsed time: 00:00.
 
 It is very hard to reproduce with an isolated example. It happens on various 
 machines, and with various projects. All these projects include a common 
 qmake include file, and it's probably something stupid I've done there, but I 
 just wanted to ask if anybody have had similar problems, or any helpful 
 advice on how to debug this...
 
 Cheers,
 Thomas
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] pb with 530 official release and MAC/OS

[John Weeks]

Sounds like the same problem I ran into: 
https://bugreports.qt-project.org/browse/QTBUG-38874

-John Weeks


On May 20, 2014, at 10:04 AM, mai...@virtual-winds.org wrote:

 Thanks for your reply
 
 Why is removing the processEvent the right thing to do?
 
 Anyhow if I remove it, the event loop is locked anyway, and no more 
 events are processed. So imo the processEvents just highlights the 
 problem, it's not the cause of it. Also note that I have similar 
 sequences in other places, same problem with QMessageBox::show() and 
 5.3.0.
 
 This is with MAC/OS 10.9 Mavericks
 
 Thanks
 Philippe LELONG
 
 Le 20-05-2014 18:43, Thiago Macieira a écrit :
 Em ter 20 maio 2014, às 18:39:41, mai...@virtual-winds.org escreveu:
 If I run this under 530/MacOS, I see only up to step 4 in the 
 console.
 If I remove processEvents() it continues, but I have problems later 
 for
 instance doing deleteLater() which never calls the destructor. As it
 seems to me the event loop is locked.
 
 Remove the processEvents, since that's the right thing to do.
 
 If you have problems in that setup, let's fix those problems.
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] pb with 530 official release and MAC/OS

[John Weeks]

In my case, we're creating a kind of progress window. The code that runs while 
the dialog is up is rather old and not thread-safe. But using Qt before 5.3 I 
can show the dialog, run the computation, adjust the information in the dialog 
and call processEvents to cause it to repaint and to allow the user to click an 
Abort button. When the computation is finished, I call exec() to wait for the 
user to click the OK button. 

With the recent changes, calling processEvents() causes the modal session to 
start, blocking any further execution outside the dialog's event loop.

This is how QProgressDialog works. From the QProgressDialog documentation of 
setValue():

Warning: If the progress dialog is modal (see 
QProgressDialog::QProgressDialog()), setValue() 
callsQApplication::processEvents(), so take care that this does not cause 
undesirable re-entrancy in your code. For example, don't use a QProgressDialog 
inside a paintEvent()!


-John Weeks

On May 20, 2014, at 12:13 PM, Thiago Macieira thiago.macie...@intel.com wrote:

 Em ter 20 maio 2014, às 19:04:39, mai...@virtual-winds.org escreveu:
 Thanks for your reply
 
 Why is removing the processEvent the right thing to do?
 
 Because processEvents() means nested event loops. You shouldn't do that. You 
 should show() and then return;, so the non-nested event loops resumes 
 executing.
 
 If you do need to blocking-show, then don't use show(), just use exec().
 
 I'm interested in knowing whether there's a lock up if you use any of the 
 above solutions. And exactly what you mean by lock.
 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] pb with 530 official release and MAC/OS

[John Weeks]

On May 20, 2014, at 2:16 PM, Paul Miller p...@fxtech.com wrote:

 Your best bet is to do your work in a thread while .exec()ing the 
 dialog. Then the main window UI's event loop can spin normally.

In my case, the code that executes is not thread-safe. It's ancient, 
complicated code. If I try to make it thread-safe, I risk breaking it. Not a 
great situation, but it is what it is. And with previous releases I don't have 
to fix it, Qt just did what I wanted.

And Thiago said:

 But it does look like this a regression.
 
 The plan is to rapidly release 5.3.1 with the pending fixes from the last two 
 months, plus maybe this fix.

That's good to hear. Thanks!

-John Weeks

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

Re: [Interest] QAction shortcuts in modal dialogs

[John Weeks]

On Apr 29, 2014, at 3:59 AM, Rutledge Shawn shawn.rutle...@digia.com wrote:

 Our application runs on Macintosh and Windows desktop systems. On Macintosh 
 it is usual to have the menu bar active even when a modal dialog is 
 displayed, and it can be used to cut/copy/paste in editable fields in the 
 dialog.
 
 Qt, on the other hand, uses the Windows convention of disabling the menu bar 
 when a modal dialog is displayed.
 
 Not the whole menu bar, but most menu items.

Well, in my application the menu bar looks available (the menu bar items are 
not dimmed) but all the items in the menus are disabled. It kind of comes to 
the same thing :)

I recently found the technique of creating a new menu bar and giving it the 
modal dialog as parent. In Qt 4 that menu works during operation of the dialog. 
But in Qt 5 the menu items are disabled just like the main menu bar. I have 
filed a bug:

https://bugreports.qt-project.org/browse/QTBUG-38600

Thanks for your attention to my problem!

-John Weeks

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

Re: [Interest] Change widget type of Qt Creator Form Class

[John Weeks]

We often just edit the .ui file. It's XML and not too hard to comprehend. You 
probably have to change it in a couple places.

-John Weeks

On Apr 11, 2014, at 11:38 AM, Murphy, Sean smur...@walbro.com wrote:

 Is there a way to easily change the base class of a Qt Designer Form Class?
  
 I created a new custom widget using Qt Creator’s “Add New…-Qt-Qt Designer 
 Form Class” wizard.  At the time, I chose “Widget” as my form template.  So 
 at the end of that sequence I ended up with myWidget.h, myWidget.cpp, and 
 myWidget.ui.  I then added some code.  Then I realized that I should have had 
 the custom widget inherit from QFrame, not QWidget.  Is there an easy way to 
 make that switch now that code is already written?
  
 In the .h and .cpp file, it’d be trivial to do a find  replace of QWidget - 
 QFrame, but I’m not seeing an easy way to change the base widget type in the 
 designer UI using the UI controls.  I’m assuming I could hack the raw XML in 
 the .ui file and change the line:
   widget class=QWidget name=myWidget
 To:
widget class=QFrame name=myWidget
  
 But that seems like a bit of a hack, and maybe that’s not even sufficient?
 Sean
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] heightForWidth

[John Weeks]

Well, I see your point- why should the window necessarily be the same shape as 
the graph when the graph is constrained to a particular dimensional 
relationship. But both Macintosh and Windows provide ways to constrain a 
window's dimensions while the user is dragging the window to a new size. In 
fact, debugging the Qt Cocoa code involved with heightForWidth() shows that 
they are handling the notifications that allow constraining window size while 
the user is dragging, so it seems like this should be feasible.

I take your point that it is a hint- all the layout stuff is hints pretty much. 
But if it is possible to apply a hint, it should be applied. Since it is 
possible to constrain window dimensions on Macintosh and Windows, it seems like 
there might be a way to tell Qt that my heightForWidth is intended to be exact, 
not a minimum dimension, similar to the way QSizePolicy:Fixed means don't 
resize this widget at all.

Thanks,
John Weeks

 Hi John,
 
 It sounds like you don't have any other widget that will take up the 
 space in the layout? The layout managers will only use the height for 
 width as a hint, so you have to provide some way to help it. Either add 
 other widgets to take the empty space around the widgets or add spacers.
 
 I hope this helps,
 
 Bo.
 
 -- 
 Bo Thorsen, European Engineering Manager, ICS
 Meet me at our quickstarts across Europe in March.
 Copenhagen, Hamburg, Munich and Zurich.
 See this page: http://ics.com/qt-quickstart

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

[Interest] heightForWidth

[John Weeks]

I have a need for windows that maintain a set aspect ratio, so I implemented 
heightForWidth(). Since I'm still exploring, I made it very simple (this 
function is called by a wrapper class that actually implements 
heightForWidth()):

 int grafRec::doHeightForWidth(int w)
{
return w/2;
}

I set a size policy:

QSizePolicy policy(QSizePolicy::Preferred, 
QSizePolicy::Preferred);
policy.setHeightForWidth(true);
content-setSizePolicy(policy);

The object called content is a subclass of QWidget and it is embedded in a 
cell of a QGridLayout. There are no other cells in the layout occupied. The 
layout and managed content widget are embedded in a top-level widget.

This actually works up to a point. As I make the window get wider, it also gets 
taller in proportion. But evidently Qt is enforcing a height that is *at least* 
half the width, where I really need a height that is *exactly* half the width.

Is this working as expected, that the height returned by heightForWidth() is 
really a minimum height? If that is so, is there a way to achieve what I really 
want?

Thank you all!

-John Weeks

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

[Interest] Finished resizing a window?

[John Weeks]

We have windows in our application that are potentially expensive to repaint, 
so when the user resizes a window we may need to put off repainting until the 
resizing is finished. It seems that we don't get mouse down/mouse up events 
when the user clicks in the window frame/resize grip area, so I can't wait 
until mouse up.

Is that correct?
Is there a solution to this?

Thanks!

-John Weeks

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

Re: [Interest] Finished resizing a window?

[John Weeks]

On 24-Feb-2014, at 2:24 PM, Thiago Macieira wrote:

 That's something entirely controlled by the window manager. Sorry.

Thanks, Thiago. That's good to know.

-John

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

Re: [Interest] New window in Qt makes the application activate

[John Weeks]

On 03-Feb-2014, at 8:32 PM, Mandeep Sandhu wrote:

 Wow...so much active-ity in this para! :)

At 61, I like to think of myself as an active senior...

-John Weeks

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