-
Notifications
You must be signed in to change notification settings - Fork 788
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command palette #3058
Command palette #3058
Conversation
This isn't the interface. Nowhere near. But this helps kick off visualising how it will all work.
Just to help things stand out for the moment. At some point I think I'll allow passing in custom styles, which will come from component classes or something. For now though this makes it easier to see what's going on.
These were there when I was first testing the layout. They're not needed any more.
At the moment it does nothing more than grab a new UUID, but this gives us scope for throwing in some sort of callout to the providers to let them know we're done.
Not like this, but kinda like this. Just experimenting at the moment, hence the random sleeps in the core of the generator (to sort of fake a slow background source).
It's not going to end up quite like this, but this gets it going.
Doesn't seem to make sense to have a LoadingIndicator constantly running in the background when it isn't needed.
See Textualize#2912 and Textualize#2914 for some context.
I don't really see much need for this, now that development of this is well under way. And even if we do want to expose this, I think we need to allow setting it on the class, not on the instance.
It's becoming clear that we do want to allow people to import from this file, so it's time to drop the underscore.
There's one typing error that's been with me for weeks now, and nothing I did seemed to get to the heart of it. Finally, I think it's dawned on me. Raising NotImplemented from the abstract base implementation confuses the type checker as it's not seeing any sort of yield going on. This... this solves it. I'm not 100% sure this is the correct thing to do, advice online seems patchy at best and the couple of things I've seen that do seem to address this sort of situation seem to introduce other typing issues (a bare yield being the main suggestion, which won't work as then it'll be yielding the wrong type). Gonna sit on this for now and see how I feel about it, or see if I can find something relevant to this.
The asend back into the search routing was always showing a typing mismatch, but I couldn't quite see what was going on; what made it even more confusing was the code was working fine. It looks like keeping hold of the "routine", and keeping that distinct from the iterator of the results, is the trick here. It all still works *and* the typing works out.
The choice of default key binding might be questionable after all: while it has been shown to work fine on macOS and Windows, I've just noticed that, in Windows 11 under Parallels at least, if I go to paste something into a Textual application from the clipboard it causes the command palette to appear first and then the text being pasted is pasted into that -- this would suggest that the paste operation is causing the same sequence to be passed in as that generated by ctrl+space. |
We've recently changed the way the command list is cleared down when the search term is modified, thus removing a source of "flashing" as the user types; this pretty much involves *not* clearing down the previous hits until the first new hit comes in. This is fine in all situations expect where the last search was a "no matches" search. In that situation the next search stats out saying "no matches". That's correct, that's the result of the previous search, but in this case it's unhelpful and potentially confusing. So this commit checks if that's the state of the command list up front and clears that option from the list.
While it's kinda cool... it's not really very helpful if you're doing things via textual-web; all you're going to do is start to use storage on the host machine, not the client machine (unless they're the same thing, of course).
Implements #3021.
Key features of the PR:
Current state of work in a simple test application, where there's a command source of lines of text, where a selected line will cause the text to be shown in a Textual notification. The command source is coded to pretend to be a very slow source, with noticeable pauses between each command been provided.
Screen.Recording.2023-08-29.at.10.44.11.mov
The matching in the command provider is done using Textual's (as yet undocumented) builtin "fuzzy matcher". The code for the command provided used here is:
where
self.DATA
is simply a list of lines of text.A slightly more sensible example, this time hooked up with a command source that wraps the main Textual application actions:
Screen.Recording.2023-08-29.at.10.46.51.mov
Still to do (not an exhaustive list):
Related to the above, consider support forOptionList
for inserting new options in specific locations in the list.Likely a full entry in the guide.2Perhaps also a HOWTO on how to write your own command source.3Footnotes
Actually, aside from some tweaks to the interface, I've left it as-is for the moment. I do wonder if we can improve the scoring -- perhaps scoring earlier matches over later and the like -- but I think it's fine for the moment. ↩
The more I think on this, the more I think it makes more sense that, initially at least, this is documented as part of the API (which it is). ↩
I think this should come later if it's decided it's needed. ↩
Going to be added by @willmcgugan before going into
main
; likely a main docs and blog combo. ↩