Os 3.2 development preview

[kolla]

The Workbench menus can be configured dynamically via arexx, there is no "configuration" of them.

[kolla]

@TribbleSmasher
Right, so all this could be fixed by simply adding SYS:Classes to the LIBS: assign from the kickstart. Yet another thing for systemd^wSystem-Startup to take care of...

(Well, ideally I'd like assigns set up like they are in MorphOS)

[kolla]

Whatever classes that are incorporated into the OS, the entire mess that is SYS:Prefs and {envarc,env}:sys/#?.prefs should be tidied up, though it would most certainly imply compatibility issues. Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar. I have earlier written that wbpattern should be merged with workbench prefs, and there should be a "public screen manager" to deal with setting up screens, their properties (including backgrounds), screen modes etc. including that of the Workbench screen. And ideally, it should be easy to import/export prefs from some text file format... perhaps an ARexx port for IPrefs.

One can dream...

[kolla]

And ideally, it should be easy to import/export prefs from some text file format...

I don't think there is any situation where this would actually be useful; you can already use a tool like Report+ to examine preference files in a user-friendly way if necessary.

Really - well, I do - a lot, and I am not alone - this is why there is a Prefs/Presets directory. It is exactly for this, but it requires that one "pre-make" all the preference files and load them with the associated prefs program. I wish for a more dynamic method to load new prefs, with specific parameters, from scripts, from arexx etc.

Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar.

Fonts and ReAction are not especially related.

Exactly, and that is "the mess". There is Font prefs and there is Palette prefs, yet the Reaction prefs have both Font and Palette settings that only are valid for Reaction classes - why should a user know what classes are reaction and what classes are not? With Reaction classes being incorporated into the OS, this should all be unified.

Most preferences editors could be construed as having something to do with appearance.

Not really, from the OS itself there is just Font, Palette, and arguably Pointer prefs. WBPattern and Workbench are prefs for the program "Workbench" - though WBPattern is a little too much, also doing the screen backdrop of the "Workbench" screen, which strictly speaking has little to do with workbench.library) - WBPattern and Workbench prefs should be merged. Screenmode and Overscan should easily be merged, and I would prefer something more advanced, akin to MUI PSI to manage public screens and their properties in general.

[kolla]

Presets can already be loaded via scripts.

Yes, and then you need to have them available. Meaning you have to enter whatever prefs program, set parameters and save to file all possible settings you may wish to have available.

Can you explain the need for more control from the command line?

Sure.

* different palette settings depending on what daylight there is, with darker settings at night - currently I do this by juggling preset files, I would prefer to send RGB values regarding the various pens directly.
* sounds prefs, audio bell - I wish to control at least the volume without having one setting file per possible volume setting.
* ASL prefs - depending on context, I want to control how ASL requesters sort files so I don't have to do it manually every time
* screenmode/overscan - I want to control certain screen properties.. width, height, depth.. in one go, without needing to keep dozens of preset files around
* serial - I wish to easily change properties like baud rate from CLI/ARexx, as AUX:, SER: etc. AFAIK do not have parameters for such.
  (Yes, I know there are options, like using http://aminet.net/package/util/libs/DigNet)

I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient.

Me too.

Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

I don't know where you get this from, I am talking about the user - me - being able to control the preferences of my computer from my preferred user interface. There is nothing that prevents programs from mucking with your preferences already.

[kolla]

The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities

And I wasn't suggesting to change the format.

it also requires the creation and integration of a robust parser into the system

Yes, something that should exist at some point sooner or later anyways.

wasting development resources we really need for more important issues.

Nothing prevents this from being implemented by someone else - as you wrote - the preferences format is a well-document open IFF format.

[kolla]

All of this is of little use for the average user.

You just summed up all the work you ever did to Amiga shell.

It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?

That was exactly my idea in the first place - and with such a daemon (IPrefsNG for teh lolz) in place, it is easy to write all kinds of new prefs programs without much hassle.

[kolla]

Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Or OS 1.x

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.

Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

[kolla]

Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Or OS 1.x

Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.

Right, those of macOS and MorphOS are modular (and if I recall correctly, due to nature of MUI, the MorphOS Prefs modules can even be launched individually). It's just one of many, many things that MorphOS has done much more elegantly than anyone else, and with help of Zune, AROS could do the same.

[kolla]

Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.

Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.

Why is it a limitation of the Os when it does not support such proprietary extensions from third party?

Because it's not proprietary? Anyone can twist around IDE cables and add connectors. In addition, there are implementations of Minimig that support this "out-of-the-box" and let you use 4 disk images at once.

http://aminet.net/package/docs/hard/4IDE

[kolla]

No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.

Well, I managed to do it without making PCBs two decades ago, and it worked, the only components are two diods. Did you even look at the images in the archive?

[kolla]

@Thomas Richter
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find

Code: [Select]

Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...

Code: [Select]

Find myfile | command
But this currently expands to

Code: [Select]

List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

I don't know of any way to "terminate" the argument list of an alias, so one can use pipes with aliases. Does it exists? Will it exist in the future?

At last (bug)...

Code: [Select]

makedir RAM:test?
List all RAM:tes#?
It's very annoying when standard OS tools don't handle characters that are valid in filenames.. I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.

[kolla]

Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find

Code: [Select]

Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...

Code: [Select]

Find myfile | command
But this currently expands to

Code: [Select]

List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

At last (bug)...

Code: [Select]

makedir RAM:test?
List all RAM:tes#?
It's very annoying when standard OS tools don't handle characters that are valid in filenames..

Sorry, I don't have an amiga here.

Hm, I thought you always had vamos at hand...

What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.

The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.

Good. And now I also know how ctrl-r works in Amiga console - that only took me two decades...

[kolla]

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.

Hm, I thought you always had vamos at hand...

Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:

Windows Subsystem for Linux for Enterprise isn't good enough?

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.

Well, guess we can all have a peek in the sources and find out? FWIW, it does not happen with List v43.4 (03-Sep-00).

[kolla]

Note that I never mentioned simple redirections, I was talking about something *BRAND NEW* for AmigaShell in 3.1.4 - effin’ PIPES!

[kolla]

lol