For example you choice to save some file to some place, in which, you already have old version of that file (with the same name of course). So, when you are in asl req, you by RMB choice "rename" (to rename old file to something like old_file.c_save) , and press enter to make changes and , at this point in the FIle field (where you choice name for file to save), you have also name of renamed file. But imho, rename should be just rename, and save file chould be no changed ?
Because of it, when i rename old file, i need to swith to File area again, and delete new letter which come from rename, to make default name of file. It is bug or just supposed to be like this in asl ?
Hmmm... It might just be the way it works - the logic behind it being whatever entry is highlighted is entered into the file field below. So, when you rename an entry and it stays highlighted after the rename, it's consistent. I can see the situations where this is a bit of a nuisance though...
It looks wrong, doesn't it? I would expect that when you rename one of the existing files, the name in the requester should not change (as kas1e said).
I think its react like this because (as daedalus say), every highlighted entry are change active file-name, and it is ok, just with case with "raname", there should be exception, i.e. if user just rename file, then do not change current file name after "entrer" is pressed. I think (i hope) it should be matter of IF/ELSE in the code of ASL..
I must admit that I'm not sure whether this is an bug or a feature. Does anyone did a cross check with (at least) OS3.9 ASL requester? My OS3.9 systems aren't reachable atm - I suppose this is a standard behaviour of ASL since the introduction of "rename" to it's inbuild features (since OS3.5 or 3.9).
I couldn't agree more! Its the one thing I was dreading on seeing when returning to Amiga. When I left Amiga MUI was doing great stuff with file requesters - you know icons for drawers, icons for files... I know some people consider it just eye-candy - but hell come on this is 2011!
An ASL requester should resemble something like in MacOS, Windows Dialog boxes, whatever MorphOS has (idk what is btw ;p) or dare I say it ... Jack (of course instead written in C/C++ or E) - you know what I mean here - ASL 2011 should explicitly use Mason Icons throughout.
Not everyone likes Mason's icons. To my tired old eyes they are much too faint and hard to interpret.
+ 1 (with all due respect to Mason for his enormous effort)
@djrikki
My gripe about the ASL filerequester is the GUI layout rather than the look.
* The OK, Volumes, Parent and Cancel buttons are in one group yet they have different functions and scope of operation (OK and Cancel control the entire requester, while Volumes and Parent only control the file list).
* OK and Cancel are related mutually exclusive choices yet they are separated from each other in the layout.
* Volumes and Parent are function-wise associated with the file list yet they are placed away from it.
* Create New Drawer, a rather common function, is buried in the menu.
It would certainly be quite easy to "patch" the File Requester of the existing asl.library . The big job would be creating a pretty GUI which did everything ASL did (although I guess you could fall-back to the old requester if an unsupported feature was requested by a program).
My gripe about the ASL filerequester is the GUI layout rather than the look.
* The OK, Volumes, Parent and Cancel buttons are in one group yet they have different functions and scope of operation (OK and Cancel control the entire requester, while Volumes and Parent only control the file list).
This is true but on the otherhand it makes efficient usage of screen space.
Quote:
* OK and Cancel are related mutually exclusive choices yet they are separated from each other in the layout.
This is the correct thing to do, it makes it much less easy to click the wrong option by accident.
Quote:
* Create New Drawer, a rather common function, is buried in the menu.
But the save requester will create drawers for you if you specify a non existant drawer in the path gadget. So no button neccessary.
* The OK, Volumes, Parent and Cancel buttons are in one group yet they have different functions and scope of operation (OK and Cancel control the entire requester, while Volumes and Parent only control the file list).
This is true but on the otherhand it makes efficient usage of screen space.
While space usage certainly is a criterion in GUI design, this particular context (the ASL filerequester) is not the case to use it as an argument and defend a wrongly designed piece of GUI. If Volumes and Parent were put in a separate row of buttons, and adjacent to the file list (which they control), the requester would only grow vertically by this single row of buttons. No big deal (we do not use 640x256 resolutions any more), and you get a more logically designed requester. [/quote]
Quote:
Quote:
* OK and Cancel are related mutually exclusive choices yet they are separated from each other in the layout.
This is the correct thing to do, it makes it much less easy to click the wrong option by accident.
Debatable at least If I wanted to increase safety, I'd separate the two gadgets by an empty space rather than by two unrelated gadgets. [/quote]
Quote:
Quote:
* Create New Drawer, a rather common function, is buried in the menu.
But the save requester will create drawers for you if you specify a non existant drawer in the path gadget. So no button neccessary.
Yes, just tell that to the newcomer Seriously: assumed user knowledge of a program's internal workings is one of the most common problems in software design. AmigaOS is full of that, unfortunately.
Personally, I think they should have made the ASL requester shorter and wider so that, on a classic machine, the file requester could be put on a custom screen to avoid palette collisions, since each screen can have its own Copper list.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
