window resizes when toolbar/popup is opened

Changing status to 'Confirmed' due to number of duplicates and affected users.

This one bug makes Inkscape completely unusable. (having to re-maximize after every operation) I took a look at it to see if I could fix it myself but my knowledge of GTK is lacking (actually I've never used it so it's completely absent altogether).

Actually there is a workaround, i noticed that the window resizes only if you maximize it by dragging it to the upper border.
If you restore the window and maximize it with the button it does not resize...

Wow, thank you! That actually helps a lot. I had been leaving it non-maximized and just stretched to the corners. This way is much better. (it also makes me think this is an internal GTK bug since I imagine GTK handles stuff like that)

Apparently double-clicking the titlebar is also a workaround for the bug.

Reproduced on Windows Seven, Inkscape trunk revision 10927.
Not reproduced with r10927+gtk-2.24.8 (local modification).

Fixed with the latest devlibs (released in 0.48.3.1).

While the latest release has solved the issue when a window is dragged to the top of the screen and resized, the issue still appears to be present if the window is dragged to either side and resized to half screen. Hope that makes sense.

Thanks in advance!

This is broken again in 0.48.4 in Windows 7 x64.

I snap the Inkscape window to the left in W7, then if I select an object and try to open "Object Properties", Inkscape's window gets re-sized really small. :(

I confirm it's not completely fixed.
It now works when you drag to window to the top, but not when you drag it to the left or right side of the screen.

This is definitely still broken on Windows 7 x64 and Inkscape 0.48.4. Aero Snap Inkscape to either side of the display and open Fill and Stroke settings (Ctrl+Shift+F) and the window will resize.

I'm running 0.48.4 r9939 on Win7 32-bit and have the same problem. I'm not sure what Aero Snap is, but I rarely run maximized windows for any app. Inkscape is no exception.

The initial window is a small square like the original report described. I drag a corner to enlarge it OK, then manually move it, usually to the right side of the screen though it is rarely exactly half the screen wide or the full length high. Open a panel using keyboard shortcuts (e.g. CTRL+SHIFT+L) and the window resizes itself to very small again. After dragging a corner to enlarge it again the size sometimes sticks when another panel is opened (e.g. CTRL+SHIFT+F), sometimes it resizes itself again.

Don't know if it would matter, but another way to dock/maximize the window is via keyboard shortcuts.
It uses the Windows key (http://en.wikipedia.org/wiki/Windows_key) and then an arrow-key, with Shift for some situations. See the following:

Windows key + Left arrow = dock to the left side of the screen. If you press it again and again, it will cycle through left and right positions, also if you have multiple monitors.

Windows key + Right arrow = dock to the Right side of the screen. If you press it again and again, it will cycle through right and left positions, also if you have multiple monitors.

Windows key + Up arrow = Maximize window.

Windows key + Shift + Left arrow = Move the window from the current monitor to another monitor (towards the left). Retain the window position and dock/maximize-state.

Windows key + Shift + Right arrow = Move the window from the current monitor to another monitor (towards the right). Retain the window position and dock/maximize-state.

Not as important in this scenario, but related:

Windows key + Down arrow = minimize the window.

on my Windows 7 machine I found the Aero Snap feature so incredibly annoying that I finally learned how to disable it completely using the instructions at:

http://www.sevenforums.com/tutorials/3069-aero-snap-turn-off.html

This bug is still in Inkscape 0.91 final. This is quite annoying because one has to restore the size of Inkscape several times which slows down the work flow a lot. Note that this bug is independent of using Aero. I don't use Aero and set Inkscape's size so that is covers the full height but not the full width (I only have one screen). Due to this bug Inkscape is always resized so that it sticks at the upper left corner of the screen and is so small that one cannot see the content. -> super, super annoying!

PLEASE fix this a.s.a.p. It's annoying the crap out of me and my colleagues and I know a lot of people avoid Inkscape for this very bug. I really hope you will make this a top priority bug fix

- cannot reproduce the bug using Windows 7, 32 bit, Inkscape 0.91 r13725 (Jan 30 2015)
- I have disabled Aero-Snap as indicated in comment 14
- Preferences settings are as shown in the attached bitmap:

- could you indicate which version of Inkscape and also which installer, 32 bit, 64 bit, .msi, .exe?
- could you try these preferences to see if they make any difference?

This error occured on Windows 10 technincal preview, 64-bit .msi installer. But I have experienced the exact same frustration earlier on Windows 7 also with 64-bit .msi installer.
Now, however I'm on Windows 8.1 64-bit .msi installer and the error has not occured yet since format. Hooray!

Still occurs on Windows 8.1 64bit, Inkscape 0.91 r13725. There is no newer build available for Windows, so I can't test the latest version.

Why would I disable Aero Snapping? It's a super handy feature and I want to work with InkScape on one half of the screen.

Happens to me with 0.91 and win7 64-bit, only when using AERO side snap.

To reproduce:
- open inkscape, and resize the window to whatever size by dragging the corners
- use win+left(right) arrow to dock the windo to the left (right) hald fo the screen
- select file-->document properties

The window reverts to the position and size it had before snapping with AERO.

I agree that "disable Aero" is not a solution...

Likely related upstream report in GTK+/Win32:
* 698652 – Aero-snapped windows in Win7 or 8 gets restored to previous size with gtk_window_present():
  https://bugzilla.gnome.org/show_bug.cgi?id=698652

good find suv, there's even a patch and from reading about the differences between SW_SHOW and SW_SHOWNORMAL, that patch should fix it. Another user reported that it wouldn't for a certain application, but that might be caused by something else.

Anyway, that GTK bug is still status new after 2 years... Can you apply it for InkScape nonetheless?

Sorry for the uninformed question, but how does one apply that patch? (Windows 7 machine here) If I am to run the diff, what file do I run it with?

Confirmed still a problem in Win 10 Pro 64-bit and v 0.91.

Good news: The issue was addressed in GTK (see upstream bug [1] mentioned by su_v above) and is fixed starting with GTK+ version 2.24.30 (verified) and 3.19.9 (untested) respectively, see relevant commits for GTK2 [2] and GTK3 [3]

I just updated GTK2 in devlibs64 (revision 33) and can confirm this bug fixed on Windows 7 x64.
I uploaded an Inkscape build including the updated libraries at [4] for you to test.

@jazzynico: What is the status in devlibs32? I guess we're currently blocked from updating to GTK 2.24.30 due to too old dependencies? Do you have an upgrade path?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=698652
[2]
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=2299a98a5d02cf74d4beae47902cc3a5e1f9723e
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=0517063d764eaa9ca5b6053e852cb45f054758b3
[3]
https://git.gnome.org/browse/gtk+/commit/?id=07a994c89f5892fd0d7fcf6b5f3448c28e75055b
https://git.gnome.org/browse/gtk+/commit/?id=eb555979dbd457f3afddada4daf8b73f2cd66db6
[4] http://download.tuxfamily.org/inkscape/win64/Inkscape_0.91%2bdevel_64bit_r14762.7z

@Eduard - Recent GTK versions require recent Glib versions, which are more and more difficult to build on 32-bit Windows (and no longer supported on XP). So I've stopped working on it because it's too time consuming and there are lots of other urgent things to do for the project (such as updating documentation, testing patches and managing bug reports). I plan to work on it again later (probably next autumn).

Thanks, that's what I suspected. As far as XP is concerned this should luckily not be an issue since there is no Aero Snap on XP anyway.

I assume for newer OSs we can only recommend to use x64 builds whenever possible for the time being...