Meeting on irc.gnome.org:#gtk-devel Meeting started July 12 2004 17:02 EST (21:02 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (mclasen), Owen Taylor (owen), Kristian Rietveld (kris), Soeren Sandmann (ssp), Ray Strode (halfline), Federico Mena Quintero (federico), James M. Cape (Jimbob), John Ehresmann (jpe) * federico returns from lunch its lunchtime in mexico ? mexicans are just weird. (: mclasen: generally 15:00 onwards mclasen: the team meeting is a good excuse not to go take a nap after lunch :) so, it seems we are ready to start I didn't post an agenda, since I didn't know any items to put there... I have committed the about dialog to HEAD now, since it didn't look like I would get more feedback on the list...give it a try if you want. (gtk-demo uses it now in the appwindow example, unless I forgot to commit that) mclasen: The one thing I iddnt' understand was what happened for no translation for the translator-credits Don't you get 'translator-credits' appearing in the dialog pgae? Looks like you would. Yay, first about dialog bug... I have an agenda item: 2.5.0 The one thing I wanted to point out regarding the widgets which are "coming home" from libgnomeui in 2.6 is that we should try to add sections to the "migration" chapter which federico started for the file chooser... mclasen: oooh, yes I can do a 2.5.0 release next weekend if people think it's a good idea mclasen: We probably need to have some special way of identifying the untranslated string I need to talk to the Beagle people about the sort of API they need to plug in searching for the file chooser owen: can't we do the same thing Q_() does (or tries to do) ? ssp: depends a bit on whether we want to try for 2.5.0 to be "almost" api complete - if we want that, we should probably wait a bit longer to get the filepicker, cmdline options and maybe some of the file chooser additions in before... mclasen: No, because we don't callgettext, the caller does owen: urg, true mclasen: I thought we decided a few weeks ago that we weren't going to wait for 2.5.0 I don't really see the point of waiting. Getting releases out will increase the amount of testing it gets yeah i wouldn't wait. owen: ok, so lets do it. Having a volunteer is even nicer... I have another doc-related question: I have added the icon view and the about dialog to the api docs just to put them somewhere. icon view ended up in the "Tree view" chapter, about dialog in the "display widgets" chapter - I would be happy for better proposals where to put them AboutDialog -> Windows, IconView -> Display Widgets (that's where I looked for it first) instinctively, the about dialog fits much better with the other complex dialogs, but the chapter in which they are grouped is named "Selectors", and thus doesn't really fit for the about dialog... I always have a lot of trouble with the current chapter organization. I can't find anything. I doubt our users are doing better... (GtkBin being in Abstract Base Classes rather than Layout Containers was always problematical) mclasen: you did forget to commit the 'about box' changes to gtk demo ... As a user, I agree with owen. ssp: will do later, thanks yeah, the about box belongs in Windows is it a Toplevel? yes so, as a small step in the right direction, I will move the about dialog to the "Windows" section thanks I have been asked about my plans for 2.4.5 earlier today, so I wanted to repeat that here: My current idea is to do 2.4.5 in 5-6 weeks, unless urgent bugs come up. mclasen: I'd probably rename Tree and List Widget to Trees, Lists, and Icons though that horrid, since GtkImage isn't there should we gather all the API bugs for 2.6 and try to sort them out soon? Well, *gathering* isn't much of a problem, unless you find 120 API bugs insufficient... Pruning that down probably is a really good idea owen: more like 160... (including glib) mclasen: OK,thatwas just a rough count for GTK+ only owen: and than you have your private supply of Pango bugs on top of that... s/than/then/ mclasen: Yeah, though that's only 7 on 1.6 API freeze... (Which is this week...) federico: I think it makes sense to view them all, to make sure we don't let too obvious/important things slip through the cracks... owen: Is elipsizing in PangoLayout on that list? heh :-) Jimbob: I write up 100 lines of notes this weekend on why it was hard... but I might still get to it thats the next filechooser: everybody wants it, and it will take us long to get it done... Jimbob: If I feel incredibly inspired tonight or tomorrow night owen: ...then you will implement ellipsizing ?! Jimbob: But it's more of a 1.8 API freeze feature for practical use, since you need GtkLabel additions as well mclasen: the file chooser was pretty paralellizable, though. I'm not sure the ellipsization code is owen: Yeah (sigh) mclasen: If I get over my distaste for it being totally broken for Arabic owen: can it be implemented in a way which allows fixing Arabic later ? (can arabic be ellipsized?) He said I SAW THE CAT => He said TAC THE WAS I => He said ... THE WAS I that's the generic Biidi ellipsization problem But arabic is worse since breaking inside a word either is going to cause reshaping which would be incorrect, or not cause reshaping, which would be incorrect owen: you loose track of direction changes in the ellipsized part ? Not really, lose direction, it's just that using a single ellipses doesn't work well Say, the phrase was He said I SAW THE CAT loudly Do you ellipsize that to He said THE WAS I ... or He said ... THE WAS I Either is weird owen: bidirectional text is weird anyway... mclasen: No doubt can you give preference to the primary language? so if caps is the secondary language, you would have "He said ... loudly" federico: You can do fairly well at picking the right one when there is a right one, but the previous example there wasn't clearly a right one owen: but for 95% of the use cases, ellipsization of bidirectional text is clearly irrelevant, isn't it ? mclasen: Yeah, basically I can just implement something that is half OK, and probably nobody will ever complain Though Arabic is a bit worse owen: would it be possible to embed ellipsization hints via markup, to help in complex cases like Arabic ? What is weird about "He said ... EHT WAS I" is weird. ? [except the weird sentence I managed to write] owen: similar to \discrectionary{}{} hyphens in TeX ? ssp: Well, that's ellipsized at the end, but the ellipsis ends up in the middle ssp: Or if you do it "He said EHT WAS I ..." then the ellipses is no twhere the text is truncated owen: well, logically the ellipsis is not in the middle ssp: Consider the longer text I had above "He said I SAW THE CAT loudly" ssp: I think part of the problem is that the ellipsis dots give no hint whether they are LTR or RTL dots... If we ellipsiuze that before "CAT" then we have more a ambiguous situation owen: maybe you need different dot for LTR and RTL ellipses ? ssp: Doesn't an ellipsis denote text as being omitted? The text isn't omitted on the right, but on the left. mclasen: Well, I'm not sure I want to start *new* typographic traditions errorlevel: I think that's what ssp was arguing owen: I thought he meant the exact opposite when he said "logically the ellipsis is not in the middle", where I think it should be in the middle since that is where the missing text is supposed to be. owen: what are the typographic traditions for displaying ellipsisized bidirectional text ? owen: Yeah, my opinion is that doing ellipsization logically works well, especially considering that it's such a rare case mclasen: There's actually no typographic tradition at all for ellipsizing at other than where the author typed ... errorlevel: Yeah it was ambiguous - I agree with you owen: so we can just make something up...or look at other systems. Does e.g. icu handle that ? If you were typing stuff on a bidi typewriter, wouldn't the ellipsis end up in the middle? mclasen: I don't know any existing practice at all ssp: There's no such thing as a bidi typewriter... * owen has visions of a rack full of gears to implement the unicode bidi algorithm.. owen: I wouldn't actually be too surprised if bidi typewriters with a manual switch between RTL/LTR have existed ssp: but they probably wouldn't have allowed you to switch text direction mid-paragraph, even if they existed... outlook has a fancy "ellipsizing" thing for icons in list widget headers they do a gradient on the alpha channel so that the icon is opaque on the non-cut side, and transparent on the cut side http://www.mytypewriter.com/item.html?PRID=1414052 * jrb wonders if this meeting just switched directions BIDI MEETING. * mclasen has to go now, I'll leave you to your dreams of bidirectional machines... OK, I think we can call the meeting adjourned I'll be at the desktopcon at OLS next monday, but I think that doesn't affect most people here (other than vektor) so we shouldn't move the meeting Meeting ended July 12 18:04 EST (22:04 UTC)