Designing a Modern Window System - Xwindows

This is a discussion on Designing a Modern Window System - Xwindows ; Ahoy! I have started writing a document today about my thoughts on window system design. Any constructive comments would be appreciated on this document. Ideally I would like to join forces with some people to create a great window system ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: Designing a Modern Window System

  1. Designing a Modern Window System

    Ahoy!

    I have started writing a document today about my thoughts on window
    system design. Any constructive comments would be appreciated on this
    document. Ideally I would like to join forces with some people to
    create a great window system design. I'm currently at an impass as the
    OpenGL/3D requirement has hit, and before I do more coding I need more
    design work completed.

    http://www.xmission.com/~georgeps/tm...dowSystem2.pdf

    I also have a video of the prototype/experimental system in action here:
    http://www.xmission.com/~georgeps/tmp/opennexx.ogg

    The Ogg Theora video is usually playable with VLC or mplayer.


    George

  2. Re: Designing a Modern Window System

    George Peter Staplin writes:

    > Ahoy!
    >
    > I have started writing a document today about my thoughts on window
    > system design. Any constructive comments would be appreciated on this
    > document. Ideally I would like to join forces with some people to
    > create a great window system design.


    The X Window System is a great design. I see no need for a
    replacement. History is full of failed attempts at replacing X.
    Perhaps it would be wise to read up on some of these before trying
    again.

    > I'm currently at an impass as the OpenGL/3D requirement has hit, and
    > before I do more coding I need more design work completed.
    >
    > http://www.xmission.com/~georgeps/tm...dowSystem2.pdf


    Some comments on that document:

    > A modern window system should provide:
    > 1. a standard extensible widget toolkit


    X has shown that separating widget kits from the window system is a
    good idea. It provides the utmost flexibility in GUI design, and
    nothing precludes one or more standard widget kits being used. In
    fact, quite a number standard, in some sense of the word, widget kits
    have over time been developed for X. Had the original Xt widget
    library been more closely tied to the base window system, modern
    libraries such as Gtk and QT would be much more difficult to
    implement.

    > 2. fast transfers of graphics for video


    X is already as efficient as is practically possible in this respect.

    > 3. a simple API


    The Xlib API is really quite simple. Doing simple things requires
    very little code and memory. More complicated operations can be
    wrapped in a widget library for convenience, while still retaining
    full flexibility where needed.

    > 4. automatic double-buffering


    X, possibly with OpenGL extensions, already provides double-buffering
    capabilities for apps that need it. Many applications do not benefit
    from double-buffering, and being forced to use it would be a real
    nuisance as well as doubling the memory requirements.

    > 5. optional network display


    This is getting repetitive, but X already has this, and does it far
    better than VNC and its ilk.

    > 6. X11 compatibility


    If you want to be compatible with X, you may as well just use X, and
    save yourself some time.

    > 7. Drivers and modules as separate processes


    Separating things into too many processes will necessarily impact
    performance, and can easily complicate the design. In my opinion, X
    strikes a good balance here.

    From the rest of the document, I get the impression that your needs
    would be more easily fulfilled by a widget kit running on X, rather
    than a complete replacement for X.

    If you have specific issues with X, that cannot be addressed through a
    client library, I would instead suggest that you help improve it to
    overcome these problems.

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: Designing a Modern Window System

    Måns Rullgård wrote:
    > George Peter Staplin writes:
    >
    >> Ahoy!
    >>
    >> I have started writing a document today about my thoughts on window
    >> system design. Any constructive comments would be appreciated on this
    >> document. Ideally I would like to join forces with some people to
    >> create a great window system design.

    >
    > The X Window System is a great design. I see no need for a
    > replacement. History is full of failed attempts at replacing X.
    > Perhaps it would be wise to read up on some of these before trying
    > again.
    >
    >> I'm currently at an impass as the OpenGL/3D requirement has hit, and
    >> before I do more coding I need more design work completed.
    >>
    >> http://www.xmission.com/~georgeps/tm...dowSystem2.pdf

    >
    > Some comments on that document:
    >
    >> A modern window system should provide:
    >> 1. a standard extensible widget toolkit

    >
    > X has shown that separating widget kits from the window system is a
    > good idea. It provides the utmost flexibility in GUI design, and
    > nothing precludes one or more standard widget kits being used. In
    > fact, quite a number standard, in some sense of the word, widget kits
    > have over time been developed for X. Had the original Xt widget
    > library been more closely tied to the base window system, modern
    > libraries such as Gtk and QT would be much more difficult to
    > implement.



    Yes, but look at the feature sets of Gtk+ and Qt. They are very
    similar. It's still possible for the clients to extend the widget set
    with my design, or completely build there own, but the idea is you solve
    most of the problem, people won't have to reinvent the wheel.


    >> 2. fast transfers of graphics for video

    >
    > X is already as efficient as is practically possible in this respect.


    I don't believe that.

    >> 3. a simple API

    >
    > The Xlib API is really quite simple. Doing simple things requires
    > very little code and memory. More complicated operations can be
    > wrapped in a widget library for convenience, while still retaining
    > full flexibility where needed.


    I know. I've studied it for years. If it's so great why are the X.org
    developers planning a replacement for it? Why do so many of the
    toolkits use extensions? The Gtk+/Gdk, Qt, Tk, and other teams have
    been duplicating efforts that are better spent on a shared layer.

    >> 4. automatic double-buffering

    >
    > X, possibly with OpenGL extensions, already provides double-buffering
    > capabilities for apps that need it. Many applications do not benefit
    > from double-buffering, and being forced to use it would be a real
    > nuisance as well as doubling the memory requirements.


    Huh? Gtk+ and I believe Qt may optionally use Xdbe/DBE. The X
    double-buffering extension. You have to support X servers without this
    extension if you want portability, so you fallback to XCopyArea. It's
    frustrating to deal with so many code paths, and especially to test
    them.


    >> 5. optional network display

    >
    > This is getting repetitive, but X already has this, and does it far
    > better than VNC and its ilk.


    I wasn't arguing that.


    >> 6. X11 compatibility

    >
    > If you want to be compatible with X, you may as well just use X, and
    > save yourself some time.


    Have you programmed for X11 for more than 5 years?


    >> 7. Drivers and modules as separate processes

    >
    > Separating things into too many processes will necessarily impact
    > performance, and can easily complicate the design. In my opinion, X
    > strikes a good balance here.


    I don't believe it will. Especially when most systems have good support
    for fine-grained locking, to support multiple core systems.

    > From the rest of the document, I get the impression that your needs
    > would be more easily fulfilled by a widget kit running on X, rather
    > than a complete replacement for X.


    Did you understand it?

    > If you have specific issues with X, that cannot be addressed through a
    > client library, I would instead suggest that you help improve it to
    > overcome these problems.


    I program for X11 all of the time. I've written my own X toolkit. It's
    called NexTk, and runs in Windows and X11. I've used Xlib, XShm, Xv,
    Xdbe, XIM, etc. It's crazy how you have to jump through hoops and
    provide for cases where those extensions aren't available. Some of the
    extensions also lack documentation, so they aren't as useful as they
    could be.

    I suspect I misunderstood the tone of your message, at least I hope I
    have. Perhaps you misunderstood my writings. I wasn't attempting to
    bash X11. X11 has known problems. I'm not sure that X12 (as documented
    on the X.org wiki is going to be entirely better). X11 was designed in
    a different time. I have a lot of respect for the work of the authors
    of X11. I'm using it now.


    George

  4. Re: Designing a Modern Window System

    On Feb 13, 8:37 pm, George Peter Staplin
    wrote:

    > > X has shown that separating widget kits from the window system is a
    > > good idea. It provides the utmost flexibility in GUI design, and
    > > nothing precludes one or more standard widget kits being used. In
    > > fact, quite a number standard, in some sense of the word, widget kits
    > > have over time been developed for X. Had the original Xt widget
    > > library been more closely tied to the base window system, modern
    > > libraries such as Gtk and QT would be much more difficult to
    > > implement.

    >
    > Yes, but look at the feature sets of Gtk+ and Qt. They are very
    > similar. It's still possible for the clients to extend the widget set
    > with my design, or completely build there own, but the idea is you solve
    > most of the problem, people won't have to reinvent the wheel.


    How easy is itto extend your system? Without concrete examples, I'll
    reserve judgement. Also, there is often need to reinvent the wheel.
    After all, modern cars don't run around on log rollers.

    > >> 2. fast transfers of graphics for video

    >
    > > X is already as efficient as is practically possible in this respect.

    >
    > I don't believe that.


    glDrawPixels (under GLX), ShmPutImage and XVPutImage all seem to go
    very fast. XVPutImage is particularly lightweight even on old cards,
    and spans xinerama across different chipsets. OpenGL works well too,
    and can span multiple discrete cards. But this still seems more of a
    quality of implementation issue, not a problem with the design of X.

    > >> 3. a simple API

    >
    > > The Xlib API is really quite simple. Doing simple things requires
    > > very little code and memory. More complicated operations can be
    > > wrapped in a widget library for convenience, while still retaining
    > > full flexibility where needed.

    >
    > I know. I've studied it for years. If it's so great why are the X.org
    > developers planning a replacement for it?


    This brings up another point. You can write a different API wrapper
    for the protocol. Is there any need to replace X11, rather than
    providing an alternative to one of the components (xlib)?

    > Why do so many of the
    > toolkits use extensions?


    Because the world of graphics has moved on a lot in 25 years. Many of
    the extensions are part of the standard for a given release number.
    Given that the world of graphics will move on a lot in the next 25
    years, your system will also need to be extensible. If you want an
    easier time, you can assume that you're targeting a recent X11
    implementation, and simply fail if the extensions are not present.
    This will have much the same effect as replacing X1 completely.

    > The Gtk+/Gdk, Qt, Tk, and other teams have
    > been duplicating efforts that are better spent on a shared layer.


    What has that got to do with extensions? What exactly is the shared
    layer?

    > >> 4. automatic double-buffering

    >
    > > X, possibly with OpenGL extensions, already provides double-buffering
    > > capabilities for apps that need it. Many applications do not benefit
    > > from double-buffering, and being forced to use it would be a real
    > > nuisance as well as doubling the memory requirements.

    >
    > Huh? Gtk+ and I believe Qt may optionally use Xdbe/DBE. The X
    > double-buffering extension. You have to support X servers without this
    > extension if you want portability, so you fallback to XCopyArea. It's
    > frustrating to deal with so many code paths, and especially to test
    > them.


    You can't have a replacement system which is portable to old
    installations and not have portability problems, whether it's a
    complete replacement for X, or a list of required features.

    > >> 5. optional network display

    >
    > > This is getting repetitive, but X already has this, and does it far
    > > better than VNC and its ilk.

    >
    > I wasn't arguing that.


    What do you mean by optional?

    > >> 6. X11 compatibility

    >
    > > If you want to be compatible with X, you may as well just use X, and
    > > save yourself some time.

    >
    > Have you programmed for X11 for more than 5 years?


    How can you have X11 compatibility and get around the problems with
    compatibility within X11?

    > >> 7. Drivers and modules as separate processes

    >
    > > Separating things into too many processes will necessarily impact
    > > performance, and can easily complicate the design. In my opinion, X
    > > strikes a good balance here.

    >
    > I don't believe it will. Especially when most systems have good support
    > for fine-grained locking, to support multiple core systems.


    This is nothing to do with X, and only something to do with xorg.
    There is nothing in the protocol which precludes the use of a
    multithreaded server. Besides that, is there any real need for a
    multithreaded server?

    > > From the rest of the document, I get the impression that your needs
    > > would be more easily fulfilled by a widget kit running on X, rather
    > > than a complete replacement for X.

    >
    > Did you understand it?
    >
    > > If you have specific issues with X, that cannot be addressed through a
    > > client library, I would instead suggest that you help improve it to
    > > overcome these problems.

    >
    > I program for X11 all of the time. I've written my own X toolkit. It's
    > called NexTk, and runs in Windows and X11. I've used Xlib, XShm, Xv,
    > Xdbe, XIM, etc. It's crazy how you have to jump through hoops and
    > provide for cases where those extensions aren't available. Some of the
    > extensions also lack documentation, so they aren't as useful as they
    > could be.


    You want your new system to be backwards compatible with X11. Why not
    just say something along the lines of:

    X12 == X11R7.3

    Now I'm targeting X12 (ie all the features in 7.3 must be available),
    so if you don't have X12, then the program won't run. This seems to
    solve many of the problems that are solvable.

    My personal favourite idea is to have a VM on the server, the idea
    being that the processes in the VM could do things like handling
    widgets, and pass infrequent messages back. One could remove very many
    round trips that way. Further, if the VM makes xlib calls, it could
    work over the network, so if the VM extension is not present, there it
    will still work transparently (but not quite as fast). DoS attacks may
    be a problem, though.

    -Ed

    --
    (You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

    /d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
    r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
    d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage

  5. Re: Designing a Modern Window System

    George Peter Staplin writes:

    > Måns Rullgård wrote:
    >> George Peter Staplin writes:
    >>
    >>> Ahoy!
    >>>
    >>> I have started writing a document today about my thoughts on window
    >>> system design. Any constructive comments would be appreciated on this
    >>> document. Ideally I would like to join forces with some people to
    >>> create a great window system design.

    >>
    >> The X Window System is a great design. I see no need for a
    >> replacement. History is full of failed attempts at replacing X.
    >> Perhaps it would be wise to read up on some of these before trying
    >> again.
    >>
    >>> I'm currently at an impass as the OpenGL/3D requirement has hit, and
    >>> before I do more coding I need more design work completed.
    >>>
    >>> http://www.xmission.com/~georgeps/tm...dowSystem2.pdf

    >>
    >> Some comments on that document:
    >>
    >>> A modern window system should provide:
    >>> 1. a standard extensible widget toolkit

    >>
    >> X has shown that separating widget kits from the window system is a
    >> good idea. It provides the utmost flexibility in GUI design, and
    >> nothing precludes one or more standard widget kits being used. In
    >> fact, quite a number standard, in some sense of the word, widget kits
    >> have over time been developed for X. Had the original Xt widget
    >> library been more closely tied to the base window system, modern
    >> libraries such as Gtk and QT would be much more difficult to
    >> implement.

    >
    > Yes, but look at the feature sets of Gtk+ and Qt. They are very
    > similar. It's still possible for the clients to extend the widget set
    > with my design, or completely build there own, but the idea is you solve
    > most of the problem, people won't have to reinvent the wheel.
    >
    >>> 2. fast transfers of graphics for video

    >>
    >> X is already as efficient as is practically possible in this respect.

    >
    > I don't believe that.


    And I believe it does. Now it is your job to prove me wrong.
    Properly performed benchmarks would be one to do that.

    >>> 3. a simple API

    >>
    >> The Xlib API is really quite simple. Doing simple things requires
    >> very little code and memory. More complicated operations can be
    >> wrapped in a widget library for convenience, while still retaining
    >> full flexibility where needed.

    >
    > I know. I've studied it for years. If it's so great why are the X.org
    > developers planning a replacement for it?


    You'd have to ask them.

    > Why do so many of the toolkits use extensions?


    Many X11 extensions wouldn't have made sense when the first protocol
    version was written (e.g. due to advances in hardware capabilities).
    Many of them still don't make sense in every implementation. That
    said, quite a number of extensions are now available in all but the
    most obscure of implementations, and can for the most part be assumed
    present.

    > The Gtk+/Gdk, Qt, Tk, and other teams have been duplicating efforts
    > that are better spent on a shared layer.


    I don't use those toolkits.

    >>> 4. automatic double-buffering

    >>
    >> X, possibly with OpenGL extensions, already provides double-buffering
    >> capabilities for apps that need it. Many applications do not benefit
    >> from double-buffering, and being forced to use it would be a real
    >> nuisance as well as doubling the memory requirements.

    >
    > Huh? Gtk+ and I believe Qt may optionally use Xdbe/DBE. The X
    > double-buffering extension. You have to support X servers without this
    > extension if you want portability, so you fallback to XCopyArea. It's
    > frustrating to deal with so many code paths, and especially to test
    > them.


    Let's see, X already has a double-buffering extension, and the most
    commonly used toolkits support it. What was your problem again?

    >>> 6. X11 compatibility

    >>
    >> If you want to be compatible with X, you may as well just use X, and
    >> save yourself some time.

    >
    > Have you programmed for X11 for more than 5 years?


    Yes. I don't remember when I wrote my first X application, but I do
    remember that it used Xlib directly.

    >>> 7. Drivers and modules as separate processes

    >>
    >> Separating things into too many processes will necessarily impact
    >> performance, and can easily complicate the design. In my opinion, X
    >> strikes a good balance here.

    >
    > I don't believe it will. Especially when most systems have good support
    > for fine-grained locking, to support multiple core systems.


    On my (quad-core) machine, the X server accounts for very little CPU
    time. There would be no benefit from multiple threads/processes.

    >> From the rest of the document, I get the impression that your needs
    >> would be more easily fulfilled by a widget kit running on X, rather
    >> than a complete replacement for X.

    >
    > Did you understand it?


    I believe so, and I believe that what you outline as problems have
    already been solved by X11.

    >> If you have specific issues with X, that cannot be addressed through a
    >> client library, I would instead suggest that you help improve it to
    >> overcome these problems.

    >
    > I program for X11 all of the time. I've written my own X toolkit. It's
    > called NexTk, and runs in Windows and X11. I've used Xlib, XShm, Xv,
    > Xdbe, XIM, etc. It's crazy how you have to jump through hoops and
    > provide for cases where those extensions aren't available. Some of the
    > extensions also lack documentation, so they aren't as useful as they
    > could be.


    You're still being very vague.

    --
    Måns Rullgård
    mans@mansr.com

  6. Re: Designing a Modern Window System

    Edward Rosten wrote:
    > On Feb 13, 8:37 pm, George Peter Staplin
    > wrote:
    >
    >> > X has shown that separating widget kits from the window system is a
    >> > good idea. It provides the utmost flexibility in GUI design, and
    >> > nothing precludes one or more standard widget kits being used. In
    >> > fact, quite a number standard, in some sense of the word, widget kits
    >> > have over time been developed for X. Had the original Xt widget
    >> > library been more closely tied to the base window system, modern
    >> > libraries such as Gtk and QT would be much more difficult to
    >> > implement.

    >>
    >> Yes, but look at the feature sets of Gtk+ and Qt. They are very
    >> similar. It's still possible for the clients to extend the widget set
    >> with my design, or completely build there own, but the idea is you solve
    >> most of the problem, people won't have to reinvent the wheel.

    >
    > How easy is itto extend your system? Without concrete examples, I'll
    > reserve judgement. Also, there is often need to reinvent the wheel.
    > After all, modern cars don't run around on log rollers.


    Well, you can get a pointer to the buffer of RGBA data associated with
    window contents, and write changes to that buffer, and call
    nx_update(window); and the changes are made to the display.

    >> >> 2. fast transfers of graphics for video

    >>
    >> > X is already as efficient as is practically possible in this respect.

    >>
    >> I don't believe that.

    >
    > glDrawPixels (under GLX), ShmPutImage and XVPutImage all seem to go
    > very fast. XVPutImage is particularly lightweight even on old cards,
    > and spans xinerama across different chipsets. OpenGL works well too,
    > and can span multiple discrete cards. But this still seems more of a
    > quality of implementation issue, not a problem with the design of X.


    The Xv paths are more efficient, because they use video card ports when
    available, so there is more hardware involved. However, sometimes this
    can be problematic, because you can't take a screenshot and include the
    window contents. If you try to you get a blue or green window. The
    alpha blending also wouldn't work with such windows.

    Xv can be problematic, because sometimes the video port needs to be
    reset with XV_SET_DEFAULTS, after some application using it crashes.
    Also, the SysV shared memory used by Xv and XShm can be problematic,
    because it is persistent unless an application uses IPC_RMID. So
    sometimes I hear about people with systems that run out of memory, and
    the users don't know about it, until I suggest the use of the ipcs
    program, and ipcrm to remove the entries. This is not ideal.


    >> >> 3. a simple API

    >>
    >> > The Xlib API is really quite simple. Doing simple things requires
    >> > very little code and memory. More complicated operations can be
    >> > wrapped in a widget library for convenience, while still retaining
    >> > full flexibility where needed.

    >>
    >> I know. I've studied it for years. If it's so great why are the X.org
    >> developers planning a replacement for it?

    >
    > This brings up another point. You can write a different API wrapper
    > for the protocol. Is there any need to replace X11, rather than
    > providing an alternative to one of the components (xlib)?


    Well, look at the issues of alpha compositing. The core of X11 wasn't
    designed for it. Even with the XDamage extension (which is slow), and
    Composite (which is also slow), you have issues with offscreen windows.

    It's possible to write a decent window system with only about 10,000
    lines of code that does alpha compositing. The 3D bits take more work.


    >> Why do so many of the
    >> toolkits use extensions?

    >
    > Because the world of graphics has moved on a lot in 25 years. Many of
    > the extensions are part of the standard for a given release number.
    > Given that the world of graphics will move on a lot in the next 25
    > years, your system will also need to be extensible. If you want an
    > easier time, you can assume that you're targeting a recent X11
    > implementation, and simply fail if the extensions are not present.
    > This will have much the same effect as replacing X1 completely.


    Unfortunately, some X servers don't have DBE. Failure is not always an
    option.


    >> The Gtk+/Gdk, Qt, Tk, and other teams have
    >> been duplicating efforts that are better spent on a shared layer.

    >
    > What has that got to do with extensions? What exactly is the shared
    > layer?


    The code paths necessary to implement double-buffering, fast imaging
    using shared memory (XShm or Xv), are not easy always.


    >> >> 4. automatic double-buffering

    >>
    >> > X, possibly with OpenGL extensions, already provides double-buffering
    >> > capabilities for apps that need it. Many applications do not benefit
    >> > from double-buffering, and being forced to use it would be a real
    >> > nuisance as well as doubling the memory requirements.

    >>
    >> Huh? Gtk+ and I believe Qt may optionally use Xdbe/DBE. The X
    >> double-buffering extension. You have to support X servers without this
    >> extension if you want portability, so you fallback to XCopyArea. It's
    >> frustrating to deal with so many code paths, and especially to test
    >> them.

    >
    > You can't have a replacement system which is portable to old
    > installations and not have portability problems, whether it's a
    > complete replacement for X, or a list of required features.
    >
    >> >> 5. optional network display

    >>
    >> > This is getting repetitive, but X already has this, and does it far
    >> > better than VNC and its ilk.

    >>
    >> I wasn't arguing that.

    >
    > What do you mean by optional?


    I mean that everything should't go over a socket when you're using the
    localhost.

    >> >> 6. X11 compatibility

    >>
    >> > If you want to be compatible with X, you may as well just use X, and
    >> > save yourself some time.

    >>
    >> Have you programmed for X11 for more than 5 years?

    >
    > How can you have X11 compatibility and get around the problems with
    > compatibility within X11?



    You can't. The X11 process would run as an application.


    >> >> 7. Drivers and modules as separate processes

    >>
    >> > Separating things into too many processes will necessarily impact
    >> > performance, and can easily complicate the design. In my opinion, X
    >> > strikes a good balance here.

    >>
    >> I don't believe it will. Especially when most systems have good support
    >> for fine-grained locking, to support multiple core systems.

    >
    > This is nothing to do with X, and only something to do with xorg.
    > There is nothing in the protocol which precludes the use of a
    > multithreaded server. Besides that, is there any real need for a
    > multithreaded server?


    I'm not suggesting a multithreaded server. I'm suggesting multiple
    processes, and with fine grained locking in most unix-like kernels you
    can get many of the same benefits with processes as with threads,
    without the problems associated with pthreads.


    >> > If you have specific issues with X, that cannot be addressed through a
    >> > client library, I would instead suggest that you help improve it to
    >> > overcome these problems.

    >>
    >> I program for X11 all of the time. I've written my own X toolkit. It's
    >> called NexTk, and runs in Windows and X11. I've used Xlib, XShm, Xv,
    >> Xdbe, XIM, etc. It's crazy how you have to jump through hoops and
    >> provide for cases where those extensions aren't available. Some of the
    >> extensions also lack documentation, so they aren't as useful as they
    >> could be.

    >
    > You want your new system to be backwards compatible with X11. Why not
    > just say something along the lines of:
    >
    > X12 == X11R7.3
    >
    > Now I'm targeting X12 (ie all the features in 7.3 must be available),
    > so if you don't have X12, then the program won't run. This seems to
    > solve many of the problems that are solvable.



    X12 is an X.org project, and you would still have the security issues
    with X11 if you did that.

    > My personal favourite idea is to have a VM on the server, the idea
    > being that the processes in the VM could do things like handling
    > widgets, and pass infrequent messages back. One could remove very many
    > round trips that way. Further, if the VM makes xlib calls, it could
    > work over the network, so if the VM extension is not present, there it
    > will still work transparently (but not quite as fast). DoS attacks may
    > be a problem, though.



    I guess if the OS is a LISP or similar safe system you could have the
    entire window system implemented as part of the system. I believe this
    was done before years ago. People tend to want a choice with regard to
    languages.


    George

  7. Re: Designing a Modern Window System

    George Peter Staplin wrote:
    > Ahoy!
    >
    > I have started writing a document today about my thoughts on window
    > system design. Any constructive comments would be appreciated on this
    > document. Ideally I would like to join forces with some people to
    > create a great window system design. I'm currently at an impass as the
    > OpenGL/3D requirement has hit, and before I do more coding I need more
    > design work completed.
    >
    > http://www.xmission.com/~georgeps/tm...dowSystem2.pdf
    >
    > I also have a video of the prototype/experimental system in action here:
    > http://www.xmission.com/~georgeps/tmp/opennexx.ogg
    >
    > The Ogg Theora video is usually playable with VLC or mplayer.


    To summarize. If you have nothing to do but critique my criticism of
    X11, and tell me that what I've written is already solved (including the
    security issues), then don't bother. I was looking for useful
    constructive comments towards furthering my design. I realize I can't
    hold your hand and stop you from posting whatever you want, but I simply
    won't respond to it anymore.

    I resent the idea that I shouldn't even bother. In any case, I'm sick of this.

    Progress doesn't come from people that are perfectly happy with
    teletypes or the current interfaces.


    George

  8. Re: Designing a Modern Window System

    George Peter Staplin writes:

    > George Peter Staplin wrote:
    >> Ahoy!
    >>
    >> I have started writing a document today about my thoughts on window
    >> system design. Any constructive comments would be appreciated on this
    >> document. Ideally I would like to join forces with some people to
    >> create a great window system design. I'm currently at an impass as the
    >> OpenGL/3D requirement has hit, and before I do more coding I need more
    >> design work completed.
    >>
    >> http://www.xmission.com/~georgeps/tm...dowSystem2.pdf
    >>
    >> I also have a video of the prototype/experimental system in action here:
    >> http://www.xmission.com/~georgeps/tmp/opennexx.ogg
    >>
    >> The Ogg Theora video is usually playable with VLC or mplayer.

    >
    > To summarize. If you have nothing to do but critique my criticism of
    > X11, and tell me that what I've written is already solved (including the
    > security issues), then don't bother. I was looking for useful
    > constructive comments towards furthering my design. I realize I can't
    > hold your hand and stop you from posting whatever you want, but I simply
    > won't respond to it anymore.
    >
    > I resent the idea that I shouldn't even bother. In any case, I'm sick of this.
    >
    > Progress doesn't come from people that are perfectly happy with
    > teletypes or the current interfaces.


    Ok, I looked. To convince people to join you, you need to
    present a compelling case.

    In the demo you have windows that turn on their side.
    That's the only thing I haven't seen before.
    I can't recall where I would have ever wanted to do such a thing.
    You need to show how this is useful.

    I've been able to use transparency for a while now, but haven't
    found any case where it was desirable. Again, it needs to
    look useful.

    Overall, the demo wasn't convincing.


    Reading the PDF I wasn't convinced that the benefits were worth
    the monumental effort it would take to replace X11.

    Standard Toolkit:

    X11 has had many "standard" toolkits.
    Xaw, Motif, etc. They still work but new ones continue
    to show up. The fact that they can show up is a good thing.
    Not convincing to me.

    Fast graphics:

    X11 already has shared memory support.
    I don't get the point.
    The graphics seem fast enough, even remotely.
    I'm on Verizon FIOS.

    Simple API:

    Seen too many claims that the API can be simple.
    Show examples of how simple your API is to be convincing.

    Double Buffering:

    Can't say. I don't see any flicker.

    Network display:

    The part about remote support wasn't clear to me.
    Are you proposing that the only remote support be for full desktops
    like VNC? Not good for me.

    X11 compatibility:

    If all my X11 stuff is in an XNest type window, forget it.

    Security:

    I wasn't convinced by the X11 security argument.
    There's all kinds of security in X11.
    Do you have anything more convincing about the problem?
    Can you cite instances of problems?

    Like the other poster, I have a natural tendency to
    reject solutions that propose to drop what I currently
    use and move to something new.

    Old stuff needs to be supported and incremental change
    is always better when the current solution works well enough.
    I've made some comments about how you can improve your presentation
    but I think you'd be better off trying to work within the existing
    framework and propose compatible improvements.

    Good luck in your efforts.

  9. Re: Designing a Modern Window System

    George Peter Staplin writes:

    > George Peter Staplin wrote:
    >> Ahoy!
    >>
    >> I have started writing a document today about my thoughts on window
    >> system design. Any constructive comments would be appreciated on this
    >> document. Ideally I would like to join forces with some people to
    >> create a great window system design. I'm currently at an impass as the
    >> OpenGL/3D requirement has hit, and before I do more coding I need more
    >> design work completed.
    >>
    >> http://www.xmission.com/~georgeps/tm...dowSystem2.pdf
    >>
    >> I also have a video of the prototype/experimental system in action here:
    >> http://www.xmission.com/~georgeps/tmp/opennexx.ogg
    >>
    >> The Ogg Theora video is usually playable with VLC or mplayer.

    >
    > To summarize. If you have nothing to do but critique my criticism of
    > X11, and tell me that what I've written is already solved (including the
    > security issues), then don't bother. I was looking for useful
    > constructive comments towards furthering my design. I realize I can't
    > hold your hand and stop you from posting whatever you want, but I simply
    > won't respond to it anymore.


    If you can't take the heat, don't tickle the dragon. What were you
    expecting, posting in comp.windows.x?

    --
    Måns Rullgård
    mans@mansr.com

  10. Re: Designing a Modern Window System

    On Feb 14, 10:08 am, George Peter Staplin
    wrote:
    > George Peter Staplin wrote:
    > > Ahoy!

    >
    > > I have started writing a document today about my thoughts on window
    > > system design. Any constructive comments would be appreciated on this
    > > document. Ideally I would like to join forces with some people to
    > > create a great window system design. I'm currently at an impass as the
    > > OpenGL/3D requirement has hit, and before I do more coding I need more
    > > design work completed.

    >
    > >http://www.xmission.com/~georgeps/tm...dowSystem2.pdf

    >
    > > I also have a video of the prototype/experimental system in action here:
    > >http://www.xmission.com/~georgeps/tmp/opennexx.ogg

    >
    > > The Ogg Theora video is usually playable with VLC or mplayer.

    >
    > To summarize. If you have nothing to do but critique my criticism of
    > X11, and tell me that what I've written is already solved (including the
    > security issues), then don't bother. I was looking for useful
    > constructive comments towards furthering my design. I realize I can't
    > hold your hand and stop you from posting whatever you want, but I simply
    > won't respond to it anymore.


    Why? If your criticisms of X are misplaced, then the chances are in
    attempting to fix them you will make some mistakes that X doesn't
    make. Since this is an X11 group, you can probably expect people here
    to be able to effectively comment on what X is really, really good at.
    You probably won't make a better windowing system by abandoning the
    parts that other windowing systems get right.

    Also, X has a very long history, littered with abandoned extensions
    which people thought would be useful but turned out not to be worth
    the effort (for instance marshalling all communications over shared
    memory). Again, if you ignore these, you are likely to make the same
    mistakes over again.

    > I resent the idea that I shouldn't even bother. In any case, I'm sick of this.


    Definitely bother, if you wish to.

    -Ed
    --
    (You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

    /d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
    r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
    d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage



  11. Re: Designing a Modern Window System

    On Feb 14, 9:55 am, George Peter Staplin
    wrote:

    > > How easy is itto extend your system? Without concrete examples, I'll
    > > reserve judgement. Also, there is often need to reinvent the wheel.
    > > After all, modern cars don't run around on log rollers.

    >
    > Well, you can get a pointer to the buffer of RGBA data associated with
    > window contents, and write changes to that buffer, and call
    > nx_update(window); and the changes are made to the display.


    OK, but on X, you can get a WindowID, and then draw a pixmap there.
    It's a little more of a pain in the neck, but in principle, it's the
    same for the point I'm about to make. The point is that this isn't
    extending the widget set in a meaningful manner, it's simply "doing it
    by hand". If enough people wish to do it by hand, then someone will
    write a library, and now you've got another toolkit with a different
    look-and-feel, and you're back to the same issue again.

    I don't normally make comparisons to other systems, since a system
    design will stand on its own. But, all the 3 major window systems have
    seen this happen. X has no standard toolkit, so peoplw use whatever.
    OSX and Windows do have one, but that doesn't stop people using other
    toolkits which don't use the default one.

    The problem of multiple toolkits looking and behaving differently
    seems to be a problem endemic to all window systems.


    > > glDrawPixels (under GLX), ShmPutImage and XVPutImage all seem to go
    > > very fast. XVPutImage is particularly lightweight even on old cards,
    > > and spans xinerama across different chipsets. OpenGL works well too,
    > > and can span multiple discrete cards. But this still seems more of a
    > > quality of implementation issue, not a problem with the design of X.

    >
    > The Xv paths are more efficient, because they use video card ports when
    > available, so there is more hardware involved. However, sometimes this
    > can be problematic, because you can't take a screenshot and include the
    > window contents. If you try to you get a blue or green window. The
    > alpha blending also wouldn't work with such windows.


    This isn't a problem with X being inefficient. If you don't use the XV
    paths, then you will have a less efficient system than the current X
    implementations. Your complaint was that X was inefficient in this
    case. Furthermore, if you use a new X over GL system, then you get
    efficiency and alpha blending and so on. It's back to being a quality
    of implementation issue, not an issue with X per se.

    > Xv can be problematic, because sometimes the video port needs to be
    > reset with XV_SET_DEFAULTS, after some application using it crashes.


    This again seems to be a QOI issue, not a problem with X.

    > Also, the SysV shared memory used by Xv and XShm can be problematic,
    > because it is persistent unless an application uses IPC_RMID. So
    > sometimes I hear about people with systems that run out of memory, and
    > the users don't know about it, until I suggest the use of the ipcs
    > program, and ipcrm to remove the entries. This is not ideal.


    Indeed, it is not ideal, though I haven't heard of it happening. One
    could use BSD style shared memory (via mmaping files, for instance).
    This would require a modification to the extension, though this would
    require rather less work than an entire window system.

    [...]

    > > This brings up another point. You can write a different API wrapper
    > > for the protocol. Is there any need to replace X11, rather than
    > > providing an alternative to one of the components (xlib)?

    >
    > Well, look at the issues of alpha compositing. The core of X11 wasn't
    > designed for it. Even with the XDamage extension (which is slow), and
    > Composite (which is also slow), you have issues with offscreen windows.
    >
    > It's possible to write a decent window system with only about 10,000
    > lines of code that does alpha compositing. The 3D bits take more work.


    Alpha compositing is an issue I have trouble caring about, but I'll
    comment anyway. The modern trend in window systems seems to be to
    render all windows in to an off-screen texture then use the 3D
    hardware to arrange these on the screen. This gives you acceleration,
    alpha blending, and indeed arbitraty transforms for free. Also,
    windows never receive damage in this case.

    Also, how complete will that windowing system be? Will it be able to
    deal with multiple (and wierd) input devices, multiple hotpluggable
    output devices, hardware acceleration, and so on?


    > > Because the world of graphics has moved on a lot in 25 years. Many of
    > > the extensions are part of the standard for a given release number.
    > > Given that the world of graphics will move on a lot in the next 25
    > > years, your system will also need to be extensible. If you want an
    > > easier time, you can assume that you're targeting a recent X11
    > > implementation, and simply fail if the extensions are not present.
    > > This will have much the same effect as replacing X1 completely.

    >
    > Unfortunately, some X servers don't have DBE. Failure is not always an
    > option.


    Why not assume they all do? That's a much weaker assumption than them
    all having your new windowing system installed. My point is that you
    can get much the same effect by assuming certain features exist as you
    can get by rewriting a window system.

    > >> The Gtk+/Gdk, Qt, Tk, and other teams have
    > >> been duplicating efforts that are better spent on a shared layer.

    >
    > > What has that got to do with extensions? What exactly is the shared
    > > layer?

    >
    > The code paths necessary to implement double-buffering, fast imaging
    > using shared memory (XShm or Xv), are not easy always.


    I've written a program which uses XPutImage versus XShmPutImage, and
    the codepaths are very simple. XV is a different kettle of fish since
    it is not the same as XPutImage, providing colourspace
    transformations, scaling and some really unreliable point-to-point
    features with certain video grabbers.

    As for double buffering, I can't comment on how hard it is to use, but
    ISTR that the ad-hoc implementation with pixmaps is very simple, and
    only requires a very thin wrapper. Besides, the point above still
    stands: what benefit do you get by writing a new windowing system as
    opposed to simply assuming a feature set on the current one?


    [...]

    > >> > This is getting repetitive, but X already has this, and does it far
    > >> > better than VNC and its ilk.

    >
    > >> I wasn't arguing that.

    >
    > > What do you mean by optional?

    >
    > I mean that everything should't go over a socket when you're using the
    > localhost.


    You mean like this?

    http://dri.freedesktop.org/wiki/SharedMemoryTransport

    The saving isn't great, by the looks of it. But anyway, X11 can
    already do this. Which brings me back to the point about assuming a
    feature set.


    > > How can you have X11 compatibility and get around the problems with
    > > compatibility within X11?

    >
    > You can't. The X11 process would run as an application.


    ok.

    > > This is nothing to do with X, and only something to do with xorg.
    > > There is nothing in the protocol which precludes the use of a
    > > multithreaded server. Besides that, is there any real need for a
    > > multithreaded server?

    >
    > I'm not suggesting a multithreaded server. I'm suggesting multiple
    > processes, and with fine grained locking in most unix-like kernels you
    > can get many of the same benefits with processes as with threads,
    > without the problems associated with pthreads.


    This is still nothing to do with X. It's something to do with a
    particular implementation of X, or other window system. Also, what do
    you gain from this?


    > > Now I'm targeting X12 (ie all the features in 7.3 must be available),
    > > so if you don't have X12, then the program won't run. This seems to
    > > solve many of the problems that are solvable.

    >
    > X12 is an X.org project, and you would still have the security issues
    > with X11 if you did that.


    What particular security issues are the problem at the moment? They
    seem well solved by allowing local connections only and tunneling
    connections over SSH at the moment. Or are you thinking of something
    else? You could assume some features and forcible disable others.


    > > My personal favourite idea is to have a VM on the server, the idea
    > > being that the processes in the VM could do things like handling
    > > widgets, and pass infrequent messages back. One could remove very many
    > > round trips that way. Further, if the VM makes xlib calls, it could
    > > work over the network, so if the VM extension is not present, there it
    > > will still work transparently (but not quite as fast). DoS attacks may
    > > be a problem, though.

    >
    > I guess if the OS is a LISP or similar safe system you could have the
    > entire window system implemented as part of the system. I believe this
    > was done before years ago. People tend to want a choice with regard to
    > languages.



    I'm not suggesting that X is the be-all and end-all of window systems.
    However, your proposal seems to be lacking a distinction between the X
    protocol and the particular implementation. If you want to see a
    particularly efficient implementation of X11, buy an old SGI O2. The
    hardware allowed everything to be shared if needed, and you could (for
    instance) get the video grabber to grab directly in to a glTexture,
    whcich would be rendered in an X window, without any copying required.

    Also, it seems like many of the suggestions could be done by simply
    assuming a recent feature set, which would give far more compatibility
    that an entirely new windowing system. It would eliminate many of the
    warts (like alternate code paths) in a single stroke.


    I'm not trying to be overtly critical of your system, but appeared to
    post to solicit comments. There's little point in focussing on the
    aspects we agree on, since I can't add anything useful.

    -Ed

    --
    (You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

    /d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
    r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
    d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage



  12. Re: Designing a Modern Window System

    on Thursday 14 February 2008 10:27
    in the Usenet newsgroup comp.os.linux.x
    George Peter Staplin wrote:

    > Ahoy!
    >
    > I have started writing a document today about my thoughts on window
    > system design. Any constructive comments would be appreciated on this
    > document. Ideally I would like to join forces with some people to
    > create a great window system design. I'm currently at an impass as the
    > OpenGL/3D requirement has hit, and before I do more coding I need more
    > design work completed.

    [snip]

    This is probably not what you expected, but a subtle security
    problem exists with pop-up windows. It would be desirable if
    there were a lock out mechanism such that one pop up check box
    can not cover another.

    Imagine that you have positioned the pointer over the "OK" of
    "send mail now OK" and during the half second between deciding
    to OK it and actually clicking the button a second window pops
    up over it that asks to confirm formatting your hard drive or
    transferring your bank account to me. ;-) It doesn't happen
    very often but it is a design problem. Don't try to solve it
    by trapping the pointer in the first box, that does not work
    in a multitasking environment.


    --
    sig goes here...
    Peter D.

  13. Re: Designing a Modern Window System

    Peter D. wrote:
    > on Thursday 14 February 2008 10:27
    > in the Usenet newsgroup comp.os.linux.x
    > George Peter Staplin wrote:
    >
    >> Ahoy!
    >>
    >> I have started writing a document today about my thoughts on window
    >> system design. Any constructive comments would be appreciated on this
    >> document. Ideally I would like to join forces with some people to
    >> create a great window system design. I'm currently at an impass as the
    >> OpenGL/3D requirement has hit, and before I do more coding I need more
    >> design work completed.

    > [snip]
    >
    > This is probably not what you expected, but a subtle security
    > problem exists with pop-up windows. It would be desirable if
    > there were a lock out mechanism such that one pop up check box
    > can not cover another.
    >
    > Imagine that you have positioned the pointer over the "OK" of
    > "send mail now OK" and during the half second between deciding
    > to OK it and actually clicking the button a second window pops
    > up over it that asks to confirm formatting your hard drive or
    > transferring your bank account to me. ;-) It doesn't happen
    > very often but it is a design problem. Don't try to solve it
    > by trapping the pointer in the first box, that does not work
    > in a multitasking environment.



    Good point. I have experienced that annoying problem with popup
    dialogs. It can be damaging if you don't know what the dialog was, and
    it pops up, asking an important question, just as you were trying to
    click something else. I suppose a specific area for popups on the
    screen might be better, or a warning of some type with a delay before a
    popup could display.


    Thanks,

    George

  14. Re: Designing a Modern Window System

    George Peter Staplin writes:

    > Peter D. wrote:
    >> on Thursday 14 February 2008 10:27
    >> in the Usenet newsgroup comp.os.linux.x
    >> George Peter Staplin wrote:
    >>
    >>> Ahoy!
    >>>
    >>> I have started writing a document today about my thoughts on window
    >>> system design. Any constructive comments would be appreciated on this
    >>> document. Ideally I would like to join forces with some people to
    >>> create a great window system design. I'm currently at an impass as the
    >>> OpenGL/3D requirement has hit, and before I do more coding I need more
    >>> design work completed.

    >> [snip]
    >>
    >> This is probably not what you expected, but a subtle security
    >> problem exists with pop-up windows. It would be desirable if
    >> there were a lock out mechanism such that one pop up check box
    >> can not cover another.
    >>
    >> Imagine that you have positioned the pointer over the "OK" of
    >> "send mail now OK" and during the half second between deciding
    >> to OK it and actually clicking the button a second window pops
    >> up over it that asks to confirm formatting your hard drive or
    >> transferring your bank account to me. ;-) It doesn't happen
    >> very often but it is a design problem. Don't try to solve it
    >> by trapping the pointer in the first box, that does not work
    >> in a multitasking environment.

    >
    > Good point. I have experienced that annoying problem with popup
    > dialogs. It can be damaging if you don't know what the dialog was, and
    > it pops up, asking an important question, just as you were trying to
    > click something else. I suppose a specific area for popups on the
    > screen might be better, or a warning of some type with a delay before a
    > popup could display.


    The simple solution is to have them appear beside the pointer, rather
    than under the pointer or centred.

    --
    Måns Rullgård
    mans@mansr.com

  15. Re: Designing a Modern Window System

    on Sunday 17 February 2008 07:20
    in the Usenet newsgroup comp.windows.x
    Måns Rullgård wrote:

    > George Peter Staplin writes:
    >
    >> Peter D. wrote:
    >>> on Thursday 14 February 2008 10:27
    >>> in the Usenet newsgroup comp.os.linux.x
    >>> George Peter Staplin wrote:
    >>>
    >>>> Ahoy!
    >>>>
    >>>> I have started writing a document today about my thoughts on window
    >>>> system design. Any constructive comments would be appreciated on this
    >>>> document. Ideally I would like to join forces with some people to
    >>>> create a great window system design. I'm currently at an impass as the
    >>>> OpenGL/3D requirement has hit, and before I do more coding I need more
    >>>> design work completed.
    >>> [snip]
    >>>
    >>> This is probably not what you expected, but a subtle security
    >>> problem exists with pop-up windows. It would be desirable if
    >>> there were a lock out mechanism such that one pop up check box
    >>> can not cover another.
    >>>
    >>> Imagine that you have positioned the pointer over the "OK" of
    >>> "send mail now OK" and during the half second between deciding
    >>> to OK it and actually clicking the button a second window pops
    >>> up over it that asks to confirm formatting your hard drive or
    >>> transferring your bank account to me. ;-) It doesn't happen
    >>> very often but it is a design problem. Don't try to solve it
    >>> by trapping the pointer in the first box, that does not work
    >>> in a multitasking environment.

    >>
    >> Good point. I have experienced that annoying problem with popup
    >> dialogs. It can be damaging if you don't know what the dialog was, and
    >> it pops up, asking an important question, just as you were trying to
    >> click something else. I suppose a specific area for popups on the
    >> screen might be better, or a warning of some type with a delay before a
    >> popup could display.

    >
    > The simple solution is to have them appear beside the pointer, rather
    > than under the pointer or centred.


    Do you mean that even a lone pop up should not appear under the
    pointer? Forbidding buttons from appearing under the pointer
    might be the simplest. Then in the pathological case where the
    screen is filled with buttons, they should all be opened except
    the one under the pointer which will open when the pointer is
    moved. Anyone who creates a single button that covers the
    entire screen should be shot.

    Anything at all except for opening "OK" under the pointer
    should be good.

    But I have no intention of writing the code, so it is really
    out of my hands.


    --
    sig goes here...
    Peter D.

  16. Re: Designing a Modern Window System

    "Peter D." writes:

    > on Sunday 17 February 2008 07:20
    > in the Usenet newsgroup comp.windows.x
    > Måns Rullgård wrote:
    >
    >> George Peter Staplin writes:
    >>
    >>> Peter D. wrote:
    >>>> on Thursday 14 February 2008 10:27
    >>>> in the Usenet newsgroup comp.os.linux.x
    >>>> George Peter Staplin wrote:
    >>>>
    >>>>> Ahoy!
    >>>>>
    >>>>> I have started writing a document today about my thoughts on window
    >>>>> system design. Any constructive comments would be appreciated on this
    >>>>> document. Ideally I would like to join forces with some people to
    >>>>> create a great window system design. I'm currently at an impass as the
    >>>>> OpenGL/3D requirement has hit, and before I do more coding I need more
    >>>>> design work completed.
    >>>> [snip]
    >>>>
    >>>> This is probably not what you expected, but a subtle security
    >>>> problem exists with pop-up windows. It would be desirable if
    >>>> there were a lock out mechanism such that one pop up check box
    >>>> can not cover another.
    >>>>
    >>>> Imagine that you have positioned the pointer over the "OK" of
    >>>> "send mail now OK" and during the half second between deciding
    >>>> to OK it and actually clicking the button a second window pops
    >>>> up over it that asks to confirm formatting your hard drive or
    >>>> transferring your bank account to me. ;-) It doesn't happen
    >>>> very often but it is a design problem. Don't try to solve it
    >>>> by trapping the pointer in the first box, that does not work
    >>>> in a multitasking environment.
    >>>
    >>> Good point. I have experienced that annoying problem with popup
    >>> dialogs. It can be damaging if you don't know what the dialog was, and
    >>> it pops up, asking an important question, just as you were trying to
    >>> click something else. I suppose a specific area for popups on the
    >>> screen might be better, or a warning of some type with a delay before a
    >>> popup could display.

    >>
    >> The simple solution is to have them appear beside the pointer, rather
    >> than under the pointer or centred.

    >
    > Do you mean that even a lone pop up should not appear under the
    > pointer?


    Of course. You might be just about to click something else when the
    popup appears.

    > Forbidding buttons from appearing under the pointer might be the
    > simplest.


    Placing the entire window away from the pointer can be easily
    implemented in the window manager. Figuring where there are buttons
    is not so simple. Besides, a window

    > Then in the pathological case where the screen is filled
    > with buttons, they should all be opened except the one under the
    > pointer which will open when the pointer is moved.


    What is already on the screen is irrelevant. Only new windows are at
    risk of accidental click interception.

    > Anyone who creates a single button that covers the entire screen
    > should be shot.


    Certainly.

    > Anything at all except for opening "OK" under the pointer
    > should be good.


    A button with potentially disastrous effects if clicked could have any
    label.

    --
    Måns Rullgård
    mans@mansr.com

  17. Re: Designing a Modern Window System

    on Sunday 17 February 2008 15:20
    in the Usenet newsgroup comp.windows.x
    Måns Rullgård wrote:

    > "Peter D." writes:
    >
    >> on Sunday 17 February 2008 07:20
    >> in the Usenet newsgroup comp.windows.x
    >> Måns Rullgård wrote:
    >>
    >>> George Peter Staplin writes:


    [snip]
    >>>> Good point. I have experienced that annoying problem with popup
    >>>> dialogs. It can be damaging if you don't know what the dialog was, and
    >>>> it pops up, asking an important question, just as you were trying to
    >>>> click something else. I suppose a specific area for popups on the
    >>>> screen might be better, or a warning of some type with a delay before a
    >>>> popup could display.
    >>>
    >>> The simple solution is to have them appear beside the pointer, rather
    >>> than under the pointer or centred.

    >>
    >> Do you mean that even a lone pop up should not appear under the
    >> pointer?

    >
    > Of course. You might be just about to click something else when the
    > popup appears.
    >
    >> Forbidding buttons from appearing under the pointer might be the
    >> simplest.

    >
    > Placing the entire window away from the pointer can be easily
    > implemented in the window manager. Figuring where there are buttons
    > is not so simple. Besides, a window


    I was thinking of going through the menus and starting an
    application like the Gimp with multiple windows and *lots*
    of buttons. Preventing any of the windows from opening
    under the pointer would make positioning them difficult.

    Would you prevent an application window from opening full screen?

    >> Then in the pathological case where the screen is filled
    >> with buttons, they should all be opened except the one under the
    >> pointer which will open when the pointer is moved.

    >
    > What is already on the screen is irrelevant. Only new windows are at
    > risk of accidental click interception.
    >
    >> Anyone who creates a single button that covers the entire screen
    >> should be shot.

    >
    > Certainly.
    >
    >> Anything at all except for opening "OK" under the pointer
    >> should be good.

    >
    > A button with potentially disastrous effects if clicked could have any
    > label.



    --
    sig goes here...
    Peter D.

  18. Re: Designing a Modern Window System

    "Peter D." writes:

    > on Sunday 17 February 2008 15:20
    > in the Usenet newsgroup comp.windows.x
    > Måns Rullgård wrote:
    >
    >> "Peter D." writes:
    >>
    >>> on Sunday 17 February 2008 07:20
    >>> in the Usenet newsgroup comp.windows.x
    >>> Måns Rullgård wrote:
    >>>
    >>>> George Peter Staplin writes:

    >
    > [snip]
    >>>>> Good point. I have experienced that annoying problem with popup
    >>>>> dialogs. It can be damaging if you don't know what the dialog was, and
    >>>>> it pops up, asking an important question, just as you were trying to
    >>>>> click something else. I suppose a specific area for popups on the
    >>>>> screen might be better, or a warning of some type with a delay before a
    >>>>> popup could display.
    >>>>
    >>>> The simple solution is to have them appear beside the pointer, rather
    >>>> than under the pointer or centred.
    >>>
    >>> Do you mean that even a lone pop up should not appear under the
    >>> pointer?

    >>
    >> Of course. You might be just about to click something else when the
    >> popup appears.
    >>
    >>> Forbidding buttons from appearing under the pointer might be the
    >>> simplest.

    >>
    >> Placing the entire window away from the pointer can be easily
    >> implemented in the window manager. Figuring where there are buttons
    >> is not so simple. Besides, a window

    >
    > I was thinking of going through the menus and starting an
    > application like the Gimp with multiple windows and *lots*
    > of buttons. Preventing any of the windows from opening
    > under the pointer would make positioning them difficult.


    You have a point. Applying the rule only to popups (they usually set
    some hint allowing them to be detected) might make sense. These are,
    after all, the most likely to receive accidental clicks, since they
    often appear with no prior user action. When starting a new
    application, the user is already aware that new windows will be
    appearing.

    > Would you prevent an application window from opening full screen?


    Certainly. In fact, I have configured my window manager to override
    the requested window size for certain applications that otherwise
    insist on opening full-screen windows. Fortunately, most of the apps
    I run are well-behaved and use sensibly sized windows.

    --
    Måns Rullgård
    mans@mansr.com

  19. Re: Designing a Modern Window System

    "Peter D." writes:

    > on Thursday 14 February 2008 10:27
    > in the Usenet newsgroup comp.os.linux.x
    > George Peter Staplin wrote:
    >
    >> Ahoy!
    >>
    >> I have started writing a document today about my thoughts on window
    >> system design. Any constructive comments would be appreciated on this
    >> document. Ideally I would like to join forces with some people to
    >> create a great window system design. I'm currently at an impass as the
    >> OpenGL/3D requirement has hit, and before I do more coding I need more
    >> design work completed.

    > [snip]
    >
    > This is probably not what you expected, but a subtle security
    > problem exists with pop-up windows. It would be desirable if
    > there were a lock out mechanism such that one pop up check box
    > can not cover another.
    >
    > Imagine that you have positioned the pointer over the "OK" of
    > "send mail now OK" and during the half second between deciding
    > to OK it and actually clicking the button a second window pops
    > up over it that asks to confirm formatting your hard drive or
    > transferring your bank account to me. ;-) It doesn't happen
    > very often but it is a design problem. Don't try to solve it
    > by trapping the pointer in the first box, that does not work
    > in a multitasking environment.


    I think I disagree.

    Dialog buttons are activated on a button press, button release
    cycle.

    I don't think my reflexes are so bad that I can't move
    the pointer away from the button if something appeared
    before the press.

    Besides that, the scenario above describes a hostile
    application. Browser based dialogs don't have the power
    to format my hard drive or transfer my bank account info.
    If I'm running a hostile application, I don't think it needs
    me to click on anything.

  20. Re: Designing a Modern Window System

    Dan Espen writes:

    > "Peter D." writes:
    >
    >> on Thursday 14 February 2008 10:27
    >> in the Usenet newsgroup comp.os.linux.x
    >> George Peter Staplin wrote:
    >>
    >>> Ahoy!
    >>>
    >>> I have started writing a document today about my thoughts on window
    >>> system design. Any constructive comments would be appreciated on this
    >>> document. Ideally I would like to join forces with some people to
    >>> create a great window system design. I'm currently at an impass as the
    >>> OpenGL/3D requirement has hit, and before I do more coding I need more
    >>> design work completed.

    >> [snip]
    >>
    >> This is probably not what you expected, but a subtle security
    >> problem exists with pop-up windows. It would be desirable if
    >> there were a lock out mechanism such that one pop up check box
    >> can not cover another.
    >>
    >> Imagine that you have positioned the pointer over the "OK" of
    >> "send mail now OK" and during the half second between deciding
    >> to OK it and actually clicking the button a second window pops
    >> up over it that asks to confirm formatting your hard drive or
    >> transferring your bank account to me. ;-) It doesn't happen
    >> very often but it is a design problem. Don't try to solve it
    >> by trapping the pointer in the first box, that does not work
    >> in a multitasking environment.

    >
    > I think I disagree.
    >
    > Dialog buttons are activated on a button press, button release
    > cycle.
    >
    > I don't think my reflexes are so bad that I can't move
    > the pointer away from the button if something appeared
    > before the press.


    I consider my reflexes pretty good too, and yet I have on occasion
    clicked a button in a popup dialogue by accident.

    > Besides that, the scenario above describes a hostile
    > application. Browser based dialogs don't have the power
    > to format my hard drive or transfer my bank account info.
    > If I'm running a hostile application, I don't think it needs
    > me to click on anything.


    It could be a browser dialogue warning about a bad SSL certificate,
    which would normally have alerted you to the possibility that a site
    you're visiting might not be what it seems.

    --
    Måns Rullgård
    mans@mansr.com

+ Reply to Thread