Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
March 2012
- 119 participants
- 1488 messages
Re: [Pharo-project] Looking for a package to do some statistics in Pharo
by Marcus Denker
O
>>
> Thanks.
> It's funny..
> btw, Marcus, is it really needed to update fetch script every time?
> i beleive this related to gforge, where you placing the base image ..
>
Yes, we wanted to have a snap shot evey 20 upates and at least test part
of the update process by updating that.
(keep in mind that *everything* not tested will break, e.g. updating 1.4000
to the current for sure broke, as it's not tested).
I changed it now, we now just update the last successful build directly from
jenkins. But this means we need to save the artefacts somewhere in case
we break something and have to go back... (but we will have that with the S3
uploader).
Marcus
--
Marcus Denker -- http://marcusdenker.de
March 5, 2012
Re: [Pharo-project] [ANN] Ideas for this year GSoC wanted
by askoh
Name: Search Indexing of Smalltalk image
Level: Intermediate
Possible mentor: Aik-Siong Koh
Possible second mentor: Ian Chai
Description
All Smalltalk development environments can now search for implementors,
senders or strings using brute force. The results are usually just listed
alphabetically. This project will use search technology to index and page
rank all the packages, classes, methods and comments in the image. Search
results will be returned quickly and ranked intelligently. It will be a
Search Engine for Smalltalk in Smalltalk. A search browser will be created
to accept search strings and return columns of hits for packages, classes,
methods and comments listed according to their page ranks. Time permitting,
an autocompletion capability will be implemented to suggest relevant methods
for code writing. The code will be made portable to all Smalltalk dialects.
Technical Details
The Anatomy of a Search Engine
http://infolab.stanford.edu/~backrub/google.html
Benefits to the Student
The student will learn the important areas of search technology and object
oriented programming. The student will experience creating something that is
immediately useful to all Smalltalk programmers.
Benefits to the Community
Fast and intelligent search of Smalltalk code will help the community
advance Smalltalk development even faster. Additional programming
capabilities can be built on top of the search capabillities.
--
View this message in context: http://forum.world.st/ANN-Ideas-for-this-year-GSoC-wanted-tp4434402p4445245…
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
March 5, 2012
Re: [Pharo-project] Looking for a package to do some statistics in Pharo
by Gastón Dall' Oglio
El 4 de marzo de 2012 22:38, Igor Stasenko <siguctua(a)gmail.com> escribió:
> 2012/3/5 Gastón Dall' Oglio <gaston.dalloglio(a)gmail.com>:
> > :) yes it's funny. Maybe in this video is not apreciated, but in projects
> > where there are many developers, this presentation of a repository log
> give
> > a quick view of the dinamic of work.
> >
> I can say more. It make me feels like i given a birth to something,
> which is then started to grow and bloom,
> tended and honed by others.
> This is very inspiring. My sincere thanks to you.
>
Thanks to you and the others developers of Pharo for your hard work :)
>
> But besides of sentiments, i don't think that such kind of
> presentation is very informative to those who did not participated
> directly.
>
Yes sure.
> It serves to give an impression, but impression is not knowledge. Less
> sentimental people need numbers :)
>
yes I agree.
Regards.
>
>
> > Regards.
> >
> > El 4 de marzo de 2012 19:11, Igor Stasenko <siguctua(a)gmail.com>
> escribió:
> >
> >> 2012/3/3 Gastón Dall' Oglio <gaston.dalloglio(a)gmail.com>:
> >> >
> >> >
> >> > El 3 de marzo de 2012 03:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>
> >> > escribió:
> >> >
> >> >> Stef,
> >> >>
> >> >> I think our banned troll is back :(
> >> >
> >> >
> >> > hehe, no no, I lack the intelligence to be a good troll :)
> >> >
> >> > I misunderstood what Stef said, I understood that he wanted to make
> >> > statistics about Pharo, more specifically on the development of Pharo.
> >> >
> >> > Anyway, if you're interested, this tool allows you to create funny
> >> > animations log from a source repository. I made a simple animation
> with
> >> > the
> >> > repository build pharo, with those commands:
> >> >
> >> > $ git clone git://gitorious.org/pharo-build/pharo-build.git
> >> > $ gource -800x600 pharo-build
> >> >
> >> > and this is the generated video:
> >> >
> >> > http://vimeo.com/37856284
> >> >
> >> Thanks.
> >> It's funny..
> >> btw, Marcus, is it really needed to update fetch script every time?
> >> i beleive this related to gforge, where you placing the base image ..
> >>
> >> >
> >> > Regards.
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko.
> >>
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
March 5, 2012
Re: [Pharo-project] MVP
by Igor Stasenko
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 <bschwab(a)anest.ufl.edu> 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: pharo-project-bounces(a)lists.gforge.inria.fr
> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K
> [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 6:36 PM
> To: pharo-project(a)lists.gforge.inria.fr
> 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.
March 5, 2012
Re: [Pharo-project] Looking for a package to do some statistics in Pharo
by Igor Stasenko
2012/3/5 Gastón Dall' Oglio <gaston.dalloglio(a)gmail.com>:
> :) yes it's funny. Maybe in this video is not apreciated, but in projects
> where there are many developers, this presentation of a repository log give
> a quick view of the dinamic of work.
>
I can say more. It make me feels like i given a birth to something,
which is then started to grow and bloom,
tended and honed by others.
This is very inspiring. My sincere thanks to you.
But besides of sentiments, i don't think that such kind of
presentation is very informative to those who did not participated
directly.
It serves to give an impression, but impression is not knowledge. Less
sentimental people need numbers :)
> Regards.
>
> El 4 de marzo de 2012 19:11, Igor Stasenko <siguctua(a)gmail.com> escribió:
>
>> 2012/3/3 Gastón Dall' Oglio <gaston.dalloglio(a)gmail.com>:
>> >
>> >
>> > El 3 de marzo de 2012 03:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>
>> > escribió:
>> >
>> >> Stef,
>> >>
>> >> Â I think our banned troll is back :(
>> >
>> >
>> > hehe, no no, I lack the intelligence to be a good troll :)
>> >
>> > I misunderstood what Stef said, I understood that he wanted to make
>> > statistics about Pharo, more specifically on the development of Pharo.
>> >
>> > Anyway, if you're interested, this tool allows you to create funny
>> > animations log from a source repository. I made a simple animation with
>> > the
>> > repository build pharo, with those commands:
>> >
>> > $ git clone git://gitorious.org/pharo-build/pharo-build.git
>> > $ gource -800x600 pharo-build
>> >
>> > and this is the generated video:
>> >
>> > http://vimeo.com/37856284
>> >
>> Thanks.
>> It's funny..
>> btw, Marcus, is it really needed to update fetch script every time?
>> i beleive this related to gforge, where you placing the base image ..
>>
>> >
>> > Regards.
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
--
Best regards,
Igor Stasenko.
March 5, 2012
Re: [Pharo-project] MVP
by Schwab,Wilhelm K
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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com]
Sent: Sunday, March 04, 2012 6:53 PM
To: Pharo-project(a)lists.gforge.inria.fr
Subject: Re: [Pharo-project] MVP
Everything has been moved in ss3.gemstone.com/ss/Spec<http://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: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com]
Sent: Sunday, March 04, 2012 6:38 PM
To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
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<http://www.squeaksource.com/DirtyExperiments/Spec-BenjaminVanRyseghem.34.mcz> into 1.3, but got an error and backed off.
Any ideas?
Bill
________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse(a)inria.fr]
Sent: Sunday, February 05, 2012 2:56 AM
To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
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: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 9:25 PM
> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
> 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: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 6:36 PM
> To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr>
> 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
March 5, 2012
Re: [Pharo-project] MVP
by Benjamin
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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com]
> Sent: Sunday, March 04, 2012 6:38 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse(a)inria.fr]
>> Sent: Sunday, February 05, 2012 2:56 AM
>> To: Pharo-project(a)lists.gforge.inria.fr
>> 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
>> > Sent: Saturday, February 04, 2012 9:25 PM
>> > To: Pharo-project(a)lists.gforge.inria.fr
>> > 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
>> > Sent: Saturday, February 04, 2012 6:36 PM
>> > To: pharo-project(a)lists.gforge.inria.fr
>> > 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
>>
>
>
March 4, 2012
Re: [Pharo-project] MVP
by Schwab,Wilhelm K
Ben,
Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec?
Bill
________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com]
Sent: Sunday, March 04, 2012 6:38 PM
To: Pharo-project(a)lists.gforge.inria.fr
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<http://www.squeaksource.com/DirtyExperiments/Spec-BenjaminVanRyseghem.34.mcz> into 1.3, but got an error and backed off.
Any ideas?
Bill
________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse(a)inria.fr]
Sent: Sunday, February 05, 2012 2:56 AM
To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
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: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 9:25 PM
> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
> 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: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 6:36 PM
> To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr>
> 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
March 4, 2012
Re: [Pharo-project] MVP
by Benjamin
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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse(a)inria.fr]
> Sent: Sunday, February 05, 2012 2:56 AM
> To: Pharo-project(a)lists.gforge.inria.fr
> 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> > Sent: Saturday, February 04, 2012 9:25 PM
> > To: Pharo-project(a)lists.gforge.inria.fr
> > 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> > Sent: Saturday, February 04, 2012 6:36 PM
> > To: pharo-project(a)lists.gforge.inria.fr
> > 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
>
March 4, 2012
Re: [Pharo-project] MVP
by Schwab,Wilhelm K
Stef,
I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz<http://www.squeaksource.com/DirtyExperiments/Spec-BenjaminVanRyseghem.34.mcz> into 1.3, but got an error and backed off.
Any ideas?
Bill
________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse(a)inria.fr]
Sent: Sunday, February 05, 2012 2:56 AM
To: Pharo-project(a)lists.gforge.inria.fr
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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 9:25 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> 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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu]
> Sent: Saturday, February 04, 2012 6:36 PM
> To: pharo-project(a)lists.gforge.inria.fr
> 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
March 4, 2012