View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014366 | Scribus | Usability | public | 2016-11-14 23:27 | 2016-11-19 04:17 |
| Reporter | dabler | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Desktop | OS | Linux Ubuntu | OS Version | 16.04 |
| Product Version | 1.5.2 | ||||
| Summary | 0014366: page navigation at bottom of window greyed out when cursor positioned in text frame | ||||
| Description | 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. | ||||
| Additional Information | Given 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. | ||||
| Tags | discussion, gui, icons, navigation | ||||
| Patch | No | ||||
|
|
> 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 ? |
|
|
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. |
|
|
@dabler seems like a relevant usecase. Thanks. Devs, any comment? |
|
|
@cbradney thinks that it has something to do with a patch that @firash submitted in 0012692 More investigation needed |
|
|
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. |
|
|
Is 0013271 related? |
| 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 | |
| 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 | |
| 2016-11-19 04:17 | Kunda | Note Added: 0042468 |
