Re: [Interest] Confused about High-DPI icons...

[Sérgio Martins via Interest]

On 2019-03-13 22:30, Matthew Woehlke wrote:

I'm trying to add High-DPI icons to my application.

Currently, I have a bunch of icons as resources, e.g.:

  :/icons/16x16/open
  :/icons/16x16/quit
  ...

From reading the documentation, it *sounds* like all I should have to 
do

is add higher resolution icons with "magic" names:

  :/icons/16x16/open@2x
  :/icons/16x16/quit@2x
  ...

...but this doesn't work; I still get the actually-16x16 icons scaled 
up
2x. (Note: I am testing with 
QT_SCALE_FACTOR=2/QT_SCREEN_SCALE_FACTORS=2

as I don't have a "real" High-DPI display.)

Has anyone gotten this to work? Am I doing something wrong? Am I
misreading the documentation?


Do you have:

QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);


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
https://lists.qt-project.org/listinfo/interest

[Interest] Sharing texture between QOpenGLContext and native OpenGL context doesn't work with MESA driver

[Stefan Fabian]

Hey,

I've been rendering Qt and QML into a texture and the resulting texture is 
rendered on top of the 3D scene of an existing application.
Code from quick experiments using only Qt can be found here 
https://github.com/StefanFabian/rviz_experiments/tree/master/qt_rviz_overlay
This works fine on my Desktop with an NVidia GPU, however, it doesn't work on 
my Notebook using an integrated graphics card and MESA drivers.
I've done some debugging and found that the content of the texture, while the 
QOpenGLContext is active, is as expected but when I call doneCurrent() and make 
the native context current again, the texture becomes a texture of the same 
size but the content is just empty with spots of what looks like uninitialized 
memory.
Any idea what could cause this and how I can get around this issue with the 
least performance impact possible (Downloading the texture and uploading it to 
the native context would come to my mind but that'd be horrible with regards to 
performance)?

Qt Version: 5.5.1
Desktop: NVidia GTX 1080 with OpenGL version 4.6 (GSLS 4.6)
Notebook: i7 8550U with OpenGL version 3 (GLSL 1.3)

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

[Interest] Confused about High-DPI icons...

[Matthew Woehlke]

I'm trying to add High-DPI icons to my application.

Currently, I have a bunch of icons as resources, e.g.:

  :/icons/16x16/open
  :/icons/16x16/quit
  ...

From reading the documentation, it *sounds* like all I should have to do
is add higher resolution icons with "magic" names:

  :/icons/16x16/open@2x
  :/icons/16x16/quit@2x
  ...

...but this doesn't work; I still get the actually-16x16 icons scaled up
2x. (Note: I am testing with QT_SCALE_FACTOR=2/QT_SCREEN_SCALE_FACTORS=2
as I don't have a "real" High-DPI display.)

Has anyone gotten this to work? Am I doing something wrong? Am I
misreading the documentation?

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

Re: [Interest] QProcess overload slot connection

[Thiago Macieira]

On Wednesday, 13 March 2019 14:08:19 PDT Jason H wrote:
> In the situation that there's a problem, you end up waiting for timeout.
> So:
> connect(process,QOverload QProcess::ExitStatus>::of(::finished), , ::quit);
> becomes:
> connect(process, ::stateChanged,[=, ](QProcess::ProcessState
> state) { qDebug() << "stateCanged" << state;
> if (state == QProcess::ProcessState::NotRunning) loop.quit();
> });
> 
> Because the NotRunning will occur always, and immediately, and finished
> won't. Failed command:
> stateCanged QProcess::Starting
> stateCanged QProcess::NotRunning
> // no finished!

Good catch. A process that didn't start can't finish.

Another way would be to waitForStarted() before entering the loop. Unlike the 
other waitFor functions, waitForStarted can be relied upon to finish rather 
quickly, since it only depends on the current thread anyway. If it takes long, 
then it's because the entire system is swapping hard and taking time to do 
everything.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Interest] QProcess overload slot connection

[Jason H]

> > What's the "right way" to connect QProcess::finished to QEventLoop::quit?
> 
> The one you listed above.

It turns out that I'm not even using that anymore. 

In the situation that there's a problem, you end up waiting for timeout.
So:
connect(process,QOverload::of(::finished), 
, ::quit);
becomes:
connect(process, ::stateChanged,[=, ](QProcess::ProcessState 
state) {
qDebug() << "stateCanged" << state;
if (state == QProcess::ProcessState::NotRunning) loop.quit();
});

Because the NotRunning will occur always, and immediately, and finished won't.
Failed command:
stateCanged QProcess::Starting
stateCanged QProcess::NotRunning
// no finished!

Successful command:
stateCanged QProcess::Starting
stateCanged QProcess::Running
stateCanged QProcess::NotRunning
finished 0 QProcess::NormalExit

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

Re: [Interest] QProcess overload slot connection

[Jérôme Godbout]

I for one use the following and it work just fine:

connect(ctr_ptr
, 
QOverload::of(::error)  // 
QOverload to avoid shadowing of ::error() and ::error(e) signal
, this
, ::controllerError);

I also had to use this form once:
connect(ctr_ptr
, static_cast(::error)
, this
, ::controllerError);


-Original Message-
From: Interest  On Behalf Of Thiago Macieira
Sent: March 13, 2019 4:22 PM
To: interest@qt-project.org
Subject: Re: [Interest] QProcess overload slot connection

On Wednesday, 13 March 2019 12:02:14 PDT Jason H wrote:
> connect(process, QOverload::of(::finished), , 
> ::quit);
> 
> 
> QEventLoop::quit slot does not take any parameters
> 
> 
> What's the "right way" to connect QProcess::finished to QEventLoop::quit?

The one you listed above.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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] QProcess overload slot connection

[Thiago Macieira]

On Wednesday, 13 March 2019 12:02:14 PDT Jason H wrote:
> connect(process, QOverload::of(::finished), ,
> ::quit);
> 
> 
> QEventLoop::quit slot does not take any parameters
> 
> 
> What's the "right way" to connect QProcess::finished to QEventLoop::quit?

The one you listed above.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Interest] QProcess overload slot connection

[Christian Ehrlicher]

Am 13.03.2019 um 20:02 schrieb Jason H:

This does not give an error, but is also wrong, I think:
connect(process, QOverload::of(::finished), , 
::quit);


QEventLoop::quit slot does not take any parameters
What's wrong with this? The signal can have more parameters than the 
signal - this was always the case.
But you should use the finished(int, QProcess::ExitCode) overload - the 
other one is deprecated and will create a compiler warning in Qt5.13 and 
above.


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

[Interest] QProcess overload slot connection

[Jason H]

void waitForProcessFinished(QProcess *process, const QString , int 
timeout) {
QTimer timer;
QEventLoop loop;
connect(, ::timeout, , ::quit);
connect(process, ::finished, , ::quit); // 
can't resolve ::finished

if (timeout > 0 ) {
timer.setSingleShot(true);
timer.start(timeout);

}
process->start(command);
loop.exec();
}


I can't seem to figure this out. There is code online that resolves it as 
above, but there is also code that uses qOverload() but I get:
use of undeclared identifier 'qOverload'

So you say that's only availible for C++14, ok I say:
connect(process, QOverload<>::of(::finished), , 
::quit);

which then gives:
no matching function call to 'of'

QOverload gives an error

This does not give an error, but is also wrong, I think:
connect(process, QOverload::of(::finished), , 
::quit); 


QEventLoop::quit slot does not take any parameters


What's the "right way" to connect QProcess::finished to QEventLoop::quit?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Whole edit window closes.

[Benjamin TERRIER]

Le mar. 12 mars 2019 à 21:39, Bill Crocker
 a écrit :
>
> Hello:
>
> Sorry. A boring old desktop widget problem...
>
> I have a QTableView.
> I use a QStyledItemDelegate on each cell.
> The delegate opens a custom, modal editor on double click.
> The editor is based on a QDialog and contains a number of widgets,
> one of which is a QComboBox.
> When I press  in the text entry area of the QComboBox,
> the whole edit window closes, but I am not done "editing". Arg.
>
> (Most of the time that is what you want because the QComboBox is
>   the only widget in the editor, but not here.)
>
> I have tried a number of things related to focus, default buttons
> but nothing has worked.
>
> How do I keep the editor open
> until I press the OK button.
>
> Thanks.
>
> Bill
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

Hi,
I had this kind of issue back in the Qt 4.8 days

From what I remember, the issue is that the QComboBox does not consume
the "return pressed" event.
So the event propagates to the QDialog which handles the event by
"pressing" the default button and closing itself.
The only solution I found was to filter the "return pressed" event,
using an event filter (`QObject::installEventFilter()`)
so that it does not reach the QDialog.

BR,

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