Re: [MiNT] FYI: XaAES changes

[Henk Robbers <h.robbers@chello.nl>]

On Thursday 20 November 2003 09:12, Standa Opichal wrote:
> Hi!
>
> On Thu, 20 Nov 2003, Petr Stehlik wrote:
> > V Út, 18. 11. 2003 v 23:32, Standa Opichal píše:
> > > I've just commited some cleanups to the XaAES code + the fileselector
> > > usability improvements:
> > >
> > > The file editable field is cleared on each folder/drive change.
> >
> > So if a program is gonna do Save As... and offers a filename but you
> > want to save it to a different folder/drive you loose the filename
> > itself (it's cleared)?
>
> Good point. 

Extremely good point.
Moreover, the action could wipe out a name I just typed.
Which would make me extremely angry of course.
Only because I wanted have look on the other drive to see if my name
makes sense.
I might even use the dir change to pick up a name from a backup directory.
(which I actually quite often do)

>I would play with this more to bring it really usable in most
> common usecases.
>

Hmmm. The current behaviour of the FS is based on 16 years of using
fileselectors and 30 years of using input fields in general. ;-)

The leading principle of the FS is: to make visible any name that already
exists in the system. This to minimize the chance of typing errors, which
might effectively make the file got lost.
Think of putting a book back in the wrong place in a large library.
The edit field should not be changed by the AES in any way unless
 initiated by the user, which means typing, hitting ESC or selecting
from the list.

Changing directory does not invalidate the contents of the field.
Especially not in a hierarchy.

If you keep the name when changing dir and the name already exists in the
new directory, the name will be highlighted and made visible.
An aspect of usefullness that would got lost.

If you really want to work on the FS, I have the following suggestion:
Make it non modal like form_alert and form_error. (or is it modal, I just
cant remember which means what)

Put the single static fs structure in the application structure together with
a copy of the clean fs tree. Make sure the code is pure.
So apps can have fileselectors concurrently on the screen.
One of the things I wanted to do, but didnt allow myself the time for.

Anecdote:
In the early 80's I wrote software for a OLIVETTI TC800 small business
computer. There was a instruction for typing data into a field on the screen.
There I got angry for the first time on the subject.
The instruction cleared the field everytime it was invoked, making it
impossible to supply a default or a previously typed value.
I was forced to bypass the instruction which would otherwise have been very
usefull and write a emulation.
I have not changed or become more tolerant. Such kind of behaviour
keeps making me angry.

There is however a nice way to avoid this kind of discussions.
If you want to have a GUI behave different, just do it, your in the position.
But only if you make the change a configurable option.
The default of wich of course must be the old behaviour to which
everybody has become accustomed. ;-)

Many of the existing options came into life this way.

-- 
Groeten; Regards.
Henk Robbers.    mailto:h.robbers@chello.nl
                   http://members.ams.chello.nl/h.robbers/Home.html
Interactive disassembler:     TT-Digger;  http://digger.atari.org
A Home Cooked teXt editor:    AHCX
The free desktop:             TERADESK