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).
sorry, I misunderstood that. :-/
Quote:
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 :) [...]
because of my misunderstanding, I did not get it, now it's clear. And yes a good idea!
Quote:
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).
yes, I was merely pointing at the fact that it's hard to make it intuitive in a way that it's understandable at the first glance for everyone. Sometimes you just have to understand and learn the paradigms of a system, in this case ASL as a part of the system.
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.
1. You don't have to open a screen yourself (if it's created in Screen.prefs AFAIK). Menus are arrays so basicly you don't program them. 3. No you don't use asl.library. You can use BOOPSI/ex-Reaction classes for those (GetFile, GetFont...). Go back to 2.
So you're using BOOPSI classes for everything.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Menus are arrays so basicly you don't program them.
Is there a better way than gadtools for Amiga menus? Because gadtools really really *really* sucks at menus: Terribly verbose for declaring them, hard to use more advanced features (like ghosted items & tick boxes), and the implicit numbering of all items means a major headache when you want to make minor changes. (I know it's still way better than directly programming them using Intuition, but this is 2010 not 1990.)
After my experience with them for RunInUAE, I ended-up writing a tiny module (in PortablE) which basically fixes all the problems I saw. I can now define menus using compact tag lists, the more advanced features are trivial to use, and modifying the menu doesn't cause major issues.
djrikki wrote: 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.
More suggestions plox.
(changed topic title - Simon)
1. Don't see a visibility problem with the black on light grey here? Shadow for already black text seems completely unnessary and would look odd.
2. a) Probably a good idea.
b) Sort by type would be useful, has been option for drawers for a long time. File requesters are usually preconfigured to just show usable file formats anyway, e.g. MPlayer file requester won't show .jpg, but you can make it you wanted to for some reason.
Personally I like the theory that the datatypes system allows all programs supporting datatypes to open any file there is a datatype for. I think there is a missed opportunity with datatypes at present, i.e. a Word doc datatype and the like could be really useful. Would like to see the centralised datypes idea enhanced and updated with an enhanced multiview (extra controls) that could then view things like PDF, Word docs, videos, etc, that would be pretty cool, rather than having lots of different viewers/readers.
I think the ASL look should be brought inline with Workbench drawers when viewing by name, i.e. adding a 'type' column, horizontal banding of background and the mini icons before the file names would be good.
Daniel wrote: @djrikki [...] b) Sort by type would be useful, has been option for drawers for a long time. File requesters are usually preconfigured to just show usable file formats anyway, e.g. MPlayer file requester won't show .jpg, but you can make it you wanted to for some reason.
Personally I like the theory that the datatypes system allows all programs supporting datatypes to open any file there is a datatype for. I think there is a missed opportunity with datatypes at present, i.e. a Word doc datatype and the like could be really useful. Would like to see the centralised datypes idea enhanced and updated with an enhanced multiview (extra controls) that could then view things like PDF, Word docs, videos, etc, that would be pretty cool, rather than having lots of different viewers/readers.
I think the ASL look should be brought inline with Workbench drawers when viewing by name, i.e. adding a 'type' column, horizontal banding of background and the mini icons before the file names would be good.
you can do exactly what you described. Have a look for those and other options in ASL prefs. as you can also do the sorting by type. Exactly like in workbench, just click on the "name", "size", "comment", "type" "date" etc column titles to sort by them.
edit: i stand corrected, you can show the type but not sort by it yet.
Never really noticed ASL prefs till now, turned strips on, file type (should be default on). Also noticed middle mouse button goes to drives when clicked, very handy and had no idea it did that, learn something new every day!
No mini icons though.
Thanks, that middle click will come in handy!
Seem to remember Apple sending out weekly emails with OSX hints and tips (some years ago now). Something similar for AmigaOS would be quite useful.
However, the save as filetype is needed as for example, a sample editing app could save the sample as IFF, MP3, WAV etc...
Yes that could be usefull. More general I would say it should be possible to simply define an array with caption and leave it to the programmer to respond to the slected field. So you could add for example selection in the open requester to open a file read only or the save as type in a save requester.
I'm not sure how, but I think PPaint is using that kind of requester?
PPaint uses a custom requester, i.e. it is coded as part of the application. Of course anyone can do that, but a) Why should we have to? b) It will take much longer to develop even the tiniest of apps, and c) The user will end up with different requesters in every app, with no system-wide consistency. In PPaint you were able to select an option to use the ASL requester instead, which meant that you chose your filetype etc. in a different window.
Hehe, wow... Maybe I'm the only one here who actually likes the ASL file requester? Something which you can do on the Amiga which still really annoys me in Windows is still move the calling window when a requester is open. Windows simple won't let you, meaning you have to cancel the requester before you move the window. Please please please don't introduce this "feature" on the Amiga!
1. You don't have to open a screen yourself (if it's created in Screen.prefs AFAIK).
Yes, IF
Quote:
Menus are arrays so basicly you don't program them.
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:
3. No you don't use asl.library. You can use BOOPSI/ex-Reaction classes for those (GetFile, GetFont...). Go back to 2.
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.
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.
Just to add for those unaware that what you are referring to already exists in ASL as ASLFR_FilterHook tag (in fact it already existed since ASL V38 under the form of tag ASLFR_FilterFunc)
@Amigo1
Quote:
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.
What ? Windows has it since Windows 95 (as every file requester are in fact a small Explorer you can do everything you can do in it inside a file requester)
@ASL maintainer
Another thing that annoys me is when a program wants the user to select an icon and they are not displayed in the ASL requester they are opening. For example that's the case with AmiDock. I don't know if this is due to dumb programmers opening an ASL requester "Please select an icon" and at the same time specifying
ASLFR_RejectIcons, TRUE
or if this is ASL autodocs that are false and ASLFR_RejectIcons is defaulting to TRUE instead of the documented FALSE. Bu t anyway that's really annoying.
[...] Hehe, wow... Maybe I'm the only one here who actually likes the ASL file requester?
No, I like it too as you can read in some of my posts!! but some suggestions are good and would be nice to see them implemented.
Quote:
Something which you can do on the Amiga which still really annoys me in Windows is still move the calling window when a requester is open. Windows simple won't let you, meaning you have to cancel the requester before you move the window. Please please please don't introduce this "feature" on the Amiga!
I was thinking about this too when I mentioned the "sticky" save-requesters on MacOS X..
I love the feature where you can drag a file into an ASL request, and it will set the dir and filename to that file. Incredibly handy when where you want to load or save to is open on WB already, especially if the app itself isn't an AppWindow.
For years I kept trying to do the same thing in Windows and getting annoyed when the file I'd dragged into the requester copied or moved to wherever the requester was pointing
Didn't they say that they implemented Reaction window.class features in Intuition since 4.1+ so you're basicly using Intuition and BOOPSI instead of Reaction always.
Why it's a problem opening screens with Intuition ?
Maybe I've been doing something against Amiga programming rules but I don't remember needing to use ClearMenuStrip() SetMenuStrip(). I'm using OffMenu and OnMenu to disable/enable menu items. I don't remember how I changed the checkmark flag.
You can use GetFile/Get#?... gadgets without needing visible gadgets in your GUI.
Use WA_NewLookMenus and WINDOW_NewMenu tags to add NewMenu structure to a window.
I didn't ever bother to study and use GadTools when I was programming for classic in old days. I was writing big load of those Intui#? structures which was quite pain when you were working on something bigger. When I got my A1 and AmigaOS4 system I started studying Reaction and using it (skipping GadTools completely).
@Chris Quote:
I love the feature where you can drag a file into an ASL request, and it will set the dir and filename to that file.
I love that feature too.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
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.
What ? Windows has it since Windows 95 (as every file requester are in fact a small Explorer you can do everything you can do in it inside a file requester)
I know, I was referring to MacOsX. Sorry for not having been more clear. Also, I hope the menus will stay in ASL. I don't see why they should not be there.
@ASL maintainer
Another thing that annoys me is when a program wants the user to select an icon and they are not displayed in the ASL requester they are opening. For example that's the case with AmiDock. I don't know if this is due to dumb programmers opening an ASL requester "Please select an icon" and at the same time specifying
ASLFR_RejectIcons, TRUE
or if this is ASL autodocs that are false and ASLFR_RejectIcons is defaulting to TRUE instead of the documented FALSE. Bu t anyway that's really annoying.[/quote]
And what you are saying here I concur, it might be very confusing for people.
Why it's a problem opening screens with Intuition ?
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.
But nitpicking a little bit more: Newcomers don't even know what are screens. Well, if you don't define any pub screen in tags for a window then the window will be opened on Workbench. If you already know which screen to use then it's already available somewhere somehow. (Use WA_Pubscreen / WA_PubScreenName.)
(Edited many times because I don't know what to say...)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
A dummy's guide to creating windows, adding gadgets, adding functions to gadgets would be most welcome. Does the SDK have a complete low down of the all the different function calls()? Gee I'll have a look, but I would welcome a quick guide to how build an interface from scratch and accept input from the user.
Would love to get back into programming again, I did work for a company once who wrote software for the military, flight and tank simulation that sort of thing; who used C++. But I wasn't in that role for very long, so didn't learn a great deal and it wasn't like I was coding from scratch - just adding to existing code.
At the same company I got to use Macromedia Authorware (I'd never heard of it before I used it) pretty good really, but you never really get your hands dirty; quite 'high-level generation?' language like object-orientated; literally.
Before college I used to mess about in AMOS, lol I recall it quite well I must have been 12 or 13. Being a fan of RPG games til this day I wanted to have a go to see whether I could create a mapping-system like Ultima's. So I created my icons, Grass, Water, Doors, Levers, Benches, Trees and what not that would make up this top-down adventure game and whacked it all into an IFF File. Wrote the code to strip off the icons 25x25pixels or whatever, give each icon/object some info like this can't be walked into, this is a door press space next to it to open it toggle the icon state etc etc. Was quite fun at the time, got the little guy walking around a scrollable screen, opening doors, losing HP if he walked into a wall that sort of thing - ahh memories, yeah am babbling on. The game didn't go much further than that.
At the moment I actually work in B2B telesales, but tiny company so more or less my own boss; designing email newsletters all that crap.
But over the last 6-8 months I've been learning a lot of Applescript (a scripting language loosely similar to Arexx), but its actually more like an application I have made rather than just open this in that and do x with it.
And so in these last few months, its taken me back a few years (A lot!) and reminded me how much I used to love coding and problem-solving.
I've already decided what my first AmigaOS project will be if I can of course get to grips with C again. Nothing to get excited about though, so no watching this space here. =P Just a small command that should belong in the C drawer as part of the standard OS install.
A dummy's guide to creating windows, adding gadgets, adding functions to gadgets would be most welcome.
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.
At work atm, just spotted a Hide Extension checkbox as well in Mac OS X requesters, personally I never use it, but it is another gadget. Defaults to hiding the file extension on first install. :D
Daedalus wrote: Hehe, wow... Maybe I'm the only one here who actually likes the ASL file requester?
No, I like ASL, it's one of the things that makes Amiga experience worth while - blazingly fast no-nonsense requesters, where the stuff you need 95% of the time is available as big, easy to hit gadgets and the stuff you only need 5% of the time is to be found in a menu, and not cluttering the interface. And background colour signaling whether it is a "open" or a "save" requester. Very nice, very intuitive, and the most effective requesters around, for any OS.
But, please - feel free to ruin that too in OS4, like they did in MorphOS. I ended up using OS3.9 asl.library there, since the one that comes with the OS is slow, cluttery, has silly context menus all over the place and quite frankly pisses me off. The 68k OS3.9 asl.library runs in circles around the powerpc native one.
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
