I needed this. i will try this out. thanks.
please include a patreon link as well On Sun, Aug 19, 2018 at 2:27 AM, Pavlo S. via gtk-devel-list < firstname.lastname@example.org> wrote: > Thank you, Philip, > > On Sat, 2018-08-18 at 16:02 -0400, philip.chime...@gmail.com 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 < > > email@example.com> 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 > firstname.lastname@example.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list >
_______________________________________________ gtk-devel-list mailing list email@example.com https://mail.gnome.org/mailman/listinfo/gtk-devel-list