DockingBarMorph errors?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

DockingBarMorph errors?

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

Re: DockingBarMorph errors?

Christoph Thiede

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 <[hidden email]> im Auftrag von K K Subbu <[hidden email]>
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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: DockingBarMorph errors?

K K Subbu
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 <[hidden email]> im
> Auftrag von K K Subbu <[hidden email]>
> *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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: DockingBarMorph errors?

Christoph Thiede

It gets repaired with "TheWorldMainDockingBar updateInstances". WDB uses a timestamp to avoid rebuilding the menu bar unnecessarily.


This would be a fix in the model (and ugly global state), but I think it would be helpful to fix just in the Morph. Other models should be able to use DockingBarMorph, too.

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von K K Subbu <[hidden email]>
Gesendet: Dienstag, 24. März 2020 20:30:00
An: [hidden email]
Betreff: Re: [squeak-dev] DockingBarMorph errors?
 
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 <[hidden email]> im
> Auftrag von K K Subbu <[hidden email]>
> *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
>
>
>




Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: DockingBarMorph errors?

K K Subbu
In reply to this post by K K Subbu
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 <[hidden email]> im
>> Auftrag von K K Subbu <[hidden email]>
>> *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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: DockingBarMorph errors?

marcel.taeumel
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 <[hidden email]>:

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