feat: shortcuts for color setters

[madonuko]

Add <Alt>1, <Alt>2, ..., <Alt>9 as the shortcuts for the color pickers (at the top of
the window).

[mahdi4261]

I really wanted that feature for a long time. Thanks for implementing that. But, this shortcut is already used for switching to specific tabs. For example Alt + 3 to go to 3rd tab.

[madonuko]

Didn't know that, I feel like it's more frequent to switch colors than to switch tabs, so maybe it's not a bad idea to remap tab switching to Ctrl+Alt+n?

[mahdi4261]

I agree with you that I rarely (probably never) switch tabs with that keyboard shortcut. I just reminded you about the conflict.

[Doublonmousse]

Pretty sure the shortcut is not set by rnote but by the use of Adw>TabBar in rnote for having tabs, and I'm not sure it's settable.

I'd be somewhat weird to have rnote be the only gtk/adwaita application where the Alt+<Number> keyboard shortcut for switching tabs didn't work so I'm not really in favor of overriding this keyboard shortcut.

I didn't know the shortcut and I'm not sure it not showing in the keyboard shortcut window is intended behavior (though that's a separate issue altogether)

[flxzt]

what about using ctrl+shift+<n> for switching colors?

[Kneemund]

Could you please run the formatter again? It seems like that small change made the line too long, which is why the CI is failing :/
LGTM otherwise, thanks!

[Atreyu-94]

I was thinking if there was still the possibility of adding a shortcut to make the fill or stroke transparent.

This would help us save one of the colors. Boxes without background and with background are usually used and right now there is no easy way to do it.

[flxzt]

hm, it does not seem to work on my machine, not sure why.

[Kneemund]

That's probably due to <Shift> being part of the shortcut, which makes keyboards produce special characters instead of numbers. GTK could handle this, but it doesn't seem to. Changing the shortcut to e.g. <Ctrl><Alt>{i}, like suggested above, works fine.

[flxzt]

Changing the shortcut to e.g. {i}, like suggested above, works fine.

sounds good to me.
These new shortcuts also need to be documented in the shortcuts window

I was thinking if there was still the possibility of adding a shortcut to make the fill or stroke transparent.

This would help us save one of the colors. Boxes without background and with background are > usually used and right now there is no easy way to do it.

Wouldn't using a transparent color as color field satisfy this usecase?

[Atreyu-94]

Wouldn't using a transparent color as color field satisfy this usecase?

No, because that way we lose a color. For example, if I have yellow selected, I would like to be able to select a key to give it 50% transparency and then return it. That would help me to have transparencies for each color and not a single color that I have to be constantly changing to achieve transparency

[madonuko]

I'm back! (?)

So I've been thinking: I started from assigning 1~9, then <Alt>1~9, then <Ctrl><Alt>1~9, and then I find myself barely using those shortcuts anymore simply because they are not really short-cuts.

I was like why not revisit the supposedly simpliest shortcut ver. and fix the issue? So here I am again back to 1~9.

Edit 1

Oh well this doesn't work because now I can't change the stroke thickness.
I'm no gtk expert so is there a way to add a condition for a shortcut?

Edit 2

Fixed that in the commit below.

[madonuko]

I'm back again! (?)

I've been using this for basically the last 2 months and I found no issues with the latest implementation!
Final to-do list for self:

• crates/rnote-ui/data/ui/shortcuts.ui
• fix merge conflicts
• make things compile

Status:

I'm getting checkmated by this because main introduced some breaking changes that I don't quite know how to fix at least without the help of lsp. And I can't get the lsp to run because I don't have the latest version of gtk4 on Fedora.

[madonuko]

Requires testing and approval

[madonuko]

I think the latest ver made it brokey again

• Ctrl + a → typing numbers ⇒ add new texts without replace
• Ctrl + 1 / 2 / 3 / … ⇒ nothing happens

I'm also thinking of setting 0 as the shortcut to make it transparent

[madonuko]

I added a println!() in the closure to action.connect_activate, and nothing gets printed when I press e.g. ctrl+1

I've no idea where the problem comes from…

[Doublonmousse]

mh ... Do you build with meson ? I'm having similar issue but on main directly with different behavior between a flatpak build and a meson one (the shortcuts ctrl+1 to 6 work on flatpak, but don't with meson).
If you run with GTK_DEBUG=interactive (and the flatpak equivalent), clicking on the GtkShortcutController

then shortcuts

they are listed.

But If I go inside Data and open the last one

the trigger is a list as expected on flatpak

with info

and

On a meson compiled version, well I get the same thing though the shortcuts are not strictly in the same order (just checked ... )

That's a mystery. Well I'm not going to complain too much if at the very least the flatpak version works. Smells like a weird gtk bug (or maybe a combined gtk/packaging issue ?)

And it works on the 0.12 flatpak but not the latest flatpak nightly ...

[madonuko]

yes I was building with meson (don't know any other methods)

I feel like there's something in gtk or adwaita not processing shortcuts correctly, especially since I think the major changes are well the code from master which I don't think is the cause, and my system upgrades which apparently updates gtk and stuff to newer versions

to confirm the conspiracy theory however we need a repro... and no idea how to test older versions of gtk on my system

[Doublonmousse]

Traced the ctrl+i shortcuts not working to a commit, should be fixed with #1515. I probably was on a not up-to-date branch so I didn't bissect this last time

[madonuko]

thank you so much!

[madonuko]

should be ready

[madonuko]

could somebody review?

[Doublonmousse]

For me this looks good.
The control shortcuts being the full list from 1 to 9 makes the shortcut window a little bit larger, but it's not a problem I think.