General and Desktop

@CuriousPan :) While you are looking at enum Qt::ItemDataRole, see what other roles are defined. You can affect fonts, colors, tooltips.... You can also look at the passed-in QModelIndex and/or the type of QVariant returned from Qt::DisplayRole/EditRole to selectively return different values for these, e.g. only numbers should be right-aligned, strings should be left-aligned.

I found a solution. It was simple. I had to add scene->update() in move() function to fix it.

@JonB said in How to implement visual effect for cutted item in QAbstractItemView?: So if you want whatever you need to know to be stored in the original item when it is cut, do so via setData(), then you don't need to remember/adjust the QModelIndex. You might store the desired "cut" icon either directly in setData(Qt::DecorationRole) or in your own Qt::UserRole + ... and test for that in data(Qt::DecorationRole)'s return value. Obviously whatever setData(role) value you use will need to be cleared out when the cut completes or is cancelled. I think it is the most efficient way. I'll use it. Meanwhile the pure original class is also preferred, it can be a parameter to other functions. It's likely that some convertions have to be there.

@0ices Hello and welcome. I have not heard of making a window the subject of drag & drop. Nor of creating a new window in a mouseMoveEvent, that would create hundreds of them as the mouse is moved. If anything I would have thought during mousePressEvent. It sounds to me as though you are creating this new window while you are in the middle of a mouse drag event on the main window --- you already have the mouse pressed down and you are dragging it? In that situation I do not know that you can/it is easy to "change" the drag which is currently in progress over the main window so that now this new window is focused and receives mouse events. The more usual way, it seems to me, would be: create whatever this new window is first, perhaps on main window mouse down, and then initiate a drag and drop event on it.

maybe i will open a new post with my current question its is not anymore about the @ symbol

Hi, thank you for your attention and support! You're a real professional! The right question. It took me a while to get it, but - of cause - you where right. I'm getting old. I forgot the second purpose of DynWidget ancestors - late initialization. So it was a typical PEBCAK.

Do a clean build of your project so that moc runs and moc_mainwindow.cpp is regenerated to match your actual MainWindow declarations in mainwindow.h (which should be on_menuBar_import_triggered())

@SGaist said in How to trigger a hotkey to a QWindow using a QButton?: Which OS are you on ? Sending key events through Qt's event loop like that won't work AFAIK. The application while embedded is still an external application. Im using Ubuntu 18.04. There is a way to send the key event through OS?

Hi @JonB thanks for your response. After a deep look in my code, I found the thing that was causing this to fail. Thanks for telling me.

@stvokr I wrote earlier @stvokr One thing: if you are saying you apply a color in code to style, that will be overridden/ignored if there is stylesheet rule applicable. Depends how you set the color of the listwidgetitem. So, yes, if you use QSS that will override setForeground() etc. You will need to stick with one or the other.

@JonB said in Single Click Event on Q: This is not a full application, just an extract. Presumably if "the application exits" on a click there is an error, and you get an error message somewhere. ?

@JonB I still think I am using wrong widget / signal. I can only position and click the mouse. I cannot highlight the text - the positioning of mouse overrides that.

tr is used for text translation. It's an old habit of mine to write my code so that translation can be implemented at anytime. As for your use case, just nuke your "tab" object and add text directly to your ui QTabWidget: ui->tabWidget->addTab(text, tr("Text Edit"));

@Emon-Haque From the bug report, I wouldn't worry about it, cross fingers it won't come up again.

@mpergand, yes subclassing is the way to go in my opinion too. So far Qt Widgets isn't that bad as I though it'd be. It's fast and looks like it doesn't use GPU at all.

Seems you are engaged in a loop. Run the debugger and when it's hang, interrupt the debugger to see the stack frame. [Edit] too late :)

Thanks a lot! That did the trick. Interesting! Wasn't aware of that difference.