Option to allow static assignation of buttons functions on stylus or moving the bottom pannel to the left/right depending on dominant hand
Hi, first of all thank you for this wonderful project, Im a physicist and always used xournalpp but this project is such a breath of fresh air that I really want to migrate all my stuff.
I only have one major gripe with how the UI/UX is handled. Sometimes (and it happens frequently) whenever Im releasing the second button on my stylus another tool gets selected with the palm of my hand.
I know that this is actually a feature, to be able to switch on the fly both 1st and 2nd tool (1st and 2nd button), however, with the tooling panel placed where it is at the moment its way more frequent that I accidentally change tool compared to the intended use!
What I think could be possible ways to fix this issue and improve the UX are:
- moving the bottom panel to the bottom left or to the bottom right side of the screen depending on the dominant hand of the user (what i think its the easiest solution)
- moving the bottom panel and integrate it into the already present side panel (what i think its the cleanest option)
- adding an option to disable the ability to change the 2nd tool on the fly and handle them like how xournalpp does (what i think its the most pragmatic option)
Again, I'm really greatful for this project and I really look forward to what the new versions will bring to the table!
Cheers!
I'm not sure I understand correctly
Sometimes (and it happens frequently) whenever Im releasing the second button on my stylus another tool gets selected with the palm of my hand.
So an accidental touch on the bottom panel happening around the time you release the second button.
Is your second button recognized as an eraser ? You'd know if that's the case because changing the button shortcut for the stylus secondary button action wouldn't change what happens with it. I'm also asking because it feels like a palm rejection issue that coincides with a button press and an eraser to pen transition could explain why (because the sequence received is probably eraser -> eraser up -> pen down in that case). Also weird otherwise why that concern only one of the two buttons.
adding an option to disable the ability to change the 2nd tool on the fly and handle them like how xournalpp does (what i think its the most pragmatic option)
Afaik, everything that is set in the button shortcuts panel isn't affected by accidental touches to the bottom panel so I'm kinda confused by this
Sorry for the huge delay i've been really busy. Thanks for getting back first of all, sorry for not explaining my self correctly, first I'll address the points you brought up:
Is your second button recognized as an eraser ? You'd know if that's the case because changing the button shortcut for the stylus secondary button action wouldn't change what happens with it
Nope its not recognized as an eraser, I can freely change the action it performs.
I'm also asking because it feels like a palm rejection issue that coincides with a button press and an eraser to pen transition could explain why (because the sequence received is probably eraser -> eraser up -> pen down in that case)|
That's exactly what i thought too and to my understanding its exactly whats happening
Afaik, everything that is set in the button shortcuts panel isn't affected by accidental touches to the bottom panel so I'm kinda confused by this
I have set the secondary stylus button to be a temporary eraser, however I can always change its function with the bottom panel by selecting the new tool while holding the secondary button
On a general note, I think that placing a panel on the bottom side of the screen is a bit optimistic, it looks great tho. But the moment palm recognition glitches (i.e. whenever releasing one of the buttons) its almost guaranteed that you are gonna change the tool. And if you are in a hurry, its quite frustrating unfortunately.
Thanks again for your continued effort!
Cheers Filippo
I have set the secondary stylus button to be a temporary eraser, however I can always change its function with the bottom panel by selecting the new tool while holding the secondary button
Yes now I see the issue (you can change the temporary pen mode using touch whilst the pen is on the screen) Though it seems you cannot change the pen tool for the temporary button if you use the pen itself with the second button pressed and try to change the tool with the bottom bar.
So it's the second button tool that gets changed in the end ? (giving the timings it could be the main pen depending on how the temporary tool is released).
I wonder if I should disable the change of tools when the pen is drawing on the screen (and extend to hovering pens ?). The second option is maybe a little too much, but the first one would make sense (not sure a lot of people change their pen settings with the pen still drawing on the screen using touch).
Playing around there's some other cases where similar actions (active when the pen is drawing) don't make sense or behave differently depending on tools
- Changing colors and fills (will work for shapes, not for pen)
- Chaning pen/eraser sizes (won't work for pen, at least register for eraser)
- clicking on header buttons
So it's the second button tool that gets changed in the end ? (giving the timings it could be the main pen depending on how the temporary tool is released).
Correct, whenever i depress the button and maybe lift a bit the stylus (it might accidentally happen, I'll be sure to pay attention from now on) the palm touches the bottom bar changing the 2nd button tool. Meaning that the next time I go to actually use the 2nd tool I need to change it again.
I wonder if I should disable the change of tools when the pen is drawing on the screen
this is actually a clever idea! Another approach (that i just thought about) is to allow only the stylus to change the tools whenever the stylus is sensed by the screen. This way if someone casually needs to change tool it can be done via touchscreen. But when writing it kinda looks silly to move your hand out of the way and touch the toolbar with the other hand, whilst maintaining the right distance from the screen with the stylus, you simply tap the new tool with the stylus (least, this is what I usually do).
there's some other cases where similar actions don't make sense or behave differently depending on tools
I totally agree with you, you can obviously generalize the thought process in all the cases you cited
I've run into this issue a lot where my palm keeps touching the bottom bar whilst I have the buttons on my stylus depressed. I've opted to move the bar to the top instead to "fix" this after searching the issue tracker and not seeing similar issues - thought it was only me with this!
The patch is ugly and hardcodes a new position; I'm not sure if I've missed anything important in the code, but works for me. This is similar to how I have Xournal set up. The patch is here: https://github.com/Excigma/dotfiles/blob/trunk/modules/overlays/patches/rnote-move-pen-picker-to-top.patch
and this is how it looks:
just thought it'd be useful to share, it might benefit someone until a more thought out fix is implemented :).
Ok so, I've had a day to invest in this. Keep in mind that I've never even read a single line of gtk4 nor rust, so bear with me. I've had to vibecode a bit here, but in the end I decided it was better to search for the online docs of gtk4 rust, and that's where I made some tangible progresses.
So what I did:
- taking inspiration from @Excigma I've relocated the BOTH bottom and top panels to top left and top right (as it looks good IMO). Unfortunately I've had to fumble with alignment of the two panels, surely someone with more knowledge than me can fix this with waaay sleeker code.
- I've changed the minimum window width to 960px
- Lastly I got rid of the Gtk scrollers in the leftmost panel as it looked goofy and always out of dimension
Here's the result:
I'll make sure to upload everything on my repo and if the maintainers are interested push the changes!
Also, if possible, is there a way to compile this into a flatpak without using the devel profile ? I would love to maintain these changes (in case they don get adopted) and use it as a daily!
Also, if possible, is there a way to compile this into a flatpak without using the devel profile ? I would love to maintain these changes (in case they don get adopted) and use it as a daily!
The release flatpak manifest is available here : https://github.com/flathub/com.github.flxzt.rnote/blob/master/com.github.flxzt.rnote.yaml
And damn, I totally forgot about https://github.com/flxzt/rnote/issues/1450#issuecomment-2922981774