After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 499916 - Can not insert gap in text buffer by using a GtkTextTag
Can not insert gap in text buffer by using a GtkTextTag
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-11-27 08:51 UTC by Miroslav Rajcic
Modified: 2018-04-15 00:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (2.38 KB, text/plain)
2007-11-27 08:54 UTC, Miroslav Rajcic
Details

Description Miroslav Rajcic 2007-11-27 08:51:54 UTC
Please describe the problem:
I am having a text like "0bullet" inside of GtkTextView, where the first 
character is a bullet sign and the rest is the ordinary text
I need to be able to format this text to insert some space gap between the 
bullet and the rest (should look like this: "0   bullet").

I've tried using tags in 3 different ways but none of these seem to work:

a) using "indent" property:

GtkTextTag *tag1 = gtk_text_buffer_create_tag (buffer, NULL,"indent", 
18,"indent-set", TRUE,NULL);
gtk_text_buffer_apply_tag(buffer, tag1, &iterBulletEnd, &iterEnd);

b) using "left-margin" property:

GtkTextTag *tag1 = gtk_text_buffer_create_tag (buffer, NULL,"left-margin", 
18,"left-margin-set", TRUE,NULL);
gtk_text_buffer_apply_tag(buffer, tag1, &iterBulletEnd, &iterEnd);

c) using "right-margin" property:

GtkTextTag *tag1 = gtk_text_buffer_create_tag (buffer, NULL, "right-margin", 
18, "right-margin-set", TRUE, NULL);
gtk_text_buffer_apply_tag(buffer, tag1, &iterStart, &iterBulletEnd);

where iterStart points to the start of text, iterEnd points to the end of 
text, iterBulletEnd points after the bullet sign.


Steps to reproduce:
1. Compile the sample code attached to this report (uncomment "#if 0" blocks to try individual attempts)
2. 
3. 


Actual results:
There is no visible gap in the view

Expected results:
There should be a gap

Does this happen every time?
Yes

Other information:
Comment 1 Miroslav Rajcic 2007-11-27 08:54:24 UTC
Created attachment 99700 [details]
test case
Comment 2 Olivier Delhomme (IRC : dup) 2007-11-27 12:27:50 UTC
I'm actually thinking to re-write a new GtkHex widget (To avoid numerous limitations of the actual GtkHex Widget) and I was planning to use a GtkTextView (to take its advantages - text marks and tags) but the hex data is usually represented by groups of 2 characters : "DE 05 F4 FF D9". So it would be useful if there is a way to do those gaps between characters (without having an additional space or a tab character). It might be very interesting to do this with tags, as one would be able to do whatever he wants with it !
Comment 3 Paul E. (Marbux) Merrell, J.D. 2010-01-13 13:22:09 UTC
I'll make a plea for giving this bug report a higher priority. It's now more than two years old and is blocking the proper rendering of ordered and unordered lists as well as blockquotes, each of which require two offsets per line. E.g., one may have a bullet flush left and list text indented, or one may have a bullet indented with the text in a list item wrapping to the same left margin as the bullet. But one can't have both the bullets and the text indented. 

Unless someone knows of a work-around?
Comment 4 Paul E. (Marbux) Merrell, J.D. 2012-04-15 21:08:54 UTC
We're now approaching five years since this bug was reported and so far apparently no one has even tested to confirm it. The bug blocks implementation of any HTML feature that requires more than a single horizontal alignment. E.g., ordered and unordered lists, blockquotes, tables, columns, etc. 

Perhaps it's time to put a sign on the Textview home page advising the unwary that it's a dead project and the code is no longer maintained?
Comment 5 taa 2013-06-25 03:21:29 UTC
Please confirm and address this long-standing GtkTextView bug. If more info is needed, please ask.
Comment 6 dhertrich 2013-06-25 05:19:54 UTC
This is one more plea to work on this with higher priority.
Comment 7 Matthias Clasen 2018-02-10 05:01:12 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 8 Matthias Clasen 2018-04-15 00:14:14 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new