- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Layout for placing widgets

by Todd Blanchard

Actually, Apple's "autolayout" is Cassowary. It is kind of inconvenient to use as is. However there are some very nice libraries. One I have used on a couple iOS projects is called PureLayout. https://github.com/PureLayout/PureLayout It has nice methods like aView autoAlignAxis: AxisHorizontal toSameAxisOfView: anotherView or aView autoCenterInSuperviewWithInsets: layoutInsets as to license: "The original implementation in OTI Smalltalk is in the public domain;" http://constraints.cs.washington.edu/cassowary/ If Thierry based his port on that version, it should be all good. I'm a fan of PureLayout - very easy to use. > On Oct 28, 2017, at 7:07 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Did you try? > I always pay attention to things that should iterate a while and > stabilise. Now I may be wrong. > I have cassowary on my machine. > I worked long time on constraints and I thought that apple has a > better model with anchor and rubber band. > > Stef > > On Sat, Oct 28, 2017 at 12:36 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> On Sat, 2017-10-28 at 10:48 +0200, Stephane Ducasse wrote: >>> Pavel I do not think that cassowary is good for us. >> >> Why? >> >> Jan >> >>> >>> >>> On Sat, Oct 28, 2017 at 2:37 AM, Todd Blanchard <tblanchard(a)mac.com> >>> wrote: >>>> Does that load as part of Bloc? >>>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek@gmail. >>>> com> >>>> wrote: >>>> >>>> Maybe we should check cassowary >>>> >>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/# >>>> ui-constraints >>>> >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.co >>>> m>: >>>>> >>>>> 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. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Pavel Krivanek

Hi Thierry, your repository mentions the MIT license but the original license of the Cassowary package was LGPL. Is is a different code? Cheers, -- Pavel 2017-10-28 21:43 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 28/10/2017 Ã 16:26, Stephane Ducasse a Ã©crit : > >> I was reading ... >> I will see if I can load cassowary in Pharo. >> > > https://github.com/ThierryGoubier/Cassowary > > Done two years ago. > > Thierry > > > >> On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> >>> Ok then may be we should give a try to use. Tx for the links. >>> >>> Stef >>> >>> On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>>> >>>>>> 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. >>>>>> >>>>> >>>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>> wrote: >>>>> >>>>> Maybe we should check cassowary >>>>> >>>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints- >>>>> part-1/#ui-constraints >>>>> >>>> >>>> >>>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> Pavel I do not think that cassowary is good for us. >>>>> >>>> >>>> >>>> Do you mean Cassowary in particular, or constraint based UI in general? >>>> >>>> My naive first impression is, if Cassowary is good enough for Apple... >>>> https://news.ycombinator.com/item?id=9846992 >>>> https://www.quora.com/Should-I-use-Auto-Layout >>>> >>>> and Google (search here for "solver")... >>>> https://academy.realm.io/posts/cool-constraintlayout-droidco >>>> n-boston-2017/ >>>> >>>> such that "in 2016, both iOS and Android have first-party layout systems >>>> based on Cassowary." >>>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-l >>>> ayout-how-do-they-compare/ >>>> >>>> then it seems worth some analysis, and discussion of better >>>> alternatives. >>>> >>>> >>>> Coincidentally, I see a Smalltalk implementation is available... >>>> http://www.squeaksource.com/Cassowary.html >>>> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >>>> >>>> >>>> For balance, some points against AutoLayout, but some alternatives also >>>> seem >>>> to use Cassowary solver... >>>> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_ >>>> i_dont_use_autolayout/ >>>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-l >>>> ayout-how-do-they-compare/ >>>> https://makeapppie.com/2015/10/28/why-stack-views-are-your- >>>> best-friend-if-you-hate-auto-layout/ >>>> https://cocoacasts.com/working-with-stack-views/ >>>> >>>> >>>> cheers -ben >>>> >>>> >>>> > >

Oct. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Thierry Goubier

Le 28/10/2017 Ã 16:26, Stephane Ducasse a Ã©critÂ : > I was reading ... > I will see if I can load cassowary in Pharo. https://github.com/ThierryGoubier/Cassowary Done two years ago. Thierry > > On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Ok then may be we should give a try to use. Tx for the links. >> >> Stef >> >> On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>> 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. >>> >>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> >>>> Maybe we should check cassowary >>>> >>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… >>> >>> >>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>>> >>>> Pavel I do not think that cassowary is good for us. >>> >>> >>> Do you mean Cassowary in particular, or constraint based UI in general? >>> >>> My naive first impression is, if Cassowary is good enough for Apple... >>> https://news.ycombinator.com/item?id=9846992 >>> https://www.quora.com/Should-I-use-Auto-Layout >>> >>> and Google (search here for "solver")... >>> https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ >>> >>> such that "in 2016, both iOS and Android have first-party layout systems >>> based on Cassowary." >>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >>> >>> then it seems worth some analysis, and discussion of better alternatives. >>> >>> >>> Coincidentally, I see a Smalltalk implementation is available... >>> http://www.squeaksource.com/Cassowary.html >>> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >>> >>> >>> For balance, some points against AutoLayout, but some alternatives also seem >>> to use Cassowary solver... >>> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… >>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >>> https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… >>> https://cocoacasts.com/working-with-stack-views/ >>> >>> >>> cheers -ben >>> >>>

Oct. 28, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Sean P. DeNigris

EstebanLM wrote > I backported lastest Iceberg version to Pharo 6.1 Awesome! Which image number has this? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 28, 2017

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

by Sean P. DeNigris

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. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Stephane Ducasse

I was reading ... I will see if I can load cassowary in Pharo. On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Ok then may be we should give a try to use. Tx for the links. > > Stef > > On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> 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. >> >> >>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> >>> Maybe we should check cassowary >>> >>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… >> >> >> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Pavel I do not think that cassowary is good for us. >> >> >> Do you mean Cassowary in particular, or constraint based UI in general? >> >> My naive first impression is, if Cassowary is good enough for Apple... >> https://news.ycombinator.com/item?id=9846992 >> https://www.quora.com/Should-I-use-Auto-Layout >> >> and Google (search here for "solver")... >> https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ >> >> such that "in 2016, both iOS and Android have first-party layout systems >> based on Cassowary." >> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >> >> then it seems worth some analysis, and discussion of better alternatives. >> >> >> Coincidentally, I see a Smalltalk implementation is available... >> http://www.squeaksource.com/Cassowary.html >> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >> >> >> For balance, some points against AutoLayout, but some alternatives also seem >> to use Cassowary solver... >> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… >> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >> https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… >> https://cocoacasts.com/working-with-stack-views/ >> >> >> cheers -ben >> >>

Oct. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Stephane Ducasse

Ok then may be we should give a try to use. Tx for the links. Stef On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> 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. > > >> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >> Maybe we should check cassowary >> >> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… > > > On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Pavel I do not think that cassowary is good for us. > > > Do you mean Cassowary in particular, or constraint based UI in general? > > My naive first impression is, if Cassowary is good enough for Apple... > https://news.ycombinator.com/item?id=9846992 > https://www.quora.com/Should-I-use-Auto-Layout > > and Google (search here for "solver")... > https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ > > such that "in 2016, both iOS and Android have first-party layout systems > based on Cassowary." > https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… > > then it seems worth some analysis, and discussion of better alternatives. > > > Coincidentally, I see a Smalltalk implementation is available... > http://www.squeaksource.com/Cassowary.html > https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf > > > For balance, some points against AutoLayout, but some alternatives also seem > to use Cassowary solver... > https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… > https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… > https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… > https://cocoacasts.com/working-with-stack-views/ > > > cheers -ben > >

Oct. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Ben Coman

> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> 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. > On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > Maybe we should check cassowary > https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui- constraints On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Pavel I do not think that cassowary is good for us. Do you mean Cassowary in particular, or constraint based UI in general? My naive first impression is, if Cassowary is good enough for Apple... https://news.ycombinator.com/item?id=9846992 https://www.quora.com/Should-I-use-Auto-Layout and Google (search here for "solver")... https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ such that "in 2016, both iOS and Android have first-party layout systems based on Cassowary." https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… then it seems worth some analysis, and discussion of better alternatives. Coincidentally, I see a Smalltalk implementation is available... http://www.squeaksource.com/Cassowary.html https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf For balance, some points against AutoLayout, but some alternatives also seem to use Cassowary solver... https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… https://cocoacasts.com/working-with-stack-views/ cheers -ben

Oct. 28, 2017

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

by Stephane Ducasse

Sven Normally by the end of next week we will have a new file format as well as an automatic transition for older projects. After that I think that using Pharo 70 tools and contributing will be ok. Right now this is working and sometimes blow up a bit :) Stef On Sat, Oct 28, 2017 at 12:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 28 Oct 2017, at 11:39, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 28.10.2017 um 11:21 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Torsten, >>> >>>> On 26 Oct 2017, at 19:12, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> Hi Sven, >>>> >>>> for Zinc there is a new issue: >>>> >>>> >>>> 1. Zinc is using #asBytesDescription. It should not be used as it is deprecated >>>> >>>> https://github.com/pharo-project/pharo/pull/401 >>> >>> This change was applied upstream: >>> >>> === >>> Name: Zinc-HTTP-SvenVanCaekenberghe.470 >>> Author: SvenVanCaekenberghe >>> Time: 28 October 2017, 11:10:06.068769 am >>> UUID: 1d831c82-f918-0d00-9306-5dc70a8677c5 >>> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.469 >>> >>> Follow an API change in Pharo: use #humanReadableSIByteSize instead of #asByteDescription in ZnUtils>>#signalProgress:total: >>> === >>> >>>> there is also >>>> >>>> 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. >>> >>> This is waiting for an integrator, I believe people are working on it. >>> >>>> I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: >>>> >>>> 3. Proper categorization in Zodiac-Tests package >>>> - to use "test" category instead of "testing" and better group the tests written >>>> >>>> https://github.com/pharo-project/pharo/pull/355/files >>>> >>>> Also it looks like the #setUp in Zodiac tests never send a "super setUp". Which >>>> should be fixed too. >>> >>> Hmm, these are more cosmetic changes, I will have a look at them later on. >>> >>>> I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use your own custom >>>> hosting server on >>>> >>>> http://mc.stfx.eu/Zodiac >>>> http://mc.stfx.eu/ZincHTTPComponents >>> >>> I would not call that a custom hosting solution, it is just Monticello. Note that there are also a copies on StHub. >>> >>>> as well as github: >>>> >>>> https://github.com/svenvc/zinc >>>> https://github.com/svenvc/zodiac >>>> >>>> If we just merge the changes from 3. into Pharo 7 they may later be overwritten when >>>> synching also Zodiac again as in 2. >>> >>> Yes, that is true. I have to follow upstream. The GitHub versions also lag a bit sometimes. >>> >>>> So how can we contribute from community side to both projects? Should I fork >>>> https://github.com/svenvc/zodiac and send a PR to it so that you can integrate? >>> >>> Zinc/Zodiac are integral parts of Pharo that are managed externally. The goal is to simultaneously support many Pharo versions, not just the latest. Most production deploys of Pharo use version 4, 5 or 6, but they still need good HTTP(S) support. That is what I am trying to do. >>> >>> The older MC repositories are public, so others can contribute in the proven MC way. I have nothing against git, but I have not yet fully switched, nor do I think that I can if I want to support older Pharo versions. >>> >> You can move to git and commit from time to time in smalltalkhub. Or even automatically. > > I am not yet ready for that. > > Hell, I haven't even contributed to Pharo 7 yet. It seems like things are still in flux all the time. Now it seems the whole filetree will go away. > >> Norbert >>> >>>> Thanks >>>> Torsten > >

Oct. 28, 2017

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

by Stephane Ducasse

>> 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. > > This is waiting for an integrator, I believe people are working on it. I do not know how to do it. Else I would do it. >> I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: >> >> 3. Proper categorization in Zodiac-Tests package >> - to use "test" category instead of "testing" and better group the tests written >> >> https://github.com/pharo-project/pharo/pull/355/files >> >> Also it looks like the #setUp in Zodiac tests never send a "super setUp". Which >> should be fixed too. > > Hmm, these are more cosmetic changes, I will have a look at them later on. > >> I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use your own custom >> hosting server on >> >> http://mc.stfx.eu/Zodiac >> http://mc.stfx.eu/ZincHTTPComponents > > I would not call that a custom hosting solution, it is just Monticello. Note that there are also a copies on StHub. > >> as well as github: >> >> https://github.com/svenvc/zinc >> https://github.com/svenvc/zodiac >> >> If we just merge the changes from 3. into Pharo 7 they may later be overwritten when >> synching also Zodiac again as in 2. > > Yes, that is true. I have to follow upstream. The GitHub versions also lag a bit sometimes. I think that with better tools such solutions will be solved in the future, > >> So how can we contribute from community side to both projects? Should I fork >> https://github.com/svenvc/zodiac and send a PR to it so that you can integrate? > > Zinc/Zodiac are integral parts of Pharo that are managed externally. The goal is to simultaneously support many Pharo versions, not just the latest. Most production deploys of Pharo use version 4, 5 or 6, but they still need good HTTP(S) support. That is what I am trying to do. > The older MC repositories are public, so others can contribute in the proven MC way. I have nothing against git, but I have not yet fully switched, nor do I think that I can if I want to support older Pharo versions. Indeed we should have a process to load MC githubified versions for a while.

Oct. 28, 2017