[11:53] <cjwatson_> blackskad: you're welcome to work on trying to make ubiquity fit in 640x480; I tried a while back and gave up
[11:54] <blackskad> cjwatson: I've already found some fields that requested a width of 600 (even 650)
[11:54] <blackskad> and the map scales automatically
[11:54] <blackskad> so it just has te be assigned a smaller size
[11:55] <blackskad> it seems the stepUser is to high
[11:55] <cjwatson_> well, preferably not assigned a size at all if that's possible
[11:55] <cjwatson> it can make good use of larger screens and should be allowed to grow
[11:56] <blackskad> gtk doesn't really obey those requests, if the user makes the window larger, the map grows with it
[11:57] <cjwatson> so my point is that if the screen is large then ubiquity should start out fairly large, because otherwise the timezone map will feel cramped
[11:57] <cjwatson> if the screen is small then obviously it should try to cope
[11:58] <cjwatson> but not at the expense of a fiddly little UI that's really hard to use on big screens
[11:58] <cjwatson> I'm sure there is some way to do both
[11:58] <blackskad> oh, now I get it
[11:59] <blackskad> yeah, I think there is
[12:00] <blackskad> a way to do so
[03:48] <mpt> I dislike the zooming of the map
[03:49] <mpt> If the current timezone was a shaded chunk, the obviously-clickable area would be larger and the zooming probably wouldn't be necessary
[03:49] <mpt> Alternatively, the map could zoom fisheye-style on mouseover :-)
[03:50] <cjwatson> if you can get hold of data for where the timezone boundaries should be drawn, I'd love it to be shaded
[03:50] <cjwatson> I didn't do that because I had no idea where to find that data
[03:50] <cjwatson> (note that some timezones are pretty small and you might still need some zooming)
[03:51] <superm1> cjwatson, have you attempted to run ubiquity lately on a gutsy build?  I have encountered very frequent seg faults that claim to do a core dump, but end up with an empty file.
[03:52] <cjwatson> superm1: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/122141 ?
[03:52] <cjwatson> evand was just mentioning that to me
[03:53] <superm1> cjwatson, likely that would be it
[03:53] <cjwatson> http://aa.usno.navy.mil/graphics/TimeZoneMap2004.png but not freely licensed
[03:53] <superm1> I was originally accounting it to the glib changes (because there is a plethora of glib warnings when it works)
[03:55] <cjwatson> even that .mil map isn't complete; according to tzdata (which also comes from somewhere in .mil, IIRC) there are *:45 zones in Australasia
[03:56] <superm1> cjwatson, barring that its a bit difficult to test my patch due to ubiquity segfaults, did you get a moment to look at it and see if anything stood out as troublesome?
[04:00] <evand> superm1: if you want a quick hack, add the following to translate_widget just after the isinstance function call:
[04:00] <evand> leak = widget.get_image()
[04:00] <superm1> wonderful.  thanks evand
[04:05] <superm1> evand, i'm assuming you meant after the 'else isInstance' call (since that is where the set_image occurs)
[04:06] <evand> superm1: correct
[04:06] <evand> right below the else
[04:06] <superm1> okay i'll throw this through my pbuilder then now
[04:15] <CIA-19> ubiquity: evand * r2101 ubiquity/ (debian/changelog ubiquity/frontend/gtk-ui.py): * Work around 122141 by keeping a reference to the button image.
[04:25] <CIA-19> ubiquity: evand * r2102 ubiquity/ (aclocal.m4 configure d-i/manifest debian/changelog):
[04:25] <CIA-19> ubiquity: * Automatic update of included source packages: silo-installer
[04:25] <CIA-19> ubiquity:  1.10ubuntu3.
[04:34] <CIA-19> ubiquity: evand * r2103 ubiquity/debian/changelog: releasing version 1.5.4
[04:40] <CIA-19> ubiquity: evand * r2104 ubiquity/ (configure configure.ac): Bump to 1.5.5
[05:05] <superm1> evand, could you see anything wrong with moving finished_dialog.run(), as shown here: http://mythbuntu.org/~supermario/mythbuntu/progress_loop.debdiff ?
[05:11] <cjwatson> that code flow is seriously hairy, but that looks ok to me
[05:12] <cjwatson> would it be better to just create a finished method that children can override, though?
[05:12] <cjwatson> seems like that'd be neater
[05:12] <superm1> well thats the thing, i was going to override, but i'm noticing my amount of overrides growing very large
[05:13] <superm1> which will make it difficult to manage changes to the original method
[05:13] <cjwatson> I'm not sure that having to stay in sync with changes to the whole of run and process_step is better than an extra overridden method
[05:13] <cjwatson> I'd rather not heave more stuff into those two complicated methods, TBH ...
[05:14] <superm1> k
[05:14] <superm1> i'll scrap that idea then
[05:16] <superm1> cjwatson, did the rest of my other patch look sane (Everything is all overrides)
[05:17] <cjwatson> I haven't had time to look yet, I'm afraid
[05:17] <cjwatson> just back from debconf + holiday
[05:18] <superm1> oh didn't realize you just got back :)
[05:18] <superm1> okay i'll give you some time then :P
[05:57] <CIA-19> ubiquity: cjwatson * r2105 ubiquity/ubiquity/frontend/gtk-ui.py: remove an apparent (harmless) paste glitch
[06:01] <evand> whoops