DockingBarMorph errors?
Locked
 
|
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 |
|
|
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?
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!
|
|
|
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 > > > |
|
|
> 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!
|
|
|
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 >> >> >> > |
|
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
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |