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



I wouldn't say it is trivial (there are actually quite a number of things
happening even when you insert just one letter).
To be very honest I can't remember that I ever felt I erased something by
accident whilst I was typing in an entry field.
I find the 'standard' way of replacing the selection with the next keystroke
quite ok (and that is what gtk does, at least in all versions I am using).
Entry fields are meant for short user input, and they are meant small and
efficent memorywise as they constitute one of the most often used widgets.
(i.e. entering numbers, single words)
If you are in a situation where you believe undo on an entry field is vital
you should possibly implement it yourself (or maybe use a text-widget with
those capabilities). In short : Every widget set I have seen implements
replacment with the next keystroke and that should be the default behaviour.
If you want this to be extended you should subclass from the entry field and
create a new (Gnome?) widget.

 Jan

Ted Lemon wrote:

> > Undo is for an application, not for a single widget.
>
> Right.   In emacs, when you hit the undo key, it switches to whatever
> buffer you modified last and undoes that change.   Undo doesn't work
> in the minibuffer, of course, because that would be inefficient.
>
> > 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.
>
> You're right.  It makes no sense to have the Gtk interface duplicate
> behaviour that is present in Windows, on the Mac, with Motif-based
> widgets, OpenLook based widgets, and so on.  In order to avoid the
> undeniably huge impact on memory footprint and speed, it's definitely
> worth behaving unexpectedly and being incompatible with the rest of
> the world.
>
> If you detect a note of sarcasm, it's not accidental, although I will
> admit it's a bit gratuitous.
>
> Implementing at least "undo recent typing" is trivial.  It should not
> add appreciably to the speed or memory footprint of the widget.
> Alternatively, we could make it configurable, although my vote would
> be to default to the standard behaviour.  What we _shouldn't_ do is to
> _force_ the user to put up with entirely new and unexpected behaviour
> in order to switch to Gtk.
>
>                                _MelloN_
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]