Amiga OS 3.2 released

[kolla]

hmm I wondering why the OS3.2 devs chose to release it now

They didn't, Hyperion did all the chosing.

[kolla]

So, you can get it for free?

Looks like that’s what was agreed upon in January, but clearly not what has been communicated from the devs and their entourage.

On the other hand, after seeing quite a few videos on 3.2, I don’t see the appeal… I will just copy over a few bug fixed commands and new shell v47 (which hopefully fixes some annoying bugs) and let the rest be - too much pointless nonsense and cluttery.

And here I could start a long rant, but I will save that for later - one thing I will mention though - they have killed the Amiga tick - one can no longer tick off items in menus, as ticks are now replaced with dots (or boingballs?)

[kolla]

Menu checkmarks have nothing to do with the Amiga tick; any resemblance between them is coincidental.

That is simply not true, the paradigm here is a workbench, with drawers, tools, projects etc. and the notes hanging there with checkmarked items - that’s where the checkmark comes from in the first place.

Checkmarks are used for togglable menu items, and dots (not boing balls :-D ) are used for mutually exclusive items, which is pretty standard on most OSes.

Well, ironically, macOS holds the tortch and keeps using checkmark ticks everywhere without anyone complaining or getting confused. I don’t know what your list of OSes is, but I suspect it is rather limited. Again mimicking Windows.

On that topic, how is max size of windows now? Still limited by screensize, because… Windows?

[kolla]

I may just as well go on…

Workbench…
Wtf has been done to Windows menu? It looks crowded, but nothing is added or removed… just moved around, screwing around with muscle memory of users?
When is “open volume” needed as menu entry? The icon is right there on the workbench… (the only usecase I can think of is if volume is marked as “hidden” in workbench prefs, but then… I am almost betting on it not being available in the menu either.)
As someone who has been dynamically altering menus since workbench got an arexx port… dynamic menu entries are annoyingly slow… how is that list of volumes holding up with changes?

Does any of the possibly relevant menu entries relocate icons on Workbench to their original positions yet?

In IControl (Intuition prefs, really) it is still not possible to set a windows equivalent to the screen dragging hotkey… sad.

(time to go to bed)

[kolla]

@kolla:

They are two different things: one is the menu equivalent of a checkbox, and the other is the menu equivalent of a radio button.  So it makes sense to distinguish them

No, it doesn't make much sense, noone ever struggled to distinguish these for more than 30 years - hopefully people can still READ!

this is done not just by Windows but by OS4.

Unimpressive list when you say "most operating systems".

There are plenty of bad interface designs in MacOS and no reason to blindly make the same mistakes.

Right, much better to blindly follow the mistakes done in Windows - the list is growing for every release.

And I ask again - is the max-window-size limitation still there in Intiution.library v47? You know, the limitation only found on Windows? Not even OS4 has this limitation...

This is for Amigas not Macs.

You mean this is for Windows users who gets confused by the Amiga paradigm, and who rather see Amiga change into something more Windows-like? So you end up doing the same mistakes as just about every "linux desktop", instead of having a distinct UX for this platform, you end up with a sorry excuse for a "look-alike" that is neither one or the other. What's next - ctrl+c/v as shortcut for "copy" and "paste"?

[kolla]

You do know that Commodore's idea (93) to use checkmarks and bullets in the menu like that predates Windows 95 - so this is actually an original Amiga concept.

Who said anything about Windows 95? Anyways OS 3.1 was released post 1993 without "radio buttons" in the menus.

(and personally I never saw the point of radio buttons, we have cycle menus (and cycle to menu) for that)

As for windows larger than screen I can only take it that you want to break every program out there that assumes this can happen. Like console and probably a lot of other programs. So while in you infinite wisdom you may think it should just be done, there are actually well thought out reasons why it would be a really bad idea. And in practice not that many people will even find it useful anyway.

I suppose that is why it is working just fine in OS4?

Seriously - when I first complained about this, Thomas said it was due to the possibility to somehow "move" windows into a position where no gadgets would be available to move it back or resize - there was ZERO explaination to how this could possibly happen, but arguing against dogma is pointless. When pointing out that OS4 manages just fine and resize windows larger than screen without any trouble, the "clarification" was that OS4 has the option to resize windows from all directions - well, now OS3 has the same, and yet here we are. And now there is a new excuse "break every program out there" - excuse me, but wtf what? Why don't those programs break on OS4 then?

[kolla]

The use case is quite obvious - you mention console, sometimes output (and for that matter, input) is longer than console window is wide - especially when workbench screen is 640 pixels wide, and that in particular is when I - ad hoc - wish to make the console window larger than screen. In general I don’t see the point in moving windows off screen if it’s not possible to make windows larger than screen.

So when do one wish for wider consoles?
When dealing with long filenames and file comments for example.

As for radio buttons - so Windows 95 was first version of Windows with what… “radio buttons” in the menus? And Win 3.x and earlier used what… checkmarks?

[kolla]

So make the screen wider with Autoscroll enabled?

Cannot be done without closing and reopening Workbench screen - the point here is that this is a need that pops up and the limitation is super annoying.

[kolla]

I do see your use case, but it seems to me to be a rather cumbersome solution, you would then have to move the window around. to see it

Of course it is a little cumbersome, but it is easier than just about anything else.

Dreaming out loud as we are - wouldn't it be better if the console had unlimited length lines and a horizontal scroll bar. It could be a mode you could turn on and off as your need arose

How about fixing a _vertical_ scroll bar first, probably much more sought after.

Anyways, this (both vertical and horitzontal bars) already exists in ViNCEd, and you can even have it on first CLI if you use the Con-handler shin^hm (sic), just don't use the shim with 68000 (guru 8000 0003 if Workbench is loaded), at least not with 3.1.4 (no idea about 3.2, I don't have it, unsure if I will - depends on the license it ships with). But - scrolling text in console is a heck lot slower than flipping an oversized window back and forth. Then it's really better to find some font that is readable at sise 6 and use SetFont to set it ad-hoc.

Btw, going from "I can only take it that you want to break every program out there" to "I don't know - i just know console will fail" is quite a ... step.

[kolla]

just don't use the shim with 68000 (guru 8000 0003 if Workbench is loaded)

At last fixed in 3.100 or 42.100 or whatever he prefers… though it still prevents SetPatch from patching copyright notice, boot with 3.1.4 kickstart and 3.1.4.1 setpatch and Hyperion pwns 2019, load the ViNCEd Con-handler “shin”(sic) and Hyperion only pwnz 2018 again. Bug reported a very long time ago, but only triggered a rather irrelevant kneejerk rant from “Der Richter” and no fix. Perhaps whoever managed to convince him about the 68000 bug (kudos btw) could also pass this one on, it looks bad that Hyperion only pwnz 2018 when they should pwn 2019, just because of Con-handler. And who knows what else SetPatch may fail to patch due to this, I have not explored, and my asbesto suit is getting thin when it comes to reporting bugs.

[kolla]

Some of us have grown VERY used to having icon.library coming from PeterK's IconLib 46.4 - with 3.1.4(.1) it works great still, but with 3.2 there are problems, the main one being due to version strings apparently. 3.2 uses 47 as major version for its icon.library, opposed to 3.1.4 which uses 45. To work around various trouble with AROS/AfA (from what I recall), the true color "TC020" variant of IconLib 46.4 is major version 51. The end result though, is that whatever in OS 3.2 that is loading icon.library (workbench.library v47 I presume) fails to load PeterK's icon.library if it is a 46.4.xxx variant, but still manages to load those that are 51.4.xxx, I suppose from the assumption that 46 <47 < 51 - so if your system is 020+ you can use for example the TC020 library, but if you're on 68000, you cannot use IconLib 46.4 anymore (unless you patch it to become for example 47.4.xxx instead of 46.4.xxx). Sad sad sad.

But why would anyone on a 68000 use IconLib 46.4 in the first place? Well, first and foremost - SPEED - on slow systems you can really tell the difference - maybe magic has been applied to icon.library v47 to make it super fast as well, but I doubt it. And secondly - all the "helper" programs - some for "cosmetics" others for work-arounds in both software and hardware. I have grown used to having outlines and shadows on my workbench icons, does at least 3.2 offer this?

I find it a bit strange that there seems to be NOTHING in the OS 3.2 FAQ about IconLib 46.4, as it this is a version of icon.library that has been more or less dominating for many years now, and included in the oh so perfectly legal 3.9 boingbags 3+4 of certain official OS 3.2 wingmen.

For sake of entertainment, I attach a screenshot showing shadowed icon text, the most awesome Amiga icon style, and also showing how Hyperion only pwnz 2018 when Con-handler is loaded (yes, version 106.2 - CLEARLY this little piece of software has been under development since the 70s to reach such a high major version!)

(oh, and there is bug or ...eh... feature challenges with "Prompt" - as you may tell from the screenshot, I use a multi-line prompt (which probably just works by pure coincident, and not by design), and the "bug" is that variable expansion in prompts only work on the first line. In the 3.2 FAQ, the word "prompt" is only mentioned once, and not at all in relation to the shell or C:Prompt, so whether this is known bug/feature or not, I cannot tell)

[kolla]

If those APi changes is (the what… 4th? incarnation of) DefIcons, I don’t really care much about it (roll my own) and will just alter 46.4, I got the source. But others may vert well stumble on this awkwardness and so it should go into the FAQ.

[kolla]

the inconsistency of text/string UI elements across the system is... unfortunate.

I am not surprised by this ReAction.

[kolla]

just don't use the shim with 68000 (guru 8000 0003 if Workbench is loaded)

At last fixed in 3.100 or 42.100 or whatever he prefers… though it still prevents SetPatch from patching copyright notice, boot with 3.1.4 kickstart and 3.1.4.1 setpatch and Hyperion pwns 2019, load the ViNCEd Con-handler “shin”(sic) and Hyperion only pwnz 2018 again. Bug reported a very long time ago, but only triggered a rather irrelevant kneejerk rant from “Der Richter” and no fix. Perhaps whoever managed to convince him about the 68000 bug (kudos btw) could also pass this one on, it looks bad that Hyperion only pwnz 2018 when they should pwn 2019, just because of Con-handler. And who knows what else SetPatch may fail to patch due to this, I have not explored, and my asbesto suit is getting thin when it comes to reporting bugs.

This problem also fixed now, in 3.101 or 42.101 - http://aminet.net/package/util/shell/ViNCEd

Changes made for 3.101:

   ViNCEd now delays loading the icon and workbench libraries, and
   only opens them when they are already in memory. This avoids
   conflicts during early startup if only one of the libraries is replaced
   by LoadModule. While this is potentially a user error, it may be
   helpful to be conservative. ViNCEd now re-attempts to open the
   libraries as soon as the preferences become available, i.e. whenever
   ENV: is created and filled.

Yes - "potentially a user error" is to use the OS version actually released, and not "between releases" OS installed on hard drive of the developer - shame on me

Anyways, kudos again for acting as der Richter-Filter!

[kolla]

No, it doesn't make much sense, noone ever struggled to distinguish these for more than 30 years - hopefully people can still READ!

No, most people don't read manuals. Most developers had to learn this the hard way.

What I meant was reading THE MENUS - hopefully no documentation should be needed to do that, heh.

Things have progressed since 1985 - GUIs are supposed to be self-explaining, albeit this presents an ongoing and sometimes impossible challenge, given the technical restrictions. Radio buttons are a well established paradigm for mutual-exclusive choices in AmigaOS since 1990, so it makes sense to extend it to menus as well.

Not really, we had cycle gadgets and cycle-to-menu - those have been using checkmarks. What do they use now?

Radio buttons can die, they are mostly redundant and just take a lot of space.

The rest has been said.

Are "hidden" volumes (wb prefs) possible to open via the "open volume" in Workbench menu? I haven't seen an answer to that.

C'mon, you must have detected more serious flaws. Even we did.

I don't have 3.2, I comment from what I see people fumble around with on youtube videos. But I understand that shell is almost just as broken as it was with 3.1.4 again in regards to FailAt levels and whatnot... even ThoR isn't using OS 3.2 release shell? So the question is now - how will Amiga Shell be maintaned from here, and how will updates be published? I __VERY MUCH__ preferred it when Thomas lumped updates to Aminet.