java-gnome-hackers

[java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi all,

I am trying to figure out a way to set the "model" property of the
CellRendererCombo to provide coverage for this type.

* I tried providing a method 
  void org.gnome.gtk.CellRendererCombo.setModel(TreeModel model) {
    setPropertyObject("model","model)
  }
  (using GObject.setPropertyObject()) and received a warning

  unable to set property 'model' of type 'GtkTreeModel' from value of
  type 'GObject'

* I also tried to use store the TreeModel in a different column
  by using a DataColumnReference (which I hoped would simply store
  the object)
  void CellRendererCombo.setModel(DataColumReference column) {

GtkCellLayout.addAttribute(vertical,this,"model",column.getOrdinal());
  }

  unable to set property 'model' of type 'GtkTreeModel' from value of
  type 'BindingsJavaReference'

It seems I am just missing a method which retains the intended type
until finally calling GTK. But after some blind digging through the
generated code (and not having the JNI overview) I must admit that I
don't know how to proceed.

Any idea/hint/help is welcome.

Regards,
  Stefan

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Andrew C. <an...@op...>]

On Tue, 2008-05-13 at 23:35 +0200, Stefan Prelle wrote:
>     setPropertyObject("model", model)

>   unable to set property 'model' of type 'GtkTreeModel' from value of
>   type 'GObject'

Ah. That would seem to be a bug.

It _might_ be the same class of problem that we recently ran into with
GValues holding enums: for some reason GValue gets grumpy when asked to
hold abstract types. See 'textview' revno 508.

Actually, the real bug is that we didn't have any test coverage of
setPropertyObject(); at least we had somethine for getPropertyObject().

Which raises a different question: why does the get path work and not
the set path? The GValues are being initialized the same way, aren't
they? Answer, no, not quite: the GValues in property getting are created
C side in our GObject.g_object_get_property() implementation using the
GParamSpec.

So we'll either have to do the enum hack again, or change the way
GObject.setProperty() works so that it creates the GValue C side.

What a pain. I hate GValues.

In fact, I'd be happy if they went away entirely. That would mean making
GObject.setProperty(), GtkTreeView.setValue()  and anything else that
uses GValue have a native overload for every type combination [in a
hand written Override]. That *is* doable, but at present we have all
those code paths concentrated through the Value code paths.

Well, whatever. Something for the future.

AfC
Sydney

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi all,

I was revisiting my attempts to implement a CellRendererCombo.
This time I was trying to implement a "DataColumnTreeModel" to give the
CellRendererCombo a column to pick its model from.

public final class DataColumnTreeModel extends DataColumn {
    public DataColumnTreeModel() {
        super(TreeModel.class);
    }
}

I ran into the problem that there is no mapping from TreeModel to a
GType:

org.freedesktop.bindings.FatalError: Don't know how to map
org.gnome.gtk.TreeModel into a GType

So I tried modifying src/jni/bindings_java_type.[c|h] to add some
mappings:

	} else if (g_str_equal(fqcn, "org.gnome.gtk.TreeStore")) {
		return GTK_TYPE_TREE_STORE;
	} else if (g_str_equal(fqcn, "org.gnome.gtk.ListStore")) {
		return GTK_TYPE_LIST_STORE;
	} else if (g_str_equal(fqcn, "org.gnome.gtk.TreeModel")) {
		return GTK_TYPE_TREE_MODEL;

While this got me a bit further, I now seem to have problems with an
assertion in the native GTK code:

org.gnome.glib.FatalError: Gtk-CRITICAL
gtk_cell_renderer_combo_set_property: assertion `GTK_IS_TREE_MODEL
(object)' failed

which propably leads to the line in gtk/gtktreemodel.h
#define GTK_IS_TREE_MODEL(obj)  (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
GTK_TYPE_TREE_MODEL))

So from my understanding GTK has problems identifying e.g. a
org.gnome.gtk.ListStore (which is an implementation of the abstract
org.gnome.gtk.TreeModel) as of being of a native GtkTreeModel.
Correct?

Am Mittwoch, den 14.05.2008, 15:22 +1000 schrieb Andrew Cowie:
> It _might_ be the same class of problem that we recently ran into with
> GValues holding enums: for some reason GValue gets grumpy when asked to
> hold abstract types. See 'textview' revno 508.

Possibly. Honestly I feel a bit overwhelmed by the whole Plumbing,
GValue, GType and generally deep and dirty mapping stuff.

> [..]
> What a pain. I hate GValues.
> 
> In fact, I'd be happy if they went away entirely. That would mean making
> GObject.setProperty(), GtkTreeView.setValue()  and anything else that
> uses GValue have a native overload for every type combination [in a
> hand written Override]. That *is* doable, but at present we have all
> those code paths concentrated through the Value code paths.
> 
> Well, whatever. Something for the future.

So that means there is currently no simple workaround to get the
CellRendererCombo working?

Regards,
 Stefan

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Andrew C. <an...@op...>]

On Sun, 2008-09-14 at 00:36 +0200, Stefan Prelle wrote:
> org.gnome.glib.FatalError: Gtk-CRITICAL
> gtk_cell_renderer_combo_set_property: assertion `GTK_IS_TREE_MODEL
> (object)' failed

So one quick thought (I'm not sure if this helps) is that GtkTreeModel
is [natively in GLib terms] an interface, not an object.

Ordinarily a bunch of crazy casting takes care of this, but in the case
of working with GValues and GTypes, I'm not sure.

> So that means there is currently no simple workaround to get the
> CellRendererCombo working?

I don't think the problem is insurmountable. Worst case scenario we just
do an override code path for this (though if we keep doing that sort of
thing will aggregate cruft, which is why I discussed a possible code
generator solution in the previous email).

Ping me on IRC and we can talk more about it.

It would really help if you wrote a tinsy Example or Snapshot which
demonstrates the problem and added it to the branch and sent it along to
us... then we could see what you're trying to do.

AfC
Sydney

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi Andrew,

Am Dienstag, den 16.09.2008, 10:51 +1000 schrieb Andrew Cowie:
> It would really help if you wrote a tinsy Example or Snapshot which
> demonstrates the problem and added it to the branch and sent it along to
> us... then we could see what you're trying to do.

Patch against "hackers/andrew/treeview/"

It is an attempt to store TreeModels in cells. I am aware that I have
not taken care of selecting the column of the enclosed TreeModel to
display, but currently my problem is at an earlier stage. :(

Regards,
  Stefan