View Issue Details

IDProjectCategoryView StatusLast Update
0010928ScribusUsabilitypublic2016-03-31 17:07
ReporterJLuc Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Product Version1.5.0svn 
Summary0010928: CTRL+CLICK n DRAG Text Frame while in edit mode should move the frame
DescriptionNow :
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).
Tagsshortcuts
Patch

Activities

jghali

2012-07-21 23:15

administrator   ~0028541

>> 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.

ale

2012-07-22 06:57

manager   ~0028545

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 :-)

JLuc

2012-07-22 09:48

developer   ~0028547

@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.

cbradney

2012-07-22 10:05

administrator   ~0028548

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

JLuc

2012-07-23 08:34

developer   ~0028562

@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 ?

ale

2012-07-25 09:37

manager   ~0028604

gimp is using alt for this...

JLuc

2012-07-26 14:10

developer   ~0028648

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).

JLuc

2013-10-17 17:05

developer   ~0030735

Last edited: 2014-03-23 10:26

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.

ale

2014-10-14 08:48

manager   ~0034008

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).

jfl

2014-11-18 15:53

reporter   ~0034214

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.

Issue History

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