Hi Subbu,

no idea. :-) You are absolutely right. It's a mess.

> Was the timestamp hack introduced to make Etoys on Squeak 5.0 
responsive?

Hmm... that TS variable is a UUID. I don't think it is needed anymore.

Best,
Marcel
Am 26.03.2020 13:31:28 schrieb K K Subbu <kksubbu.ml at gmail.com>:
Marcel/Dave,

Do any of you know the rationale/history behind TheWorldDockingBar?

This class breaks a lot of patterns and is quite hacky.

For instance, >>instance uses singleton pattern but the class also has
>>updateInstances.

>>updateIfNeeded: checks for a timestamp and doesn't act on layout
changes. Was the timestamp hack introduced to make Etoys on Squeak 5.0
responsive? Do we still need this?

Regards .. Subbu

On 25/03/20 1:00 AM, K K Subbu wrote:
> The docking bar is instantiated by TheWorldDockingBar class and when it
> is moved around the spacing gets overwritten like you pointed out.
>
> It gets repaired with "TheWorldMainDockingBar updateInstances". WDB uses
> a timestamp to avoid rebuilding the menu bar unnecessarily.
>
> Regards .. Subbu
>
> On 24/03/20 11:45 PM, Thiede, Christoph wrote:
>> Interesting. The defect appears to be #updateLayoutProperties, where
>> #hResizing and #vResizing are set without regard to their old values.
>> While the menu items are okay to be set like this, the spacers are
>> not, and neither are the search bar and the clock (for completeness,
>> the docking bar is built in #fillDockingBar:). I don't know how we
>> could rule this best:
>>
>>
>> Store the relative resizing information as a new property in each
>> submorph of the docking bar? This would make it harder to extend it.
>>
>> Only swap hResizing and vResizing values when the method is called
>> (with a few assertions, of course)? This is not too easy because the
>> docking bar has more than two resizing states: It can be floating, too.
>>
>> Remember the latest resizing properties of all submorphs before the
>> adhering is changed, and reapply it when possible? This sounds the
>> most plausible approach to me. But it will revert layout changes made
>> by the user when you drag the docking bar multiple times.
>>
>>
>> What do you think?
>>
>> Best,
>> Christoph
>>
>> ------------------------------------------------------------------------
>> *Von:* Squeak-dev im
>> Auftrag von K K Subbu
>> *Gesendet:* Sonntag, 22. März 2020 16:29 Uhr
>> *An:* The general-purpose Squeak developers list
>> *Betreff:* [squeak-dev] DockingBarMorph errors?
>> All,
>>
>> I encountered a strange problem by accident with the main docking bar in
>> Squeak 6.0alpha-19541 (linux VM):
>>
>> * bring up halo menu on the main docking bar
>> * click on pick icon and click again in the same place.
>> * Expected behavior - the main docking bar remains unchanged
>> * Actual behavior - menu items are packed to the left.
>>
>> Does anyone else see the same behavior?
>>
>> I also saw another anomaly:
>>
>> * If I click ctrl-1 ctrl-2 etc, the drop down menu appears below
>> Project, Tools etc. But if I press ctrl-0, the drop down menu remains in
>> place but the text cursor switches to the Search Bar. This is confusing
>> and disconcerting.
>>
>> Regards .. Subbu
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200326/b9507f52/attachment.html>