Bugs, Blame, Bogosity



You may be aware that the status dock is not working in GNOME 2.0 and did
not work reliably in 1.4.  A number of bug reports have been filed against
window managers, docklet-using applications, and the status dock itself.
Lately, despite that the status dock has been reported not to work with
other window managers, the reports have been reassigned to sawfish; another
one was reassigned moments before this email.

The real bug is not in any of the window managers; it's not even in the
GNOME status dock. The real bug is the protocol which the docklets use.
Nowhere else are toplevel windows mapped without overriding parent
substructure event redirection when they are not intended to be controlled
by the window manager. The KDE System Tray protocol is a window manager
protocol; it should not be, but it is. It is also an incompletely
documented protocol. The version of it which the GNOME Status Dock
purports to support was last used in KDE1.

This claim I make is not without controversy. However, even if it were
prudent for the protocol to be a window manager protocol, bug reports
against window managers would be requests for enhancements. They would
certainly not be major as #62652 is; NEEDINFO would be the most
appropriate status since the window manager responsibilities of the
KDE protocol are not documented.

Despite all of this, the GNOME Status Dock has been broken since either
December 2001 or January 2002. When it was ported to libwnck, the code
which detected mapping of windows using the KDE1 protocol was removed
and not replaced by code for any version. The GNOME Status Dock is not
failing to reparent docklets, it's no longer trying. The mistaken
belief that sawfish or other window managers were responsible for the
visible problems has allowed this species of bug to thrive.

Furthermore, and I probably shouldn't mention this, the method by which
the status dock reparents KDE-style docklets exacerbates the potential
for the race condition which may occur when docklets are used with a
non-compliant window manager. The condition for such window managers
is still avoidable only by chance or by window manager error, but the
chances can be reduced by more careful attention to what must occur
for reparenting and rememberance that the X11 protocol is asynchronous.
Without a compliant window manager, the code must violate the ICCCM.
The window manager could reliably prevent it from working, but I've
not seen a window manager that would so strictly enforce the rules
as to do that. The erroneous diagnosis has prevented what small relief
of symptoms are available to the patient.

The bug in the protocol has been allowed to survive and various mutant
strains have descended from it. In that most remarkable manner of bugs,
the newer strains have served to protect the queen. In a turn probably
never witnessed in the biological world, the newest strain seems to have
infected the only predator of the bugs; without swift action it will not
be long before this unbalanced ecosystem collapses.


Destroy the queen.
Gregory Merchan
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]