Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

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

0 Members and 1 Guest are viewing this topic.

Offline NinjaCyborg

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)
 

Offline TribbleSmasher

That would require experiencing the newly added features in 3.2. Who knows, maybe everything we ever need is already included?

like i wouldn't mind booting a CF from the PCMCIA slot, with boot priorities properly respected.

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)

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 NinjaCyborg

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.

Offline nbache

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

Best regards,

Niels
 

Offline lionstorm

I bought 2x AOS3.1.4  floppies + ROM for my A1200s, installed only on my A1200/B1260 and still annoyed by :

- no unarchiving tool (Unarc rulezzz)
- no autopupdate of drawer/RAM after copying something in it
- no autoresize of drawers
- no filemanager like view (Filer rulezzz)

Anyway it is great to see some update released, sadly I should have waited for AOS3.2 which seems to be more features rich than 3.1.4
 

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 Minuous

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.
« Last Edit: May 18, 2021, 06:29:57 AM by Minuous »
 

Offline nbache

Plus one of the big advantages of AmigaOS in general (classic as well as NG) was always IMHO the tendency towards modularization rather than monolithization (if that's even a word ...).

Best regards,

Niels
 

Offline chris

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

Best regards,

Niels

RAWBInfo I think is because it needs ReAction, which isn't guaranteed to be available if you've booted a barebones WB installation (the built-in info window uses gadtools, which is always available)
ASyncWB I guess is separate because it is easier to have a program which patches the OS and is already a separate process, than trying to make WB spawn a new process internally when copy operations are initiated (also it probably uses ReAction again?  Although there's no reason why such a simple UI would need it)
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar picture is Tabitha by Eric W Schwartz
 

Offline nbache

@chris:
Quote
(also it probably uses ReAction again?  Although there's no reason why such a simple UI would need it)
The progress meter when copying etc., I assume.

Best regards,

Niels
 

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 Minuous

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.
 

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 kolla

RAWBInfo (RA as in ReAction) *is* an addon, one that replaces the WBInfo built into Workbench.library with one using the addon collection of boopsi classes known as ReAction. It is almost ironic that RAWBInfo is back in the OS, as in the “drama” that went down with Os 3.1.4 release, ThoR made it very clear that WBInfo window is NOT an editor (despite the obvious fact that tooltypes are edited there) and that essentially all features of RAWBInfo (all file system flags, copy/paste icons, palette manipulate, icon type manipulation etc) are somehow “wrong” and anyone thinking otherwise just don’t know how dumb they are. Well, and now RAWBInfo is back, hopefully less buggy than previous versions.

B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS