While trying to open a popupmenu from another popupmenu, I ran into a tiny problem. Both the menus close when I open the submenu. A temporary solution I'm using is closing the original menu on click and the submenu remains open then. I think they're both trying to grab the focus and close due to that. Does anyone know a reasonable way of creating hierarchical popupmenus in gnome shell extensions?
The menu system in the shell is a little bit convoluted with regard to the signals and opening and closing. You should definitely have a look a popupMenu.js if you haven't already.
If I recall from my own adventures, it's not possible to have submenus in submenus because of the way the signals propagate but you can subclass any of those classes and modify the signals, or you can fake your own submenus by adding manipulating the visibility property:
Also have a look at PopupMenuSection class with it's comment:
deliberately ignore any attempt to open() or close(), but emit the corresponding signal so children can still pick it up
Related
[EDIT] - wasn't getting to the disable code the way I thought I was; works fine with any of the solutions below.
I have a modeless QT dialog, in which all kinds of user settings can be manipulated. In addition, it can save and load large data sets, which can take several seconds. Lots going on in the main window underneath (realtime app) and that's fine, and interaction there is okay, but in the dialog itself, I need to block user interaction.
Essentially, during the load, I don't want the user to be able to change / affect any of the controls in the modeless dialog (and there are a lot of them.)
Rather than disable each one individually (or even that way if that's the only way), is there a straightforward means I can use to disable input to the dialog entirely until the load is complete?
There's a progress bar in it that shows what's going on, too, which is constantly updated by the load process, so that needs to keep on working.
I tried this...
On dialog open:
QDialog *window = this;
Then around load:
window->setDisabled(true);
....
window->setDisabled(false);
...which compiles fine, and runs without complaint, but the window did not disable.
I also tried:
window->setEnabled(false);
....
window->setEnabled(true);
...that doesn't seem to do anything either.
I tried this too:
QList<QWidget*> list = window->findChildren<QWidget *>();
foreach(QWidget *qw, list)
{
qw->setEnabled(false);
}
....
QList<QWidget*> list = window->findChildren<QWidget *>();
foreach(QWidget *qw, list)
{
qw->setEnabled(true);
}
..also does nothing.
Based on Qt documentation (http://doc.qt.io/archives/qt-4.8/qwidget.html#enabled-prop):
Disabling a widget implicitly disables all its children. Enabling
respectively enables all child widgets unless they have been
explicitly disabled.
So your snippets are essentially doing same thing in different ways so that doesn't seem to be a problem and modality of dialog shouldn't have any effect on this as well. How are you loading / saving the data? If you are doing it in e.g. click slot then you are basically blocking the UI event loop which means that UI doesn't have cycles to react to your changes. If you want to isolate UI from background action so it will properly react even that you are doing heavy lifting in the background and you should consider using QRunnable or QTread to offload the work away from UI thread.
I am making my first steps with Qt. As an exercise, I am writing a GUI for a many-core processor, and individual cores are shown in a separate window. From this window, there may be several copies, with their independent life, including menus, status line, etc. That is, they are essentially like a QMainWindow, but having a QMoreMainWindow :). Might be any side effect if I use QMainWindow several times?
Nothing prevents you from using any of them for anything. They do have different roles and properties:
QMainWindow is just that: a main window. It has a toolbar, dockwidgets, a menu bar, a status bar, and a central widget. If you don't need all (most of) those things, you clearly don't want a QMainWindow.
QWindow is a barebones object in which is useful if you don't want/need QWidget's functionality.
QDialog is meant to be used for pop-up windows (i.e. "dialogs") like a messagebox or an open file dialog.
QWidget is the basic window or window element. If in doubt, use this.
Reading your question, it seems you want each of those windows to be a QMainWindow. Note I'd still prefer a custom QWidget with only the parts I needed if I were you. Adding a statusbar and menu isn't that much code.
multiple main windows is no issue at all. I also use them in my application and they work fine. You can either have the main windows separately (no parent) or dependant on some main mainwindow, so that they are closed when the main mainwindow is closed.
When your main windows have independent lives and menus, status lines etc., this speaks even more for multiple main windows that probably should all have no parent assigned.
So, yes, your approach seems perfectly fine to me.
I have an already fully functioning app, with a custom widget that opens a custom QMenu when clicked, by calling exec_():
menu.exec_(QPoint)
I recently migrated from PyQt4->PyQt5 and noticed that the focusOutEvent method I was overriding was no longer responsive. I already have a fix, which works just fine:
menu.setFocus() #calling this prior to exec_()
Nevertheless, I would like to understand what exactly is different after the Qt migration, that I had to manually set the focus in order to keep desired functionality.
The menu is set to have StrongFocus.
Another apparent issue that might be related is that the setting of the cursor to hand fails to change back to regular cursor when the cursor leaves the menu rect.
Thank you! =)
Using Pyside, but a general Qt question:
I am building a Qt app with a controlling QMainWindow. From this window the user can open other QMainWindows (or QDialogs) and from some of those she can open more. The user is intended to think of the first QMainWindow as "the app" and the others as lots of different views on more or less the same data.
So I'd like all the windows to be independently stackable so the user can set up the screen to their own requirements. In particular I want the user to be able to bring the first QMainWindow on top if wanted. But I don't really want each window to have its own task bar entry (though I can live with that). Also I would like them to minimise and restore together, and I would like them all to close when the first main window closes.
If I parent them all on the first mainwindow it works nicely except they stay on top of it which is not what I want.
Instead I have it kind of working by making them all independent with parent = None. Then I register them all with the main window and close them all when it closes. But this makes them a bit too independent - they minimise separately and have their own task bar entry.
Am I missing some obvious fix to this? Is there any easy way (a flag?) to stop the children staying on top of the parent?
Or is there some UI guideline that I am breaking by desiring this?
Or is there a cleaner design somehow? I thought of adding a dummy parent that they could all descend from but maybe that's messy. Would that parent need a visual presence? I wouldn't want that.
Suggestions?
You can have as many QMainWindows as you want, or parentless QWidgets. I think the best way to handle your situation is to create your own pseudo parent-child relationship like this:
In your QMainWindow subclass, store a QList of all the QWidgets you want it to manage. Then, again in your QMainWindow subclass, reimplement methods such as QWidget::closeEvent(), QWidget::hideEvent() (for when the window is minimized), and QWidget::showEvent() (for when it is restored) so that it also closes, hides, or shows all of the widgets in its QList. Make sure to also delete them in the QMainWindow subclass's destructor. Now, whenever you create a sub-window, pass the main window a pointer to it not as a normal QWidget child, but just so that it can be added to the main window's QList of QWidgets to manage. E.g.:
MainWindowSubclass::addPseudoChild(QWidget *pseudoChild)
{
myListOfPseudoChildren.append(pseudoChild);
}
Another alternative that hasn't been mentioned yet is populating a QMdiArea with QMdiSubWindows. It doesn't do exactly what you asked for, but it's a pretty clean design nonetheless.
So I thought I would add what I eventually settled upon. This was particularly inspired by the comments of #leemes (Thanks - good stuff) and a little experimentation of my own.
I used the code attached here DetachTabExample
to develop a "Detachable Tab" widget and tab bar. This allows tabs to be dragged outside the main window when they become independent windows. Then if closed they return to the tab bar.
Then I placed all my content in the QMainWindow but in separate tabs. The users can drag the ones they want out on to the other monitor. Seems to be working fine. There are still some extra windows that I have floating but it has cut down the clutter and clarified the structure.
I am trying to use QSystemTrayIcon for my application and i am facing some problems.
It is the first time i use qt so i am not really used to it.
I followed this tutorial to make a system tray icon but i fail to customize it.
I want to have a button show/hide and not 3 show, hide, restore. These actions are really confusing for a newbie and i dont know what to do and what to connect.
I tried some things but with no luck.
Also when the system tray menu appears if you click somewhere else, the menu stays open.
Any way to solve this thing too?
If you want to remove one of the menu items, modify the createTrayIcon function so that it only adds the actions you need (and clean up the unused members once you get it to work). It's that simple.
If you want a single menu item or button to toggle between visible and hidden, you'll need to create a custom slot that calls show() or hide() (or setVisible(bool)) depending on whether the widget is hidden or not (use isVisible() for that for example). Then connect your action to that slot.
Read the Signals and Slots documentation and examples for information about how to create a new slot.