Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

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 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 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

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 Matt_H

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.

Okay, and then by the time most software was being written for 2.0+ in ~1994 we had the other GUI toolkits starting to proliferate, each with their own UI conventions. And that's why the lack of standards has persisted. It makes sense to me now. :) Do I have it right?
 

Offline Matt_H

Given that ixemul on 68K has fragmented into so many non-compatible implementations now, I think static/compiler-side linking is the way to go for the future. As said above, memory is cheap now.

And I’ve said this ever since they were introduced, but I think OS4 has its own problems with the SObjs: implementation. With softlinks/hardlinks and different versions of a given SObj mutually incompatible with each other (and none of them have $VER strings), it’s creating dependency hell on AmigaOS. As a user, it feels like it provides zero benefits but lots of headaches. Yes, there’s a convenience factor for developers for porting from *nix, but I’d rather this was handled statically as an improvement to the SDK.
 

Offline Matt_H

But if you're going to use it you best put the versions you need in your own application specific PROGDIR:SObjs drawer.

While I hope that the OS4 roadmap calls for phasing out SObjs entirely at some point, this is a great interim/medium-term solution. I admire the OS4 devs' desire to make *nix code more portable, but I think that effort would be better spent on build systems and development libraries rather than new runtime paradigms for users.
 

Offline Matt_H

OS4 has made some progress on fonts by unifying all (most?) outline font types under a single TypeManager/Intellifont/Fountain-like program. On OS3 we still need separate font install utils for TTF, PostScript, Intellifont, etc. So step 1 would be bringing a similar unified utility to OS3.

Step 2 would be  better font family detection across the board. I'd like to see ASL font requesters display, e.g., just Arial and not all of Arial, Arial Bold, Arial Italic, Arial Bold Italic, etc. The subtype should be selectable from another gadget in the requester. And if I have a font and I set it to be italic I want the system to automatically use the italic variety of that font, not apply some algorithmic distortion to it.

Step 3 would be the ability to drop some .ttf or .otf files into Fonts: and have them just work - without having to "install" them.
 

Offline Matt_H

With OS3.2 about to ship, thoughts can turn to OS3.3! What ideas would you like to see addressed in 3.3? (this is not an official question! I'm not part of the team working on it)

From reading the 3.2 FAQ, it looks like there's quite a bit of functionality controlled by Env vars. I'd like to see that moved into Prefs programs instead - seems more polished that way.

Similarly, ASyncWB and RAWBInfo are back. I'd rather see those features integrated into Workbench and controllable via Prefs. Keeping them as separate programs makes them feel kind of hacky, like they were in 3.5.
 

Offline Matt_H

I assume those are still separate to stop them using up memory on lower memory systems and/or so that workbench library isn't bloated in size.

That's an interesting point, but I still wonder if there''s a cleaner way of implementing that functionality. As arguments for LoadWB, maybe? RAWBInfo and ASyncWB have been around since 1999 or earlier. Surely that code could be optimized/moved into some other component without much bloat?

I also wonder if there's a conceptual lesson/design that could be brought forward from OS1.3. My understanding is that the info window was contained in info.library back then. Based on that precedent, could RAWBInfo be moved into a new iteration of info.library? Or maybe an info.class for ReAction? That would keep it out of workbench.library.

And for comparison, they are still separate in OS 4.x, even though lots of other stuff has been done to Workbench.

So probably for a good reason ...
My criticism/suggestion applies to OS4, too. They're in OS4 because they were carried forward from OS3.5/3.9. My overall point is that it seems like Workbench functionality is still being conceptualized as though it's 1999. Let's think bigger! :)
 

Offline Matt_H

Based on that precedent, could RAWBInfo be moved into a new iteration of info.library? Or maybe an info.class for ReAction? That would keep it out of workbench.library.

It's already out of workbench.library, so I don't see much benefit in having it as a class rather than an application.
The point I’m trying to make is that as a separate program that replaces the default info window, it feels like a patch/hack. Ideally it would just be part of workbench.libray, but if bloat is a concern then packaging it as a library/class would make it feel like a more integral part of the OS.
 

Offline Matt_H

The point I’m trying to make is that as a separate program that replaces the default info window, it feels like a patch/hack.

It isn't a patch or hack, it uses the defined hooks which Workbench makes available for this purpose. Doing it this way means anyone can write an enhanced replacement for this part of the OS.
That's great that it works in an OS-legal way, but it still feels like a hack or an add-on. Maybe I'm alone in that opinion. Since it's an OS component I just wish it was a little more transparent or less noticeable. I like what it does, I just don't like it adding clutter to my WBStartup drawer.

Anyway, I think we're going to have to agree to disagree on this. Let's move on to another subject. :)
 

Offline Matt_H

Thread resurrection!

A Printer System, it's high time we had something. Turbo Print is long gone, at least a spooler or something. Gutenberg? probably not coming...

Chris

CUPS has been floated as a possibility for a long time and I was always skeptical of how it could be implemented in a clean, Amiga-like fashion. But recent versions of MorphOS have done something like this pretty successfully. It's a bit clunky because it's alongside TurboPrint for now, but as it gets refined I think it might be worth borrowing the concept for regular AmigaOS.
 

Offline Matt_H

@Thread

By far it's the stupid 'Drawer Clean Up', 'Snapshot All' and 'Show All Files' rubbish! Just make it so that drawers are always tidy and all files are always visible and when you close the window it automatically saves it's layout etc. All this archaic rubbish needs overhauling! TurboPrint is an absolute dream still but Workbench is showing its age IMHO.

Gotta disagree, slightly. :)

Manual snapshotting is something I absolutely *love* about the Amiga. Similar to the Save/Use/Cancel philosophy - I know that if I'm messing around with something, none of the changes will be permanent unless I explicitly make it so. Hiding clutter in a drawer by only displaying files with icons is another valuable feature for me. On Windows/Mac, I can't stand it when I make a change to a window for a particular one-time scenario and then need to undo it by hand the next time.

MorphOS is sort of doing something like you describe. There's a view mode that will ignore icon positioning info and automatically place things in a grid. What I don't like about it is that it also scales the icons up or down to fit the grid, which can make them look weird. And it's a system-wide toggle buried pretty deep somewhere.

That being said, if auto-tidy or auto-snapshot could be set on a system-wide *or* per drawer basis I think I'd be interested. There are certain drawers where I could envision using it, but would still want the regular behavior elsewhere.

Per earlier posts in this thread, I believe permanent Show All Files can be mostly done now by copying an icon with that setting to ENVARC:sys/def_drawer.info. All new drawers should then have Show All Files enabled as default.
 

Offline Matt_H

How about a "Task Manager" like windows so when a task hangs up and freezes you can check tasks to see what is hanging up and end the task.
Would be wonderful, of course, but being able to kill crashed tasks cleanly (without bringing down the whole system) would require major architectural changes to the OS.