<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>> <span style="font-size:12pt">It gets repaired with "TheWorldMainDockingBar updateInstances". WDB uses </span><span style="font-size:12pt">a timestamp to avoid rebuilding the menu bar unnecessarily.</span></p>
<div><br>
</div>
<p></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">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.
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Best,</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Christoph</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von K K Subbu <kksubbu.ml@gmail.com><br>
<b>Gesendet:</b> Dienstag, 24. März 2020 20:30:00<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] DockingBarMorph errors?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">The docking bar is instantiated by TheWorldDockingBar class and when it
<br>
is moved around the spacing gets overwritten like you pointed out.<br>
<br>
It gets repaired with "TheWorldMainDockingBar updateInstances". WDB uses <br>
a timestamp to avoid rebuilding the menu bar unnecessarily.<br>
<br>
Regards .. Subbu<br>
<br>
On 24/03/20 11:45 PM, Thiede, Christoph wrote:<br>
> Interesting. The defect appears to be #updateLayoutProperties, where <br>
> #hResizing and #vResizing are set without regard to their old values. <br>
> While the menu items are okay to be set like this, the spacers are not, <br>
> and neither are the search bar and the clock (for completeness, the <br>
> docking bar is built in #fillDockingBar:). I don't know how we could <br>
> rule this best:<br>
> <br>
> <br>
> Store the relative resizing information as a new property in each <br>
> submorph of the docking bar? This would make it harder to extend it.<br>
> <br>
> Only swap hResizing and vResizing values when the method is called (with <br>
> a few assertions, of course)? This is not too easy because the docking <br>
> bar has more than two resizing states: It can be floating, too.<br>
> <br>
> Remember the latest resizing properties of all submorphs before the <br>
> adhering is changed, and reapply it when possible? This sounds the most <br>
> plausible approach to me. But it will revert layout changes made by the <br>
> user when you drag the docking bar multiple times.<br>
> <br>
> <br>
> What do you think?<br>
> <br>
> Best,<br>
> Christoph<br>
> <br>
> ------------------------------------------------------------------------<br>
> *Von:* Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im <br>
> Auftrag von K K Subbu <kksubbu.ml@gmail.com><br>
> *Gesendet:* Sonntag, 22. März 2020 16:29 Uhr<br>
> *An:* The general-purpose Squeak developers list<br>
> *Betreff:* [squeak-dev] DockingBarMorph errors?<br>
> All,<br>
> <br>
> I encountered a strange problem by accident with the main docking bar in<br>
> Squeak 6.0alpha-19541 (linux VM):<br>
> <br>
> * bring up halo menu on the main docking bar<br>
> * click on pick icon and click again in the same place.<br>
> * Expected behavior - the main docking bar remains unchanged<br>
> * Actual behavior - menu items are packed to the left.<br>
> <br>
> Does anyone else see the same behavior?<br>
> <br>
> I also saw another anomaly:<br>
> <br>
> * If I click ctrl-1 ctrl-2 etc, the drop down menu appears below<br>
> Project, Tools etc. But if I press ctrl-0, the drop down menu remains in<br>
> place but the text cursor switches to the Search Bar. This is confusing<br>
> and disconcerting.<br>
> <br>
> Regards .. Subbu<br>
> <br>
> <br>
> <br>
<br>
<br>
</div>
</span></font>
</body>
</html>