- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>>> Does Toolbuilder make sense? To me it looked like yet another compatibility >>> layer that does not bring anything (other than forcing anyone to use something >>> that has to be compabtible to MVC). >> >> It is quite powerful given that it can run OmniBrowser. > > Of course Omnibrowser makes it easy by not allowing anything else than what is > in MVC (e.g, Trees). For sake of correctness: ToolBuilder supports trees since at least Squeak 3.9, but probably earlier. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

On Nov 16, 2011, at 7:09 PM, Lukas Renggli wrote: >>>> where? >>>> Because we removed it. >>> >>> It is contained in the Polymorph packages in Pharo 1.3, but it missing >>> some and has additional other features compared to the version in >>> Squeak. >>> >>> I was asking because OmniBrowser in Squeak is now using ToolBuilder, >>> the code works with a few changes in Pharo 1.3 too. >> >> Does Toolbuilder make sense? To me it looked like yet another compatibility >> layer that does not bring anything (other than forcing anyone to use something >> that has to be compabtible to MVC). > > It is quite powerful given that it can run OmniBrowser. Of course Omnibrowser makes it easy by not allowing anything else than what is in MVC (e.g, Trees). > And the extra > layer makes UI building trivially testable. This is not possible when > directly using Morphs. > What we need is a seperation between Morph and the Widgets on top of Morphic. This than will likely include some layer, too. But keeping Toolbuilder if you have no MVC and Tweak is not really useful. > For Pharo I will rewrite the OB UI builder to directly generate an > optimized Polymorph GUI. This buys more us more flexibility. > .. like trees. -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Eliot Miranda

On Wed, Nov 16, 2011 at 2:13 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > > > In general it abstracts away the specific UI used to present a tool and > I'd say that was generally useful. Anyone wanting to experiment with a > novel UI could benefit from ToolBuilder. In Squeak trunk there's even the > ability to test it against Morphic and MVC. MVC is still useful for those > trying to build minimal images. > > > MVC was removed in Pharo in 1.1... > Thta's not the point. ToolBuilder has backends for Morphic and MVC but one could add e.g. a backend for a native window/widget set, etc. The point is that it abstracts away from the specific widget/window set used to build a tool allowing one to experiment and evolve the system. > > Why not make Morphic compact instead of keeping MVC? There is quite a lot > of code everywhere in Squeak > dealing with MVC compatibility.. very hard to clean up anything. E.g we > removed Paragraph... and merged > all multiple Paragraph classes of Morphic into one (called, ahh... > Paragraph). > > E.g. getting a new Canvas would for shure be much harder if we would have > kept MVC. > > > I've found ToolBuilder useful for constructing new UIs, editing > > existing ones and being able to follow actions without needing to know > > much about about Morphic. > > Why not make Morphic easy to use instead? Wasn't it supposed to be easy? > That's not the alternative, nor is it the rationale for ToolBuilder. A compact, easy-to-understand Morphic is orthogonal to the utility of ToolBuilder. > > Marcus > > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

> > In general it abstracts away the specific UI used to present a tool and I'd say that was generally useful. Anyone wanting to experiment with a novel UI could benefit from ToolBuilder. In Squeak trunk there's even the ability to test it against Morphic and MVC. MVC is still useful for those trying to build minimal images. > MVC was removed in Pharo in 1.1... Why not make Morphic compact instead of keeping MVC? There is quite a lot of code everywhere in Squeak dealing with MVC compatibility.. very hard to clean up anything. E.g we removed Paragraph... and merged all multiple Paragraph classes of Morphic into one (called, ahh... Paragraph). E.g. getting a new Canvas would for shure be much harder if we would have kept MVC. > I've found ToolBuilder useful for constructing new UIs, editing > existing ones and being able to follow actions without needing to know > much about about Morphic. Why not make Morphic easy to use instead? Wasn't it supposed to be easy? Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>>> where? >>> Because we removed it. >> >> It is contained in the Polymorph packages in Pharo 1.3, but it missing >> some and has additional other features compared to the version in >> Squeak. >> >> I was asking because OmniBrowser in Squeak is now using ToolBuilder, >> the code works with a few changes in Pharo 1.3 too. > > Does Toolbuilder make sense? To me it looked like yet another compatibility > layer that does not bring anything (other than forcing anyone to use something > that has to be compabtible to MVC). It is quite powerful given that it can run OmniBrowser. And the extra layer makes UI building trivially testable. This is not possible when directly using Morphs. For Pharo I will rewrite the OB UI builder to directly generate an optimized Polymorph GUI. This buys more us more flexibility. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Frank Shearar

On 16 November 2011 21:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Nov 16, 2011 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: >> >> >>> I was kind of surprised that ToolBuilder is still part of Pharo. >> >> >> >> where? >> >> Because we removed it. >> > >> > It is contained in the Polymorph packages in Pharo 1.3, but it missing >> > some and has additional other features compared to the version in >> > Squeak. >> > >> > I was asking because OmniBrowser in Squeak is now using ToolBuilder, >> > the code works with a few changes in Pharo 1.3 too. >> >> >> Does Toolbuilder make sense? To me it looked like yet another >> compatibility >> layer that does not bring anything (other than forcing anyone to use >> something >> that has to be compabtible to MVC). > > In general it abstracts away the specific UI used to present a tool and I'd > say that was generally useful. Â Anyone wanting to experiment with a novel UI > could benefit from ToolBuilder. Â In Squeak trunk there's even the ability to > test it against Morphic and MVC. Â MVC is still useful for those trying to > build minimal images. It's also really useful for someone who knows just enough about Morphic to not want to know anything more about Morphic to still knock up a half-decent UI. I've found ToolBuilder useful for constructing new UIs, editing existing ones and being able to follow actions without needing to know much about about Morphic. frank >> >> Â Â Â Â Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > > > -- > best, > Eliot >

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Eliot Miranda

On Wed, Nov 16, 2011 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: > > >>> I was kind of surprised that ToolBuilder is still part of Pharo. > >> > >> where? > >> Because we removed it. > > > > It is contained in the Polymorph packages in Pharo 1.3, but it missing > > some and has additional other features compared to the version in > > Squeak. > > > > I was asking because OmniBrowser in Squeak is now using ToolBuilder, > > the code works with a few changes in Pharo 1.3 too. > > > Does Toolbuilder make sense? To me it looked like yet another compatibility > layer that does not bring anything (other than forcing anyone to use > something > that has to be compabtible to MVC). > In general it abstracts away the specific UI used to present a tool and I'd say that was generally useful. Anyone wanting to experiment with a novel UI could benefit from ToolBuilder. In Squeak trunk there's even the ability to test it against Morphic and MVC. MVC is still useful for those trying to build minimal images. > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: >>> I was kind of surprised that ToolBuilder is still part of Pharo. >> >> where? >> Because we removed it. > > It is contained in the Polymorph packages in Pharo 1.3, but it missing > some and has additional other features compared to the version in > Squeak. > > I was asking because OmniBrowser in Squeak is now using ToolBuilder, > the code works with a few changes in Pharo 1.3 too. Does Toolbuilder make sense? To me it looked like yet another compatibility layer that does not bring anything (other than forcing anyone to use something that has to be compabtible to MVC). Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] SystemChangeNotifier and Traits

by Eliot Miranda

On Wed, Nov 16, 2011 at 1:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > + 1 > > and we should remove the old ones and a lot of old abstraction > MethodReference, > PseudoClass, FilePackage, and a lot more > I hope that we will get into that mode soon. > PseudoClass, FilePackage, may indeed be poor. But IMO MethodReference is central and extremely useful. > Stef > > On Nov 16, 2011, at 3:55 PM, Fernando Olivero wrote: > > > Please note that eventually the system is going to be using solely > > System announcements, instead of the old mechanism in place right now. > > > > Did you try hooking up to the SystemAnnouncements? > > > > For examples, check out Nautius. > > > > Fernando > > > > > > > > On Tue, Nov 15, 2011 at 9:02 PM, ezequiel lamonica > > <lamonicaezequiel(a)gmail.com> wrote: > >> Hello again, > >> > >> Now the problem is when I create a class that use Traits, > >> SystemChangeNotifier sends two messages to report this creation: 1st for > >> class added without traits, and 2nd for class modified to use this > trait. > >> And this last message has Object as old class instead of ClassForTesting > >> without traits. > >> > >> For example: > >> > >> Object subclass: #ClassForTesting > >> uses: TSortable > >> instanceVariableNames: 'a' > >> classVariableNames: '' > >> poolDictionaries: '' > >> category: 'OOSCM-ClientImageTest' > >> > >> > >> Can I change those messages to use only one message that includes > traits? Is > >> not this better? > >> > >> What do you suggest? > >> > >> > >> > >> ----- > >> eze > >> -- > >> View this message in context: > http://forum.world.st/SystemChangeNotifier-and-Traits-tp4073962p4073962.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > >> > > > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>> I was kind of surprised that ToolBuilder is still part of Pharo. > > where? > Because we removed it. It is contained in the Polymorph packages in Pharo 1.3, but it missing some and has additional other features compared to the version in Squeak. I was asking because OmniBrowser in Squeak is now using ToolBuilder, the code works with a few changes in Pharo 1.3 too. >> Are there any users? Are there any plans to update it to match the >> version of Squeak? Is it encouraged to build UIs with ToolBuilder? > > no Â :) > We were brainstorming on valueHolder, Spec and UIBuilder a la VW with Benjamin and we got the > conclusions: > Â Â Â Â Specs are cool because the same application Model can propose multiple spec That has nothing to do with specs though, there are many other ways of how multiple views can work with or provided by the same model. In my experience specs often lack the necessary dynamics to build useful UIs. So a lot of glue code is necessary to assemble the different parts. In the end I find it more convenient to just use the glue code (like in Seaside or ToolBuilder). > Â Â Â Â valueHolder are the building brick to be able to reuse the application model UI logic (and not just the UI widgets). I do not understand that point. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011