A topic that has sprung up recently is how bad the ASL file requesters suck
Some suggestions reported so far are:
1. Font colour and visibility is lame; need to add a shadow to text.
2. They need to be more customisable for the developer, ability to add gadgets such as:
a) Save As file type
b) Filter by file type drop-down box as opposed to expecting user to type #?.ext. So in a music application you could filter by .MOD file, MP3, MP4, AIFF etc. In a graphics application you could filter by JPG, PNG, TIFF, BMP etc accessible from a drop-down box. If the pro-user wants to filter files traditionally he can enter #?.ext in the filename field.
Imho first suggestion are not about ASL. It's just about how workbechn display the Fonts. What you dislike - it's imho about not avail options in font rendering on OS itself. ASL (imho) have no any code about Fonts in it. And (imho again), that is really last from all suggestions which can make sense.
Some ppls like when font strong, without shadow and all the crap. Other ones are like shadow and such. But it's not about ASL, it's about workbechn itself, and font preferences.
About "save":
Quote:
to expecting user to type #?.ext
That you can do already (i.e. type .ext). That will also make no sense, i am more about making or dropdown menu / gadget button for choise file format, or add that .ext hardcore, which user _can't_ remove. But imho, the best choise - just dropdown menu, at bottom of ASL requester, where use can choice file format. Imho the best and easy way.
Edited by kas1e on 2010/6/26 19:18:16 Edited by kas1e on 2010/6/26 21:30:59
Ok, there is how i think it should looks like when user press "save as" in programm which mean saving in more than 1 file format:
From coder side, to make that dropdown formats menu works, code can passed to ASL like that (imho pretty easy):
string string_of_formats =
{
aaaaa, // text for first item
bbbbb, // text for second item
ccccccc, // text for third item
0 // terminate the string list
}
So, when user will use ASLM_FileReqSaveList, then, ASl req will for first create that dropdown menu, and for second will return value with the number of the string, from strings buffer.
Then coder can use it as he want.
+ I also think that will be cool to have ability, to add Mark Button, for "add file extension automatically to a file". It can be added or only when ASLM_FileReqSaveList are used, or just in any case for Save abitlity. Just because it always was a bit not understanable for new users (and for old ones too) , how programm will save file rigjht now, with extension , or without.
Your suggestion is probably quite workable, but without knowing the inner secrets of ASL, I cannot begin to make any assumption as to how easy this would be to implement, or indeed whether it would break any sort of compatibility.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Whilst we're on the subject of ASL, please can I repeat my request for the ability to remove the "Size" part of the font requester?
getfont.gadget would need the same modification.
@djrikki
I'm relatively happy with ASL's filtering, but then I never filter by extension. Development-wise it is better to create a filter function which picks up the correct files by examining them - doesn't give the user any control, but if the app can't open the file anyway this is irrelevant File extensions are an awful way of identifying a file type, just look at the mess on Windows where it is the only option. Of course it is necessary sometimes with particular formats which don't have distinctive headers.
I do agree with the addition of a "file format" option on the ASL save requesters, it has been very much needed for a long time.
Instead of showing the extension (like .jpg) in the Format dropdown list, I think it should be better to put a list of the formats available, as in:
Joint Photographic Experts Group (JPEG/JFIF) Exchangeable image file format (Exif) Tagged Image File Format (TIFF) Portable Network Graphics (PNG) Graphics Interchange Format (GIF) Windows bitmap (BMP) Computer Graphics Metafile (CGM) Scalable Vector Graphics (SVG)
That way, the user can use the extension he/she wants (jpg or jpeg, tiff or tif, if any extension at all). Same for wordprocessor's documents, spreadsheets, texts, etc.
it comes so handy in a directory with lot of files:
#?april#?
No, no the user customizable filter should stay, please!
And btw, please don't remove the rename function in ASL. Even if other OSes do not have such an option, I have come used to it when I mistyped the name of a new created drawer.
thanks!
@all
in the prefs drawer there is an ASL requester settings tool.
and as far as know, the font color can be changed in GUI preferences.. (or create a new color in Palette first)
Of course. As i point before, coder should have ability to put any text to it, not only file extensions.
I'm confused, what kind of text? isn't there already the possibility to put wildcards in there? i.e if I open a file requester from multiview, there is already and entry in the "Pattern" field.Quote:
~(#?.info)
and from another thread: just because people used to other OS do not expect a menu in a file requester, IMHO it should not indicate the function to be obsolete per se.
Apple has the economic possibility to hire geniuses to explain unusual procedures to newcomers, because nowadays people expect to be fed instead of using their brains and curiosity.
Sometimes we tend to nitpick to much in this community. Look at the mobile phone market, different vendors implement different GUIs in their phones. Yet people learn how to use them.
In regard to rename function. Windows has had it for ages, select a file press F2, but yeah a button is more useful. Bearing in mind again that my knowledge of Amiga is somewhat distant: useful features in a requester would be New Drawer, Rename and Delete as well of course Load/Save and perhaps some right-click functionality giving menu under pointer with common options on other OSes like Delete (aka move to Trash), Properties (aka Get Into) and Open With can often be a useful feature.
In regard to show file types when 'Opening a file', yes its been in Windows since year dot, but really its for information only so you can see what an application is capable of opening. Its of course better if the requester just shows every file that can be opened by the application and allow the user to filter the list further or simply Show All.
If the OS team make it a priority to fix ASLs then the OS as a whole would look more appealing; or at least thats my opinion.
But we have to of course bear in mind there is so much more than needs doing as well like the graphics system aka ditching Warp3D and replacing it with MESA.
A case of sit back and wait and see what Hyperion brings out next, from here it can only get better.
I'm confused, what kind of text? isn't there already the possibility to put wildcards in there? i.e if I open a file requester from multiview, there is already and entry in the "Pattern" field.Quote:
We about Save file requester (only about Save, Load are should be / can be the same as it now).
And text about i mean, it text for dropdown gadget buttons of Format field (check screenshot). Coder should have ability to put any text to it.
Anyway, Rigo already understand what i mean, and that was main point of all of this :)
Users will loose nothing, and none of programs will works in different. Just that ones which want to _save_ more than in one file format, will have new functional field in ASL requester, which will allow to choice in which file-format need to save a file (that will solve all problems for video-convert-editing toolz, music editor, words-processors, image editors and alt). Because as it for now, coders need to create 2-step solutions, like bring window with file-format selection, and then ASL requester. That long, and unproductive.
Quote:
Look at the mobile phone market, different vendors implement different GUIs in their phones. Yet people learn how to use them.
Let's they do what they want, and vendors and users of phones. We about ASL improvements here, to make it more productive and friendly, and not about making everything boring and like somethere else (imho).
As I pointed out in the other thread, the ASL requesters should aim for more in-your-face functionality. That is, the requester GUI should display all available functions, in the form of gadgets. Not hide them somewhere (like in amenu). That's how requesters are meant to work.
I said it before and I'll say it again: requesters are NOT program windows, so they should not have a menu strip attached to them. The menu represents a second level of control while requesters are only supposed to have one.
There is a strong argument in favour of putting the Volume/Assign list next to the folder contents list, rather than requiring a special button to be pressed to see it. For a start it is more intuitive & faster to use. It has already been done on MOS & I think some 3rd-party OS3 hacks, and it's really nice.
Well I don't have any idea how it works but isn't possible to make a third-party software which could be a ASL replacement ? Or the limitations are due to the AOS libraries ?
Well I don't have any idea how it works but isn't possible to make a third-party software which could be a ASL replacement ? Or the limitations are due to the AOS libraries ?
The best solution would be to implement the new ASL as a class within the ReAction/BOOPSI framework. (Asl.library would still need to remain part of the OS for compatibility reasons.) Info- and query requesters are already programmed this way, through requester.class.
Just look at the mess the programmer has to face when making a GUI on the Amiga:
1. Screens and menus are programmed using intuition.library. 2. Windows, gadgets, images and some types of requester are programmed in an object-oriented way, using ReAction. 3. File-, font- and screenmode requesters are programmed using asl.library.
djrikki wrote: 2. They need to be more customisable for the developer, ability to add gadgets such as:
a) Save As file type
b) Filter by file type drop-down box as opposed to expecting user to type #?.ext. So in a music application you could filter by .MOD file, MP3, MP4, AIFF etc. In a graphics application you could filter by JPG, PNG, TIFF, BMP etc accessible from a drop-down box. If the pro-user wants to filter files traditionally he can enter #?.ext in the filename field.
You are confusing file types and file extensions. Stupid windows tells you that you would change the file type by just renaming a file, which is of course total BS. Amiga datatypes can inspect the file itself (any many datatypes do it that way), so that eg a jpeg file will always end as picture, no matter which extension is has. In ASL you have the posibility to define a hook that can filter the files so that you can show only picture files (identified with datatypes library) in the requester.
Yes, that's already there as a hook, but not many applications use it... The Workbench Preferences programs do IIRC - try opening a non-picture file as a WBPattern backdrop. It doesn't even list them, regardless of file extension. Maybe some applications should be updated to use it. However, the save as filetype is needed as for example, a sample editing app could save the sample as IFF, MP3, WAV etc...
In regard to rename function. Windows has had it for ages, select a file press F2, but yeah a button is more useful. Bearing in mind again that my knowledge of Amiga is somewhat distant: useful features in a requester would be New Drawer, Rename and Delete as well of course Load/Save and perhaps some right-click functionality giving menu under pointer with common options on other OSes like Delete (aka move to Trash), Properties (aka Get Into) and Open With can often be a useful feature.
In regard to show file types when 'Opening a file', yes its been in Windows since year dot, but really its for information only so you can see what an application is capable of opening. Its of course better if the requester just shows every file that can be opened by the application and allow the user to filter the list further or simply Show All.
If the OS team make it a priority to fix ASLs then the OS as a whole would look more appealing; or at least thats my opinion.
But we have to of course bear in mind there is so much more than needs doing as well like the graphics system aka ditching Warp3D and replacing it with MESA.
A case of sit back and wait and see what Hyperion brings out next, from here it can only get better.
Well, all of the above mentioned but "Get Info" (I don't see the point of if anyway) is already implemented in ASL. Frankly to me it's more intuitive to look for such functions in a menu than press the Fkeys one after the other to find the desired operation.
Then we are there again, on every OS there is something you have to look in a manual for. At the beginning the MacOS X requesters (beside the fact that they bind to the window they have been called from, actually only the save file requester) where a bit confusing to me, especially the simple ones. Now I got used to them, find them personally better than the WinXP ones, but still, there are things I miss (rename for once and drag and drop).
But the "Save as" function is really a good idea and I would love a preview function, almost unbearable to choose pictures and images.
edit: ps.: the binding of the requester to the calling window, is sometimes annoying to me. but IMHO a good concept over all. :)
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
File extensions are an awful way of identifying a file type, just look at the mess on Windows where it is the only option. Of course it is necessary sometimes with particular formats which don't have distinctive headers.
