RSS/Atom feed Twitter
Site is read-only, email is disabled

Gimp 2.0.2 and elusive detachable"tear-ablemenus"

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

9 of 9 messages available
Toggle history

Please log in to manage your subscriptions.

Gimp 2.0.2 and elusive detachable "tear-able menus" Joseph Heled 12 Jul 21:18
  Gimp 2.0.2 and elusive detachable "tear-able menus" Sven Neumann 12 Jul 22:52
Gimp 2.0.2 and elusive detachable "tear-ablemenus" Joseph Heled 13 Jul 02:21
  Gimp 2.0.2 and elusive detachable "tear-ablemenus" Markus Triska 13 Jul 09:18
   Gimp 2.0.2 and elusive detachable "tear-ablemenus" Sven Neumann 13 Jul 09:23
Gimp 2.0.2 and elusive detachable"tear-ablemenus" Joseph Heled 13 Jul 08:24
  Gimp 2.0.2 and elusive detachable"tear-ablemenus" Sven Neumann 13 Jul 09:30
  Gimp 2.0.2 and elusive detachable"tear-ablemenus" Markus Triska 13 Jul 20:40
Gimp 2.0.2 and elusivedetachable"tear-ablemenus" Joseph Heled 13 Jul 09:52
Joseph Heled
2004-07-12 21:18:41 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable "tear-able menus"

Gimp 2.0.2 and elusive detachable "tear able menus"

Has anyone else experiences this? I can't get it to work. Say I bring the popup menu from the image, "Layers", and press the dotted line. The menu detaches, but the moment the mouse leaves it it disappears. It re-shows when I switch to another desktop, but disappears the moment i try to place the mouse on it.

I have no idea if this is a gtk problem, kde, or gimp??

$gimp --version GIMP version 2.0.2

$pkg-config --modversion gtk+-2.0 2.4.0

KDE 3.0.3-8 (stock from RH 8)

$uname -a : Linux yoda 2.4.20-30.8.legacy #1 Fri Feb 20 18:58:10 PST 2004 i686 athlon i386 GNU/Linux

Thanks, Joseph

Sven Neumann
2004-07-12 22:52:19 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable "tear-able menus"

Hi,

Joseph Heled writes:

I have no idea if this is a gtk problem, kde, or gimp??

$gimp --version GIMP version 2.0.2

$pkg-config --modversion gtk+-2.0 2.4.0

Please, by all means, update GTK+. Lots of bugs have been fixed in the 2.4 series and still using 2.4.0 is sortof lightheaded.

Sven

Joseph Heled
2004-07-13 02:21:14 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable "tear-ablemenus"

Please, by all means, update GTK+. Lots of bugs have been fixed in the 2.4 series and still using 2.4.0 is sortof lightheaded.

Life is sort of slow with a 56K modem.

Updated gtk+, glib and atk. The problem remains

$pkg-config --modversion gtk+-2.0 2.4.4
$pkg-config --modversion glib-2.0
2.4.4

I guess that if no one else has this problem, it is a kde problem. I know there is a kde-3.0.5 available for RH 8.0, but I doubt something as obscure has been fixed in such a small upgrade.

-Joseph

Joseph Heled
2004-07-13 08:24:36 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable"tear-ablemenus"

Hi,

Your remark about "focus policy" sent me to the KDE control center - and yes, it is a focus problem of sorts. I was running with "focus strictly under mouse" (CC/Look & Feel/Window Behavior/Focus). When I Change that to "Click to Focus", the menu remains until the window focus is lost. Would you do me a favor and see under which policy you run and if you get the same problem if you switch to another policy? (actually all you have to do is to detach a menu and switch focus by clicking on another window).

Still, the menu disappears after a focus lose and does not return. This can be either a KDE bug or GTK bug.

gimp 1.2 (under gtk 1.2) has no such problem since the menu has its own window, i.e.comes up with a title bar of it's own.

And I have no other gtk2 program which brings up detachable menus ...

Gnome is not an option right now. Even the installed one is broken after I updated the libg/gtk 2.4. I can't allow an upgrade the kill my KDE, which can happen :(

-Joseph

> That would also be my guess. I've been using Gimp with KDE 3.[012] for some > time, and although I (contrary to you) never ran into anything that I knew > should work but didn't, there surely were moments that made me doubt the > cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me > with regards to that, so I recommend that you give it a shot (if possible) > and see if the problem remains, to narrow down the range of imagined > possibilities.

Markus Triska
2004-07-13 09:18:49 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable "tear-ablemenus"

I guess that if no one else has this problem, it is a kde problem.

That would also be my guess. I've been using Gimp with KDE 3.[012] for some time, and although I (contrary to you) never ran into anything that I knew should work but didn't, there surely were moments that made me doubt the cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me with regards to that, so I recommend that you give it a shot (if possible) and see if the problem remains, to narrow down the range of imagined possibilities.

Markus.

Sven Neumann
2004-07-13 09:23:24 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable "tear-ablemenus"

Hi,

Markus Triska writes:

I guess that if no one else has this problem, it is a kde problem.

That would also be my guess. I've been using Gimp with KDE 3.[012] for some time, and although I (contrary to you) never ran into anything that I knew should work but didn't, there surely were moments that made me doubt the cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me with regards to that, so I recommend that you give it a shot (if possible) and see if the problem remains, to narrow down the range of imagined possibilities.

It should be sufficient to try a different window manager, you shouldn't have to completely switch your desktop to make that happen. But then, I don't know how closely the KDE window manager is integrated with their desktop.

Excuse my ignorance, but what is the default focus policy on KDE nowadays?

Sven

Sven Neumann
2004-07-13 09:30:30 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable"tear-ablemenus"

Hi,

Joseph Heled writes:

Still, the menu disappears after a focus lose and does not return. This can be either a KDE bug or GTK bug.

gimp 1.2 (under gtk 1.2) has no such problem since the menu has its own window, i.e.comes up with a title bar of it's own.

The detached menus certainly get window decorations here (using sawfish) so this is most likely a bug in the KDE window manager then.

Sven

Joseph Heled
2004-07-13 09:52:54 UTC (over 19 years ago)

Gimp 2.0.2 and elusivedetachable"tear-ablemenus"

Yes it is certainly a KDE problem. Both WindowMaker and twm gave the menu a decoration (i.e. a title bar). Google shows that several others has encountered the problem on KDE 3.0X, and tearoff is disabled (and commented out) in KDE 3.1. I wonder if they solved it in 3.2/3.3?

Thanks for your all of you who has responded !!

Joseph

Markus Triska
2004-07-13 20:40:55 UTC (over 19 years ago)

Gimp 2.0.2 and elusive detachable"tear-ablemenus"

On Tuesday 13 July 2004 06:24 am, Joseph Heled wrote:

Your remark about "focus policy" sent me to the KDE control center - and yes, it is a focus problem of sorts. I was running with "focus strictly under mouse" (CC/Look & Feel/Window Behavior/Focus). When I Change that to "Click to Focus", the menu remains until the window focus is lost. Would you do me a favor and see under which policy you run and if you get the same problem if you switch to another policy? (actually all you have to do is to detach a menu and switch focus by clicking on another window).

Still, the menu disappears after a focus lose and does not return. This can be either a KDE bug or GTK bug.

I have now tried both options ("focus strictly under mouse" and "click to focus") in KDE 3.2.3 without problems: I can tear off menus and they receive focus when under the mouse / I click on them (depending on the setting). They do not disappear magically. In short: works perfectly.

I consider it unlikely that we will easily find the exact cause of the problem (could be deep inside Qt), and even if we do, the fix could be non-trivial. Depending on how much you want working tear-off menus (beside other advantages of newer KDE versions), an update of KDE and/or Qt would therefore still seem to be the easiest way to fix the problem. For instance (assuming the worst possible outcome of an attempted KDE update), backing up my entire system and doing a complete re-install would cost me approximately 12 hours, maybe more, but not more than 15 hours. I guess that this is still nothing compared to locating the problem and fixing it, but I could of course be wrong (with both).

Markus.