- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Preferences location on linux and windows?

by ClÃ©ment Bera

On Sun, Oct 29, 2017 at 9:27 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > tx! > I would have never guessed it. > That's normal, nobody would have guessed it because it's not a guess. Instead of guessing, one can just use any of the Pharo search engine which allow to find anything in Pharo in a couple seconds. Using GTSpotter, typing 'Preferences' immediately shows as the first result the general and version preference folders, with location and contents. Using the class search feature of Nautilus [1], entering 'Preferences' shows only a couple classes, including StartupPreferencesLoader, which by name explicitly says this is responsible for loading the startup preferences. Looking at its comment we see: ... Print the result of "StartupPreferencesLoader preferencesGeneralFolder" which holds the startup scripts common to all versions of Pharo. Print the result of "StartupPreferencesLoader preferencesVersionFolder" which holds the startup scripts specific to the version of the current image. ... As Nicolas said, the address of the folder is different based on the OS version, OS settings, OS updates, the user rights of the person who started Pharo... That's why in StartupPreferencesLoader the way to find the path is documented and not the path itself. [1] Open Nautilus, right click in the left column and select 'Find class...' in the menu > > > On Sun, Oct 29, 2017 at 9:23 PM, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com> wrote: > > Le 29/10/2017 Ã 21:19, Stephane Ducasse a Ã©crit : > >> Hi guys > >> > >> I'm about to release a new booklet and I need the following information. > >> What are the preferences location on linux and windows? > >> > >> TX > >> > > > > Hi, > > > > For windows: > > > > C:\Users\Name_Of_Your_User\AppData\Roaming > > > > You can also describe it by: > > > > %userprofile%\AppData\Roaming > > > > This location contains a "Pharo" folder. > > > > > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > > 59650 Villeneuve d'ascq France > > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Oct. 30, 2017

Esteban's ChangeLog week of 23 October 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 23 October 2017 to 29 October 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=23/10/2017&to=29/10/2017 ChangeLog ========= 26 October 2017: ---------------- * I spent far too much time backporting 0.6.2 to Pharo 6.1, but now is done :) 25 October 2017: ---------------- * ... and iceberg 0.6.2 hit Pharo 7.0a :) * I just released [Iceberg v0.6.2](https://github.com/pharo-vcs/iceberg/releases/tag/v0.6.2) Now I need to * update Pharo 7.0 * backport to Pharo 6.1 * I backported latest [metacello](http://github.com/metacello/metacello) to Pharo 6.1 This is needed to now backport iceberg (0.6.2) 24 October 2017: ---------------- * And now I took the oportunity to modify zeroconf to *not* download sources if release >= 7.0 (the image comes with sources anyway). * I just changed the way zeroconf works to restore its original purpose. Turns out, at some moment we introduced a change to ask users if an override will happen. But this is a problem because zeroconf is designed to be used on CI environments, where human interaction does not have a place. I restored the old behaviour, but now I'm creating a backup of files already existing. This way if someone has an error and executes zeroconf in the wrong place, previous images will not be lost. 23 October 2017: ---------------- * I spend some days last week woking with the guys of AFI ([http://afi-sa.fr](http://afi-sa.fr), yes they also use Pharo in some of their projects) and together we recovered SeasideTesting from Davis Shaffer to be used for their TDD experience. you can check it out here: [https://github.com/Afibre/SeasideTesting](https://github.com/Afibre/Seaside… Whatâs SeasideTesting? A package to test Seaside components. Why we do not use Parasol? Because it is based on selenium and that makes the process slow. Where can I know more? * there is some documentation here (for VW, I think): [http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… * some slides here (on squeak): [http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf](http://esug.… but all that is old. Best way is to just install and see the tests, as always, cheers! Esteban

Oct. 30, 2017

Re: [Pharo-dev] Preferences location on linux and windows?

by Nicolas Cellier

Par dÃ©finition, tu ne peux pas trouver son adresse c'est un nomade... https://www.linguee.fr/anglais-francais/traduction/roaming.html 2017-10-29 21:27 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > tx! > I would have never guessed it. > > > On Sun, Oct 29, 2017 at 9:23 PM, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com> wrote: > > Le 29/10/2017 Ã 21:19, Stephane Ducasse a Ã©crit : > >> Hi guys > >> > >> I'm about to release a new booklet and I need the following information. > >> What are the preferences location on linux and windows? > >> > >> TX > >> > > > > Hi, > > > > For windows: > > > > C:\Users\Name_Of_Your_User\AppData\Roaming > > > > You can also describe it by: > > > > %userprofile%\AppData\Roaming > > > > This location contains a "Pharo" folder. > > > > > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > > 59650 Villeneuve d'ascq France > > > >

Oct. 29, 2017

Re: [Pharo-dev] Preferences location on linux and windows?

by Stephane Ducasse

tx! I would have never guessed it. On Sun, Oct 29, 2017 at 9:23 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 29/10/2017 Ã 21:19, Stephane Ducasse a Ã©crit : >> Hi guys >> >> I'm about to release a new booklet and I need the following information. >> What are the preferences location on linux and windows? >> >> TX >> > > Hi, > > For windows: > > C:\Users\Name_Of_Your_User\AppData\Roaming > > You can also describe it by: > > %userprofile%\AppData\Roaming > > This location contains a "Pharo" folder. > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Oct. 29, 2017

Re: [Pharo-dev] Preferences location on linux and windows?

by Cyril Ferlicot D.

Le 29/10/2017 Ã 21:19, Stephane Ducasse a Ã©critÂ : > Hi guys > > I'm about to release a new booklet and I need the following information. > What are the preferences location on linux and windows? > > TX > Hi, For windows: C:\Users\Name_Of_Your_User\AppData\Roaming You can also describe it by: %userprofile%\AppData\Roaming This location contains a "Pharo" folder. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 29, 2017

Re: [Pharo-dev] Zinc and Zodiac - Synching/Contributing

by Stephane Ducasse

Yes in general this is simple. Stef On Sat, Oct 28, 2017 at 5:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote >> Hell, I haven't even contributed to Pharo 7 yet. It seems like things are >> still in flux all the time. > > I definitely understand the feeling! Although, one day for fun I fixed a > little bug following Guille's instructions [1] and found it pretty > straightforward. I do not miss slices. In fact updating Fogbugz was harder > than committing the fix ha ha. > > 1. > https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 29, 2017

Preferences location on linux and windows?

by Stephane Ducasse

Hi guys I'm about to release a new booklet and I need the following information. What are the preferences location on linux and windows? TX

Oct. 29, 2017

Re: [Pharo-dev] , for vector creation

by Stephane Ducasse

(1 i: 2) is nice. Tx for the feedback nicolas. On Sat, Oct 28, 2017 at 11:15 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Just a few notes: > > 1) 4 , 2 , 3 , 5 looks too much like Shlemiel the painter, ok for short > vector input, but not even for printing (think re-interpreting) > > 2) 1 x + 2 y + 3 z might look nice. Exactly like 1+2i (Complex) or > 1+2i+3j+4k (Quaternion) > But for the sake of efficiency, I had to introduce (1 i: 2) otherwise > interpretng a complex matrix was too much expensive (compared to Matlab) > > 3) as Doru said, there are many possible conflicts for Number>>, I'm pretty > sure that Jun was using it too > for this reason I removed it from Smallapack > > 2017-10-27 19:12 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Ok good to know. >> >> On Fri, Oct 27, 2017 at 8:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > Indeed, we have BlInsets that are used for either padding or margin. >> > >> > Doru >> > >> >> On Oct 26, 2017, at 11:43 PM, Stephane Ducasse >> >> <stepharo.self(a)gmail.com> wrote: >> >> >> >> Doru >> >> >> >> I was thinking that you would also have BlMargin because Margin is a >> >> nice concept. >> >> When I introduced it with Igor it simplified a lot of code in expand, >> >> shrink and other operations. >> >> >> >> Stef >> >> >> >> On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <tudor(a)tudorgirba.com> >> >> wrote: >> >>> Hi, >> >>> >> >>> To make the conversation more interesting, in Bloc we also have >> >>> BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we >> >>> model explicitly the intention of usage even if they share the instance >> >>> variable names. We did not use Point because we needed 3D and 4D as well and >> >>> Point has too many meanings that are conflated into one. >> >>> >> >>> This pattern was used everywhere we could. For example, we have >> >>> BlBounds instead of Rectangle (actually, this is also because of performance >> >>> reasons of working directly with 4 numbers rather than 2 points). >> >>> >> >>> Of course, these come with an apparent extra maintenance cost. So, if >> >>> we see a possibility of unifying we should definitely take it, and this is >> >>> where external reviewers can help to point out possibilities. We should just >> >>> not unify just for the sake of it. >> >>> >> >>> Cheers, >> >>> Doru >> >>> >> >>>> On Oct 26, 2017, at 10:57 AM, Tudor Girba <tudor(a)tudorgirba.com> >> >>>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov >> >>>>> <dionisiydk(a)gmail.com> wrote: >> >>>>> >> >>>>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>>>> Hi, >> >>>>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov >> >>>>>> <dionisiydk(a)gmail.com> wrote: >> >>>>>> >> >>>>>> Another question. >> >>>>>> >> >>>>>> Will not these vectors deprecate Point in future ? Imaging that we >> >>>>>> will completely move to Bloc. >> >>>>> >> >>>>> No. Point is a perfectly reasonable data structure to describe a >> >>>>> position. A Vector is something else and has other contracts. The >> >>>>> coincidence is that they share the same variables, but they have different >> >>>>> API. For example, a vector has #length. A point does not. >> >>>>> >> >>>>> Now Point implements most vector operations. The #length is defined >> >>>>> as radius by #r message. I imaging that with new vector you will reimplement >> >>>>> many of Point methods. Also I doubt that Point plays any role in system >> >>>>> which is different than math vector. >> >>>> >> >>>> I think that over time we have accumulated all sorts of other usages >> >>>> for Point. For example, Rectangle uses origin and corner as a position not >> >>>> as vectors. >> >>>> >> >>>> Doru >> >>>> >> >>>>> >> >>>>>> And what about Rectangle? (Bloc implements own BlRectangle). >> >>>>> >> >>>>> These two do not have the same semantics. BlRectangle is a >> >>>>> BlGeometry and is used for defining a path within an element. BlRectangle is >> >>>>> polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a >> >>>>> generic data structure that can be used for other purposes. >> >>>>> >> >>>>> We should definitely try to find commonalities and opportunities for >> >>>>> unification. However, we should not confuse state with types which are >> >>>>> defined by the purpose they are used for (and associated behavior). >> >>>>> >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>> >> >>>>>> 2017-10-26 9:26 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>>>>> #(1 3 4 5 7 -2) asVector >> >>>>>> >> >>>>>> Meh. >> >>>>>> Ugly. >> >>>>>> >> >>>>>> { 1. 3. 4. a. b } asVector >> >>>>>> >> >>>>>> is the natural consequence. >> >>>>>> >> >>>>>> v := (1,3,4,5,7,-2) asVector >> >>>>>> >> >>>>>> keeps the parens. But why do I need to do that? >> >>>>>> >> >>>>>> Autoformatting messing with my parentheses is just a mistake. >> >>>>>> I put them in, leave them where they are, 'kay? I do not need an >> >>>>>> editor that rewrites what I tell it. AST power or not. >> >>>>>> >> >>>>>> And frankly, I like the "Feenk way of doing things" most of the >> >>>>>> time, so I am willing to go that route. >> >>>>>> >> >>>>>> Phil >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Automatic formatting will turn it into >> >>>>>>> >> >>>>>>> vector := 1,3,4,5,7,-2. >> >>>>>>> >> >>>>>>> Which is not as nice. >> >>>>>>> >> >>>>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) >> >>>>>>> asVector would work too), this starts to look quite generic: >> >>>>>>> >> >>>>>>> vector := width, height, depth. >> >>>>>>> >> >>>>>>> >> >>>>>>> Question: why not extend @ notation? >> >>>>>>> >> >>>>>>> x @ y @ z? >> >>>>>>> >> >>>>>>> Peter >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Thu, Oct 26, 2017 at 8:22 AM, phil(a)highoctane.be >> >>>>>>> <phil(a)highoctane.be> wrote: >> >>>>>>>> >> >>>>>>>> I also like the , message for those vectors and the concatenation >> >>>>>>>> of dimensions makes sense. >> >>>>>>>> >> >>>>>>>> vector := (1,3,4,5,7,-2). >> >>>>>>>> >> >>>>>>>> looks how it should be. >> >>>>>>>> >> >>>>>>>> Readable, easy to translate vector stuff from reference text. >> >>>>>>>> >> >>>>>>>> Phil >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess >> >>>>>>>> <nicolaihess(a)gmail.com> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" >> >>>>>>>>> <astares(a)gmx.de>: >> >>>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> there might be reasons for an own 2D vector class (instead of >> >>>>>>>>> using Point). >> >>>>>>>>> But still I dislike the reimplementation of "," because for me >> >>>>>>>>> so far it >> >>>>>>>>> has the meaning of "concatenating things". >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Like concatenating coordinates :-) >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Here you redefine it to create vector instances and it works >> >>>>>>>>> only up to three >> >>>>>>>>> so far. Right? >> >>>>>>>>> >> >>>>>>>>> I understand that this gives some similarities with the math >> >>>>>>>>> notation (1,2) >> >>>>>>>>> but I personally would prefer to use: >> >>>>>>>>> >> >>>>>>>>> 1@2 asVector >> >>>>>>>>> >> >>>>>>>>> or Vector2D x: 1 y: 2 >> >>>>>>>>> >> >>>>>>>>> Thx >> >>>>>>>>> T. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >> >>>>>>>>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >> >>>>>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> >>>>>>>>>> Betreff: [Pharo-dev] , for vector creation >> >>>>>>>>>> >> >>>>>>>>>> Hi, >> >>>>>>>>>> >> >>>>>>>>>> As mentioned in the separate thread, we played with introducing >> >>>>>>>>>> the extension: >> >>>>>>>>>> >> >>>>>>>>>> , aNumber >> >>>>>>>>>> ^ BlVector2D x: self y: aNumber >> >>>>>>>>>> >> >>>>>>>>>> This means that (10,20) will return a 2D vector. >> >>>>>>>>>> >> >>>>>>>>>> We also have (10,20,30) which returns a 3D vector. >> >>>>>>>>>> >> >>>>>>>>>> , is used for different meanings already in the image beside >> >>>>>>>>>> the collection concatenation. For example, in FileReference is adds a file >> >>>>>>>>>> extension. And Exceptions create a collection. In other packages, >> >>>>>>>>>> PetitParser uses it as a sequence operator. >> >>>>>>>>>> >> >>>>>>>>>> Please voice your concerns. >> >>>>>>>>>> >> >>>>>>>>>> Cheers, >> >>>>>>>>>> Doru >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> www.tudorgirba.com >> >>>>>>>>>> www.feenk.com >> >>>>>>>>>> >> >>>>>>>>>> "Every thing should have the right to be different." >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> -- >> >>>>> www.tudorgirba.com >> >>>>> www.feenk.com >> >>>>> >> >>>>> "When people care, great things can happen." >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> www.feenk.com >> >>>> >> >>>> "If you interrupt the barber while he is cutting your hair, >> >>>> you will end up with a messy haircut." >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> www.feenk.com >> >>> >> >>> "We are all great at making mistakes." >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "If you can't say why something is relevant, >> > it probably isn't." >> > >> > >> >

Oct. 29, 2017

Re: [Pharo-dev] Layout for placing widgets

by Stephane Ducasse

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 <btc(a)openinworld.com> wrote: > > > On Sun, Oct 29, 2017 at 8:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > 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-Auckl… >>> >>> 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 <stepharo.self(a)gmail.com>: >>>> >>>> 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 >>>> >>> >>> >> >> >

Oct. 29, 2017

Re: [Pharo-dev] Layout for placing widgets

by Ben Coman

On Sun, Oct 29, 2017 at 8:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com> 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/Zeidle >> rEtAl2013-AucklandLayoutEditor.pdf >> >> The video: https://www.youtube.com/watch?v=NPPz1OJwICA >> >> The website: https://www.haiku-os.org/blog/czeidler/2012-09-03_ale_auckla >> nd_layout_editor >> >> >> Cheers, >> >> HernÃ¡n >> >> >> >> 2017-10-27 14:13 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> 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 >>> >>> >> >> > >

Oct. 29, 2017