Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

Offline NinjaCyborgTopic starter

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

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

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

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

@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 NinjaCyborgTopic starter

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

Ixemul provides a POSIX type environment to help with porting of complex Unix applications that need more than just a basic standard C library. On OS4 this was replaced with newlib which does much the same thing but it is much more up to date and a bit more 'Amiga-like' in it's implementation.

On OS3, there is both the 'libnix' option, which is a static library that does much of what ixemul does, except the latter does it as a shared library so in theory you only need one instance of it in memory, whereas if you use libnix you'll carry some of that weight with you in your own binary (though the linker only adds what you actually use). In practice, memory is cheap now and I'd like to think anyone using Amiga for anything serious, including serious hobby, has at least 6MB RAM if not a lot more. There's also clib2 which is a much expanded standard C library (much more than the old c.lib you got with SAS/C for example) that also goes a long way towards giving you POSIX compatibility.

On OS4 there's the also the most extreme option, AmiCygnix which, like it's inspiration Cygwin, attempts to give you the baseline part of a complete Linux distribution.

VBCC also has a POSIX link library which again covers a lot more than just the baseline C library. Indeed, I'm looking at using that to complete an up to date Python port. But I'm hoping for a decent SDK release for OS3.2.

In short, you can port a lot of non-GUI Unix/Linux software to Amiga these days relatively easily, but of course you'll find a lot of the recent stuff needs far more RAM and processing power than a classic Amiga can provide. And you need a more recent build of GCC too. Finally as always, the lack of Unix fork() creates issues.
 

Offline NinjaCyborgTopic starter

It's more than just the C library, full POSIX compliance dictates shell (command line) behaviour, security model, filesystem conventions, and a baseline set of command line tools. The shell conventions and filesystem can be mostly emulated. The security model can be ignored if you don't care about security. But it's not a small amount of work. But as I said, most of that work has been done, at least for OS4, and you can get by on OS3, I just wish there was a standard SDK baseline we were all using, as collaborating is a pain when everyone has slightly different setups for their toolchain.

fork() is not simple to emulate either if you don't have a Unix-like kernel, and compatible hardware, to begin with. Even Cygwin has to jump through hoops to implement fork(). fork is the tool of lazy developers though too. Dependency on fork is why Apache Web Server is inferior to Nginx for example.
 

Offline NinjaCyborgTopic starter

Back in the early 90s, Amiga was the only mainstream platform with half decent POSIX compatibility that wasn't itself a Unix. This was of course pre- NextSTEP, pre-Windows NT kernel with unix services, pre-BeOS and pre Linux being anything more than a student project.

I attribute this to two things: the Amiga OS developers taking some inspiration from Unix (and the notorious Unix haters handbook I reckon), and more especially, the geekgadgets work. I'm not sure who even did that work, ixemul and friends seem to have just appeared out of thin air. I'm sure someone else will post with more information about that. I, like you, always found GeekGadgets to be a bit too 'un Amiga' like but the fact is it was necessary for some of the more advanced software we got especially in the absence of a more full featured standard C library.

I believe MorphOS has made it a core part of the platform, rather than going down the OS4 path of integrating newlib, which has turned out I think to be the better solution.

[Edit] - well I did some research and apparently Fred Fish was behind it, and in his day job he also worked on the early GDB which explains his familiarity with the GNU suite of software that it was built on, and he worked at Cygnus i.e. he was part of the Cygwin team. Remember, GNU on its own is the layer of common tools that sits on top of the Linux kernel, to make a mostly POSIX compatible complete Linux operating system. RIP Fred. And look at that photo https://en.wikipedia.org/wiki/Fred_Fish - Matt Dillon (DICE C compiler and lots of other stuff), Oliver Wagner (Voyager and all those other MUI internet tools).
« Last Edit: March 13, 2021, 03:24:18 PM by NinjaCyborg »
 

Offline NinjaCyborgTopic starter

Yeah SObjs is bad enough on Linux where it somehow originated as a way to share small amounts of resident code by forcing the MMU to do loads of unnecessary extra work. So much for Torvalds obsession with efficiency. In practice as you say it leads to DLL hell, worse even than on windows where everybody long ago gave up and just keeps their DLLs in their own directory. Releasing things as SObjs in theory incentivises developers to do interface management. In practice they don't. The only advantage it brings to OS4 is making it slightly easier to port code that's structured that way. But if you're going to use it you best put the versions you need in your own application specific PROGDIR:SObjs drawer.
 

Offline NinjaCyborgTopic starter

Re: What are your top AmigaOS annoyances that you'd like to see addressed?
« Reply #10 on: March 13, 2021, 10:05:04 PM »
Fonts! Oh a huge annoyance for the longest time was the difficulty of making font aware user interfaces. Thanks be for Reaction and those who did the work in 3.9 and now 3.2 to reimplement everything using it. That's one annoyance that can be crossed off the list.

But I know what @nyteschayde means. Steve Jobs was famously as picky about fonts and font rendering as he was about rounded corners and that's one area where classic MacOS undeniably beat us back in the day. Both the default choice of fonts and the font engine leave a lot to be desired. Praise be also for the freetype2 port.

I'd also settle for a redesign of topaz 8 that is easier on the eye but which has all the same glyph dimensions.

Even OS4 comes with some pretty iffy fonts from the limited pool of fonts that were totally free in 2005. Let's hope the next version leverages some of the nice free for all uses fonts Google has been spitting out in recent years.
 

Offline NinjaCyborgTopic starter

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

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.