Hello.
I am wondering why ErrorDialog() does not set a parent value as default?
It makes a while since I (can) understand that Dialogs provided by gramps interface are ignoring the parent dialog within gramps UI!
Sure, it will pop-up once there is an error. Anyway, all these dialogs are designed for Gramps UI. Maybe we could get ride of additionnal issue related to Gramps dialogs by setting something on init section?
e.g., parent=self.uistate.window
The default parent=None leads to the Gtk parent mapping issue. Sure, need to fix this on addon or whatever plugins. Maybe it is not the most intuitive way for re-using Gramps’ dialogs as we do not always know that parent=None. It is discouraged by Gtk, but within Gramps (e.g., via a tool, gramplet, or plugin), the main parent window should be “gramps”. Just a possible improvement by setting the main window as parent by default seems to be a logical way. I do not know why the default is None, but getting this Gtk warning by just re-using Gramps’ dialogs could be a little bit confusing during testing for an addon. Maybe to get ride of this issue, could provide a less confusing ecosystem for addons too?
Yes…
During testing, I got such warnings.
I was able to fix them by setting parent=self.uistate.window. I (too often) called ErrorDialog, but I missed some of them. So, once it occurs I fix it on my local version of the addon. But by looking at gramps/gui/dialog.py, we can see that most dialogs do not set parent dialog. Within gramps program it sounds a little bit strange as we are running the main dialog/window. I was able to get ride of the warnings, just wondering why there is no default set, this might (or not) limit such extra warnings.
Note, we know that such warning is not a blocking issue, but as I do not think that gramps-web, betty or others projects looking at gramps API, are also re-using these (Gtk) dialogs, why the default parent is None?
Simple answer is that the dialogs don’t have access to uistate.window. This is not in their init call, and is not something that can be imported without a hack. Adding uistate to all the calls is as bad as fixing up the parent.
If you are wondering about the hack, it is possible to modify an imports dictionalry. we could do something like adding UISTATE="" to gen.const.
Then in the gui.viewmanager we could import gramps.gen.const, then at the point where self.uistate is created, add gramps.gen.config.__dict__["UISTATE"] = self.uistate which would update the config dict.
Then in each of the various dialog classes init code, you could do from gramps.gen.const import UISTATE. And finally use that to create the parent if the parent was not originally set.
If you wondered why the UISTATE import had to be done in each of the classes, instead of once at the top of the module, it is because this module gets imported early on, before UISTATE exists. So all we would get is the empty string originally set in gen.const.
It is a hack because messing with the module dict is frowned upon, some future version of Python might change this stuff and the hack would no longer work. See https://docs.python.org/3/reference/datamodule.html section 3.2.9.
Waouh, what a great answer. I just thought that there was a signal dedicated to UI (via Gtk) against CLI. So, once we called the GUI, we have a main dialog as parent by default, which might change according to dialog called. I was wrong. Thank you, Paul. I did not know that there was a legacy issue around dialogs (maybe during Gtk2-> Gtk3 upgrade?). As wrote, I have no blocking issues with this current behavior. I was rather wondering why I only got the Gtk parent mapping error when the ErrorDialog was “poping up”. I just missed to set the parent dialog, which by default is None.
Thanks!
We should avoid putting GUI code in the gramps.gen module.
How about creating a separate module for the GTK.Application class? Then we could do something like:
from gramps.gui.application import app
window = app.get_active_window()
Perhaps we could also create the application window earlier? The error messages in the GrampsApplication will still have no parent, but we can’t really avoid that.