Great, cool feature! Some comments:

• The Dirty flag hack doesn't work in some cases (try searching for "p" and then go to the Timeline section; the "First Default Frame" label will be incorrectly enabled). It might be better to collect all Label widgets that have buddies during the "for" loop, then reprocess the labels collection to determine whether the label and its corresponding buddy should be disabled or not (I don't think the DIRTY flag will be needed. Just check if the label or its associated buddy is enabled; if so, both will be enabled).
• Please rebase the PR to the latest commits.

Removed the use of the DIRTY flag and fixed some corner cases.

Great!! I didn't mention before but Slider and ColorButton widgets should be disabled too. I found that disable all Slider and ColorButton widget before to process the labels will be enough (similar case thatuiWindows()->setEnabled(false);

        // Always disable the Slider and ColorButton widgets; they will be enabled through
        // their label.
        if (widget && widget->type() == kSliderWidget || widget->type() == ColorButton::colorbutton_type())
          widget->setEnabled(false);

ColorButton::colorbutton_type() isn't accesible, I moved colorbutton_type() to the header file inside ColorButton class. This would require approval from @dacap.

In case we need access to colorbutton_type(), you can refactor it to static WidgetType ColorButton::Type() as a public member of ColorButton.

Fixed some issues with the disabling/re-enabling and added a disabled state to the ColorButton basically making it greyscale, since it had no disabled feedback.

@dacap Made a change to Slider so it's also setting the text() to the value, I think it makes sense semantically but I could also just work around that in my code and not change a core class.

Fixed accidentally breaking everything (oops) and added two new things:

• Made the search a focus magnet like in keyboard shortcuts
• LinkLabel now inherits the regular label style which means they have a "disabled" color
• Added the closeOnEsc property to SearchEntry, which came from me trying to naturally "clear" the search using the escape key. Made it optional by default and I've added it for big windows with a search like this, keyboard shortcuts and the command runner.

Almost perfect, but...:

          if (label->isEnabled()) {
            label->buddy()->setEnabled(true);

            // Special case to handle buttonsets
            if (label->buddy()->type() == kGridWidget) {
              for (auto* child : label->buddy()->children())
                child->setEnabled(true);
            }
          }
          else if (label->buddy()->isEnabled() && !label->buddy()->text().empty()) {
            label->setEnabled(true);
          }

I found that the ComboBox labels are disabled regardless, even though the string "pn" belongs to one of the available options ("png") in the default file association ComboBox under "Files" section.

The problem lies in the following "else if" statement:

  else if (label->buddy()->isEnabled() && !label->buddy()->text().empty())

In the mentioned ComboBox label->buddy()->isEnabled() is "true", however, !label->buddy()->text().empty() is "false" since !label->buddy() is a ComboBox type with no text. Finally, in the UI, the ComboBox label will incorrectly change to a disabled state.

Added a cache of the lower case searchable text for the widgets, this speeds up the processing on each keystroke by around 40%~, I've also added debouncing to SearchEntry which further minimizes the load at the expense of a bit of latency, but it should be helpful on lower-end systems and not particularly noticeable otherwise. Also renamed closeOnEsc to clearOnEsc since that's what it's doing.

I've rebased this to latest beta to avoid conflicts with the merged PR #5503

You can find the rebased version here https://github.com/dacap/aseprite/tree/preferences-search in case you want to move your own branch. Anyway there are some comments to make.

@dacap Made a change to Slider so it's also setting the text() to the value, I think it makes sense semantically but I could also just work around that in my code and not change a core class.

I'm not sure why this change was required. Is it necessary for this feature?

Looks great @ckaiser 👍 I'll merge it right now, and make a little change in the Grid section that it looks something has changed.