-
Notifications
You must be signed in to change notification settings - Fork 8
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
Extensions should be able to populate 'TextToDisplay' Equivalent from Run #121
Comments
Oh interesting. That's pretty cool idea. I'll ideate on this on the drive home. Cause like, in the PT Run case, I'm guessing the suggestion is based on the "selected" element in the list. That presents an interesting API design choice here. My initial thought is that it would make sense for this to be a property on If we put it as a property on the list item itself, that's a little easier. Then every time we select a new item, we just display the heck I'm just gonna commit that right away. |
Is the value of So in the registry example: when the user has Actually, IMO that's the only thing that makes sense. Cause then the user can type Okay I don't have any questions |
Oh okay the PT Run stuff is weird. Cause it displays ghost text of the I kinda think that's weird. I think as you up/down through the list, you should only see ghost text till you hit → to "accept" it. But I can be overridden on that matter. I think we can probably get away with Just the ghost text for v0.1, and come back for a v0.2 |
Agree that feels weird. I think what you described is precisely what I'd want as a user. I was thinking though: why don't we make the default behavior of list items to have a text to display sorta situation that just works? At least for v0.1 that sorta just fulfills the nice autocomplete type thing and extensions don't have to think about it. We could then have an override or something if for some reason an extension wants a different behavior? Or maybe even a Boolean only that an extension just says yes I want to allow auto complete or no that messes with my aesthetic. While we build it out I'll play around with PowerToys plugins to see if there are any interesting use cases where the text to display actually isn't just the result text. |
While sitting up with Luca last night, I think I realized why it's like this. If we just have a second text box at the end, showing the "remainder" of the |
As discussed in #121. Adds a new `IListItem.TextToSuggest` property. If an extension populates that, and the user hits right-arrow when the item is selected, we'll set the `SearchText` to that text. I didn't give it a UI treatment, because 1. I'm not good at XAML 2. As noted in #121 (comment), there's complicated edge cases here. You have to track what's actually been typed, and then also have a ghost suggestion for the very first item (before the user types/up/downs at all). I didn't think it was valuable to implement that right now before we have A Real App. * targets #144 * which targets #142 * which targets #141 and those guys are all merged as of #150
Right now in Run, plugins can include 'QueryTextDisplay' which allows for some pretty cool auto-complete functionality.
I'm thinking we should allow for something equivalent where either one of two things happen or both?:
We automagically include the text to be filled in without extensions even thinking about it. Meaning that from the users perspective we routinely will just be giving suggestions that can be completed with tab.
Extensions can do a similar flow to what they do today and provide the string to be displayed and handle what happens when the user tabs.
To be more clear, here is what I'm talking about:
The text was updated successfully, but these errors were encountered: