Flow.Launcher
Flow.Launcher copied to clipboard
Flow-Launcher
Insert active explorer path
I refactored the code from https://github.com/Flow-Launcher/Flow.Launcher/pull/904
Please test this code, as I haven't really done it.
Are we able to fix the CI build issue?
It's because of merge conflict. Just resolve it.
Are we able to fix the CI build issue?
It's because of merge conflict. Just resolve it.
Ah! Didn't see that. That's what I get for glancing.
@stefnotch Do you have time to remove the comreference and move everything to either dynamic or a template class? Then we shall be able to move to the final stage.
@taooceros Okay, I've changed it to use dynamic. However, I didn't test the code at all, since I don't have the .NET 5 framework on this machine. (Only got .NET 6)
@taooceros Okay, I've changed it to use dynamic. However, I didn't test the code at all, since I don't have the .NET 5 framework on this machine. (Only got .NET 6)
I think flow has been upgraded to .Net 6. The original pr is pretty old, so do you mind taking sometimes to merge the dev branch? Thanks
@taooceros Lovely, that's super nice to hear. Okay, I merged it in and tested it out. Seems to work rather nicely, the only thing I'd tweak is: The entire text should be selected when it automatically inserts the file explorer path. (aka it should be easy to get rid of the inserted file explorer path)
@taooceros Lovely, that's super nice to hear. Okay, I merged it in and tested it out. Seems to work rather nicely, the only thing I'd tweak is:
It does take almost a whole year for .Net 6 branch to be merged🤣. That's pretty nice. Thanks
The entire text should be selected when it automatically inserts the file explorer path. (aka it should be easy to get rid of the inserted file explorer path)
I am not sure whether it is easy to be done. I will reach back soon about that once I finish the current stuff.
One thing I am a bit worried by this feature is that it only applies to explorer plugin (although it is a built in plugin). Therefore, do you think it would be better if we put the code into plugin project instead of the main project?
Regarding text selection, there will be much more that needs to be done. Maybe we should expose an api for plugins to select a part of the query base on index. Another idea is to use a special actionkeyword to query only in the specific path. Thereby we don't actually need to handle the long preceding path (and also don't need to select it). However, that will lose us the possibility to traverse around it (but search around it may be enough?). If this way makes more sense, maybe we need a way to quickly switch to normal path search under the same path.
I think we can put the helper class in Flow.Launcher.Plugin project, since it maybe quite useful but somewhat non-trivial to implement.
Therefore, do you think it would be better if we put the code into plugin project instead of the main project?
Thought the idea was to expose this functionality via the API? If not then yes move it to plugin project so all plugins can take advantage of.
EDIT: functionality as in grabbing the active window, is this what you are asking?
Therefore, do you think it would be better if we put the code into plugin project instead of the main project?
Thought the idea was to expose this functionality via the API? If not then yes move it to plugin project so all plugins can take advantage of.
EDIT: functionality as in grabbing the active window, is this what you are asking?
I don't think we need to expose as api. It's nothing related to flow.
But isn't this functionality potentially can be used by several plugins e.g. Explorer & Runner plugins? Even though placing in the plugin project can achieve the same, but wouldn't putting it in API will mean it will be documented and potentially allow it to be used (assuming) by other non-C# language plugins?
But isn't this functionality potentially can be used by several plugins e.g. Explorer & Runner plugins? Even though placing in the plugin project can achieve the same, but wouldn't putting it in API will mean it will be documented and potentially allow it to be used (assuming) by other non-C# language plugins?
hmmm make sense? Though I think there's a really long path to allow non-c# plugin to use feature like this. I just feel like the plugin api may be better to include api that is configurable in flow or depends on flow. This looks like simply a utility function.
Yeah, at this stage, up to you guys, ultimately placing it in the plugin project is a good start.
Yeah let's put it into the plugin project first. We can add it to the api later.
I have a concern at the current stage. We actually allow customize the action keyword for exploring a particular directory. That means it is possible that the inserted directory won't do anything (which is partially why I think it would be better to move the code to explorer plugin, where it has control over its own action keyword).
@stefnotch maybe let's delay moving to Flow.Launcher.Plugin after we finish #1097. It contains too much change to explorer plugin that I didn't want to handle the merge conflict.
@stefnotch Let's make this a built-in command😉(Sorry for such a long delay).
https://github.com/Flow-Launcher/Flow.Launcher/pull/1474
@taooceros That sounds like a great idea! Would you like to take care of it, since it might take me a while to get around to doing so?
@taooceros That sounds like a great idea! Would you like to take care of it, since it might take me a while to get around to doing so?
yeah sure!
Hmmm I guess we need to adjust the logic a bit, since the shortcut will be activated after flow showing up, so the foreground window will become flow. What do you think about getting the explorer window with the highest z-index? @stefnotch
@stefnotch mind give it a test?
Assign something like this or use the custom shortcut 
