Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!rpi!ispd-newsserver!ism.isc.com!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: XWarpPointer revisited.....
Message-ID: <994@attc.UUCP>
Date: 22 Jan 91 18:00:10 GMT
References: <9101212345.AA03235@devnull.Eng.Sun.COM>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 70

In article <9101212345.AA03235@devnull.Eng.Sun.COM> dshr@eng.sun.COM (David Rosenthal) writes:
>Martin Brunecky writes:
>
>>     The "popup non-obscuring" or "popup at screen-center" etc, however,
>>     require pointer motion (either by the user or by the application).
>>     My suggestion for this scenario was that there are situations where
>>     warping the pointer by the application *may* be appropriate, and
>>     may not disturb the direct manipulation paradigm any more than the
>>     popup itself does.
>> 
>The important words here are "warping the pointer by the application" not
>just "warping the pointer".  Tom LaStrange points out:
>> 
>> Actually, OPEN LOOK applications and window managers can provide this exact 
>> behavior.  This is accomplished through the private OL Client/WM protocol
>> and it is actually the window manager that does the warpping.
>> 
>This provides the behaviour you want *without* the problems caused by
>the application warping the pointer.  The ICCCM does not restrict 
>warping the pointer by the window manager.
>
>Note that the behaviour being discussed is part of the overall look and feel
>that should be consistent between applications.  Inconsistent behaviour in
>this area would be worse than consistent behaviour that you didn't like.
>This isn't an area that the application programmer should be writing
>at all - use what your toolkit gives you and if you don't like it beat
>up on your toolkit supplier.  So,  the rules are:
>
    in brief, don't  EVER  do it ..


    The problem is that ICCCM conventions for any MODALS or the kind
    of behavior above DO NOT EXIST. Except for ONE WM (which we can't
    rely on any more than any other) there are NO Window Managers that would
    provide the functionality above, though there are (few) window 
    managers providing private, incompatible, non-ICCCM (und thus TOTALLY
    useless) support for various application (and other) modals.

    I am sorry to say that, but the Window Manager (protocol) evolution
    is lagging a century behind application needs, thus forcing many of
    us to take action on the application side.

    As we (and many other people) migrate EXISTING applications to
    X World, we have to provide EFFICIENT solutions TODAY.
    Bad enough that switching to X we suffer a significant performance hit
    (compared to previous kernel graphics systems such as GPR, Pixrect, UIS).
    
    Now you suggest I should DRASTICALLY REDUCE USER'S (customers)
    PRODUCTIVITY for the sake of consistency with non-existent
    other applications and non-existent ICCCM rules.
    
    I AM SORRY. I CAN'T DO IT.

    I can't afford to dissatisfy my users (more that I already am
    by foisting the X performance upon them) by obiding by well-intended,
    but incomplete and even inappropriate requirements for consistency.

    Of course, I will obide the "consistency" requirements as soon
    as there will be rules and *implementations* which provide
    efficient solutions *available from multiple vendors*.
    Until such *implementations* do exist, I *MUST* and I *WILL* ignore
    rules which RESTRICT without GIVING alternate solution.

    {flame of}

-- 
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky                           {...}sunpeaks!auto-trol!marbru
(303) 252-2499                        (sometimes also:  marbru@auto-trol.COM )
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404