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 643732 - Source view is created with a GtkTextBuffer instead of GtkSourceBuffer
Source view is created with a GtkTextBuffer instead of GtkSourceBuffer
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: General
2.11.x
Other Linux
: Normal minor
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
: 706859 708094 (view as bug list)
Depends on: 708584
Blocks:
 
 
Reported: 2011-03-02 22:14 UTC by Philip Chimento
Modified: 2013-09-26 17:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test program to illustrate bug (1.47 KB, text/plain)
2011-03-02 22:14 UTC, Philip Chimento
  Details
GtkSourceView: construct with a GtkSourceBuffer instead of a GtkTextBuffer (2.27 KB, patch)
2013-03-30 13:48 UTC, Sébastien Wilmet
none Details | Review

Description Philip Chimento 2011-03-02 22:14:04 UTC
Created attachment 182307 [details]
Test program to illustrate bug

When constructing a GtkSourceView with g_object_new() instead of the usual gtk_source_view_new(), it is initialized with an empty GtkTextBuffer instead of an empty GtkSourceBuffer. This is primarily a problem when building a source view with GtkBuilder.

I have attached a small program that demonstrates the bug. When constructing the GtkSourceView with g_object_new(), the following warnings are given:

GLib-GObject-WARNING **: invalid cast from `GtkTextBuffer' to `GtkSourceBuffer'

when retrieving the buffer and casting it to a GtkSourceBuffer, and

GtkSourceView-CRITICAL **: gtk_source_buffer_set_language: assertion `GTK_IS_SOURCE_BUFFER (buffer)' failed

when trying a GtkSourceBuffer function on it. In addition, the text in the buffer is not highlighted. Exchanging the offending g_object_new() call with a call to gtk_source_view_new() doesn't generate the warnings, and the text in the buffer is highlighted.
Comment 1 Sébastien Wilmet 2013-03-30 13:48:37 UTC
Created attachment 240168 [details] [review]
GtkSourceView: construct with a GtkSourceBuffer instead of a GtkTextBuffer

In constructed(), gtk_text_view_get_buffer() was called. Since no buffer
is created at this point, a GtkTextBuffer was created implicitly by
gtk_text_view_get_buffer().

Now a GtkSourceBuffer is created explicitly in constructed().

This simplifies gtk_source_view_new() and
gtk_source_view_new_with_buffer().
Comment 2 Paolo Borelli 2013-03-30 14:40:53 UTC
Review of attachment 240168 [details] [review]:

::: gtksourceview/gtksourceview.c
@@ +260,3 @@
 gtk_source_view_constructed (GObject *object)
 {
+	GtkSourceBuffer *buffer = gtk_source_buffer_new (NULL);

It is not clear to me how this works: it is creating a new buffer and setting it unconditionally on the view, even if a buffer was specified with new_with_buffer
Comment 3 Sébastien Wilmet 2013-03-30 15:19:51 UTC
Yes, it is not really optimized. If new_with_buffer() is used, the buffer created in constructed is finalized and replaced by the new one. It was already the case with the TextBuffer, but it seems that, with the patch, the TextBuffer is still created and finalized (so it's worse than before, but at least we have a SourceBuffer in the end).

The latter problem can maybe be solved in GtkTextView.

In other words, in:
+       return g_object_new (GTK_SOURCE_TYPE_VIEW,
+                            "buffer", buffer,
+                            NULL);

the buffer property is set after constructed(), since it's not a constructed property (if I understand correctly).
Comment 4 Sébastien Wilmet 2013-06-12 12:47:28 UTC
For the record:

<swilmet> maybe a cleaner solution would be to override gtk_text_view_get_buffer()
<swilmet> because if the buffer is null, get_buffer() creates it (a GtkTextBuffer)
<swilmet> but the virtual pointer get_buffer doesn't exist
(some tests)
<swilmet> overriding get_buffer() doesn't work well, another hack is needed to avoid an infinite loop
<swilmet> but having a virtual method create_buffer() that unconditionnaly creates a new buffer, that works
<swilmet> but it means a new function in the API
<swilmet> unless a simple pointer in the class struct is sufficient
<swilmet> the infinite loop is because get_buffer() must call set_buffer(), which then call get_buffer(), etc
<swilmet> the cleaner solution is to call create_buffer() in get_buffer()
<swilmet> (if the buffer is null)
Comment 5 Sébastien Wilmet 2013-06-12 21:03:45 UTC
If bug #667466 is fixed, the situation would be a little better.
Comment 6 Philip Chimento 2013-06-12 22:00:16 UTC
Re bug #667466: Actually, despite what my original bug report said, the biggest problem is not now GtkBuilder, but creating a GtkSourceView in Python or JS through GObject introspection.
Comment 7 Sébastien Wilmet 2013-08-27 10:55:25 UTC
*** Bug 706859 has been marked as a duplicate of this bug. ***
Comment 8 Sébastien Wilmet 2013-09-15 01:52:33 UTC
*** Bug 708094 has been marked as a duplicate of this bug. ***
Comment 9 Sébastien Wilmet 2013-09-26 17:32:58 UTC
Fixed in the master branch. This will be available for GtkSourceView 3.12.