Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 136253 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Matt_H

Re: Os 3.2 development preview
« on: August 29, 2019, 04:34:50 AM »
Is the default Rexx: assign now SYS:Rexx instead of S:? I’ve been doing that manually on my systems for years! :)

The standard iconify gadget and Printer prefs output device are great additions. Personally, I’d prefer that ReAction not become part of the OS, or at least not as a replacement for GadTools as with the standard system utilities in 3.5+.

I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?

Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #1 on: August 29, 2019, 03:15:25 PM »
I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?
Yup. The 3.1 prefs and GUIs in general were never font sensitive. Hardcoded topaz.8.
Yeah, just went back and confirmed on a 3.1 system. Funny, I could have sworn there was an OS release from C= that was font-sensitive. Must have been mixing it up with a later version. At any rate, thanks for finally making this happen!
« Last Edit: August 29, 2019, 03:20:11 PM by Matt_H »
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #2 on: August 29, 2019, 03:32:58 PM »
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.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #3 on: August 29, 2019, 04:18:41 PM »
All sorts of fun speculating in this thread!

I'm curious about the new GUIDES: assign. My first thought was that it was a new system-wide AmigaGuide-based help feature, but then wondered why that wouldn't have just been part of HELP:. Would like to know more :)

And based on the backdrop it looks like image tiling has returned to WBPattern prefs.

Another feature request: an official prefs editor for the WB Tools menu whose settings can be read by workbench.library/LoadWB directly (so that an additional tool in WBStartup isn't necessary).
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #4 on: August 29, 2019, 07:43:20 PM »
Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?

Yes, more BOOPSI please. Greatly preferred over ReAction.
On that same line, Commodore also had two packages of v42 datatypes that never made it into the OS. Granted, they're for formats now largely obsolete, but it would be nice to fold them back into the official source tree.

I'm looking at the uncompleted features originally planned for 3.1 and wondering how many have not already been addressed in 3.1.4 that would still make sense to complete. There's label.image and a new cycle.gadget on the BOOPSI front that never made it out of Commodore HQ. The 1993 DevCon notes also detail planned directions for the UI, of which those BOOPSI classes were the beginning. Would it make sense to continue down that path?

Quote
Most of todays users need:
Networking to exchange files with the internet and their PCs. (a big project)
Possibly not as big as you think. I've been an advocate of Commodore's Envoy for years, which is an extremely lightweight and extremely Amiga-like way to do LAN filesharing. If the devs could acquire Envoy and extend it with a hypothetical smb.service, that would allow filesharing from PCs much more easily than the current challenge of setting up an obsolete/incompatible Samba server.
Quote
Built in lha and zip support to handle file archives once transfered.
3.5+ did this with Unarc and XAD, but I'm wondering if there's a more lightweight way to do this without reinventing the wheel.
Quote
Easy GUI methods to launch favorite applications/games/demos.
Other than the prefs editor for the WB Tools menu I mentioned in a previous post, I'm not sure this is necessary as an OS-level feature.



Even as we're daydreaming about features, it's important to remember the scope: this is an OS for relatively low-spec machines. What absolutely needs to be part of the OS, what might be relegated to some sort of official add-on, and what should just be a regular tool distributed via other means like Aminet? I trust Thomas and co. have that all in mind.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #5 on: August 29, 2019, 10:55:18 PM »
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?

Quote
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!
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #6 on: August 31, 2019, 03:27:36 AM »
So I guess my hesitancy/issue/concern about ReAction is that on a 3.5+ system if you boot without a startup-sequence, then none of the system tools/prefs/utilities work because none of the assigns necessary for their ReAction components to function are established by default. Plus there are all those confusing messages about resource.library that don't really point the user in the right direction to set things up manually.

Conversely, on a 3.1 system all you need to do to get into a near-fully functional Workbench (and associated tools) is to establish ENV: and run LoadWB. This makes diagnosing whatever is preventing the system from completing a normal boot much easier.

With the new work being done on ReAction, is there a way to fix this shortcoming so that programs will be able to find requisite classes with little or no user intervention?
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #7 on: August 31, 2019, 04:14:12 AM »
@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.
Sure, that makes sense.

Quote
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. ;-)

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!  :o
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #8 on: August 31, 2019, 06:21:49 PM »
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?

I'm learning that for the first time in this thread, but I think there is still a bit of a difference between bundling classes with the OS to make them available for developers/users of other applications, and switching over the system utilities to require them (if the concern I raised in a previous post can't be addressed).

But it seems like the team is aware of the complexity of the situation, so I'm glad they're giving it some thought.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #9 on: September 05, 2019, 02:45:56 AM »
@paul1981:

Quote
Can you give the LoadWB command a NOWBSTARTUP option?
In OS4, for comparison, this is achieved by holding down a Shift or an Alt key during startup. Maybe something similar could be done in 3.2? (To make life that bit easier for anyone using both ;-))

Best regards,

Niels

3.9+ (3.5+?) has the SKIP aka SKIPWBSTARTUP switch. Should be easy for the dev team to add that back in.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #10 on: September 20, 2019, 02:13:19 AM »
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?

No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #11 on: November 30, 2019, 04:38:04 PM »
Quote
So, we are moving towards a much smarter console. Unfortunately, there is not yet a scroll gadget because this would require support from the console.device - which I'm currently not trying to touch. But this will come, sooner or later.

I'm genuinely curious: WShell, KShell (and others? ViNCEd?) have had scroll gadgets for a long time. How do they implement them? Hacks?
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #12 on: December 01, 2019, 02:13:15 AM »
KShell adds an iconify gadget to the window as well, so I wonder if there are some hooks into Intuition?

I just realized the OS4 shell/console also has a scroll gadget, so maybe there's some documentation/code you could borrow from that when the time comes.