January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Minimal pharo

by Esteban Lorenzano

Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible. Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribiÃ³: > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > >> ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can contribute. > > Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization. > > Cheers, > Adrian

Jan. 5, 2011

Re: [Pharo-project] [Pharo-users] Minimal pharo

by Esteban Lorenzano

Hi, I don't think my experience is really usable for general image shrinking. What I was doing is preparing images to run on the iPhone, and then I was cutting a lot of things needed in any other scenarios. In fact, I named my "technic" as "brute shrinking" :P and what I was using was an adaptation of Pavel's experiments: 1) I run all the cleans provided on Pharo. 2) I change the morphic UI with a dummy one. 3) I remove lots of packages using package unloader (and I said: lots... any package I'm not using). 4) I remove lots of classes (again, any clearly not-used class remaining in not unloaded packages) 5) I remove lots of methods (using Pavel's listing, here) 6) finally I was removing even InputEventFetcher, etc. (no need for a iOS user interface, I'm processing the events in "other way") with all this, my smallest image were about 4.1M... and it was working properly inside an iPhone :) as you can see... it doesn't look like it is useful for real non-mars scenarios... I can provide the scripts, of course, if you still think it is useful. and I thought on reorganize, taking into account all this drops, yes... but the experiments were aborted by the apple clause change... now solved, but no time to continue the work on it yet :) Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribiÃ³: > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > >> ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can contribute. > > Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization. > > Cheers, > Adrian

Jan. 5, 2011

Re: [Pharo-project] Hudson Win setup build

by Igor Stasenko

On 5 January 2011 11:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jan 5, 2011, at 11:11 AM, Torsten Bergmann wrote: > >> Would be nice if Hudson could also build >> the Pharo windows setup automatically >> in the future. Should be easy to setup. >> >> I know thats not the highest prio but >> I wanted to check if it is possible anyway >> (dont know what kind of machine the ci server >> is currently runnning on). >> > > right now we just have a linux slave builder. This is what IT Services > was able to provide. > >> Since I think VM's are built in the future >> via Hudson too there must be access to a >> win32 machine anyway. > > > Yes, we will look into setting up a Mac and a Windows slave > soon. > > One idea is to use an older intel mac and install windows there > as a virtual machine and use this machine for both windows and mac. > > Alternatively, Hudson can have Amazon E2C slaves... for windows, that > would be an alternative (but an expensive one). > Well, let us try a cheapest alternative first :) First we need to build a working solution. Customizing or moving it somewhere else it won't be a big problem (i hope). As to me, one important thing is that community should be able to participate. Once it is done, it should stay open for improvements and additions/extensions by people from community no just a limited number of persons. Because obviously, none of us have time to watch for everything. > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by nullPointer

Yeah, that is dicussed before, many times. UIBuilder is dead, and I believe any type of classic designer like VW use. Try implement a classic designer for UIs is lost time. I have many time for lost :) I believe the future is WPF, and the tools for generate XAML. Too exists some tools for create XUL. DonÂ´t is needed a UI designer in Smalltalk, only is needed a "Reader" for build the UI from a XML text. Regards. -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175319.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by Igor Stasenko

On 5 January 2011 10:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is really good > +1 This is something, morphic was needed 10 years ago. Not saying about today. > On Jan 5, 2011, at 2:18 AM, nullPointer wrote: > >> >> Finally I implemented the posibility of create a custom windows in >> CLFramework. >> >> The final visual result fails in somethings, but seems the original: >> >> http://forum.world.st/file/n3174741/example.png >> >> http://www.youtube.com/watch?v=QAu6fPyz1b0 >> http://www.youtube.com/watch?v=Gb9NoWFdhXo >> http://www.youtube.com/watch?v=5CpUnIH9KVw >> -- >> View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by StÃ©phane Ducasse

First people should use it, second we should check if the code is overriding or not the code in the image (if this is the case we should see how the code in the kernel and in the builder should be changed to avoid overrides), .... Now you can load the package and use it. and this is the best move for pushing its adoption. I looked at the code long time ago and I should redo it. Stef On Jan 5, 2011, at 8:38 AM, Olivier Auverlot wrote: > uibuilder is a very impressive tool ! > > Pharo must have this type of tool for to be a credible solution in the development of desktop applications.I think that integrate uibuilder in the standard image will be a good idea :) > > this is planed ? > > Best regards > Olivier > www.auverlot.fr > >> Cool ! >> >> Laurent >> >> On Wed, Jan 5, 2011 at 2:18 AM, nullPointer <epicfan(a)gmail.com> wrote: >> >> Finally I implemented the posibility of create a custom windows in >> CLFramework. >> >> The final visual result fails in somethings, but seems the original: >> >> http://forum.world.st/file/n3174741/example.png >> >> http://www.youtube.com/watch?v=QAu6fPyz1b0 >> http://www.youtube.com/watch?v=Gb9NoWFdhXo >> http://www.youtube.com/watch?v=5CpUnIH9KVw >> -- >> View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > >

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by StÃ©phane Ducasse

> I donÂ´t know if I understand correctly the question... Yes > The design code is saved in a basic message #specmorph: > specMorph > > | cLStatusbar container cLPanel | > "container" > container := CLPanel new. > self containerSpec: container. > container visible: false. > container openInWorld. > > "cLPanel" > cLPanel := CLPanel new. > container addMorph: cLPanel. > self cLPanelSpec: cLPanel. > > "cLStatusbar" > cLStatusbar := CLStatusbar new. > cLPanel addMorph: cLStatusbar. > self cLStatusbarSpec: cLStatusbar. > > ^container > > and another spec method for define each control of view, in current example > be #cLPanelSpec:, #cLStatusbarSpec: and #containerSpec:, for example: > > cLPanelSpec: aTCLControl > > aTCLControl name: 'cLPanel'. > aTCLControl usePolymorphStyleMechanism: false. > aTCLControl balloonText: nil. > aTCLControl enabled: true. > aTCLControl location: 0@0. > aTCLControl extent: 530@377. > aTCLControl anchors: {true .true .true .true .}. > aTCLControl imageResource: nil. > aTCLControl style: {(BorderStyle width: 0 color: Color transparent) .(Color > r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true > .}. > aTCLControl minWidth: 2. > aTCLControl minHeight: 2. > aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0 .false > .false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft > .#topLeft .#none .#none .}. ok this is better than to serialize the object. > I believe the definition of UI must be do with XUL, or XAML. Of that way > donÂ´t need a designer in Smalltalk, else could be use some of tools for > create XAML o XUL uis. Later, a "Reader" could parse the XML and build a > Morphic GUI or a Seaside GUI. As I told you before (read my previous emails) you do not need XML or XAML. You just need what is done in VW a spec They have done that and it works well. Here I did not formatted it well but you GET EXACTLY THE SAME EXPRESSION POWER THAN XML without the need for yet another parser. > cLPanelSpec: aTCLControl > > aTCLControl name: 'cLPanel'. > aTCLControl usePolymorphStyleMechanism: false. > aTCLControl balloonText: nil. > aTCLControl enabled: true. > aTCLControl location: 0@0. > aTCLControl extent: 530@377. > aTCLControl anchors: {true .true .true .true .}. > aTCLControl imageResource: nil. > aTCLControl style: {(BorderStyle width: 0 color: Color transparent) .(Color > r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true > .}. > aTCLControl minWidth: 2. > aTCLControl minHeight: 2. > aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0 .false > .false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft > .#topLeft .#none .#none .}. can be turned into #(Spec name: 'cLPanel'; usePolymorphStyleMechanism: false; ... and...) this is strictly equivalent to XML. Now if you build an XML reader we will be able to reuse the interpretation (oh there is this reference in the XML then I should create an object of a specific class). Look at the example below for the changeList widget. I do not have the time to format it well. #(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #label: #(#{Kernel.UserMessage} #key: #ChangeList #defaultString: 'Change List' #catalogID: #labels) #min: #(#{Core.Point} 300 400) #bounds: #(#{Graphics.Rectangle} 512 268 942 768) #menu: #menuBar #isEventDriven: true) #component: #(#{UI.SpecCollection} #collection: #(#(#{UI.SequenceViewSpec} #properties: #(#{UI.PropertyListDictionary} #dragOkSelector #wantToDrag: #dragEnterSelector #dragEnter: #dragOverSelector #dragOver: #dragStartSelector #doDrag: #dropSelector #drop: #dragExitSelector #dragLeave:) #layout: #(#{Graphics.LayoutFrame} 0 0 0 0 -100 1 150 0) #name: #listView #model: #selectionInList #callbacksSpec: #(#{UI.UIEventCallbackSubSpec} #doubleClickSelector: #toggleRemoveForListController: #requestValueChangeSelector: #changeRequest) #menu: #changeListMenuHolder) #(#{UI.CompositeSpecCollection} #collection: #(#(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 0) #model: #fileFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #file #defaultString: 'file' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 25) #model: #changeTypeFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #type #defaultString: 'type' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 50) #model: #classNameFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #class #defaultString: 'class' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 75) #model: #protocolFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #protocol #defaultString: 'protocol' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 100) #model: #selectorFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #selector #defaultString: 'selector' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 125) #model: #valuesFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #same #defaultString: 'same' #catalogID: #labels))) #compositeSpec: #(#{UI.CompositeSpec} #layout: #(#{Graphics.LayoutFrame} -100 1 0 0 0 1 150 0) #name: #filters #flags: 8)) #(#{UI.ResizingSplitterSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 150 0 0 1 153 0) #name: #ResizingSplitter1 #horizontal: true #minAboveSize: 150 #minBelowSize: 25 #aboveWidgets: 'listView filters' #belowWidgets: 'textCanvas') #(#{UI.SubCanvasSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 153 0 0 1 0 1) #name: #textCanvas #flags: 0 #minorKey: #standardText)))) The first view is what you get in the UIbuilder and the second view is the widget once it is open > > > Regards > > -- > View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175227.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 5, 2011

Re: [Pharo-project] Hudson Win setup build

by Marcus Denker

On Jan 5, 2011, at 11:11 AM, Torsten Bergmann wrote: > Would be nice if Hudson could also build > the Pharo windows setup automatically > in the future. Should be easy to setup. > > I know thats not the highest prio but > I wanted to check if it is possible anyway > (dont know what kind of machine the ci server > is currently runnning on). > right now we just have a linux slave builder. This is what IT Services was able to provide. > Since I think VM's are built in the future > via Hudson too there must be access to a > win32 machine anyway. Yes, we will look into setting up a Mac and a Windows slave soon. One idea is to use an older intel mac and install windows there as a virtual machine and use this machine for both windows and mac. Alternatively, Hudson can have Amazon E2C slaves... for windows, that would be an alternative (but an expensive one). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by nullPointer

I donÂ´t know if I understand correctly the question... The design code is saved in a basic message #specmorph: specMorph | cLStatusbar container cLPanel | "container" container := CLPanel new. self containerSpec: container. container visible: false. container openInWorld. "cLPanel" cLPanel := CLPanel new. container addMorph: cLPanel. self cLPanelSpec: cLPanel. "cLStatusbar" cLStatusbar := CLStatusbar new. cLPanel addMorph: cLStatusbar. self cLStatusbarSpec: cLStatusbar. ^container and another spec method for define each control of view, in current example be #cLPanelSpec:, #cLStatusbarSpec: and #containerSpec:, for example: cLPanelSpec: aTCLControl aTCLControl name: 'cLPanel'. aTCLControl usePolymorphStyleMechanism: false. aTCLControl balloonText: nil. aTCLControl enabled: true. aTCLControl location: 0@0. aTCLControl extent: 530@377. aTCLControl anchors: {true .true .true .true .}. aTCLControl imageResource: nil. aTCLControl style: {(BorderStyle width: 0 color: Color transparent) .(Color r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true .}. aTCLControl minWidth: 2. aTCLControl minHeight: 2. aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0 .false .false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft .#topLeft .#none .#none .}. I believe the definition of UI must be do with XUL, or XAML. Of that way donÂ´t need a designer in Smalltalk, else could be use some of tools for create XAML o XUL uis. Later, a "Reader" could parse the XML and build a Morphic GUI or a Seaside GUI. Regards -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175227.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

[Pharo-project] Hudson Win setup build

by Torsten Bergmann

Would be nice if Hudson could also build the Pharo windows setup automatically in the future. Should be easy to setup. I know thats not the highest prio but I wanted to check if it is possible anyway (dont know what kind of machine the ci server is currently runnning on). Since I think VM's are built in the future via Hudson too there must be access to a win32 machine anyway. Thx T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

Jan. 5, 2011