Re: Development with GObjects
I can help. But my interests do not got beyond C/C++ scope. I am writing other sections for my blog, where all other concepts will be introduced little-by-little. Anyway, let me know how I can help and we can discuss. On Mon, 2018-08-20 at 09:10 -0600, Sriram Ramkrishna wrote: > > > On Sat, Aug 18, 2018 at 2:03 PM Philip Chimento via gtk-devel-list < > gtk-devel-list@gnome.org> wrote: > > Nice work, Pavlo! I wonder if you can work this into a patch for > > the GObject documentation :-) > > > > You might want to check out > > https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/ > > as well. > > > > > > Pavlo, if you're interested we are working on a developer > documentation portal. We might not hit C first, but I'm sure we > could use your help when it comes to organizing and writing tutorials > when the time comes. It's worth joining up. Let me know! > > sri > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
On Sat, Aug 18, 2018 at 2:03 PM Philip Chimento via gtk-devel-list < gtk-devel-list@gnome.org> wrote: > Nice work, Pavlo! I wonder if you can work this into a patch for the > GObject documentation :-) > > You might want to check out > https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/ > as well. > > > Pavlo, if you're interested we are working on a developer documentation portal. We might not hit C first, but I'm sure we could use your help when it comes to organizing and writing tutorials when the time comes. It's worth joining up. Let me know! sri ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
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 < gtk-devel-list@gnome.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 > _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@gnome.org> 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@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
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 _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@gnome.org> 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@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
Nice work, Pavlo! I wonder if you can work this into a patch for the GObject documentation :-) 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 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. - 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. Best regards, Philip C On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list < gtk-devel-list@gnome.org> 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. > > -- > - Pavlo Solntsev > - > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > Sent from Evolution on GNU/Debian > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
