Development with GObjects

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Development with GObjects

Gtk+ - Dev - General mailing list
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 <www.debian.org>


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Development with GObjects

Gtk+ - Dev - General mailing list
Nice work, Pavlo! I wonder if you can work this into a patch for the GObject documentation :-)


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 <[hidden email]> 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 <www.debian.org>


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Development with GObjects

Gtk+ - Dev - General mailing list
Thank you, Philip,

On Sat, 2018-08-18 at 16:02 -0400, [hidden email] 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 <
> [hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Development with GObjects

Gtk+ - Dev - General mailing list
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 <[hidden email]> wrote:
Thank you, Philip,

On Sat, 2018-08-18 at 16:02 -0400, [hidden email] 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 <
> [hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Development with GObjects

Sriram Ramkrishna
In reply to this post by Gtk+ - Dev - General mailing list


On Sat, Aug 18, 2018 at 2:03 PM Philip Chimento via gtk-devel-list <[hidden email]> wrote:
Nice work, Pavlo! I wonder if you can work this into a patch for the GObject documentation :-)




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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Development with GObjects

Gtk+ - Dev - General mailing list
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 <
> [hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list