View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016186||Scribus||Usability||public||2020-07-23 11:56||2020-08-18 19:17|
|Target Version||Fixed in Version|
|Summary||0016186: adjustement of the item size: use shift for top and bottom|
- 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.
|Tags||No tags attached.|
i'm working on this...
... but, first, the existing code needs some refactoring...
if (m_view->m_ScMW->actionManager->compareKeySeqToShortcut(kk, buttonModifiers, "editClearContents"))
if (m_view->m_ScMW->actionManager->compareKeySeqToShortcut(kk, buttonModifiers, "editTruncateContents"))
when checking for the delete key.
the action is triggered by the action manager anyway.
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?
||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.|
ooooops... yes, i got it when looking at the key down...
you're not against using an enum for it, aren't you?
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?
some files i had to reset for future reference...
canvasmode_normal.cpp (3,449 bytes)
|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|