GRAMPS › GRAMPS - Dev

Problems with gtk 3 conversion

Classic

List

Threaded

7 messages Options

Benny Malengier

Problems with gtk 3 conversion

Nick, Gerald, or other Gtk experts,

I have hit a wall in the Gtk 3 conversion, see http://www.gramps-project.org/bugs/view.php?id=5009

Please have a look at the problem: There is no more GenericTreeModel, and my attempts of creating a pure python one have failed.
So we have 3 options:

1/I'm doing something wrong and it can work using Gtk.TreeModel, we just need to understand it better.
2/We need to write a C module as Generictreemode, then use ctypes and GObject to inherit from it and use in Gramps
3/we need to convert to Gtk.ListStore and Gtk.TreeStore

Let's hope it is 1/!
The file treeviewgramps.py shows the problem. When run, it shows:

(treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `iface->get_n_columns != NULL' failed
(treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_iter: assertion `iface->get_iter != NULL' failed

And the treeview holds no data.

What I can say for now is that documentation is bad, no resources yet via the internet, and segmentation faults galore.

Benny

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Remove Ads

John Ralls-2

Re: Problems with gtk 3 conversion

On Jun 19, 2011, at 2:06 PM, Benny Malengier wrote:

> Nick, Gerald, or other Gtk experts,
>
> I have hit a wall in the Gtk 3 conversion, see http://www.gramps-project.org/bugs/view.php?id=5009
>
> Please have a look at the problem: There is no more GenericTreeModel, and my attempts of creating a pure python one have failed.
> So we have 3 options:
>
> 1/I'm doing something wrong and it can work using Gtk.TreeModel, we just need to understand it better.
> 2/We need to write a C module as Generictreemode, then use ctypes and GObject to inherit from it and use in Gramps
> 3/we need to convert to Gtk.ListStore and Gtk.TreeStore
>
> Let's hope it is 1/!
> The file treeviewgramps.py shows the problem. When run, it shows:
>
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `iface->get_n_columns != NULL' failed
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_iter: assertion `iface->get_iter != NULL' failed
>
> And the treeview holds no data.
>
> What I can say for now is that documentation is bad, no resources yet via the internet, and segmentation faults galore.

GenericTreeModel is an implementation of GtkTreeModel... GtkTreeStore is too. It looks like John Stowers has made some effort to make GenericTreeModel more python-like, but it doesn't look like he's extended GtkTreeModel. 1/ or 3/ should be feasible, but will require that you rewrite your code to use the GtkTreeModel functions directly.

After browsing the code in pygtktreemodel.c for a bit, it looks to me that it should port to Gtk3 with minimal pain, so 2/ might be the least amount of work.

Regards,
John Ralls

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Benny Malengier

Re: Problems with gtk 3 conversion

2011/6/20 John Ralls <[hidden email]>

On Jun 19, 2011, at 2:06 PM, Benny Malengier wrote:

> Nick, Gerald, or other Gtk experts,
>
> I have hit a wall in the Gtk 3 conversion, see http://www.gramps-project.org/bugs/view.php?id=5009
>
> Please have a look at the problem: There is no more GenericTreeModel, and my attempts of creating a pure python one have failed.
> So we have 3 options:
>
> 1/I'm doing something wrong and it can work using Gtk.TreeModel, we just need to understand it better.
> 2/We need to write a C module as Generictreemode, then use ctypes and GObject to inherit from it and use in Gramps
> 3/we need to convert to Gtk.ListStore and Gtk.TreeStore
>
> Let's hope it is 1/!
> The file treeviewgramps.py shows the problem. When run, it shows:
>
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `iface->get_n_columns != NULL' failed
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_iter: assertion `iface->get_iter != NULL' failed
>
> And the treeview holds no data.
>
> What I can say for now is that documentation is bad, no resources yet via the internet, and segmentation faults galore.

GenericTreeModel is an implementation of GtkTreeModel... GtkTreeStore is too. It looks like John Stowers has made some effort to make GenericTreeModel more python-like, but it doesn't look like he's extended GtkTreeModel. 1/ or 3/ should be feasible, but will require that you rewrite your code to use the GtkTreeModel functions directly.

Yes, rewriting to GtkTreeModel is what I did, but it is an abstract class not allowing direct inheritence. I need to figure out the correct way to do it.

I now do:

class FlatBaseModel(GObject.GObject, Gtk.TreeModel):
    __gtype_name__ = 'FlatBaseModel'

    def __init__(self):
        GObject.GObject.__init__(self)

Which already throws an assertion.
I think the error is in the needed implementation of

http://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeModelIface

I don't know if above init is sufficient to set this GInterface also...

After browsing the code in pygtktreemodel.c for a bit, it looks to me that it should port to Gtk3 with minimal pain, so 2/ might be the least amount of work.

Yes, the only disadvantage is that we need to do some compiling in Gramps for install, raising the bar for a source install by users.
However, as so many resources on the net exist for GtkGenericTreeModel, and so many applications seem to use it, I would hope they create some support to make porting easier.

I wrote a mail to John Stowers to ask if he has a git branch with port of his D-Feet application, as it uses GtkGenericTreeModel, if no reply, I'll subscribe to pygtk list and ask there. On IRC there was nobody with the knowledge to help.
All I need would be one example of how it is supposed to be set up :-)

Benny

Regards,
John Ralls

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

John Ralls-2

Re: Problems with gtk 3 conversion

On Jun 20, 2011, at 12:04 AM, Benny Malengier wrote:

2011/6/20 John Ralls <[hidden email]>

On Jun 19, 2011, at 2:06 PM, Benny Malengier wrote:

> Nick, Gerald, or other Gtk experts,
>
> I have hit a wall in the Gtk 3 conversion, see http://www.gramps-project.org/bugs/view.php?id=5009
>
> Please have a look at the problem: There is no more GenericTreeModel, and my attempts of creating a pure python one have failed.
> So we have 3 options:
>
> 1/I'm doing something wrong and it can work using Gtk.TreeModel, we just need to understand it better.
> 2/We need to write a C module as Generictreemode, then use ctypes and GObject to inherit from it and use in Gramps
> 3/we need to convert to Gtk.ListStore and Gtk.TreeStore
>
> Let's hope it is 1/!
> The file treeviewgramps.py shows the problem. When run, it shows:
>
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_n_columns: assertion `iface->get_n_columns != NULL' failed
> (treeviewgramps.py:2871): Gtk-CRITICAL **: gtk_tree_model_get_iter: assertion `iface->get_iter != NULL' failed
>
> And the treeview holds no data.
>
> What I can say for now is that documentation is bad, no resources yet via the internet, and segmentation faults galore.

GenericTreeModel is an implementation of GtkTreeModel... GtkTreeStore is too. It looks like John Stowers has made some effort to make GenericTreeModel more python-like, but it doesn't look like he's extended GtkTreeModel. 1/ or 3/ should be feasible, but will require that you rewrite your code to use the GtkTreeModel functions directly.

Yes, rewriting to GtkTreeModel is what I did, but it is an abstract class not allowing direct inheritence. I need to figure out the correct way to do it.

I now do:

class FlatBaseModel(GObject.GObject, Gtk.TreeModel):
    __gtype_name__ = 'FlatBaseModel'

    def __init__(self):
        GObject.GObject.__init__(self)

Which already throws an assertion.
I think the error is in the needed implementation of

http://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeModelIface

I don't know if above init is sufficient to set this GInterface also...

After browsing the code in pygtktreemodel.c for a bit, it looks to me that it should port to Gtk3 with minimal pain, so 2/ might be the least amount of work.

Yes, the only disadvantage is that we need to do some compiling in Gramps for install, raising the bar for a source install by users.
However, as so many resources on the net exist for GtkGenericTreeModel, and so many applications seem to use it, I would hope they create some support to make porting easier.

I wrote a mail to John Stowers to ask if he has a git branch with port of his D-Feet application, as it uses GtkGenericTreeModel, if no reply, I'll subscribe to pygtk list and ask there. On IRC there was nobody with the knowledge to help.
All I need would be one example of how it is supposed to be set up :-)

Benny,

I'm not sufficiently familiar with pygi to know if you can implement a gtk interface directly in Python, or how to go about it. Are the Gtk-supplied implementations (GtkTreeStore, etc.) not adequate?

Did you see http://developer.gnome.org/gtk3/stable/TreeWidget.html ?

Regards,

John Ralls

Benny Malengier

Re: Problems with gtk 3 conversion

2011/6/20 John Ralls <[hidden email]>

Benny,

I'm not sufficiently familiar with pygi to know if you can implement a gtk interface directly in Python, or how to go about it. Are the Gtk-supplied implementations (GtkTreeStore, etc.) not adequate?

No, in their default format they are inadequate, they duplicate the storage of the database. We need more control on what is stored, and specifically, we may not store an entire database table in memory, or we consume the memory.

I got a reply from J5 however, he pushed his pygi conversion of d-feet here:
http://git.gnome.org/browse/d-feet/tree/dfeet?h=pygi

So, in his approach, he changed Gtk.GenericTreeModel by Gtk.TreeStore, but then overwrites all calls of Gtk.TreeStore (append, on_iter_...) to do what he wants it to do.
See http://git.gnome.org/browse/d-feet/tree/dfeet/introspect_data.py?h=pygi
The trick is that it is apparently not needed for the Node class to be a Gtk.TreeIter, something I assumed was needed.

I'll give it a shot with the listviews like this, and see if it comes out. We already use our own Node class and our own data storage, I just need to find a way to move it into the List/TreeStore instead of a helper class.

Benny

Did you see http://developer.gnome.org/gtk3/stable/TreeWidget.html ?

Regards,
John Ralls

Benny Malengier

Re: Problems with gtk 3 conversion

2011/6/21 Benny Malengier <[hidden email]>

2011/6/20 John Ralls <[hidden email]>

Benny,

I'm not sufficiently familiar with pygi to know if you can implement a gtk interface directly in Python, or how to go about it. Are the Gtk-supplied implementations (GtkTreeStore, etc.) not adequate?

No, in their default format they are inadequate, they duplicate the storage of the database. We need more control on what is stored, and specifically, we may not store an entire database table in memory, or we consume the memory.

I got a reply from J5 however, he pushed his pygi conversion of d-feet here:
http://git.gnome.org/browse/d-feet/tree/dfeet?h=pygi

So, in his approach, he changed Gtk.GenericTreeModel by Gtk.TreeStore, but then overwrites all calls of Gtk.TreeStore (append, on_iter_...) to do what he wants it to do.
See http://git.gnome.org/browse/d-feet/tree/dfeet/introspect_data.py?h=pygi
The trick is that it is apparently not needed for the Node class to be a Gtk.TreeIter, something I assumed was needed.

I'll give it a shot with the listviews like this, and see if it comes out. We already use our own Node class and our own data storage, I just need to find a way to move it into the List/TreeStore instead of a helper class.

Inheriting now works, for inheriting types you need to prepend methods with do_ (?? it used to be on_ in gtk2).

I now hit a seg fault, upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=653151

If somebody has experience with compiling and using the Gtk C code to investigate the seg fault, that would be great...

Benny

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

John Ralls-2

Re: Problems with gtk 3 conversion

On Jun 22, 2011, at 12:53 AM, Benny Malengier wrote:

2011/6/21 Benny Malengier <[hidden email]>

2011/6/20 John Ralls <[hidden email]>

Benny,

I'm not sufficiently familiar with pygi to know if you can implement a gtk interface directly in Python, or how to go about it. Are the Gtk-supplied implementations (GtkTreeStore, etc.) not adequate?

No, in their default format they are inadequate, they duplicate the storage of the database. We need more control on what is stored, and specifically, we may not store an entire database table in memory, or we consume the memory.

I got a reply from J5 however, he pushed his pygi conversion of d-feet here:
http://git.gnome.org/browse/d-feet/tree/dfeet?h=pygi

So, in his approach, he changed Gtk.GenericTreeModel by Gtk.TreeStore, but then overwrites all calls of Gtk.TreeStore (append, on_iter_...) to do what he wants it to do.
See http://git.gnome.org/browse/d-feet/tree/dfeet/introspect_data.py?h=pygi
The trick is that it is apparently not needed for the Node class to be a Gtk.TreeIter, something I assumed was needed.

I'll give it a shot with the listviews like this, and see if it comes out. We already use our own Node class and our own data storage, I just need to find a way to move it into the List/TreeStore instead of a helper class.

Inheriting now works, for inheriting types you need to prepend methods with do_ (?? it used to be on_ in gtk2).

I now hit a seg fault, upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=653151

If somebody has experience with compiling and using the Gtk C code to investigate the seg fault, that would be great...

You don't really need to compile it yourself. If your distro has source packages, install them for libglib and libgtk3. Otherwise get the sources for the appropriate version from ftp.gnome.org and install them at the paths in you backtrace so that gdb can find them.

Alternatively, you can use jhbuild (http://ftp.acc.umu.se/pub/GNOME/sources/jhbuild/, documentation at http://developer.gnome.org/jhbuild/unstable/) and set that up to build a tree for yourself. That will get you the latest development versions of everything unless you spend a fair amount of time customizing your build. You can use mac/gramps.modules from the Gramps repo to get you close; change the include to gnome-apps-3.0.modules so it gets the dependencies from the jhbuild modulesets rather than the OSX modulesets at github. (It might work to use the OSX modulesets on Linux with a wee bit of tweaking, I've never tried.) Set your CFLAGS to include "-O0 -ggdb3" to turn off all optimizations and turn on maximum debugging information in whatever format gdb supports best on your distro.

Once you've got a complete source tree to work with, the problem appears to me to be that whatever type is getting checked has some NULLs in the type description. If that's your FlatBaseModel class (likely, I suspect) then there's a bit more for you to figure out about creating new GObject types in Python. I don't know enough about that to help, I'm afraid.

Regards,

John Ralls