It's about time I start another of these "bring half finished projects back to live" threads.

How panels behave/look:
This hasn't really changed that much since MorphOS 1.4 and I am currently experimenting with automatic layouts and more animations than the default zipping.
Current way of zipping works in a rather complicated way and ends up in resizing the window and copying a partial bitmap of the contents into it. The good is that it works on non enhanced displays.
- making the panel zip on it's long side (so a horizontal panel at bottom would scroll/zip downwards)
-> exists as a rough "hack" only for enhanced displays, could be made to work for non enhanced one
- "zipping" the panel by going smaller overall (64 -> 16 in height)
- highlight the obj under mouse by making it bigger
-> this older OSX style of panels was what I had working before I took over the Ambient panels, implementation should straight forward, but won't work on non enhanced (unless I do fake transparency, which I won't)

Custom panel objects:
These exist for quite a while (I think starting with MorphOS 3.12) but I never made the API fully public.
-> API will be moved (well already is) to panel.library (which might get renamed) and extended to allow for special panel windows or groups

Apps accessing the panel:
Sofar only my private test programs use panel.library to overlay the GFX of "their" panel object

I do have some more ideas that may or may not be made a reality at which point some of the functionality in panel.library would be better presented as an ambient.library (either as a whole or splitting it into 2 libraries).

Question is how many are still using non enhanced displays?
These would have to skip on some of eyecandy stuff but still have working basic panels.

I never use non enhanced displayes.

One thing I would love is the ability for the panel to snap to the middle of the screen, either horizontally or vertically.

Thanks for picking this up again, very exciting!

@ Kronos - I also use 'Enhanced Display' on Ambient, as I don't really see any benefit in using 'Non-Enhanced-Display' on Ambient other than as a RAM saving, which is not critical on Ambient for my systems.

ambient.library? You can only have one Ambient at a time, better create a panel.library. 🥳

"ambient.library" obviously in the sense of accessing function in Ambient from outside modules/apps.

Atm, the "panel.library" offers function to read/write Ambient prefs file items, which ain't panel specific.


As for "only 1 Ambient at a time", there is an option in the source to change that. No idea if and how far that was ever tested or even implemented.


@MoerBoer
Sure panel smack in the middle of the screen, maybe with items arranged in a circle?


*runs*

Forcing a panel to always center itself at the bottom of the screen is working (but still in a hacky way).

For me will be nice feature possibility of saving panel prefs in one file. To copy it to other computers.

Current version can be saved, but if there is other panel present, copied prefs are added to old one.
For me it will be fine, because I have a lot of MOS computers, but I am not sure how many users needs it.

Quote:

You can compile Ambient to run multiple times resulting in multiple screens with multiple desktops. It is even possible to quit Ambient to default shell, when enabled, which allows to test a new version without rebooting.

@geit
I see, however a development environment does not count for Kronos design decision.
By the way we already have the workbench.library and one Workbench

The point is Ambient needs to be more split into components, so external parts like panels don’t need to recreate the wheel every time.

Ambient itself is bloated already and extern components still need to duplicate code.

@geit

That is the point here, making the panels it's own app that access Ambient.library to parse prefs-files and start apps while providing a prefs-group to Ambient (so it's still all just one pref window).

But thats beyond the scope of a MorphOS 3.20 release (unless it takes much longer then the usual even to even revision update cycle).

I use non enhanced display on my 32VRAM MacMini from first MacMini support. (with 512x512 tiled Ambinet pattern on 1680x1050/16bit screen to save VRAM.
This is my only MorphOs hardware as 64Mb VRAM version was hard to found.
For all tasks 32Mb of VRAM is more then enough, only few games needs more than that. (and Blender)
Most of apps I open on Ambient screen, but LW/Modeler and few others use custom screens so I use non enhanced display.
I don't care about fancy animation/trasparency effects but I use panels on my system.

Been thinking a bit about the splitting the panels of from Ambient:

Quote:

At 1st I thought to make the main prefs-pane a mcc so I could reside in the Panel distribution but still be called by Ambient to show up in the general prefs.

Panel app would then just read the prefs file via functions provided by an "ambient.library" with everything staying separated by binaries and tasks.

The issue here is that panel objects both defined in the Ambient binary and external classes will supply their own sup prefspane. No issue as it is all just 1 Ambient task, put across different tasks that sound like a way to disaster.

Basically both the main panel app and every external class would have to act as an library called by Ambient (either directly or by calling into the panel app) which should work, but just feels wrong....

Another way round this would be to just turn everything Panel starting from the Window into an external class and leave it all just running as part of Ambient.

Would cut down the size of the Ambient binary and would allow for 3rd party custom Panels that are different from the root up.

Quote:

Go on! Making panel external and open is probably a good idea. Make panel item a mcc that can be subclassed for custom stuff. Be wise for the API :)