1 < ebassi> so, let's start with the various items of the meeting?
   2 < ebassi> 1. GSEAL progress report (timj)
   3 < ebassi> 2. GIO FileChooser merge post-mortem and pending issues/bugs (mclasen, garnacho)
   4 < ebassi> 3. deprecating gtk_widget_new() (timj)
   5 < ebassi> 4. Offscreen patch status and next steps (ebassi, timj)
   6 < mitch> can i add 5. deprecating as much of gtktypeutils.h as humanly possible?
   7 < ebassi> mitch: sure you can :-)
   8 < mitch> so i do :)
   9 < timj> -1. GSEAL progress report (timj)
  10 < timj> Mitch and me have completed review of the recent changes in our GSEAL branch. we're fixing the quirks now and also take mclasen's comments into account
  11 < timj> then we'll commit the history to upstream
  12 < timj> if someone wants to see/review the final resulting patch (roughly 5k - 6k locs), tell me and i'll post it to gtk-devel after the merger
  13 < diegoe> timj: for history reasons and sneak peaks it would be nice :)
  14 < timj> diegoe: ok
  15 < timj> garnacho: are you here for #2 ?
  16 < garnacho> yes, but learned recently that there was an item for the filechooser :)
  17 < garnacho> not sure what matthias wanted to mention here
  18 < ebassi> garnacho: I added that :-)
  19 < garnacho> ah :)
  20 < ebassi> garnacho: I wanted to have a post-mortem: pending issues, things that broke, things missing
  21 < ebassi> garnacho: just for the folks following the minutes
  22 < ebassi> (and for me :-))
  23 < garnacho> sure :), the filechooser is already merged, I've been working on some issues I found (these are already committed)
  24 < garnacho> one thing that has been broken is libgnomeui, still have to provide a patch for that
  25 < garnacho> and I'd like to work on a couple of improvements to the filechooser in the gio side
  26 < garnacho> namely, there's no difference between the auth dialog being cancelled and the 3 tries expiring
  27 < garnacho> and mount operations are not cancellable
  28 < garnacho> I'll also work on any bugs that pop up in bugzilla, obviously :)
  29 < ebassi> cool
  30 < garnacho> oh, and I'm thinking we should also deprecate gtk_file_chooser_*_new_with_backend()
  31 < mitch> (and i just managed to deprecate GtkType)
  32 < mitch> in my tree :)
  33 < ebassi> garnacho: since the backends are now gone, I'd say +1 to deprecate that
  34 < ebassi> mitch: w00t :-)
  35 < mitch> garnacho: i agree, it serves no purpose
  36 < garnacho> will cook a patch :)
  37 < mitch> ebassi: not as impressive as it sounds, 4 files changed, 3 already committed
  38 < timj> ok, do we move on to the next point?
  39 < ebassi> since we're talking about deprecations... :-)
  40 < timj> -3. deprecating gtk_widget_new() (timj)
  41 < timj> gtk_object_new has been deprecated for ages, and g_object_new() is currently the recommended substitute for creating widgets and objects. consequently i'd like to see gtk_widget_new deprecated, especially since it might be useful to reintroduce this function in 3.x future with different semantics.
  42 < timj> i was hoping for an opinion from mclasen here as well...
  43 < jdahlin> are the semantics for gtk_widget_new different from g_object_new?
  44 < jdahlin> [except that the GType obviously needs to be a subtype of GtkWidget]
  45 < timj> currently, no
  46 < timj> it became a mere alias with the introduction of GObject, just like widget_ref/unref
  47 < mitch> get rid of it, it serves no purpose
  48 < mitch> die die die
  49 < timj> so, unless anyone has any objections, i'll pass deprecation of this on to the cleaner ;)
  50 < jdahlin> there seems to be a couple of callsites, mostly from deprecated widgets
  51 < mitch> jdahlin: these don't matter
  52 < timj> jdahlin: easily sed-able. we could even mention an sed line in the next migration instructions
  53 < mitch> sed breaks indentation
  54 < mitch> i object
  55 < mitch> people can fix their code properly in an editor
  56 < timj> mitch: i take it you object to sed, not deprecation ;)
  57 < mitch> and the get to see their rotting crap after a while again
  58 < mitch> yes no sed :)
  59 < jdahlin> mitch: non issue with the current broken mismatch of tabs and spaces
  60 < mitch> jdahlin: haha indeed
  61 < mitch> if i was in charge... ;)
  62 < timj> mitch: ok, please deprecate then, i'll move on:
  63 < timj> -4. Offscreen patch status and next steps (ebassi, timj)
  64 < timj> recently the pixmap redirection has been committed upstream, so the next steps i think are applying ebassi's refactorings and then tackle even handling properly
  65 < ebassi> status from me: the rebasing took some more time than expected, and I'm off until friday; I hope to finish it off on the plane
  66 < timj> there are a few tricky bits with event handling that i think would be good to discuss solutions for in a BOF at guadec. 
  67 < timj> so before guadec it'd make sense to concentrate on applying refactorings and unit tests
  68 < ebassi> the refactorings are quite clearly split and the hell if other backends break... ehm... ;-)
  69 < jdahlin> as in non-X11?
  70 < ebassi> yep
  71 < jdahlin> probably up to tml and richard
  72 < ebassi> basically, since the offscreen redirection needs a GdkOffscreenWindow which is backend agnostic, it needs most of the GdkWindow API moved into an interface (like GdkDrawable did)
  73 < timj> ebassi: hm, do you mean you're likely to have 2 rebased patches next week? 1-refactorings, 2-event stuff.
  74 < ebassi> yes
  75 < timj> ebassi: great. richard will be back from vacation next week, i'm sure we can make him look at the refactorings then
  76 < ebassi> cool
  77 < timj> i'd really like to see that committed before guadec
  78 < timj> about a gtk BOF where we can talk about even processing, do we have a gtk BOF registered at all for guadec yet?
  79 < timj> could drop behdad a line about it otherwise i guess...
  80 < timj> s/even /event /
  81 < ebassi> timj: I think we have one
  82 < ebassi> lemme check the schedule
  83 < behdad> timj: you've got a meeting scheduled
  84 < behdad> timj: for the BoF, just drop any TBC slot in the schedule and drop me a line in mail
  85 < timj> what's the schedule URL again?
  86 < behdad> https://guadec.expectnation.com/guadec08/public/schedule
  87 < behdad> meeting is on 8th IRC
  88 < ebassi> yep
  89 < ebassi> 2008-07-08, 12:00
  90 < timj> hm, 1h might be too short if people want to discuss 3.0 again ;)
  91 < timj> behdad: could you reserve the 14:30 slot for gtk as well for possible continuations?
  92 < behdad> sure
  93 < timj> thx
  94  * behdad likes over-lunch meetings :D
  95 < timj> speaking of 3.0, there's one other issue i shortly meant to discuss here:
  96 < timj> moderation of gtk-devel-list
  97 < behdad> do you also want me to get foundation sponsor the lunch meeting? :D
  98 < timj> we've been having one or two "unproductive" threads on gtk-devel list recently and at some point bkor decided to start moderating individuals
  99 < behdad> someone else needs to do the reservation though
 100 < behdad> timj: he did that just for one person
 101 < ebassi> timj: yeah, about that :-)
 102 < behdad> timj: also note that advisory-board meeting is on same day 14:30..18:15.  we'll bring you in after the gtk+ meeting then
 103 < bkor> timj: if you don't want me or do want me to do that, just tell me.. only moderated one person 
 104 < bratsche> I wish I was going to guadec this year.
 105 < timj> i wanted to bring this up here to sense: a) if people feel generally ok with moderating participants if things get out of hand (we've not done this in the past); b) *what* actually should be moderated. i tend to say "clear trolling"/off-topic discussions here, but that's of course always a judgement call.
 106 < bkor> didn't keep the rejected msg(s? forgot), but it was needed IMO (personal attack)
 107 < timj> behdad: yes, thanks for the reminder
 108 < behdad> http://guadec.expectnation.com/guadec08/public/schedule/grid?date=2008-07-08
 109 < behdad> meeting 12:00 to 15:15 now
 110 < timj> bkor: either way, i think we should have discussed this here, because it's a change in policies
 111 < ebassi> as far as I'm concerned, moderation is perfectly fine - even if I could be subject to it
 112 < ebassi> well, especially :-)
 113 < timj> ebassi: i don't think we have a need to moderate (core) developers at this point ;)
 114 < bkor> timj: I just considered all mailing lists a 'don't troll too much (IMO I'm very lenient, a few have said privately they hate the current signal/noise.. but that is more than just gtk-devel)', except when maintainers say it is ok
 115 < diegoe> 8th at 17-19 is expected to be the freefa soccer match :p
 116 < behdad> diegoe: drop me a mail to add it somewhere to the schedule
 117 < bkor> timj: perhaps foundation list discussion, or do you think better just gtk?
 118 < diegoe> behdad: ok, ill be confirming that tomorrow probably
 119 < timj> bkor: i think most agree that the last thread got out of hands and that personal attacks are unproductive so should be fine to be kept off the list if it really gets out of hand
 120 < timj> bkor: i've added myself as list maintainer as well now (since owen isn't actively maintaining it anymore), so i also see moderation requests
 121 < timj> if nobody has anything else to add, we'll move on...
 122 < timj> -5. deprecating as much of gtktypeutils.h as humanly possible? (mitch)
 123 < mitch> i already did GtkType and gtk_type_class() on my disk
 124 < ebassi> mitch: does the beast link? ;-)
 125 < mitch> yes ;)
 126 < mitch> i'd also like to deprecate the vtable entries of GtkObjectClass
 127 < mitch> and replace them with dummy gpointers in case DISABLE_DEPRECATED is set
 128 < timj> no objections for deprecations from me...