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 :)

If anybody want to know how convulated and interdependent even the most basic function in Ambinet are.

YES

So I tried pulling Panel related source files out and have them compile in a different location
-> endless dependencies
Next I tried building an Ambien with everything not Panels disabled
-> same difference

As a last resort I started from scratch, read a MUI Window, a group and a bunch of DTPic objects that look like a panel.
This obviously did "work" and gave me a base to which I could pull in one class one method after the other.
Dragbar do work (as dragbar) and can trigger zipping to the left which since today looks (almost) like it's done in the Panels.

There is obviously still much todo and if my wild assumption of MorphOS3.20 getting released in the 2nd half of 2024 come true I might end up running late.

But are upsides, I can test version without having to restart Ambient and the code base is a fraction making for much faster turnarounds.
I also simpliefied how the whole zipping is organized. No need to go multithreaded when only panels run in that task. There is one global timer in appclass that keeps running as long as 1 of the 10 slots for zipping is active. 10 is a random number that I choose as I see it unlikely that a user could trigger more before the 1st is finished. If someone manages to do it anyways zip 11 and onwards will just be instant.

I will probraly do some non/semifunctional public betas at a later, think about a fixed panel with just a few icons found in a naked MorphOS install doing little more then zipping in the 1st instance.

At later time these might get somewhat functional with a basic text based config file, but these will be time locked to make sure noone uses them for real.

If that is all good it is back to hacking inside Ambient to make them the default option, reconnect with the prefs and conffig file system and so on.

New features as outlined in earlier post will only happen if time permits.

@ Kronos - It sounds like you've been busy on this little (convoluted) project!

Will it end up with "Panels" as a mcc class if you manage to complete your "little" effort in time for MOS v3.20, or even at some later stage if it takes even longer than you currently estimate?

@NewSense

I am not 100% sure what you are aiming at and since I have been asked something similar yesterday:

Sure it is and will be possible to use a panel class in a different app, just like it is possible with screenbar modules or even any class you find peeking and poking in any code running at time.

Thats offcourse a dangerous idea and doesn't make much sense in the 1st place.

As for being able to subclass panel classes to change look layout or behaviour, sure thats about 90% of what this update will be about.

So there will be panel app (not an mcc) which provides the basic classes which you will either to able to subclass or replace with your own MCCs. If you want your panels to look like the Windows start menu or maybe even the Win8 tiles, if it shall look like early OSX or if you want to mimmck the look of same fake made for TV OS. All is possile.

None to little of that will be part of the default app included in MorphOS3.28 and upwards ;)

[ Edited by Kronos 04.11.2023 - 08:14 ]

Good news, bad news......


I did manage to open a prefs file and read out basic setting like size, orientation, background etc. Next step would be reading in the panel objects and passing all that to my redone classes.


I also had implemented D&D and wondered why it didn't work. Till it dawned my that it ain't part of Ambient anymore and that stuff only works within one app *duh* Guess I have to go the AppWindow route.

Did a 1st public alpha build:

http://www.steamdraw.homepage.t-online.de/PanelApp.lha

Will search for "New_Panel_1.prefs" in "PROGDIR:" so you might want to copy that from sys:prefs/Ambient/Panels.

Programs can be launched, dragbar, spacer, separator and subpanel classes are also included. subpanel will default to sys:tools/format.info for the time being.

And just to be clear it is an alpha release, so a lot of things will not work or cause issues.

OK, it works for me, but expanding and zipping the Panel is very slooooow, and some of the classic Amiga OS3 icons that would normally display OK with the Ambient Panel view are distorted beyond recognition, in that the area they cover are between 2x and 6x wider than the area they should take up so you cannot make out what the area on the panel they represent, as the icon is too graphically corrupted to make it out, you just have to see the program that launches to know what it was you clicked on to actually see the program once it has loaded.

But, hey, it's an alpha release and it works, so thanks for your efforts so far Kronos, but I wouldn't want to swap it for the Ambient Panels as yet.

First test: like NewSense "expanding and zipping the Panel is very slooooow"

No bug found.

Blue color for second picture instead red will be better on MorphOS

2nd alpha:
http://www.steamdraw.homepage.t-online.de/PanelApp.lha

This one "only" added support for Glow and non-Glow Amiga as well as SVG icons.

Only as in:
- created a custom Ambient build with a PanelTestButtonClass (1:1 copy of PanelBaseButtonClass at this point)
- placed a bar of those with problematic Icons in the Panels prefs area (so it won't get autotriggered on every Ambient restart)
- added another source file with a copy of the icon_read() function
- trimmed that function down form almost 1000 to just 180 lines (lots of stuff not needed for panels)
- pulled in all Ambient functions called from there (with a slight rename to avoid linker issues)
- pruned those functions
- pulled in more functions and defines used in the 1st set of functions
- rinse&repeat (x5)
- made sure all the renamed stuff that needs initializing gets that
- transferred the source file to the PanelApp project
- did some adjustments to other sources in PanelApp
- still got a few "undefined reference" errors
- went back to Ambient build to hunt down some more stuff
- rinse&repeat (only x1)
- compile PanelApp
- panic attack all old icons just a black square
- realized that I had forgotten to init the colormap needed for remapping


So what still isn't fixed:
- non square icon may get scaled wrong
- zipping is faster but extra wonky


Next version should get proper scaling and zipping plus support for multiple panels.
Afterwards I will start on the prefsApp/Group/MCC which might not get public alphas depending on wether it requires a special Ambient build.

@ Kronos - So, Panel Alpha-2 seems to run a lot faster, and zipping is a lot faster, but I suppose it is too early to expect anything more at this Alpha stage!

Most icons load OK, such as PageStream, BubbleDoc, DocViewer, NoWinEd, Calimero - all PNG icons, even BME's icon which is a Classic Amiga Icon (BitMap Editor - included with PageStream v4) also loads at the correct aspect colour range, but PageLiner that also was included with PageStream v4 and has a Classic Amiga Icon loads up 4x to wide, but seems to be the correct height (unless some of it is cropped by the Panel itself).

Two icons that do not actually display, just rendered as black squares, are Digita Organiser v2 and Photogenics v5 which are both Classic Amiga Icons.

I am not sure testing other Classic Amiga Icons associated with their programs would be of much use to you at this stage, but if it would be then I can try to check some of them with the Panel Alpha v2?

Overall, this Alpha release is an improvement over the initial release, and I am certainly encouraged by your progress so far.

Would be nice if you could provide me those icon to see at which point they fail.

@ Kronos - PM sent for your contact details so I can supply the icons/images/screengrab(s), etc. as required.

[UPDATE] - PM reply received from Kronos, and message with icons sent to his return email address - which has "bounced" as the email address supplied is not valid! I await another response from Kronos to discover his correct email!