Skip to content
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

[FEATURE] Have wiki-tui act as a GNOME search provider #49

Open
2 tasks done
ThomasFrans opened this issue Jun 16, 2022 · 6 comments
Open
2 tasks done

[FEATURE] Have wiki-tui act as a GNOME search provider #49

ThomasFrans opened this issue Jun 16, 2022 · 6 comments
Labels
type: feature Implements a new feature

Comments

@ThomasFrans
Copy link
Contributor

Is your feature request related to a problem? Please describe.
I'm just throwing this out there as a nice feature for the application, but having the application function as a search provider in GNOME would be a nice touch. I don't know if it would fit in the scope of the project, so it's just a suggestion. It's absolutely not necessary, but it would make searching Wikipedia just that little bit easier, as most of the time you just quickly want to search a subject, and have the result be displayed. I haven't fully dived into the possibility of this feature, because I wanted to ask it first, but from what I understand, the application should add a GTK application struct (from gtk-rs, which I've used before, so I could help implementing this), and a dbus interface that listens for the different events of a search (start search, update search, select item...). Then the application would either open with the search, or change view to the search if there was already a window.

Describe the solution you'd like
Adding the ability for wiki-tui to function as a search provider in GNOME. It would allow the user to search for something in the general search bar of GNOME, and have results displayed in the GNOME UI, that allow the user to directly open wiki-tui for the specified page. It would have to be implemented as a feature, so it can be disabled on Windows, MacOS and other Linux distros.

https://developer.gnome.org/documentation/tutorials/search-provider.html#getinitialresultset-as-as

Additional context
The results would show up like the file explorer results, after which the user could select one and wiki-tui would display it.
image

Checklist

  • checked that this feature wasn't requested before in an issue
  • read CONTRIBUTING.md
@Builditluc
Copy link
Owner

Builditluc commented Jun 16, 2022

Yes, that would be a great feature for wiki-tui. I agree this would need to be a feature that can optionally be installed because only GNOME users could use it. As for the implementation, unfortunately, I don't use GNOME (I'm on macOS but have access to a NixOS machine) so I don't know what wiki-tui would need to be able to do for this to work.

When working on this feature I can set up GNOME and help developing it.

Because the current documentation (the readme basically) and contributing guidelines suck (sorry for the language but it's true) I want to set up a proper documentation website with mkdocs (basically you write .md files and it converts it into a nice website).

During that change, I think it would be good to bump wiki-tui to v1.0 and follow semantic versioning after that (don't know the details yet, but working on writing an issue).

Because of this, I can start / help on this feature in a few days / a week or so

@ThomasFrans
Copy link
Contributor Author

ThomasFrans commented Jun 17, 2022

Basically the high level steps we would need are:

  • Somehow implement the DBus interface (I saw there is a crate in crates.io made by the same guys that make gtk-rs that offers this)
  • Make a GTK application, which does all the magic to allow integrating with GNOME.
  • Make the search provider specification which needs to be installed in a certain place for the search provider to be found by GNOME (GNOME also uses the desktop file I added in a previous commit to show the search provider in settings, so the user can toggle it)
  • Every time the search provider is needed, the application is started if it isn't already running, and the virtual method startup() will be called in which you can do setup before answering through the DBus interface.

I'll try to figure out the specific steps and start working on this when I have time, and I'll open a pull request to get some help with the search stuff as I'm not that familiar yet with how that's implemented in wiki-tui 🙂

Also a mkdocs website would be great for new contributors. The README is fine, but it could use some improvement like you said :)

https://gitlab.gnome.org/World/Rust/search-provider (currently broken due to an error in the zbus_macros dependency)

@Builditluc
Copy link
Owner

Okay so I've read a bit through the search provider documentation on docs.rs and it seems like we need to have some sort of mode where we can search without having the UI. Maybe we could do that with a CLI argument (something like wiki-tui --gnome-search?)

I'm happy to help with the search stuff (the UI uses the wiki::search::SearchBuilder to search for articles. There you can set some settings and it will return a wiki::search::Search with all of the results and an offset for pagination. Maybe it can be used with the search provider?)

@0323pin
Copy link
Contributor

0323pin commented Jul 8, 2022

Sorry for jumping in uninvited. If you do this, please use dbus and not, zbus as the later doesn't build on NetBSD.

Actually, I hope this will be possible to fully disable so we can keep the nice TUI application that wiki-tui is free from freedesktop "conventions".

Thanks!

@Builditluc
Copy link
Owner

Hey @0323pin,

yes, I too hope it will be possible to disable it entirely. I thought of a setting you can change in the config file, so you have to enable it there (it won't be initialized if not enabled). However, with this approach, the libraries will still have to be compiled (just won't be used).

Would that be a problem? If yes, we can maybe put this into a cargo feature.

@0323pin
Copy link
Contributor

0323pin commented Jul 12, 2022

@Builditluc I'd rather have it as a cargo feature.
Even if it's on by default, I can switch it off on our builds.
If possible I'd rather avoid compiling the libraries, it keeps things cleaner.
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Implements a new feature
Projects
None yet
Development

No branches or pull requests

3 participants