March 2012 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Dale Henrichs

Philippe, Wouldn't it be more correct to say "we don't use Metacello"? Dale ----- Original Message ----- | From: "Philippe Marschall" <philippe.marschall(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: "Pharo mailing list list" <pharo-users(a)lists.gforge.inria.fr> | Sent: Monday, March 5, 2012 11:43:32 PM | Subject: Re: [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached) | | 2012/3/5 Lukas Renggli <renggli(a)gmail.com>: | >> There has been continuous problems with OmniBrowser across | >> multiple platforms (another example of a project where the | >> maintainer doesn't use metacello) and that has caused problems in | >> Seaside, because the seaside maintainers insist that OB be | >> included in the core ... so I disagree with their decision, but | >> it is their decision ... | > | > Uhh? No! Nothing in Seaside depends on OB. | > | > We like OB and we use it in our development images. This is all. | | Yes, but we don't use Metacello to build them. | | I'm cool with switching the default adaptor to Zinc if that makes | life easier. | | Cheers | Philippe | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

March 6, 2012

Re: [Pharo-users] using tree morphs

by Alain Plantec

can I get your code (from an attached change set as an example), it would be cool to make another example out of this. btw, I will answer to your questions Cheers Alain Le 06/03/2012 00:13, Alexis Parseghian a Ã©crit : > I've been playing with MorphTree et al. for the past few days, trying > to understand how they work. Reading the example code in > Morphic-MorphTreeWidget-Examples helped. I've also been trying to > figure out the Settings Browser, but this one I have a hard time following :( > > Anyway, I think I've got the basics now : I instantiate a > MorphTreeMorph when building my window in an subclass of a > MorphTreeModel. The contents of my model's list get wrapped in the > appropriate MorphTreeNodeModel subclasses. > > I can get the tree to display *what* I want. My problem is with the > *how* ; more specifically, how to get the columns right. > > * the first column always displays correctly, with or without an > expander (and in the latter case, expanded or not). > * the following columns have the text overlapping their left-side > resizer by about half a character. > * subsequent columns display off their vertical boundaries (to the > right), seemingly depending on the length of the preceeding column. > Same as if there were no columns but just morphs abutted to one > another. Manually resizing the previous column to contain the longest > text gets me back to the previous case (half a char too much to the > left). In other words, if I'm guessing right, the column clips its > contents /visually/, but not in relation to their /reported width/. > > I'm pretty sure there's something really basic I've missed in the > layout, but I can't figure it out from the example code nor the > classes' protocols. > > Any hints ? > > Thanks. > > My code: > > * the root list is a collection of associations 'string' -> article instance > * I'm building a view with the category (expandable) in the first > column. Once expanded, it shows the article's properties in columns. > > CategoriesAndArticlesTree(MorphTreeModel)>>buildTree > | treeMorph | > treeMorph := (self treeMorphClass on: self) > columns: { > MorphTreeColumn new rowMorphGetSelector: > #categoryOrAuthor. > MorphTreeColumn new > rowMorphGetSelector: #title; > headerButtonLabel: 'Title' font: nil. > MorphTreeColumn new rowMorphGetSelector: #issue. > MorphTreeColumn new rowMorphGetSelector: #foo > }. > treeMorph > hResizing: #spaceFill; vResizing: #spaceFill; > withHLines: true; > makeLastColumnUnbounded; > resizerWidth: 1. > ^ (treeMorph buildContents ) > CategoriesAndArticlesTree>>rootNodeClassFromItem: anItem > ^ CategoriesTreeNode > > CategoriesTreeNode(MorphTreeNodeModel)>>categoryOrAuthor > ^ self theme builder newLabel: item key > CategoriesTreeNode>>childNodeClassFromItem: anItem > ^ ArticlesTreeNode > CategoriesTreeNode>>childrenItems > ^ item value > the other column-related selectors are implemented and return a nil. > > ArticlesTreeNode(MorphTreeNodeModel) implements the column-related > selectors by returning the appropriate article property wrapped in a > label. > ArticlesTreeNode>>categoryOrAuthor > ^ self theme builder newLabel: item author > ArticlesTreeNode>>foo > ^ self theme builder newLabel: 'foo' >

March 6, 2012

Re: [Pharo-users] using tree morphs

by Alain Plantec

Le 06/03/2012 12:35, StÃ©phane Ducasse a Ã©crit : > Hi alexis > > pay attention that (not sure that this is still the case) but alain used subclassing for setting browser while I would have used > composition. it is still the case :( and it has to be fixed > To me the setting browser is not a tree but composed by a tree. yes Alain > > Alain will certainly reply to all your questions. > > Stef

March 6, 2012

Re: [Pharo-users] using tree morphs

by Alain Plantec

Le 06/03/2012 07:49, S Krish a Ã©crit : > Pay close attention to the example for > Class PackageTreeExample > > it uses: method #rootNodeClassFromItem: to display its children > derived from #rootItems > > It picks up each of the node to display through: thereafter from the > various node classes it uses: All Nodes class should be a subclass of > PackageAbstractNodeExample > > #childNodeClassFromItem: and #childrenItems > > It is a beautiful nearly perfect tree morph, I have every used across > all UI from VC++/ VW/ VA / Java.. > > ouah! thanks, cool to read that :) Alain

March 6, 2012

Re: [Pharo-users] using tree morphs

by StÃ©phane Ducasse

Hi alexis pay attention that (not sure that this is still the case) but alain used subclassing for setting browser while I would have used composition. To me the setting browser is not a tree but composed by a tree. Alain will certainly reply to all your questions. Stef

March 6, 2012

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Sven Van Caekenberghe

On 06 Mar 2012, at 08:43, Philippe Marschall wrote: > 2012/3/5 Lukas Renggli <renggli(a)gmail.com>: >>> There has been continuous problems with OmniBrowser across multiple platforms (another example of a project where the maintainer doesn't use metacello) and that has caused problems in Seaside, because the seaside maintainers insist that OB be included in the core ... so I disagree with their decision, but it is their decision ... >> >> Uhh? No! Nothing in Seaside depends on OB. >> >> We like OB and we use it in our development images. This is all. > > Yes, but we don't use Metacello to build them. > > I'm cool with switching the default adaptor to Zinc if that makes life easier. This is a configuration issue. >From my point of view, as author of Zn, I can only say that I am very happy with the collaboration and openness of the Seaside developers to adopt Zn. They tried and used Zn as soon as it became available, it was included in builds and distributions, and there are enough abstraction in place to let people use whatever server they want. What should be the default is not for me to say, although it would make some sense on certain Pharo builds. Sven

March 6, 2012

Re: [Pharo-users] using tree morphs

by S Krish

Pay close attention to the example for Class PackageTreeExample it uses: method #rootNodeClassFromItem: to display its children derived from #rootItems It picks up each of the node to display through: thereafter from the various node classes it uses: All Nodes class should be a subclass of PackageAbstractNodeExample #childNodeClassFromItem: and #childrenItems It is a beautiful nearly perfect tree morph, I have every used across all UI from VC++/ VW/ VA / Java.. study the abstract super class.. a bit and debug through the example a bit more.. On 3/6/12, Alexis Parseghian <a.parseg(a)gmail.com> wrote: > I've been playing with MorphTree et al. for the past few days, trying > to understand how they work. Reading the example code in > Morphic-MorphTreeWidget-Examples helped. I've also been trying to > figure out the Settings Browser, but this one I have a hard time following > :( > > Anyway, I think I've got the basics now : I instantiate a > MorphTreeMorph when building my window in an subclass of a > MorphTreeModel. The contents of my model's list get wrapped in the > appropriate MorphTreeNodeModel subclasses. > > I can get the tree to display *what* I want. My problem is with the > *how* ; more specifically, how to get the columns right. > > * the first column always displays correctly, with or without an > expander (and in the latter case, expanded or not). > * the following columns have the text overlapping their left-side > resizer by about half a character. > * subsequent columns display off their vertical boundaries (to the > right), seemingly depending on the length of the preceeding column. > Same as if there were no columns but just morphs abutted to one > another. Manually resizing the previous column to contain the longest > text gets me back to the previous case (half a char too much to the > left). In other words, if I'm guessing right, the column clips its > contents /visually/, but not in relation to their /reported width/. > > I'm pretty sure there's something really basic I've missed in the > layout, but I can't figure it out from the example code nor the > classes' protocols. > > Any hints ? > > Thanks. > > My code: > > * the root list is a collection of associations 'string' -> article instance > * I'm building a view with the category (expandable) in the first > column. Once expanded, it shows the article's properties in columns. > > CategoriesAndArticlesTree(MorphTreeModel)>>buildTree > | treeMorph | > treeMorph := (self treeMorphClass on: self) > columns: { > MorphTreeColumn new rowMorphGetSelector: > #categoryOrAuthor. > MorphTreeColumn new > rowMorphGetSelector: #title; > headerButtonLabel: 'Title' font: nil. > MorphTreeColumn new rowMorphGetSelector: #issue. > MorphTreeColumn new rowMorphGetSelector: #foo > }. > treeMorph > hResizing: #spaceFill; vResizing: #spaceFill; > withHLines: true; > makeLastColumnUnbounded; > resizerWidth: 1. > ^ (treeMorph buildContents ) > CategoriesAndArticlesTree>>rootNodeClassFromItem: anItem > ^ CategoriesTreeNode > > CategoriesTreeNode(MorphTreeNodeModel)>>categoryOrAuthor > ^ self theme builder newLabel: item key > CategoriesTreeNode>>childNodeClassFromItem: anItem > ^ ArticlesTreeNode > CategoriesTreeNode>>childrenItems > ^ item value > the other column-related selectors are implemented and return a nil. > > ArticlesTreeNode(MorphTreeNodeModel) implements the column-related > selectors by returning the appropriate article property wrapped in a > label. > ArticlesTreeNode>>categoryOrAuthor > ^ self theme builder newLabel: item author > ArticlesTreeNode>>foo > ^ self theme builder newLabel: 'foo' > >

March 6, 2012

using tree morphs

by Alexis Parseghian

I've been playing with MorphTree et al. for the past few days, trying to understand how they work. Reading the example code in Morphic-MorphTreeWidget-Examples helped. I've also been trying to figure out the Settings Browser, but this one I have a hard time following :( Anyway, I think I've got the basics now : I instantiate a MorphTreeMorph when building my window in an subclass of a MorphTreeModel. The contents of my model's list get wrapped in the appropriate MorphTreeNodeModel subclasses. I can get the tree to display *what* I want. My problem is with the *how* ; more specifically, how to get the columns right. * the first column always displays correctly, with or without an expander (and in the latter case, expanded or not). * the following columns have the text overlapping their left-side resizer by about half a character. * subsequent columns display off their vertical boundaries (to the right), seemingly depending on the length of the preceeding column. Same as if there were no columns but just morphs abutted to one another. Manually resizing the previous column to contain the longest text gets me back to the previous case (half a char too much to the left). In other words, if I'm guessing right, the column clips its contents /visually/, but not in relation to their /reported width/. I'm pretty sure there's something really basic I've missed in the layout, but I can't figure it out from the example code nor the classes' protocols. Any hints ? Thanks. My code: * the root list is a collection of associations 'string' -> article instance * I'm building a view with the category (expandable) in the first column. Once expanded, it shows the article's properties in columns. CategoriesAndArticlesTree(MorphTreeModel)>>buildTree Â Â Â Â | treeMorph | Â Â Â Â treeMorph := (self treeMorphClass on: self) Â Â Â Â Â Â Â Â columns: { Â Â Â Â Â Â Â Â Â Â Â Â MorphTreeColumn new rowMorphGetSelector: #categoryOrAuthor. Â Â Â Â Â Â Â Â Â Â Â Â MorphTreeColumn new Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rowMorphGetSelector: #title; Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â headerButtonLabel: 'Title' font: nil. Â Â Â Â Â Â Â Â Â Â Â Â MorphTreeColumn new rowMorphGetSelector: #issue. Â Â Â Â Â Â Â Â Â Â Â Â MorphTreeColumn new rowMorphGetSelector: #foo Â Â Â Â Â Â Â Â }. Â Â Â Â treeMorph Â Â Â Â Â Â Â Â hResizing: #spaceFill; vResizing: #spaceFill; Â Â Â Â Â Â Â Â withHLines: true; Â Â Â Â Â Â Â Â makeLastColumnUnbounded; Â Â Â Â Â Â Â Â resizerWidth: 1. Â Â Â Â ^ (treeMorph buildContents ) CategoriesAndArticlesTree>>rootNodeClassFromItem: anItem Â Â Â Â ^ CategoriesTreeNode CategoriesTreeNode(MorphTreeNodeModel)>>categoryOrAuthor Â Â Â Â ^ self theme builder newLabel: item key CategoriesTreeNode>>childNodeClassFromItem: anItem Â Â Â Â ^ ArticlesTreeNode CategoriesTreeNode>>childrenItems Â Â Â Â ^ item value the other column-related selectors are implemented and return a nil. ArticlesTreeNode(MorphTreeNodeModel) implements the column-related selectors by returning the appropriate article property wrapped in a label. ArticlesTreeNode>>categoryOrAuthor Â Â Â Â ^ self theme builder newLabel: item author ArticlesTreeNode>>foo Â Â Â Â ^ self theme builder newLabel: 'foo'

March 5, 2012

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Dale Henrichs

If you have questions about metacello, I am willing to answer them... Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: "Pharo mailing list list" <pharo-users(a)lists.gforge.inria.fr> | Sent: Monday, March 5, 2012 12:18:23 PM | Subject: Re: [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached) | | > There has been continuous problems with OmniBrowser across multiple | > platforms (another example of a project where the maintainer | > doesn't use metacello) and that has caused problems in Seaside, | > because the seaside maintainers insist that OB be included in the | > core ... so I disagree with their decision, but it is their | > decision ... | | Uhh? No! Nothing in Seaside depends on OB. | | We like OB and we use it in our development images. This is all. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

March 5, 2012

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Dale Henrichs

If you want to discuss configuration issues, I am all ears... Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: "Pharo mailing list list" <pharo-users(a)lists.gforge.inria.fr> | Sent: Monday, March 5, 2012 12:18:23 PM | Subject: Re: [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached) | | > There has been continuous problems with OmniBrowser across multiple | > platforms (another example of a project where the maintainer | > doesn't use metacello) and that has caused problems in Seaside, | > because the seaside maintainers insist that OB be included in the | > core ... so I disagree with their decision, but it is their | > decision ... | | Uhh? No! Nothing in Seaside depends on OB. | | We like OB and we use it in our development images. This is all. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

March 5, 2012