[Cuis-dev] Don't Mode Me In: >>layerNumber

[H. Fernandes]

Hi Ken, 


The current behavior is not modal in a sense you are locked with a Morph you are obliged to interact with. 
In some circumstances when you can't change the order in the Z axe, for example a Halo or a menu insisting to be visible to the user, you can slide on the X or Y axes to have no overlapped Morph, then interact freely as you want with the presented Morph.. 


>From my observation with users interacting with a Cuis app, you will have the main window application, the additional morph or tool to show up on top of this main window. The user will interact between the main window and the overlapping additional tools, for example a style dialog that pop up. In some circumstance, the dialog will fall behind the window, the user click on main window. For these reason I lowered a bit the layer number of the dialog panel, after all why a panel not on the top when you want to interact with. 
For other application, on Dybo for scripted Morph, the same situation occurs with its halo and morph menu. A halo is a kind of meta level of interaction with a Morph, my perception i it should remain visible in all circumstances, as are the balloon text. 

In your example, I am not sure to feel the issue as you can play with x and y axes to interact as you want. For me menu should always be on the top, if not needed should be closed, but never fall behind. One option is to set halo and menu with the layer number. 
Regarding Debugger and related developer tool, may be moving them all at a lower layer number. 


Before committing any code changes, I suggest we look at the current state of layer numbers and annoyances observed. Likely documenting in DrCuis' workbench will be a good start. 



Dr. Geo -- http://gnu.org/s/dr-geo 

----- Mail original -----


Hi Folks, 

I have been playing around with the #layerNumber which solves the desire 
to have some windows come before others (a.k.a. "stay on top"). 

I have not yet come to a crisp set of rubrics/behaviors, but thought to 
share some of my concerns -- why the current behavior bugs me. 

Larry Tesler had a motto "Don't Mode Me In" as a reaction to text 
editors with modes which required a user take some action with no 
possibility of an override -- one got into a "Mode" which had to be delt 
with. 

I guess I feel the same way about the current #layerNumber behavior. 

I attached a couple of screenshots. 

The first one shows a Morph with selection handles, one of which was 
used to open its menu, and a menu selection of #borderWidth: brought up 
an edit panel with which to fill in a new value. Note that the halo 
morphs are above the menu and both are above the fill-in panel. 

The second example shows a morph's menu used to bring up a color 
selection panel which now totally hides the original morph. One is 
unable to "send to back" or "bring to front" the original morph or these 
panels. The menu stays in front of the panel hides the original morph. 

Perhaps worse, Selecting a panel's menu->debug->"browse morph class" 
brings up a browser _behind_ the larger color picker panel, which makes 
browser use much more painful. 

One thought was to have a Z-order "slice" which maintains a 
front-to-back relation between a morph, its handles, its menu, and 
related fill-ins/pop-ups. The idea here would be that the entire 
related "slice" could be brought to the front or sent to the back of all 
other Morphs. One could re-arrange ordering within the "slice" so that 
a menu could show up in front of construction handles and fill-in panels 
could be in front of or behind the menu. 

Also, some popUps are not closely related to any base morph and their 
behavior should be independent as well. 

So I don't have a real solution here (yet!). But I think we can do 
better than this and you smart folks should be able to help out! 

In any case, I really do want "send to back" and "bring to front" to 
again do what I expect. 

Thanks for listening, 
-KenD 

-- 
Cuis-dev mailing list 
Cuis-dev at lists.cuis.st 
https://lists.cuis.st/mailman/listinfo/cuis-dev 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250521/d1e4ba35/attachment-0001.htm>