GNOME Bugzilla – Bug 57050
Don't display selection for unfocused view
Last modified: 2014-08-03 18:57:12 UTC
The position of the blinking insertion cursor in the GtkTextView is determined by the position of the "insert" mark, which is stored at the GtkTextBuffer level. Because this mark is associated to the buffer rather than the view, all views associated to the same buffer share the same insert cursor. In terms of user interface, this means the following behavior: - when moving the insert cursor in one view, the insert cursor in all other views will move as well. - when selecting some text in one view, the selection will be displayed in all other views as well. In the context of our source code editor, this leads to some rather unusual behavior which we can't seem to be able to override. For instance, a developer might want to edit 2 sections of a file using 2 views located at 2 different locations of this file. In my opinion, it would be more logical to have the insert point and selection marks to be moved to the GtkTextView level, since these concepts are graphical concepts.
This is pretty much undoable. It would break the API in a pretty major way, and require a lot of reworking/redesign. Emacs has the current text widget behavior. MS Word almost does - it remembers the cursor/selection per-view, but only displays them in one view. This would actually be easy to allow in the current widget; it already displays the cursor only in the focus view, if we change that to also only display the selection in the focus view, then you would simply have to record the cursor/selection on focus out, and restore them on focus in, to get the MW Word behavior. There's always the option to have two buffers and keep them in sync... Anyway I'm retitling the bug to "Don't display selection for unfocused view," that is not an API-affecting bug, this should allow you to get the MS Word behavior without too much trouble.
We originally tried the "enter/leave" event strategy which was not very successful. I forgot the "focus_in/focus_out" events, and they work like a charm. Thanks! For the record, having 2 buffers is not as attractive, because the user can potentially manipulate large files. For instance, we have one file in the GNAT sources which is ~500K... I aggree this is a rather extreme case, but it would be a shame not to use the MVC aspect of this new widget. I also think this is a good idea not to show the selection when the text view does not have the focus. Should I create a new bug entry for this? Will you keep this API change in mind for the next major version of gtk+ (2.2?)? Wouldn't it make sense for each view to have its own insertion cursor?
There's no need to create a new bug entry I've "converted" this one. If we change anything for 2.2 I think it would just be to do what I've described for focus in/out automatically; I'm not sure that's correct, but maybe it is.
We gave a try to the idea of saving/restoring the "insert" mark when receiving focus_out/focus_in signals. This works fairly well except for a nasty little detail: we forgot the "selection_bound"... Suppose we have 2 views of the same buffer. When going from the first view to the other, we save the insert mark on one side and restore it on the other side. The location of the "selection_bound" mark and the "insert" mark thus become instantly different, which creates selection zone in the buffer. On the other hand, if we save both marks, moving from one view to the other would cause a selection zone to mysteriously disappear, and even maybe a different one to re-appear... I think the least disturbing behavior is to move both marks to the same place when gaining the focus. Although we will loose the current selection, we will not re-create the old one. However, I suspect all users will think of this as a bug when this happens. Having a better approach would clearly enhance the reusability of this widget. Apart from the idea of having 2 buffers in sync, there does not seem to be any way out. PS: Is it better to discuss this issue through bugzilla or should I switch to gtk-devel?
Right that's why I say to make this work we have to not render the selection in the unfocused widget. Then you could implement whatever save/restore behavior seemed right for the selection. gtk-devel-list is fine, or here in the bug is fine. If you post to the list probably you want to add a note to the bug with a link to the list thread in the list archives.
Hmm, I think we just changed the widget to display the selection in a faded color when unfocused. That behavior seems to contradict this bug. We need to sort it out... Rationale for the faded color IIRC was that since you can paste the selection with middle mouse in X, it's nice to be able to see the current selection?
If we want to show the faded selection when unfocused by default, then we would need to add API to let you turn off showing any selection when unfocused - simply setting selection color to base doesn't work, since tag colors would be lost. i.e. there is no hack to do this, text view API is required. Which means this is an API bug. I really hate "gtk_text_view_set_no_selection_when_unfocused()" though - I'd want something more like gtk_text_view_set_selection_per_view() or the like, I don't know. It's kind of a can of worms. I think we're just going to have to suck it up, and solve this in 2.2. It's just too unclear what should or could be done in the 2.0 timeframe.
For a different solution to the same problem, see bug #601677.
lets close this one and keep the other bug