Re: [Pharo-dev] Layout for placing widgets

[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 :

> 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
>>  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  wrote:
>>>
 2017-10-27 19:13 GMT+02:00 Stephane Ducasse :
>
>>
>> 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 
> 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.s...@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



>
>

Re: [Pharo-dev] Layout for placing widgets

[Thierry Goubier]

Hi Pavel,

Le 28/10/2017 à 22:29, Pavel Krivanek a écrit :

Hi Thierry,

your repository mentions the MIT license but the original license of the 
Cassowary package was LGPL. Is is a different code?


I ported the original, public domain smalltalk implementation of Cassowary.

Regards,

Thierry


Cheers,
-- Pavel

2017-10-28 21:43 GMT+02:00 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
> 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
> wrote:

2017-10-27 19:13 GMT+02:00 Stephane Ducasse
>:


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
>
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
>
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-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-layout-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

Re: [Pharo-dev] , for vector creation

[Nicolas Cellier]

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 :

> Ok good to know.
>
> On Fri, Oct 27, 2017 at 8:39 AM, Tudor Girba  wrote:
> > Indeed, we have BlInsets that are used for either padding or margin.
> >
> > Doru
> >
> >> On Oct 26, 2017, at 11:43 PM, Stephane Ducasse 
> 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 
> 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 
> wrote:
> 
>  Hi,
> 
> > On Oct 26, 2017, at 10:36 AM, Denis Kudriashov 
> wrote:
> >
> > 2017-10-26 10:20 GMT+02:00 Tudor Girba :
> > Hi,
> >> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <
> dionisi...@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 p...@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 
> wrote:
> >>>
> >>> Automatic formatting will turn it into
> >>>
> >>> vector := 1,3,4,5,7,-2.
> >>>
> 

Re: [Pharo-dev] Layout for placing widgets

[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  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  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 
>>> wrote:
 Does that load as part of Bloc?
 
 On Oct 27, 2017, at 12:59 PM, Pavel Krivanek 
 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 :
> 
> 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
> 
 
 
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] Layout for placing widgets

[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
 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  wrote:

2017-10-27 19:13 GMT+02:00 Stephane Ducasse :


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 
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 
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-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-layout-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

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

[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-Pharo



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

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

[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

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

[Sven Van Caekenberghe]

> On 28 Oct 2017, at 11:39, Norbert Hartl  wrote:
> 
> 
> 
>> Am 28.10.2017 um 11:21 schrieb Sven Van Caekenberghe :
>> 
>> Torsten,
>> 
>>> On 26 Oct 2017, at 19:12, Torsten Bergmann  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

Re: [Pharo-dev] Layout for placing widgets

[Jan Vrany]

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 
> wrote:
> > Does that load as part of Bloc?
> > 
> > On Oct 27, 2017, at 12:59 PM, Pavel Krivanek  > 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  > 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
> > > 
> > 
> > 
> 
> 

Re: [Pharo-dev] Layout for placing widgets

[Stephane Ducasse]

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  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 
>> wrote:
>> > Does that load as part of Bloc?
>> >
>> > On Oct 27, 2017, at 12:59 PM, Pavel Krivanek > > 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 > > 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
>> > >
>> >
>> >
>>
>>
>

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

[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.

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

[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  wrote:
>
>
>> On 28 Oct 2017, at 11:39, Norbert Hartl  wrote:
>>
>>
>>
>>> Am 28.10.2017 um 11:21 schrieb Sven Van Caekenberghe :
>>>
>>> Torsten,
>>>
 On 26 Oct 2017, at 19:12, Torsten Bergmann  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
>
>

Re: [Pharo-dev] Layout for placing widgets

[Ben Coman]

> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse :
>>
>> 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 
> 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 
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-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-layout-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

Re: [Pharo-dev] Layout for placing widgets

[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  wrote:
>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse :
>>>
>>> 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 
>> 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 
> 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-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-layout-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
>
>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

I think that testing more SDL and using it will help there.

On Fri, Oct 27, 2017 at 4:50 AM, Ben Coman  wrote:
>
>
> On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba  wrote:
>>
>> Hi,
>>
>> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris 
>> > wrote:
>> >
>> > Denis Kudriashov wrote
>> >> Good initiative.
>> >
>> > +1 :)
>> >
>> >
>> > Denis Kudriashov wrote
>> >> Here is my twitter questions:…
>> >
>> > Mine are:
>> > 1. Is it possible/easy/smooth to zoom in/out?
>>
>> We now have BlScalableElement which handles the zooming. The next thing is
>> to attach animations to it.
>
>
> and...and...and...  can it zoom via the mouse-wheel? Or is support for this
> planned / what are the issues?
>
> cheers -ben

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

[Sven Van Caekenberghe]

Torsten,

> On 26 Oct 2017, at 19:12, Torsten Bergmann  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.

Sven

> Thanks
> Torsten

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

The BlScalableElement is a utility element that zooms the elements inside. 
Indeed, all elements can be transformed, but this is a low level ability. The 
ScalableElement allows us to think in terms of elements, and strategies of 
zooming.

The mouse wheel is an event issue that can be added on top.

Cheers,
Doru



> On Oct 27, 2017, at 4:50 AM, Ben Coman  wrote:
> 
> 
> 
> On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba  wrote:
> Hi,
> 
> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris  wrote:
> >
> > Denis Kudriashov wrote
> >> Good initiative.
> >
> > +1 :)
> >
> >
> > Denis Kudriashov wrote
> >> Here is my twitter questions:…
> >
> > Mine are:
> > 1. Is it possible/easy/smooth to zoom in/out?
> 
> We now have BlScalableElement which handles the zooming. The next thing is to 
> attach animations to it.
> 
> and...and...and...  can it zoom via the mouse-wheel? Or is support for this 
> planned / what are the issues?
> 
> cheers -ben

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

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

[Tudor Girba]

Great work!

Doru


> On Oct 27, 2017, at 11:36 AM, Esteban Lorenzano  wrote:
> 
> Hi,
> 
> I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit 
> for latest changes. 
> This version has an important amount of tweak and fixes, but most important 
> is the inclusion of tonel file format (this is default for Pharo 7.0, 
> optional for Pharo 6.1) and introduces a file-per-class format. 
> The advantages of this format has everything to do with the speed of access 
> (is easier to reconstruct a package like) and the space on disk (methods are 
> usually small but minimum space in disk is usually 4k so we waste a lot of 
> space). Is also a better format for SSD disks.
> 
> To backport Iceberg 0.6.2 I also needed to backport latest version of 
> Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of 
> it available :)
> 
> cheers!
> Esteban
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"We cannot reach the flow of things unless we let go."

Re: [Pharo-dev] Call for help for stability and rewrite of FreeType

[Stephane Ducasse]

(Ok so continuing with this superb gmail UI)


- drop Freetype alltogether
- rewrite the plugin
- create a binding using raffaillac sketch

Now we need help. Who is willing to help us?
Should we try to set up a bounty?

Stef



On Sat, Oct 28, 2017 at 10:48 AM, Stephane Ducasse
 wrote:
> Hi all
>
> I'm and I guess many of you are fedup about the instability that the
> FreeType plugin
> produces.
>
> So we need help because clement and esteban are fully booked.
>
> We have three options:
>
>
> Does anybody
>
>
> Stef

Re: [Pharo-dev] Layout for placing widgets

[Stephane Ducasse]

Pavel I do not think that cassowary is good for us.


On Sat, Oct 28, 2017 at 2:37 AM, Todd Blanchard  wrote:
> Does that load as part of Bloc?
>
> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek 
> 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 :
>>
>> 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
>>
>
>

[Pharo-dev] Call for help for stability and rewrite of FreeType

[Stephane Ducasse]

Hi all

I'm and I guess many of you are fedup about the instability that the
FreeType plugin
produces.

So we need help because clement and esteban are fully booked.

We have three options:


Does anybody


Stef

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

[Norbert Hartl]

> Am 28.10.2017 um 11:21 schrieb Sven Van Caekenberghe :
> 
> Torsten,
> 
>> On 26 Oct 2017, at 19:12, Torsten Bergmann  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. 

Norbert
> 
>> Thanks
>> Torsten