View Issue Details

IDProjectCategoryView StatusLast Update
0016186ScribusUsabilitypublic2020-08-18 19:17
Reporterale Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0016186: adjustement of the item size: use shift for top and bottom
Descriptioncurrently:

- one can use alt-arrows to change the size of an item.
- shift does the changes on the "other" direction.

i often use it and it's very useful, but i've always be surprised by the behavior of the shift key. it always takes some time to use it again correctly.

while explaining the behavior to somebody, an idea struck me.

what if the arrow would change the bottom and right sides.

- arrow right / bottom increases the right / bottom
- arrow left / bottom decreases the right / bottom side
- pressing shift switches the side where the change is applied (and not anymore the direction of the change):
  arrow-shift-top would then move up the upper side and arrow-shift-bottom move down the upper side.

my experience is that one spends more time tweaking the size one side (increase / decrease) and rarely adjusts both sides

if the change is the right one, we might need to have a configuration to switch the left / right default for RTL

i can work on a patch.
TagsNo tags attached.
PatchNo

Activities

ale

2020-07-27 11:45

manager   ~0047874

i'm working on this...

... but, first, the existing code needs some refactoring...

ale

2020-07-27 12:22

manager   ~0047875

i'm removing

                        if (m_view->m_ScMW->actionManager->compareKeySeqToShortcut(kk, buttonModifiers, "editClearContents"))
                            scrActions["editClearContents"]->trigger();
                        if (m_view->m_ScMW->actionManager->compareKeySeqToShortcut(kk, buttonModifiers, "editTruncateContents"))
                            scrActions["editTruncateContents"]->trigger();

when checking for the delete key.

the action is triggered by the action manager anyway.

ale

2020-07-27 12:29

manager   ~0047876

Question:

the left key has

                m_view->TransformPoly(10, 0, resizeBy/unitGetRatioFromIndex(m_doc->unitIndex()));

and the right key has

                m_view->TransformPoly(11, 0, resizeBy/unitGetRatioFromIndex(m_doc->unitIndex()));


if the off by 1 is needed, the reason should be documented.

any idea of the reason?

jghali

2020-07-27 12:41

administrator   ~0047877

As the TransformPoly function declaration indicates it, the first argument is not an amount, but a mode, so yes the off by 1 is needed.. and already documented by TransformPoly first argument name.

ale

2020-07-27 12:51

manager   ~0047878

ooooops... yes, i got it when looking at the key down...

you're not against using an enum for it, aren't you?

ale

2020-07-27 12:59

manager   ~0047879

is there any sane reason why CanvasMode::commonkeyPressEvent_NormalNodeEdit()

- is not split in multiple functions?
- and has so much repeated code?

or is just because it has been extended multiple times and got in this state?

ale

2020-08-18 19:17

manager   ~0047969

some files i had to reset for future reference...

canvasmode_normal.cpp (3,449 bytes)

Issue History

Date Modified Username Field Change
2020-07-23 11:56 ale New Issue
2020-07-27 11:45 ale Note Added: 0047874
2020-07-27 12:22 ale Note Added: 0047875
2020-07-27 12:29 ale Note Added: 0047876
2020-07-27 12:41 jghali Note Added: 0047877
2020-07-27 12:51 ale Note Added: 0047878
2020-07-27 12:59 ale Note Added: 0047879
2020-08-18 19:15 ale File Added: canvasmode.h
2020-08-18 19:16 ale File Added: canvasmode-2.h
2020-08-18 19:16 ale File Deleted: canvasmode-2.h
2020-08-18 19:16 ale File Deleted: canvasmode.h
2020-08-18 19:17 ale File Added: canvasmode_normal.cpp
2020-08-18 19:17 ale Note Added: 0047969