Hi Christoph --

> Maybe I will introduce something like #isGrayedOut for summarizing #isEnabled and #isFilteredOut ...

Please don't mix up object state (here: isEnabled) with (visual) object representation (here: color-is-gray or looks grayed-out).

Maybe the filter can just remember the original state of its list.

Best,
Marcel
Am 05.10.2021 17:49:01 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
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 ...

Best,
Christoph
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.



Best,
Marcel
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.

Best,
Christoph

---
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/20211006/d1272994/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37823 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211006/d1272994/attachment.png>