< ebassi> so, let's start with the various items of the meeting? < ebassi> 1. GSEAL progress report (timj) < ebassi> 2. GIO FileChooser merge post-mortem and pending issues/bugs (mclasen, garnacho) < ebassi> 3. deprecating gtk_widget_new() (timj) < ebassi> 4. Offscreen patch status and next steps (ebassi, timj) < mitch> can i add 5. deprecating as much of gtktypeutils.h as humanly possible? < ebassi> mitch: sure you can :-) < mitch> so i do :) < timj> -1. GSEAL progress report (timj) < 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 < timj> then we'll commit the history to upstream < 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 < diegoe> timj: for history reasons and sneak peaks it would be nice :) < timj> diegoe: ok < timj> garnacho: are you here for #2 ? < garnacho> yes, but learned recently that there was an item for the filechooser :) < garnacho> not sure what matthias wanted to mention here < ebassi> garnacho: I added that :-) < garnacho> ah :) < ebassi> garnacho: I wanted to have a post-mortem: pending issues, things that broke, things missing < ebassi> garnacho: just for the folks following the minutes < ebassi> (and for me :-)) < garnacho> sure :), the filechooser is already merged, I've been working on some issues I found (these are already committed) < garnacho> one thing that has been broken is libgnomeui, still have to provide a patch for that < garnacho> and I'd like to work on a couple of improvements to the filechooser in the gio side < garnacho> namely, there's no difference between the auth dialog being cancelled and the 3 tries expiring < garnacho> and mount operations are not cancellable < garnacho> I'll also work on any bugs that pop up in bugzilla, obviously :) < ebassi> cool < garnacho> oh, and I'm thinking we should also deprecate gtk_file_chooser_*_new_with_backend() < mitch> (and i just managed to deprecate GtkType) < mitch> in my tree :) < ebassi> garnacho: since the backends are now gone, I'd say +1 to deprecate that < ebassi> mitch: w00t :-) < mitch> garnacho: i agree, it serves no purpose < garnacho> will cook a patch :) < mitch> ebassi: not as impressive as it sounds, 4 files changed, 3 already committed < timj> ok, do we move on to the next point? < ebassi> since we're talking about deprecations... :-) < timj> -3. deprecating gtk_widget_new() (timj) < 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. < timj> i was hoping for an opinion from mclasen here as well... < jdahlin> are the semantics for gtk_widget_new different from g_object_new? < jdahlin> [except that the GType obviously needs to be a subtype of GtkWidget] < timj> currently, no < timj> it became a mere alias with the introduction of GObject, just like widget_ref/unref < mitch> get rid of it, it serves no purpose < mitch> die die die < timj> so, unless anyone has any objections, i'll pass deprecation of this on to the cleaner ;) < jdahlin> there seems to be a couple of callsites, mostly from deprecated widgets < mitch> jdahlin: these don't matter < timj> jdahlin: easily sed-able. we could even mention an sed line in the next migration instructions < mitch> sed breaks indentation < mitch> i object < mitch> people can fix their code properly in an editor < timj> mitch: i take it you object to sed, not deprecation ;) < mitch> and the get to see their rotting crap after a while again < mitch> yes no sed :) < jdahlin> mitch: non issue with the current broken mismatch of tabs and spaces < mitch> jdahlin: haha indeed < mitch> if i was in charge... ;) < timj> mitch: ok, please deprecate then, i'll move on: < timj> -4. Offscreen patch status and next steps (ebassi, timj) < 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 < 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 < 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. < timj> so before guadec it'd make sense to concentrate on applying refactorings and unit tests < ebassi> the refactorings are quite clearly split and the hell if other backends break... ehm... ;-) < jdahlin> as in non-X11? < ebassi> yep < jdahlin> probably up to tml and richard < 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) < timj> ebassi: hm, do you mean you're likely to have 2 rebased patches next week? 1-refactorings, 2-event stuff. < ebassi> yes < timj> ebassi: great. richard will be back from vacation next week, i'm sure we can make him look at the refactorings then < ebassi> cool < timj> i'd really like to see that committed before guadec < timj> about a gtk BOF where we can talk about even processing, do we have a gtk BOF registered at all for guadec yet? < timj> could drop behdad a line about it otherwise i guess... < timj> s/even /event / < ebassi> timj: I think we have one < ebassi> lemme check the schedule < behdad> timj: you've got a meeting scheduled < behdad> timj: for the BoF, just drop any TBC slot in the schedule and drop me a line in mail < timj> what's the schedule URL again? < behdad> https://guadec.expectnation.com/guadec08/public/schedule < behdad> meeting is on 8th IRC < ebassi> yep < ebassi> 2008-07-08, 12:00 < timj> hm, 1h might be too short if people want to discuss 3.0 again ;) < timj> behdad: could you reserve the 14:30 slot for gtk as well for possible continuations? < behdad> sure < timj> thx * behdad likes over-lunch meetings :D < timj> speaking of 3.0, there's one other issue i shortly meant to discuss here: < timj> moderation of gtk-devel-list < behdad> do you also want me to get foundation sponsor the lunch meeting? :D < 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 < behdad> someone else needs to do the reservation though < behdad> timj: he did that just for one person < ebassi> timj: yeah, about that :-) < 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 < bkor> timj: if you don't want me or do want me to do that, just tell me.. only moderated one person < bratsche> I wish I was going to guadec this year. < 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. < bkor> didn't keep the rejected msg(s? forgot), but it was needed IMO (personal attack) < timj> behdad: yes, thanks for the reminder < behdad> http://guadec.expectnation.com/guadec08/public/schedule/grid?date=2008-07-08 < behdad> meeting 12:00 to 15:15 now < timj> bkor: either way, i think we should have discussed this here, because it's a change in policies < ebassi> as far as I'm concerned, moderation is perfectly fine - even if I could be subject to it < ebassi> well, especially :-) < timj> ebassi: i don't think we have a need to moderate (core) developers at this point ;) < 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 < diegoe> 8th at 17-19 is expected to be the freefa soccer match :p < behdad> diegoe: drop me a mail to add it somewhere to the schedule < bkor> timj: perhaps foundation list discussion, or do you think better just gtk? < diegoe> behdad: ok, ill be confirming that tomorrow probably < 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 < 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 < timj> if nobody has anything else to add, we'll move on... < timj> -5. deprecating as much of gtktypeutils.h as humanly possible? (mitch) < mitch> i already did GtkType and gtk_type_class() on my disk < ebassi> mitch: does the beast link? ;-) < mitch> yes ;) < mitch> i'd also like to deprecate the vtable entries of GtkObjectClass < mitch> and replace them with dummy gpointers in case DISABLE_DEPRECATED is set < timj> no objections for deprecations from me...