Statis of Bug 59390

[Kent Wilson <kenton wilson gmail com>]

Hello,

I came across the following bug report (#59390). In looking at the report it
seems that an attempt was made to add some APIs that would allow Pango
markup to be added to a text buffer (GtkTextBuffer). Has this work been
completed (The report status is 'FIXED')? I didn't see it listed in the online
API docs for GtkTextBuffer.  If I understood this correctly the purpose was
to allow someone to add Pango markup language to a GtkTextBuffer and in
doing so the text would be displayed in a GtkTexView with the section of 
text rendered with the given Pango markup "directives"  (i.e., bold or
underline text, font size change, color, etc.). Is this correct?

Kent

--- New APIs (?) ---

  - text_buffer_insert_markup() 
  - text_buffer_insert_markup_with_tag() 
  - text_buffer_set_markup() 
  - text_buffer_set_markup_with_tag() 
 
--- Bug Report 59390 ---

Reporter: jpritikin pobox com (Joshua N Pritikin)

> Is there an easy way to load Pango Markup into a GtkTextBuffer?
 
Nope.
 
> Or do i need to do it myself -- create the appropriate GtkTextTags, scan
> the string with a GMarkup parser, and insert chunks piece by piece?
 
This is essentially the problem, there are no default tags, and
inserting markup would require that.

So yeah, what you have to do right now is write your own gmarkup
parser that does this. You could of course start with pango-markup.c
source code, and change it to modify a text buffer instead of a
PangoAttrList.
 
Should think of a GTK 2.2 or 3.0 solution, no doubt this feature will
be popularly requested.

Havoc Pennington <hp redhat com>


------- Additional Comment #1 From Havoc Pennington 2002-02-22 12:27 -------

<rambokid> hp: peeking at the testtext example, it doesn't seem to
hard to add a function to your text widget taht inserts text with
pango markup.
<hp> rambokid: no it shouldn't be hard
<hp> rambokid: the only issue is what you do about the tag table
<hp> rambokid: one way is to require people to use the special "pango
markup tag table"
<hp> rambokid: another is to have
gtk_text_tag_table_create_pango_markup_tags() to modify any existing
tag table to contain the markup tags
<hp> rambokid: another is to have a markup language that's like <tag
name="foo">text</tag> and then work with any tag table
<rambokid> hp: you have tag names, i guess you'd add pango-* tags on
demand (i.e. if such a tag isn't already there) kinda like we use
qdata on widgets along side the user using qdata as well
<hp> rambokid: but that last option wouldn't use the Pango markup format
<hp> rambokid: that might be a good option, yes, to implicitly add the
tags when they are first used


------- Additional Comment #2 From Matthias Clasen 2003-02-05 10:31 -------

*** Bug 105313 has been marked as a duplicate of this bug. ***


------- Additional Comment #3 From Tim-Philipp Müller 2004-01-15 23:43 -------

Created an attachment (id=23423)
small test that implements text_buffer_insert_markup() and other
convenience functions


------- Additional Comment #4 From Tim-Philipp Müller 2004-01-15 23:49 -------

Attachement above is a self-contained test program that implements 
this functionality in a simple and crude way. 
 
It has four new functions: 
 
  - text_buffer_insert_markup() 
  - text_buffer_insert_markup_with_tag() 
  - text_buffer_set_markup() 
  - text_buffer_set_markup_with_tag() 
 
The _with_tag functions take an extra GtkTextTag to apply to the 
whole text, for word wrapping and justification parameters etc. 
 
Possibly it would be better to use GMarkupParser here and 
parse the markup ourselves. That would also allow us to 
expand the markup to include stuff like word wrapping and 
text justification, which cannot be set via pango markup. 
Additionally it would allow us to insert pixbufs with markup  
like <img file='foo.png'>. Or is that overkill? 
 
In any case, it would be nice if something like this went into 2.4, 
however crude it is implemented. In the worst case, one could point 
out in the docs that those functions are only suitable for short 
text. 
 
Cheers 
-Tim 
 
 


------- Additional Comment #5 From Tim-Philipp Müller 2004-01-16 12:30 -------

Created an attachment (id=23451)
Test app with text_buffer_insert_markup() implementation. This version
fixes memory leaks of the previous version.


------- Additional Comment #6 From Tim-Philipp Müller 2004-01-22 01:45 -------

Created an attachment (id=23628)
proposed patch that adds four new functions to the API


------- Additional Comment #7 From Tim-Philipp Müller 2004-01-22 01:54 -------

First of all, sorry for the flood. I thought it was better to post a  
sample first to see if my approach was right, but I guess it's  
better to just submit a patch. Won't do it again.  
  
  
The above patch introduces four new functions to the API, as  
described in my previous comment, ie:  
  
 - gtk_text_buffer_insert_markup()  
 - gtk_text_buffer_insert_markup_with_tag()  
 - gtk_text_buffer_set_markup()  
 - gtk_text_buffer_set_markup_with_tag()  
  
None of these functions takes a length argument. The markup text is  
expected to be NUL-terminated and will always be inserted fully.  
This is because the alternatives all seem a bit awkward to me.  
  
Any thoughts or comments?  
  
Cheers  
-Tim  
  
PS: maybe someone could change the keywords to API, PATCH ... 
 


------- Additional Comment #8 From Owen Taylor 2004-01-22 11:58 -------

Moving to 2.6 API Freeze since we have a patch. Haven't looked
at the patch or proposed API.


------- Additional Comment #9 From Elijah Newren 2004-03-10 16:14 -------

I'm adding the BLOCKED_BY_FREEZE keyword.


------- Additional Comment #10 From Tim-Philipp Müller 2004-06-15 08:33 -------

Created an attachment (id=28723)
same patch, but with 'Since: 2.6' in the description


------- Additional Comment #11 From Bug flys 2004-08-19 01:53 -------

What about markups which overlap to each others? something like:
  <i><u>2 tags text</i></u>
The real_insert_markup should check if the range of a markup overlaps with the
previous one and accumulate tags before insert.

Also a new tag is created for every markup encountered, that cause tags the same
markup being created. Shouldn't a hashtable of 'markup' -> tag be saved in the
textbuffer, so that tags can be reused by name?


------- Additional Comment #12 From Bug flys 2004-08-19 01:59 -------

or:
   <i>and <u>underline me </u> to stop it </i>.


------- Additional Comment #13 From Tim-Philipp Müller 2004-08-19 05:42 -------

I assume you meant  
 
  <i><u>2 tags text</u></i> 
 
? 
 
I would expect pango_parse_markup() to accumulate tags like that (I haven't 
actually checked whether it does though). 
 
I am not sure I understand the purpose of your last example <i>and 
<u>underline me</u> to stop it</i>.  
 
I agree a hash table that maps a certain format to a re-usable tag would be 
nice, but it doesn't seem worth the effort to me. In any case, this kind of 
optimisation could still be added later IMHO. Feel free to modify the patch 
though, or come up with a new one :) 
 
Cheers 
 -Tim 
 
 


------- Additional Comment #14 From Bug flys 2004-08-21 03:09 -------

About reuse the tag of a given markup, there is a function:

  GtkTextTag* gtk_text_tag_table_lookup (GtkTextTagTable *table, const
gchar *name);

A named tag should be checked first and if NULL is returned, a new one can be
created. No hashtable is neccessary.


------- Additional Comment #15 From Tim-Philipp Müller 2004-08-21 06:53 -------

When I said 'effort' I didn't mean the hashtable lookup or the 
gtk_text_table_lookup(), but rather the problem of 'I have this bunch of 
PangoAttributes with these values; how do I know I already have a tag with 
exactly the same attributes?'. 
 
Maybe this is trivial, but I don't see how to easily do it. Of course one 
could always serialise the attributes into a string again and derive a tag 
name from that, but I have my doubts that that would really be of advantage 
for the common case. Similarly, we could parse the attributes ourselves using 
GMarkupParser instead of pango_parse_markup(), but that seems like unnecessary 
code duplication for hardly any benefit to me. 
 
Cheers 
 -Tim