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 784244 - Can gtk_widget_class_set_css_name() be wrapped?
Can gtk_widget_class_set_css_name() be wrapped?
Status: RESOLVED OBSOLETE
Product: gtkmm
Classification: Bindings
Component: general
3.89.x
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2017-06-27 11:16 UTC by Daniel Boles
Modified: 2018-05-22 12:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Boles 2017-06-27 11:16:16 UTC
This function is used to set the CSS node name to be used by a type of widget, called from its class init function.

I don't know much about how gtkmm implements custom widgets yet. Is this something that we could wrap, or is that not possible? Otherwise I imagine we would have to use C to implement a base custom widget type, thereby gaining the ability to define the class init method, and then inherit from that custom type in C++ code.
Comment 1 Kjell Ahlstedt 2017-06-28 13:01:08 UTC
Functions that must be called from the class init function or the instance init
function are problematic for C++ coders. In gtkmm-3 it's not possible to add
anything to the class init functions. See comments in
https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/custom/custom_widget/mywidget.cc?h=gtkmm-3-22

In gtkmm-4 it's possible, but it's done with C code.
Because of the way gtk+4 handles signal_draw() and snapshot_vfunc() we needed
a way for custom widgets to add to the class init function:
Gtk::WidgetCustomDraw and Gtk::WidgetCustomSnapshot, which derive from
Glib::ExtraClassInit.
https://developer.gnome.org/glibmm/unstable/classGlib_1_1ExtraClassInit.html
See also https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/custom/custom_widget
where those classes are used.

Can gtk_widget_class_set_css_name() be wrapped? This is meaningful only if the
class init function is wrapped in C++ code. I suppose it would be possible to
use a sigc::slot. What can be done with GtkWidgetClass? It's the C version of a
vtable.
Comment 2 Daniel Boles 2017-06-28 13:11:02 UTC
Thanks for the info! I hadn't seen those.

It seems like this is covered OK in gtkmm-4, and wrapping the C function would not really achieve much useful.

And in the case of gtkmm-3, it sounds like it simply isn't possible to achieve this, and we would need to keep using added style classes or IDs instead, or implement the base widget class in C and then derive from that.


Btw, the @code formatting doesn't seem to be fully working in the rendered docs for ExtraClassInit: the syntax highlighting works, but the indentation is broken and missing. I guess either the CSS needs to include white-space: pre, or a <pre> or <tt> tag should be added to the output. On a quick test, adding white-space: pre fixes the indentation but results in a line worth of spacing between each line.
Comment 3 Kjell Ahlstedt 2017-06-28 13:43:50 UTC
Gtk::WidgetCustomDraw and Gtk::WidgetCustomSnapshot are not needed in gtkmm-3.
Glib::ExtraClassInit can probably be added to glibmm-2.4 (ABI version, would be
the glibmm-2.52 release or what?). (Glibmm versions are utterly confusing.
Comments in ExtraClassInit say it's new in 2.52. Now it should be 2.54. What
shall it be next week?) Anyway, ExtraClassInit requires modification of
Glib::ObjectBase. My modification in the master branch breaks ABI. It would
perhaps be possible to make a similar modification that doesn't break ABI.
Is it worth the trouble? I don't know.

The @code formatting is different, and better, in the docs/reference/html
directories that we generate locally, when we build modules with make.
I don't know who is responsible for the CSS files used in
https://developer.gnome.org/glibmm/.
Comment 4 GNOME Infrastructure Team 2018-05-22 12:16:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtkmm/issues/17.