Re: [gtk-list] Re: Typing over selection...

[Kenneth Albanowski <kjahds kjahds com>]

On Sun, 13 Sep 1998, Some Guy wrote:

> On Sun, 13 Sep 1998, Ted Lemon wrote:
> 
> > > Maybe, but there is room for improvement.  It is screech-out-load annoying
> > > when a single keystroke wipes out a large section of text that you just
> > > finished typing and were about to commit but saw one last error.
> > 
> > You're right that it's annoying when this happens, but that's what
> > Undo is for.  Come on, these are the 90's.  Emacs has had undo since
> > the days if ITS TECO.  This is an easy problem to solve.  Sure,
> > existing Windoze and Mac applications may not let you undo in an
> > entry-widget, but that doesn't mean Gtk can't support it.
> 
> Undo is for an application, not for a single widget.  If undo was
> crammed into every editable widget, Gtk+ would become much larger
> than it need be.  I think it would be a good deal easier to leave it
> so that you have to hit that extra 'DEL' and then start typing than
> to implement an undo feature for all entry widgets.  Just because
> it's the 90s doesn't mean we should start wasting memory by putting
> unneeded features into applications. Emacs has undo because it's a
> text editor.  Small widgets like Entries don't need such an elaborate
> feature.

All Windows edit fields (and maybe Mac too, I'm not sure) have one-level
undo built in, and one-level undo does _not_ cost much of anything,
compared to the benefit. Humans make mistakes. "Undo" is a surprisingly
good tool (compared to many other attempts) to help humans correct their
mistakes before they inflict them on unsuspecting software. Undo is a good
thing to have, QED. 

Or, put another way: maybe undo is only "for an application, not for a
single widget", but I think any human is going to consider that widget
part of the application.

Moreover, how in heavens name does "cramming undo into every editable
widget" expand Gtk+ significantly? There are, what, two editable widgets?
And _both_ of those are derived from GtkEditable, which is where the
functionality should go. And, if someone was feeling _really_ fancy, they
could implement a generic undo capability that, by default, un-did normal
editing actions, but also allowed applications to define more
sophisticated custom undo features, including grouping. (Hint: "undo" is
just a sequential or circular list of actions recorded during editing,
each action being something like "insert 'abc' at 3", or "delete 'def' at
9". Undo consists of playing them back, in reverse. Redo consists of
playing them back again forwards. If we want to limit memory usage, just
keep a single level.)

Sheesh, this is the 90s, the 300Mhz Pentium II is common-place, 32Meg of
memory is standard and we can jolly well splurge on elaborate features, in
the right places. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)