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...
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.