Re: Wrapping problem



> 
> Karl Nelson <kenelson@ece.ucdavis.edu> writes:  
> > Thus I propose that we add a pointer to the parent in GtkCListRow and
> > GtkCListColumn.  This would be enough to make both GtkCList and GtkCTree
> > much easier to wrap.  Is there any reason not to do this?  Are there
> > any issues that need to be considered?
> > 
> 
> The obvious cost of doing this is one pointer per row/node, 
> 10K nodes * 4 bytes is 40K bytes. Not a huge deal.
> 
> Though I think you could easily add the pointer to the C++ wrapper
> object for the GTK 1.2 wrapper - 

Not as easy as it seems...
 
>   class Node
>     {
>       GtkCTree* parent_;
>       GtkCTreeNode* node_;
> 
>       public:
>         Node(GtkCTree* parent, GtkCTreeNode* node);
> 
>         void set_something(int);
>     };
> 
>   void Node::set_something(int i)
>     { gtk_ctree_set_something(parent_, node_, i);}
> 
>   Node CTree::get_node() {
>      return Node(ctree, gtk_ctree_get_node(ctree));
>   }

Okay with this system there is no way to take a gtk+ structure
and make a gtk-- one without extra info.  Thus I would have to
supply it at every call...

  CTreeNode get_some_node()
    { return CTreeNode(gtkobj(),gtk_clist_get_sone_node(gtkobj())); }

A bit of a pain, but doable.  The problem comes when placing
this in a GList wrapper.  The standard way to make a wrapper
is to write a generic template and then using it on you data types.

However as the CTreeNode requires 2 pieces of information and
is not directly transformable, this means a standard wrapper won't
do.  Thus I must write an entire STL wrapper (several hundred lines)
just for this one type.  Multiply this by all the structures 
that suffer this problem and you get thousands of lines of code 
that must be maintained.  It is possible, but not pretty. 

> Granted I'm not sure how this interacts with deriving from
> GtkCTreeNode if you want to do that...

We don't derive these types of structures.  Nor do we create them,
thus we can't add any data to them.  Gtk+ creates them and we just
use a cheap wrapper that can be cast to it.

(This goes back to the fragment discussions that we had with 
Tim.  We would like fragments to become at least mini objects
so that there is a basic set of services we can use.)

--Karl




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]