[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtkmm
Subject:    Re: prepare_create_table wrapping - part2
From:       Pavlo Solntsev <pavlo.solntsev () gmail ! com>
Date:       2017-05-15 12:45:29
Message-ID: 1494852329.1529.7.camel () gmail ! com
[Download RAW message or body]

Dear Kjell.

There is no open bug. I should probably explain how it started. I have
personal interests in using libgdamm. I found that simple process of
creating tables was missed in libgdamm. However, in libgda those
methods were available. I had two options: 1) make my own version of
methods to create a table or 2) help community and add those methods to
libgdamm. Initial problem with implementation was with understanding
how implementation (wrapping) works. Sorry, but not a lot of
documentation available. I naturally expected different behavior of
_CLASS_GENERIC methods and _WRAP_METHOD. In the process I learn
information that wasn't clearly available to me: class in class
wrapping. Wrapping non GObject based classes etc. To all that, I didn't
know internal policy in *mm projects. Does it make sense to write
classes in the mm module? How to wrap correctly C style struct to C++
class, or leave it as a struct. After I spent some time, played with
code, bugged you (sorry for that) I have already answers for majority
of the listed above questions but some of them still unclear. 

I will file a bug report for missing
Gda::ServerOperation::prepare_create_table()
Gda::ServerOperation::perform_create_table()
methods to track all changes. 

And I agree with you comments. 

Best,

On Sun, 2017-05-14 at 19:28 +0200, Kjell Ahlstedt wrote:
> This discussion is perhaps more suitable for a bug report. But if
> you 
> had started with a libgdamm bug, I would not have found it. Anyway,
> here 
> are some comments.
> 
> _WRAP_METHOD and many other _WRAP_* macros can only be used in a
> class 
> with a _CLASS_* macro. In this patch it looks like 
> ServerOperationCreateTableArg is not included within another class.
> It 
> ought to be possible to use one of the _CLASS_* macros, perhaps 
> _CLASS_OPAQUE_COPYABLE.
> 
> cnc.operator->()->gobj()? Why not just cnc->gobj()?
> 
> Don't ServerOperationCreateTableArg's copy constructors leak memory? 
> They assign to _parent several times.
> 
> 
> Den 2017-05-13 kl. 18:42, skrev Pavlo Solntsev:
> > Dear Kjell.
> > 
> > Thank you so much for pointing on that. I have successfully
> > compiled
> > libgdamm. Could you please take a look for CreateTableArg class
> > implementation. Is it something we can stay with? I found that
> > _WRAP_METHOD doesn't work in this case.
> >    
> > Thanks.
> > 
> > 
> > On Sat, 2017-05-13 at 09:53 +0200, Kjell Ahlstedt wrote:
> > > You have misspelt CreateTableArgTraits in some places
> > > (CreateTableArgTriats), but not everywhere.
> > > 
> > > You can remove the CONVERSION()s to Glib::RefPtr<const
> > > ServerOperationCreateTableArg> and
> > > Glib::RefPtr<ServerOperationCreateTableArg>. I suppose they are
> > > not
> > > used, and therefore make no harm.
> > > 
> > > There may be other errors, I haven't studied your code in detail.
> > > 
> > > 
> > > -- 
> > 
> > - Pavlo Solntsev
> > 
> 
> 
-- 
- Pavlo Solntsev
---------------------------------------------
Sent from Evolution on GNU/Debian <www.debian.org> id="-x-evo-
selection-start-marker">


_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

[prev in list] [next in list] [prev in thread] [next in thread]