Closed joadoumie closed 1 week ago
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 IListPage
itself - the search box is owned by the page. That however would be very chatty to update. The host would call page.SelectionChanged(item)
and then asynchronously the extension would raise PropChanged("TextToDisplay")
, which then the host would call page.TextToDisplay
to fetch the new text. Three x-proc calls, every time the selection changes.
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 item.TextToSuggest
. Each item can suggest something if it wants.
heck I'm just gonna commit that right away.
~I suppose my last question is:~
Is the value of TextToDisplay
the whole string that we fill in the search box? Or just append?
So in the registry example: when the user has HKEY_CURRENT_USER\
in the search box, and has HKEY_CURRENT_USER\AppEvents
selected, is the TextToDisplay
"HKEY_CURRENT_USER\AppEvents"
Actually, IMO that's the only thing that makes sense. Cause then the user can type HKCU
and the TextToDisplay
is HKEY_CURRENT_USER
Okay I don't have any questions
Oh okay the PT Run stuff is weird.
Cause it displays ghost text of the TextToDisplay
of the first result, then when you up/down arrow, the TextToDisplay
actually gets added to the text box BUT doesn't filter it. But then if you backspace at that point, the text in the box gets committed.
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 TextToSuggest
, then something like HKCU
-> HKEY_CURRENT_USER
doesn't... really work at all. So, you have to modify the actual text box itself to display it. We'll have to be careful to track changes to the field caused by us showing previews, vs actual changes to the search caused by typing. We only really want to send UpdateSearch(query)
if the user actually types a character.
This merged in #145 and then also #150 (cause I botched that merge)
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: