Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: What are your top AmigaOS annoyances that you'd like to see addressed?  (Read 3364 times)

0 Members and 1 Guest are viewing this topic.

Offline NinjaCyborg

Like the title says, what are your Amiga annoyances that you wish would be fixed after all this time?

Mine are:

  • When Intuition asks you to close all windows so it can change the workbench screen mode, and especially when it keeps asking you, even though it has already changed the screen mode, and even though you have already closed all the windows
  • Workbench doesn't let you tell it to always show icons for any folder that has no icons in it by default
  • You can't tell Workbench to ignore Default Tool and always use DefIcons, or at least to automatically fall back to deficons options if default tool can't be found - also to diffentiate between the Viewing default tool and the Editing default tool
 
The following users thanked this post: First Ninja

Offline Matt_H

Good idea for a thread! I can't think of any off the top of my head, but I'm sure some will come to me as the discussion progresses.

I agree with your points so far. One note, though:
Quote
Workbench doesn't let you tell it to always show icons for any folder that has no icons in it by default
There are some partial workarounds for this. You can snapshot a window after selecting Show All Files. Then if you copy that drawer's icon to ENVARC:sys/def_drawer.info your new drawers will be set to Show All Files by default. I think you need DefIcons for this to work, not sure about a stock 2.x/3.1 system.

Offline NinjaCyborg

That's a good one, and even after all these years still tips to be learned. IIRC the def_drawer def_tool def_project def_trashcan icons only pre-DefIcons feature was that they'd be used as templates when new objects were created in iconedit but not by Workbench when it's trying to fill in iconless files.

 

Offline cgutjahr

Workbench as a whole is one big annoyance, IMHO. Slow, cumbersome and minimalistic - and the concept of every file having its own icon and storing default tools, positions or whole drawer layouts and settings in there introduces a ton of problems in daily use.

The other thing that always annoyed me was the lack of consistency in the UI interfaces: Some twenty years ago, I counted how many different keyboard shortcuts for answeing a simple yes/no? requester I had to remember. I came up with nine or ten different methods of answering such a requester(Amiga-V/B,Enter/Escape, TAB+Enter, "y"/"ny"...) - most working just for one or two applications, none of them working for all requesters.

Offline NinjaCyborg

IMHO the right way to think of Workbench's DiskObjects i.e. .info files is they are equivalent to the Mac resource forks, where extended metadata about a file is stored. Yes they store icons, they also store arbitrary 'extended attributes' i.e. tooltypes.

The difference is on a Mac, the filesystem hides that abstraction for you and treats the resource fork and the data fork (i.e. the actual file) as one atom. This can be seen not only on CrossMac when reading ancient HFS disks, and today when using a FAT disk on a Mac, where the resource fork is what becomes the annoying ._ files.

But yes it would be nice if more things other than workbench were aware of their existence. Or that perhaps the filesystem could take some responsibility for ensuring they move or are deleted with their 'data forks'.

As for shortcuts and UI, it would have been nice if more apps had followed the AUISG suggestions, unfortunately it was pretty hard to get hold of a copy back in the day I recall, although I have one on my shelf. It is/was totally up to developers to choose their shortcuts so it's on each of them. Perhaps if ClassAct/Reaction had seen greater adoption or Commodore had released their own proper set of GUI controls or even just some complete examples of full features 'document' centric applications we might have all then used as a template. The best example I ever saw was Deluxe Music 2, absolutely it set the standard for how to build a font sensitive, style guide compliant, user friendly, and accessible (due to consistent use of shortcuts) document centric application. Heck, even today I can't think of another app that has a global, floating set of toolbars that crucially, can never itself be selected as the active window - something crucial for free floating 'speedbars'.
 

Offline cgutjahr

But yes it would be nice if more things other than workbench were aware of their existence. Or that perhaps the filesystem could take some responsibility for ensuring they move or are deleted with their 'data forks'.
One could debate if icons for executables make more or less sense than a resource fork or Linux's '.desktop' files or just storing the information in the executable file's header. But drawers, project files or media featuring their own custom icons just introduces a ton of problems:
  • constantly having to change default tools for stuff you just got from somewhere
  • as an RTG user, you were also constantly resizing and redisplaying drawers, just so you could read the filenames
  • You're constantly fixing the appearance of something because icons look ugly/out of place or they don't display at all
  • global changes are pretty much impossible: You want to switch to another icon set, or use a different default picture viewer? Have fun changing hundreds of icons
  • nothing respects your personal preference for how drawer contents should be displayed
  • listing directory contents becomes dog slow (on 1992/1993 computers)
  • I need to tell (e.g.) my text editor whether to create icons (1st useless configuration option), what default tool to insert (2nd useless config option) and how to deal with existing icons (3rd useless config option)
Yeah, you could create workarounds for most of these problems. But it would be way easier to just ignore any icon not associated with an executable file, and ignore position data for executable icons. And then let the system handle all that icon business automatically.

Quote
As for shortcuts and UI, it would have been nice if more apps had followed the AUISG suggestions
Agreed, but I think the bigger problem was that people never used the official toolkit(s) because...

...in the eighties there wasn't any (to speak of)
...in the early nineties, most of your users were still on 1.x (and you didn't fancy rewriting your entire GUI)
...in the mid/late nineties, Gadtools was already outdated so everybody was coming up with extensions again
« Last Edit: March 11, 2021, 05:00:49 PM by cgutjahr »
 

Offline Matt_H

Workbench as a whole is one big annoyance, IMHO. Slow, cumbersome and minimalistic - and the concept of every file having its own icon and storing default tools, positions or whole drawer layouts and settings in there introduces a ton of problems in daily use.
Ah, for me the minimalism is part of the charm of Workbench. I like the total control separate icon files offer. My workflow has always been Workbench for front-end UI, DOpus4 for back-end file operations. But I agree that sometimes some automation would be helpful. Ambient has made moves in this direction, hasn’t it? You can toggle between auto arrangement and icon-defined arrangement in the global prefs. But it would be cool if you could set it at a per-drawer level. i.e., default to one and override to the other either via a drawer tooltype or by, say, holding LeftAmiga while opening a drawer. (Maybe Ambient already does this?)

Quote
The other thing that always annoyed me was the lack of consistency in the UI interfaces: Some twenty years ago, I counted how many different keyboard shortcuts for answeing a simple yes/no? requester I had to remember. I came up with nine or ten different methods of answering such a requester(Amiga-V/B,Enter/Escape, TAB+Enter, "y"/"ny"...) - most working just for one or two applications, none of them working for all requesters.
This is a good one. I thought LeftAmiga V/B was universally recognized by Intuition? I guess not. What could Commodore have done here to enforce standards? I.e., what was baked into 1990s MacOS/Windows APIs so that they didn’t have this problem?

Offline NinjaCyborg

Left amiga shortcuts are universal but there aren't many of them (two in fact). Right amiga shortcuts are application specific.

The comments about Workbench are good, it would be nice if you could set Workbench to (a) ignore default tool on Project icons and read it from the deficon instead, either always, or when the default tool does not exist and (b) set it to ignore the icon image of the project icon and always load the icon from the matching deficon. Only the tooltypes would be preserved which would be ignored when not relevant.

Likewise for drawer icons it would also be nice if you could put Workbench in some kind of 'smart' mode where it picked drawer size and did an auto cleanup of any/all drawers and certainly all drawers with no icons at all by default.

I'd also like it if the RX show ports command only showed ARexx aware ports, not all named ports.
« Last Edit: March 11, 2021, 03:44:41 PM by NinjaCyborg »
 

Offline cgutjahr

My workflow has always been Workbench for front-end UI, DOpus4 for back-end file operations.
Sure, so was mine - and probably every other Amiga user's. But "frontend UI" basically means using WB as a program launcher - and for that little functionality, you had to spend way too much time finetuning it IMHO.

I'm not bashing WB btw. - back in the early nineties, all the desktops had tons of annoying quirks. It's just that WB never evolved, and we've been using it way past it's original expiry date.

I thought LeftAmiga V/B was universally recognized by Intuition?
No, it's an ASL thing, not intuition (IIRC - it's been a while). Meaning that any application not using ASL would usually not respect these shortcuts.

Quote
I guess not. What could Commodore have done here to enforce standards?
The original Kickstart didn't have any UI toolkit worth mentioning, due to lack of time and ressources, and probably Mical's lack of experience and research on the subject. Once you sold millions of machines with that version of the OS, you have a problem. Commodore would have had to come out with a UI toolkit addon ASAP. One that worked under 1.x and was free to install (or distribute with commercial applications). But that's probably asking too much, given Commodore's problems at the time, and the total lack of any UI experience - let alone research on the subject.
 

Offline Matt_H

The comments about Workbench are good, it would be nice if you could set Workbench to (a) ignore default tool on Project icons and read it from the deficon instead, either always, or when the default tool does not exist and (b) set it to ignore the icon image of the project icon and always load the icon from the matching deficon. Only the tooltypes would be preserved which would be ignored when not relevant.
I wonder if (a) could be implemented currently with a commodity. i.e., if a certain hotkey is detected in the input stream (say, Left Amiga) when double-clicking a project it'll re-parse the startup command using the DefIcon.
(b) sounds like it would be harder to implement. As a first step, it would be helpful if the Info window for projects showed both the current icon and the DefIcon and if you could drag them onto each other. i.e., replace the current icon with the DefIcon or replace/update the DefIcon with the current icon, all from a single window.
 

Offline Matt_H

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #10 on: March 11, 2021, 05:12:01 PM »
Sure, so was mine - and probably every other Amiga user's. But "frontend UI" basically means using WB as a program launcher - and for that little functionality, you had to spend way too much time finetuning it IMHO.

I'm not bashing WB btw. - back in the early nineties, all the desktops had tons of annoying quirks. It's just that WB never evolved, and we've been using it way past it's original expiry date.
Heh. Maybe I'm like Workbench and never evolved, either. :) I never did much customization or tuning beyond the standard prefs editors and I've gotten so used to the quirks that I hardly remember them.

Quote
The original Kickstart didn't have any UI toolkit worth mentioning, due to lack of time and ressources, and probably Mical's lack of experience and research on the subject. Once you sold millions of machines with that version of the OS, you have a problem. Commodore would have had to come out with a UI toolkit addon ASAP. One that worked under 1.x and was free to install (or distribute with commercial applications). But that's probably asking too much, given Commodore's problems at the time, and the total lack of any UI experience - let alone research on the subject.
That certainly explains the lack of standardization in the 1.x era. But then we had ASL/GadTools with OS2.0. In other words, why didn't that "fix" the problem from then on? Was it too late by that point to get compliance from developers?

Offline NinjaCyborg

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #11 on: March 11, 2021, 05:21:57 PM »
@Matt_H

There's a few reasons:
- A lot of the installed user base and a lot of the application developers themselves were US based but stuck on OS 1.3, whether EA or Newtek - and remember if you changed the UI on a pro tool like DPaint or LightWave your pro users would have to re-learn everything. Sometimes simple is best. Anecdotally version 2.0 and up was more likely to be found in UK and europe not least because the 500+ sold so well
- Gadtools was by no means a full featured 'widgets' toolkit, it's pretty bare bones in terms of what it offers, and you have to do things like dynamic font size support and dynamic layout yourself which is a chore. Although apparently there was a gadtools for 1.3 available to developers? Deluxe Music 2 might even have used it for backwards compatibility, I recall reading in a Medium post by Talin, the developer of it
- Whilst there were some options that helped fill that gap such as Olsen's gtlayout library, really only MUI and ClassAct/Reaction came close to providing what you'd get from say, MFC on Windows, and when I say close, I mean still a million miles away. MUI ran like a dog with no legs on unexpanded machines but without it we'd never have got half the software we got back then, whilst ClassAct came really late in the day, like 1997 I think it was first released by which time most developers had moved on (but there was for a while some really promising software that never shipped full versions, like Voodoo, and a news reader, and a web browser that CAldi and co promised)
« Last Edit: March 11, 2021, 05:23:07 PM by NinjaCyborg »
 

Offline TribbleSmasher

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #12 on: March 11, 2021, 05:25:22 PM »
With Kickstart 2 the StyleGuide was introduced, similar to the Macintosh.
Unfortunately, it wasn't mandatory so every developer keep doing horrible things. There wasn't even a default menu struct or clipboard interface one had to use, everything was by choice so they did...

Offline NinjaCyborg

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #13 on: March 11, 2021, 05:30:57 PM »
You've reminded me another 'annoyance' - that the clipboard could support 256 clips, but everyone just used unit 0. What would have made most sense I think is for each IFF type to be given a device number so you could always clips one of each type. Sure, at the time they might have thought that's no good, there could be more than 256 data types. In practice though you'll never have more than plain text, rich text, bitmap, vector image, 3d object, audio sample and a handful of others. Heck, check the official IFF registry there are only 37 types of which half are metadata or bitmap types.
 

Offline cgutjahr

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #14 on: March 11, 2021, 05:40:16 PM »
Quote
That certainly explains the lack of standardization in the 1.x era. But then we had ASL/GadTools with OS2.0. In other words, why didn't that "fix" the problem from then on? Was it too late by that point to get compliance from developers?
Commodore Germany sold about 1.3 million Amigas running Kickstart 1.x (A1000, A500, most A2000s, CDTV) and some 0.2 million Amigas running 2.x (A500+, 600, later A2000s). Obviously, any sane software developer would target Kickstart 1.x.

The situation would only change later, when the A1200 showed up and most A500 users would abandon the platform for the PC.

Gadtools was by no means a full featured 'widgets' toolkit, it's pretty bare bones in terms of what it offers, and you have to do things like dynamic font size support and dynamic layout yourself which is a chore.
Sure, but we're talking 1990 here, I doubt the competition was doing any better back then?
« Last Edit: March 11, 2021, 06:26:21 PM by cgutjahr »