[squeak-dev] Menu filters override item enablements

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Tue Oct 5 15:48:50 UTC 2021

Hi Marcel, hi Jakob,

> Then why would it work for the "Projects" menu?

Interesting observation! This seems to be because the project menu uses updating menu items with an enablement selector rather than passing a single boolean to #isEnabled:.

However, even in this example, the enablements do not always look correct. For example, if you type in "save", after one second, after one second, "Enter Previous Project" will be re-enabled despite the active filter. The stepping conflicts with the type filters here ...

Thanks for your thoughts, Jakob! I agree that consistent names in the public interface are more important. Maybe I will introduce something like #isGrayedOut for summarizing #isEnabled and #isFilteredOut ...



Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 5. Oktober 2021 08:47:22
An: squeak-dev
Betreff: Re: [squeak-dev] Menu filters override item enablements

Hi Christoph --

> I traced this down to our delightful type-to-filter feature which overwrites the enablement of menu items

Then why would it work for the "Projects" menu? You can keyboard-filter there, too.



Am 04.10.2021 16:54:50 schrieb christoph.thiede at student.hpi.uni-potsdam.de <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.


Sent from Squeak Inbox Talk<https://github.com/hpi-swa-lab/squeak-inbox-talk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211005/0f94824b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37823 bytes
Desc: image.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211005/0f94824b/attachment.png>

More information about the Squeak-dev mailing list