From fnaumann@mail.cs.uni-magdeburg.de Thu Nov 20 23:53:01 2003 From: Henk Robbers To: mint@fishpool.com Subject: Re: [MiNT] FYI: XaAES changes Date: Thu, 20 Nov 2003 23:35:47 +0100 User-Agent: KMail/1.5.1 References: <1069283624.1640.1.camel@joy.home> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200311202335.47460.h.robbers@chello.nl> Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: h.robbers@chello.nl Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: 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