[Tfug] Speaking of desktops (little 'd')...

[Bexley Hall]

Hi, Rich,

--- On Tue, 11/11/08, Rich <r-lists at studiosprocket.com> wrote:

> Like pretty much everyone else: stealing focus is #1. The
> most frustrating is when you're typing a password in to
> an obscured field. As this is something the GUI provides, it
> shouldn't be too hard to prevent something from stealing
> focus -- even if it pops up a window in front of it.
> It's unexpected behavior, so it's a bug.

<frown>  I don't consider it a "bug" -- I consider it a misused 
feature.  (I think of bugs as things that don't do what the
programmer intended them to do -- clearly, whoever is using that
popup -- wrongly? -- *wants* to steal your attention  :< )

> Windows that say "I'm focussed!" when
> they're not -- this only seems to happen on Windows,
> where programmers find it too hard to use the provided GUI,

Ah, good point!  But, it would be hard to implement something
where the application could NOT do this.  Unless you force the
WM to decorate *all* windows and always use those decorations
to convey this state.  So, even if an application drew its
own *bogus* titlebar, the *real* titlebar around it would
still accurately convey this information...

> so they draw their own. But then their event listeners are
> always shouldered aside by "more important" tasks.
> Programmers need to learn that there is nothing more
> important than providing feedback to the user.
> 
> But that leads to other problems: overenthusiastic status
> reporting. Ever tried using Thunderbird to a remote IMAP
> server over an unreliable connection (i.e. Cox)? It'll
> have trouble saving sent messages to "Sent", so it
> complains with focus stealing popups. The Thunderbird guys

Hmmm... I've never encountered this and find it interesting
that they would make such a "mistake".  :<

> need to look at Apple Mail, which has an "Activity
> Viewer" (note: this isn't where you can do
> fingerpainting and pin the donkey on the tail).
> 
> Windows's "You need to reboot for the changes to
> take effect" style popups after receiving automated
> updates. They only have two responses, "Reboot"
> and "Remind me later". Where's "Piss off"?

"Have you stopped beating your spouse?"

> Mac has a similar thing, but you can force quit the
> Software Update GUI, or you can update from the command
> line.
> 
> Windows's slow shutdowns; whether it's its
> insistence on patience (hey, gotta wait for this
> unresponsive program to... err... respond -- but that's
> why I'm shutting down), or its desire to perform
> installations. Neither of these should prevent me from
> undocking my laptop and taking it with me, but they
> frequently do. It makes me drive home faster -- so it *is*
> actually a safety hazard.

But that's a consequence of the OS's bloat.  For the same reason
it takes so long to *boot*.  I don't think (?) that's a part
of the "user interface" per se...
 
> One non-bug thing that deserves my withering gaze is GUI
> buttons grouped together by style, rather than function.
> Intuition (Amiga) had the close gadget in the top left,
> window raise/lower and switch size in the top right, and
> drag-resize in the lower right. The old Mac desktop had it

You mean the WM decorations (i.e., your examples are all
outside the scope of the application)?

> just about right too. Every desktop since has determined
> that I should have the close gadget right next to the
> minimize gadget. Yes, on FOSS window managers I can often
> customize this placement, and I frequently do. There's
> the key *frequently*. Every new account I get I have to jump
> through hoops to have a GUI that works well for me.

<ponder>  This one is a tough call, IMO.  I don't like having
controls that can do "bad/big things" next to controls that
are more forgiving.  E.g., unless you want to annoy the
user with "Do you really want to close the application?"
dialogs, then if the user tries to minimize the window
(something that tends to get done often) and *misses* (since
the decorations are often very small), then he ends up quitting
the application entirely!
 
> As for Don's other points:
> 
> > - focus follows cursor (in some cases, I like this; at
> >   other times, it is a nuisance.  Maybe the application
> >   should convey this to the window manager as a 'preference'?)
> > - auto raise when in focus (I consider this A Bad Idea in
> >   almost all circumstances)
> 
> ffm is a traditional way of interacting with windows. I
> prefer it, so I check it wherever possible. Even on Mac,
> which uses click-to-focus-and-raise (ctfar?), I have
> focus-follows-mouse set in my X11 environment. It just works
> better. At least it works better than the Mac and Windows
> behavior.

I've found focus follows (mouse) cursor can be annoying as it
requires you to leave the mouse *in* your current window.  Under
X, I run <mumble> which hides the mouse cursor after some period
of inactivity.  This helps, but means I have to wait for the damn
thing to be unmapped before I can be sure of what I am typing.
If you "click to focus", then I simply slap the mouse out of the
way (which I can do faster than waiting for the cursor to unmap)
and I'm good to go.

In applications where I have to do a lot of typing (i.e., where the
mouse cursor is often a distraction), I'd like this behaviour.  In
others where I'm just pointing at things on the screen (e.g., in
the debugger or in some CAD application), then I want the mouse
to remain (visible) in the current window.

I guess this should be a preference that the application exports
to the WM for enforcement is what I would find best.  This allows
the user to pick a default behaviour for *all* windows -- and
override it for *specific* application classes.

> Yes, the middle ground would be a handy option:
> click-to-focus-but-never-raise-until-told-to-do-so
> (ctfbnruttds?)

YCHCYAQFTJB
 
> > But, what about the other "channels" used to convey information
> > to the user.  E.g., should any app be able to "make noise"
> > whenever it wants?  Or, should the noises that it is allowed to
> > make be tied to where the user's focus resides?  Etc.
> 
> Second option. I'm the user, I'll decide what info
> I want. I want my noise squirreled away in a small log
> window or (get this) not at all.

Huh?  Perhaps I was unclear.  By "noise" I really meant *noise*
(i.e., auditory phenomena).  Hard to imagine squirreling them away
in a small window!  (open window, lots of sound comes rushing out,
close window quickly!!  :> )
 
> On Mac (I mention it only because it's my non-work
> machine) there is a plethora of text editors that use their
> own screen to reduce distractions. Every few months, someone

Huh?  "their own screen"?

> comes out with a groundbreaking study that shows how
> distractions actually lower productivity. Who'd've guessed?