Hi,

Without looking at the code or other surroundings: sounds reasonable
to separate this.

My 2ct for the selectors are: ignore the filters first and give the
domain enabled selectors names. Do not use "domain" in the names. ;-)
Keep compatibility. Then think of the filter selectors as addons to
the implementation. Or put the other way around: I believe that the
filtering using the enabled settings is an implementation detail and
should therefore not dictate the protocol.

If a component relied on the fact that the filtering played with the
enabled setting, better change that component rather than components
that relied on the domain-provided enabled settings. The
implementation of the visuals should follow suit with the refactoring
and check both selectors if necessary.

"Locked" means something different in Morphic.

Kind regards,
Jakob

Am Mo., 4. Okt. 2021 um 16:54 Uhr schrieb
<christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi all,
>
> 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:).
>
> 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[:].
>
> Here are two actionable questions for you:
>
> 1. Do you aggree with this idea in general?
> 2. How shall we name these selectors? 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.
>
> Looking forward to your help.
>
> Best,
> Christoph
>
> ---
> Sent from Squeak Inbox Talk