Os 3.2 development preview

[Gulliver]

Cool! When is 3.2 supposed to be released?

We have no date for it.

It is currently in development, and development depends on our free time which varies a lot on an individual basis. So it is really hard to estimate.

[Gulliver]

Will this allow the use of environment variables in the Workbench title?

That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.

It looks like the titlebar variable feature is backported from OS4. If I recall, one of the optional variables is the system time, so a clock should be possible, although I don't have my OS4 machine in front of me to check. Personally, I use DOpus4 in window-iconified mode to provide a clock on my systems.

This does tie into a related discussion about how to add more complex functionality to the titlebar. Perhaps a new API is in order, similar to MorphOS's screenbar modules, although maybe that's a discussion for Release 3.3 or later.

Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.

Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.

[Gulliver]

Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.

Interesting, thanks for that clarification. Even if the variable isn't present in the library, this feature does at least offer the possibility of a workaround - if another program can spit out the time to ENV:currenttime couldn't you pull it from there?

Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.

Oh yeah, very much aware of that, and very grateful for the time you guys are able to put in!

Current implementation of the title bar feature is extremely recent, so it is still under construction and all of its features cannot be fully tested at the moment.

But yes, enviroment variables are usable and you should be able to perform all kind of cool tricks with them, including the one you mention.

[Gulliver]

Will there be any different hardware requirements for 3.2?

For the moment, 3.2 hardware requirements are much the same as 3.1.4. But this could change with the inclusion of ReAction.

Only time will tell for sure. It is too early to give you a definitve answer on this.

[Gulliver]

@Matt_H

I see your point, but then again it is too early to start worrying about this. We still need to properly test ReAction, class by class, then we need to assemble and SDK for it, and then we will probably see if we start converting and porting programs to it.

So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

In this way you would be able to choose you poison. ;-)

[Gulliver]

That would make me happy to be able to choose (I might even want ReAction on one of my higher-spec machines), but then on the developer end you would need to maintain two versions of the code! 

Well, the choice is simple in the transitional OS release between the two GUI Toolkits.

After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).

But that is a desition that will not be taken anytime soon.

[Gulliver]

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square

The other day, we were discussing how the default OS installation should be, and I was mentioning the fact that our userbase is not getting any younger and that we should probably need to use bigger fonts.   

[Gulliver]

I believe Workbench needs a lot of improvement from its usability point of view. And you only coved the tip of the iceberg. It lacks so many things...

Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

The problem is that Workbench is so much behind that it will require a lot of manpower to get to a reasonable state where we can see it as a friendly partner within AmigaOS.

So dont't expect those changes will come out in the short term. Hopefully some small incremental changes may start to appear.

[Gulliver]

@Pgovotsos

The functionality does not need to get in the way of users, but be available as an extra when required. Following the AmigaOS principle of "power beneath the hood".   

AmigaDOS and ARexx mostly work the same way, you can use the bare minimum, and maybe not even touch them, but if you require to do more advanced stuff, they are already there, sitting in the dark, not getting in the way. 

Have you used ScalOS as a workbench replacement? DOpus Magellan? They can behave and look excactly the same as good old workbench, but are highly configurable to deliver much more advanced functions for power users that require those. They have many flaws in their implementation, but the general concept behind them is good.

Anyway, as said before, this is not something that is going to be happening anytime soon, as there are a lot of other things which have higher priority, and even then, when the time comes, such things will need to be properly discussed and evaluated.

[Gulliver]

Can you or Thomas could give us some insight what actually is planned in this release?

As for the planned things, I reserve that right Thomas, since he is the lead developer.

As for things currently implemented (of course, still being worked on), I can safely transcribe the whitepaper I am writing, since Hyperion already displayed it:

AmigaOS 3.2
---------------

Based on the stability, bug fixes and progress cemented with
AmigaOS 3.1.4 (and its update 3.1.4.1), we decided to put our efforts
towards the same successful path, but this time focusing on
implementing new features, in this new AmigaOS 3.2 release.

In part, based on the user feedback and the support received, besides
the usual continued delivery of bug fixes that improve overall
stability, we added the following new features to AmigaOS 3.2:

1. The Shell

Shell now has the ability to have a partial name of a program or path
autocompleted using the TAB key.

We have a new shell built-in command called "history" that lists the
contents of the Shell history buffer with the help of the cursor keys.

We also added the && operator that first executes the first command,
and if this fails, it aborts. If not, it executes the second command.

Error handling has been improved. We have a functional stderr. So we
can specifically redirect error streams when using the shell.

There is now also a way to debug commands being executed from the
shell by using the serial port.

The bootmenu got two new checkmark options that reflect on the
behaviour of the shell, and make its advanced options much more simple
to use.

2. The User Interface

The ReAction GUI toolkit does a successful comeback, but now with
extended functionality and an array of bug fixes never seen before.

Due to popular demand, the new intuition.library that allows you to
move windows out of the screen is now built-in by default, that said,
we added an optional fall-back method for those who still use the
unmaintained CyberGraphX RTG system.

Intuition has the ability to allow windows to be iconified and hidden
and this has been implemented in Workbench programs. An iconification
gadget will be visible to the left of the zoom gadget for this purpose.

You can find scalable gadtools GUIs in most of the Workbench programs.
This means that they have become font sensitive, and properly adjust
to different font sizes. So you are no longer forced to use the default
topaz font on them anymore.

3. Preferences

IControl now toggles on/off the out of the screen window dragging
abilities of the newly built-in intuition.library.

Printer prefs allows the user to enter a custom output device for
the printer and select a unit number.

WBPattern has been updated to provide layout options to scale, tile,
interpolate, and center backgrounds if a picture is selected for it.

Workbench prefs enables you to customise the text present in the
title bar on the Workbench screen.

4. Tools, Utilities and System applications

Mounter is an interactive partition mount tool that operates on
devices that support the RDB (Rigid Disk Block) data structures.

DefIcons is a program that attempts to identify different file types
and depending on its own configuration, it will apply a default icon
with an associated action to each of them.

5. Miscellaneous

The RAM-Disk now supports "external hardlinks" and its purpose is
to integrate env-handling features into RAM, and avoid unnecessary
copying of files. This saves memory and makes the system boot
marginally faster.

We now have a new rom module called "system-startup". Its job is
to make rom updates easier and alleviate LoadModule from some of its
work by loading system components from disk, replacing many ROM ones.

We also cleanly re-implemented the AssignWedge patch that extends the
standard AmigaDOS volume request ("Please insert volume ...") with
additional features that allow the user to create an Assign or
permanently deny the requested volume until next reboot.

The datatype system has been improved: there is a new BMP datatype
that manages Windows/OS2 bitmap images, and an improved text datatype
with search functionality built-in. 

Input.device can now properly manage multiple input events
appropriately, and this essentially means better support for USB
solutions that are aware of this.

You will also find several fixes, optimizations and updates that cover
nearly all AmigaOS components, and a few other minor features that are
properly addressed in our FAQ.

[Gulliver]

Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?

The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.

I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.

If it sounds a bit vague to you, then I will change the wording so that I avoid any confusion.

Thanks

[Gulliver]

More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?

I have been continuously writing and improving a FAQ for 3.2 since 11 months by now.

And it is still getting more content, as questions are asked and features are added.

The FAQ will be publicly available when AmigaOS 3.2 gets ready for release.

[Gulliver]

Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.

The 3.1.4.1 FAQ on Aminet covers everything new. Old stuff should be covered by the good old 3.1 manual except some specific topics.

I am writing the current AmigaOS 3.2 FAQ, which is the nearest thing to a manual. It currently covers more than 100 topics.

I could certainly write a book about 3.2, but it would unfortunately take me about six months. And I am not so sure there is a market for it, or even worth spending my time on it.

[Gulliver]

Sorry if this has been asked, is there a list of features for this release?

https://forum.amiga.org/index.php?topic=74270.msg845770#msg845770

Be warned that the list is now outdated.
3.2 now has even more features than those mentioned.

[Gulliver]

Is that the same "hack" which is enabled in the OS4 Classic port by creating a Kickstart module called AtapiIsMajik (or something like that)?

Best regards,

Niels

..."ATAPIismajik 52.1 (7.8.2007)

The OS4 motherboard IDE scsi.device driver can handle IDE drives
which are attached to the single motherboard IDE port (unit 0 for
the master drive, unit 1 for the slave drive).

The OS4 IDE scsi.device can also handle IDE drives which are attached
to the second IDE port when IDE port doubler hardware is installed
(unit 2 for the master drive on the second IDE port, unit 3 for the
slave drive on the second IDE port).

The following IDE port doubler hardware is automatically detected:
- Elbox EIDE99

The following IDE port doubler hardware is NOT automatically detected:
- IDEFix
- IDEFix97
- IDEFix Express

Currently there exists no known method to autodetect the IDEFix group
of IDE port doublers, its necessary that you specify if such hardware
is present."...