View Issue Details

IDProjectCategoryView StatusLast Update
0010584ScribusUsabilitypublic2016-02-09 12:47
ReporterJLuc Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.4.1.svn 
Target VersionFixed in Version 
Summary0010584: Keep insertion mode after inserting glyph
DescriptionThe preselected glyphs pane makes inserting special glyphs really easy. That's great. There is however a little pain after the glyph has been inserted :

Just after the glyph has been inserted, the insertion mode is now lost. One has to click on the desired frame. This opens the frame in edition mode but the insertion cursor it at the begining of the frame. So one has to search for the previous typing or editing place, and precisely click on the right character so as to be able to go on with the editing or typing that this "insert glyph" behaviour has interrupted.

So as to smoothen the flow of editing, a valuable extra comfort would be brought when the insertion mode would not be lost, or would be recovered just after the glyph(s) is(are) inserted. The insertion carret would be placed just at the insertion place, after the inserted glyphs.



related to 0011721 confirmed SE defaults when switching away and back to Scribus  
related to 0013688 closedjghali Text highliting in Story Editor disappears after changing font 



2012-02-13 22:44

administrator   ~0027694

Unable to reproduce.


2012-02-15 11:05

developer   ~0027700

Well I cannot reproduce the "jump to begining of frame" behaviour, so it's not as bad as described ! I dont know how i happened to meet that behaviour.

AMOF : Inserting mode after inserting a glyph seems to be neither "editing content" nor "editing frame" : the move or change shape dots on frames corner are not there, but typing does not insert any characters neither.
So it requires one more click (on the place to insert) before being able to actually type. Maybe this click could be avoided.


2012-09-06 22:37

developer   ~0028914

After inserting a glyph through the "insert glyph" window, the editing carret keeps blinking in the edited frame, but amof the focus seems to be somewhere on the "insert glyph" window. To bring it back to the edited frame, one has to click on the edited frame, precisely at the edit place in text. If not clicked exactly on the edit place, the edit place is lost.

That is not specific to this tool but it is a hindrance for this specific tool. It would be nice when inserting a glyph in a text (and going on with typing the text) would be as easy as typing it.


2012-10-28 09:57

manager   ~0029110

could not reproduce...


2012-10-28 14:06

developer   ~0029121

Last edited: 2014-01-30 11:23

View 2 revisions

Reproduced once more.

I shall now explain using an example.

Imagine I want to type a "phone" sign in the middle of a sentence. For example "Office ( 032 3322 22 31" where ( has to be the phone glyph in some special font. This text is part of a large text, (large text possibly including many such special glyphs to be inserted)

- I am in wysiwyg mode of editing (not the story editor).
- I first type "Office " since it is the begining of the wanted sentence.
- Then i insert the needed glyph in the required font, using "Insert glyph" menu, then doubleclicking on the requested glyph.
- When this is done, insertion carret go on blinking in the wysiwyg. But if i type " 032..." (so as to go on with the natural typing of text) it is not ok : no text is inserted, nothing happens. I first have to click on the place where the glyph has been inserted, just after it.

This is a loss of time since it requires to aim precisely at the insertion point.
This is unfriendly since it breaks the typing flow and brings the machine in front of me instead of the machine gently helping me to do the work.

Scribus knows very well where the glyph has been inserted
and should bring the edit mode back to that point immediatly after the glyph has been inserted,
so as to enable the user to immediatly type text after a glyph has been inserted (that it : without having to first specify exactly where edit should happen).


2012-10-30 08:48

manager   ~0029131

ok, on a mac i could see the problem... (focus follow mouse, makes some things easier :-)

no idea how to solve this, though...

should the frame get focus after you click insert?

another idea would be that when an "active" frame gets clicked, the cursor is placed under the mouse only if the document was already active. otherwise, put the focus on on the text frame without moving the cursor.
no idea if this is possible to do...


2014-01-30 11:25

developer   ~0031228

Last edited: 2014-09-09 16:27

View 2 revisions

As is now, it is misleading because the inserting carret goes on blinking, as if in edit mode, but it is NOT in editing mode : typing is not recorded as long as one does not click inside the to-be-edited text frame.
Its misleading because "blinking carret" usually means "edit is possible".
As long as focus is not given back to edit window after insert action, shouldn't carret stop blinking as long as frame is not in edit mode ?


2014-09-09 16:25

developer   ~0033605

Last edited: 2014-09-09 16:28

View 3 revisions

As for a way to overcome the hindrance on Ubuntu 14.04 : using the Unity Tweak Tool, in the "Windows management" > "More tools" parameters, its possible to set the "Focus Behaviour" to "Auto-raise", and the "Focus mode" to "Sloppy". With such parameters, the focus is automatically given to the window the mouse hovers, thus enabling to type in the edited text frame.

Issue History

Date Modified Username Field Change
2012-02-13 22:38 JLuc New Issue
2012-02-13 22:44 jghali Note Added: 0027694
2012-02-15 11:05 JLuc Note Added: 0027700
2012-09-06 22:37 JLuc Note Added: 0028914
2012-10-28 09:57 ale Note Added: 0029110
2012-10-28 14:06 JLuc Note Added: 0029121
2012-10-30 08:48 ale Note Added: 0029131
2014-01-30 11:23 JLuc Note Edited: 0029121 View Revisions
2014-01-30 11:25 JLuc Note Added: 0031228
2014-09-09 16:25 JLuc Note Added: 0033605
2014-09-09 16:26 JLuc Note Edited: 0033605 View Revisions
2014-09-09 16:27 JLuc Note Edited: 0031228 View Revisions
2014-09-09 16:28 JLuc Note Edited: 0033605 View Revisions
2015-10-02 19:22 JLuc Relationship added related to 0011721
2015-10-02 20:40 JLuc Patch => No
2015-10-02 20:40 JLuc Description Updated View Revisions
2015-11-25 01:17 Kunda Tag Attached: #please_test
2016-02-09 12:47 Kunda Relationship added related to 0013688