GNOME Bugzilla – Bug 736367
GtkSourceView should implement GtkBuildable::get_internal_child()
Last modified: 2018-05-26 13:53:16 UTC
If GtkSourceView implements GtkBuildable::get_internal_child() for the "completion" property, it should be possible to set defaults on the completion window from directly in the GtkBuilder XML. For example, instead of setting "select-on-show" and "show-headers" in my class constructed vfunc, it would be nice if it could be done in the widget template using: <child internal-child="completion"> <object class="GtkSourceCompletion"> <property name="select_on_show">False</property> </object> </child> I'm not totally sure this is how it would work, but seems plausible.
I'll have a look at this this evening or tomorrow.
It works! https://git.gnome.org/browse/gtksourceview/log/?h=wip/gtk-buildable It should be documented in the class description, and maybe the glade description should be updated too.
Awesome, just what I need, thanks! Patch looks good too.
looks good to me too, feel free to push. I wonder if the info widget should be buildable as well
That would just need the same thing done to GtkSourceCompletion right? We should be able to dive down into internal children just fine.
I guess so... and now you are making me wonder if we should support specifying gutter renderers in the ui file too :)
(In reply to comment #6) > I guess so... and now you are making me wonder if we should support specifying > gutter renderers in the ui file too :) I would appreciate this, especially if it came with API to fetch the list of renderers in a GtkSourceGutter. For example, I need access to the line renderer so that I can select ranges of lines by click/dragging the line numbers.
Yes, GtkBuilder doesn't complain about nested internal children. What properties would you set on the CompletionInfo? I've tried "margin", but it doesn't work well, the label is not centered even when setting the halign and valign. I've also tried "border_width", but it doesn't work. For glade, I think internal-child is not supported.
(In reply to comment #7) > For example, I need access to the line renderer so that I can select ranges of > lines by click/dragging the line numbers. We can maybe implement that directly in GtkSourceView.
(In reply to comment #8) > What properties would you set on the CompletionInfo? > > I've tried "margin", but it doesn't work well, the label is not centered even > when setting the halign and valign. > > I've also tried "border_width", but it doesn't work. It actually works fine, I thought the border_width draws a black border, but it's a transparent border. So to have some space around the label, setting just the border_width to 3 works fine, the label is centered. For the gutter, the xpad and ypad properties are deprecated, so I don't know why it is useful to access the gutters in the .ui file. The patches are available in this branch: https://git.gnome.org/browse/gtksourceview/log/?h=wip/gtk-buildable I think it is a good idea to have a border_width of 3 by default, so there is also a commit for that. But since we are currently in API and UI freeze, it should wait for the next cycle.
I think we can sneak part of this in for 3.14 it does not actually add any public API. I'd say let's push the completion patches and leave the gutter part for next cycle when we figure out how to deal with the renderers
The API is not just a list of types, functions, signals and properties. What is possible to do with GtkBuilder is also part of the API in my opinion. And implementing an interface is also part of the API.
Sure, but the current API already exposes the same concepts and functionality, we are just adding another way to accomplish the same thing in a way that may be more convenient in some cases. Considering this and the fact that the change has no cost in terms of added public methods to the library I think we can get this in. The API freeze is a tool to help us making better decisions, not a burocracy rule to follow blindly.
Yeah, here in this case there are not a lot of risks. I've pushed the completion commits.
It's unlikely that this feature is ever going to be implemented, so I close the bug.