@OlafS25

Quote:

it was never planned to be updated to 4.X

I know that, of course. This is why I expressed my surprise at someone mentioning "the lack of OS4 features in OS3.1.4"

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Trixie

Quote:

Trixie wrote: @matthey [quote]...20+ years of OS4 development...

nearly shat myself when I read that...

@Trixie

Quote:

This is why I expressed my surprise at someone mentioning "the lack of OS4 features in OS3.1.4

I interpreted that comment as follows:

Hyperion could claim that their intention is to upgrade 68k users to OS4, and the OS4 link is then an argument in favour of the legality of 3.1.4 . But the fact that there is a clear lack of OS4 features in 3.1.4. would be a problem for that argument, if they were to make it.

I don't believe he was expressing an expectation that OS4 features *should* have appeared in 3.1.4. He was just making reference to a hypothetical legal argument. That's how I interpreted it, anyway.

Last edited by BrianHoskins on 07-Feb-2019 at 04:48 PM.

@BrianHoskins
Your interpretation of my comment is correct and well said.

Quote:

Trixie wrote: Did anyone really expect the 20+ years of OS4 development to miraculously appear in an OS3 upgrade done basically by two people? That would be really naive.

I didn't really expect much from Hyperion at all. Sure, there were primarily 2 AmigaOS 3.1.4 developers who weren't getting paid but they had to waste time creating a new GUI for some prefs to use GadTools instead of Reaction which could have been used from AmigaOS 4. The intuition.library was already being upgraded which would have made the work easier. Instead, AmigaOS 3.1.4 moved backward from AmigaOS 3.5+ instead of having a standard scalable and font sensitive Reaction GUI. The extra wasted work is reminiscent of the wasted work of developers trying to support AmigaOS 3 and AmigaOS 4 (NetSurf developers for example). I'm not blaming the developers who did a miraculous amount of work given the situation. There is no excuse for Hyperion who were unprofessional in their support of AmigaOS 3.1.4 while taking more out of the project than they put in.

Last edited by matthey on 07-Feb-2019 at 05:09 PM.

My main motivation for buying OS 3.1.4 was iPrefs with support for v45 Workbench prefs and ASL prefs on 68000. Getting rid of Reaction was a bonus.

Last edited by kolla on 07-Feb-2019 at 07:33 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: My main motivation for buying OS 3.1.4 was iPrefs with support for v45 Workbench prefs and ASL prefs on 68000. Getting rid of Reaction was a bonus.

GadTools is so primitive. Text, gadgets and visuals in windows can end up getting clipped at the edges and may become unaccessible. This is more likely with longer texts in non-English languages and with lower resolutions. A font sensitive and scalable GUI can change the spacing and even switch to a smaller font to avoid elements being clipped. There is some calculation overhead in this but it is not much and generally worth it. The 68k AmigaOS should not be held back by the 68000, 512kiB of memory and single floppy drive specs. I would like to see the AmigaOS shrink but removing functionality and features is not the way to do it. Separate compiles for 68000 and 68020+ should help some. Optimized code for the 16 bit 68000 is very different than for the 32 bit 68020-68060.

@matthey

Quote:

GadTools is so primitive. Text, gadgets and visuals in windows can end up getting clipped at the edges and may become unaccessible. This is more likely with longer texts in non-English languages and with lower resolutions.

I use OS 3.1.4 on low resolution with non-English language setting, I know all about this - and they are non-issues.

The change I would like to see, is that font used for screenbar/menus and window titles should be separate from those used by GadTools.

Quote:

The 68k AmigaOS should not be held back by the 68000, 512kiB of memory and single floppy drive specs.

My 68000 systems are running at 40-50MHz and have 3.5-8MB of RAM - why should my systems be held back by silly choices made by OS developers?

How much of OS 3.9 essentials do you think _really_ requires 68020? As someone who have stripped OS3.9 down to work on 68000 systems, I can tell you - not bloody much!

Quote:

I would like to see the AmigaOS shrink but removing functionality and features is not the way to do it. Separate compiles for 68000 and 68020+ should help some. Optimized code for the 16 bit 68000 is very different than for the 32 bit 68020-68060.

Sure, whatever - just be sure to keep 68000 support, as that is the only 68k chip you can reliably count on existing for all foreseeable future.

Last edited by kolla on 07-Feb-2019 at 08:55 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: I use OS 3.1.4 on low resolution with non-English language setting, I know all about this - and they are non-issues. The change I would like to see, is that font used for screenbar/menus and window titles should be separate from those used by GadTools.

GadTools was not designed to be flexible or configurable. It is a poorly thought out GUI with many limitations.

GadTools advantages
simple
easy to use

Reaction advantages
scalable
font sensitive
flexible
configurable
modular and extendable
object oriented and BOOPSI compatible
easy to use

Quote:

My 68000 systems are running at 40-50MHz and have 3.5-8MB of RAM - why should my systems be held back by silly choices made by OS developers?

Maybe because the system designers made a silly choice to only add support for a 16 bit CPU from 1979?

Quote:

How much of OS 3.9 essentials do you think _really_ requires 68020? As someone who have stripped OS3.9 down to work on 68000 systems, I can tell you - not bloody much!

I am aware that many of the AmigaOS 3.9 modules were not compiled for the 68020+ even though the minimum requirement was for a 68020. It is unfortunate as there was room on the CD for both 68000 and 68020+ optimized modules.

Quote:

Sure, whatever - just be sure to keep 68000 support, as that is the only 68k chip you can reliably count on existing for all foreseeable future.

There are enough 68020 compatible open cores that work in a cheap FPGA that 68020 simulation is not a problem. These are possible in hardware competitive in price with the Raspberry Pi but not offering as much value due to the lack of performance (68030 level of performance).

@matthey

Quote:

There are enough 68020 compatible open cores that work in a cheap FPGA that 68020 simulation is not a problem.

That does not help existing 68000 systems, of which there are plenty.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

I also just want to say that Gadtools is not a GUI, it is a toolkit to build GUIs. With OS 3.5, a quick and easy choice was made, instead of improving Gadtools, ClassAct was chosen to quickly fill the gap. Instead of being a temporary quick fix, it has become a legacy problem in itself. And all the developers of ClassAct/Reaction (caldi, newlook etc) are long gone. I much rather see Gadtools improved, and extended in a way that integrates with the rest of the OS, rather than existing as a "packagage" slapped ontop of what is. Likewise, look at all the prefs programs, how many of them should really be merged? Instead of adding and adding, focus should be on improving what already exists.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

And more on prefs... If I was king, I'd rather have a iprefs.library with an API to access all supported prefs settings, and let people build prefs GUIs using whatever toolkit they wish, or just by passing off values through ARexx.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Talking of prefs the workbench pattern prefs in 3.1.4 is crap no options for tiled or streach or fill. Os3.1.5 lol

Last edited by g01df1sh on 08-Feb-2019 at 12:30 AM.

_________________
A1200 ACA1232 128MB Indivison MkIICr
Elbox empty Power Tower
RPi3 Emulating C64 ZX Atari PS BBC
Wii with Amiga emulation
Vampire v4 SA

Not many people realize Cloanto includes OS 3.X in AmigaForever…
They went out of their way to secure most of the rights to the 3.5/3.9 upgrades and added a few more things. Hence the version bump to 3.10(aka 3.X)...since 4.0 was already taken.

Anyway...

Now they they seemingly have ALL the rights to 3.1+, let's hope they restart development and upgrade Exec now that they'll have legal access to the source code.


Might as well drop the 3. from the version and just call it OS X
Then we can all be on the 10/X version...

@g01df1sh

WBPattern should anyways be merged with Workbench prefs.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Gadtools is not a GUI, it is a toolkit to build GUIs. With OS 3.5, a quick and easy choice was made, instead of improving Gadtools, ClassAct was chosen to quickly fill the gap. Instead of being a temporary quick fix, it has become a legacy problem in itself.

Sorry but you are jumping to conclusions while being misinformed here.

In OS2.x, Commodore introduced two GUI toolkits - GadTools and BOOPSI - as alternatives to replace the horrible 1.x GUI programming API. As the inherent limitations of GadTools soon became apparent and BOOPSI received some important additions in OS3.x, it was foreseen that the future Amiga GUI programming API would be based on BOOPSI, the object-oriented and extendable nature of which lends itself well for the task. Commodore's plans were clearly presented in Martin Teileffer's paper for the 1992 Orlando developer conference, which is available on the Amiga Developer CD2.1 for your reference. Unfortunately, as we all know, Commodore didn't have the time to have their plans materialized.

So when Haage&Partner started developing OS3.5, ClassAct (renamed ReAction) was a natural choice: it had a reasonably big class set, it was available for licensing, and it was based on BOOPSI, which Commodore were going for. Saying that GadTools should have been improved instead is a barmy idea. GadTools was a false start and an inherently bad design - and even back in Commodore times they knew they'd be flogging a dead horse.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

Quote:

kolla wrote: I also just want to say that Gadtools is not a GUI, it is a toolkit to build GUIs. With OS 3.5, a quick and easy choice was made, instead of improving Gadtools, ClassAct was chosen to quickly fill the gap. Instead of being a temporary quick fix, it has become a legacy problem in itself.

Trixie is correct. GadTools was being replaced long before AmigaOS 3.5 and GadTools is the legacy problem. The following are the start of the notes from the '93 DevCon.

Quote:

GadTools Objects Although GadTools provides the framework needed to support our UI look, its many inherent limitations often become problems that application writers have to work around: o No Relativity GadTools objects don't support any form of positioning relativity, making them difficult to use in sizable windows. o Not Extensible GadTools objects do not support inheritance, making them impossible to extend from within an application. You get what you get, nothing more. o Not Changeable Once a GadTools object is created, it is impossible to change many ot its static attributes such as its label or font. The only way of accomplishing these tasks is to remove all gadgets from the window and recreate them from scratch. o Not Connectable GadTools objects do not support any form of object interconnections. This prevents the creation of "self-driven" user interfaces, where the application merely sets things up, and lets the UI objects do all the work by themselves. BOOPSI objects have none of the problems denoted above. They are as easy to use and access as GadTools objects are, and quite a bit more flexible. With this in mind, the obvious course to follow is to create a series of BOOPSI classes that parallel in functionality the existing GadTools objects. The new objects would not have the old problems and would add missing functionality along the way. Once the new classes are in place, GadTools can become one of their clients. The main reason behind this move would be to reduce the amount of redundant code in ROM. It also guarantees that the new classes provide all of GadTools' functionality, in a compatible and consistent manner.

https://archive.org/stream/International_Amiga_Developers_Conference_Notes_1993_Commodore/International_Amiga_Developers_Conference_Notes_1993_Commodore_djvu.txt

Quote:

And all the developers of ClassAct/Reaction (caldi, newlook etc) are long gone.

All the original developers of AmigaOS are long gone (most are alive but they don't work for free). Even Olsen is not one of the original AmigaOS developers. By your logic we should ditch the AmigaOS too. Also, AmigaOS 4 substantially improved Reaction.

Christopher Aldi came back to our room (the Amiga embedded guys) and hung out with us after a Gateway show back in the '90s. He is another really cool easy going guy. He was young at the time so I expect he is still around.

Quote:

I much rather see Gadtools improved, and extended in a way that integrates with the rest of the OS, rather than existing as a "package" slapped ontop of what is. Likewise, look at all the prefs programs, how many of them should really be merged? Instead of adding and adding, focus should be on improving what already exists.

GadTools should have never existed. Instead, more time should have been spent upgrading BOOPSI. Even the builtin classes (attached to and started in intuition.library) were Spartan and lack of sub classes often made BOOPSI more difficult to use than GadTools. AmigaOS 4 made some improvements to the builtin BOOPSI classes. Reaction gave the sub classes that were missing and AmigaOS 4 improved on them. The AmigaOS 3.9 Reaction has less functionality and more bugs in comparison. The difference can be seen in NetSurf for AmigaOS 3 vs AmigaOS 4. Chris Young introduced kludges and disabled parts of the GUI to keep it working but it looks ugly and wastes his time. A good example of a bug is the tag GA_RelBottom not working for the frbuttonclass. The gadget fails to attach to the bottom border of a window. This BOOPSI bug in AmigaOS 3 has probably been around for 25 years. Olsen may have fixed the bug with the new AmigaOS 3.1.4 intuition.library but now Reaction is missing for NetSurf. Why does Amiga make everything so hard and "unfriendly"? Only Amiga makes it impossible.

Last edited by matthey on 08-Feb-2019 at 03:36 PM.

@matthey

Quote:

I didn't really expect much from Hyperion at all. Sure, there were primarily 2 AmigaOS 3.1.4 developers who weren't getting paid but they had to waste time creating a new GUI for some prefs to use GadTools instead of Reaction which could have been used from AmigaOS 4.

The problem with that is that OS3.1.4 builds on OS3.1 and is close to it. Using Reaction would have made it too complicated and needed backporting for all other system programs. Here's a case in point, try and run any Prefs program from an OS3.9 boot shell and it doesn't work. It is unable to load up the GUI. One thing I hate about OS3.9 when I need to fix a breakage in the boot shell. OS3.1 is better in this regard as Prefs programs run from a boot shell.

Quote:

GadTools is so primitive. Text, gadgets and visuals in windows can end up getting clipped at the edges and may become unaccessible. This is more likely with longer texts in non-English languages and with lower resolutions. A font sensitive and scalable GUI can change the spacing and even switch to a smaller font to avoid elements being clipped.

GadTools builds on top of Intuition. But provides a standard look and slightly easier way of creating new gadgets. And menus. However GadTools is font sensitive and does support a scalable GUI. The catch is it lacks a layout engine. I think this would have made a difference if they built one in. It can be told what font to use, it isn't locked to Topaz 8 like some programmers were. And for resizing the programmer needs to rebuild the interface by hand. It can be done.

Quote:

Hypex wrote: The problem with that is that OS3.1.4 builds on OS3.1 and is close to it. Using Reaction would have made it too complicated and needed backporting for all other system programs. Here's a case in point, try and run any Prefs program from an OS3.9 boot shell and it doesn't work. It is unable to load up the GUI. One thing I hate about OS3.9 when I need to fix a breakage in the boot shell. OS3.1 is better in this regard as Prefs programs run from a boot shell.

AmigaOS 3.5 introduced the resource.library which is poorly documented. I'm not sure what is going on there. Reaction/ClassAct is very simple and easy to install though. The classes are regular Amiga libraries which go in SYS:Classes. After installation, the only assign necessary is the normal AmigaOS 3.x S:Startup-Sequence assign which is also necessary before using DataTypes.

Assign LIBS: Sys:Classes ADD

This was adequate with ClassAct but AmigaOS 3.5 and 3.9 added the resource.library for some reason. ClassAct also included both 68000 and 68020 optimized versions of the classes. AmigaOS 3.5 and 3.9 could have been better but ClassAct/Reaction is implemented in about as simple a way as possible while remaining modular.

Quote:

GadTools builds on top of Intuition. But provides a standard look and slightly easier way of creating new gadgets. And menus. However GadTools is font sensitive and does support a scalable GUI. The catch is it lacks a layout engine. I think this would have made a difference if they built one in. It can be told what font to use, it isn't locked to Topaz 8 like some programmers were. And for resizing the programmer needs to rebuild the interface by hand. It can be done.

By scalable I mean relative objects in resizable windows. GadTools is severely lacking here. GadTools does some primitive font sensitive adjusting but without relative objects it is quite poor. The GadTools menu system isn't too bad but should have been replaced with a BOOPSI menu system which I believe AmigaOS 4 did. Unfortunately, Hyperion kept updating the unprofitable market while they left the larger profitable market behind. Hyperion deserves the Darwin Award in business which may be coming soon.

Last edited by matthey on 08-Feb-2019 at 06:38 PM.
Last edited by matthey on 08-Feb-2019 at 06:34 PM.
Last edited by matthey on 08-Feb-2019 at 06:22 PM.
Last edited by matthey on 08-Feb-2019 at 06:20 PM.

Quote:

matthey wrote: Hyperion kept updating the unprofitable market while they left the larger profitable market behind. Only Amiga makes it impossible.

Yes, they left the profitable market behind because they were only allowed to operate in the unprofitable market. Amiga (Inc) made it impossible, or rather that settlement agreement did, until it became too tempting (or necessary) to interpret the agreement in a different way.

Quote:

hth313 wrote: Yes, they left the profitable market behind because they were only allowed to operate in the unprofitable market. Amiga (Inc) made it impossible, or rather that settlement agreement did, until it became too tempting (or necessary) to interpret the agreement in a different way.

If Hyperion had shared instead of being greedy, they might have a brighter future now. Instead, it looks like they became desperate as they neared bankruptcy and rolled the dice.