View Issue Details

IDProjectCategoryView StatusLast Update
0014366ScribusUsabilitypublic2016-11-19 04:17
Reporterdabler Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
PlatformDesktopOSLinux UbuntuOS Version16.04
Product Version1.5.2 
Target VersionFixed in Version 
Summary0014366: page navigation at bottom of window greyed out when cursor positioned in text frame
DescriptionJust tried 1.5.2, the first thing I noticed apart from the interface redesign was that when editing the contents of a text frame, the page number and navigation arrows are disabled. I can get them back by going to the toolbar and selecting the Select Item (arrow icon) button. I prefer the 1.4.6 behaviour, where navigation to another page lost focus on any active frame. Better still would be to retain the cursor position if navigation away from then back to the same frame with no other action in between. Only lose focus if the frame is not visible when typing resumes.
 
Additional InformationGiven changed behaviour of the 'edit contents of frame' button, now shown as 'T in a box' icon, where it puts a blue circle on contents of an image frame (don't know what it does - looks like a rotate symbol in other packages), the select item arrow and edit contents T (would be better as an 'E') should be together on the toolbar as a Ying/Yang pair. Someone more steeped in the Scribus community might like to move this to wherever interface design issues are decided on.
Tagsdiscussion, gui, icons, navigation
PatchNo

Activities

Kunda

2016-11-16 03:40

manager   ~0042430

Last edited: 2016-11-16 03:40

View 2 revisions

> Just tried 1.5.2, the first thing I noticed apart from the interface redesign was that when editing the contents of a text frame, the page number and navigation arrows are disabled. I can get them back by going to the toolbar and selecting the Select Item (arrow icon) button. I prefer the 1.4.6 behaviour, where navigation to another page lost focus on any active frame. Better still would be to retain the cursor position if navigation away from then back to the same frame with no other action in between. Only lose focus if the frame is not visible when typing resumes.

what's an example usecase ?

dabler

2016-11-16 22:33

reporter   ~0042441

Not sure how to draw a usecase - I'll give you a Booch style scenario:
I'm editing a book. I'm in a text frame on page 47. I've just changed the tense of a verb. The next noun is a place name. I remember the same word was was used a couple of pages back. I want to check that the spelling is consistent for both occurrences.
In 1.4.6, I move mouse to the 'go to previous page' arrow at the bottom of the window click as many times as needed to find the page with the first occurrence, read it without attempting to change it, then click the 'go to next page' arrow the same number of times to return to the page I am working on. If I need to make more changes, I have to move to the top of the window, click 'Select Item' arrow move pointer back over the frame and double click to resume editing.
In 1.5.2, I first have to move the pointer to top of window, click 'Select Item' arrow, then to bottom of window to 'go to previous page' arrow, click - read -click 'go to next page'arrow to return to the frame I'm working on. Then I can just double-click to resume editing.
So in writing this out, I realise that 1.5.2 has altered the sequence of pointer movements and clicks, but not increased the work to to do this kind of check editing, which I do a lot of.
In my ideal process: edit, move pointer to 'go to next page' arrow, click as needed to re-read earlier page, move pointer to 'go to next page'arrow and click as needed to return to editing point, click to resume editing in that frame.
I would be happy to adopt a consistent behaviour of single-click to select frame and double-click to edit contents, just as happens when the file is first opened. The sequense is: open file, navigate to page with the frame that needs work, single-click to work on the frame, or double-click to work on the contents. There should be no need to go to the tool bar to click the 'select item' arrow, except in more complex cases where frames might be overlaid etc, but that is outside the scope of this scenario.

Kunda

2016-11-17 11:44

manager   ~0042446

@dabler seems like a relevant usecase. Thanks.
Devs, any comment?

Kunda

2016-11-18 03:15

manager   ~0042450

@cbradney thinks that it has something to do with a patch that @firash submitted in 0012692
More investigation needed

cbradney

2016-11-18 17:57

administrator   ~0042463

Last edited: 2016-11-18 23:03

View 2 revisions

So the patch by @FirasH actually fixes a couple of issues that I am not sure we would want to reverse.

2 things to note:
- Pressing escape will get you out of text edit mode (saving you moving the mouse around and clicking to deselect)
- Using a mouse with a scroll wheel will allow you to stay in edit mode but scroll away. Obviously that might be inconvenient if you are moving more than a few pages but it is an option.

Kunda

2016-11-19 04:17

manager   ~0042468

Is 0013271 related?

Issue History

Date Modified Username Field Change
2016-11-14 23:27 dabler New Issue
2016-11-14 23:27 dabler Tag Attached: discussion
2016-11-14 23:27 dabler Tag Attached: gui
2016-11-14 23:27 dabler Tag Attached: icons
2016-11-14 23:27 dabler Tag Attached: navigation
2016-11-16 03:40 Kunda Note Added: 0042430
2016-11-16 03:40 Kunda Note Edited: 0042430 View Revisions
2016-11-16 22:33 dabler Note Added: 0042441
2016-11-17 11:44 Kunda Note Added: 0042446
2016-11-17 11:44 Kunda Status new => acknowledged
2016-11-18 03:15 Kunda Note Added: 0042450
2016-11-18 17:57 cbradney Note Added: 0042463
2016-11-18 23:03 cbradney Note Edited: 0042463 View Revisions
2016-11-19 04:17 Kunda Note Added: 0042468