Meeting on irc.gnome.org:#gtk-devel Meeting started August 30 2005 16:11 EDT In attendence: Kristian Rietveld (kris) Matthias Clasen (mclasen) Owen Taylor (owen) Jonathan Blandford (jrb) Federico Mena Quintero (federico) Tor Lillqvist (tml) the meeting is like right now right? not sure (my clock is off) It's 20:00 on the dot no w BING, meeting started agenda? 1) working on the 2.10 schedule 2) should we agree on a time for a GTK+ team gettogether during the Boston Summit ? ok, starting with 1) I put a draft schedule up at www.gtk.org/plan/2.10 (ignore the broken server-side includes...) i came up with this: http://www.babi-pangang.org/~kris/2.10-plans (my laptop is going to run out of battery soon, so i might drop off for a few minutes) kris: I gave you my feedback there already yep ooks like a reasonable list. Do you want me to update the treeview section of the 2.10 plan with that list ? Looks, even oh, sure mclasen: going along with that is the multi-drag API for the IconView kris: I would like to have a column editor, if only internally in the file chooser jrb: yes, for the icon view dnd I just copied the tree view dnd api why is a column editor in the filechooser useful>? jrb: so if we add a multi-dnd api to the tree view, it should be propagated to the icon view mclasen: exactly kris: because some people want to add extra fields, like file size ok so if we are going to add this column editor to the file chooser, it doesnt make any sense to not add it for general treeviews imho (OK, server-side includes fixed ... new directories have to be added to install.sh) owen: I'm not very hopeful that I will remember that till the next time... mclasen: there are a bunch there that are queued and ready(ish) to go jrb: a bunch of what ? mclasen: features mclasen: they need a round of API discussion oh, I was about to ask how we initiate that (like Druid, HRef) eg the recent files stuff, and the assistant I think gtk-devel-list is the right place for API review but of course, people certianly do post API review stuff there and get no response (recent files stuff, for example) owen: yeah. That's an issue (though, they're often hard)-: did federico follow the recent files stuff ? I thought he did, at least initially The trouble really is that good API review is time exhaustive ... so just posting sometihng to the list isn't necessarily going to cause anybody to schedule it in mclasen: I think he did some yeah. We also need API freeze on the schdule. Maybe we can try being more agressive by explicitly scheduling API reviews ok, so I will try to spend some time on the recent-files and druid apis, and post reviews mclasen: One thing that might help would be simply having a list of what's blocking on API review. owen: to a certain extent, a lot of these are blocking on 'design', too. Like if we decide to implement GnomeHRef via GtkLabel/markup vs. GtkButton owen: we could turn the plan page into a table showing some status for each feature, like "needs review" jrb: Yeah, certainly there is often preliminary discussion that strongly influences the API design jrb: I've asked that in the bug already: is GnomeHRef actually useful ? I mean, is it used ? mclasen: about box has a URL; it pops up often enough mclasen: *shrug*. It's a little weird as older machines sometimes end up with 404s, but that's okay jrb: about box uses a homegrown solution for that mclasen: yup. Just pointing a use of the URL. Part of Ridley is deciding what we need to salvage, and this may not make the list. (-: We probably shouldn't get bogged down with this particular example, though jrb: sure, but we also do not want to disappoint eager porters, who put lots of work into useless widgets... mclasen: exactly. So we need to frontload this stuff mclasen: especially for giant ones like the canvas. jrb: on the recent-files stuff, we really dropped the ball a bit already mclasen: yeah Aug 30 16:39:14 * owen has some doubts about how recent files is going to work wihtout a VFS dependency jrb: since we probably do not want to add a libxml dependency for recent files... owen: or the on-disk mess that we've inherited (though we could easily just move on there) jrb: well, it's more a question of interpretation if you get an URI jrb: though I suppose we could copy the dual-mode-api of GtkFileChooser, and indiicate whether you can handle URIs owen: sounds reasonable jrb: in terms of libxml, no, I don't want to depend on 1M+ library just for recent files jrb: I haven't looked at our current on-disk stuff, but maybe we could get away with parsing it with GMarkup? owen: looks pretty GMarkup-parseable owen: the on-disk format is pretty busted (as I understand it) independent of what we use to parse it. But I haven't looked in a while and we can probably change the layout. jrb: As long as we use a different filename we should probably move this discussion to the API/Design review thread for recent-files on gtk-devel (when it happens) Yeah... yup OK, so what should we be dicsussing now? This meeting (as many of these) is drifting a bit :-) owen: Boston Summit we should try to have a meeting with those who can make it who will be there ? but more interestingly, there seems to be more consensus for a hack fest atmosphere ebassi wants to use libxml for recent-files i won't be at the boston summit due to the simple reason that i refuse to enter the usa ;) jrb: Who is going to be there? RH people, federico are all I see on TellUsYoureComing the kde people/mozilla don't want to adopt the standard unless it is based on xbel and xbel requires pretty hefty xml parsing tml: will you be in boston ? * owen is not feeling charitable to mozilla at the moment mclasen: nope they can just fork gtk... mclasen: we should trademark gtk vektor: any chance you'll make it to Boston? jrb: first of all, we should agree on a time during the Boston summit what's hard about xbel? of course, you *could* write out xbel files with arbitrary encodings, etc, but do people? owen: let me ask ebassi again, but I *think* he mentioned xinclude if mozilla had designed the file format, you would need javascript to interpret it... f_lunch: I'm siure there are cracked out people who want to include some remote http URI in their xbel file but but hehe, yeah mclasen: I suppose it depends what we want to accomplish. Though it sounds like API/design review is the most important thing anyway, bbiab mclasen: or actually, maybe i should start asking my boss, when is it? tml: second weekend in oct, sat - mon mclasen: Nat was pushing to have the Boston summit be pretty code-heavy mclasen: we could run it as a hackfest-type affair and try to hammer out a widget or two. (-: jrb: so should just fix a time, say Sunday morning ? mclasen: If we want to do hacking over the weekend, we possible should plan on it on Saturday on an initial meeting owen: fine with me I'll try to find a good spot on the schedule on Saturday, and report back next week OK, shouldn't be hard. Just stick it in at 2:00 pm say ok, before everybody (at least me) runs away, I went over the api bugs last week, and moved some reasonably looking ones to the 2.10 api freeze milestone one bug on which I wanted some input is the request to undeprecate the toolitem set_icon_size function where the argument is that "ordinary" toolbars should really follow the desktop-wide settings, but there may be "special" toolbars where this does not apply I think vektor also had this problem at some point in eclipse so, would you agree to convert the deprecation into a doc comment strongly discouraging the use of the function for ordinary toolbars ? mclasen: Can't really think of any arguments against it. We do have the _unset() function so their's a consistent meaning if set it overrides, if not set, it doesn't Does the property have an unset state? that might be an issue (is there a property?) we should have a profiling hackfest f_lunch: that's been #fedora-desktop for the past couple weeks owen: we have a icon_size_set flag jrb: oooh - lorenzo's work? f_lunch: yeah f_lunch: you mean gtk-perf hacking ? mclasen: not really; more like general gnome profiling * jrb isn't really sure that that's suited for a hackfest, but we can discuss it closer to the date * jrb was thinking of tackling GnomeApp but we can figure it out jrb: I really want to get jody and mmeeks together to talk about gnomeapp (GnomeApp seems potentially more parallelizable) anyway, looks like we're running out of steam a little bit. * mclasen runs out of time, personally uh oh tick tick tick tick tick tick ok, need to go. see you next week, hopefully no new gtk releases until then... (we could also do a Print dialog) heh Meeting ended 17:06 EDT