@Rigo

Still, we do need a few I'm sure some tags are not needed because these values are either passed to ASL from the gadget (ASLFR_Window, ASLFR_Screen) or can be taken from system defaults (ASLFR_Locale) or ASL prefs. Certain values are hardcoded in getfile, like ASLFR_SleepWindow being always set to TRUE, which I personally prefer but some other programmers may not.

So I'm for adding a meaningful set of tags that put getfile in line with ASL function-wise.

While I have your attention here, I have a small suggestion to make. In checkbox.gadget, the CHECKBOX_TextPlace tags accepts a value of PLACETEXT_LEFT or PLACETEXT_RIGHT. These values come from gadtools, and I often have to #include <libraries/gadtools.h> just to be able to use the two values. Consider that new programmers will see little relation between gadtools and ReAction, and so will spend some time trying to figure out why these two values generate compile errors - especially as the checkbox autodoc makes no mention of it. I suggest putting PLACETEXT_LEFT and PLACETEXT_RIGHT to the checkbox include file.

In light of the recent ASL requester discussion, I'd also like to draw the OS developers' attention to the fact that the getfile.gadget tags are not on par with the ASLFR_ tags. So in practice, although getfile.gadget wraps around the ASL filerequester, it provides less functionality.

For example, the ASLFR_InitialShowVolumes tag lets me open a filerequester with the list of volumes displayed automatically. But when using the getfile.gadget, there's no corresponding GETFILE_InitialShowVolumes tag and I cannot provide similar behaviour in my filerequesters.

I guess it shouldn't be too much work to add new tags to getfile.gadget so that the functionality of filerequesters is identical, regardless of whether you use ASL or ReAction.

@kas1e

There'd be a major drop in CPU usage if LodePaint was converted to a regular, no-busy-wait Exec event loop. You can see it when opening a file. Normally, LodePaint eats about 91% of my CPU in idle state. When the ASL requester opens, Exec takes over and CPU usage suddenly drops to 8%. After you close the requester, the program returns to whatever it does when idle, and we are back at 91%.

@kas1e

Quote:
Done! What's your e-mail address so that I can send you the code?

@kas1e

Quote:
OK, I'll keep this in mind when designing the fileformat selector for you. Do any of the other supported save formats have any settings?

I've said all I had in mind. Those who have ears to hear shall hear

@saimo

Quote:
Absolutely! Usability does not mean eye candy, and vice versa.

@ChrisH

Nice job you're doing there, man!

Quote:
You can try application.library's PrefsObjects for handling configuration, it's very handy and easy to program. PM me should you need help with implementing this.

@chris, kolla, TSK

I know all that, I've been an Amigan for 20 years. I don't have a problem remembering hotkeys or finding things in the ASL menu. I know how it all works.

However, as my little test (mentioned earlier) shows, people not familiar with AmigaOS are puzzled by the requesters because they find certain things illogical and/or unintuitive. And ASL is just one example: remember Thom Holwerda's AmigaOS4.1 article on OSnews? Why did this highly experienced computer user think that OS4 didn't want to "let him in"?

You cannot just tell these people, "Learn the OS!"

First, UIs should work in the same way regardless of platform, so as the user feels comfortable with them. A Windows/Mac/Linux user should not fail to save a file using an Amiga filerequester - if they do, something is wrong, and it's not the user. Quirkiness and idiosyncrasies in the UI only contribute to the learning curve - it takes enough time to learn the program functions so spare the user from having to learn the interface as well.

Second, the Internet has changed usability standards tremendously. There has been a steep decline from the traditional "first learn, then use" paradigm, and modern OSes are trying to reflect that. If we are to design an OS aiming at attracting new users, we should take that into account. (Of course if we want to keep the OS to ourselves, we can live happily with what we have.)

@ChrisH

Quote:
I do agree with the "blazingly fast" part. We surely don't need thumbnails in ASL, and neither we want to turn it into a file manager of some sort, like Windows has it. If there's something I hate about the Windows filerequester, it's the ability to move files around (instead of just selecting them, as a filerequester should do).

I, however, cannot agree with the "no-nonsense" bit because there ARE nonsensical things in ASL. I'm sorry that I'll repeat myself here but it seems worth doing so.

1. Requesters are meant to either display information (info requesters), or require user input (query requesters, filerequesters and the like). When a requester opens, you acknowledge information by pressing a button, you select a choice, you pick up a file/font etc., depending on the type of requester. All you are to do is there, all is clear, no hidden functionality. This is called single level of control and that's how requesters should be designed. ASL breaks this by having functions hidden in the menu.

2. Another reason is that requesters are not program windows so they are not supposed to have menu strips attached to them.

3. Even if we decide to ignore UI design conventions and keep requesters with menus, why is Create Directory in the second (hidden) level of control? It's such a commonly needed function that it should be visible and available right away.

4. The grouping of the buttons at the bottom of the requester makes no sense. You only group gadgets logically, according to function or a particular area of operation. Now what we have here? OK and Cancel (buttons that control the requester) right next to Volumes and Parent (navigation buttons). Surely they should form two separate gadget groups and not one.

As you can see, my grudge is with ASL, and not with kolla.

@Amigo1

Quote:
I'm sure it wasn't, that's why I don't take it personaly - did it sound like that?

Despite certain good features that surely deserve praise, the ASL requester still remains one of the most ill-designed pieces of GUI of AmigaOS. Kolla is implying that our call for improvement will necessarily make the requesters slow and clumsy to use. My question is: what makes you think that? No one is trying to bring in the Windows requester horror! We just want the system to be on par with today's usability standards, not 1990's.

@kolla

Yes, we are all participating in this discussion because we want to turn OS4 into an unusable piece of garbage.

@Mrodfr

Quote:
Ranger is developed by Steven (ssolie), not by Fredrik (salass00). But I myself keep confusing the two all the time

@MoonSire

Quote:
You are not completely wrong

@Chris

Quote:
Rather, it should return a BOOPSI object that would be then attached to the window object.

@djrikki

Quote:
A new Amiga programmers' guide is being organised as we speak. I volunteered to write the UI section, and am planning out what to cover in the two chapters that will deal with user interface programming.

Actually, there are two aspects to it, and there will be not enough room in the book to cover both properly. The first aspect is, how to program it (this is what the book aims to cover mainly). Second, how to design it so that you end up with a logical, functional UI. The latter is partly covered by the Amiga User Interface Style Guide but this document is largely obsolete and needs rewriting.

I've been thinking of drawing up at least an unofficial set of guidelines for OS4 UI design. One that perhaps would not go into so much detail as the Style Guide but it would give programmers some hints at what to aim for in their UIs. If such an initiative were endorsed by the OS Dev Team, the better.

It's been discussed numerous times that OS4 needs more documentation. The AutoDocs and Includes are about all the programmer gets. So it may come as a surprise that as regards OS4 development, there's the Dev Team, the Betatester Team, the Translator Team, but apparently, there is no dedicated Documentation Team to bring some boost and structure to the information we get.

And NO, lack of resources is not to blame here. Betatesters and translators are surely unpaid volunteers; you could find similar entusiasts to help out with the docs as well. It all depends on the Dev Team to actually WANT to make a call for such an initiative.

@TSK

Quote:
It's not a problem per se. But the keyword here is "consistency". We seasoned Amiga programmers are used to the current ways but newcomers (and we do want new programmers, don't we?) will ask questions such as: "Why do I open a screen using OpenScreen() and a window by creating an object?". And so on. All I'm saying is that the developments in Amiga UI programming have led over the years to a system that is inconsistent and difficult to understand if you look at it from outside.

@xeron

But you must be careful about one thing. WINDOW_NewMenu takes a global array of struct NewMenu that is referenced every time the window is open or reopen. So if some of your menu items change state (ticked, ghosted...) during program use, and you iconify+deiconify its window, your menu strip will NOT remember its state before iconification and will, instead, reset to the initial settings passed in the NewMenu array.

WINDOW_NewMenu was a good idea and allows attaching menus in an easy way but I'm not sure that the above has been taken into account. In my opinion, the implementation of this tag was a little thoughtless.

@TSK

Quote:
Yes, IF

Quote:
Menus are only DEFINED as arrays. But you also often need to change menu item state depending on program status, and this is where you have to IIntuition->ClearMenuStrip(), change flags in struct MenuItem, and then reattach the strip by calling IIntuition->SetMenuStrip().

Quote:
You can only use ReAction's getfont.gadget, getfile.gadget etc. when your program calls requesters upon selecting these gadgets. But if you only call, say, Open or Save from the menu, you use asl.library because your GUI has no getXYZ.gadget to use.

Quote:
This is simply not true, see above.

@mbrantley

Quote:

The Amiga Style Guide (chapter "Application Keyboard Shortcuts") does recommend reserving RAmiga-O for Open.