Minutes of the GTK+ Team IRC meeting - 2008-05-13

[Emmanuele Bassi]

= minutes for the 2008-05-13 meeting =

* website bugzilla component for gtk+ (timj)
- everyone agrees
- ACTION: add the component

* report on DNS update for www.gtk.org (timj)
- www.gtk.org is now on cube.gtk.org (MIT)
- ftp.gtk.org is still pending for accounts creation

* unit testing fixes (timj)
- mclasen reported segfaults on make check
- mclasen says are now fixed

* possible gtk+ meeting at linuxtag in berlin (timj)
- no other gtk+ developer there
- no meeting

* possible change of date for the meetings (mclasen)
- tuesday is good
- even for mclasen (family duties should not be a problem)
- time is good

* delegation of maintainership tasks (mclasen)
- especially releasing and other administration duties in case
  mclasen is not available for a while

* gtk+ 1.2 tutorial still in trunk (ebassi)
ACTION: remove gtk_tut.sgml from trunk (it's inside the gtk-1-2 branch)

* gtk+ 2.0 tutorial should not be packaged (ebassi)
- kept in trunk
- documentation should link the web version
ACTION: remove from the tarballs, and add link

* gtk+ 2.13 schedule for GNOME 2.24 (vuntz)
- trunk needs to be assessed
ACTION: mclasen will do a devel snapshot before next meeting
ACTION: prepare a list of outstanding 2.13 items before next meeting

* rework the gobject tutorial
- it is old and unmaintained
- the signals section is broken
- teaches bad practises

irc log available at: http://live.gnome.org/GTK+/Meetings
next meeting: 2008-05-27, 20:00 UTC

ciao,
 Emmanuele.

--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

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

[Stefan Kost]

Hi,

Emmanuele Bassi schrieb:
> = minutes for the 2008-05-13 meeting =
>
8< snip 8<

>
> * rework the gobject tutorial
> - it is old and unmaintained
> - the signals section is broken
> - teaches bad practises

I can go over it. Please send me pointers to what you want to have changed. From
my own todo list:
* G_DEFINE_TYPE and the like could be added (although I dislike their limmitations)

Speaking of docs. Whats the opinion of gtk/glib developers regarding inline
api-docs. I am much in favour of them. If the core developers are for it, we
could do a joint effort and move the docs. I did that once for gstreamer.
Unfortunately glib/gdk/gtk/gtk-pixbuf is too much for one person.

Stefan
>
> irc log available at: http://live.gnome.org/GTK+/Meetings
> next meeting: 2008-05-27, 20:00 UTC
>
> ciao,
>  Emmanuele.
>

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

[A. Walton-2]

On Wed, May 14, 2008 at 3:15 PM, Stefan Kost <ensonic@...> wrote:

> Hi,
>
> Emmanuele Bassi schrieb:
>> = minutes for the 2008-05-13 meeting =
>>
> 8< snip 8<
>
>>
>> * rework the gobject tutorial
>> - it is old and unmaintained
>> - the signals section is broken
>> - teaches bad practises
>
> I can go over it. Please send me pointers to what you want to have changed. From
> my own todo list:
> * G_DEFINE_TYPE and the like could be added (although I dislike their limmitations)
>
> Speaking of docs. Whats the opinion of gtk/glib developers regarding inline
> api-docs. I am much in favour of them. If the core developers are for it, we
> could do a joint effort and move the docs. I did that once for gstreamer.
> Unfortunately glib/gdk/gtk/gtk-pixbuf is too much for one person.

When asked on IRC (I'm not sure if it was me who asked or if it just
came up in discussion though; happened back when I was working on docs
for GIO so it's been a while), mclasen responded that he was in favor
of inlining the documentation, and that he was doing it as he went
along instead of just doing a mass move all at once (/paraphrase). I
don't know if that means he's against the mass move or not, we could
use him chiming in on this part.

I completely agree with you on this though, and I'm available to help
if this is something we really want to knock out. Having the docs in
the code means it's more likely the documentation will get touched
when the related code is touched, which means, at least in theory,
we'll have better documentation everywhere which is definitely a good
thing, for newer programmers and people like me with short attention
spans and bad memory.

Maybe we should put this on the next meeting's agenda?

2 cents, etc,
-A.Walton

> Stefan
>>
>> irc log available at: http://live.gnome.org/GTK+/Meetings
>> next meeting: 2008-05-27, 20:00 UTC
>>
>> ciao,
>>  Emmanuele.
>>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>

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

[Emmanuele Bassi]

On Wed, 2008-05-14 at 22:15 +0300, Stefan Kost wrote:

> > * rework the gobject tutorial
> > - it is old and unmaintained
> > - the signals section is broken
> > - teaches bad practises
>
> I can go over it. Please send me pointers to what you want to have changed. From
> my own todo list:

- the signals section is wrong on various levels that should require a
complete rewrite.

- storing signal ids inside the class structure is wrong; if a subclass
needs to emit a signal defined by its parent class, then it should call
g_signal_emit_by_name().

- the example of using signals to write a buffer to disk is utterly
wrong; it's a nice way of demonstrating overriding a virtual function,
not of using signals.

- the examples are inconsistent in the coding style, with obvious errors
due to copy and pasting from different sources. and please, let's drop
the MAMAN thing: only french-speaking people will get the reference; for
everyone else it's not different than calling the classes 'foo' and
'bar' - which, at least, would be an inside joke.

- the tutorial contains personal remarks that don't belong to a text
distributed with the library.

- the section about GTypeInstance should either be dropped or
incorporated into the GTypeInstance page of the API reference; as it is,
it just confuses readers.

- the private data section should be removed, and only
g_type_class_add_private() should be used to illustrate the private
pointer.

- the section about potential "abuses" of the signals is wrong; if we
are scare of potential "abuses" we should not put this information
inside the tutorial, but inside the API reference. the section does talk
about signal emission hooks and blocking, though; hence it's not abusing
anything.

- the tutorial references sources files that are not shipped with GLib.

- the dispose implementation is horrid, and there's no finalize example.

I already have a patch fixing some of the inconsistencies attached here:

  http://bugzilla.gnome.org/show_bug.cgi?id=530759

> * G_DEFINE_TYPE and the like could be added (although I dislike their limmitations)

using G_DEFINE_TYPE() at least avoids having non mt-safe GType
functions, for instance, unless you want to periodically not only
recompile, but rewrite them. let's face it: writing a get_type()
function is needed only for interfaces - and I'd really like to avoid
that as well with a G_DEFINE_INTERFACE macro. otherwise is just a huge
waste of time.

> Speaking of docs. Whats the opinion of gtk/glib developers regarding inline
> api-docs. I am much in favour of them. If the core developers are for it, we
> could do a joint effort and move the docs. I did that once for gstreamer.
> Unfortunately glib/gdk/gtk/gtk-pixbuf is too much for one person.

AFAIR, most of the gtk+ team is in favour of slowly moving away from
template files and use inlined gtk-doc. the task is daunting, and would
probably be a good chance to audit and improve (or correct) the current
documentation as well. personally, I feel that it's something that
should be tackled on a per-template file basis; even new contributors
could start doing this.

> Stefan
> >
> > irc log available at: http://live.gnome.org/GTK+/Meetings
> > next meeting: 2008-05-27, 20:00 UTC
> >
> > ciao,
> >  Emmanuele.
> >
>
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

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

[Stefan Kost]

Hi,
A. Walton schrieb:

> On Wed, May 14, 2008 at 3:15 PM, Stefan Kost <ensonic@...> wrote:
>> Hi,
>>
>> Emmanuele Bassi schrieb:
>>> = minutes for the 2008-05-13 meeting =
>>>
>> 8< snip 8<
>>
>>> * rework the gobject tutorial
>>> - it is old and unmaintained
>>> - the signals section is broken
>>> - teaches bad practises
>> I can go over it. Please send me pointers to what you want to have changed. From
>> my own todo list:
>> * G_DEFINE_TYPE and the like could be added (although I dislike their limmitations)
>>
>> Speaking of docs. Whats the opinion of gtk/glib developers regarding inline
>> api-docs. I am much in favour of them. If the core developers are for it, we
>> could do a joint effort and move the docs. I did that once for gstreamer.
>> Unfortunately glib/gdk/gtk/gtk-pixbuf is too much for one person.
>
> When asked on IRC (I'm not sure if it was me who asked or if it just
> came up in discussion though; happened back when I was working on docs
> for GIO so it's been a while), mclasen responded that he was in favor
> of inlining the documentation, and that he was doing it as he went
> along instead of just doing a mass move all at once (/paraphrase). I
> don't know if that means he's against the mass move or not, we could
> use him chiming in on this part.
>
> I completely agree with you on this though, and I'm available to help
> if this is something we really want to knock out. Having the docs in
> the code means it's more likely the documentation will get touched
> when the related code is touched, which means, at least in theory,
> we'll have better documentation everywhere which is definitely a good
> thing, for newer programmers and people like me with short attention
> spans and bad memory.
>
> Maybe we should put this on the next meeting's agenda?

 >
Yes, that would be good. I missed yestadays meeting, as my kid is sick and the
meeting is quite late (for finnish time).

It does not have to be a mass move. WHat imho is important is that it it done
file by file. Once a file is done, it should be removed from svn (and added to
the ignore list). Once the whole tmpl dir is done, the module can be switched to
a tmpl free build (its a bit faster).

Stefan

>
> 2 cents, etc,
> -A.Walton
>
>> Stefan
>>> irc log available at: http://live.gnome.org/GTK+/Meetings
>>> next meeting: 2008-05-27, 20:00 UTC
>>>
>>> ciao,
>>>  Emmanuele.
>>>
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list@...
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>

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

[Mikkel Kamstrup Erlandsen-2]

2008/5/14 Emmanuele Bassi <ebassi@...>:

On Wed, 2008-05-14 at 22:15 +0300, Stefan Kost wrote:

> > * rework the gobject tutorial
> > - it is old and unmaintained
> > - the signals section is broken
> > - teaches bad practises
>
> I can go over it. Please send me pointers to what you want to have changed. From
> my own todo list:

- the signals section is wrong on various levels that should require a
complete rewrite.

- storing signal ids inside the class structure is wrong; if a subclass
needs to emit a signal defined by its parent class, then it should call
g_signal_emit_by_name().

- the example of using signals to write a buffer to disk is utterly
wrong; it's a nice way of demonstrating overriding a virtual function,
not of using signals.

- the examples are inconsistent in the coding style, with obvious errors
due to copy and pasting from different sources. and please, let's drop
the MAMAN thing: only french-speaking people will get the reference; for
everyone else it's not different than calling the classes 'foo' and
'bar' - which, at least, would be an inside joke.

A humble request - if someone does a rewrite of the tutorial please use real world metaphors with obvious relations instead of abstract sizes like Foo and Bar. I always forget which one is parent and which one is child. Fx, Car and SportsCar or what ever. It is my experience that this approach is much more pedagogical.

Cheers,
Mikkel

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

[Alberto Ruiz-4]

2008/5/15 Mikkel Kamstrup Erlandsen <mikkel.kamstrup@...>:

2008/5/14 Emmanuele Bassi <ebassi@...>:

On Wed, 2008-05-14 at 22:15 +0300, Stefan Kost wrote:

> > * rework the gobject tutorial
> > - it is old and unmaintained
> > - the signals section is broken
> > - teaches bad practises
>
> I can go over it. Please send me pointers to what you want to have changed. From
> my own todo list:

- the signals section is wrong on various levels that should require a
complete rewrite.

- storing signal ids inside the class structure is wrong; if a subclass
needs to emit a signal defined by its parent class, then it should call
g_signal_emit_by_name().

- the example of using signals to write a buffer to disk is utterly
wrong; it's a nice way of demonstrating overriding a virtual function,
not of using signals.

- the examples are inconsistent in the coding style, with obvious errors
due to copy and pasting from different sources. and please, let's drop
the MAMAN thing: only french-speaking people will get the reference; for
everyone else it's not different than calling the classes 'foo' and
'bar' - which, at least, would be an inside joke.

A humble request - if someone does a rewrite of the tutorial please use real world metaphors with obvious relations instead of abstract sizes like Foo and Bar. I always forget which one is parent and which one is child. Fx, Car and SportsCar or what ever. It is my experience that this approach is much more pedagogical.

Yes, also, avoid adding comments on the code. It's a much better approach mix snippets within the code, and show the whole source file/method at the beginning or the end of the example.

Also, functions with more than a few lines of code doesn't help at all, if the user has to keep scrolling the webpage/pdf file to be able to get the full picture it gets harder to understand.

Cheers,
Mikkel

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

--
Un saludo,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list