On Sat, Oct 24, 2009 at 6:43 PM, Ilya Zakharevich <nospam-abuse@xxxxxxxxx> wrote: > On 2009-10-21, Karl Günter Wünsch <kgw@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> IMHO the move to a single image window with dockables would solve >> quite a lot of interoperability problems. For example there are >> plenty of broken window managers out there. Relying on them (WM >> developers) getting it right in the end for the GIMP is proving to >> be a long wait. > > You are right, somehow I assumed that the problems of GIMP's window > management would be solved. Taking into account the history, this was > a short-sighted assumption. There are no problems of *GIMP*'s window management. Your failure to understand this is the reason that people are getting annoyed at you. > >> As desktop environments go the window managers that >> work with the GIMP as intended tend OTOH to be the ones that don't >> play well with KDE for example (if you even have the choice, which >> you haven't really in KDE4). Oh and windows is a beast that isn't >> handled easily as well > > BTW, I see again and again this "assumption" that the responsibility > for observed problems of GIMP may be shifted to WM's problems. I > never could understand it. WM is only responsible insofar as having the WM behaves in a consistent and predictable way is very helpful. On Linux, virtually all WMs conform to the ICCCM window management standard (the window management hints in GTK+ were designed based on ICCCM, I think). On Windows, the management conforms to no recognized standard. So the WM holds some responsibility in such misbehaviour. The main responsibility is GTKs. In the case where I confirmed the TAB behaviour, I suspect that's because I haven't configured AwesomeWM correctly: in my case it is focusing the toolbox window when it reappears, instead of keeping the focus on the image window.. this is what is preventing TAB from working, and it's definitely outside of both GIMP and GTK+'s scope to address this. I'm currently looking at how to fix my configuration. > > [Keep in mind that my experience in apps<-->WM interaction is rather > minimal - I participated in porting Perl/Tk toolkit from X11 to > non-X11 system, and watched the corresponding mailings lists for > slightly more than a decade.] > > Here is the picture as I understand the rare morcels I saw: > > a) on window creation, GIMP registers a few bits of information with GTK++; > > b) the exact meaning of these bits is not documented, and is known > to vary widely; Completely false. http://library.gnome.org/devel/gtk/unstable/GtkWindow.html http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#GdkWindowTypeHint Provides comprehensive documentation, even though it may not be in the language you most easily understand. Missing content for certain languages is not at all the same as missing content for all languages. > > c) the observed results are most of the time not what one would want; This is true. Even on the stated standard, Metacity, some odd behaviour with TAB seems to be happening (Every time the toolbox reappears, it has moved down and to the right somewhat.) I'm not sure if there is any problematic behaviour on other WMs like the KDE window manager, XFCE, fvwm, blackbox/fluxbox/etc, WindowMaker.. > > d) the interpretation is that "it's somebody else's fault". 'somebody else'.That's vague. GIMP devs have been specific and definite about this problem for a long time: it's GTK+'s fault. GIMP provides specific information, which it is GTK's job to interpret and pass onto the WM in a way that it can understand. GTK+ currently fails to translate certain information accurately for the Windows WM. You can scream until you're blue in the face and it won't make this any less true. > > Obviously, I'm missing something... I hate to ask for somebody else's > time, but I would appreciate a correction (or at least a reference to > older discussions...). > >> the window manager there sucks at managing applications that consist >> of multiple single windows that don't have a proper native >> inheritance structure > > I'm pretty sure that this is NOT how it happens in Windows. AFAIK, > there is no window manager; each application is responsible to arrange > the x/y/z-order of its toplevel windows itself (there is a simple > callback interface for such arrangements). There is window management -- otherwise you could not close windows, or minimize or maximize or move or resize windows (or switch between windows like with ALT-TAB or clicking). In fact window management covers more than the initial creation of windows, but also their movement, resizing, reordering, delivering keyboard and mouse events to the right windows, etc. The callback interface is not unique (in fact GTK implements it in a way that works on all platforms and WMs I've tried, which are many, so the 'callback' behaviour appears to be ubiquitous rather than unique to Windows.). With most WMs, the client program has a high degree of control over the particular behaviour of the windows it creates. So, arguably GIMP *could* work around GTK's current shortcomings in this area. That is just not regarded as a serious option because it is a) ugly, b)evil, and c)inevitably going to confuse GTK+. Hence, we are left with fixing GTK+ (which is the right fix). _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
