Amiga OS 3.3 top 3 "must have" features (Wishlist)

[Jope]

Originally Posted by eXeler0

I think he might have meant that its difficult to set it up on an emulated system in a way’d want when you try to install /prepare a cf card for use in an actual Amiga?

Still, what's wrong with doing a part of the setup on the Amiga once you've transferred the card. :-)

[eXeler0]

Originally Posted by Jope

Still, what's wrong with doing a part of the setup on the Amiga once you've transferred the card. :-)

Well, the main point he was making is he wished to have it included from scratch so he wouldn't have to that - personally, I agree, I've had lots of trouble getting stuff like Plipboxes, PCMIA wireless cards to to work, and when it doesn't work, you're not sure if the problem is software / configuration or hardware related. If it was included you'd expect it to be set up right.. Stuff like that, but yea, ppl have been doing it manually for 25+ years so I guess its not anything wrong with it for those who enjoy tinkering with it ;-)

[DisasterIncarna]

As a weird sort of wishlist feature, is there a way to do math in tooltypes, specifically regarding X/Y Co-ordinates many programs use to position their windows, instead of WINDOWX=50, WINDOWY=50 is there a way to specify an X/Y as ScreenWidth-X, ScreenHeight-Y to make programs that support that feature adapt to lower/bigger screenmodes.

[Thomas Richter]

Maybe some confusion here. The position of windows is collected/evaluated by intuition, and intuition does not care about tool types. You probably mean the console handler, and the path towards a console, and then programs that open the console handler from a path, where the path is given in a tool type?

Note that there is not a single Os component involved here, but 3 of them: a) the program that parses the tooltype (e.g. IconX), b) the console-handler which receives the parsed string, and c) intuition which receives the window coordinates from the console-handler.

It is probably a question of the console-handler to support this. I'm not sure, but maybe ViNCEd does offer some feature in this direction, but I do not not know.

[DisasterIncarna]

Originally Posted by Thomas Richter

Maybe some confusion here. The position of windows is collected/evaluated by intuition, and intuition does not care about tool types. You probably mean the console handler, and the path towards a console, and then programs that open the console handler from a path, where the path is given in a tool type?

Note that there is not a single Os component involved here, but 3 of them: a) the program that parses the tooltype (e.g. IconX), b) the console-handler which receives the parsed string, and c) intuition which receives the window coordinates from the console-handler.

It is probably a question of the console-handler to support this. I'm not sure, but maybe ViNCEd does offer some feature in this direction, but I do not not know.

I know in for example AmigaShell as part of its Window=CON: ?/?/?/etc options you can specify X,Y,Width,Height,etc. However other programs have their own personal system of X/Y window position, regardless for either way we are basically passing them a fixed/static number they use to do their thing.

For the CON: example instead of
WINDOW=CON:100/100/500/200/AmigaShell-Window/CLOSE

is there a way to do something like
WINDOW=CON:{ScreenWidth-500}/{ScreenHeight-200}/500/200/AmigaShell-Window/CLOSE

A value fed back in a way the tooltype is not aware its being fed a math question, it would just get a return value and use it with some variables such as ScreenHeight and other useful values being an option to do math with, tho atm only the screen dimensions is something i can think of.

A few other programs i can think of that have positional values as a tooltype.

SnoopDos: ICONPOS=0,0
Clock: LEFT=0, TOP=0
Exchange: WINLEFT=0, WINTOP=0, WINWIDTH=0,WINHEIGHT=0
DeliTracker2: MAINWINXY=0/0
Newshell (Via CON: uses X, Y, Wid, Hgt)

There are many more that use values for window positioning in their tooltypes, no standard tooltype name but the values they use are all basically screen positions, its the ability to allow for more flexible values which would be really useful by having a tooltype be able to use a value as normal or fudge in a math'd value.

Maybe if a tooltype see's something like WINLEFT={ScreenWidth-100} then the result of that can be fed to the program looking for its value.

This could help negate the need to re-snapshot MUI windows into new positions when changing a screenmode and helping older non-mui programs open in more useful positions.

Might be an overreach or impossible for tooltypes to work that way but would be useful (*cough*, for me at least) if it could i'm also probably not explaining thsi well, but well, thats me in a nutshell, handy ideas i like but crap at explaining it clearly

[James]

Originally Posted by Daedalus

Another thing that sounds like just being like Windows/Linux/Mac for the sake of it. Temporarily leaving out icons that I want to put away again is another nice Workbench thing I'd love to see in Windows. OS4 has an icon indicator to show that it's left out.

Adding a Make Link option might be doable, it can then be left out for the effect you're looking for. But links like that are dependent on the underlying filesystem IIRC so might not work everywhere.

There is an Arexx script to enable icon shortcuts on WB for OS3.5+ here:

https://aminet.net/package/util/wb/IconLink

[jbenam]

My wishlist:

1) Integrated LHA/ZIP + GUI
2) Integrated (but optional during install) TCP/IP stack
3) Lightweight Aminet downloader (something similar to UHC Tools GUI) - much more useful than a browser and lets users quickly expand their OS after installation

[desiv]

Oh, I just thought of something else that I know is probably not worth it or doable or whatever... ;-) ;-)

One of the things that confused me for a bit when re-installing/building my desktop was that after I had a couple of apps in WBStartup, I couldn't test resolution changes, because those apps were running.
Yes, I know, it's not too hard to kill my meter and menu apps before I do that, but I almost always forget to do that. ;-)
It would be nice if I didn't have to. If the apps could be auto killed and then relaunched or something???
Maybe (and this might already exist??) have a way for apps to be asked politely to shut themselves down, and then it is up to the apps to upgrade themselves for support for that? And then just something that can restart them when done? (again, a way to politely ask them to restart?)
And yes, I can think of several reasons why this might be too difficult to actually do.
Just throwing it out there. ;-)

[mousehouse]

I like the lightweight approach to the OS, even though 3.2.1 is quote a set of floppies by now, still a nimble OS.

My top 3 (in random order)...

1.
Enhanced line editing in AmigaShell. Maybe add some features like CTRL+A and CTRL-E that are in a Unix shell. Also, history is a bonus and line editing is missing (for me?) in 3.2. AmigaShell does not need to become a bash-equivalent (I can install that) but I do frequently use it. The 3.9 OS has some add-on which does a lot of this stuff also.

2.
An optimised (and recent) version of LHA would be a great addition.

3.
Smart datatypes... now that we have PPC add-on chips, ARM through ZZ9000, things on mediator, DSPs, ... would an updated framework be doable where you can add datatypes optimised to use a coprocessor, and the OS picks one (and defaults to 68k)? I have WarpDT on one machine, but if I take the PPC out everything breaks. Etc. even nicer would be universal binaries in an extended hunk format, haha. Nah that would make everything super complex. Datatypes would be nice...

[Thomas Richter]

Originally Posted by mousehouse

Enhanced line editing in AmigaShell. Maybe add some features like CTRL+A and CTRL-E that are in a Unix shell.

Line editing of the console (please, do not confuse that with the Shell - that is just a program running in the console) is pretty enhanced alerady, though the shortcuts are Amiga-like and not Unix-like. For example ^E is sending an interrupt signal, if you want to move to the end of the line, use Shift+Cursor-Right.

Originally Posted by mousehouse

Also, history is a bonus and line editing is missing (for me?) in 3.2.

A "history" we have since 1.3, and even a command controlling it in 3.2. And we have TAB completion.

Originally Posted by mousehouse

AmigaShell does not need to become a bash-equivalent (I can install that) but I do frequently use it. The 3.9 OS has some add-on which does a lot of this stuff also.

If you want the 3.9 console (not shell) back, you can still do that. Grab ViNCEd from Aminet. It does have a couple of more features, including enhanced and full-screen editing.

Originally Posted by mousehouse

An optimised (and recent) version of LHA would be a great addition.

It would already work for me if LHA would not break window iconification. I was talking to its author on this and provided information how to do it, but no avail.

Originally Posted by mousehouse

Smart datatypes... now that we have PPC add-on chips, ARM through ZZ9000, things on mediator, DSPs, ... would an updated framework be doable where you can add datatypes optimised to use a coprocessor, and the OS picks one (and defaults to 68k)?

That is not the matter of the datatypes system, but the matter of the datatype itself. There is no problem checking in the code which hardware is available, and using the right/optimized implementation depending on which processor is in the system. It is more an issue of authors being lazy. The same issue applies to all programs, not just datatypes.

[Reynolds]

What about a hotkey for screenmode change in case of emergency? so you shouldn't have to e.g. boot without startup and delete/rename the screenmode.prefs file to get a basic WB loading and having chance to fix a videomode issue in a case when you see nothing due to any issues but knows that WB completely loaded?

Haven't read through yet the whole thread but it would be cool if the CF adaptor could be bootable, if there is a bootable CF with any filesystem attached...?

[daxb]

There is Hotkey included in OS 3. You just to have to add the hotkey you need/want.

[Reynolds]

Originally Posted by daxb

There is Hotkey included in OS 3. You just to have to add the hotkey you need/want.

Yes, but can you change back the screenmode without any further interaction than pressing a key with no visible frontend? AFAIK it isn't possible, but would be helpful.

[Thomas Richter]

Actually, I do not see why this should not be possible. Just assign the key to a small script that loads a safe screenmode default with the screenmode program in the Prefs drawer.

[DisasterIncarna]

Originally Posted by Reynolds

Yes, but can you change back the screenmode without any further interaction than pressing a key with no visible frontend? AFAIK it isn't possible, but would be helpful.

not tried with Screenmode, but WBPattern lets you specify a prefs file to USE, this is how my wallpaper randomiser program can get rando wb pictures, normally the pictures are locked and cant be randomised, so you just tell wbpattern to USE a saved file which has blank entries, do your wallpaper change then tell WBPattern to USe the new wallpaper.

Does Screenmode also allow you to USE a saved prefs file like WBPattern from CLI/Shell? if so you could save a ScreenMode-Basic.Prefs to envarc which has the basic/normal screenmode you prefer such as bog standard 4 color hires and use it for your quick/minimal workbench.

Thats IF screenmode lets you work like WBPattern ofc, then you can just hotkey that with a script that swaps between the proper screenmode and the basic one.

EDIT: Just checked, screenmode does have the options FROM,EDIT/S,USE/S,SAVE/S so you should be able to invoke

RUN <>NIL: SYS:Prefs/SCREENMODE FROM ENVARC:SYS/ScreenMode-Basic.prefs USE

if you create a screenmode of your choosing and save it to envarc:sys.

and

RUN <>NIL: SYS:Prefs/SCREENMODE FROM ENVARC:SYS/ScreenMode.prefs USE


To toggle back to normal. you could also make a ENV variable for scripting to make a TOGGLE variable you can check and change the screenmode accordingly.

[daxb]

Beside ScreenMode you can try: http://aminet.net/package/util/wb/parsesmprefs

[wiser3]

I would like to have a "public screen manager" with the OS. Perhaps as part of the WB screen prefs it could open and mange public screens. Abilities to include moving windows from one screen to another and having it auto open screens on startup.

I realize there would be compatibility issues with it. Afterall we can't even close/reopen most windows in order to change the WB resolution. Would compatibility be high enough to be worth the effort of creating this?

[Mathesar]

Originally Posted by jbenam

My wishlist:

1) Integrated LHA/ZIP + GUI
2) Integrated (but optional during install) TCP/IP stack
3) Lightweight Aminet downloader (something similar to UHC Tools GUI) - much more useful than a browser and lets users quickly expand their OS after installation

That would be my list as well.
Regarding #2. In the embedded world, LwIP is very popular.
https://en.wikipedia.org/wiki/LwIP. It fits the lightweight concept for OS 3.2 (3.3 ) quite nicely.

[mousehouse]

Originally Posted by Thomas Richter

Line editing of the console (please, do not confuse that with the Shell - that is just a program running in the console) is pretty enhanced alerady, though the shortcuts are Amiga-like and not Unix-like. For example ^E is sending an interrupt signal, if you want to move to the end of the line, use Shift+Cursor-Right.



A "history" we have since 1.3, and even a command controlling it in 3.2. And we have TAB completion.



If you want the 3.9 console (not shell) back, you can still do that. Grab ViNCEd from Aminet. It does have a couple of more features, including enhanced and full-screen editing.



It would already work for me if LHA would not break window iconification. I was talking to its author on this and provided information how to do it, but no avail.



That is not the matter of the datatypes system, but the matter of the datatype itself. There is no problem checking in the code which hardware is available, and using the right/optimized implementation depending on which processor is in the system. It is more an issue of authors being lazy. The same issue applies to all programs, not just datatypes.

Thanks Thomas... I clearly need to dive a bit more into the 3.2 features before commenting

As for datatypes - maybe I'll give that a try! Do you know of any documentation available online on the datatypes implementation?

[TGM]

Could we have a "core" version of Picasso96 built in? Both hardware (Vampire, PiStorm) and emulation (MiSTer, WinUAE) all have RTG options now and it would be sensible to at least have basic support.

Apologies if this was in 3.2 - I don't remember it being included.