Hi Kerrick, Here's my initial impressions. Some comments are related to Qt, since that's where I come from. ext Kerrick Staley wrote on 2012-08-31: > Hello, > > I had an idea for automating widget layout in a framework like Clutter, > Gtk+, or Qt. Imagine you have a row of widgets that are competing for > horizontal space. Instead of having the developer (who is using the > framework) declare a custom size for each widget, you could instead have > the widget designer declare a mathematical function that takes the > widget's width and returns a value indicating how much utility [1] the > widget gets from that width. > Then, you can sum the utilities for all the > widgets in the row, and then run an optimization algorithm [2] in order > to figure out the allocation that maximizes this sum. This optimization > could be performed at compile time to achieve a static layout, or > dynamically at runtime whenever the window size changes or the widgets' > contents change. Hmmm.. I don't see a big use-case for calculating layouts at compile-time. Manual layouting within form editors (e.g. Qt designer) will probably solve 95% of those cases. And you can always manually calculate the actual geometries at source-code-generation-time :). > > As an example, let's say you have a widget displaying a table or > spreadsheet populated with some data. Assume the widget has the > ability to automatically add scrollbars if there is not enough room to > display its contents. If there is not enough room to display all the > columns in this table, then the user will still get some partial > benefit from being able to see only a few of the columns in the table; > they can scroll through the rest. The more columns, the better, > however: this minimizes the amount of scrolling necessary. The user > will *not* get much benefit, however, out of being able to see half of > a column: if there is enough space to display, say, 3.5 columns, then > the table might as well be big enough to display only 3 columns: the > user won't be able to read anything in the extra half-column anyway. > Hence, the utility curve for this widget will end up looking something > like a step function (but will flatten for widths that are enough to > display all the data). As another example, an image will have a > utility curve that grows drastically initially, but slows down once > the image is large enough for the user to discern its contents. I don't see how it can drastically grow initially if the utility function cannot return a value larger than the widget's width? (Since you named it 'utility' I'm assuming the returned value must be less-than-or-equal to the width of the widget. Is my assumption wrong?) > > The curve of the widget will depend on the widget's content, and may > change as the program runs. Widgets may change their internal layout > entirely at certain sizes (e.g. a widget may display text and an icon > at larger sizes, but display only an icon at smaller sizes); in this > situation, the utility curve will end up being a piecewise function. > The application designer (who is distinct from the widget designer) > may also be able to supply parameters to alter the utility curve; the > most obvious example is a parameter that would scale the whole utility > curve, making that widget bigger in the layout. > > If no "good" choice for a utility curve is immediately apparent, then > a curve of the form k*ln(w) (where w is the input width and k is a > scaling parameter) is a good default. If all the widgets in a row are > assigned this curve, then it turns out that the optimal width of each > widget is proportional to that widget's k parameter. > > I don't know how useful/practical this idea is, but I don't think I > have the time to create an effective implementation all by myself. If > some of the Clutter or Gtk+ folks are interested in implementing this > idea in their framework, I'd love to help out, though (sorry Qt devs, > but I'm a GNOME guy). The most useful thing about this idea is that it would allow to limit the size of the widget to a set of discrete sizes, and this is something that Qt's layout system does not support. I'm not sure I see a big value in allowing non-linear + non-discrete functions. So if we just want to limit ourselves to a set of discrete sizes, the utility function is overkill, and leaves little room for optimization. In that case I would prefer a bit more "declarative" approach, where each discrete step could be specified or something. > > - Kerrick > > [1] The units of the utility value are meaningless, but all the > widgets within a library should have utility curves that are > commensurate with each other, so that their default behavior is reasonable. > > [2] Optimization is well-studied; see > https://en.wikipedia.org/wiki/Mathematical_optimization. However, the > choice of algorithm with which to perform the optimization is crucial, > especially if the optimization will be carried out at runtime. An > appropriate algorithm should be very fast, but doesn't necessarily need > to return the global maximum; instead, it should return a layout that's > "good enough". As time progresses and CPU power increases, increasingly > sophisticated algorithms can be used for this purpose. Yes, but it might be *very* slow. Since the utility functions might be nonlinear, using linear programming to find the optimal solution is obviously not possible. And non-linear programming is not efficient. The alternative then is to use an iterative method, which is also slow. And I don't even know how well iterative methods works with discrete functions. regards, Jan Arve _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
