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.