My main concerns is that right now we have limited ressources to work on this topics.
Stef On Sun, Oct 29, 2017 at 5:14 PM, Ben Coman <[email protected]> wrote: > > > On Sun, Oct 29, 2017 at 8:28 PM, Thierry Goubier <[email protected]> > wrote: >> >> Hi Hernan, >> >> It's difficult to do an evaluation for the underlying solver, because the >> paper doesn't evaluate that aspect. > > > The solver seems the least interesting part of ALM. There two orthogonal > concerns: > * Generating the constraints - which is probably what distinguishes > AutoLayout, ConstraintLayout, enaml and the key to usability > * Solving the constraints - while doing it right is well known, doing it > efficiently is the challenge which Cassowary has covered. But ideally the > solver would be pluggable so performance could be improved later > substituting an FFI or GPU implemented solver. Also, if it is feasible to > include a solver in the main Pharo distribution, it would be great if that > could be re-used at the business application level. > > So the interesting aspect of ALM seems to be: > * A new algorithm that automatically generates the constraints necessary to > keep a layout non-overlapping. > * Many other layout managers rely on a hierarchy of nested layouts to define > more complex layouts. Within nested layouts, widgets typically cannot be > aligned across different levels of the hierarchy > * ALM constraints are specified as horizontal and vertical tabstops, which > are virtual lines that form a grid to which all the elements of the GUI are > aligned. > > This last point of virtual guidelines echos some ideas that reoccur for me > from time to time - something similar to how professional designer software > like Adobe Illustrator operate with virtual guidelines - though they use > manual placement rather than dynamic constraint based placement. > > There is also the Auckland Layout Editor that might provide a good template > to copy. We've been missing a GUI editor for layouts. > > cheers -ben > >> >> >> Le 29/10/2017 à 13:11, Hernán Morales Durand a écrit : >>> >>> IMO the right move is to take advantage of this technique/library in >>> Smalltalk : >>> >>> "The Auckland Layout Model (ALM) is a novel technique for specifying >>> 2D layout as it is used for arranging the controls in a GUI. The model >>> allows the specification of constraints based on linear algebra, and >>> an optimal layout is calculated using linear programming. Linear >>> equalities and inequalities can be specified on horizontal and >>> vertical tabstops, which are virtual lines that form a grid to which >>> all the elements of the GUI are aligned. The described technique >>> supports the dynamic adaptation of a layout to changes in the >>> environment, e.g. window size, and offers more flexibility than other >>> layout managers. " >>> >>> http://aucklandlayout.sourceforge.net/ >>> >>> Contains various models of layouts: >>> >>> Border Layout >>> Box Layout (BGroupLayout) >>> >>> Horizontal Layout >>> Vertical Layout >>> >>> Gridbag Layout >>> Flow Layout >>> Constraint-Based Layout (BALMLayout) >>> >>> The paper: >>> https://www.cs.auckland.ac.nz/~lutteroth/publications/ZeidlerEtAl2013-AucklandLayoutEditor.pdf >>> >>> The video: https://www.youtube.com/watch?v=NPPz1OJwICA >>> >>> The website: >>> https://www.haiku-os.org/blog/czeidler/2012-09-03_ale_auckland_layout_editor >>> >>> >>> Cheers, >>> >>> Hernán >>> >>> >>> >>> 2017-10-27 14:13 GMT-03:00 Stephane Ducasse <[email protected]>: >>>> >>>> Hi >>>> >>>> I was wondering if there is a layout that we can use to propose >>>> alternate placing layout >>>> for widgets in spec? >>>> >>>> Like >>>> >>>> attached to the left 10pixels rubber band box or fixed size box >>>> 10pixels attached to the right. >>>> >>>> >>>> Stef >>>> >>> >>> >> >> >
