Meeting on irc.gnome.org:#gtk-devel Meeting started June 7 17:02 EST (21:02 UTC) In attendance: Matthias Clasen (mclasen), Owen Taylor (owen), Jonathan Blandford (jrb), Federico Mena Quintero (federico), Soeren Sandmann (ssp), Robert Ögren (roboros), John Ehresmann (jpe), are we missing anybody ? mclasen: Looks reasonable. ok: maybe we can just start then... ...by announcing that we'll do a gtk+ 2.4.3 sometime this week to fix the button size fiasco a bit more. so if you have 2.4.x fixes lying around and missed 2.4.2, you can try to get them in 2.4.3 I wonder if we should do something about the button size change in the combobox, which was caused by the default arrow size change in 2.4.2 One option would be to just declare that "it looks better this way anyway"... mclasen: What could we do? Isn't it the case that either the button will get larger or the arrow smaller since we had an arrow/focus-rect overlap? yes. since the button in the combobox is focusable. mclasen: Then I think we basically just have to leave the button bigger... yea does somebody else want to volunteer for doing the release this time ? well, then I will probably do it around Friday. do we have other issues to discuss ? jrb, did we decide something wrt to the treeview drag/modality issue ? mclasen: yes mclasen: not being able to drag when modal is much worse than whatever that bug was is that a fix for 2.4.x ? mclasen: federico was going to revert that change and put in a comment. We'll find a real fix if the initial problem reoccurs mclasen: I think so, yes good ok, what else ? owen, can you tell us a bit about the current state of pango ? Jun 07 17:20:41 * mclasen didn't really track pango development in the last months...apart from seeing demos of strange glyph printouts occasionally... mclasen: I've added support for rotated text and a few other features, my plan is to cut off development at the gnome-2.8 API freeze and push out a 1.6 release mclasen: So for now to decouple it from the GTK+ release schedule since I really want the gnome-print/Pango integration in gnome-2.8 would we need anything in gtk+ to support using rotated text, or could one just drop in pango 1.6 and have labels with vertical text work in gtk 2.4 ? s/vertical/rotated mclasen: It would at least require something like gtk_label_set_angle() or gtk_label_set_matrix() mclasen: But that's a few lines of code. Actually the main work item to get that working is getting rotatated drawing with Xft ... currently what I have in Pango is just FT2 (the Xft rendering mostly lives in GTK+, not Pango) mclasen: But yes,I think we should be able pretty trivially get rotated labels for GTK+-2.6 not that I think rotated labels are overly useful, but they may certainly give some "aah" effect mclasen: They are pretty frequently requested, though I think people want more the ability to draw rotated text with GDK owen: regarding the gnome-print integration, do we have some (however vague) plans to move a print dialog to gtk, with some kind of backend separation like the new file selector ? mclasen: Yes. :-) mclasen: (that was in the guadec paper I sent you the link to, actually) mclasen: That's a post-Cairo item, however Good. I should read that, probably :-) maybe this should be on the list rather than the meeting, but we need a boolean-returning version of gtktreeview::row-activated but I can't think of a good name other than row-activated2 activate-row ? mclasen: duh, good idea If we really think the confusion is worth the gain, the name should be somewhat explicit, like row-activated-check federico: Though I guess activate-row could emit row-activated out of the default handler. owen: it's what makes the tree view appear to swallow enters But I have a somewhat hard time seeing how this is going to make the world a better place. it's one less bug! didn't we hack around that in certain places ? federico: We have the same problem as why we couldn't make ::activate a boolean return and get rid of gtk_entry_set_activates_default() mclasen: yeah, but I don't want those hacks to proliferate federico:well, different. But related. We can't tell if anybody is connecting to row-activated, so we can't pass through the return if there is no action done would it be ok to 1) make gtk_tree_view_row_activated() return boolean instead of void; 2) have it emit both signals, and return the result of the new signal? You can't compatibly change the return type of a signal Oh,you mean the function No, that doesn't work, because row-activated logically always returns TRUE owen: I mean, have the function emit both signals; the old one for compatibility, the new one for the return value owen: I'd then change gtkfilechooser and gtkfontsel to use the new signal I don't follow what the change would be, say, for the fontsel. well, the fontsel uses the same hack as the fileselector to active the default when row_activated is emitted... mclasen: But the only thing that would avoid that is if GtkTreeView didn't trap enter, and making GtkTreeView not trap enter unless ther is a activate-row callback that returns true will cause current apps to break yeah, one should not have to special-case Enter for a widget an alternative would be gtk_tree_view_set_activates_default() mclasen: We'd have to have a mode setting for GtkTreeView thats what I was trying to propose: GtkTreeView::activates_default as a boolean property owen: what would break in current apps? I'd say that for most of them it is perceived as a bug that you can't accept dialog boxes with Enter if a tree view is focused federico: Any app that has a dialog box and connects to ::row-activated federico: Which I think is relatively common. Hitting return is supposed to bring up the "edit profile" dialog, and instead closes the dialog what's the function to see if there are connections to a signal? I have to leave, see you next week... Has "pending" inthe name, but things like gtkmm are going to break that since you can't tell if the default handler does anything or not hmmmm so, an activates_default thing instead? It seems best to me OK, mclasen is gone, it's been an hour, probably should adjourn. Anything else? owen: the g_filename_to_uri() thing can that fix go in? federico: Did you ever do the analysis of what (if anything) in gnome saves encoded uris to disk? owen: I did a grep on the core desktop and nothing uses it other than for a temporary value federico: Let's go ahead and make the change in stable and HEAD. Needs to be prominently noted in the release announcement for the next GLib version. federico: I'm not happy with the compatibility level, but I don't see an alternative. owen: cool, I'll make the change federico: Add something to the release notes section of the README owen: ok, will do Meeting ended June 07 18:02 EST (22:02 UTC)