GNOME Bugzilla – Bug 358141
Add session management for plug-in windows
Last modified: 2018-05-24 12:00:20 UTC
user screens and desktop layout vary widely. Default size and position of plug-in windows will often need changing. (eg preview is too small to be of real use or dlg obscures something else we need on the screen - maybe outside Gimp.)
It is infuriating and distruptive to work flow if the user needs to repeatedly resize and reposition every time he calls up a tool or filter.
Plug-ins need to retain these settings from one call to the next. Preferably across sessions as well.
[Gimp-developer] UI improvements :
> specific: Filters | Motion Blur ... I resize to get a more visible
> preview size and move it out of the way of other things on the screen.
> Next time I use it I dont want to start again.
> While this is probably down to the plugin writer, at least the "common"
> filters should be vetted/modded to retain size/pos before being
> integrated. And it should be recommended for all plug-ins.
Raphaël suggests this could go in pluginrc.
I suggest this should go into sessionrc.
Both ends of that could be implemented quite trivially, even
passing the stored values to the plug-in would be a quick hack.
The problem is how to get the values from the plug-in back to
the app. The only way i see is to call a PDB function whenever
the plug-in's dialog receives GtkWidget::configure-event.
We need GimpPlugInDialog for this. AFAIK Mitch has already started to work on it. But this won't go into the tree before the 2.4 release.
The file pluginrc is of course the wrong place for this even though the name might imply that it's the right place. pluginrc is nothing but a cache of plug-in procedure registration.
Bumping to 2.8.
Not enough resources or 2.8 and not a very important feature. Bumping to Future.
Created attachment 246299 [details] [review]
How about something like this?
1. It creates a new folder in user directory.
2. When a gimp-dialog comes up, it tries to read it's rc file from the newly created folder and moves/resizes the dialog.
2. when a gimp-dialog closes, it takes the current values and writes a rc file in the newly created folder.
Since the "real" solution (refactoring the plug-in API, having a GimpPlugIn
object etc blah) won't happen for 2.10, this approach is really nice and
just the right thing for 2.10).
- Please don't use tabs in the source
- Add spaces before all '('
- The config values should be "pos-x" not "pos_x"
- Use g_build_filename() not g_strconcat() (window backslashes)
- Format function headers properly
- Most importantly: make sure this only happens to plug-in windows,
GimpDialog is used all over in the code too.
- I'm not sure if the help-id works everywhere, need to double check that
- I think the folder should simply be created when writing the config
files, no need to do this in the core.
In the "core" not in the "code.
*** Bug 700970 has been marked as a duplicate of this bug. ***
Created attachment 248873 [details] [review]
I hope, now there are no more tabs in the source. My dev-environment sometimes ignores my wishes. And hopefully, a space is before every '('.
For the most importatnt thing: Of course I agree with you but I didn't find an other way than to blacklist every known internal call to gimp_dialog_new. I cannot see in the code, how to differ plugins from internal calls.
And you are right, of course, not every plug-in uses a help-id, e.g. the famous plug-in 'gmic', so I changed to 'role'. It must not be NULL (as allowed for help-id) and it is unique enough. And 'role' is with X11 for the purpose of reallocating known windows.
I changed the location of folder creation.
The patch works in the newest master.
There is a small limitation:
Script-fu dialogs are opened in the same position. I think, this must be also the case on linux, because the title and the role is always the same. So now it shows the same behaviour. And there can be only one script-fu dialog active, so the limitation is acceptable.
Mitch, I have not checked the patch myself, but last time you said it was good and it just needed some tweaks, which Harmut did. What about now? Let's not leave good patches rot. :-)
The patch still uses manual blacklisting of plug-in dialogs, instead of
generically excluding them. This can't stay like that. The code needs
to figure if it runs in the plug-in process generically.
I meant to say "menual blacklisting of core dialogs". Also, it should be
using GIO not FILE*.
Additionally, it should honor the new preference about where to place
windows on multiple monitors, and store the window position relative
to the window's monitor, like core session management does.
(In reply to Michael Natterer from comment #12)
> The patch still uses manual blacklisting of plug-in dialogs, instead of
> generically excluding them. This can't stay like that. The code needs
> to figure if it runs in the plug-in process generically.
gimp calls g_set_prgname
so it should be possible to use g_get_prgname
Good idea, but the return value has to be compared to an other value, and I don't know, how to get that value from gimp, because calling "gimp_dialog_new" from a plug-in is an other process.
(In reply to Hartmut Kuhse from comment #16)
> Good idea, but the return value has to be compared to an other value, and I
> don't know, how to get that value from gimp, because calling
> "gimp_dialog_new" from a plug-in is an other process.
my idea was to compare its return value with "gimp" or "gimp-2.9"
But GIMP could also set an env variable GIMP_PRGNAME to
the same as what it sets as glib prgname. So a plug-in
has g_set_prgname return value comparing different from
the env variable whereas in gimp it would be identical
Other ideas could be gimp setting an env var GIMP_PLUGIN=1
in the environment of plug-ins it launches, or
GIMP_PLUGIN_SAVE_WINDOW_PLACEMENT=1/0 and obviously not setting it
in the core process.
Created attachment 297580 [details] [review]
@massimo: That works. I defined an environment variable with the basename of gimp.
As plug-ins get an own name via gimp_ui_init, I can compare them in gimp_dialog_new_valist. So blacklisting is gone so far.
I changed the storing/reading of position rc files to gio.
I do not have more than one monitor, so I cannot realize the demand to "honor the new preference where to place windows on multiple monitors, and store the window position relative to the window's monitor, like core session management does".
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/214.