(03:38:31 PM) mclasen: ok, that last point I put on the agenda was extended layout, again
(03:40:41 PM) tbf: ok, so what shall i do, that we get it in?
(03:40:49 PM) mclasen: although I don't know if we have much new insight there since the last time we discussed it
(03:41:28 PM) kris: I will review the cell view, tree view and related bits once you guys settled on the API
(03:41:33 PM) mclasen: tbf: the one thing I wanted to point out about your sorting concern
(03:41:54 PM) kris: because it doesn't feel productive to review to me if the API/inner works is still up in the air
(03:41:59 PM) tbf: mclasen: well, gtktable is inefficient already: O(n²)
(03:42:15 PM) mclasen: is that I think you should be able to do much better than n log n, since the list should be almost always nearly sorted
(03:42:18 PM) tbf: mclasen: and merge sort only has O(n log n) on a unsorted list
(03:42:24 PM) mclasen: unless the requisitions of the children vary wildly
(03:42:40 PM) tbf: mclasen: on a sorted list it is O(n) - so sorting shouldn't be a concern
(03:43:03 PM) tbf: mclasen: false alert
(03:43:09 PM) mclasen: fok, cool
(03:43:54 PM) mclasen: timj: I wonder if you had time to review the extended layout work at all ?
(03:44:02 PM) mclasen: iirc, you have some prior art in that area...
(03:45:07 PM) timj: haven't had time for review yet nufortunnately
(03:45:29 PM) tbf: mclasen: maybe we should start in small steps... natural size for gtklabel and gtk[hv]box
(03:45:41 PM) tbf: plus the required interface definition
(03:45:52 PM) Behdad Esfahbod: I think the main question at this point is, whether to go with Havoc's proposal of a merged natural and minimum extents, or separate calls as it is right now
(03:46:24 PM) Behdad Esfahbod: the rest looked like implementation details to me
(03:46:34 PM) tbf: behdad that's indeed an interesting question: my feeling is, that his proposal makes things more complicated - not more easy
(03:47:01 PM) tbf: behdad: as you have to maintain more state in your size request functions and take care, not to confuse things
(03:47:09 PM) Behdad Esfahbod: tbf: you can always make that method simply call two other ones to fill in each of natural and min
(03:47:27 PM) tbf: behdad: the other direction also works
(03:47:36 PM) Behdad Esfahbod: on the other hand, gives you the ability to for example build a pangolayout once, then measure it differently to set both natural and min
(03:47:50 PM) Behdad Esfahbod: tbf: other direction has overhead
(03:47:55 PM) Behdad Esfahbod: you end up computing some stuff twice
(03:48:07 PM) Behdad Esfahbod: and if you always going to call both, makes sense to merge to me
(03:48:09 PM) tbf: behdad: you have to completly reconfigure the layout anyway
(03:48:18 PM) msanchez left the room (quit: Ex-Chat).
(03:48:34 PM) Behdad Esfahbod: tbf: no. it may be as simple as calling set_width on it. building the layout is done once.
(03:48:51 PM) ***Behdad Esfahbod brings up tbf's mail
(03:49:13 PM) Behdad Esfahbod: there was another advantage to havoc's idea
(03:49:49 PM) Behdad Esfahbod: was it nov or oct?
(03:49:53 PM) Behdad Esfahbod: found
(03:49:56 PM) Behdad Esfahbod: http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html
(03:50:57 PM) Behdad Esfahbod: havoc's version decouples width and height completely
(03:51:41 PM) Behdad Esfahbod: that is, when computing natural width, also computing natural height is pretty much useless
(03:51:56 PM) Behdad Esfahbod: you really need to recompute proper height based on allocated width later anyway
(03:52:03 PM) Behdad Esfahbod: so I like havoc's api better
(03:52:21 PM) Behdad Esfahbod: or maybe yours is more natural and lends to more optimizations. donno
(03:53:22 PM) mclasen: I assume you can always pass NULL for the out arguments to forego the calculation of a piece of information ?
(03:53:30 PM) mclasen: if there are out parameters, that is...
(03:53:46 PM) Behdad Esfahbod: well, the implementation should support it still
(03:54:38 PM) tbf: mclasen: but if you do not want to get lost in if/else desert, you calculate everything anyway
(03:54:56 PM) mclasen: I guess
(03:55:12 PM) Behdad Esfahbod: I suggest writing havoc's api and implementing it for gtklabel
(03:55:16 PM) Behdad Esfahbod: then compare the two
(03:55:22 PM) mclasen: so I don't think I can see a clear advantage to either variant
(03:55:40 PM) mclasen: so looking at a real case like gtklabel and deciding based on that seems reasonable
(03:56:22 PM) Behdad Esfahbod: tbf: can you do that, or too much work?
(03:57:00 PM) tbf: behdad: from re-reading the code: for gtklabel separating height and width calculation would require calulation size requests, twice
(03:57:18 PM) tbf: behdad: for gtklabel, height and width are quite coupled
(03:57:28 PM) Behdad Esfahbod: I'll try to review your stuff again then.
(03:58:34 PM) ***mclasen is looking at the patches, too
(03:59:16 PM) tbf: well, i can try to rewrite gtklabel to support havoc's suggestions...
(04:01:10 PM) Behdad Esfahbod: tbf: ok, we can meet later and take an in-depth look then
(04:01:15 PM) mclasen: tbf: so, your email has this
(04:01:16 PM) Behdad Esfahbod: say, friday
(04:01:19 PM) mclasen: I have to admit, that I have to check the impact of my size-negotiation
(04:01:19 PM) mclasen: code on size-groups, as I forgot to define an invariant similar to the
(04:01:19 PM) mclasen: natural-size invariant. Just realized that, when writing this up.
(04:01:32 PM) mclasen: any further insight into how size groups fit into extended layout ?
(04:03:46 PM) tbf: no new insights