Long-term Roadmap: the future of espanso #255
Comments
|
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. |
|
@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 :) |
|
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 :) |
|
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
|
@atika this is very interesting! Thanks for sharing |
|
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. |
|
@macintacos Yes, that will come in the near future. |
|
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? |
|
@karanrajpal14 Thanks for pointing that out, I'll investigate |
|
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.
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. |
|
@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. ¯_(ツ)_/¯ |
|
@4lch4 @bashfulrobot I appreciate both of your comments, this is definitely some great feedback! |
|
@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. 👍 |
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
changed the title
|
@federico-terzi have you decided on the GUI using what library/framework? |
|
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:
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 :) |
|
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! |
|
@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 :) |
|
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. |
|
Hey @YourPsychiatrist, Thank you! Luckily, the project is far from being dead (see the
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 :) |
|
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 |
|
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 |
|
@quintrino Thanks for sharing! Looks very useful :) |
|
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? |
|
On second thought, I don't think I would like a web interface. 🤔 But then again, it might be the easiest solution. |
|
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. |
|
@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 |
|
Sure! So, all of the things I named are open-source:
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.
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.
I hope this helps! |
|
@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 |
|
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):
cheers ✌️ |
|
@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! |
|
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 |
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. Custom config locations should be fine. Adapters to something like Solid may be worth looking into. |
|
For the GUI, have you considered Flutter? Flutter apps compile from a single codebase to native applications everywhere: Android, iOS, Windows, Linux, MacOS, and Web. Flutter provides a great development experience, hot reload, and targets a fast & smooth 60 fps experience. There is also a generator for Flutter/Dart <-> Rust bindings. I've had excellent success building cross-platform apps with Flutter, and if it sounds appealing I am happy to work on this. 😃 |
|
As a code reviewer at IT courses I use espanso for review snippets. Writing them in yml file was super uncomfortable for me. So, I wrote a small workaround - otoe(obsidian to espanso). This allows you to write all the snippets with pretty GUI of obsidian and then just run the script and you'll have your espanso yml with all the notes. Maybe it will be interesting for someone. |
Cloud synchronization service
+1 to this! And syncing files is already easy using SyncThing or similar (as BashfulRobot pointed out). I would trust espanso less if it added cloud sync. |
|
I'd love to see #286 on the roadmap and/or a plan how to do it. You don't have to do all the work yourself ;) I'd love to help and I'm sure others will too. |
I agree, I don't think we need to have cloud sync. I use GitHub to sync my matches and share them with co workers. All they need to do is pull down the changes. |
|
I'm closing the issue mostly because of its age. We have some relevant info here, but in the most part this is solved in v2 |
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 coreis, 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 coredaemon.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.
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 :)
The text was updated successfully, but these errors were encountered: