Status of this project
isaacwisdom opened this issue · comments
Hello everyone,
First off, I'd like to apologize for the lack of work on this project in the past year. I know many of you use this tool as a part of your workflow on your reMarkable, and it's incredible for me to see how my simple wish to make the button on the Lamy pen actually do something is now used by so many people.
However, I'm a musician by trade, not a software developer, and I think I've reached the limit of what I'm able to accomplish here as a hobbyist. I also got an iPad about a year ago, meaning that I hardly ever touch my reMarkable. I guess I've joined the dark side, haha.
Anyways, I cannot figure out why this tool isn't working on software version 3.0.0.0. The most I can say is that the branch with the fix works on my reMarkable 2, and I don't know why it doesn't seem to work for anyone else. The way that this project fundamentally works (by simulating button actually taps on the screen by the user) was always a bit of a workaround and buggy ( perhaps just from poor implementation), and I think we've reached the limits of what this workaround can really accomplish.
Since I don't really use my reMarkable anymore, it's hard for me to justify putting more time into the development of this project, so I guess this is me officially stepping back. I won't be archiving the project, but I am going to switch the default branch back to v1. If you're brave enough to touch my spaghetti code, I'm happy to explain the overall structure to anyone who wishes to continue development on v2.
Thanks everyone,
Isaac
Hi,
First of all, thank you for creating this project. I understand that you probably won't get back to working on this project, but i may have found the reason it won't work for most users atm. I don't have the time to test this theory but maybe someone else can.
I believe most users didn't disable auto-updates and since the big update 3.5 the Layout of the pencilcase has changed. It used to be a "horizontal-dropout-thing" with a separate button for the stroke and color selection. Now it is an "all in one table shaped selection menu".
Since the selection of those things are actual taps on the screen and the positions of those taps are hardcoded in the effects_data header (?) i think tap-positions are just misaligned since the update.
Perhaps someone can validate this theory and (if true) change the positions accordingly.
Greetings,
Steffbo
Hello,
I can try on the RM1, if only I could get that Docker-thing talking to me...
@isaacwisdom thanks for all the work you have done.
I have identified a few problems with the current code; at this point, I managed to get things "running" in the sense that actions aren't ignored anymore, and things like the toolbar toggle on click even work as expected. However, as @St3ffbo pointed out, another issue is that the toolbar itself has changed quite a bit, and so new coordinates are needed in order to get everything working smoothly. Problem is that I have no idea how you populated effects_data.h, so it would be great if you could explain that!
EDIT: Repo available here, currently right-handed portrait mode works for notebooks and PDFs (though see slotThe@81f0850).
EDIT 2: Things may or may not work now with landscape and left handed mode! More testers are needed, though.
@slotThe
Hi,
on isaacs profile you can find another Project called "RemarkableGetScreenLocations". With this you can output screenTab coordinates to ssh-console. It has the old Layout as Template so you can tab on "fake button" and not activate them. Since we want the coordinates from the new button locations you can take some screenshots of the opened drawer with the help of the desktop share. Ive included an example, but you would need to import as pdf or create a Template from that. I hope this can help you in some way.
Ive got too much work atm but will certainly take a look this whole thing mid-October, when i have more time.
@St3ffbo thanks! That… sounds a lot more complicated than I anticipated :)
Anyways, for now I guessed some locations for notebook-right-handed-portrait-mode, and that seems to have worked; see here.
The main problem isn't actually this misalignment, it's that getOpenFileUUID always returns garbage. It seems to look for appropriate .lock files that just don't exist anymore (at least for me, the first grep command only returns the framebuffer). I suppose one would need to come up with a new way to find out what file on is currently editing. For now, I've changed getToolbarOrientation to just return default values (the afforementioned notebook-right-handed-portrait-mode); see here
Thank you so so much for your work! I just tested it out on my 3.7 version and the eraser worked great
I hope it isn't too gauche to announce a fork I've been working on: RMStylusButton. Instead of simulating touch events to trigger actions, it simulates keystrokes. This makes it insensitive to things like landscape mode and left-handed mode, and it should be more resistant to UI changes in new versions of the OS. This does restrict actions to those with keyboard shortcuts, which means it only supports erase, undo, and redo right now. If you want more configuration options, @slotThe's fork is definitely the way to go.