Re: [RP] ... --solved (with my workspace scripts) -Phuk!

[Brian May]

>>>>> "Peter" == Peter Pentchev <address@hidden> writes:

    Peter> Of course they do have a window manager - that is, there is a part of
    Peter> what the users perceive as "the one-piece GUI/OS" that specifically 
takes
    Peter> care of mapping window-level requests from the application to bitmap-
    Peter> and line-drawing level requests to the low-level graphics subsystem.
    Peter> It's just that *from the user's point of view* it is not clearly
    Peter> separated from the rest of the GUI.

Thats what I meant. As in the interface the user deals with. On
X-Windows it can be completely different depending on what
customisations the user has put in place. Try explaining to a novice
user how to debug a network problem when they don't even know how to
open an xterm a have an unknown window manager a friend setup and
configured.

In MS Windows, there is always a start menu, always a run option
(hmmm... maybe not in Vista), etc.

The "window manager" in MS Windows isn't really separated from the
programmers point of view either. In MS Windows (unless anything has
changed in recent years, but it doesn't look like it), each
application process is responsible for processing basic "window
manager" events such as moving or resizing windows. Typically this
means passing the event on to a Windows system DLL so it can deal with
it, but this happens in the same process thread that deals with the
other events for this window.

This means if an application is busy, you cannot move it out of the
way because it will not respond to the move event until it is ready;
this is unlike X-Windows were the Window manager is a separate
process, so it can continue processing events even if the application
is busy.

Ok, maybe it might get confusing when applications don't redraw on
time, but at least you aren't restricted from accessing that modal
dialog box because the application window somehow accidently covered
it. You can't move the application window out of the way because it is
waiting for a response from the dialog box first. You can't respond to
the dialog box because you don't even know it is there, it is
covered. Yes, this shouldn't happen, but it happens on MS-Windows far
to often.

I don't know anything about the model of Mac OS X here. It wouldn't
surprise me if it is the same as MS Windows.

Not that the event model of current X servers is perfect either (my
understanding is that Xorg only was one queue - so one application
doing constant flat out updates - e.g. "cat /very/large/file" in an
xterm - can prevent other applications from performing updates), but
at least there is motivation to solve these issues (even though this
one is apparently complicated to solve - may require multi-threaded
Xorg server design). Unless this has been fixed recently that is.
-- 
Brian May <address@hidden>