RFC: Disabling blinking cursor by default

Dimi Paun dimi at lattica.com
Fri Feb 6 14:57:33 UTC 2009


On Fri, 2009-02-06 at 10:43 +0100, Michael Schwendt wrote:
> > On a busy X session (I typically have 30-40+ windows open)
> > not having a blinking cursor is crazy.
> 
> The problem with your arguments is that you call something "crazy"
> without explaining *what* would be crazy about it. 

But do you think it matters? 

Look: if a proposal is forwarded to change dubious defaults you
are told to come back with a rigorous scientific  usability study
showing X and Y. Knowing full well that's pretty much impossible. 
Even claiming that 90%+ of computer users use Windows is qualified as
unsupported numbers and hand-waving.

However, if someone from Red Hat wakes up one morning and decides
to change a default that will affect _everybody_ using a computer,
they do it without a moment's notice. And we are supposed to swallow
it as such because someone came up with a *totally* unsupported
number of trees saved(1). 

> Only one out of your 30-40+ windows would be active/selected and
> highlighted with different window border colours.

The blinking caret will not help you much to identify the window,
for that you have other clues. But in a typical editor window
in X (like Eclipse, Write, etc) where there is a lot of information
on the screen and the caret can be anywhere (it's not constrained
like in a terminal) it can be quite helpful for some people.

We are making these kind of changes driven by political motivation (2)
rather than technical merit (3). This is bad. 

----

1. In fact, it's so unsupported that even when asked politely to
   explain how in good $DEITY name they come up with it they didn't
   bother. 
2. Yes, it's political, based on the incorrect assumption that
   we're gonna save trees.
3. There have been a weak attempt to dress it in a technical 
   argument, but it can't stand to any serious review/discussion.
   However, this doesn't seem to interest anybody.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




More information about the devel mailing list