General and Desktop

@ambershark said in Is there a way to update the screen from outside the application?: @m.kawakami It sounds like you just want to refresh the window of an application that is not your application. So you don't have the source for it and you can't modify it. In which case I would just have your application call xrefresh. Type man xrefresh ... or here is an online man page for Thank you for your reply. xrefresh has already tried, but it was not improved. QWidget::update () has confirmed that the display has been improved.

@JonB Oh I get it now... You changed webkit to webengine and that caused these issues. Now I understand why you keep talking about all these buttons in your app. It's because the app was fundamentally changed by replacing a technology. So it's not as easy as replacing your async places with progress dialogs since you don't necessarily know where all those places are. That is a nasty thing to deal with. I wish you luck, lol.

@brucezcg said in QListWidget: How to disable when mouse hover ,the items change background color?: I don't want to change background color when hover, I just want to disable hover, when hover, the items stay the background color, may be different colors, so I couldn't set hover to certain color. Well in that post I linked you on stackoverflow, it shows: QListWidget::item:hover, QListWidget::item:disabled:hover, QListWidget::item:hover:!active, {background: transparent;} That means it just hides the hover, doesn't set it to a certain color. It should do exactly what you need. You can of course make a custom delegate too. That's more work that setting a quick css though.

Hi, Can you explain what you expect and what you get on that widget ? What version of Qt are you running ? On what version of macOS ?

It's in the "Topic Tools" button.

Hi, The ID selector follows this syntax: QWidget#widgetObjectName.

@JonB Oups, I found my blunder! In the body of QGraphicsPG constructor (not shown on my simplified code), the compute() function is also called i.e. BEFORE this object is added to the scene, hence scene() is not yet allocated a value. In the subsequent calls made by the slot on_actionDummy_triggered, everything is OK and dynamic_cast works perfectly. Thanks JonB a lot for your help!

@Chris-Kawa equally awesome, thank you too!

export QT_LOGGING_TO_CONSOLE=1 start QtCreator - gives the desired.

@Joachim-W said in how to set current working directory so that QFile gets relative paths right: thanks to @JonB's questions, I located the problem: the current directory changes while my application is running, namely when the singleton instance of Mainwin is created. Yep, that's the only thing which makes sense! I meant to ask what to do instead. I definitely need to get command line arguments interpreted in the standard way. Now, doubtless you already realise this, but if you are dealing with relative paths received from the command line, you'd better deal with them (even if it's only to make them absolute) before you hit that code which changes the working directory (unless they really intentionally relative to the home directory in your app for some reason). whereas for a command-line interface it is insane to overwrite the current working directory. I see no reason why a file dialog for read/write should not be relative to the current directory, rather than say the home directory, but of course depends on context. Finally, as @VRonin says, you can (and should) use QFileDialog::setDirectory() rather than actually changing directory if you only want that for the purpose of the file dialog.

Hi Else one "rogue" QWidget could eat all keys and shortcut keys would stop working.

I looked at a similar thing for a while actually, Implementing it mixing QMdiArea and QDockArea is a mess. There are commercial products for it but couldn't find a viable solution

Not solved, but found a work-around. It is not very satisfactory, but I can't see another option right now. The function: m_widget->style()->polish(m_widget); is definitely interfering with the "triggered" event from QAction. I have found out that this works, somehow: void QExtWidgetSimpleFlasher::setFlash(bool flashOn) { m_widget->setProperty("flash", flashOn); m_widget->style()->unpolish(m_widget); m_widget->update(); } For some reason, unpolish is able to update button colors and text font. It updates everything I need except size. So I have to create a configurable width and height, and also call widget->setFixedWidth(config.width); widget->setFixedHeight(config.height); This gives me the desired end-result and button behaviour. If anyone comes along and know what is up with the polish function, please let me know. Best regards, Stian

So simple ! void MainWindow::positionChange(qint64 p) { if(!ui->sliderProgress->isSliderDown()) ui->sliderProgress->setValue(p); }

@column: dUNSUPPORTED GDB VERSION GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6) This version of GDB is really old. Can you try updating it? Edit: and Creator 3.5.1 is stone-old too...

@VRonin Yeah, I appreciate that its an issue with the underlying implementation - my fumbling has had be digging into the QAbstractItemView class and implementing my own setIndexWidget function in a custom QTableView class. Ultimately, the widgets dropped into the cells will have the same base class but the derivatives will be very different.

@zyannick Thank you very much. I have already thought about using a different library like qcustomplot. So with Qt Charts alone there is no better way, isn't it?