MVP
Locked
12
12
 
|
Hello all,
I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill |
|
|
I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite
view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly.
Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. Sleep calls... Bill From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, February 04, 2012 6:36 PM To: [hidden email] Subject: [Pharo-project] MVP
Hello all,
I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill |
|
|
More:
proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, February 04, 2012 9:25 PM To: [hidden email] Subject: Re: [Pharo-project] MVP
I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual
view editor, and second, can be surprisingly easy to code directly.
Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. Sleep calls... Bill From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, February 04, 2012 6:36 PM To: [hidden email] Subject: [Pharo-project] MVP
Hello all,
I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill |
|
|
if you want to have a look at what we are doing with benjamin you can have a look at
Spec Yesterday benjamin added inputField support and rewrote the changeSorter. Stef On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: > More: > > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. > > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 9:25 PM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. > > Sleep calls... > > Bill > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 6:36 PM > To: [hidden email] > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. > > Bill |
Spec.pdf (904K) |
|
Stef,
Oops - read in the wrong order (I just asked what spec might be based on a different message from you). It seems clear from the current context that it is something I should indeed review. Bill
From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]]
Sent: Sunday, February 05, 2012 2:56 AM To: [hidden email] Subject: Re: [Pharo-project] MVP if you want to have a look at what we are doing with benjamin you can have a look at
Spec Yesterday benjamin added inputField support and rewrote the changeSorter. Stef On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: > More: > > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. > > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 9:25 PM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. > > Sleep calls... > > Bill > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 6:36 PM > To: [hidden email] > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. > > Bill |
|
|
In reply to this post by Stéphane Ducasse
Stef,
I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. Any ideas? Bill From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]]
Sent: Sunday, February 05, 2012 2:56 AM To: [hidden email] Subject: Re: [Pharo-project] MVP if you want to have a look at what we are doing with benjamin you can have a look at
Spec Yesterday benjamin added inputField support and rewrote the changeSorter. Stef On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: > More: > > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. > > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 9:25 PM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. > > Sleep calls... > > Bill > > > > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] > Sent: Saturday, February 04, 2012 6:36 PM > To: [hidden email] > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. > > Bill |
|
|
<base href="x-msg://907/">I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages)
Keep me in touch, Ben On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote:
|
|
|
Ben,
Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? Bill From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]]
Sent: Sunday, March 04, 2012 6:38 PM To: [hidden email] Subject: Re: [Pharo-project] MVP I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages)
Keep me in touch,
Ben
On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote:
|
|
|
<base href="x-msg://909/">Everything has been moved in ss3.gemstone.com/ss/Spec :)
Ben On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote:
|
|
|
Ben,
Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? Bill From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]]
Sent: Sunday, March 04, 2012 6:53 PM To: [hidden email] Subject: Re: [Pharo-project] MVP Everything has been moved in
ss3.gemstone.com/ss/Spec :)
Ben
On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote:
|
|
|
In reply to this post by Schwab,Wilhelm K
Bill, since you working on it, please consider following.
Models & widgets: - all widgets which require a model/state, should require a specific protocol for communicating with them. - a "real" model object may not support given protocol directly, and for adapting it, there should be a model/value adaptors. From design point of view, it means that widget implementation should be free of things like we see in PluggableXYZMorph, which turned into a storage of bunch of selectors and code into spahetti of UI logic and model logic. All widgets should just send messages to model in a form: model doSomething or model askSomething but not: model perform: myOnClickBigButtonSelector If there is not possible to connect widget and model directly, we should provide a model wrappers, which then could carry those numerous 'myOnClickBigButtonSelector' or block closures, connectors, whatever. Like that, a widget designer can clearly tell , what he wants from widget's model, what inputs his widget expects and rest is not of his concern. No any onClickSelector ifNil: [ yadda yadda ] ifNotNil: [ (model undestands: onClickSelector ) ifTrue: [ model perform: onClickSelector ] ].... this should be replaced by appropriate model adaptors, value holders etc , so widget may keep own code clean. We had discussions before, like why don't use blocks instead of selectors. And the answer was that it is easier to find implementors/navigate connections with symbols than blocks.. Which is true. Unless model(s) could have a built-in support for navigating and finding real guy behind the scenes, who responsible for taking actions etc. And i think this is much more appropriate than manually traverse through the hashes of selectors from a button nested into multiple levels of widgets, and models connected /nested in hierarchy too.. About layouts and layouts managers. It's kind of fine to have proportional layouts, but it doesn't solves all needs. Sometimes we want to "put it here" and "i don't give a shit about layouts". I dealt with nested layout since Delphi, and while they serve well most of the times, sometimes it is very hard to convince designed that his design is not really fits into out technical world, simply because you cannout "put it here" and designer "don't give a shit about layouts". :) So, people invented workarounds, like in modern browsers we have absolute/fixed/relative positioning and z-levels aka layers. Another approach is to control layout via anchors. I did some experiments with it not long ago, and i think it is quite promising, except that more thought needed how to organically merge this with traditional layouts. Anyways, here the link to original discussion: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-April/046473.html (and somewhere there must be the code) On 5 February 2012 04:25, Schwab,Wilhelm K <[hidden email]> wrote: > I'm still a little overwhelmed, but I see attention to layout; this has been > a BIG stumbling block for me in my efforts to bring MVP to Pharo. I > recommend using nested composite view/presenter pairs for most layout. > First, it lends itself well to an eventual view editor, and second, can be > surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained > table-like elements, but the real workhorses are proportional layouts, which > can be set either horizontal or vertical. By nesting them, very complicate > behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. > Pharo/morphic layout works great for children of the top level, but after > that, I can't get reliable results. > > Sleep calls... > > Bill > > > > ________________________________ > From: [hidden email] > [[hidden email]] on behalf of Schwab,Wilhelm K > [[hidden email]] > Sent: Saturday, February 04, 2012 6:36 PM > To: [hidden email] > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of > MVP. I am **slowly** working on a framework for it, but would be glad to > be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should > work "out of the box." Models can include value holders, value adapters, > converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try > to package and make available. If nothing else, they will have value in > seeding discussion if not be directly usable. More to come. > > Bill > > > > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Schwab,Wilhelm K
bill
thanks for the catch. I updated the document. Gofer new url: 'http://ss3.gemstone.com/ss/Spec'; package: 'ConfigurationOfSpec'; load ConfigurationOfSpec project load: #stable Stef On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: > Ben, > > Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? > > Bill > > > > > From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] > Sent: Sunday, March 04, 2012 6:53 PM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > Everything has been moved in ss3.gemstone.com/ss/Spec :) > > > Ben > > On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: > >> Ben, >> >> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >> >> Bill >> >> >> >> >> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >> Sent: Sunday, March 04, 2012 6:38 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] MVP >> >> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >> >> >> Keep me in touch, >> >> Ben >> >> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>> >>> Any ideas? >>> >>> Bill >>> >>> >>> >>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>> Sent: Sunday, February 05, 2012 2:56 AM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] MVP >>> >>> if you want to have a look at what we are doing with benjamin you can have a look at >>> Spec >>> >>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>> >>> Stef >>> >>> >>> >>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>> >>> > More: >>> > >>> > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>> > >>> > >>> > >>> > >>> > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>> > Sent: Saturday, February 04, 2012 9:25 PM >>> > To: [hidden email] >>> > Subject: Re: [Pharo-project] MVP >>> > >>> > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>> > >>> > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>> > >>> > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>> > >>> > Sleep calls... >>> > >>> > Bill >>> > >>> > >>> > >>> > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>> > Sent: Saturday, February 04, 2012 6:36 PM >>> > To: [hidden email] >>> > Subject: [Pharo-project] MVP >>> > >>> > Hello all, >>> > >>> > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>> > >>> > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>> > >>> > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>> > >>> > Bill |
|
|
Stef,
Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? More fiddling to come. Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] Sent: Monday, March 05, 2012 3:26 AM To: [hidden email] Subject: Re: [Pharo-project] MVP bill thanks for the catch. I updated the document. Gofer new url: 'http://ss3.gemstone.com/ss/Spec'; package: 'ConfigurationOfSpec'; load ConfigurationOfSpec project load: #stable Stef On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: > Ben, > > Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? > > Bill > > > > > From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] > Sent: Sunday, March 04, 2012 6:53 PM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > Everything has been moved in ss3.gemstone.com/ss/Spec :) > > > Ben > > On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: > >> Ben, >> >> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >> >> Bill >> >> >> >> >> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >> Sent: Sunday, March 04, 2012 6:38 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] MVP >> >> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >> >> >> Keep me in touch, >> >> Ben >> >> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>> >>> Any ideas? >>> >>> Bill >>> >>> >>> >>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>> Sent: Sunday, February 05, 2012 2:56 AM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] MVP >>> >>> if you want to have a look at what we are doing with benjamin you can have a look at >>> Spec >>> >>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>> >>> Stef >>> >>> >>> >>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>> >>> > More: >>> > >>> > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>> > >>> > >>> > >>> > >>> > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>> > Sent: Saturday, February 04, 2012 9:25 PM >>> > To: [hidden email] >>> > Subject: Re: [Pharo-project] MVP >>> > >>> > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>> > >>> > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>> > >>> > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>> > >>> > Sleep calls... >>> > >>> > Bill >>> > >>> > >>> > >>> > From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>> > Sent: Saturday, February 04, 2012 6:36 PM >>> > To: [hidden email] >>> > Subject: [Pharo-project] MVP >>> > >>> > Hello all, >>> > >>> > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>> > >>> > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>> > >>> > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>> > >>> > Bill |
|
|
In reply to this post by Stéphane Ducasse
On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. Isn't Shout enabled in 1.4? > In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. > > Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? In the past you have shown to want very stable, out of the box usable, "I can not do anything wrong" kind of software. Does it then make sense to use Nautilus, which is in active development? Marcus -- Marcus Denker -- http://marcusdenker.de |
|
|
I do need stability, but there is nothing wrong with dabbling in the unstable to test something like spec.
________________________________________ From: [hidden email] [[hidden email]] on behalf of Marcus Denker [[hidden email]] Sent: Monday, March 05, 2012 4:10 AM To: [hidden email] Subject: Re: [Pharo-project] MVP On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. Isn't Shout enabled in 1.4? > In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. > > Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? In the past you have shown to want very stable, out of the box usable, "I can not do anything wrong" kind of software. Does it then make sense to use Nautilus, which is in active development? Marcus -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Schwab,Wilhelm K
spec is not made to work on 1.3
Stef On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. > > Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? > > More fiddling to come. > > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] > Sent: Monday, March 05, 2012 3:26 AM > To: [hidden email] > Subject: Re: [Pharo-project] MVP > > bill > > thanks for the catch. I updated the document. > > > Gofer new > url: 'http://ss3.gemstone.com/ss/Spec'; > package: 'ConfigurationOfSpec'; > load > > ConfigurationOfSpec project load: #stable > > > Stef > > > On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: > >> Ben, >> >> Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? >> >> Bill >> >> >> >> >> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >> Sent: Sunday, March 04, 2012 6:53 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] MVP >> >> Everything has been moved in ss3.gemstone.com/ss/Spec :) >> >> >> Ben >> >> On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: >> >>> Ben, >>> >>> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >>> >>> Bill >>> >>> >>> >>> >>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>> Sent: Sunday, March 04, 2012 6:38 PM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] MVP >>> >>> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >>> >>> >>> Keep me in touch, >>> >>> Ben >>> >>> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>>> >>>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>>> >>>> Any ideas? >>>> >>>> Bill >>>> >>>> >>>> >>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>> Sent: Sunday, February 05, 2012 2:56 AM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] MVP >>>> >>>> if you want to have a look at what we are doing with benjamin you can have a look at >>>> Spec >>>> >>>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>>> >>>> Stef >>>> >>>> >>>> >>>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>>> >>>>> More: >>>>> >>>>> proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>>>> >>>>> >>>>> >>>>> >>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>> Sent: Saturday, February 04, 2012 9:25 PM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] MVP >>>>> >>>>> I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>>>> >>>>> Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>>>> >>>>> There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>>>> >>>>> Sleep calls... >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>> Sent: Saturday, February 04, 2012 6:36 PM >>>>> To: [hidden email] >>>>> Subject: [Pharo-project] MVP >>>>> >>>>> Hello all, >>>>> >>>>> I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>>>> >>>>> Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>>>> >>>>> I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>>>> >>>>> Bill > > > |
|
|
The problem is that we improved a lot he morphic layout in 1.4, and Spec is based on that. So most probably it doesn't work in 1.3 (and I didn't put effort in this direction, and will probably not)
Try Nautilus instead of OB ^^ Again, we improved the system, but we are not maintaining OB, so it could be not up to date. Have fun with Spec, Ben On Mar 5, 2012, at 1:41 PM, Stéphane Ducasse wrote: > spec is not made to work on 1.3 > > Stef > > On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. >> >> Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? >> >> More fiddling to come. >> >> Bill >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >> Sent: Monday, March 05, 2012 3:26 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] MVP >> >> bill >> >> thanks for the catch. I updated the document. >> >> >> Gofer new >> url: 'http://ss3.gemstone.com/ss/Spec'; >> package: 'ConfigurationOfSpec'; >> load >> >> ConfigurationOfSpec project load: #stable >> >> >> Stef >> >> >> On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: >> >>> Ben, >>> >>> Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? >>> >>> Bill >>> >>> >>> >>> >>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>> Sent: Sunday, March 04, 2012 6:53 PM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] MVP >>> >>> Everything has been moved in ss3.gemstone.com/ss/Spec :) >>> >>> >>> Ben >>> >>> On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: >>> >>>> Ben, >>>> >>>> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>> Sent: Sunday, March 04, 2012 6:38 PM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] MVP >>>> >>>> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >>>> >>>> >>>> Keep me in touch, >>>> >>>> Ben >>>> >>>> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >>>> >>>>> Stef, >>>>> >>>>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>>>> >>>>> Any ideas? >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>>> Sent: Sunday, February 05, 2012 2:56 AM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] MVP >>>>> >>>>> if you want to have a look at what we are doing with benjamin you can have a look at >>>>> Spec >>>>> >>>>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>>>> >>>>>> More: >>>>>> >>>>>> proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>> Sent: Saturday, February 04, 2012 9:25 PM >>>>>> To: [hidden email] >>>>>> Subject: Re: [Pharo-project] MVP >>>>>> >>>>>> I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>>>>> >>>>>> Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>>>>> >>>>>> There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>>>>> >>>>>> Sleep calls... >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>> Sent: Saturday, February 04, 2012 6:36 PM >>>>>> To: [hidden email] >>>>>> Subject: [Pharo-project] MVP >>>>>> >>>>>> Hello all, >>>>>> >>>>>> I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>>>>> >>>>>> Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>>>>> >>>>>> I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>>>>> >>>>>> Bill >> >> >> > > |
Nautilus would be a nice GSoC project (was MVP)
|
|
Hi Benjamin,
Are you thinking about applying with Nautilus on this Google Summer of Code? I think your work is to be supported more, and applying to the GSoC stipendium is a nice opportunity, not to be missed :) Best regards Janko Dne 05. 03. 2012 17:46, piše Benjamin: > The problem is that we improved a lot he morphic layout in 1.4, and Spec is based on that. So most probably it doesn't work in 1.3 (and I didn't put effort in this direction, and will probably not) > > > Try Nautilus instead of OB ^^ > Again, we improved the system, but we are not maintaining OB, so it could be not up to date. > > > Have fun with Spec, > > Ben > > On Mar 5, 2012, at 1:41 PM, Stéphane Ducasse wrote: > >> spec is not made to work on 1.3 >> >> Stef >> >> On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. >>> >>> Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? >>> >>> More fiddling to come. >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>> Sent: Monday, March 05, 2012 3:26 AM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] MVP >>> >>> bill >>> >>> thanks for the catch. I updated the document. >>> >>> >>> Gofer new >>> url: 'http://ss3.gemstone.com/ss/Spec'; >>> package: 'ConfigurationOfSpec'; >>> load >>> >>> ConfigurationOfSpec project load: #stable >>> >>> >>> Stef >>> >>> >>> On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: >>> >>>> Ben, >>>> >>>> Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>> Sent: Sunday, March 04, 2012 6:53 PM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] MVP >>>> >>>> Everything has been moved in ss3.gemstone.com/ss/Spec :) >>>> >>>> >>>> Ben >>>> >>>> On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: >>>> >>>>> Ben, >>>>> >>>>> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> >>>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>>> Sent: Sunday, March 04, 2012 6:38 PM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] MVP >>>>> >>>>> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >>>>> >>>>> >>>>> Keep me in touch, >>>>> >>>>> Ben >>>>> >>>>> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >>>>> >>>>>> Stef, >>>>>> >>>>>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>>>> Sent: Sunday, February 05, 2012 2:56 AM >>>>>> To: [hidden email] >>>>>> Subject: Re: [Pharo-project] MVP >>>>>> >>>>>> if you want to have a look at what we are doing with benjamin you can have a look at >>>>>> Spec >>>>>> >>>>>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>>>>> >>>>>>> More: >>>>>>> >>>>>>> proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>> Sent: Saturday, February 04, 2012 9:25 PM >>>>>>> To: [hidden email] >>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>> >>>>>>> I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>>>>>> >>>>>>> Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>>>>>> >>>>>>> There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>>>>>> >>>>>>> Sleep calls... >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>> Sent: Saturday, February 04, 2012 6:36 PM >>>>>>> To: [hidden email] >>>>>>> Subject: [Pharo-project] MVP >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>>>>>> >>>>>>> Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>>>>>> >>>>>>> I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>>>>>> >>>>>>> Bill >>> >>> >>> >> >> > > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
Re: Nautilus would be a nice GSoC project (was MVP)
|
|
Why not :)
The thing is I do not know which steps have to be done to apply so :) Ben On Mar 5, 2012, at 5:54 PM, Janko Mivšek wrote: > Hi Benjamin, > > Are you thinking about applying with Nautilus on this Google Summer of > Code? I think your work is to be supported more, and applying to the > GSoC stipendium is a nice opportunity, not to be missed :) > > Best regards > Janko > > Dne 05. 03. 2012 17:46, piše Benjamin: >> The problem is that we improved a lot he morphic layout in 1.4, and Spec is based on that. So most probably it doesn't work in 1.3 (and I didn't put effort in this direction, and will probably not) >> >> >> Try Nautilus instead of OB ^^ >> Again, we improved the system, but we are not maintaining OB, so it could be not up to date. >> >> >> Have fun with Spec, >> >> Ben >> >> On Mar 5, 2012, at 1:41 PM, Stéphane Ducasse wrote: >> >>> spec is not made to work on 1.3 >>> >>> Stef >>> >>> On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>>> >>>> Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. >>>> >>>> Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? >>>> >>>> More fiddling to come. >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>> Sent: Monday, March 05, 2012 3:26 AM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] MVP >>>> >>>> bill >>>> >>>> thanks for the catch. I updated the document. >>>> >>>> >>>> Gofer new >>>> url: 'http://ss3.gemstone.com/ss/Spec'; >>>> package: 'ConfigurationOfSpec'; >>>> load >>>> >>>> ConfigurationOfSpec project load: #stable >>>> >>>> >>>> Stef >>>> >>>> >>>> On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: >>>> >>>>> Ben, >>>>> >>>>> Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> >>>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>>> Sent: Sunday, March 04, 2012 6:53 PM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] MVP >>>>> >>>>> Everything has been moved in ss3.gemstone.com/ss/Spec :) >>>>> >>>>> >>>>> Ben >>>>> >>>>> On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: >>>>> >>>>>> Ben, >>>>>> >>>>>> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>>>> Sent: Sunday, March 04, 2012 6:38 PM >>>>>> To: [hidden email] >>>>>> Subject: Re: [Pharo-project] MVP >>>>>> >>>>>> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >>>>>> >>>>>> >>>>>> Keep me in touch, >>>>>> >>>>>> Ben >>>>>> >>>>>> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >>>>>> >>>>>>> Stef, >>>>>>> >>>>>>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>>>>> Sent: Sunday, February 05, 2012 2:56 AM >>>>>>> To: [hidden email] >>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>> >>>>>>> if you want to have a look at what we are doing with benjamin you can have a look at >>>>>>> Spec >>>>>>> >>>>>>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>>>>>> >>>>>>>> More: >>>>>>>> >>>>>>>> proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>>> Sent: Saturday, February 04, 2012 9:25 PM >>>>>>>> To: [hidden email] >>>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>>> >>>>>>>> I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>>>>>>> >>>>>>>> Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>>>>>>> >>>>>>>> There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>>>>>>> >>>>>>>> Sleep calls... >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>>> Sent: Saturday, February 04, 2012 6:36 PM >>>>>>>> To: [hidden email] >>>>>>>> Subject: [Pharo-project] MVP >>>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>>>>>>> >>>>>>>> Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>>>>>>> >>>>>>>> I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>>>>>>> >>>>>>>> Bill >>>> >>>> >>>> >>> >>> >> >> >> > > -- > Janko Mivšek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > |
Re: Nautilus would be a nice GSoC project (was MVP)
|
|
Dne 05. 03. 2012 18:00, piše Benjamin:
> Why not :) > > The thing is I do not know which steps have to be done to apply so :) For start just describe here answering these questions: Project name Level (Beginner, Intermediate, Advanced) Description Technical Details Benefits to the Student Benefits to the Community Those are just ideas for now, but we need to be as detailed already. Later we can choose the mentor, second mentor etc. Best regards Janko > > > Ben > > On Mar 5, 2012, at 5:54 PM, Janko Mivšek wrote: > >> Hi Benjamin, >> >> Are you thinking about applying with Nautilus on this Google Summer of >> Code? I think your work is to be supported more, and applying to the >> GSoC stipendium is a nice opportunity, not to be missed :) >> >> Best regards >> Janko >> >> Dne 05. 03. 2012 17:46, piše Benjamin: >>> The problem is that we improved a lot he morphic layout in 1.4, and Spec is based on that. So most probably it doesn't work in 1.3 (and I didn't put effort in this direction, and will probably not) >>> >>> >>> Try Nautilus instead of OB ^^ >>> Again, we improved the system, but we are not maintaining OB, so it could be not up to date. >>> >>> >>> Have fun with Spec, >>> >>> Ben >>> >>> On Mar 5, 2012, at 1:41 PM, Stéphane Ducasse wrote: >>> >>>> spec is not made to work on 1.3 >>>> >>>> Stef >>>> >>>> On Mar 5, 2012, at 10:03 AM, Schwab,Wilhelm K wrote: >>>> >>>>> Stef, >>>>> >>>>> Thanks for the code! #stable does some things on 1.4, but I still got nowhere with 1.3. The big thing keeping me off of 1.4 is shout in the browsers - I *really* like syntax highlighting. In fairness, I have not looked at 1.4 in a week or so, so maybe that's been fixed. However, I can certainly run it to play around with spec. >>>>> >>>>> Even on 1.4, I got a DNU over groups; this time I had to add the noop to OB, which is apparently the default in 1.4?? >>>>> >>>>> More fiddling to come. >>>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>>> Sent: Monday, March 05, 2012 3:26 AM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] MVP >>>>> >>>>> bill >>>>> >>>>> thanks for the catch. I updated the document. >>>>> >>>>> >>>>> Gofer new >>>>> url: 'http://ss3.gemstone.com/ss/Spec'; >>>>> package: 'ConfigurationOfSpec'; >>>>> load >>>>> >>>>> ConfigurationOfSpec project load: #stable >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Mar 5, 2012, at 1:24 AM, Schwab,Wilhelm K wrote: >>>>> >>>>>> Ben, >>>>>> >>>>>> Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>>>> Sent: Sunday, March 04, 2012 6:53 PM >>>>>> To: [hidden email] >>>>>> Subject: Re: [Pharo-project] MVP >>>>>> >>>>>> Everything has been moved in ss3.gemstone.com/ss/Spec :) >>>>>> >>>>>> >>>>>> Ben >>>>>> >>>>>> On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: >>>>>> >>>>>>> Ben, >>>>>>> >>>>>>> Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [[hidden email]] on behalf of Benjamin [[hidden email]] >>>>>>> Sent: Sunday, March 04, 2012 6:38 PM >>>>>>> To: [hidden email] >>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>> >>>>>>> I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) >>>>>>> >>>>>>> >>>>>>> Keep me in touch, >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: >>>>>>> >>>>>>>> Stef, >>>>>>>> >>>>>>>> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] >>>>>>>> Sent: Sunday, February 05, 2012 2:56 AM >>>>>>>> To: [hidden email] >>>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>>> >>>>>>>> if you want to have a look at what we are doing with benjamin you can have a look at >>>>>>>> Spec >>>>>>>> >>>>>>>> Yesterday benjamin added inputField support and rewrote the changeSorter. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >>>>>>>> >>>>>>>>> More: >>>>>>>>> >>>>>>>>> proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>>>> Sent: Saturday, February 04, 2012 9:25 PM >>>>>>>>> To: [hidden email] >>>>>>>>> Subject: Re: [Pharo-project] MVP >>>>>>>>> >>>>>>>>> I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >>>>>>>>> >>>>>>>>> Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >>>>>>>>> >>>>>>>>> There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >>>>>>>>> >>>>>>>>> Sleep calls... >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]] >>>>>>>>> Sent: Saturday, February 04, 2012 6:36 PM >>>>>>>>> To: [hidden email] >>>>>>>>> Subject: [Pharo-project] MVP >>>>>>>>> >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >>>>>>>>> >>>>>>>>> Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >>>>>>>>> >>>>>>>>> I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >>>>>>>>> >>>>>>>>> Bill >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> -- >> Janko Mivšek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |