Meeting on irc.gnome.org:#gtk-devel
Meeting started April 12 2004 17:08 EST (21:08 UTC)

In attendance:

 Jonathan Blandford (jrb), Anders Carlson (andersca), Matthias Clasen
 (maclas), Noah Levitt (noah), Federico Mena Quintero (federico), 
 Kris Rietveld (kris), Soeren Sandmann (ssp), Manish Singh (yosh), 
 Owen Taylor (owen)

<owen>	Item 1: what do people think of announcing these meetings on gtk-devel-list?
<owen>	I'm getting a little tired of maintaining my long invitee list :-)
<andersca>	sounds good
<ssp>	It's fine by me
<jrb>	how about a gtk-core-devel list or something
<mclasen>	can't hurt
<owen>	The main advantage I see of doing the invites privately is that people might feel more obligated to attend if they get asked explicitely :-)
<jrb>	(because we always need more mailinglists....)
<andersca>	jrb: I thought that was gtk-devel-list
<owen>	jrb: if we had something like that it would have to be explicitely administrative only ...
<andersca>	perhaps another mail alias?
<kris>	I don't see why gtkdev@gtk.org won't work./
<jrb>	owen: yeah.  you used something similar for discussing the release notes
<owen>	Oh, related topic - what would people think about killing the bug mail to gtkdev and making people watch gtk-bugs@gtk.org for bugzilla mail?
<mclasen>	watching gtk-bugs works nicely for me
<owen>	kris: Well, gtkdev@gtk.org is buried in bugzilla mail currently...
<jrb>	kris: forgot about that
<andersca>	bugzilla mail and spam...
<kris>	oh
<yosh>	could rename it to gtk-devel@gtk.org
<andersca>	yeah
<owen>	kris: plus I don't really see a reason for that to be there, everything else at gnome.org
<owen>	yosh: To confuse the heck out of everybody? 
<yosh>	heh, or some other non spamvertised email addy
<owen>	yosh: gtk-devel-asparagus@gtk.org ...
<andersca>	how does one watch gtk-bugs@gtk.org?
<owen>	andersca: Just go to your email preferences in bugzilla, there's a list of addresses to watch
<mclasen>	I think just posting invitations to the list should be fine; a mail alias will have to be maintained as well...
*	jrb loses track of the meeting 5 minutes in...
<owen>	mclasen: That would be my preference. Less work for me the better.
<owen>	Let's try that, if it doesn't work out, we'll try something different
<owen>	Any other opinions on the bug mail thing? Seems to be working OK for matthias and me (and people have been doing it for Pango for a while)
<owen>	The only real disadvantage is that when you change a bug you see *everybody* that gets mailed, but then again, maybe that will stop people adding me to the Cc: on gtk bugs
<owen>	OK, moving on - topic 2: branching
<owen>	My feeling is that we might as well do the branch and changelog juggling right now, yeah, it's a maybe a little more inter-branch merging, but we are used to that
<owen>	The other alternative woudl be to wait until 2.4.1
<jrb>	when is 2.4.1 planned for?
<mclasen>	when will we do that 
<owen>	jrb: That's topic 3
<owen>	OK, let's move to that and go back
<mclasen>	there's currently ~200 bugs on the 2.4.1 and 2.4.2 milestones. Do we want to fix any significant amount of these for 2.4.1 ?
<owen>	I'll be effecitively gone from April 23-30, and the jrb/maclas for some portion of that as well, so I think we should shoot for getting 2.4.1 out before then
<federico>	sorry, guys, back from lunch
<owen>	maclasen: No, no. :-)
<owen>	federico: Just talking about 2.4.1 schedule
<owen>	federico: What's the filechooser story on that?
*	jrb wants to see 139290 fixed
<federico>	owen: it's fairly well and the bugs are minor or future
<federico>	jrb: yeah, I'd say that's the most important one
<owen>	federico: Think you and jrb could get together over the next few days and make the GtkFileSel bug milestones relevant?
<federico>	and 138807
<federico>	owen: fine on my part
<jrb>	yeah, we should do that
<owen>	Does 2.4.1 next monday-ish sound reasonable? 
<andersca>	19th?
<owen>	And does anyone want to volunteer for the release-maker role. (If you volunteer, you get to pick the exact date)
<federico>	is this just for gtk or glib/pango as well?
<owen>	federico: Definitely glib. I may hold onto the Pango release pumpkin
<mclasen>	I would volunteer if I knew that I'll have my regular work machine by next monday...
*	mclasen would rather not try distchecking the whole gtk stack on this machine
<owen>	mclasen: Yeah, distcheck on that box might be a leetle bit painful. 
<kris>	I can distcheck on my athlon at work
<kris>	(since my home box is debian now)
<kris>	(and I have to use owen's libtool rpms)
<owen>	kris: Actually, *most* of that stuff is integrated into libtool. I used pretty much stock 1.5.2 for the last release
<federico>	where's the magic checklist of things to do to make a release, again?
<owen>	But probably still better to stick to a standard libtool rather than switching back and forth
<owen>	federico: under docs/
<kris>	federico: in cvs
<federico>	ah, ok
<owen>	kris: So, was that a volunteering?

[ IRC network problems ]

<mclasen>	so we agreed to branch after 2.4.1, next week ?
<kris>	for what?
<federico> ah, ok
<federico> I can do one of the two modules
<andersca> I could do the other, I'm free from school and everything until monday
<mclasen> volunteers found; should we go back to the branching question ?
<jrb> yeah
<andersca> branching would be sometime next week then
<federico> it's probably best to branch until after 2.4.1 to coax people to fix bugs rather than put in new features...
<federico> (when should we start discussing 2.6 features?)
<mclasen> if 2.4.1 is only a week away, I'd say we wait with branching until then, unless someone has urgent 2.6 stuff to deliver...
<mclasen>	owen: I think federico and andersca volunteered for one module each
<owen>	andersca/federico: OK, so you'll divide up gtk+ and glib and coordinate with me for pango?
<andersca>	fine by me
<federico>	owen: sure
<owen>	Waiting until after 2.4.1 to branch sounds reasonable to me
<andersca>	branch is cvs branching and moving the changelog?
<owen>	andersca: Yes
<andersca>	ok
<federico>	ooh, yes
<federico>	emacs is taking long to fontify it :)
<owen>	andersca: (Actually, what we've done is copied and truncated for the mechanics)
<kris>	vim doesn't.
<federico>	so, any critical bugs for 2.4.1?
<owen>	federico: Need to figure out how we are going to go through the bugs and figure that out
<owen>	federico: (Other than GtkFileSel, where you and jrb have been volunteered)
<mclasen>	owen: I can triage the combobox and uimanager bugs (and try to fix some)
<mclasen>	owen: gdk-pixbuf as well
<owen>	mclasen: That sounds good. I'll volunteer to triage glib and pango
<jrb>	I can give treeview a quick look
<federico>	we have a bunch of outstanding patches, don't we?
<mclasen>	approx 116 bugs with PATCH keyword...
<jrb>	federico: we have some from morten
<owen>	federico: Though that doens't necessarily mean much. The new patch status stuff is pretty neat.
<mclasen>	owen: did I miss something here (patch status) ?
<owen>	mclasen: With the bugzilla upgrade ... try editing a patch
<owen>	ssp: Any interesting in doing the triaging for GDK?
<mclasen>	cool
*	owen tries the "I need three volunteers, you, you and you approach"
<ssp>	owen: let me check how much work that is 
<jrb>	need GtkTextView triaged too
<kris>	op kris
<owen>	noah: input-methods? I don't think it will take more than 10-15 minutes
<owen>	OK, I'll take gtk/gtk and gtk/general as well. Blech.
<owen>	Next topic
<owen>	2.6!
<federico>	should we just wait for sun people to patch a11y bugs?
<jrb>	yay!
<federico>	w00t
<federico>	we absolutely must have a replacement for BonoboWindow/BonoboDock
<owen>	federico: I'd like to see us be more proactive about that ... built up some experience in the area in the gtk+ team
<owen>	federico: Is BonoboDock really useful?
<andersca>	I'm not sure it is
<owen>	federico: And how does it relate to IDE style docks?
<federico>	owen: I quite like it
<andersca>	maybe for bigger applications like gnumeric
<owen>	federico: What do you do with it?
<mclasen>	there is a dock widget in libegg...
<andersca>	yeah, that's an IDE style dock
<owen>	is that the same as the anjuta2 dock?
<federico>	owen: it basically integrates nicely with the XML menu/toolbar description stuff, so that the status bar displays item descriptions automatically; I *think* it also has some persistence features to let you save detachment status, etc.
<andersca>	owen: I don't think so
<ssp>	owen: I guess I can triage the gdk bugs if that just means "setting milestones", but more than I won't have time for
<jrb>	I never thought status bars were useful for that.
<andersca>	federico: I think BonoboWindow handles the status bar
<mclasen>	yes, it got added by biswapesh at some point
<federico>	andersca: I don't think it makes sense to have one without the other
<owen>	ssp: That's all I mean. Empty --- milestone 2.4.1 milestone has only bugs that you think that it is urgent to fix for 2.4.1
<owen>	ssp: We can look for other poeple to actually fix them
<owen>	(urgent or completely triival. One or the other)
<andersca>	federico: when I say 'dock' here, I mean 'the ability to drag around toolbars and menus'
<owen>	Ok, let's not get too bogged down in detail here -- the meeting has already gone on an hour
<jrb>	I am somewhat hopeful that lgs can do something interesting with GtkGrid
<andersca>	toplevel appwindow is on the plan anyway
<mclasen>	jrb: would that be a model-view sheet widget ?
<owen>	jrb/andersca/federico: So I'm getting support for the kill-libgnomeui major theme from you guys?
<andersca>	owen: big time
<mclasen>	jrb: on-par with treeview ?
<jrb>	mclasen: http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_project
<andersca>	jrb: must kill flaahgra
<federico>	owen: we need GnomeClient or an equivalent; we'd still need to keep libgnomeui around for the deprecated/bincompat widgets
<jrb>	owen: that's the major things we'd like to do.
<jrb>	federico: of course.  but we'd like to makr the whole library as deprecated
<owen>	Eek, uses GtkTreeModel. Anyways, details.
<jrb>	mclasen, owen: it's a bit rough, but the guy says a lot of the write things and has gotten things working already
<owen>	I think a GtkGrid like widget would need a) a mission statement. What is it? What is it not? b) A working prototype. c) An open source app using it
<owen>	and some careful API review. It would be nice to encourage those things *before* we make a commitment one way or the other for 2.6
<federico>	we'd need an about box (already in the plan) and hopefully a replacement for the stupid Gnome*Entry widgets
<jrb>	s/write/right
<mclasen>	federico: I worked on the about box about a year ago. bugzilla has the patches
*	owen wants to see a detailed plan on what would be involved. And doesn't really want to wait until jrb/andersca's talk at guadec for that
<federico>	mclasen: oh, cool!
<andersca>	owen: perhaps our talk can be named 'the future of libgnomeui - today'
<kris>	did you submit a talk?
<mclasen>	federico: http://bugzilla.gnome.org/show_bug.cgi?id=109435
<owen>	andersca; You can put up a web page in plan/2.6/ and then turn that into a talk at guadec
<jrb>	andersca: I was kinda hoping our talk would be "how we killed libgnomeui"
<owen>	OK, any other particualr features people just can't wait to talk about?
<jrb>	andersca: we had that list of things that need replacing;
<andersca>	I've worked on the option parser
<jrb>	owen: what do you think of typeahead in 2.4.x?
<andersca>	and I'm writing up something 
<federico>	owen: let me talk to gpoo about templates for gtkentry
<ssp>	owen: what about the height-for-width? I think it's probably needed for a good dock
<owen>	ssp: I'd love to have height-for-width. I don't think it's too hard, though it can easily get into "fix geometry management"
<owen>	federico: People have done quite a bit of work for that. I think there are extensive patches somewhere in bugzilla. It's one of those issues that the GTK+ team members don't care about but many users do.
<ssp>	owen: yeah, but does it make sense to have a height-for-width interface and then later a fix-geometry interface?
<owen>	jrb: typeahead in 2.4.x? Sounds scary to me
<andersca>	what about non-pixel units?
<jrb>	owen: is it scarier in 2.6.x?
<federico>	owen: it would make some things very nice, like IP address entries
<owen>	ssp: Well, we can bin-compat extend interfaces, but it woudl be good to look some at what all we need, and see what we can accomplish in one go
<federico>	andersca: xdevconf may be a good place to talk about that
<owen>	jrb: I think the idea is that we are more willing to make changes that might break apps in 2.6
<owen>	jrb: I think let's try to get typahead going on the unstable branch and get some experience with what-if-anything breaks
<owen>	jrb: then we can discuss backport
<jrb>	owen: alright.  I want to make a patch available for 2.4.x anyway though so we can test it with apps
<federico>	apart from features...
<jrb>	owen: most importantly evolution, which has a bunch of non-accelerated keybindings...
<owen>	andersca: non-pixel units, well, would be nice, but may be ENOTIME
<federico>	we need to have the APIs more or less settled a long time before the next gnome release, so that programs will actually use them, and so that we can find problems on time
<mclasen>	jrb: another treeview feature that would be nice to have in 2.6 is that "mode" stuff, so that combobox list mode can have proper mouse behaviour...
<jrb>	mclasen: owen shot down my mode proposal last time...
<owen>	federico: know a link to the gnome-2.8 schedule? This release would be targetted at 2..10
<owen>	jrb: I did? /me doesn't remember
<jrb>	owen: yeah.
<kris>	you did
<jrb>	you didn't like any of the modes kris and I proposed, anyway..
<kris>	and then we had no clue how to fix it
<kris>	so we didn't
<mclasen>	for combobox we only need a "focus-follows-mouse" mode...
<federico>	owen: jrb as a release-team dude may know better :)
<owen>	federico: BTW, what I think andersca means by non-pixel units is specifying padding, etc, in twips, points, whatever; which seems to me to be a GTK+ level thing, not X level
<andersca>	yeah
<jrb>	mclasen: that's not really a mode
<andersca>	owen's proposal about reserving upper bits for the unit type was kinda neat
<mclasen>	jrb: whatever it is, combobox needs it...
<owen>	http://mail.gnome.org/archives/desktop-devel-list/2004-March/msg00315.html
<federico>	I like Longorhn's idea of "logical pixels"
<owen>	Has 2.8.0 in mid-september
<federico>	it's in line with raph's ramblings around high-res displays
<owen>	federico: Well, pixels have to stay pixels, so if we encourage people to use something else, we need to do it some other way. We can't just start reinterpreting gtk_container_set_border_width (box, 10);
<mclasen>	owen: but we could reinterpret gtk_container_set_border_width (box, LOGICAL_PIXEL(10)) ...
<andersca>	ok, I need to leave
<andersca>	see you later all
<owen>	mclasen: Maybe. We'd need to add some sort of widget flag "I understand logical pixels"
<owen>	andersca: Later
<owen>	OK, anybody have issues with my strawman schedule?
<federico>	owen: is that "2.6 is for gnome 2.10"?
<jrb>	federico: yes
<ssp>	owen: Why can't 2.5.0 be released wihtout being feature complete?
<owen>	There would be about one month between gnome-2.8 and the gtk+ 2.8 API slush freeze according to that, which might be a bit tight to get extensive testing, if we see gnome as being the major testbed
<jrb>	owen: I like it.  We'll get people porting to GNOME apps in September, which will give us three months to shake things out.
<owen>	ssp: No reason, but I think utility of releasing tarball releases before things somewhat settle down isn't very big
<owen>	ssp: Basically, if we are continually changing things, the tarball is never going ot match the apps
<federico>	if we push 2.6 past gnome 2.8, we should *really* encourage people to use the new APIs in 2.4 for gnome 2.8
<federico>	make sure they remove deprecated stuff, align things for the deprecation of libgnomeui, etc.
<owen>	federico: Well, 2.6 before gnome 2.8 isn't feasible...
<owen>	federico: as far as I can see
<mclasen>	federico: what stronger encouragement than deprecating the old stuff do you have in mind ?
<federico>	owen: yeah, I'm just saying that we should try to engage people more with the plans for gtk+, rather than just expecting them to find the new features on their own
<federico>	mclasen: actively comb the code of core desktop apps to see where they are using non-deprecated APIs in cumbersome ways, and that could be made cleaner by using new APIs, etc.
<federico>	we need an API thought police
<owen>	federico: One problem is that the GNOME desktop is not necesarily very representative of the GTK+ app user base
<owen>	federico: In some sense,. the "fifth toe" stuff is the place where we really need to get some trial buy-in
<federico>	owen: I think it gives us a good indication of where people were using gtk+ for a long time and didn't switch to new APIs for historical reasons
<jrb>	API thought police???
<federico>	owen: yeah, that's a good idea... there's some interesting stuff there
<federico>	jrb: to avoid stupidities like "while (!done) { gtk_dialog_run (file_chooser); if (!is_dir (file_chooser_get_filename()) done = TRUE; }"
<jrb>	federico: needs rebranding though. (-:
<mclasen>	federico: I guess that just points out the importance of good examples in the docs
<owen>	OK, I need to think about getting home here. Any other thoughts?
<kris>	I am thinking about sleep
<kris>	only 6 hours left for kris
<mclasen>	next meeting time ?
<ssp>	so am I
<owen>	Do we want to meet again next week? I think the week after that is out (RH company meeting)
<federico>	mclasen: it was really a bug
<mclasen>	federico: I meant more generally, we need examples demonstrating proper use of new api (unless it is obvious)
<jrb>	(do we want to discus moving this earlier again? We're losing the europeans)
<federico>	mclasen: yeah, we do
<ssp>	owen: if you think there is something to be discussed, you can announce a meeting
<owen>	federico: What do you think about an hour earlier?
<federico>	owen: works for me... it falls on my lunchtime, but since I work from home these days, it's not a problem
<owen>	jrb: Though I think in general this one just ran too long. We need to keep to an hour. (The IRC problems didn't help)
<owen>	OK, we'll try an hour earlier next time and play it by ear if we have one or not

Meeting ended April 12 18:29 EST (22:29 UTC)