Hi,

On Wed, 2008-05-28 at 08:55 +0200, "Procházka Lukáš Ing. - Pontex s. r.

I'd like ALL GIMP windows (typicaly one named "GIMP", window "Layers", window "Brushes", window with edited images etc.) to be brought to the front (of other non-GIMP windows), when an arbitrary of them is selected (e.g. via Alt+Tab) or clicked on.

We have discussed this and it would be very difficult to implement, if not impossible. This is because such functionality would have to be implemented at the window manager level.

Your request is also somewhat obsolete due to a couple of changes in trunk that will be in GIMP 2.6. For window managers that honor the "utility" window hint, the problem is basically solved. What's currently missing is a proper implementation of this window manager hint in the Win32 port of GTK+/GDK. If you can help with that, that would be very much appreciated and it would basically solve your feature request.

In case of WinXP (and probably MS Win in general): All [parent dependent] windows created with a special creation flag (maybe WS_CHILD or WS_TOOLWINDOW window style in WinAPI, see e.g. MSDN for CreateWindowEx() function) are automatically brought to the top. If they don't have such creation flag, behaviour described above must be implemented another way.

Please try if this API can be used to implement the behavior described above. There's a bug report for this at http://bugzilla.gnome.org/show_bug.cgi?id=132501

Sven

Sven Neumann wrote:

Procházka Lukáš Ing. - Pontex s. r. wrote:

I'd like ALL GIMP windows (typicaly one named "GIMP", window "Layers", window "Brushes", window with edited images etc.) to be brought to the front (of other non-GIMP windows), when an arbitrary of them is selected (e.g. via Alt+Tab) or clicked on.

We have discussed this and it would be very difficult to implement, if not impossible. This is because such functionality would have to be implemented at the window manager level.

Your request is also somewhat obsolete due to a couple of changes in trunk that will be in GIMP 2.6. For window managers that honor the "utility" window hint, the problem is basically solved. What's currently missing is a proper implementation of this window manager hint in the Win32 port of GTK+/GDK. If you can help with that, that would be very much appreciated and it would basically solve your feature request.

What does help a bit is bringing an image window to the front then hitting TAB twice - that'll hide then show all the dock windows and thus bring them to the front.

By the way - would it be possible to make that key (TAB) configurable? It would be really nice to be able to work in fullscreen all the time by just showing and hiding all dock windows when neccessary, but TAB ceases to work as soon as some control in a dock has focus...

(I guess an option to disable TAB to switch between controls in the dock windows - which I personally never need, since I navigate the docks with the mouse - isn't an option, is it?)

That or the ability to scroll beyond the image's bounds (extending the scroll bars to go half the width/height of the window beyond the image edges) would make working a lot easier - I find myself constantly resizing image windows after opening to fit them between the toolbox and the dock so that everything stays accessible.

Just my 0.02 EYPO...

Von: "Procházka Lukáš Ing. - Pontex s. r. o."

I'd like ALL GIMP windows (typicaly one named "GIMP", window "Layers", window "Brushes", window with edited images etc.) to be brought to the front (of other non-GIMP windows), when an arbitrary of them is selected (e.g. via Alt+Tab) or clicked on.

As only MS Win user, I'm no judge of how other window managers work.

In case of WinXP (and probably MS Win in general): All [parent dependent] windows created with a special creation flag (maybe WS_CHILD or WS_TOOLWINDOW window style in WinAPI, see e.g. MSDN for CreateWindowEx() function) are automatically brought to the top. If they don't have such creation flag, behaviour described above must be implemented another way.

If you want to change the behaviour on Windows, then you should check how you can contribute to GTK+. This is where window-management related problems are supposed to be solved (for example, if the the "always on top" hint for docks would work, then one big problem would be solved already).

There shouldn't be no platform-dependent code in GIMP for this, after all this is what GTK+ is supposed to abstract away from applications.

HTH, Michael

Hi,

On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:

That or the ability to scroll beyond the image's bounds (extending the scroll bars to go half the width/height of the window beyond the image edges) would make working a lot easier - I find myself constantly resizing image windows after opening to fit them between the toolbox and the dock so that everything stays accessible.

That is on the list for 2.6 (as you could have easily found out by browsing the bugs on the milestone).

Sven

Sven Neumann wrote:

On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:

That or the ability to scroll beyond the image's bounds (extending the scroll bars to go half the width/height of the window beyond the image edges) would make working a lot easier - I find myself constantly resizing image windows after opening to fit them between the toolbox and the dock so that everything stays accessible.

That is on the list for 2.6 (as you could have easily found out by browsing the bugs on the milestone).

I know that, I just wanted to present it as a usable alternative to being able to hit TAB anytime to show/hide the dock windows.

Still - would it be possible to make the function the TAB key currently has remappable, like all the other functions that already are?

Hi,

On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:

(I guess an option to disable TAB to switch between controls in the dock windows - which I personally never need, since I navigate the docks with the mouse - isn't an option, is it?)

That is already possible using the existing infrastructure to redefine key-bindings in GTK+ applications. Just add something like this to your ~/.gimp-2.5/gtkrc file:

binding "no-tab" { unbind "Tab"
unbind "Tab"
}
class "GtkWindow" binding "no-tab"

Sven

Hi,

On Wed, 2008-05-28 at 10:17 +0200, Kurt Pruenner wrote:

Still - would it be possible to make the function the TAB key currently has remappable, like all the other functions that already are?

No, it can't be configured through the same mechanism as the menu keybindings. And I don't think that making it configurable is a good idea. Tab is a good choice for this as it follows the example of other applications providing similar functionality.

Sven

Hi,

On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:

It would be really nice to be able to work in fullscreen all the time by just showing and hiding all dock windows when neccessary, but TAB ceases to work as soon as some control in a dock has focus...

Tab only has this effect when the image window has the keyboard focus. It is not even bound in the dock windows (except for the default key-binding from GTK+ which is to move the focus).

Sven

If you want to change the behaviour on Windows, then you should check how you can contribute to GTK+. This is where window-management related problems are supposed to be solved (for example, if the the "always on top" hint for docks would work, then one big problem would be solved already).

One problem in implementing window manager hints and related things correctly on Windows is the lack of exact specifications what they should do, and a lack of *minimal* sample programs that could be used to verify that the implementation is correct.

--tml

One problem in implementing window manager hints and related things correctly on Windows is the lack of exact specifications what they should do, and a lack of *minimal* sample programs that could be used to verify that the implementation is correct.

That said, at least the gdk_window_set_keep_above() function can be tested with testgtk, and it seems to work. Is this what was referred to earlier in this thread?

--tml

Hi,

On Wed, 2008-05-28 at 13:22 +0300, Tor Lillqvist wrote:

That said, at least the gdk_window_set_keep_above() function can be tested with testgtk, and it seems to work. Is this what was referred to earlier in this thread?

I may be wrong, but I remember that various users reported that it would not work on Windows. Is GIMP doing something differently than testgtk?

Sven

Hi,

On Wed, 2008-05-28 at 13:17 +0300, Tor Lillqvist wrote:

One problem in implementing window manager hints and related things correctly on Windows is the lack of exact specifications what they should do, and a lack of *minimal* sample programs that could be used to verify that the implementation is correct.

I'd say the somewhat established behavior for 'utility windows' is that they are not listed in the taskbar and that they are kept above normal windows of the same application. Some window managers also reduce the window decorations, but that is probably not obligatory.

Would it help if we made a small example application? Perhaps add some code to testgtk?

Sven

That said, at least the gdk_window_set_keep_above() function can be tested with testgtk, and it seems to work.

I may be wrong, but I remember that various users reported that it would not work on Windows. Is GIMP doing something differently than testgtk?

(Pay attention to gdk vs. gtk below...)

The way GIMP uses gdk_window_set_keep_above() is different from the way testgtk uses it. GIMP actually calls gtk_window_set_keep_above(), and before the window has been mapped even. This, I guess, as such is a reasonable thing to do, but the end result is that gdk_window_set_keep_above() never gets called for a mapped window with setting=TRUE.

Presumably this is due to some bug in GTK+, but I have no idea where in GTK+ exactly. As such the code for the non-mapped case of gdk_window_set_keep_above() in the win32 backend is exactly like the corresponding code in the x11 backend, it calls the cross-platform gdk_synthesize_window_state() function and the result of the actions caused by this is in cross-platform code, until eventually then something *should* cause gdk_window_set_keep_above() to be called with setting=TRUE once the window has been mapped. But that doesn't happen.

My guess is that the reason for the above is some slight difference in when and/or in what sequence GDK events are generated between the win32 and x11 backend, and that the related cross-platform code some implicit dependency on the event sequence or timing of the x11 backend. More debugging and comparing of function call traces on win32 vs. x11 would be needed to find out exactly...

testgtk on the other hand (when one clicks the "Keep above" toggle button of the "window states" test) explicitly calls gdk_window_set_keep_above() with setting=TRUE on an already mapped window... and that works.

Perhaps it would be a good idea to add also a test for the setting keep-above before a window is shown to testgtk.

I'd say the somewhat established behavior for 'utility windows' is that they are not listed in the taskbar and that they are kept above normal windows of the same application. Some window managers also reduce the window decorations, but that is probably not obligatory.

Would it help if we made a small example application? Perhaps add some code to testgtk?

That would make testing a bit easier, yes.

--tml

Hi,

On Thu, 2008-05-29 at 12:14 +0300, Tor Lillqvist wrote:

Would it help if we made a small example application? Perhaps add some code to testgtk?

That would make testing a bit easier, yes.

I am not sure if I can find time for this soon enough. Perhaps someone else on this list is interested? You would not have to build or run this on Windows, just make two patches for testgtk. One that allows to set 'keep-above' before mapping a window. And another one that introduces a way to try the 'utility' window hint in testgtk. This is a simple task and it would help to solve some of the most urgent usability problems that GIMP faces on the Windows platform.

Sven