Things to improve in GtkTextView

For the past few years we have got a lot of people asking us (the gedit team) why we did not provide a way to split a document and visualize it with several GtkTextViews. In this post I will point out the three problems that stop us from doing it.

  • The cursor follows the insert mark from the TextBuffer.
  • The selection is managed in relation to the insert mark and the selection-bound mark.
  • The invisible tags are managed per document.
Why is this a problem?
  • Well right now the invisible tags are not a big problem as we don’t support code folding yet, but probably we will do it soon, although in relation to the inser and the selection it is pointless to split a document and use it from several views if you are editing a document and both views are following the cursor no matter if you are in one view or another.
What would be the way to fix this?
  • To manage the insert and selection-bound marks the GtkTextView should a per view-insert and view-selction-bound marks and follow only the ones set by it. The view should also modify the insert and selection-bound marks from the TextBuffer so this ones follow the ones from the view.
  • In relation to the invisible tags, I am not totally sure how the best way would be for this. Probably doing something similar as with the marks.
With this post I just wanted to point out these problems in case somebody wants to fix them 🙂
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Things to improve in GtkTextView

  1. Nelson says:

    I also take the chance to say it would be cool if someone can implement a useful feature that’s in other text editors, see http://bugs.gnome.org/96436 for details.

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

  2. nacho says:

    Some discussion from IRC:

    nacho: and about textview: I think you could handle invisibility with per-view textmarks, so you end up with a gboolean gtk_text_view_can_see_mark (view, mark)
    mmm
    nacho: i suppose you need this feature anyway for insert and selection marks (you can be sure that i’ll select a word in view 1 and then start editing that word in view 2, just to annoy you)
    so instead of having an invisibility mark
    we just have a mark that we just as invisible from the text view
    yeah
    textbuffer code does not interpret marks i think
    the marks that use mainly is the insert and the selection-bound
    those are then tracked by the view
    and the code that interprets them is textview specific – textlayout etc i tink
    see that marks != tags
    * Anxiety has quit (Leaving.)
    for invisibility we use tags
    true
    but the same thing applies
    pbor, ^^
    as I was saying to nacho in #gedit I think ideally all tags would need to be per view
    a mark for me is just a tag where the endpoint equals the startpoint
    yup
    so excuse me when i use those names interchangably 🙂
    well, or at least each tag should have a “tagview” object in the view (sorry cannot come up with a good name)
    so that for instance style associated with the tag is in the “tagview” object
    yeah
    you need another indirection
    this way we could have a syntax color for a “dark” text in a gedit tab, but a “light” color for the print view of that doc
    right
    but that’s a question of interpreting the tags
    tags should be per-buffer
    but interpretation should be per-view
    the “tagview” object would also have a flag that says if that particular tag/mark represents the cursor for the given view
    yep
    so a tag “comment” could be printed light, displayed dark and hidden in emails
    or whatever
    * ian has quit (ChatZilla 0.9.87 [Firefox 5.0/20110624090022])
    yep, there are many use cases that boil down to this separation
    I guess this would need an api break?
    not sure
    at the end of the road probably yes, but some prepatory changes could be done within our current bounds
    might be interesting to get done without
    but possible
    eg. the current tag properties could be overriden by a corresponding “tagview” object
    but fall back to current behavior if none is set
    i’d probably invent a new GtkTextTagBase class (or interface)
    and have GtkTextTag inherit from that
    unfortunately tags are not gobjects iirc
    and then you could do your own subclasses and have them implement a (* apply) (GtkTextTagBase *, GtkTextView *) function
    i think they are
    textappearance and whatever aren’t
    yep, they are

Leave a Reply

Your email address will not be published. Required fields are marked *