View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0010928 | Scribus | Usability | public | 2012-07-21 21:27 | 2016-03-31 17:07 |
Reporter | JLuc | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.5.0svn | ||||
Summary | 0010928: CTRL+CLICK n DRAG Text Frame while in edit mode should move the frame | ||||
Description | Now : When editing a text frame, the CTRL KEY has no effect. Its useless. + When editing a text frame, it requires to move outside of text frame and click on a blank space (with no other text frame) so as to leave edit mode : these move are a loss of efficiency. Then, one has to doubleclick again so as to enter again edit mode. Suggestion is : It would be very handy when CTRL + CLICK'n'DRAG on the frame being edited would move the currently edited frame and *without leaving edit mode* (= going back to it as soon as click'n'move has ended). | ||||
Tags | shortcuts | ||||
Patch | |||||
|
>> When editing a text frame, it requires to move outside of text frame and click on a blank space (with no other text frame) so as to leave edit mode Simply press Escape. |
|
yep, i'm not sure that ctrl-click really brings a benefit here. the capability to edit the frame size and position while being in edit mode has already been requested in the past and it is possibly legit. nit i'd go for a more general way: an example would to keep the handles always enabled and moving the frame by clicking on its borders, at a place where there is no handle. if this is feasible, it would be a nice add to scribus :-) |
|
@jghali : yes ESC leaves edit mode and is easyer than clicking away. However, in my experience, it requires more mental steps when all i want is to move the frame while going on with the editing: 1) ESC is an explicit request to exit edit mode 2) moving the frame is the only actual wish 3) doubleclick or E is a new explicit request to enter edit mode again. 1) and 3) are technical steps that dont fit the mental situation and workflow. CTRL+MOVE is only one mental step : exactly the desired action. @ale : that could be an alternative but 1) the borders lead to resizing now, not moving + 2) having "frame editing mode" and "content editing mode" together makes the editing less secure : rising the risk of conflicts when clicking close to the border... OTOH CTRL+MOVE is restricted to moving, but it could be extended to include resizing : when the CTRL+CLICK'n'MOVE is in the center of the frame, it moves it, and when the CTRL+CLICK'n'MOVE is in on a border or on a corner it resizes the frame. CTRL is required and prevents conflicts. |
|
We used to have frame resizing and moving capability while in edit mode in the past, but it causes issues with updates and complicates a lot of things |
|
@cbradney : You dont give details but it reads like a programming issue. Do you think the use of the CTRL KEY modifier would avoid complicating things ? |
|
gimp is using alt for this... |
|
Key points are : - there is no increased complexity for the beginner (the beginner doesnt notice any change unless volontarily searching for it) - there is improved UX for the poweruser. Both CTRL or ALT would be fine for the poweruser, since both are available for this task. Poweruser would probably be quick to get used to it once used a couple of time, since "new behaviour to acquire" is directly linked to "desired action" (no intermediate steps). |
|
As for now, moving the viewport can only be achieved with the scrollbars or with mouse-MIDDLE-button CLICK'N'MOVE. This is standard for linux but there is no hint for it. As a consequence, the way to move a frame within its page when in edit mode could logically be a variant : (CTRL or SHIFT or ALT) + (mouse-MIDDLE-button CLICK'N'MOVE). As for now : - ALT triggers a mousepointer change, like for a guide setting, but it seems there is nothing behind that mousepointer change. - with SHIFT is the same as without SHIFT : it triggers the viewport change. - with CTRL, mous-MIDDLE-button click'n'move does nothing. Unless i miss some feature i could not spot, it looks like none of these is required and all 3 seem possible candidates for an "edit-mode frame move" action. |
|
i still think that this should be done without adding a modifier. if we want to allow the user to resize/move/rotate the frame while being in edit mode, we should show the handles (and define a way to move the frame from its border). |
|
Being able to move/change the size of a text frame while in edit mode is a feature I use all the time in InDesign. It's a big time saver when busily editing a bunch of small text frames that need to be adapted somewhat closely to their contents. |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-07-21 21:27 | JLuc | New Issue | |
2012-07-21 23:15 | jghali | Note Added: 0028541 | |
2012-07-21 23:15 | jghali | Severity | major => minor |
2012-07-21 23:24 | jghali | Severity | minor => feature |
2012-07-22 06:57 | ale | Note Added: 0028545 | |
2012-07-22 09:48 | JLuc | Note Added: 0028547 | |
2012-07-22 10:05 | cbradney | Note Added: 0028548 | |
2012-07-23 08:34 | JLuc | Note Added: 0028562 | |
2012-07-25 09:37 | ale | Note Added: 0028604 | |
2012-07-26 14:10 | JLuc | Note Added: 0028648 | |
2013-10-17 17:05 | JLuc | Note Added: 0030735 | |
2013-10-17 17:18 | JLuc | Note Edited: 0030735 | |
2013-10-17 20:23 | JLuc | Note Edited: 0030735 | |
2013-10-19 21:54 | JLuc | Note Edited: 0030735 | |
2014-03-23 10:26 | JLuc | Note Edited: 0030735 | |
2014-03-23 10:27 | JLuc | Tag Attached: poweruser | |
2014-03-23 10:27 | JLuc | Tag Detached: poweruser | |
2014-03-23 10:27 | JLuc | Tag Attached: poweruser | |
2014-10-13 16:03 | Kunda | Tag Detached: poweruser | |
2014-10-14 08:48 | ale | Note Added: 0034008 | |
2014-11-18 15:53 | jfl | Note Added: 0034214 | |
2016-03-31 17:07 | Kunda | Tag Attached: shortcuts |