December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About morph layout

by dimitris chloupis

> 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. What does this mean ? You mean that the solution to the GUI should be web based (Js / Html5) ?

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by Sven Van Caekenberghe

On 24 Dec 2012, at 11:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. +10 > Now I think that Pharo delivers. We will continue. +100 Very well said, quotable material ! > Stef Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 24, 2012

[Pharo-project] Is there a simple example of how to create a GUI form in Pharo or Squeak?

by Frank Church

Is there a simple example of how to create a GUI form in Pharo or Squeak? I want to accomplish a simple task with a form: 1. Create a form with a button and edit control and 2 text areas. 2. Enter a value into the edit control. 3. Run a database query using the value in the edit control as a parameter and return the results in text area 1 4. Run a shell script using the value in the edit control as a parameter and return the results in text area 2 I have OpenDBX running successfully and I don't think using OSProcess and CommandShell will be that difficult. Creating the form is the part I don't know how to accomplish. I have done some searching and there seems to be a surprising dearth of info on how to create a simple GUI from scratch using Pharo or Squeak. -- Frank Church ======================= http://devblog.brahmancreations.com

Dec. 24, 2012

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