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:
 >  so if you follow those guidelines, you will
 > be working with us and not against us.

Yeah, but the specifications and guidelines on 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

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

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.


Gimp-developer mailing list

Reply via email to