Carol Spears writes: > another really awesome approach to fixing this problem would be to write > a window manager for windows! you would become famous and wellknown in > all of the software communities if you could accomplish such a task! Hmm, no. Don't mix up things here. The X11 protocol was designed from the start to have well-defined and well-separated special clients called "window managers" that do a specific job and are interchangeable, and there is no *the* standard window manager. In Windows, however, things are way different. Sure, there are some 3rd-party replacements for the Explorer "shell" (which is what corresponds most closely to the concept of window manager in X11). But I don't think one can seriously consider them more than fringe efforts. (Sure, I am certain they have a bunch of fanatical followers as fringe efforts usually have...) > the standards for this window manager that all of the cool free software > applications have agreed to use can be found at: > http://www.freedesktop.org so if you follow those guidelines, you will > be working with us and not against us. Yeah, but the specifications and guidelines on freedesktop.org are explicitly specific to X11. Their relevance for GTK (and GIMP) on Windows is that if they define how things should work on X11, and then if there is a program that exercises some specific window state manipulation functionality on X11, one can then look at that program's behaviour on X11 as a model when implementing the same functionality on GTK/Win32. Many of the problems related to GIMP window management on Windows are simply because of bugs in GTK on Win32. Fixing these bugs is just a matter of somebody having the time and inspiration to do it, and most importantly, to verify that fixing one thing doesn't break something else... It would be most welcome to have a set of minimal test programs that would exercise specific window management features that are visible though the platform-independent GTK API, so that one could then hack GTK/Win32 until the programs behaves as close as possible as on X11 (using some popular and hopefully standards-conforming window manager). These test programs would then also form a regression test suite. To put it a bit bluntly, much of the window state manipulation functionality in GTK has just appeared in the X11 backend, with little specification what it should exactly do, and what function call sequences are expected to work and what aren't necessarily expected to work. (For instance, is it expected to work if a program sets a GTK window decorations before the underlying real GDK window has been realized?) It shouldn't be hard to understand that the Win32 implementation then has been partly just guesswork, which happens to work well with some programs, but not with others. --tml _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
