After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 363738 - pick better size and position of the initial image window
pick better size and position of the initial image window
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal minor
: 2.10
Assigned To: GIMP Bugs
: 373319 (view as bug list)
Depends on:
Reported: 2006-10-20 19:03 UTC by martin.buchner
Modified: 2018-05-24 12:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

first shot at such an algorithm (8.32 KB, patch)
2006-12-19 13:29 UTC, Sven Neumann
needs-work Details | Review

Description martin.buchner 2006-10-20 19:03:33 UTC
An other algorithm (more alternatives) for the size and position of the
initial image window would be perfect: If choosen in the settings, the initial
image window should not go over the program window of gimp (like an normal window-program) and use all the place of the complete rest of the screen.

Other information:
It is possipble in the general settings to save the size and position of the program-window and docks. It would be famous, if there is a possibility for choose the size and position of the initial image window. I want the maximum place for my first image/photo. I use GIMP to correct photos. My program-window of GIMP is on the side and the complete rest of my screen should by used of the first image (like other Window-programs). I know, this is not helpful for everyone, but a possibility for this setting would be wounderfull. Otherwise I have to do by every photo the same work: Set the size of the window to the maximum beside the program-window.
I suggest this possibilities in the settings for the initial image window:
-rest of the screen beside the program-window (picture could be smaller on one side as the initial image window)
-maximum place beside the program-window, but the picture has the same proportion as the initial image window (initial image window could be smaller on one side as the maximum screen beside the program-window)
-full screen
Comment 1 Sven Neumann 2006-11-10 10:12:33 UTC
*** Bug 373319 has been marked as a duplicate of this bug. ***
Comment 2 Sven Neumann 2006-12-19 13:29:17 UTC
Created attachment 78621 [details] [review]
first shot at such an algorithm

The patch outlines how such an algorithm could work. It doesn't cope well with a cluttered screen yet, it uses arbitrary hardcoded values to account for window decorations and it doesn't set a reasonable initial zoom ratio.
Comment 3 Sven Neumann 2008-01-15 13:38:01 UTC
Changing version to "Current SVN" as this request is not specific to any
particular version.
Comment 4 Michael Natterer 2012-01-08 21:58:15 UTC
Setting milestone to 2.10 because there is a prototype patch to find
empty regions on the screen which is worth looking into.
Comment 5 strata_ranger 2012-05-05 17:25:49 UTC
As an aside, this problem can be avoided entirely on GIMP 2.8 when running it in single-window mode.  I had problems with GIMP 2.6 placing the main image window underneath the toolbar windows all the time....
Comment 6 Jehan 2017-11-19 15:25:13 UTC
This is still needed but since SWM is now our default and it does not look like anyone is really looking this as a priority, we should just bump to 2.12 milestone to not slow down 2.10 release. I will try to have a look at the proposed algorithm after 2.10 release if I can make the time.
Comment 7 Jehan 2017-12-04 23:48:24 UTC
Putting back to 2.10 milestone. We decided to simply put the very import bugs as blockers. Anything non-blocker have simply very few chances to make it unless someone decides to give it an importance (by working on it and providing working patches).
Comment 8 GNOME Infrastructure Team 2018-05-24 12:01:50 UTC
-- 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: