S,M,L connected to SpinButton

[fabienjuif]

related to #171

Idea is to simplify the UX a bit.

• The sizes are percentages
• We could add back button with a "size" that translate this way (this is what's exposed in the screenshot)
  • S(mall) => 33%
  • M(edium) => 100%
  • L(arge) => 300%

For now the PR breaks things, like

• Text inputs
  • Because the focus in always in the SpinButton atm

I find it more intuitive like this but this is maybe me? WDYT?

[fabienjuif]

[fabienjuif]

related #51

[fabienjuif]

WDYT @gabm @RobertMueller2 ?

I think it way more usable like this but I am biased ofc

[RobertMueller2]

Personally, I kinda like the S,M,L buttons. But I agree, they have some overlap with the annotation size factor, and now that that is exposed, maybe it is too complicated now.

Maybe we can use the S/M/L buttons to set certain (configurable?) values for the annotation size? EDIT: I think, maybe relative to the image size, although that could be tricky for different aspect ratios.

Let's discuss this a bit more :)

[fabienjuif]

I think this is what I suggest here (or at least try)

We could add back button with a "size" that translate this way (this is what's exposed in the screenshot)

S(mall) => 33% M(edium) => 100% L(arge) => 300%

There are not random values, this is values I tried in this PR and showed in the first screenshot.

Edit: and then we remove the x, the buttons are just a way to change the percentages with pre-defined values

[RobertMueller2]

ok, sorry, I suppose I got confused. Does indeed sound like the same thought.

[fabienjuif]

With latest commit I am unsure how to update the toolbar model on the action event yet

[fabienjuif]

At this stage I have s,m,l group buttons that modify the spin value. Before opening the PR, what I'd like is when I change the spin value for something <> than the s,m,l no button is toggled on

[gabm]

hmm gnome guidelines say:

Only use a spin button when the exact numeric value is meaningful or useful. If this isn’t the case, a slider might be a better choice.

https://developer.gnome.org/hig/patterns/controls/spin-buttons.html

maybe that's a better choice?!

[fabienjuif]

Maybe

adjusting the value relative to its current value is more important than choosing an absolute value

[RobertMueller2]

slider would also match #51 better. so there's that ;) but I didn't think that far when dealing with annotation size value.

[fabienjuif]

Ok so we are going closer to the first version I've made without the S/M/L buttons. And we could replace the spin with a slider.

If you feel this is worth a try I'll dig into that

[RobertMueller2]

Ok so we are going closer to the first version I've made without the S/M/L buttons. And we could replace the spin with a slider.

If you feel this is worth a try I'll dig into that

I think so.

• S/M/L provides something that isn't too technical, disadvantage: lacks fine control
• Spin Button provides more control, but adds technicality

The solution on main does indeed solve the issue of lacking control, but it also combines the disadvantages of both.

I think the slider is perfect here, really, fine control if done right, doesn't expose the technical stuff.

[gabm]

here are some ideas. I am unsure what GTK offers, Ill check...

https://www.justinmind.com/web-design/slider

(number 8 looks suitable)

EDIT: GTK Scale has marks .. https://docs.gtk.org/gtk4/class.Scale.html

[MangelMaxime]

When reporting #243, someone pointed me to this PR

I tested the behavior of numbered marker in this PR and they are really too big (even bigger than before) 😅

From top to bottom, I used L, M, S

And I think this problem is the same for other element, like if you try to create an array with L size I don't know in which scenario it could be practical.

When comparing Satty to previous screenshot editor tool I used, I find that the sizing are not really that useful and often off for example to get a good sized Numbered Marker I would need to use size S but then arrows, rectangle, etc. feels too small and I need to choose size M or change the scale factor. This makes it difficult to quickly edit a screenshot

[fabienjuif]

This PR aims also at simplifying our ratios for each tools. We would needs, as you point it out, to tweak them before merging this PR

edit:

If you play with this PR and find tool factor that you think are best, it would be cool to share this so I can try them out too!

[w-jablonski]

Numbered marker is something else than the other tools, which are line-based. It might be hard to find its default size (even when related to the line size or image size) that users would find satisfactory/non-surprising. So the user puts the numbered marker kinda "hit or miss" and will sometimes be dissatisfied with the size. So they hit Undo, resize with the slider or otherwise, and try again. And if still not satisfied, try again... Then once they've found the right size, now the size of other tools might be off...

Perhaps an alternative would be to have numbered markers resizable as they appear, in similar manner as the "Ellipse tool" is resizable with Shift+Alt held. Then the next marker by default keeps the size of the original one. I think splitting the sizing of numbered markers | line | text would benefit UX. Even better, this particular one is a non-setting (the user chooses, not us).

Thanks

[RobertMueller2]

Numbered marker is something else than the other tools, which are line-based. It might be hard to find its default size (even when related to the line size or image size) that users would find satisfactory/non-surprising. So the user puts the numbered marker kinda "hit or miss" and will sometimes be dissatisfied with the size. So they hit Undo, resize with the slider or otherwise, and try again. And if still not satisfied, try again... Then once they've found the right size, now the size of other tools might be off...

Perhaps an alternative would be to have numbered markers resizable as they appear, in similar manner as the "Ellipse tool" is resizable with Shift+Alt held. Then the next marker by default keeps the size of the original one. I think splitting the sizing of numbered markers | line | text would benefit UX. Even better, this particular one is a non-setting (the user chooses, not us).

Thanks

Hmm.. I can see some benefit in setting text and line width separately. But since the markers display text as well, surely that could be one setting for both, no?

Also, I'd say that resizable markers is not a thing in the other annotation tools I've used. I mean, sure, that's not a good reasoning at all. :D But I'd like to avoid creating something that is equally frustrating ;)