- Pharo-dev - lists.pharo.org

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

I should add a repository for distribution. Stef On Jun 18, 2011, at 2:59 PM, StÃ©phane Ducasse wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > >

June 18, 2011

Re: [Pharo-project] User-friendly FFI (was Re: roadmap for 1.4)

by StÃ©phane Ducasse

Excellent idea Dave!!! Stef On Jun 18, 2011, at 5:59 PM, Dave Mason wrote: > > On 2011-Jun-18, at 9:07 , laurent laffont wrote: > >> + a FFI that a stupid idiot like me can use > > I'm working on it, aiming for a paper at IWST. I posted a request for opinion and help on this yesterday, but got little response (perhaps because it was part of another thread). > > See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050298.html > > ../Dave >

June 18, 2011

Re: [Pharo-project] roadmap for 1.4

by StÃ©phane Ducasse

On Jun 18, 2011, at 5:18 PM, Norbert Hartl wrote: > Are they all of equal importance? no > To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. no it can be fast. One of the point is to have the code under our nose so that we can really integrate code. For example, that the browser uses ring as a start. That I can work on RBEngine changes related to RPackage. > What happened to the zinc integration btw.? It is integrated and working well since a while :) > > Norbert > > > > Am 18.06.2011 um 14:59 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> >

June 18, 2011

[Pharo-project] User-friendly FFI (was Re: roadmap for 1.4)

by Dave Mason

On 2011-Jun-18, at 9:07 , laurent laffont wrote: > + a FFI that a stupid idiot like me can use I'm working on it, aiming for a paper at IWST. I posted a request for opinion and help on this yesterday, but got little response (perhaps because it was part of another thread). See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050298.html ../Dave

June 18, 2011

Re: [Pharo-project] roadmap for 1.4

by laurent laffont

On Sat, Jun 18, 2011 at 5:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Are they all of equal importance? To me it sounds really a lot. And it > looks like 1.4 will last quite long until it will be released. What happened > to the zinc integration btw.? > Zinc is already in 1.3. Laurent. > > Norbert > > > > Am 18.06.2011 um 14:59 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > >: > > > Hi guys > > > > here is a kind of dump of roadmap for 1.4 first level is to make sure > that we have only one single image. > > > > - load FileSystem > > -> so that we can start to integrate and improve the fileSystem API > > > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what > should be changed for RPackage to work > > > > - Ring > > -> so that we can start to integrate it > > > > - Fuel > > -> so that we can deprecate SmartRefStream (there may be a problem > with mcz (not sure)). > > > > - I want Opal in 1.4 too. > > > > - continue to remove StringHolder hierarchy > > > > - Morphic improvements > > > > Comments are welcomed. > > > > Stef > > > > > >

June 18, 2011

Re: [Pharo-project] roadmap for 1.4

by Norbert Hartl

Are they all of equal importance? To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. What happened to the zinc integration btw.? Norbert Am 18.06.2011 um 14:59 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > >

June 18, 2011

Re: [Pharo-project] OB column width resizing

by Schwab,Wilhelm K

Not yet - it's still very crude on some of the more important points. ________________________________________ 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: Saturday, June 18, 2011 8:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OB column width resizing Igor do you have your code somewhere? Stef On Jun 18, 2011, at 2:47 PM, Schwab,Wilhelm K wrote: > Stef, > > I had missed it. Fernando raises some good points about the layout manager. One of the ways I have historically solved some of the problems that arise is to use "way too many"<g> nested containers. > > Consider making a list of several labeled text fields for a dialog box. One approach to that is a pair of vertical proportional layouts, one with the labels (each aligning text to the right) and another with the fields. Put both of them in another container to size them to available space in something else. > > Igor and Fernando reminded me of something I failed to mention about Dolphin: the layout manager of a container forces particular types for the managed subviews' #arrangement. ProportionalLayout wants numbers; FramingLayout wants things very similar to what exists in Pharo. Framing layout is very powerful, but nested proportionals can often to pretty much the same thing and often with far less anguish. > > 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: Saturday, June 18, 2011 3:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OB column width resizing > > bill > > did you check the idea of igor about layout that acts as anchors? > > Stef > > > On Jun 17, 2011, at 11:49 PM, Schwab,Wilhelm K wrote: > >> As my Pharo MVP framework grows, I am starting to miss Dolphin's layout managers. The voodoo of automatically inserting splitters is, IMHO, time thrown after bad. We should instead have easy-to-use widgets that do what one expects and then explicitly place them where they belong. >> >> Dolphin's proportional layouts can be set as horizontal or vertical, and one can add splitters to allow the proportions to be changed. An aspect called #arrangement can be set to zero to make something fixed size or to any number which then becomes that much out of the sum of peer #arrangement values. >> >> My first priority is to get any type of layout that is reliable with deeply nested composites. Not there yet :( >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Friday, June 17, 2011 4:00 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] OB column width resizing >> >> Lukas Renggli wrote: >>> >>> See >>> http://groups.google.com/group/omnibrowser-dev/browse_thread/thread/3957238… >>> >> >> Thx :( >> >> -- >> View this message in context: http://forum.world.st/OB-column-width-resizing-tp3606264p3606347.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > >

June 18, 2011

Re: [Pharo-project] roadmap for 1.4

by Alexandre Bergel

Looks good! Alexandre On 18 Jun 2011, at 08:59, StÃ©phane Ducasse wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 18, 2011

Re: [Pharo-project] roadmap for 1.4

by laurent laffont

On Sat, Jun 18, 2011 at 2:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that > we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what > should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem > with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > Yes for Morphic ! + a FFI that a stupid idiot like me can use + keymapping Laurent > > Comments are welcomed. > > Stef > > >

June 18, 2011

Re: [Pharo-project] OB column width resizing

by StÃ©phane Ducasse

Igor do you have your code somewhere? Stef On Jun 18, 2011, at 2:47 PM, Schwab,Wilhelm K wrote: > Stef, > > I had missed it. Fernando raises some good points about the layout manager. One of the ways I have historically solved some of the problems that arise is to use "way too many"<g> nested containers. > > Consider making a list of several labeled text fields for a dialog box. One approach to that is a pair of vertical proportional layouts, one with the labels (each aligning text to the right) and another with the fields. Put both of them in another container to size them to available space in something else. > > Igor and Fernando reminded me of something I failed to mention about Dolphin: the layout manager of a container forces particular types for the managed subviews' #arrangement. ProportionalLayout wants numbers; FramingLayout wants things very similar to what exists in Pharo. Framing layout is very powerful, but nested proportionals can often to pretty much the same thing and often with far less anguish. > > 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: Saturday, June 18, 2011 3:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OB column width resizing > > bill > > did you check the idea of igor about layout that acts as anchors? > > Stef > > > On Jun 17, 2011, at 11:49 PM, Schwab,Wilhelm K wrote: > >> As my Pharo MVP framework grows, I am starting to miss Dolphin's layout managers. The voodoo of automatically inserting splitters is, IMHO, time thrown after bad. We should instead have easy-to-use widgets that do what one expects and then explicitly place them where they belong. >> >> Dolphin's proportional layouts can be set as horizontal or vertical, and one can add splitters to allow the proportions to be changed. An aspect called #arrangement can be set to zero to make something fixed size or to any number which then becomes that much out of the sum of peer #arrangement values. >> >> My first priority is to get any type of layout that is reliable with deeply nested composites. Not there yet :( >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Friday, June 17, 2011 4:00 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] OB column width resizing >> >> Lukas Renggli wrote: >>> >>> See >>> http://groups.google.com/group/omnibrowser-dev/browse_thread/thread/3957238… >>> >> >> Thx :( >> >> -- >> View this message in context: http://forum.world.st/OB-column-width-resizing-tp3606264p3606347.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > >

June 18, 2011