Meeting on irc.gnome.org:#gtk-devel Meeting started July 20 2004 17:02 EST (21:02 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (mclasen), Federico Mena Quintero (federico), James M. Cape (Jimbob), Soeren Sandmann (ssp) coffee! coffee!! ok, got mine. Shall we start ? The one thing I put on the agenda was "making the meeting more accessible", since I saw the discussion on gtk-devel-list between federico and billh regarding participation of the a11y team in this meeting... sure bill proposed to move the meeting to an earlier time, like 10am EST to give the sun people in ireland a chance to participate do we think they'd show up if we hed it then? We could try and invite them. If they don't show up, we can move back to the old time... sounds reasonable Would it help if they did? Isn't the problem that their patches don't get reviewed? or maybe we can just do a singular "joint gtk/atk meeting" ssp: the a11y combobox patches have been looked at we just didn't really like the proposed api unfortunately, we don't really have a better proposal either, short of moving the a11y implementation inside gtk the problem is that we want to hide implementation details in the combobox api, but a11y seems to need access to all the details like position of characters on the screen, things like that the reason the a11y implementation isn't in GTK+ is there was no way to do that and get GTK+ 2.0 out but now that GtkCellView is no longer private, maybe we can take another look at the combobox a11y problem it's probably worth reassessing that with a strict separation between gtk and the a11y impl, it is not possible to have private widgets in gtk which are accessible... but coming back to making the meeting time. Would a time like 10am EST be accessible for all participants ? mclasen: yeah. Though we have added a11y-only calls in the past to get things working, eg: gtk_tree_view_set_destroy_count_func why don't we have a11y implementations inside gtk? federico: the combobox a11y bug contains an answer from Padraig why he didn't want to write a patch for that basically, he would have to duplicate a lot of auxiliary code which currently lives in atk 10 am EST would be fine by me mclasen: As a pseudo-lurker, 10a is about 2h too early for me (I've got classes until 11:45a EST). But a11y takes precidence over me being able to pseudo-lurk, IMO :-) Jimbob: you have code in GTK+ now, don't you? jrb: proposed code, anyways ok, then I guess we'll try the early time next week, and I'll send a special invitation to the a11y guys. We should probably discuss a11y then next week... do we have other topics to discuss ? according to www.gtk.org/plan/2.6, we'll do weekly 2.5.x releases until 2.6.0... since we have done 2.5.0 now, we should probably start looking for volunteers... weekly?? that sounds like overkill to me ah, it says "every other week", so thats probably biweekly which probably makes more sense what features can we expect to land during the next two weeks ? mclasen: so let us put 'release volunteer' on the agenda for the next meeting ssp: yes federico: do you plan to work on any of the 2.6 file chooser additions during the next 2 weeks ? mclasen: yeah, I guess I should need to talk to people about what sort of APIs they want btw, during a subsequent meeting, should we talk again about synchronizing gtk to the gnome schedule? do we really want that ? Do THEY really want that ? the problem with staggered releases is that it takes *two* gnome releases for gtk+ features to reach users federico: you want the ellipsizing, don't you jrb: that, but also the (currently nonexistent) searching APIs for gtkfilechooser also, if we were synchronized, I think it would make people pay more attention to gtk and contribute more to it ...and get more early testing of new apis federico: it's not unreasonable so while 2.6 is too late now for gnome's purposes, I think we could afford to cut the gtk 2.8 schedule a bit short and synchronize it with gnome federico: would the gnome release team be willing to depend on an unreleased gtk ? I'm not convinced it's a good idea. I am affraid it will make GNOME people think they get to decide the direction of gtk+ mclasen: we do for all the other libraries. ok, I guess we should discuss this again when we get closer to the 2.6 release last topic before I have to run off: did anybody look into the icon theme sharing/mmap stuff which has been discussed ? not me, but if alan's library is as tiny as he boasts, then it could be a nice little toy to have in gtk or glib what about the performance patches which we put into 2.5.0 now, I think we had the idea to maybe backport them to 2.4.x if they haven't caused problems in 2.5.x for a while would it be appropriate to target that for 2.4.5, or should we wait longer before doing that ? I run my system with HEAD, and nothing has broken so far; I really don't know if it is faster :) any speed increase is probably offset by my laptop's frequent swapfests the icon theme sharing could help there... ...at least a bit mclasen: When is 2.4.5? I think we said 5-6 weeks after 2.4.4 until something urgent shows up mclasen: andersca pointed out a bug in the update counter code that should be fixed before we put it in stable ssp: ok, I'll ask again before I do 2.4.5... brb mclasen: I'm not sure the unset bg patch should go into stable at all, but the predictive expose should be pretty safe ok I'll have to go now. Bye Meeting ended July 20 18:00 EST (22:00 UTC)