- Pharo-dev - lists.pharo.org

Re: [Pharo-project] CLFramework and Pharo
by Rob Rothwell June 30, 2010

June 30, 2010

Message: 5 > Date: Wed, 30 Jun 2010 23:50:24 +0200 > From: St?phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] CLFramework and Pharo > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: <77E6AD68-79FF-4590-9FB6-7B2E1C961001(a)inria.fr> > Content-Type: text/plain; charset=iso-8859-1 > > But you rely on XML. > Second the builder (ie generating the XML) is not the problem as far as I > know. > but more how to assemble the widget and make sure that the layout > are kept or specified. > > Then how using an external tools can make sure that this tool got well the > way layoutMorph > and other works? > > Stef > > > My knowledge is limited, but XML seems more portable than code Smalltalk. > > I do not understand why we want portability. > Please note that the VWspec are as portable as XML between Smalltalk they > are just arrays ( > probably we would get a problem for the UI.Node notation but this is not > the problem. > Another place to see such an example is Smalltalk/X. I think they conformed to the VW Specs as well... Rob

1 0

[Pharo-project] [update 1.2] #12026
by StÃ©phane Ducasse June 30, 2010

June 30, 2010

12026 ----- - Issue 2069: Be able to load DummyUIManager in a Pharo image. Part two

1 0

[Pharo-project] [update 1.2] #12024 (new version)
by StÃ©phane Ducasse June 30, 2010

June 30, 2010

12024 ----- - Issue 2105: Packages remodularization and now without obsolete classes Stef (thanks Pavel)

3 4

[Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2
by Denis Kudriashov June 30, 2010

June 30, 2010

I try last Pharo 1.1 rc2 10.06.10. I found that tool for changing color by user is changed. ColorPickerMorph is removed. Now I can't dynamically change color by mouse and see my changes immediately. Now I must select color in new tool, press ok button. And after that tool close and I must open it again if I dont like my changes. It is bad behavior compare with pharo 1.0/squeak. But I really like new color picker morph. New tool is ColorSelectorDialogWindow. How I can hookup It for tracking color selection? Maybe I must add some event triggering in #basicSelectedColor: method. But I see many #changed: sends in #basicSelectedColor: method. And maybe I already can implement some dependent class for needed stuff. What you think?

2 7

[Pharo-project] [update 1.2] #12025
by StÃ©phane Ducasse June 30, 2010

June 30, 2010

12025 ----- - Issue 2599: better extract parameter - Issue 2604: a script as argument squeak mysqueak.image file.st squeak mysqueak.image scripts/file.st squeak mysqueak.image ../../svn/scripts/file.st Stef and Hilaire happily hacking to relax :)

1 0

[Pharo-project] [update 1.2] #12024
by StÃ©phane Ducasse June 30, 2010

June 30, 2010

Pavel can you have a look to see if everything is ok? 12024 ----- - Issue 2105: Packages remodularization

2 10

[Pharo-project] [update 1.2] #12025
by StÃ©phane Ducasse June 30, 2010

June 30, 2010

12025 ----- - Issue 2105: Packages remodularization - Post actions Pavel I just did the DecompilerTests compileAll. LanguageEnvironment compileAll. FileServices cleanUp. CodeHolder compileAll. CompiledMethod compileAll. Debugger compileAll. Object compileAll. MCMczInstallerTest compileAll. MCInitializationTest compileAll.

1 0

[Pharo-project] CLFramework and Pharo
by Torsten Bergmann June 30, 2010

June 30, 2010

I've just noticed that "nullPointer" now recreated http://www.squeaksource.com/CLFramework again and uploaded CLFramework-nullPointer.90.mcz This time the code has a BSD license. The page says "Failed attempt of visual UI builder for Pharo-Polymorph. Abbandoned. Only works in Pharo 1.0" >From my point of view: 1. This sounds very negative and I dont understand what lead to this decision. Similar to the decision to delete the project on SqS midway. Especially since the previews looked really really good. Is it a time or other issue on nullpointer's side or did the community fail in support... 2. This looks to me as if the project will stop now with 1.0 and is not moved to 1.1. or 1.2 3. I dont understand why the license changed from MIT to BSD but that does not allow us to include the now released version 90 or further work in the MIT licensed pharo-dev. I expect a day in the life of Pharo where people will demand more support to build visual tools. So to create a UI Builder the community - either has to start from scratch then - or continue with the project as a fork based on an earlier version ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) Really sad. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 7

June 30, 2010

https://gforge.inria.fr/frs/download.php/27220/PharoCore-1.2-12023-UNSTABLE… Stef

1 0

June 30, 2010

Hi all Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common vision. Here what I would like to get in 1.2. Now it does not mean that this is a definitive list and that we will have the energy to do all but like that you know that you can put energy do build this common vision :) - better infrastructure for integrating rb composite queries into the system The idea is to introduce a superclass on top of systemDictionary and to define there an API that is compatible with the one of RB (and potentially modified the one of RB) - another step towards using announcement for system notification - better tools for dev - have a look at the RB change model so that we could get a real undo and changes - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. Right now this looks too brittle to do anything - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) - New Compiler in beta - Helvetia hooks - ROME API - Sophie Event Hierarchy - Define some architectural action to get the system more modular - Hudson infrastructure - metacello to manage core - metacelloRepository for 1.0/1.1/1.2 Gofer - squeak collection optimisation? - Alien Open points: - What do we do with ToolBuilder? Not clear to me. - What should be done at the level of polymorph? - What should be done a the level of Pluggable**** can we use the fact that we have now block closure to get it better. As you guess it will not come simply but this is important that we all head towards a common understanding Stef

7 13