Hi all,<br>
<br>
today I was investigating why enablements in docking bar menu items do not work (for instance, if there are no open windows, then the "No Windows" item should be disabled, but it is not). I traced this down to our delightful type-to-filter feature which overwrites the enablement of menu items (see MenuMorph >> #displayFiltered: and MenuItemMorph >> #isEnabled:).<br>
<br>
I think two mental models are clashing here: First, the menu provider/model wants to declare whether an item is available/locked from the domain-specific perspective. Second, the UI needs a way to temporarily disable items that have been filtered out. I suggest we add a second pair of selectors to MenuItemMorph to differentiate between both kinds of enablement - i.e., something like #isDomainEnabled[:] and #isFilterEnabled[:].<br>
<br>
Here are two actionable questions for you:<br>
<br>
<b>1. Do you aggree with this idea in general?</b><br>
<b>2. How shall we name these selectors?</b> In the Trunk, there are 3 senders to the existing setter and and ~10 senders to the existing getter. I wonder whether we shall maintain backward compatibility here or whether the existing #isEnabled[:] is also subjected to change. Maybe #isAvailable[:] (domain) and #isLocked[:]? Or #isAvailable[:] and #isFilteredOut[:]? In any case, #isEnabled should be the logical conjunction of both states.<br>
<br>
Looking forward to your help.<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i>