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 118922 - TreeModel columns can't be of type "short"
TreeModel columns can't be of type "short"
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: reference documentation
2.4
Other other
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 158818
Blocks:
 
 
Reported: 2003-08-02 08:59 UTC by Martin Schulze
Modified: 2011-07-27 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test_treeview_unsigned_short.cc (1.29 KB, text/plain)
2003-08-03 11:31 UTC, Martin Schulze
  Details
test_treeview_unsigned_short_2.cc (1.38 KB, text/plain)
2003-08-08 16:57 UTC, Martin Schulze
  Details
gtkmm2-improve_treeview_docs.diff: Proposed documentation additions. (2.87 KB, patch)
2003-08-09 12:42 UTC, Martin Schulze
committed Details | Review
gtkmm2-improve_treeview_docs.diff: updated patch for gtkmm-2.2 (3.03 KB, patch)
2003-08-11 21:22 UTC, Martin Schulze
committed Details | Review
gtkmm-improve_treeview_docs.diff: updated patch for gtkmm-2.4 (2.88 KB, patch)
2003-08-11 21:23 UTC, Martin Schulze
committed Details | Review
test_treeview_short.cc (835 bytes, text/x-c++src)
2004-11-17 21:11 UTC, Murray Cumming
  Details

Description Martin Schulze 2003-08-02 08:59:07 UTC
As clarified in

http://bugzilla.gnome.org/show_bug.cgi?id=94170

TreeModelColumns cannot be of type "UNSIGNED SHORT". Other simple types are
affected as well.

However, the runtime errors are not self-explanatory nor is this behaviour
documented.
It should be mentioned in the book, Chapter 8, "Model Columns" and in the
reference documentation of TreeModelColumn or TreeModelColumnRecord.

I will try to make a patch later today.

Are there any possibilities to make TreeModelColumn compile time safe, i.e.
trigger errors if the type is not supported?
Comment 1 Murray Cumming 2003-08-03 09:22:24 UTC
That bug does not explain to me why we can't use unsigned short columns. 

This might have been fixed for gtkmm 2.4, as part of this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=102853
Comment 2 Martin Schulze 2003-08-03 11:30:28 UTC
I don't understand. The problem described in
http://bugzilla.gnome.org/show_bug.cgi?id=102853
seems to impose that compile time errors arise when using unsuppoerted
types for TreeView::append_column_editable(). I'm talking about
TreeView::append:column(), however.

While
http://bugzilla.gnome.org/show_bug.cgi?id=102853
is certainly somehow related to
http://bugzilla.gnome.org/show_bug.cgi?id=94170
I can't see how it is supposed to be fixed with the patch
http://bugzilla.gnome.org/showattachment.cgi?attach_id=13428

Since I don't have gtkmm-2.4 installed (which would take a while on
this damn slow machine) I can't check myself whether the problems are
gone in 2.4 so I'm attaching a test case that uses
TreeModelColumn<unsigned short> and results in the following run time
errors with gtkmm-2.2:

(process:1270): GLib-GObject-CRITICAL **: gtype.c:1875: initialization
assertion failed, use g_type_init() prior to this function
 
(a.out:1270): Gtk-WARNING **: gtkliststore.c:377: Invalid type (null)
passed to gtk_list_store_set_column_types
 
 
(a.out:1270): GLib-GObject-CRITICAL **: file gvalue.c: line 302
(g_value_type_transformable): assertion `G_TYPE_IS_VALUE (src_type)'
failed
 
(a.out:1270): GLib-GObject-WARNING **: gtype.c:2967: type id `0' is
invalid
 
(a.out:1270): GLib-GObject-WARNING **: can't peek value table for type
`<invalid>' which is not currently referenced
 
(a.out:1270): GLib-GObject-WARNING **: gvalue.c:93: cannot initialize
GValue with type `(null)', this type has no GTypeValueTable implementation
 
[2]+  Segmentation fault      (core dumped) ./a.out


(Note, however, that I get different runtime errors and no segfault
with my app which loads the treeview from a .glade file with
libglademm - strange!)

Please try the test case with gtkmm-2.4 and tell me what the correct
behaviour should be. I don't think we can ignore this - it really took
me a while to locate the error in my app.
Comment 3 Martin Schulze 2003-08-03 11:31:34 UTC
Created attachment 18867 [details]
test_treeview_unsigned_short.cc
Comment 4 Murray Cumming 2003-08-04 07:34:47 UTC
Yes, I looked at that bug again and it does seem to solve a different
problem. 
Comment 5 Elke Meier 2003-08-04 08:06:51 UTC
Tried it out with gtkmm 2.2.5, and it obviously has not been fixed.
Here's the output, in case anyone is interested:

 (process:16668): GLib-GObject-CRITICAL **: gtype.c:1875: 
initialization assertion failed, use g_type_init() prior to this 
function

(a.out:16668): Gtk-WARNING **: gtkliststore.c:377: Invalid type 
(null) passed to gtk_list_store_set_column_types


(a.out:16668): GLib-GObject-CRITICAL **: file gvalue.c: line 302 
(g_value_type_transformable): assertion `G_TYPE_IS_VALUE (src_type)' 
failed

(a.out:16668): GLib-GObject-WARNING **: gtype.c:2967: type id `0' is 
invalid

(a.out:16668): GLib-GObject-WARNING **: can't peek value table for 
type `<invalid>' which is not currently referenced

(a.out:16668): GLib-GObject-WARNING **: gvalue.c:93: cannot 
initialize GValue with type `(null)', this type has no 
GTypeValueTable implementation

Segmentation fault (core dumped)
Comment 6 Murray Cumming 2003-08-04 12:12:45 UTC
I will investigate eventually if nobody else does.
Comment 7 Martin Schulze 2003-08-04 14:48:19 UTC
I couldn't manage half the things I wanted to tackle this weekend :(
However, I will drop a note before I start investigations of my own
before you do. Might get Friday, though. You are sure now, that there
were no fixes for gtkmm-2.4 regarding this problem?
Comment 8 Murray Cumming 2003-08-04 15:05:57 UTC
No, but it looks like Daniel had some clue. The hard drive on my linux
machine will be kaput until Monday.
Comment 9 Martin Schulze 2003-08-08 15:41:06 UTC
I will start to investigate now.
Questions to be answered:
- Is this a bug?
- Otherwise: Why not? Can error messages be triggered at compile time?
- Otherwise: Where shall we document this behaviour?
Comment 10 Martin Schulze 2003-08-08 16:56:25 UTC
Now I know how to reproduce the other error message and avoid the
segfault. I'll attach a corrected test case. Difference: don't
instantiate a Gtk::TreeModelColumnRecord before calling "Gtk::Main
kit;". Otherwise Glib::Value<unsigned short>::value_type() fails
triggering the first run-time error and eventually leading to the
segfault.

The corrected test case triggers the following run-time error known
from http://bugzilla.gnome.org/show_bug.cgi?id=94170:

(a.out:1163): GLib-GObject-WARNING **: unable to set property `text'
of type `gchararray' from value of type `glibmm__CustomBoxed_t'
Comment 11 Martin Schulze 2003-08-08 16:57:38 UTC
Created attachment 19038 [details]
test_treeview_unsigned_short_2.cc
Comment 12 Martin Schulze 2003-08-09 09:52:34 UTC
> - Is this a bug?

First test case: no: use of gtk(mm) functions (here for setting up
custom GValue type) before instantiating Gtk::Main is not allowed.

Second test case: not really: use of custom GValue types is perfectly
legal. However it is not possible to automatically create a
TreeViewColumn from TreeView::append_column(). Instead, the
TreeViewColumn has to be created manually and a function for
displaying data has to be provided with
TreeViewColumn::set_cell_data_func(). After that, the column can be
appended directly with the appropriate TreeView::append_column() overload.


> - Otherwise: Why not? Can error messages be triggered at compile time?

First test case: No.

Second test case: In theory. The TreeView::append_column(const
Glib::ustring& title, const TreeModelColumn<ColumnType>& model_column)
overload should fail if the TreeModelColumn uses a custom GValue type.
A compile-time-check can be added using some template magic with
template specializations for all supported types. The corresponding
TreeView::append_column_editable() overload already fails to compile
if the type is not supported. A run-time-check might be easier and
cleaner to implement (somehow check Value<the_type>::value_type()).


> - Otherwise: Where shall we document this behaviour?

First test case: Already documented in
file:///usr/local/share/doc/gtkmm-2.0/docs/reference/html/classGtk_1_1TreeModelColumnRecord.html

Second test case:
file:///usr/local/share/doc/gtkmm-2.0/docs/tutorial/html/ch08s02.html#id2962983
and
file:///usr/local/share/doc/gtkmm-2.0/docs/reference/html/classGtk_1_1TreeView.html#a25
should mention that TreeViewModelColumns that use custom GValue types
can not be used this way. The standard GValue types have to be listed
somewhere.
Comment 13 Martin Schulze 2003-08-09 12:31:29 UTC
> > - Otherwise: Why not? Can error messages be triggered at compile time?
> 
> First test case: No.
> 
> Second test case: In theory. The TreeView::append_column(const
> Glib::ustring& title, const TreeModelColumn<ColumnType>& model_column)
> overload should fail if the TreeModelColumn uses a custom GValue type.

I was wrong here. It is also possible to set the cell data function
with TreeViewColumn::set_cell_data_func() after the column has been
created with the TreeView::append_column(const
Glib::ustring& title, const TreeModelColumn<ColumnType>& model_column)
overload. The TreeViewColumn doesn't have to be created manually.
=> We only need to improve the documentation. I will attach a patch.
Comment 14 Martin Schulze 2003-08-09 12:42:21 UTC
Created attachment 19059 [details] [review]
gtkmm2-improve_treeview_docs.diff: Proposed documentation additions.
Comment 15 Martin Schulze 2003-08-09 12:45:15 UTC
The only problem I see after improving the documentation of
TreeView::append_column is that I find it quite difficult to track
down the runtime error

(a.out:1163): GLib-GObject-WARNING **: unable to set property `text'
of type `gchararray' from value of type `glibmm__CustomBoxed_t'

to an incorrect use of this function. Maybe we should cite the error
message?
Comment 16 Murray Cumming 2003-08-11 12:01:39 UTC
You might also try doing the same thing in GTK+ in C.
Comment 17 Murray Cumming 2003-08-11 12:08:30 UTC
Please commit the documentation patch after making these changes:

> Note that only for some basic column types like Glib::ustring, int,
bool, Gdk::Pixbuf, etc. the CellRenderer is set up correctly. ...

I would prefer
"
The CellRenderer can only be created automatically for some basic
column types, such as Glib::ustring, int, bool, Gdk::Pixbuf. Also, the
default CellRenderer might not be setup exactly as needed.

You might prefer to create the TreeViewColumn and or CellRenderer
manually. You might provide a callback that converts the type into a
string representation with TreeViewColumn::set_cell_data_func().
"

Please do not mention this:
> * If you want this function to support a custom CellRenderer provide
a template specialization of
TreeViewColumn_CellRendererGeneration::generate_cellrenderer()
That is fairly internal API and this is an unpleasant thing for
someone to do.
Comment 18 Martin Schulze 2003-08-11 12:15:33 UTC
I will do so this evening. I must not forget to also commit to gtkmm-
2.4!
Comment 19 Martin Schulze 2003-08-11 12:18:48 UTC
> You might also try doing the same thing in GTK+ in C.
In C you also have to provide a callback with 
gtk_tree_view_column_set_cell_data_func() for unsupported types such 
as (unsigned) short. There is no knowledge to be gained with a C test 
case so I won't waste my time with it...
Comment 20 Martin Schulze 2003-08-11 21:21:19 UTC
> I would prefer
> "
> The CellRenderer can only be created automatically for some basic
> column types, such as Glib::ustring, int, bool, Gdk::Pixbuf. Also,
> the default CellRenderer might not be setup exactly as needed.
> You might prefer to create the TreeViewColumn and or CellRenderer
> manually. You might provide a callback that converts the type into a
> string representation with TreeViewColumn::set_cell_data_func().
> "

Please also proof-read the following paragraph I'd like to add:

 * Otherwise, if the type is not supported, at run-time no text will
 * appear in the column while the following warning is generated
repeatedly:
 * GLib-GObject-WARNING **: unable to set property `text' of type
 * `gchararray' from value of type `glibmm__CustomBoxed_t'

I will wait with the commit. Meanwhiles, I'm attaching updated patches
for gtkmm-2.2 and gtkmm-2.4.
Comment 21 Martin Schulze 2003-08-11 21:22:40 UTC
Created attachment 19126 [details] [review]
gtkmm2-improve_treeview_docs.diff: updated patch for gtkmm-2.2
Comment 22 Martin Schulze 2003-08-11 21:23:44 UTC
Created attachment 19128 [details] [review]
gtkmm-improve_treeview_docs.diff: updated patch for gtkmm-2.4
Comment 23 Murray Cumming 2003-08-12 05:33:37 UTC
OK, though we would of course prefer to have a more meaningful error 
generated from gtkmm.

I need to investigate why the unsigned type is not supported by GTK+.
Comment 24 Martin Schulze 2003-08-12 08:26:25 UTC
Ok, then I will commit as soon as possible.

> I need to investigate why the unsigned type is not supported by 
GTK+.
It's not the unsigned but the short type. int and unsigned int are 
supported, short and unsigned short are not. There is no GValue type 
for them.
Comment 25 Murray Cumming 2003-08-12 14:30:13 UTC
I guess this is platform-dependent.
Comment 26 Martin Schulze 2003-08-12 18:29:27 UTC
Documentation additions committed to both gtkmm2 and gtkmm cvs modules.
Comment 27 Murray Cumming 2003-10-08 12:50:36 UTC
This might be a clue about how to support these extra types:
http://bugzilla.gnome.org/show_bug.cgi?id=83190
Comment 28 Murray Cumming 2004-11-17 12:03:15 UTC
This bug seems relevant too:
http://bugzilla.gnome.org/show_bug.cgi?id=94170
Comment 29 Murray Cumming 2004-11-17 12:07:10 UTC
I think we just need to add an unsigned short template specialization. I will
try it.
Comment 30 Murray Cumming 2004-11-17 21:11:34 UTC
Created attachment 33892 [details]
test_treeview_short.cc

Here's a slightly simpler example, updated for gtkmm 2.4.
Comment 31 Murray Cumming 2004-11-18 11:06:20 UTC
I must find out how the CellRendererText is able even to render an int via it's
text property.
Comment 32 Murray Cumming 2004-11-20 13:37:50 UTC
I did some reasearch, and I have a possible solution:

We could use g_value_register_transform_func() to register a new transformation
from the Value<short>::value_type() to gchararray. glib already registers a
transformation func for int to gchararray. We would do this in our
Value<>::value_type() specialization.

Alternatively, we could persuade the glib developers to do it in glib.

However, all of these number-to-string conversions are arbitrary and probably
not often what is needed, so people often use set_cell_data_func(). Maybe an
append_column_numeric(model_column, numeric_format) would be better, if we can
think of a sensible way to represent the format.
Comment 33 Murray Cumming 2004-12-06 08:58:10 UTC
I have added TreeView::append_column_numeric() and
TreeView::append_column_numeric_editable() in gtkmm 2.5, which can at least be
used as workarounds.
Comment 34 Morpheus 2011-07-27 12:02:11 UTC
Hi,

I post on this bug because I've got same or a related problem (after many years as I can see in the dates of comments).

I had the same problem with short types; seeing this bug, I've used append_column_numeric like Murray said and it works, but using append_column_numeric_editable, the code doesn't compile, throwing this message:

In file included from /usr/include/gtkmm-2.4/gtkmm/combobox.h:34:0,
                 from /usr/include/gtkmm-2.4/gtkmm.h:123,
                 from main.cc:3:
/usr/include/gtkmm-2.4/gtkmm/treeview.h: In function ‘void Gtk::TreeView_Private::_auto_store_on_cellrenderer_text_edited_string(const Glib::ustring&, const Glib::ustring&, int, const Glib::RefPtr<Gtk::TreeModel>&) [with ColumnType = short int]’:
/usr/include/gtkmm-2.4/gtkmm/treeview.h:2463:82:   instantiated from ‘void Gtk::TreeView_Private::_connect_auto_store_editable_signal_handler(Gtk::TreeView*, Gtk::CellRenderer*, const Gtk::TreeModelColumn<ColumnType>&) [with ColumnType = short int]’
/usr/include/gtkmm-2.4/gtkmm/treeview.h:2181:5:   instantiated from ‘int Gtk::TreeView::append_column_numeric_editable(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&, const Glib::ustring&) [with ColumnType = short int]’
main.cc:63:57:   instantiated from here
/usr/include/gtkmm-2.4/gtkmm/treeview.h:2492:9: error: invalid cast from type ‘const Glib::ustring’ to type ‘short int’

And, for 3.0:

In file included from /usr/include/gtkmm-3.0/gtkmm/combobox.h:36:0,
                 from /usr/include/gtkmm-3.0/gtkmm/appchooserbutton.h:27,
                 from /usr/include/gtkmm-3.0/gtkmm.h:101,
                 from main.cc:3:
/usr/include/gtkmm-3.0/gtkmm/treeview.h: In function ‘void Gtk::TreeView_Private::_auto_store_on_cellrenderer_text_edited_string(const Glib::ustring&, const Glib::ustring&, int, const Glib::RefPtr<Gtk::TreeModel>&) [with ColumnType = short int]’:
/usr/include/gtkmm-3.0/gtkmm/treeview.h:2242:82:   instantiated from ‘void Gtk::TreeView_Private::_connect_auto_store_editable_signal_handler(Gtk::TreeView*, Gtk::CellRenderer*, const Gtk::TreeModelColumn<ColumnType>&) [with ColumnType = short int]’
/usr/include/gtkmm-3.0/gtkmm/treeview.h:1960:5:   instantiated from ‘int Gtk::TreeView::append_column_numeric_editable(const Glib::ustring&, const Gtk::TreeModelColumn<ColumnType>&, const Glib::ustring&) [with ColumnType = short int]’
main.cc:63:57:   instantiated from here
/usr/include/gtkmm-3.0/gtkmm/treeview.h:2271:9: error: invalid cast from type ‘const Glib::ustring’ to type ‘short int’

Using integer and casting resolves the problem, but this is a workaround.

I don't know if this deserves to be solved or not, but I notify it to put record.

I've tried with gtkmm 2.4 (apt: 1:2.24.0-1) and 3.0 (3.0.1-1), on Debian testing.
Comment 35 Murray Cumming 2011-07-27 12:12:47 UTC
> using
append_column_numeric_editable, the code doesn't compile

Please file a new bug, ideally with a simple-as-possible test case.
Comment 36 Morpheus 2011-07-27 12:33:49 UTC
(In reply to comment #35)
> Please file a new bug, ideally with a simple-as-possible test case.

Done: https://bugzilla.gnome.org/show_bug.cgi?id=655416