New Bottom Help text
ClosedPublic

Authored by Leon0402 on Sep 2 2019, 10:01 PM.

Details

Summary

Changes to the text in the bottom help text include:

  • Add missing text: Mouse actions have been missing and have therefore been added
  • Improve code: Most of the texts have been similar, redundancies have been mostly removed
  • Make texts more clear: Especially the shift option has been added to the other texts to make clear that this is an additional feature, which can be used in these modes
  • Fix translation issues: texts have been seperated before for visual reasons, which makes translation hard. Splitting the text up should be done automatically (row wrap) or by the translator (add \n) ... for now the bottom help text is just wider, layout will be fixed in my other revision
  • Make model easier: Only one text each actions, code for layout is easier (see my other revision)
  • Updated texts for special modes: Some commands where not possible when "capture is enabled", others have been missing

Further ideas:

Mouse/keyboard actions should be the same e.g. shift should active fine-tune with mouse and alt should active magnifier with keyboard. This would allow to write a more compact help text.

Use icons instead of words (e.g. icons for right-click/left-click, alt, strg etc.): Icons would save space and are easier to read/use

Test Plan

Check if texts are correct (grammatically) and usefull. Check if there is any text missing for the different options. Suggestions for better texts, changes are very welcome

Diff Detail

Repository
R166 Spectacle
Branch
updateBottomHelpText2 (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 16089
Build 16107: arc lint + arc unit
Leon0402 created this revision.Sep 2 2019, 10:01 PM
Restricted Application added a project: Spectacle. · View Herald TranscriptSep 2 2019, 10:01 PM
Leon0402 requested review of this revision.Sep 2 2019, 10:01 PM
Leon0402 edited the summary of this revision. (Show Details)Sep 2 2019, 10:06 PM
Leon0402 edited the test plan for this revision. (Show Details)

+1

Mouse/keyboard actions should be the same e.g. shift should active fine-tune with mouse and alt should active magnifier with keyboard. This would allow to write a more compact help text.

Agree. I'm also not a fan of (+ key: action). Bu what about resizing then which is also Alt? Maybe it would be enough to do
Shift: Toggle magnifier/Fine tune selection
or

Shift + arrow keys: Fine tune selection
Shift + mouse: Toggle magnifier

Also I don't like Click here and drag. Just "drag" is maybe sufficient.
I just had another idea: We have multiple controls for the same action. What about switching the order of Layout around:

     Take screenshot: Enter or double-click
Create new selection: Drag outside the current selection
      Move Selection: Arrow keys 
                      Drag the current selection
    Resize Selection: Arrow keys + Alt
                      Drag drag handles ( <-- kinda meh) 
 Fine-tune Selection: Arrow keys +  Shift 
    Toggle magnifier: Shift while dragging 
     Reset Selection: Right click 
              Cancel: Escape

In Menus there is also first the Action then the shortcut.

src/QuickEditor/QuickEditor.cpp
535

Only mouse.

539–544

Same here and below.

540

I think Shift should be capitalized.

541

No magnifier here from my testing.

I just had another idea: We have multiple controls for the same action. What about switching the order of Layout around:

I really like this idea actually, that makes a lot more sense ... in general ... because usually you are searching for the action and then you want to know how to do it and with the current Layout it always felt the other way round

Also I don't like Click here and drag. Just "drag" is maybe sufficient.

Agreed e.g Drag inside/outside selection rectangle and drag resize handles? ... At least if that is proper English :D

Agree. I'm also not a fan of (+ key: action). Bu what about resizing then which is also Alt? Maybe it would be enough to do
Shift: Toggle magnifier/Fine tune selection

This is basically what we had before, the problem I had with this is that it's not clear, which actions exactly work with the shift option.
For example there is no toggle magnifier if you move the rectangle ... the approach with (+ key: action) makes very clear in my option, which additional options work where.
Additionally, it also saves some space in comparison to writing every command double with + shift

Perhaps we can have a look again with your new layout suggestion and see what other people think about that.

This is how it could look like. I really like it and perhaps we could add some styling to make it look better (but I'm not a designer, so perhaps someone else has a mockup for that then :P)

ndavis added a subscriber: ndavis.EditedSep 3 2019, 1:47 PM

This is how it could look like. I really like it and perhaps we could add some styling to make it look better (but I'm not a designer, so perhaps someone else has a mockup for that then :P)

Mouse actions should always be at the top, then keyboard actions, then modifiers (+Shift)

ndavis added a comment.Sep 3 2019, 1:50 PM

Also, "pixel-by-pixel" (there might be a better way to say it, maybe find it later) is better than "fine tune" because it's more accurate.

To be honest I'd say it'd probably look better if it's more in-line with how status boxes look on Discover (and throughout Kirigami, IIRC) style-wise with its background, border and shadows, but hey that's just my opinion on it.

To be honest I'd say it'd probably look better if it's more in-line with how status boxes look on Discover (and throughout Kirigami, IIRC) style-wise with its background, border and shadows, but hey that's just my opinion on it.

Fair point but this patch is only about the strings.

< Also, "pixel-by-pixel" (there might be a better way to say it, maybe find it later) is better than "fine tune" because it's more accurate.

I agree with you, could be better. I asked in the vdg group for name suggestions, hopefully some creative mind comes up with a good name for it :)

To be honest I'd say it'd probably look better if it's more in-line with how status boxes look on Discover (and throughout Kirigami, IIRC) style-wise with its background, border and shadows, but hey that's just my opinion on it.

I agree with you, but this patch is actually only about the content of the strings (and also a little bit about the layout of the strings), but not about the box itself. But I like your idea and a visual improvement for the Box is on my to do list :)

Leon0402 updated this revision to Diff 65362.Sep 4 2019, 9:39 AM
  • Result is now on the left side, action on the right side
  • Mouse Actions are above Keyboard actions
  • Word fine-tune replaced by more clear explaination
ngraham accepted this revision as: VDG, ngraham.Sep 4 2019, 2:00 PM

This looks fine to me now. Other folks?

This revision is now accepted and ready to land.Sep 4 2019, 2:00 PM
The-Feren-OS-Dev added a comment.EditedSep 4 2019, 2:01 PM

Alright, in terms of strings if I were to make one suggestion it'd be this:
Change the SHIFT tips to language like "(Hold SHIFT to Blah)" (e.g.: "Hold SHIFT to Magnify").

Leon0402 added a comment.EditedSep 4 2019, 4:09 PM

Alright, in terms of strings if I were to make one suggestion it'd be this:
Change the SHIFT tips to language like "(Hold SHIFT to Blah)" (e.g.: "Hold SHIFT to Magnify").

I'm not sure if I have a preference regarding this style and my suggested style. The only thought I had with my style is that (in a different revision) you could visually make more clear that this is the "additional options" line ...for example by making "+ Shift" bold or anything like that. So the user sees more clear that this is an additional option.
While with your suggestion, it might be more difficult to visually distinct them?

But as I said, I'm not really sure what I prefer. This was just a thought coming in my mind, so I would like others @ngraham @davidre @ndavis to comment on this and say there preference. This would also be a good place to make design suggestions (like I did above with the bold "+ Shift"). These suggestions will not be addressed in this revision, but they might help to decide what the best layout is?

Edit: Maybe someone also has a completly different solution for the shift option ... like a third column or anything like that? I personally think, the box is quite tall now (see updated screenshot)... although not incredibly high, I could still live with it

Leon0402 edited the test plan for this revision. (Show Details)Sep 4 2019, 4:15 PM

I'm okay with it the way it is now, though @The-Feren-OS-Dev's suggestion isn't bad either. I say we land it now and we can see how we like it, and if we want to further tweak it later, we can do that. Nothing's set in stone, so there's no reason to bikeshed. Git commits are cheap. :)

Sound good?

davidre added inline comments.Sep 4 2019, 4:54 PM
src/QuickEditor/QuickEditor.cpp
535

Small shift need to be "Shift"

535

Also this is not usinz the same style as in the other case with shift in a new line

540

Add some context to the last string that makes clear that shift is the key

541

Also here.

Leon0402 updated this revision to Diff 65381.Sep 4 2019, 7:02 PM
Leon0402 marked 5 inline comments as done.

Updated style for the other if branch

Leon0402 added a comment.EditedSep 4 2019, 7:17 PM

Would be great if someone could check again all options make sense in the different branches and I have not deleted any useful information accidentally.

I also noticed something:

IfI open spectacle and click in the settings "Accept on click and release" and in the comboBox below "Until Spectacle is closed" and then do a screenshot in the rectangular area mode, the standard text is shown and not the shorter one (Note: Only on the first run, the shorter one should be shown as there is no saved positition then). If I click in the comboBox "Never remember" everything works fine.

That is very strange, because it works in my master branch (as far as I can tell) and the second information shows that the if branch has to be correct (it also seems correct to me). Except from that I've changed nothing, so I don't know where this bug should come from.

Would be nice if someone can confirm this bug (and can confirm that in the master branch the bug wasn't there), maybe I just did something wrong.

davidre added inline comments.Sep 5 2019, 7:46 AM
src/QuickEditor/QuickEditor.cpp
531

You changed the condition here which is fine because it didn't work as advertised before. (It didn't take the picture after changing when you had release to capture and a remebered region was available after changing the size. I think you need to test for mSelection.size().isEmpty()instead of
!mRememberRegion

Leon0402 updated this revision to Diff 65411.Sep 5 2019, 11:02 AM

Changed if condition according to David's comment

*Bump*

Is there something holding this back to land?

ngraham accepted this revision.Sep 24 2019, 3:59 PM

Nah let's do it.

This revision was automatically updated to reflect the committed changes.