RE: [Development] Idea for automatic widget layout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux