Meeting on irc.gnome.org:#gtk-devel Meeting started November 29 2005 16:00 EDT In attendence: Matthias Clasen (matthias) Behdad Esfahbod (behdad) Maciej Katafiasz (mathrick) Mart Raudsepp (leio) Mikael Hallendal (Hallski) Anders Carlsson (andersca) Jonathan Blandford (jrb) Tim Janik (rambokid) Emanuele Bassis (ebassi) Nov 29 14:59:37 mclasen: what's the agenda for the meeting? I probably have to leave just before. Nov 29 15:00:34 behdad: I don't have any specific items Nov 29 15:01:14 behdad: we could quickly talk about the shortened schedule for glib and pango, ie when to declare api freeze and get serious Nov 29 15:01:42 right. I'll read the minutes then. Nov 29 15:01:46 behdad: we could also talk about wether we need to do another quick stable gtk release, to pick up federicos filechooser fixes Nov 29 15:01:52 yeah Nov 29 15:02:04 and if andersca shows up, macosx could be discussed Nov 29 15:02:38 yeah yeah, Pango's ATSUI stuff needs some work Nov 29 15:02:52 there's a bug open about examples/ not compiling, and also the docs Nov 29 15:04:13 ok, 2.13.3 tarballs are due on dec 12. I'm leaving Toronto for a trip back home on 13th. Nov 29 15:04:48 how is pango looking from your perspective ? anything missing apart from fixing up macosx ? Nov 29 15:04:59 I don't think we can get any big items in Nov 29 15:05:05 well, yes Nov 29 15:05:15 the OpenType stuff in basic module needs fixage Nov 29 15:05:23 is the meeting already on? Nov 29 15:05:26 but that's blocking on me communicating with Owen Nov 29 15:05:26 oh, whats broken there ? Nov 29 15:05:41 mathrick: I can't make it, so just chatting :) Nov 29 15:05:45 mathrick: no, this is the meeting where we discuss the agenda for the meeting Nov 29 15:05:49 behdad: ah, ok Nov 29 15:05:54 mclasen: right now we hit the OpenType code no matter what. we want to shortcircuit Nov 29 15:05:55 mclasen: aha Nov 29 15:06:16 mclasen: the problem is that, in all fc shapers that have opentype support Nov 29 15:06:39 we have a line like if (!ruleset) { fallback_shape(.); return; } opentype shaping here Nov 29 15:06:51 I used to think that's handling the case for non-OpenType fonts Nov 29 15:07:15 but figured out that it actually is not. if you dig into the code, the if (!ruleset) never happens. Nov 29 15:07:26 so basically the fallback code is just dead code currently. Nov 29 15:07:33 and now we have made basic module like this too. Nov 29 15:07:58 if the font doesn't have opentype stuff, the opentype code creates a dummy/empty ruleset Nov 29 15:08:05 oh, so we need to figure out how to fall back to fallback_shape Nov 29 15:08:09 my guess is that: Nov 29 15:08:12 yeah Nov 29 15:08:22 so if (ruleset_is_empty (ruleset) {...} Nov 29 15:08:49 I guess there's no way to distinguish between decent opentype fonts, and simple truetype, other than checking for whether the mark, mkmk, kern, etc (all needed) tables are present Nov 29 15:08:56 kinda, yeah. Nov 29 15:09:04 but then comes the next point Nov 29 15:09:22 if for example the font has an opentype kern table, but no mkmk table, Nov 29 15:09:42 we can do better by using the opentype code (for kern) AND doing fallback mark-to-mark positioning. Nov 29 15:09:54 mark mark Nov 29 15:09:59 we don't have fallback mark-to-mark positioning yet, but that's easy to implement. Nov 29 15:10:02 yeah, Nov 29 15:10:06 * mclasen loves those cryptic 4 letter acronyms Nov 29 15:10:31 mclasen: nod Nov 29 15:10:45 in the same way, the arabic shaper can be changed to do callback if init, medi, fina, isol tables are not present Nov 29 15:11:03 again, we don't have fallback arabic shaping code anymore. have to introduce it again. Nov 29 15:11:18 is the current situation just a performance regression, or do we get wrong shaping without the fallback ? Nov 29 15:11:19 but the point I'm trying to make is that instead of if (something) fallback ; else opentype; Nov 29 15:11:37 we have to do if (!this opentype table present) fallback for this opentype feature. Nov 29 15:11:59 mclasen: mostly performance. Nov 29 15:12:08 remains a tiny issue, Nov 29 15:12:26 which is whether bare truetype hinging should be done even if kern table is present Nov 29 15:12:39 that's just a matter of me reading through opentype list archives and decide Nov 29 15:12:47 that I'll do soon. Nov 29 15:12:57 does truetype hinting not use the kern table ? Nov 29 15:12:58 s/hinging/kerning/ Nov 29 15:13:23 no, there's a pre-opentype kerning stuff in truetype it seems Nov 29 15:13:29 * behdad searches Nov 29 15:13:58 mclasen: and that is handled by pango_fc_font_kern_glyphs Nov 29 15:14:02 so the question is if there are opentype fonts with quality tt kerning but a crap kern table ? Nov 29 15:14:21 not quite. Nov 29 15:14:49 currently we are broken. since fallback is not called at all, and pango_fc_font_kern_glyphs is not called, where it was being called previously Nov 29 15:14:59 so we have regression on non-opentype truetype fonts at least Nov 29 15:16:26 ok, so we do need per-table fallback at least for kerning Nov 29 15:16:41 yes, I believe so at this point. Nov 29 15:17:35 behdad: but why do you need to read opentype list for that? Nov 29 15:18:08 mathrick: it was being discussed there Nov 29 15:18:15 mclasen: update, I've been a bit off. Nov 29 15:18:27 mclasen: apparently the truetype kern stuff is in table kern. Nov 29 15:18:33 so basically we are not regressing. Nov 29 15:18:43 opentype fonts may have gpos tables for additional kerning Nov 29 15:18:58 quoting here: http://www.microsoft.com/typography/otspec/recom.htm Nov 29 15:19:04 'kern' Table Should contain a single kerning pair subtable (format 0). Windows will not support format 2 (two-dimensional array of kern values by class); nor multiple tables (only the first format 0 table found will be used) nor coverage bits 0 through 4 (i.e. assumes horizontal data, kerning values, no cross stream, and override). OpenType fonts containing CFF data do not support the 'kern' table and should therefore specify kerning data using t Nov 29 15:22:24 behdad: and what comes after that? :) Nov 29 15:23:02 still looking in the list archives. but basically this is saying that the basic module is doing correct. Nov 29 15:23:08 so it's all about performance now. Nov 29 15:23:35 behdad: so what that means is that 1) kerning for TT and 'kern' table for OT are the exact same thing or 2) OT kern table includes everything TT kern table does? Nov 29 15:24:30 mathrick: there's one kern table, which is what TT used to use, and OT uses too. but given OT's gpos capabilities, you don't have to limit yourself to the limited kern table. You can do whatever positioning you want using gpos. Nov 29 15:32:14 behdad: so, you won't be at the meeting? Nov 29 15:32:31 behdad: have you checked that m17 stuff yet, or does that take more time? Nov 29 15:33:09 mathrick: takes time. got to find some empty spot. or wait until current engagements are done :( Nov 29 15:33:23 I've got to leave in 20 minutes. Nov 29 15:33:50 behdad: pity Nov 29 15:34:10 talking of talking about glib/pango releases, what about gtk+? That will lag behind with numbers from now on? Nov 29 15:34:24 but after I finish this thing, which is writing my masters thesis finally, I'll have a lot more time to do major stuff in pango Nov 29 15:34:42 leio: wasn't the plan to call the result 3.0? Nov 29 15:34:44 or maybe not Nov 29 15:34:50 that was a separate plan Nov 29 15:34:57 3.0 is after Ridley lands Nov 29 15:35:05 but what is it about lagging? Nov 29 15:35:23 mathrick: gtk+ doesn't make a release for GNOME 2.14 Nov 29 15:35:27 (note that I haven't read -devel for past several months, so I don't know) Nov 29 15:35:30 so glib and gtk+ versions get out of synch Nov 29 15:35:34 behdad: oh Nov 29 15:35:42 that's gonna confuse people Nov 29 15:35:47 but that's were the fun starts :) Nov 29 15:36:04 what about skipping numbers when there's new GTK+? Nov 29 15:36:04 GNOME 2.14, pango 1.12, glib 2.10, gtk+ 2.8 Nov 29 15:36:09 gotta love it Nov 29 15:36:12 so that they're back in synch Nov 29 15:36:14 leio: if you compare the version numbers of glib, pango and gtk, you'll notice that they are different already... Nov 29 15:36:25 micro version, and pango, yes Nov 29 15:36:35 I believe we will need a release for GNOME-2.14 Nov 29 15:36:40 after I get around to this redraw thing Nov 29 15:36:48 it is a big problem with cairofied themes Nov 29 15:37:01 I like to look at OpenGL thing of Gtk+ Nov 29 15:37:13 I'll bring that up next week maybe, after I've managed to look again at it Nov 29 15:37:17 there will be a few more stable releases before 2.14 Nov 29 15:37:17 but probably not for 2.10 Nov 29 15:38:56 right, was imagining we could test it in 2.9.x for a while, and get it into stable 2.8 before GNOME 2.14 Nov 29 15:39:10 I haven't read the discussion, but I don't really like the idea of desyncing GTK+ and Glib Nov 29 15:39:19 it's gonna hurt in support dept Nov 29 15:40:28 how ? Nov 29 15:40:43 mclasen: the more versions you have, the more people get confused Nov 29 15:41:01 that's why GStreamer switched to synced released Nov 29 15:41:07 we used to have separate numbering Nov 29 15:41:31 sorry, slight electricity problem Nov 29 15:41:43 mclasen: IMHO, for the sake of simplicity, it's better to make empty (or just bugfixes) GTK+ release Nov 29 15:42:04 and get that pushed into thousands of poor guys on dialup? Nov 29 15:42:24 behdad: if we have bugfixes, they would get it anyway Nov 29 15:42:40 we don bugfix releases already Nov 29 15:42:42 mathrick: see your contradictory statements: "the more versions you have, the more people get confused" and "its better to make [...] a release" Nov 29 15:42:57 mclasen: distinct versions Nov 29 15:43:09 it's easy when you have glib 2.10 and gtk 2.10 Nov 29 15:43:22 well, of course we can just say that it's packagers' job to distribute gtk Nov 29 15:43:30 its also easy when you have glib 2.10 and gtk 2.8 Nov 29 15:43:46 "tried it with gtk 2.10, broken, with 2.8, broken too, with 2.6, broken" wait wait wait, they are all the same code, released to keep up the number ;) Nov 29 15:43:59 at least its not more complicated than when you have gtk 2.8 and pango 1.10 or gtk 2.8 and glibc 2.3.5, etc... Nov 29 15:44:13 mclasen: for you. But people don't track releases that closely Nov 29 15:44:45 mathrick: what's so special about gtk+ and glib? users don't really know that they are so tight Nov 29 15:45:06 mathrick: thats why we have umbrella gnome releases to keep people from figuring it out Nov 29 15:46:01 behdad: to sum up. mclasen knows what you wanted to say wrt OT and fonts and real pango stuff that matters? Then if I have time, I can talk with owen about vertical and stuff, to see if he has any special ideas about that. Nov 29 15:46:44 mathrick: yeah, OT problem comes down to me figuring out a way with owen to shortcircuit non-opentype case. Nov 29 15:46:49 behdad: ok Nov 29 15:46:57 what we need is someone benchmarking the fallback vs opentype paths Nov 29 15:47:21 behdad: I'm not gonna do any big talk just yet, I don't think I will have much time pre-Feb anyway Nov 29 15:47:34 but I'm reading for the time being Nov 29 15:48:38 again :( Would appreciate a log of what I missed priv msg'd or posted Nov 29 15:48:47 mathrick: yeah, around that time is better for me too Nov 29 15:49:28 leio: logs will appear on www.gtk.org in due course Nov 29 15:49:34 I'll include pre-meeting chatter Nov 29 15:49:42 ok Nov 29 15:49:53 thanks mathrick (I might want to reply on something immediately) Nov 29 15:50:23 leio: np. If you had 200s timeout, you might have missed some earlier stuff, tho Nov 29 15:50:29 probably Nov 29 16:01:25 ok, time to start, I guess Nov 29 16:02:13 * mathrick looks around for owen Nov 29 16:05:24 he won't be here Nov 29 16:06:03 oh Nov 29 16:08:33 Hallski, so now that the osx code is in cvs, do you have any kind of roadmap or similar ? I mean, there is certainly work left to do, right ? Nov 29 16:14:35 mclasen: yeah there is work left to do Nov 29 16:14:41 mclasen: I'll try to get anders here Nov 29 16:15:24 Hallski, might be cool to just post a state-of-the-os-x port mail to gtk-devel, so that people learn where we stand, and where they can chime in Nov 29 16:15:34 mclasen: there is a http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do Nov 29 16:15:50 mclasen: which outlines what is left to do Nov 29 16:15:55 mclasen: but doesn't have any dates Nov 29 16:16:49 I thought we should discuss the glib and pango schedules today Nov 29 16:17:22 looking at the gnome 2.14 schedule, it has api freeze mid-January Nov 29 16:19:04 jrb: I'll have a minor pokage for you later, when mclasen's done discussing important stuff Nov 29 16:19:10 okay Nov 29 16:19:44 so I thought we should strive for api-frozen pango and glib releases before christmas Nov 29 16:19:58 does that sound doable ? Nov 29 16:21:07 mclasen: i'd hope so. Nov 29 16:21:35 I'll look over the small api additions on the glib 2.10 milestone next week Nov 29 16:21:45 or maybe 2. january if people want to hack on glib over the holidays. Nov 29 16:22:27 maybe, but people should have better things to do over the holidays... Nov 29 16:24:49 andersca: will you add docs for the os x api additions at some point ? Thats mostly pango, I guess Nov 29 16:26:15 from what behdad said earlier, the main thing that needs to be sorted out in pango before 1.12 is better handling of non-opentype fallback, now that the basic shaper uses opentype Nov 29 16:27:31 mclasen: I've received you mail Nov 29 16:27:50 mclasen: by the way, the parser object lives in libegg/bookmarkfile Nov 29 16:27:56 mclasen: ah, yeah Nov 29 16:28:05 ebassi: ah ok, I'll check that out later Nov 29 16:28:11 mclasen: oh wait...there are no api additions Nov 29 16:28:18 mclasen: and mostly addresses your concerns on it ;-) Nov 29 16:28:38 mclasen: because it's only a pangocairo backend... Nov 29 16:29:22 andersca: I think the backend api is documented as well in pango, but I'll have a closer look, maybe there is no need for api docs Nov 29 16:29:58 mclasen: you mean the functions that the shapers use? (I think that's one currently) Nov 29 16:33:37 andersca: PangoCairoFontMap is documented, so I wonder if PangoATSUIFontMap should be, too Nov 29 16:33:57 mclasen: I guess it wouldn't hurt Nov 29 16:34:13 mclasen: although PangoATSUIFontMap is an abstract class... Nov 29 16:35:47 andersca: anyway, it may be good to have a section "OS X Rendering" next to the other backend-specific sections in the pango docs Nov 29 16:36:24 mclasen: well, there's no real "OSX rendering" APIs, since it just uses the cairo osx backend Nov 29 16:36:36 and also a section about OS X specifics in the GTK api docs (if there are any specifics) Nov 29 16:36:51 not yet... Nov 29 16:37:15 but I think collecting that kind of information in your wiki, and converting it to docbook once things are sufficently stable is fine Nov 29 16:43:36 rambokid, some time ago I wrote a patch to add G_TYPE_GTYPE. Should I send that your way for review ? Nov 29 16:44:06 mclasen: yeah, nagging me about patch review in my inbox is always the best way to get a response ;) Nov 29 16:44:25 * mclasen goes looking for that patch Nov 29 16:48:33 mathrick: you had something about treeview ? Nov 29 16:48:48 ah, yeah Nov 29 16:49:26 jrb: http://bugzilla.gnome.org/show_bug.cgi?id=322286 Nov 29 16:49:52 kris said it's not done to avoid overloading functions of double click Nov 29 16:50:09 but IMHO, the more important thing here is supporting user's model Nov 29 16:50:19 and there, double click should clearly expand :) Nov 29 16:53:35 separate thing is providing the default implementation, as current row-activated has void prototype. But I have semi-sensible idea on that I think. Nov 29 16:53:44 I think jrb is busy with something else Nov 29 16:54:36 no problem, I'm not going anywhere Nov 29 16:54:47 mclasen: you can speak up too :) Nov 29 16:55:02 I guess the difficult question is if this can be implemented compatibly Nov 29 16:55:36 Other than that, I think the idea to expand on double-click has merit Nov 29 16:55:56 mclasen: I have something which gives not so much impact without change, but which can be enabled trivially Nov 29 16:56:39 mclasen: basically, the idea is to expand if the tree has no row-changed handler, and provide "expand-default" property which would also enable that for when there's handler Nov 29 16:56:49 err Nov 29 16:56:52 row-activated Nov 29 16:57:50 I don't think there's any way to just drop that in for when there's a handler Nov 29 16:57:58 as that would break nautilus immediately Nov 29 16:59:07 mclasen: you've got mail :-) Nov 29 17:02:29 ebassi: I'll respond after studying libegg/bookmarkfile Nov 29 17:02:53 mclasen: okay Nov 29 17:05:15 mathrick: I guess I would have to see a patch Nov 29 17:05:41 ok, if nothing else to discuss, I propose we consider the meeting closed Nov 29 17:05:50 mclasen: yeah, I was holding back waiting for someone to greenlight me at least a bit Nov 29 17:06:10 mclasen: hmm, one thing Nov 29 17:06:38 mclasen: nothing like vertical text support was ever considered for GTK+ API, right? Nov 29 17:07:23 I'm trying to imagine what would be needed to do that sanely inside GTK+ Nov 29 17:07:23 I don't know how much consideration went into that during 1.2 -> 2.0 when pango was born Nov 29 17:07:43 mclasen: dummy dir enums are there Nov 29 17:07:48 but GtkTextDirection has only rtl and ltr Nov 29 17:07:57 hmm? Nov 29 17:08:15 mclasen: I think TTB and BTT should be there too Nov 29 17:08:36 typedef enum Nov 29 17:08:36 { Nov 29 17:08:36 GTK_TEXT_DIR_NONE, Nov 29 17:08:36 GTK_TEXT_DIR_LTR, Nov 29 17:08:36 GTK_TEXT_DIR_RTL Nov 29 17:08:36 } GtkTextDirection; Nov 29 17:10:08 ah Nov 29 17:10:23 mclasen: looking at pango, TTB values are deprecated Nov 29 17:10:44 mclasen: unicode's tr9 specifies algorithm in terms of normal BiDi Nov 29 17:10:59 with small additional hints for block flow Nov 29 17:11:11 that's why they're not needed for layout Nov 29 17:11:24 but for display itself, I think it would be still needed Nov 29 17:13:17 mclasen: do you have any idea as to how much stuff would break if we added TTB and BTT for widgets' default directions? Nov 29 17:13:54 ie, how much logic inside GTK+ is tightly dependent on the direction Nov 29 17:15:58 I guess quite a bit all over the place Nov 29 17:16:06 all the automatic flipping code Nov 29 17:17:02 mclasen: ah, but that's the thing we can fix Nov 29 17:18:01 mclasen: I was more concerned about the stuff which doesn't directly have to do with direction API, ie. the stuff which won't get fixed by default, and especially anything which could end up in 3rd party code Nov 29 17:18:30 mclasen: do widgets need to provide their own flipping? Nov 29 17:19:02 mathrick: if they are simple composites using standard containers, then not Nov 29 17:19:19 mathrick: but if they are doing custom drawing or manual positioning of children, then yes Nov 29 17:19:28 oops Nov 29 17:20:10 mclasen: well, that's gonna hurt, because while you can figure out the layout from the text alone, you don't really know that for widgets Nov 29 17:20:28 anyway, we need to have pango support that first Nov 29 17:22:15 mathrick: I'm not sure widgets need to do anything special for vertical direction (i mean nothing like rtl flipping) Nov 29 17:23:08 mclasen: depends on how far you want to go with vertical stuff Nov 29 17:23:40 mclasen: that is, should menu/toolbars be vertical in vertical locale? Meeting ended 17:23 EST