Add Info Window for displaying additional information from extensions

[DraggonFantasy]

This pull request introduces a new feature: the Info Window. The Info Window is a non-focusable, borderless window that can be displayed alongside search results. It is designed to provide additional information for selected search results, such as previews, descriptions, or other relevant details.

The Info Window can be utilized by extensions to display custom HTML content related to the selected search result. As a demonstration of this new functionality, I have implemented an extension that searches Wikipedia. When a user selects a Wikipedia search result, a preview of the Wikipedia page is displayed in the Info Window, allowing the user to quickly review the content before opening the full page in a web browser.

Here's a screenshot showcasing the Info Window with the Wikipedia search extension:

This feature will enhance the user experience by allowing them to access more information without needing to open a separate application.

Please review the changes and let me know if you have any suggestions or concerns.

[friday]

Thank you for the PR, but you really should have checked first before making this effort as this is not something we are ready for at the moment.

To implement this well you need knowledge about the current priorities (see #869), platform compatibility etc, and a lot of time. I don't want to add something that will not last, or that will create maintenance issues, or that won't work for all users. I want to replace the Extension Actions API completely, starting with v6 (#931). It is my top priority right now when I get time again. It should be backwards compatible for extensions, but I don't want to add anything new for the old API. I'm working on creating a new simplified and more consistent and opinionated extension API layer.

You also added on_select. So extensions would be able to do anything when the user select an item. But do we want them to be able to do anything or just this? What if some extension goes super creative and decide that instead of pressing enter to trigger the action, they run the main action when you select, causing an inconsistent user experience (see #326 for what I think about this). Also, if the first row has on_select, how do you select it? Do you have to go down and up again with the arrow key or does it pop up without the user actually selecting it? In that case won't it also fire up that window lots of times when you type the query?

There are other issues with it being a window also. It's not really safe to assume you have space on the right side of the Ulauncher window, or that that's where you want it opened. In Wayland when you can't position windows, this would position itself on top of the regular Ulauncher window. Also, if you can't focus on the new window, can you select and copy text from it? You can't do that now either (only if the extension uses the copy action), but for "more details" I can certainly see why people would want to.

We also want to make Ulauncher use less ram, and WebKit2GTK is a resource hog, doesn't work for all users (#114) and keeps itself running the background even after you close the window (although possible to force-kill it: #1064).

I prefer the design in #893 more, or to add it below the list item. But either way whatever solution we go with should work well with the rest of the API. In the meanwhile I think this is not something critical. You can open a URL in a browser

I won't close this though. It can serve as a reference/example implementation for the future or lead to more discussion.

My take on this:

1. It has to wait until after the extension API changes are completed for v6.
2. It should be triggered by an intentional user interaction, not happen unexpected. For example: All extension items with "more info" the result could be marked in some way (ex: 🛈 o "ℹ️") so the user knows it has extra info, then they can click that or press a special dedicated keyboard combination to show it (ex "alt+i").
3. It should show in the existing window.
4. It's probably impossible not to use WebKit2GTK for this, but at least it should close down the process after (Ulauncher already suffers from performance issues that I'm trying to improve).

[DraggonFantasy]

Thank you for such a detailed response. I didn't check the current priorities for this PR, because I've made this change primarily for myself as I'm going to use it with my own extensions made for my personal use, but also decided to share it with you or anyone who may want such feature. I expected that you're probably not going to merge it now, because when I was creating the PR, I saw that you're not adding new features until v6 is ready.

Maybe I'd take some of the issues you've mentioned and try to help with them if I have time, because I really like Ulauncher and want to make it better.

Regarding on_select - initially I thought to make it only capable of showing this extra-information window, but then I decided to make it more general and similar to on_enter or on_alt_enter to allow more "creative use", e.g. dynamic pagination of results or some fancy UX. I agree with you that it may be "too much", but it's just my opinion that it's nice when API allows more freedom, especially for such a software that is focused on personal performance/productivity.

The first item's on_select is triggered automatically (no need to go down and again up) - that's what I experience with my example wikipedia extension. When I finish writing my query and get list of wikipedia articles - I immediately get the information window with the preview of the first article. It feels like a natural UX, because I immediately see that the items have extra information and feel that if I select other items I'll get the extra info for them as well.

Agree on your points about a window.

1. Sure
2. I think it can be a setting like "show extra info on select", because I think some of the users would like to have the information shown immediately without need of extra steps to show it. If this setting is on - the info is shown on select, otherwise - it is shown on click/key press/whatever action from user side
3. Agree
4. Agree

[friday]

I think about 3 we can probably reach some kind of agreement. I definitely wouldn't want to load a browser engine making a web request every time I press up/down to highlight results, for performance reasons. I also don't want to completely opt out of showing extra details though, in case I want to do it occasionally.

I think extra steps are great UX. If you make the steps easy and performant people will learn them in their muscle memory.

Regarding on_select - initially I thought to make it only capable of showing this extra-information window, but then I decided to make it more general and similar to on_enter or on_alt_enter to allow more "creative use"

Ulauncher's extension API was originally designed like this, but that's what I want to get away from: https://blog.codinghorror.com/falling-into-the-pit-of-success/

Imo, when a user press enter, they should know what that does first. Same with alt-enter or any other action they can perform.

My vision for this:

• on_input should only yield results. Nothing else.
• on_item_enter is meant to be backwards compatible, but I want to add a replacement ex on_item_activate that should do the same, but have a stricter and simpler form:

1. If it returns a list of results, render that list.
2. If it returns a string, set the query to the string.
3. If it returns neither list or string it closes the app. To override this return True.
4. OpenAction, and CopyToClipboardAction should be regular functions that you can import and run inside of the method, instead of returning them. This way we no longer need ActionList
5. ExtensionCustomAction, DoNothingAction and HideWindowAction would also not be needed as a consequence of this, so it makes the API much easier.

Maybe I'd take some of the issues you've mentioned and try to help with them if I have time, because I really like Ulauncher and want to make it better.

That would be very much appreciated. I think you did a very thorough job on this PR, so your help would be appreciated. The areas that I think is most in need of help though is stuff that is kind of hard to explain, but I went through the existing issues and marked a few of them with contributor friendly.

#273 is something I intentional have been leaving for others as I'm not a Python dev.
#1148 and #1177 are sort of isolated from the API stuff, but they still aren't easy.