Better Keyboard API with Linux Support - Discussion

[momokrono]

Hi! I just wanted to start by thanking you for creating this amazing project! I've been trying it out for the past days and I love it.

As by the title, the binary created by the pyinstaller script doesn't contain the necessary icons, and this is a possible problem since after having compiled the project, the newly created binary is "bugged". What I mean is, all icons are missing and most importantly the tray icon doesn't appear, and the only way to stop the process is to kill it via task manager.

Ideally, since the images and icons used are quiet small, embedding them inside the binary should solve the issue without a noticeable increase in filesize, making the binary completely standalone and portable.

One particular thing I've noticed is the binary size: the one download from the release section is above 130 MB, while the one the pyinstaller build script outputs is around 66 MB, half the size.

While this can be fixed by copying inside the dist folder the necessary files, this should be written explicitly inside the README since for now it only lists installing pyinstaller and running the script.

Steps to reproduce:

• clone the repo
• create and activate a virtualenv
• install dependencies
• install pyinstaller
• run the pyinstaller-build-script

By the way, I've forked the repo to add Linux support and I got it working. In theory it should work on Mac as well, tomorrow I'll spin up a VM and post an update. If that's ok with you, I'll issue the PR.

[theJayTea]

Hey, thanks so much for your extensive work on a Linux port! :) I'd be super glad to accept your PR and add you as a key contributor in the app's About and in the README.

About the icons: I intentionally left the icons and backgrounds outside the binary so that people could customise them (people have already done so haha), and people have even asked to keep the prompts outside the binary in something like a prompts.json file. You're right that I forgot to mention this in the compilation part of the README, I'll fix it.

About the file size: I think I didn't set up the venv correctly when compiling, so it would've pumped up the file size as PyInstaller would've included other libraries from my pain Python install too.

I'll recompile it as soon as I can!

Thank you again for your work on the Linux version, that's awesome :D

[momokrono]

That is definitely a possibility I haven't considered!

I guess the issue's closed then.

About the PR: I'll clean the commit tree a bit and check if I can tidy up the code in general (refactoring, comments and so on) and I'll keep you updated. Thanks!

[theJayTea]

@momokrono Awesome, thank you again for your great contribution!

Just a quick heads-up: I’ve restructured the main repo to include platform-specific folders.

When you’re ready to create a pull request for the Linux version, please make sure your files are in a folder called Linux (root/Linux/). This way, we can merge it directly into the main branch without any issues.

Looking forward to your PR! :D

[theJayTea]

@momokrono I will also make you a collaborator with Write access, so you can edit the latest Release and add the compiled Linux executable :)

[momokrono]

Thank you, really! I don't know what to say ^^"

On this note, I've structured the code so that the program knows how to handle the operating system at runtime, importing the required packages and installing platform-specific dependencies when running pip install . after cloning the repo. In theory it shouldn't be necessary to split the code into Win/Linux/Mac subfolders, but if you prefer to do this then I'll revert the changes and create the different versions. You're the boss. Also, the only file requiring some adaptation is WritingToolApp.py since it's the one responsible for handling the keyboard.

For now, since Linux is a bit, let's say, weird, we should focus on the script postponing the release of a binary to a later date. Mostly because the hotkey works only on Xorg and not on Wayland (for all readers that don't know, Xorg is the old window system for Linux, Wayland is the new one and for security reasons it stops apps from reading the keyboard if they are not in focus, making the whole 'capture the hotkey' thing impossible). Nowadays almost every Linux distro moved to Wayland so I'm already thinking about how to tackle the problem. And Linux users shouldn't be scared of using a terminal to run a simple python main.py, in theory.

BTW, in the meantime I've fixed a bug where if during setup (first time use, accidentally moved/deleted config.json and so on) you close either the onboarding window or the setting one, the program runs in the background forever because the exit signal wouldn't be emitted and since the tray icon wouldn't be spawned you'd need to kill the process via task manager.

Like an idiot, I committed this bugfix to the main branch of my fork, so if you think this is an urgent fix I could create a new branch, commit the fixes there and create a PR with only the bugfix.

[theJayTea]

Ah, I see!

---

The reason I had created separate sub-folders for each platform is because:

• the macOS version needed a few additional changes (when using Writing Tools, it never pasted the response as focus did not automatically go back to the original window, so we needed code to manually remember and bring focus back to the original window).
• I'll be experimenting with more keyboard hotkey detection libraries on Windows, as with the current one, on some devices, the hotkey doesn't work after you lock and unlock the device. It'll just be more convenient to have separate folders for the codebase for each platform.

I hope it won't be too much work to revert that change? So sorry about this!

---

And got it, don't worry about compiling a binary, I'll leave that to your discretion.

---

Finally, thanks for fixing that! You could create a PR with that whenever you get the time (as it is luckily a rarer bug).

---

Thank you again for all your work here :D

Please do add credit to yourself as a contributor in the About section of the app! I'll copy this to the Windows version and to the main README.

Cheers!

[momokrono]

OK! I'll move the Linux code inside its folder then.

As a test, I tried running my code directly inside my windows VM removing the checks I added to switch to your code if running inside windows, and it works! For the Linux port I switched from the keyboard package from pynput.keyboard but it works in Windows just as well, being able to copy and paste no problem. I've checked the macos code and @kurcz uses pynput as well and handles the keyboard pretty much like I do, with these difference:

• I added a lambda to make the code more os-agnostic.
• I use the built-in pynput.keyboard.HotKey while he checks manually if the keys are pressed.
• he parses manually ctrl, cmd, alt and shift, while I transform the string from the syntax keyboards expects to pynputs's to handle the hotkey combination automatically. He also added a ctrl->cmd transformation, and I don't know if it's needed to invoke the popup but we should ask him.

So, since the pynput package works on Windows as well, if you were planning to move to it instead of using keyboard, with a single code we would cover every OS. The loss of focus I've noticed sometimes happens in Windows too, so we could implement too. Does it happen to you? Maybe it happens for me since I'm running inside a VM?

If you can and have the time, pull my code and try it, if it works for you and covers the hotkey problems you were talking about we could think about unifying the code inside a dev branch, to leave main clean.

And about the credit, I'll add myself once my contribution gets merged haha.

[theJayTea]

Hey @momokrono, thank you for the comprehensive explanation.

I just tried the current version of your fork (which uses pynput regardless of the OS) on my bare-metal install of Windows, and it works perfectly! The issue with it breaking on screen lock is fixed :D I think pynput is what I would have settled with anyway for Windows — I hadn't had time to experiment a bunch with different libraries due to my ongoing college applications.

And I haven't faced any loss of focus issues on my end, I tested it on 2 native Windows PCs. I'll keep an eye out for this though.

We can actually combine the codebase with pynput, at least with Windows and Linux for now. I'll ask @kurcz if it would be easy for him to join the combined codebase.

[momokrono]

@theJayTea Great!

The focus problems I was referring to were not troubles going back to the original window, but rather the popup not acquiring focus, making it so that I kept writing on the selected text instead of inside the QLineEdit of the popup, overwriting the text. I've added two lines that fixed the problem.

To be clear, this only happened inside a VM, probably because I launched it with with just a pair of cores and a handful of GBs of RAM, so I guess this should help on lower-end machines.

If you are OK with it, you/we could create a dev branch and I'll push there. While we are here, would you prefer a requirements.txt or a pyproject.toml? I used the latter to better handle the different requirements the different platforms had, but now that we are going towards a unified codebase we can just use a requirements.txt and be done with it.

[theJayTea]

I see, thanks for fixing that.

I've been testing out on different devices and it seems stable, so we could just directly push it to main if that's alright with you.

Just ignore the existing Windows and Linux folders (I can delete these), and push it to a new Windows and Linux subfolder.

A requirements.txt should suffice :)

[momokrono]

To be completely honest, I would prefer branching and pushing to dev, devel or however you want to call a development-only branch. The project is getting traction and tons of attention so I would prefer to have a main branch as clean as possible with bug-fixes and big features pushed there, with the occasional release tagged accordingly. And I had my fair share of "oh **** I've just pushed to production" moments while adding new features to personal/work code, screwing things up. The dev branch can be as "dirty" as you want, receiving updates, new features, allowing you and other contributors to quickly develop desired/required feats without risking pushing bugs and regressions into the "official" code. At the same time, people wanting the latest features can just use the dev branch knowing there could be possible bugs requiring fixes.

But you make the call!

Also, it could be worth spending some time writing down some contribution guidelines and setting up a possible "structure" to follow to better manage the project. For example, where to branch from to develop new features, how to make pull requests, write issues and so on. All of this can, of course, be updated/modified in the future, but it's good to have a basic starting point. Let me know what you think!

[theJayTea]

That's very sound advice, thank you.

I've created a dev branch that we can use!

I'll certainly get to that. Unfortunately, this coming week, I'm extremely busy with all my US college application deadlines coming right up haha, but I'll work on that and more bug fixes after this hectic week.

Thank you again for all your support and work on Writing Tools!

[momokrono]

Just pushed to dev! It's a pleasure, really :) If you want, you can close the issue.

[Seviks]

Thanks for your effort! I tried the dev-branch and I got this error:

  File "/WritingTools/Windows_and_Linux/WritingToolApp.py", line 170, in _show_popup
    selected_text = self.get_selected_text()
                    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/WritingTools/Windows_and_Linux/WritingToolApp.py", line 222, in get_selected_text
    clipboard_backup = pyperclip.paste()
                       ^^^^^^^^^^^^^^^^^
  File "/WritingTools/Windows_and_Linux/writer/lib/python3.12/site-packages/pyperclip/__init__.py", line 295, in __call__
    raise PyperclipException('Pyperclip could not find a copy/paste mechanism for your system. For more information, please visit https://pyperclip.readthedocs.io/en/latest/index.html#not-implemented-error' + additionalInfo)
pyperclip.PyperclipException: Pyperclip could not find a copy/paste mechanism for your system. For more information, please visit https://pyperclip.readthedocs.io/en/latest/index.html#not-implemented-error
On Linux, you can run `sudo apt-get install xclip` or `sudo apt-get install xselect` to install a copy/paste mechanism.

Obviously, I need to install more dependencies. I did install the packages in requirements.txt. However, the error persists. Could you help me you?

Edit: This is on PopOs 22.04. I installed 'xclip' and 'xsel'. 'xselect' was not available with apt.

[theJayTea]

@momokrono thank you for your work. I spent the last 2 hours working on it and improving a few other things, and I've put this version into Main.

1. I fixed the settings page being broken on your version, and made it shorter as it was too long.
2. Fixed some other bugs/improvements that are on the v4 release notes.

@Seviks, are you trying that on Linux? It worked fine on Windows for me.

[momokrono]

@theJayTea Awesome! Weird about the settings page, what was broken? I didn't notice problems on my end, maybe something changed while I was refactoring the code to push it into dev, but I'm happy you sorted it out.

@Seviks Here to help. I've noticed the last line you pasted suggests some packages to install, have you tried installing them? Also, could you tell me what distro you're using, what desktop environment and if you are on Wayland or X11?

[Seviks]

Sorry, I completely forgot about that. This is on PopOs 22.04. I've added the information in the post above. The docs in the error mentions also further packages. I installed 'xclip' and 'xsel' with no luck. Happy to deliver futher information.

[momokrono]

@Seviks I've tested the code inside a VM, PopOs 22.04 fresh install. It works after sudo apt install xclip, that was the only package I was missing. Mind that I rebooted after installing xclip to make it work.

Are you using Gnome or a different DE?

[theJayTea]

@theJayTea Awesome! Weird about the settings page, what was broken? I didn't notice problems on my end, maybe something changed while I was refactoring the code to push it into dev, but I'm happy you sorted it out.

If you're curious, the Shortcut Key and Theme options didn't show up in the settings page in yesterday's dev branch. If it actually showed up for you, maybe I broke something and fixed it haha.

Thanks again for the migration to pynput and the other bug fixes! Feel free to modify the README's contributor section or the About screen of the tool if you'd like (I added a blurb already).

[Seviks]

@Seviks I've tested the code inside a VM, PopOs 22.04 fresh install. It works after sudo apt install xclip, that was the only package I was missing. MIind that I rebooted after installing xclip to make it work.

Are you using Gnome or a different DE?

Hmm, it must be something on my end then. I can't understand why, though, since the installation is only a few days old. Error persists after reboot and package is installed:

It's default Pop Os, gnome-shell --version says GNOME Shell 42.9. echo "$XDG_SESSION_TYPE" -> x11

If it works on fresh install, I suggest you close the issue. I would comment if I found out something new. I also use the tool at work on Windows, and it works as intended there. Very helpful!

[momokrono]

Hi @Seviks, I'd rather not close the issue to fully understand what's going on. I've tested the code on Arch bare-metal and inside VMs, and a physical windows machine too. Having other users try it on bare-metal Linux machines is quite important, so that we can understand if the bug is in the code, pyperclip or some package on your system. And I hate the whole "it works on my machine, closing" thing. So I'd rather spend time debugging this and then create a wiki with a good troubleshooting section than leave you alone figuring this out.

If you run xclip in the terminal, does it print any error? What's your pyperclip version? Mine is 1.9.0, if you are behind you can try a pip install --upgrade pyperclip.

If you create a simple script with something like

import pyperclip

pyperclip.copy('test')
print(pyperclip.paste())

and run it from within the virtual-env, does it work? Does it give you any other info?

Also, please run echo $DISPLAY

One last thing: have you installed Gnome extensions to handle your clipboard or a different clipboard manager altogether? Or are you running "stock"?

[Seviks]

Thank you for your constructive approach, @momokrono.

The xclip command does not generate an error message; instead, it results in a blinking cursor on a new line.

I could resolve the issue when I tried the other steps you suggested. It was likely due to a problem with the virtual environment in VSCodium in a sh-Shell. Running the program in the bash terminal required installing python3-dev, python3-pip (i couldn't even run pip, I don't know why). After creating a new virtual environment (python3 -m venv writingtool) and running main.py, I encountered an error indicating that libxcb-cursor0 was missing (From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.). Installing this package using apt resolved the issue. A more direct way to run the tool would definitely be beneficial for users like me.

(echo $DISPLAY gave :0, pyperclip version also 1.9.0 and no gnome clipboard extension installed)

[momokrono]

@Seviks Glad you managed to make it work!

These days I'm a bit busy to work on this, but I'm already brainstorming ways to release a binary, ideally a flatpack or an appimage. While there is a script that compiles the project into an executable, flatpacks or appimages definitely fits better in the Linux ecosystem.

A binary isn't out yet since I'm alone working on the Linux side of the project, but hold still we'll get there.

I'll update the readme with a detailed, step by step guide on how to run it locally to ensure there is a way to make the code work for everybody.

Thanks for the feedback!