Web lists-archives.com

Re: Development with GObjects




Thank you, Philip, 

On Sat, 2018-08-18 at 16:02 -0400, philip.chimento@xxxxxxxxx wrote:
> Nice work, Pavlo! I wonder if you can work this into a patch for the
> GObject documentation :-)

I see no reason why not. I am planning to issue other sections, e.g.
derivable objects, interfaces, properties. I am open for discussion the
best way to incorporate my work to the official manual. What I found,
very often, it is hard to incorporate documentation to the existing
one. Mainly because of the existing structure and logic flow. Also, as
I mentioned in the post, the official manual very technical and very
confused for newcomers. Spending enough time in academia, I always
interested in simplification of the complex concepts. Therefore, I
decided to present my interpretation of very complex concept in a way
that a beginner will be able to understand. 

> You might want to check out 
> https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/
>  as well.
> 
> In my personal style I would do three things differently, I don't
> know for sure whether I'm correct about these or how widespread they
> are as best practices:
> 
> - It's not necessary to override dispose or finalize if the only
> thing you do is chain up.

I totally agree with this. The reason I mentioned them is for logic
flow consistency. I mentioned constructor before so I have to mentioned
a destructor and probably copy constructor concept (which I didn't). 

> - I would free self->name in finalize instead of dispose, along with
> any other memory that is fully owned by the MyPoint instance. In
> dispose, I would only drop any references to memory that had been
> passed in through MyPoint's API.

Hm... This is interesting point. For myself, dispose and finalize are
still very confusing. But it make sense now. I will try to add some
additional explanation to the text. 

> - I think it's confusing to have my_point_free() that calls
> g_clear_object(), since usually g_object_unref() is known as the
> standard way to release a reference to a GObject, and it doesn't
> necessarily free the object if there are other references.

I would call this as my personal vision. I mentioned that
<prefix>_free() is just a convenient wrapper around g_object_unref(). I
think this analogy comes from C world, where the free() family
functions are used to free the memory. Again, you probably observe this
situation through a prism of your experience but in my opinion for
beginner it is a little bit confusing to call g_object_unref()
especially in the situation where simple structure can be seen. I will
try to add some additional wording to clarify this a little bit more. 

Best,
> 
> Best regards,
> Philip C
> 
> On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list <
> gtk-devel-list@xxxxxxxxx> wrote:
> > I am putting together a tutorial how to use GObject. It is my
> > interpretation and I was trying to keep is as simple as possible
> > and
> > clear for new users. 
> > 
> > https://psunfun.blogspot.com/
> > 
> > Thanks.
> > 

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list