I think the Smart Filters could use a tri-state control: included, not included, and disabled.
This would preserve the current behavior while giving users more flexibility and more possible combinations.
And how should that be triggered?
By clicking in a cycle maybe? ![]()
(Disabled->included->not included->Disabled…)
I’m sorry if I’m being a bit persistent. I don’t mean to be rude or disruptive. I know you have a lot of work to deal with, and believe me, I’ve been in a somewhat similar situation myself.
I just wanted to share something I’ve noticed from my side. With some of my feature requests, I don’t really get a meaningful signal about how the idea was received. I can’t tell whether it’s useful, too much, not relevant, or simply not a direction you’re interested in.
I’m not saying this expecting a response to every request. I just wanted to mention that, from the other side, having no signal at all makes it difficult to know how to adjust my approach, improve my ideas, or shape future requests.
If something isn’t interesting or isn’t a direction you want to pursue, that’s completely fine. Even knowing that would be useful feedback for me.
Anyway, I just wanted to put this out there. Thank you very much, and I really really appreciate all the wonderful work you’re doing on Glyphs ![]()
There is sometimes no single signal to respond with. A proposal is always considered, but it’s exact shape and implementation often only crystalizes over time or as more proposals/requests in a similar direction come in.
I don’t think the multi-color selection backgrounds work well, but I see the need for quick access to functionality like this. I have some ideas that solve something similar, but go in a different direction. And those have other downsides …
Part of good software design is not adding every requested feature immediately, as that would get confusing quickly and cause a lot of conflicting features that do not interoperate or make the performance of each other worse.
It’s a balancing act where a solution is not always obvious or without tradeoffs. If we do not reply further on a feature request, consider it considered with the hope for a good solution to emerge that covers multiple requests at the same time.
Thank you for clarifying this. That makes a lot of sense now, and it’s really helpful to know how I should interpret the lack of further replies. I appreciate you taking the time to explain it ![]()
