- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About morph layout

by StÃ©phane Ducasse

Hannes this is exactly for these reasons that we started Pharo. We want to have a clean and powerful system. Now in addition we want to make sure that people can make business with it. And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable in 1980 that are now possible. Now I think that Pharo delivers. We will continue. Stef

Dec. 24, 2012

[Pharo-project] [update 2.0] #20453

by Marcus Denker

20453 ----- Issue 7165: CleanUp MethodChangeRecord (preparation) http://code.google.com/p/pharo/issues/detail?id=7165 Issue 7018: move unicode initialization methods to the separate package http://code.google.com/p/pharo/issues/detail?id=7018 Diff information: http://ss3.gemstone.com/ss/Pharo20/Unicode-Initialization-MarcusDenker.2.di… http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.195.diff http://ss3.gemstone.com/ss/Pharo20/Multilingual-TextConversion-MarcusDenker… http://ss3.gemstone.com/ss/Pharo20/Multilingual-Encodings-MarcusDenker.39.d… http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1278.diff

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by H. Hirzel

Hello Igor Thank you for this interesting mail. An issue over 11 years old, see below. On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, > > just wanna share some ideas about how we can cleanup morph a bit. A bit? It will be a lot of effort. Squeak 4.4-12234 (current) Morph selectors size 1183 Pharo 2.0 (Beta) Morph selectors size 865 Cuis 4.1 (18th Dec 2012) Morph selectors size 343 This was an issue in 2001 http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt see > Layout.. bizarre. Yes, see humorous contribution from June 2001 http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt search for the Morph class has 924 methods in that mails There was an effort Morphic Cleanup Project http://wiki.squeak.org/squeak/3005 lead by Diego Gomez Deck It produced some results. But they did not reach far enough. However Juan Vuletic was successful in coming up with a simpler Morphic in Cuis. http://www.jvuletich.org/Cuis/Index.html > There are so many methods dedicated to laying out morphs that it easy > to get lost. Cuis has a new layout system. Worth to check out. > For me the main mystery and source of confusion is that there actually > two different groups: > > - methods to control morph's own layout (in respect to its parent) > - methods to control morph's children layout (something called > layoutPolicy) > > the problem is that both APIs are found in single class, which one? and most of > them contain 'layout' word in it, > so it is really hard to determine which one to use and when.. > > Over a years, i seen that people learned how to use existing > functionality, without delving deep into > implementation detail. Yes. > But if you try to extend/change behavior (in your subclass), you will > quite soon find out that it is really > hard to tell with 100% certainty that the methods you override is the > right place for your customization. Yes, this actually has made development very difficult. In such a way that most people have abandoned it. Very few GUIs are actually built with it. > Also, an important detail is extremely polluted protocol(s), making > Morph a GOD class, > with so many functions that it is unbearable. > So, what i want to propose is same as i proposed to introduce for > "SmalltalkImage" > is to use "scoping" accessors , or "delegate" accessor to get access > to part of functionality > with clear context. Surely a good intermediary step. > Remember: > Smalltalk vm version > Smalltalk tools browser > > so, lets see how code might look like if we apply same approach to > morph protocols: > > Example. > Original: > > column := AlignmentMorph newColumn vResizing: #shrinkWrap; > hResizing: #shrinkWrap; > layoutInset: 1; > borderColor: Color black; > borderWidth: 0; > wrapCentering: #center; > cellPositioning: #center; > color: Color white; > yourself. > > Change: > > column := AlignmentMorph newColumn. > > column color: Color white. > column layout shrinkWrap. "v and h both" > > column border > width: 0; > color: Color black. > > column childLayout > inset: 1; > wrapCentering: #center; > cellPositioning: #center. > > Cons: > - a code is a bit more elaborate. That because, of course, we cannot > merge everything into single cascade. > > Pros: > - from code it is clear, which properties belong to which parts of > functionality. You cannot confuse, for instance, whether > 'wrapCentering' > property controls morph's own layout or a layout of its children > - most important, we can considerably shrink Morph's protocol by > removing all direct accessors and instead put them into delegated > behaviors. > > More than that, a delegates don't need to be a dummy state holders > (like most of properties are now), but actually an object(s) which > conform to certain protocol.. > > For instance, if we have a 'border' as a delegate, and morph wants to > draw it, it could just tell: > > MyMorph>>drawOn: aCanvas > self border drawOn: aCanvas > > btw, then it is actually makes sense having a BorderedMorph subclass, which > a) introduces 'border' delegate > b) cares to draw its border > in contrast to Morph who shouldn't. > > As well as in case of layouts, you can tell: > > morph layout changed. > > or > > morph childLayout layOutChildren. > > etc. > > I can't comment more at the approach at the moment. Could you elaborate it a bit more? As the leading example of Juan Vuletich shows it is possible to reduce the complexity of Morphic. It would be good to check out what he has written about his work. Best regards Hannes Hirzel > -- > Best regards, > Igor Stasenko. > >

Dec. 24, 2012

Re: [Pharo-project] A contorted way of making things work :)

by H. Hirzel

Cuis 4.1 was released last Tuesday, 18th Dec. Juan Vuletich writes on the Cuis mailing list "Cuis 4.1 is available at http://www.jvuletich.org/Cuis/Index.html . Biggest news is in the Morph hierarchy. Ivars 'bounds' and 'fullBounds' are gone! All coordinates are now Float and relative to the owner morph. This is part of the transition to Morphic 3. The drawing engine is still BitBlt and the UI is not scalable yet, but Morphic 3 is now much closer." After this effort of Juan, Morphic is much easier to understand. It is fun to play with Cuis and assumingly a source of ideas to apply to Pharo as well. It would be interesting to know from Juan how he managed to get rid of the instance variables 'bounds' and 'fullBounds' --Hannes On 12/24/12, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: > On 24/12/2012 02:03, Igor Stasenko wrote: >> On 24 December 2012 02:27, Peter H. Meadows >> <peter.h.meadows(a)googlemail.com> wrote: >>> What is 'morphic 3' in cuis? Could it be ported to pharo? >>> >> Morphic 3 is a grand project pursued mainly by Juan. >> Once it will be released to public, we will see. > > I believe the most recent Cuis has started this by changing all > coordinates to parent relative Floats and also by expunging bounds and > fullBounds. > >

Dec. 24, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Douglas Brebner

On 24/12/2012 02:03, Igor Stasenko wrote: > On 24 December 2012 02:27, Peter H. Meadows > <peter.h.meadows(a)googlemail.com> wrote: >> What is 'morphic 3' in cuis? Could it be ported to pharo? >> > Morphic 3 is a grand project pursued mainly by Juan. > Once it will be released to public, we will see. I believe the most recent Cuis has started this by changing all coordinates to parent relative Floats and also by expunging bounds and fullBounds.

Dec. 24, 2012

[Pharo-project] About morph layout

by Igor Stasenko

Hi, just wanna share some ideas about how we can cleanup morph a bit. Layout.. bizarre. There are so many methods dedicated to laying out morphs that it easy to get lost. For me the main mystery and source of confusion is that there actually two different groups: - methods to control morph's own layout (in respect to its parent) - methods to control morph's children layout (something called layoutPolicy) the problem is that both APIs are found in single class, and most of them contain 'layout' word in it, so it is really hard to determine which one to use and when.. Over a years, i seen that people learned how to use existing functionality, without delving deep into implementation detail. But if you try to extend/change behavior (in your subclass), you will quite soon find out that it is really hard to tell with 100% certainty that the methods you override is the right place for your customization. Also, an important detail is extremely polluted protocol(s), making Morph a GOD class, with so many functions that it is unbearable. So, what i want to propose is same as i proposed to introduce for "SmalltalkImage" is to use "scoping" accessors , or "delegate" accessor to get access to part of functionality with clear context. Remember: Smalltalk vm version Smalltalk tools browser so, lets see how code might look like if we apply same approach to morph protocols: Example. Original: column := AlignmentMorph newColumn vResizing: #shrinkWrap; hResizing: #shrinkWrap; layoutInset: 1; borderColor: Color black; borderWidth: 0; wrapCentering: #center; cellPositioning: #center; color: Color white; yourself. Change: column := AlignmentMorph newColumn. column color: Color white. column layout shrinkWrap. "v and h both" column border width: 0; color: Color black. column childLayout inset: 1; wrapCentering: #center; cellPositioning: #center. Cons: - a code is a bit more elaborate. That because, of course, we cannot merge everything into single cascade. Pros: - from code it is clear, which properties belong to which parts of functionality. You cannot confuse, for instance, whether 'wrapCentering' property controls morph's own layout or a layout of its children - most important, we can considerably shrink Morph's protocol by removing all direct accessors and instead put them into delegated behaviors. More than that, a delegates don't need to be a dummy state holders (like most of properties are now), but actually an object(s) which conform to certain protocol.. For instance, if we have a 'border' as a delegate, and morph wants to draw it, it could just tell: MyMorph>>drawOn: aCanvas self border drawOn: aCanvas btw, then it is actually makes sense having a BorderedMorph subclass, which a) introduces 'border' delegate b) cares to draw its border in contrast to Morph who shouldn't. As well as in case of layouts, you can tell: morph layout changed. or morph childLayout layOutChildren. etc. -- Best regards, Igor Stasenko.

Dec. 24, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Igor Stasenko

On 24 December 2012 02:27, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > What is 'morphic 3' in cuis? Could it be ported to pharo? > Morphic 3 is a grand project pursued mainly by Juan. Once it will be released to public, we will see. -- Best regards, Igor Stasenko.

Dec. 24, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Peter H. Meadows

What is 'morphic 3' in cuis? Could it be ported to pharo? On 23 December 2012 16:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 23, 2012, at 5:09 PM, Igor Stasenko wrote: > >> On 23 December 2012 16:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> Is there a list of the pitfalls of morphic somewhere ? >>> >> How dare you! :) >> >> Of course there's no such thing. > > - global positioning > - too many responsibilities > for example handMorph > - too many duplicated logic (border is one) > - isKindOf: usage > >> Morphic was developed on premise that you are clever enough to >> understand it by reading code. >> >> P.S. Don't think that i want to blame anyone, or discourage from using it. >> Morphic based on a very good concepts. And i really like it. >> But then, lack of documentation, lack of systematic approach >> and no review process has led it to what we have now. > > > This is why we should start to systematically rethink it and clean it. :) >

Dec. 24, 2012

Re: [Pharo-project] Error 400 when pushing to Smalltalk with metacello

by Camillo Bruni

maybe silly question... are you 100% sure that you have the same repository (aka credentials) for the normal package and the config-package? happened to me more than once that I accidentally have two MC repositories and I only declare the credentials in one :/ also the errors codes from smalltalkhub where not always that useful. Maybe that is fixed now, but I remember to always get a 400 and not the specific html error codes 401 unauthorized 404 not found 409 conflict at least in general having specific messages would help figure out what's wrong.. On 2012-12-23, at 14:34, Damien Pollet <damien.pollet(a)gmail.com> wrote: > When I use the metacello convenience method > #saveModifiedPackagesAndConfiguration: my package mcz uploads fine but then > I often get a 400 error for the configuration mcz (I would not say > systematic but most of the time). But if I go to monticello and copy it to > smalltalkhub from the package cache, it goes fine. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 23, 2012

Re: [Pharo-project] producing a .pdf from Pharo

by Alexandre Bergel

> What about using Athens with Cairo back-end? Cairo can produce PDF We will keep that in mind. Thanks! Alexandre > > > On Wed, Dec 19, 2012 at 1:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Perfect!!! > Thanks guys! > > Alexandre > > > On Dec 19, 2012, at 12:21 PM, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: > > > Hi Alexandre, > > > > I think that it's possible. Actualy with Artefact, you can draw geometric shapes and texts. The stable version is the 174 on Squeaksource. > > > > Olivier ;-) > > > > Le 19 dÃ©c. 2012 Ã 11:50, Alexandre Bergel a Ã©crit : > > > >> Hi! > >> > >> I know there has been some discussions related to this, however I could not find anything relevant from google. > >> I have no knowledge about the .pdf format, but I am wondering how feasible is it to export Roassal like visualization [*] in a .pdf? > >> > >> Cheers, > >> Alexandre > >> > >> [*] e.g., http://objectprofile.com/roassal-screenshots.html > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing enthusiasm." > Winston Churchill -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 23, 2012