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

Long-term Roadmap: the future of espanso #255

Open
federico-terzi opened this issue Apr 29, 2020 · 35 comments
Open

Long-term Roadmap: the future of espanso #255

federico-terzi opened this issue Apr 29, 2020 · 35 comments

Comments

@federico-terzi
Copy link
Collaborator

federico-terzi commented Apr 29, 2020

Hello everyone!

We came a long way since the first version of espanso released in September 2019!

Slowly but steady, espanso is building a small community of users and I'm super happy about that.

At this point, I thought it could be a good idea to share my vision of the project, as well as the upcoming milestones that I would really like to bring to life in the future.

Roadmap

To give a better idea, I'll start referring to the current espanso project as espanso core.

There are 4 areas I'd like to focus my efforts on in the upcoming months (most probably years), that I think would really bring this project a step forward.

Keep in mind that maintaining espanso core is, and will always be, the priority.

Espanso GUI

Before you all start yelling at me, let me explain :)

Espanso is currently a tool for the tech savy, mainly developers and system administrators. These users have always been my top priority (being one of them myself).

That said, there is a huge part of users that would like to use espanso, but are not comfortable enough with terminals and configuration files to start using it. Moreover, even though I spend a lot of time in the terminal, there are times in which I would just prefer a nice UI when adding a match.

For this reason, in the future espanso will come with a GUI. Of course, you won't be forced to use it. In fact, I'm working hard to make it an optional component. In this way, a user could choose to use espanso in two different flavors:

  • Espanso-core: the current version of the project
  • Espanso-gui (actually the name still has to be defined): will bundle a GUI as well as the espanso core daemon.

Keep in mind that if you choose the GUI version, you will still be able to use espanso from the terminal (which to me is a priority).

Technical details

Creating a cross-platform GUI is not a trivial thing and there are a lot of compromises to be made. In the end, I settled with this approach:

The GUI will be based on a custom fork of webview, therefore built on top of Web technologies combined with Rust.
Compared to traditional Web-based approaches such as Electron, this package uses the default Operating System webview which will result in a very small executable size (2/5 mb instead of 50/100mb) and about half the memory usage.

After quite a bit of effort, I decided to avoid this route and I'm considering other alternatives. I went as far as implementing a pretty functional Windows version based on this approach, but the amount of effort required to make it cross-platform was really too much. Lots of new things are being worked on in this area, so expect many updates.

But why didn't you choose QT?

I experimented a bit with it, but I don't like the end result at all. Moreover, setting up a CI pipeline with it would have been problematic.

When will this come?

Hard to give a date honestly, after completing #594 we will move to this one.

Espanso Android

I've made a few tests on Android and thanks to the Accessibility APIs it's possible to create a text expander there as well. The main idea would be to extract the core features of espanso and package them as a native library. Luckily, Rust can be compiled almost everywhere :)

That said, I don't have a planned date for it. As soon as the GUI becomes reasonably stable, I'll move to this one.

Espanso Sync

This one is lower in priority, as you can already synchronize your espanso configurations between devices with a bit of work.

I would really like to create a built-in Cloud synchronization service. That would require creating a custom sync server (which you could also host yourself) and create a Cloud service for it. This approach would be more convenient for the end-user, as most people are using espanso between different devices.

The main issue is that hosting is expensive, therefore we would need to find a way to pay for these server costs. Ideally, we could find a cloud sponsor that offered that hosting for free to the project.

New Espanso Hub

The current package system is still very rough. I'm currently discussing with @timorunge about possible alternatives (see #253).

In the foreseeable future, we will probably leverage GitHub repositories, as they are free to use and already available.

In the future, we could create an interactive package repository such as PyPI, but that would again require a server and therefore a sponsor to pay for it.

How can you help

If you liked the project, there are a ton of ways you can help to bring these ideas to life:

Donate

If you have the possibility, a donation (even a small one) really helps :) It keeps me motivated and shows that people care about the results of my work :)

Share the word

If you liked espanso, please consider talking about it with your friends, on social media or writing a blog post about it! The more people get to know the project, the more likely it is for it to last in the future :)

Give feedback

If there is something you don't like, a feature you think would be useful or a bug, don't hesitate to open an issue or create a post on our subreddit.

Together, we'll build the first universal text expander, open for everyone :)

@bashfulrobot
Copy link

bashfulrobot commented May 5, 2020

One suggestion that might be easier for you. With regards to the sync system, an easier thing to do might be to allow custom configuration locations. Then the user can simply save their config wherever they want and use the sync system of their choice (ie - seafile, google drive, etc). This relieved you of the burden of operating service or taking into account potential personal information stored in the config (IE - phone numbers, addresses, etc).

The only thing I can think of that could be an issue is with confinement in the snap package. So that may need some reworking to allow access to the home folder (there is an interface), etc.

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented May 5, 2020

@bashfulrobot thank you for the feedback. At the moment, the sync system is just an idea and will probably take ages to see the light (if it sees it at all) :)

The current approach to use those cloud services is listed in the sync docs and is based on symbolic links, which is still a bit cumbersome but works :)

@bashfulrobot
Copy link

bashfulrobot commented May 5, 2020

Yeah - it accomplishes the same thing. :-) I was more thinking about down the line when you looked at introducing the GUI and making it more approachable to the none terminal users.

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented May 6, 2020

Yeah - it accomplishes the same thing. :-) I was more thinking about down the line when you looked at introducing the GUI and making it more approachable to the none terminal users.

Another user suggested the same thing, so I've opened an issue #267 if you want to keep track of that :)

@atika
Copy link

atika commented May 13, 2020

For macOS users, in the meanwhile, I wrote a simple script to add support for user input (text field and dropdown) into expanders using Pashua.

https://gist.github.com/atika/dc2de3f8813d9919485761347b200d61

espanso-popup-demo

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented May 13, 2020

For macOS users, in the meanwhile, I wrote a simple script to add support for user input (text field and dropdown) into expanders using Pashua.

https://gist.github.com/atika/dc2de3f8813d9919485761347b200d61

espanso-popup-demo

@atika this is very interesting! Thanks for sharing

@macintacos
Copy link

macintacos commented Aug 25, 2020

With regards to the UI, will there be the ability to search through existing snippets that you have configured while you're typing in a text field (via a global shortcut of some kind)? I'm thinking something like Typinator's Quick Search or TextExpander's equivalent.

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Aug 25, 2020

@macintacos Yes, that will come in the near future. modulo, the espanso's graphical component, already comes with a Search UI, but it's not wired yet. I have to stabilize the current version first :)

@karanrajpal14
Copy link

karanrajpal14 commented Sep 6, 2020

Any chance you could use GitHub Gists or Pastebin for online storage and syncing? VSCode Settings Sync used GitHub Gists to provide a similar functionality. Could you explore the same?

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Sep 7, 2020

@karanrajpal14 Thanks for pointing that out, I'll investigate

@4lch4
Copy link

4lch4 commented Oct 29, 2020

Hey @federico-terzi, I'd love to help with the sync portion of the roadmap. I'm not sure if there's an existing issue out there for it, but for some reason I'm really interested in adding this and have a few ideas for how to do it.

  1. We could do what @karanrajpal14 mentioned with Pastebin/Gists, similar to how VSCode Settings Sync works.
  2. Let users host their config files on an SFTP/Samba server of their choosing and perform a sync with the server specified by the user whenever the config is updated locally, etc.
  3. I'd gladly foot the bill for a droplet/space that could be used for an encrypted cloud storage where the user could provide their own encryption key and then whatever is stored on our end would be 100% encrypted and unreadable by us.
  4. All of the above. Let users choose to use their own Gists account for storing it privately there or on our own cloud-encrypted server.

I think aside from how and where to store the files, I believe the most important/difficult part is going to be nailing down the options for syncing. I believe the Settings Sync extension for VSCode has a great set of options that we could use as a starting point and trim down/add properties as we see fit for espanso.

@bashfulrobot
Copy link

bashfulrobot commented Oct 29, 2020

@4lch4/ @federico-terzi

I think I would look at a sync backend that can avoid being out in the public (yes, a private gist is better). Sometimes people may have some semi sensitive info in their expander. Like addresses and phone numbers, and maybe other things. I personally have already solved this issue by simply using a sync mechanism like Seafile (Dropbox replacement) on a private server. That however is not user-friendly to the average person.

I just think that it needs to user-friendly and accounts for sensitive or privacy-focused data. And not inadvertently leak the user's data, or inadvertently let a user leak their own data.

¯_(ツ)_/¯

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Oct 29, 2020

@4lch4 @bashfulrobot I appreciate both of your comments, this is definitely some great feedback!
I've got to be honest with you, I'm going through a super busy period of my life, so I can't dedicate much time to these proposals for the next 2 months.
I really hope you'll understand, and if you are still willing to collaborate, we can restart the conversation then :)

@bashfulrobot
Copy link

bashfulrobot commented Oct 29, 2020

@federico-terzi I'm all good! I appreciate the product even in its current form. it's probably one of the best text expanders on linux. I fully understand the whole busy life thing. 👍

@4lch4
Copy link

4lch4 commented Oct 31, 2020

@4lch4 @bashfulrobot I appreciate both of your comments, this is definitely some great feedback!
I've got to be honest with you, I'm going through a super busy period of my life, so I can't dedicate much time to these proposals for the next 2 months.
I really hope you'll understand, and if you are still willing to collaborate, we can restart the conversation then :)

No worries at all! I completely understand what you mean. I wish you the best, and look forward to hearing from you when the storm has passed 😄

@federico-terzi federico-terzi changed the title Roadmap: the future of espanso Long-term Roadmap: the future of espanso Feb 15, 2021
@xplosionmind xplosionmind mentioned this issue Mar 6, 2021
@100nandoo
Copy link

100nandoo commented Mar 8, 2021

@federico-terzi have you decided on the GUI using what library/framework?

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Mar 8, 2021

Hey @100nandoo,

I've been thinking about this for a while and, so far, my plan would be to adopt a similar approach to Telegram with tdlib and the Xi editor.

In particular, we would extract the business logic as a separate Rust library and build a number of "frontends" on top of it (probably using something like Protobuf to make communication easier between different languages and handle schema evolution).

The first front-end will be built using Electron. Despite being "sub-optimal" in many areas, Electron offers two advantages that are key in the first phase:

  • Fast time-to-market
  • Easy to iterate between different ideas/features

We will use the Electron implementation as a "testbed" to define the core set of features that will later guide the implementation of the native front-ends.

I personally like native UIs a lot, especially on macOS, but I think the Electron step is really necessary as implementing 3 different native UIs will be very time-consuming, and I want to give a reasonable fallback to users in the meanwhile.

I've also considered alternatives like Tauri, which is very promising but not ready for production use yet. Perhaps, I might consider it as an alternative to Electron, but I wouldn't bet on it. We can always port the Electron app to Tauri later.

Another huge advantage of the "common business logic library" approach is that if someone from the community is willing to create alternative clients, they will be easily able to do so :)

Let me know if you have any concerns!

Cheers :)

@richardlissimore
Copy link

richardlissimore commented Mar 8, 2021

As long as the GUI remains something that I don't have to have permanently loaded in memory whatever you choose is cool by me!

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Mar 8, 2021

@richardlissimore Absolutely! No need to keep the editor running after it has been closed. The only thing that will keep running is the usual espanso daemon, which is completely independent of the editor.

A necessary note is that the "core" espanso will be still supported, with the editor being an optional component. If you don't need the editor and would rather avoid using the storage for that, you could still download the "bare" espanso.

Another option that I'm considering is to expose a localhost GUI like Jupyter notebook or Syncthing from the espanso core, which would be very lightweight, running in the user's browser. The good news is that by following the Electron + Rust core library route, supporting this option would be just a matter of wiring things up differently. I would still prefer a stand-alone application, but I know a lot of people don't really mind and would rather save storage space.

Some people would also prefer a TUI #558. In this case, having a common core would be beneficial as well.

We are not at that point yet, so we have plenty of time to decide which option could be the best

Feel free to comment if you have any suggestion :)

@YourPsychiatrist
Copy link

YourPsychiatrist commented Jun 23, 2021

As a "long-term" espanso user I would like to help out with the project :) I saw that the last commit is some time in the past and was almost scared it had been discontinued.

So, are you guys interested in some help? I also experience some personal (little) bugs that I would love to investigate.

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Jun 23, 2021

Hey @YourPsychiatrist,

Thank you! Luckily, the project is far from being dead (see the dev-1.x branches for the latest developments) and I hope to ship an alpha version 2.0 by the end of summer :)

So, are you guys interested in some help? I also experience some personal (little) bugs that I would love to investigate.

I'd love to get some help once the alpha is released! At that point, all the feedback from the community will be immensely valuable :) Before then, there is really no much point, as the current version is going to be discontinued soon

Cheers :)

@YourPsychiatrist
Copy link

YourPsychiatrist commented Jun 24, 2021

Thanks for the answer @federico-terzi! I didn't go through the branches so that explains a lot :P I will gladly check that one out! thx

@quintrino
Copy link

quintrino commented Sep 26, 2021

With regard to Android integration.

On the off chance that someone else might get some value out of it, I've writing a ruby script here that converts an espanso file into a format that you can import into the Android text expander Texpand.

Still super eager for when Espanso hits Android because Texpand obviously has a different format for more advanced features, but it might help tide people over in the mean time with some of their basic expansions.

Thanks for making such an amazing tool @federico-terzi

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Sep 27, 2021

@quintrino Thanks for sharing! Looks very useful :)

@pedzed
Copy link

pedzed commented Nov 26, 2021

If Espanso will have a custom sync server, we might as well edit our config from a web interface.

I think a web interface is the easiest route to go for cross-platform compatibility. Those who don't trust the server can host one themselves, or of course, use the command line.

A native GUI would be best experience, but the time one can save using a web stack, could probably be better spent on the core code.

The primary thing I am thinking about being an issue, is signalling the Espanso client that new data is available. Websockets?

@pedzed
Copy link

pedzed commented Nov 26, 2021

On second thought, I don't think I would like a web interface. 🤔

But then again, it might be the easiest solution.

@eternaleye
Copy link

eternaleye commented Dec 16, 2021

Any thoughts on integrating on Linux via providing an IME plugin, either via existing protocols (display-protocol-native like XIM/wl-text-input, or existing IME services like ibus/fcitx5) or via toolkit plugins (GTK and Qt both have IME plugin interfaces that give you a lot of control)?

I ask because sniffing all input isn't especially portable (on Wayland, it's explicitly blocked as a security issue), but people do already use IME engines for similar use cases (in my case, I have an emoji database and a LaTeX sequence database loaded into fcitx5's table plugin), and their main weakness is exactly where Espanso is strong: they lack a large, easy-to-use corpus of drop-in databases.

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Dec 21, 2021

@eternaleye Thank you for the feedback! This sounds interesting, could please you point me to some open-source projects in that area? I'd love to investigate how those are working under the hoods

@eternaleye
Copy link

eternaleye commented Dec 24, 2021

Sure! So, all of the things I named are open-source:

  • XIM, the X Input Method is part of the X11 protocol, to see how to implement an input method that uses it, you can see how fcitx5 or ibus do so. If you support XIM, users who are running under X11 will near-universally be able to use your software, but it does nothing on Wayland. It also has somewhat limited functionality, and potentially poor-looking UI.
  • wl-text-input has the same relationship to the Wayland display protocol as XIM does to X11, and both fcitx5 and ibus both implement it, if you want to see how. Converse to XIM, this will give you near-universal support on Wayland, but nothing on X11. It's also quite new.

As for toolkits, both GTK and Qt support input methods that work via the above protocols, but you can get tighter integration (and more functionality) by directly implementing the toolkit-specific input method plugin interface. However, be aware - major toolkit versions need separate plugins. Qt 5 and GTK 3 are currently the most widely deployed, but both Qt 6 and GTK 4 are going to be much more relevant before long.

  • In Qt, the docs on QPlatformInputContext are relatively bare, but KDAB did a reasonably deep dive on the subject as well. In addition, fcitx5 and ibus have implemented Qt input method plugins. Supporting this will get you solid integration in any Qt-based application, including all KDE programs.
  • In GTK, the upstream docs are a bit more helpful, and both fcitx5 and ibus have implemented such plugins. This will get you solid integration in Gtk-based applications, such as Inkscape, Firefox, and Gnome-based applications.

Meanwhile, fcitx5 and ibus are basically frameworks to make it both easier to write input methods and to make any that you write more portable, by acting as a common interface (and single daemon) that integrates with all the platform-specific interfaces (such as XIM or wl-text-input) and all the toolkits (such as GTK or Qt). As you likely noticed in the above entries, implementing a plugin for either of these gets you all the others basically for free. In addition, you can ride on their existing documentation for getting the system integrations all set up, and they have GUI configurators for enabling their modules (unlike the other options). Another upside is that if people already use one of these for other reasons (such as CJK input), they won't be forced to choose between that and espanso - these support multiple plugins being active. I personally use fcitx5, but I used to use ibus and it has overall higher usage in the community as far as I know.

  • For fcitx5, you may want to look at fcitx5-anthy, a Japanese module for fcitx5 using the external Anthy library (as it shows integration of a third-party library with fcitx5 as an input method provider)
  • For ibus, it similarly has an ibus-anthy module, which should enable apples-to-apples comparison.

I hope this helps!

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Dec 24, 2021

@eternaleye Thank you for the detailed summary! That will be immensely valuable. I've opened a separate issue to go further in the investigation: #915

@deg0nz
Copy link

deg0nz commented Jan 5, 2022

Regarding the GUI part:

Maybe you already heard about these, but I will just leave this here just in case (since you are already using Rust):

  • Maybe Tauri is an option for the GUI (but it could also be too bloated for your use case)
  • Some days ago, I came across dioxus, which looked promising on first sight but is in a very early stage as it seems

cheers ✌️

@federico-terzi
Copy link
Collaborator Author

federico-terzi commented Jan 6, 2022

@deg0nz Thank you for the feedback! Tauri is indeed my first choice for now, but I'll have to properly investigate the downsides :) I didn't know about dioxus, I'll check it out!

@reesericci
Copy link

reesericci commented May 17, 2022

I was literally about to recommend Tauri for the GUI lol

@ZerkerEOD
Copy link

ZerkerEOD commented Jun 30, 2022

@federico-terzi, is there any chance that a search bar is coming to Linux or am I missing it somehow? Documentation makes it look like there is no search bar in linux.

Please ignore my above comment I had to change the key from the default and it instantly started working. It didn't like my alt key on my keyboard apparently

@reitzig
Copy link

reitzig commented Aug 19, 2022

I would really like to create a built-in Cloud synchronization service. That would require creating a custom sync server (which you could also host yourself) and create a Cloud service for it.

FWIW, I personally would be very sceptical about installing what amounts to an always-on keylogger that sends stuff to a public cloud by design.
(Self-hosting is a fine workaround, but not available to the less technical users you want to build sync for in the first place.)

Custom config locations should be fine. Adapters to something like Solid may be worth looking into.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests