Meeting on irc.gnome.org:#gtk-devel Meeting started August 23 2005 16:02 EDT In attendence: Matthias Clasen (matthias) Jonathan Blandford (jrb) Kristian Rietveld (kris) Owen Taylor (owen) Tor Lillqvist (tml) Johan Dahlin (jdahlin) Jody Goldberg (jody) Behdad Esfabod (behdad) Billy Biggs (vektor) Thorsten Schoenfeld (kaffee) John Ehresman (jpe) ok, its time already yay ok, so I guess we should discuss Project Ridley and how to destill a 2.10 schedule from it before diving into that: I'll do 2.8.1 later tonight or early tomorrow after testing owens font options patch when's branching going to happen? thats a good question I'm going to do pango r.s.n., since behdad has some outstanding cleanups he wants to do mclasen: i have a patch which might be nice for 2.8.1 I think glib/gtk should follow kris: oh, whats it about ? mclasen: i can commit it once i get my gtk+ updated mclasen: gtktreemodelsort speedup would it be unthinkable to change g_spawn* to use UTF-8 on win32 at this point in 2.8 (and do the usual #define magic in headers and add binary compatibility wrappers)? kris: can you get it in tonight ? if not, need to at least document that g_spawn* take system codepage strings on win32, not glib encoding mclasen: sure kris: does it break anything ? :-) mclasen: nope kris: I'll wait for it then i'll update gtk+ on my devel box right now takes a while tml: if it is a win32 only change, I think it's basically your call mclasen: ok. somehow i didn't remember the g_spawn* API when did the glib encoding = utf-8 on win32 changes .. tml: While wegenerally try to avoid it, anything that we can do 2.6 to 2.8 we *can* do 2.8 to 2.8.1 - there isn't a black-and-white line there tml: unfortunately, I already did a glib 2.8.1 release last night, so it would go only into 2.8.2, or you'd have to do a patched 2.8.1 for win32 mclasen: no big deal imho. i assume 2.8.2 is not *that* far away? tml: a couple of weeks fine tml: I was planning on doing the next 2.8.x releases in time for gnome 2.12.1, unless something urgent comes up * mclasen curses his gtk build picking up -lpixman from somewhere... kris: don't know if you noticed yet, but jrb and I put your name next to the treeview things on the Project Ridley page mclasen: jrb told me kris: I hope that aligns with your own 2.10 plans... mclasen: yeah mclasen: especially dnd :) mclasen: i'll probably add some more items there kris: I think we should create a separate 2.10 schedule kris: and keep the Project Ridley pages strictly for the 'platform consolidation' tasks yeah, we should make it clear that Ridley isn't is for GTK+-2.0 er, 3.0 ok or 2.10, even i am going to copy most treeview items to 2.10 anyway (: so, what period of time should we target for the 2.10 schedule ? 6, 9, 12 months ? are we going for a 2.10 or 3.0? or don't we know that yet ? mclasen: I'd be happy with 6 so long as we're able to get things in mclasen: say 2.10 in 6 months, 3.0 in 12 I think we are going for an ABI and API compatible release, that could be named 2.10 i would say 9 then well, 9 months would put it more comfortably in the middle between GNOME releases? jrb: I just fear that we're going to get in a crunch with the next gnome release then (like we did this cycle) also and, I think that 6 months is just too short for gtk+ could 2.10 be skipped? jdhadlin: I don't want to see us do a 2 year cycle or anything like that jdahlin: you mean do 2.12 in 12 months ? mclasen: or 3.0 jdahlin: I think releasing on a reaosnably compact schedule is very beneficial owen: agreed, but if more time is needed.. especially since what we are talking about for ridley is lots of medium size things rather than any huge things some are large, like printing and canvas jdahlin: do you need more time? mclasen: But doesn't that just argue for developing them over a 2 release cycle, say? jrb: for my tasks I doubt it i think 12 months is really the maximum cycle length * mclasen knew it. libtool is to blame again. -lpixman survived in .la files... looking back, 2.8 took us 8 months from the release of 2.6 jrb: well, depends. libglade in gtk+ can be a very big tasks. I think some restrains are needed and maybe 6 months of real development time, since we had about a month of slack time over christmas, and a slow period at the end mclasen: yeah. oh why don't the gnome libs use something like sanitize-la.sh? jrb: for gazpacho I'm still tweaking the loader every once and then (but the interfaces seems stable) etc doh xchat crash in the other cube... so if we would target 9 months, would that make you feel comfortable about getting printing done, owen ? etc jdahlin: yeah mclasen: Hmm. It really depends on how much time I'll have on GTK+ which isn't very predictable mclasen: My guess is that it's ~3 months of full-time work mclasen: But since the APIs should (IMO) be simple, I think it's the sort of thing where a half-job could be a good start and wouldn't present problems mclasen: So I'd be OK with 9 for that ok Have we looked at how that lines up wiht the gnome release schedule? let me just check so I get things straight: are 2.10, 3.0 and project ridley 3 separate releases? I guess, without looking, 9 months from today should put us 2.5 months into the 2.16 release cycle jdahlin: Project ridley isn't a release, it's a project owen: is anything known about gnome releases beyond 2.12 ? mclasen: Well, we've done 6 months cycles constitently for a good long time now. So, there's a reasonable *guess* that will continue owen: I guess the message of a 9month target would be: we knowingly skip 2.14, but we leave enough room to feel comfortable about meeting 2.16 jdahlin: I think the idea is that 2.10 is a milestone on the road to ridley and 3.0 is completion owen: so parts of it can go into $next and others in $next+1 ? ah, I see (For whatever "completion" is) jdahlin: yes, and possibly $next+2 jdahlin: ridley is done not when we release GTK+, but when we don't require libgnome ->libgnomeui jrb: aren't they tied together? So, looking at the project ridley list, it seems we currently put printing and most of the small libegg things on the 2.10 schedule with some confidence jdahlin: sure. And people are confused enough that maybe we should just call 'get GTK-3.0 out' project ridley jrb: most people are going to think that 2.0->3.0 = API/ABI brekage jdahlin: that's what education is for one way to make the marketing aspect of a major version increase more obvious would be to follow the java example and go 2.10 -> 12.0 whoa mclasen: Except that doesn't really solve the "huge verison numbers" problem but I guess we are to conservative for that GTK+-30 roman numbers! or maybe GTK 35+, considering most of the core developers are OLD oooh GTK X GTK+-XXX we could even have a gtk.xxx domain then ;-) 35??? users don't really like big version changes (2.x -> 3.x) without visible changes zdzichuBG: we'll have a good story, though zdzichuBG: as we'll deprecate a stack of libraries along with it else we can just choose another default theme anyway, it sounds like we don't have much of a plan maybe we should just go a couple weeks before finalizing the schedule jrb: right, but it's rather developer-, not user-visible zdzichuBG: we're a toolkit; not an app indeed. zdzichuBG: or, we could do what kris says. jrb: I'll put up an initial proposal, so we have some basis for further discussion next week jrb: Lack of a plan isn't a reason for waiting, it's a reason for making a plan :-) mclasen: sounds good ja, mach nur einen Plan heh jrb: so how do we go about finding people interested in looking at the libgnome/libgnomeui tasks ? mclasen: sameway we do other such things; publicize them and hope someone bites, or wait for someone to show up mclasen: patch has been committed. mclasen: can I propose a few more widgets for ridley ? kris: thanks jody: if you don't propose libxml... jody: only if they currently exist in a library jody: otherwise, they should just be proposed for GTK+-2.10 jrb: I'm thinking of a few of the things in goffice what about finishing introspection? i am hacking on a column view widget jdahlin: It's not "ridley" but it's definitely on the tentative 2.10 list jdahlin: yes, I am going to get back to that jdahlin: there are actually patches coming out of the language-bindings world for it mclasen: gustavos repository changes? s/changes/improvements/ jdahlin: and some other patches as well * kaffee is currently working on the Perl side of things. and it looks like gobject-introspection is alreay reasonably complete, from POV. still need to generate the metadata files... jrb: header scanning... one tricky bit might be to get the offsets and sizes of struct fields correct. [sorry that I make noise in meeting time, but I think a GTK 3.0 release makes sense to keep up with the hype with Qt 4.0] behdad: By the time that 3.0 is out ,they'll be on 5.0, most likely haha behdad: But yes, incrementing the major version does keep it obvious that we are making progress I think it's easier to emphasize backwards compatibility when marketing than to emphasize that you've added billions of new features in 2.random_number. kaffee: the plan for the offsets was to have a little tool generate them at build time, and then merge the results with a master api description mclasen: yeah, I think that would work with some offsetof() and sizeof() magic. I almost think that we should make 2.10 3.0 on the excuse of "2.8 + 0.2 == 3.0" should we also make it a goal that 3.x only has 5 minor releases before 4.0? * jrb would vote for that iff we can kill libgnome/ui and we take 9 months owen: don't start the decimal version number game; all the prominent enough numbers are already taken by metacity, tex, etc 2.A i think we should first come up with a list of features, which are reasonable to get in one release and then come up with a schedule mclasen: But there are so many irrationals out there.... owen: but so few of them have catchy names... owen: I thought dramage's shirt had a comprehensive list of them all owen: any thoughts on #314114? kris: you are right, of course. This whole version number discussion is probably not relevant to the next GTK+ version anyway since completion of ridley in 9 months is pretty unlikely tml: Well,t he current values are clearly way wrong, as you see any time you bring up a color selector so, the list of features which I think I'll put on the draft schedule is: introspection, printing, all the libegg things from the ridley list, kris' other treeview stuff for the remaining things, we'll have to see how they proceed tml: I havne't looked at how you would want to fix it owen: pity there is no ave_x_advance in cairo_font_extents_t ok, anyway, I need to get on the bike see you next week mclasen: when you say 'printing' are you putting a dialog in gtk, and a print-job into glib ? or is everything into gtk, or part into cairo ? jody: I think print-job goes into gtk or gdk owen: regarding OpenGL (#119189), after the model taken for cairo integration, do you still think that /idiosynchratic scheme/ of attaching OpenGL context to arbitrary widgets is not the way to go? jody: the actual pdf/ps/gdi generation code is in cairo owen: I disagree. the job settings are not gui related behdad: Yes. I think you just have a function to get the GL visual jody: that may be the case, but things have to go somewhere and I dont' want glib depending on libgnomecups or whatever does printing including getting the text widget to print its buffer? owen: that's a given. we wouldn't want gtk depending on cups either. the transports need to be in modules. as with gdk-pixbuf jody: In the end, i don't think the goal is create a be-all-and-end-all printing solution, but rather to create something that meets the needs of normal applications jody: So, in my vague plans, things like querying current jobs are out of scope as well owen: we don't need all singing all dancing, but 'normal' is subject to debate jpe: Maybe. Printing widgets is unlikely, but a GtkTextView "paginate and print" might be general enough to be useful jody: but of course. :-) as always owen: people expect their print dialogs to have connections out into the system, eg add printer, or list jobs jody: I don't think everyhting that is in the print dialog should be in the API jody: that is, I dont' want to design a clean two layer system: "Non-gui API for talking to printers" "Print dialog built on non-gui API" Because I think that will pose portability problems, and also cause us to expose a really complex API to applications (trees of options, anyone?) owen: applications need a way to persist the print settings jody: we can have stringify or something like that. owen, printing simple text is going to be something many applications will want Going to be? I think it's something apps already want. jpe: An interesting part of the design phase here is collecting requirements. There are very few apps on Linux that do "simple" printing owen: there is more to debate here, but I've got to go feed the youngins jpe: Most things that print are pretty complex - whether it's the GIMP, FireFox, OOo. So, getting a sense of the typical app may take some work jody: It won't be set in stone tomorrow :-) owen, I guess I think of the custom database app as more typical because every business ends up writing one jpe: Yes, that' sdefinitely more typical (GTK+ does a fairly bad job of catering to that crowd ... no entry validation features, etc) jpe: But would you want to print a GtkTextView in that sort of app? gedit? jpe: Perhaps what you want there is gtk_text_buffer_draw (buffer, cr, x, y, width) and assume it's not going to overflow the page jdahlin: gedit isn't an inspiration for adding API that they could just do themselves owen, eventually these apps want complex reports, but the ability to print free form text is a start owen, I would say the ability to print word-wrapped text that looks close to what it looks like on the screen is the minimum requirement owen, you might glance at the win32 rich edit control -- lookup EM_FORMATRANGE in msdn owen, not that gtk+ can't do better than it, but it is something that kind of works Meeting ended 17:23 EDT