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

Re: [Pharo-project] Issue 3930 in pharo: PickAFileToWriteNotification is not used --> move to Deprecated13

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 3930 by marcus.d...(a)gmail.com: PickAFileToWriteNotification is not used --> move to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=3930 in 13126

April 1, 2011

Re: [Pharo-project] Issue 3677 in pharo: A to:do: loop cannot modify the limit inside the block

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3677 by marcus.d...(a)gmail.com: A to:do: loop cannot modify the limit inside the block http://code.google.com/p/pharo/issues/detail?id=3677 in 13126

April 1, 2011

Re: [Pharo-project] Issue 432 in pharo: CollectionExtensions

by pharo＠googlecode.com

Updates: Status: Closed Comment #16 on issue 432 by marcus.d...(a)gmail.com: CollectionExtensions http://code.google.com/p/pharo/issues/detail?id=432 I added to the wishlist: http://code.google.com/p/pharo/wiki/IdeasToImplement "evaluate extension of moose for inclusions in pharo base library"

April 1, 2011

[Pharo-project] Issue 3932 in pharo: Delete package: FreeTypeSubPixelAntiAliasing

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3932 by marcus.d...(a)gmail.com: Delete package: FreeTypeSubPixelAntiAliasing http://code.google.com/p/pharo/issues/detail?id=3932 Package FreeTypeSubPixelAntiAliasing is empty. Delete

April 1, 2011

[Pharo-project] Issue 3931 in pharo: Move all Exceptions-Kernel to Kernel-Exceptions

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3931 by marcus.d...(a)gmail.com: Move all Exceptions-Kernel to Kernel-Exceptions http://code.google.com/p/pharo/issues/detail?id=3931 The classes in Exceptions-Kernel should be moved to the Kernel package

April 1, 2011

[Pharo-project] Issue 3930 in pharo: PickAFileToWriteNotification is not used --> move to Deprecated13

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3930 by marcus.d...(a)gmail.com: PickAFileToWriteNotification is not used --> move to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=3930 PickAFileToWriteNotification is not used --> move to Deprecated13

April 1, 2011

[Pharo-project] SimpleMorphic adoption schedule

by Fernando Olivero

HI Tudor, i guess porting and updating SMx from the latest version in CUIS, would be made around next week. This would give us: new Morph kernel, significantly simplified layout, basic widgets simplified and unified ( for example only one class for buttons) and anti-alised rounded corners for windows and buttons( Juan implemented this taking ideas from Morphic3, way better than the OS native widgets, just take a look at CUIS ). Then * Integrating Alain's editor state into the text morphs views shouldn't take more than one day. ( I believe Glamour only requires up to here). * When Ben releases Nautilus, we would have to port it to SMx. ( to have standard browsers) * Polymorph and SMx merge, would take quite a while, depending on the amount of people we get involved. So i dont know how much would it take to replace entirely Morphic with SMx, having all the features of Polymorph also. Highly depends on the people involved in this effort. But having a simple version of SMx, is feasible within 15 days . and then gradually add pieces till we can trash any Old-Morphic dependance. Fernando On Thu, Mar 31, 2011 at 12:56 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Fernando, > > These are good news. > > I am very interested in using this in Glamour. Just one question: What is the expected schedule? > > Cheers, > Doru >

April 1, 2011

Re: [Pharo-project] Issue 3929 in pharo: Package Filter for MC based repo browser

by pharo＠googlecode.com

Comment #2 on issue 3929 by stephane...(a)gmail.com: Package Filter for MC based repo browser http://code.google.com/p/pharo/issues/detail?id=3929 rahhh lovely.... Excellent, tx Stef

April 1, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Fernando Olivero

Thanks ben, i will have that in mind. Regarding the menus, an interesting discussion with Juan came from analyzing the menu actions handling: 1) Who must be responsible for raising the menu? In our case , is the menu pragma builder invocation on the view or on the model? 2) Who should be responsible for handling the menu actions? the model , the view or both depending on the action itself? I'm intrigued to learn how are you handling this issues in Nautilus? Fernando On Fri, Apr 1, 2011 at 1:09 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Apr 1, 2011, at 9:16 AM, Fernando Olivero wrote: > >> Ok. >> >> Regarding the names, I was arguing in favor of using BrowserMorph >> instead of Browser for the Morphic side, because it would really a >> Browser for the Morphic UI. >> >> So lets agree on the basic required widgets. On the Nautilus side, >> what are the widgets needed? In a previous email you mentioned >> MorphTreeMorph. Lets make a list so i know the status of the SMx port, >> and what needs to be done at the View level. >> >> Basic: >> 1) Button >> 2) Menus >> 3) PluggableTextMorph >> 4) SystemWindow >> 5) PluggableListMorph ( and maybe its variants) >> --------- >> Nautilus: >> 5) MorphTreeMorph > > 6) PluggableIconListMorphOfMany (such a good name ...) > 7) IconicButton > 8) MenuBuilder (menus based on pragma) > > and I think that's all > > > > Ben > > >> >> >> On Thu, Mar 31, 2011 at 10:01 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> >>>> I agree with it and would like to help with the Nautilus model, and >>>> the corresponding view for SimpleMorphic. >>>> >>>> I belive we should look at CUIS TexProvider hierarchy, since he >>>> already cleanup this classes, and the intent is similar to the yours. >>>> As he told in en email: "To clean the hierarchy is ok, but we should >>>> be very careful to no put MODEL LOGIC in the VIEW. In CUIS the idea is >>>> to deal with PluggableTextModel that gets plugged a TextProvider or >>>> CodeProvider." >>> >>> I do not see why we need that at all. >>> For the moment let us finish Nautilus and remove most of the StringHolder subclasses >>> then after porting that to SimpleMorphic will just be switching to the correct treeMorph >>> because the model will be the same in Morphic and in SM >>> >>>> Somehow similar to what you propose in the pdf, and what stef is >>>> talking about. Composition instead of inheritance. >>>> >>>> So to summarize: >>>> >>>> 1) Model logic in specialized code providers >>> Â Â Â Â Not only: a browser model should know not only about code but about the current state of the tools: >>> Â Â Â Â which view (packages,.... buttons is selected). >>> >>>> 2) View on specialized views, moving the current functionality from >>>> the model to the view, that dont have model logic. >>> Â Â Â Â Not really so far we use a good tree and this is enough >>> >>>> 3) I suggest keeping the curent names, for instance, Browser is the >>>> model, BrowserMorph is the view ( in Morphic) >>> Â Â Â Â We will see. >>> >>> For the moment this is not important. We should get SM cleaned and port Polymorph on top of it >>> and clean the main widgets. >>> >>> >>>> >>>> >>>> Fernando >>>> pd: I will sync with Juan on this effort, so we can all work together >>>> on the next Morphic. >>>> >>>> >>>> >>>> >>>> On Thu, Mar 31, 2011 at 5:46 PM, Benjamin >>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>> >>>>> On Mar 31, 2011, at 5:51 PM, Torsten Bergmann wrote: >>>>> >>>>>>>> Model >>>>>>>> TextModel >>>>>>>> Workspace >>>>>>>> PluggableTextModel >>>>>>>> TextProvider >>>>>>>> CodeProvider >>>>>>>> Â Â Browser >>>>>>>> Â Â HierarchyBrowser >>>>>>>> Â Â Debugger >>>>>>>> Â Â Inspector >>>>>>> >>>>>>> For me, this hierarchy is bad. >>>>>>> Workspace is not a model, it's a view basically. >>>>>> >>>>>> Take care not to confuse things here. If you think as "Workspace" >>>>>> as the window that is popping up when you open a workspace >>>>>> then you are on the wrong track. >>>>>> What you see is just one (morphic) view on a model/workspace instance. >>>>>> >>>>>> >>>>>> Workspace, Inspector, Browser - all these ARE models and >>>>>> you can have different looking views on it or open one or more views >>>>>> on the same model. >>>>>> >>>>>> Try >>>>>> >>>>>> |browserModel Â | >>>>>> browserModel := Browser new. >>>>>> Browser >>>>>> Â openBrowserView: (browserModel openEditString: nil) >>>>>> Â label: 'View 1'. >>>>>> Browser >>>>>> Â openBrowserView: (browserModel openEditString: nil) >>>>>> Â label: 'View 2'. >>>>> >>>>> >>>>> >>>>> Browser class>>#newOnClass: aClass label: aLabel >>>>> Â Â Â Â "Open a new class browser on this class." >>>>> Â Â Â Â | newBrowser | >>>>> >>>>> Â Â Â Â newBrowser := self new. >>>>> Â Â Â Â newBrowser setClass: aClass selector: nil. >>>>> Â Â Â Â ^ self >>>>> Â Â Â Â Â Â Â Â openBrowserView: (newBrowser openOnClassWithEditString: nil) >>>>> Â Â Â Â Â Â Â Â label: aLabel >>>>> >>>>> >>>>> openOnClassWithEditString: aString >>>>> Â Â Â Â "Create a pluggable version of all the views for a Browser, including views and controllers." >>>>> Â Â Â Â ^ self openAsMorphClassEditing: aString. >>>>> >>>>> >>>>> openAsMorphClassEditing: editString >>>>> Â Â Â Â "Create a pluggable version a Browser on just a single class." >>>>> Â Â Â Â ^UIManager default openBrowser: self asMorphClassEditing: editString >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So here, a Browser instance send openBrowser: asMorphClassEditing: with self as parameter: >>>>> >>>>> openBrowser: aBrowser asMorphClassEditing: editString >>>>> Â Â Â Â "Create a pluggable version a Browser on just a single class." >>>>> Â Â Â Â | window dragNDropFlag hSepFrac switchHeight mySingletonClassList | >>>>> >>>>> Â Â Â Â window := (SystemWindow labelled: 'later') model: aBrowser. >>>>> Â Â Â Â dragNDropFlag := true. >>>>> Â Â Â Â hSepFrac := 0.3. >>>>> Â Â Â Â switchHeight := 25. >>>>> Â Â Â Â mySingletonClassList := PluggableListMorph on: aBrowser list: #classListSingleton >>>>> Â Â Â Â Â Â Â Â Â Â Â Â selected: #indexIsOne changeSelected: #indexIsOne: >>>>> Â Â Â Â Â Â Â Â Â Â Â Â menu: #classListMenu:shifted: keystroke: #classListKey:from:. >>>>> Â Â Â Â mySingletonClassList enableDragNDrop: dragNDropFlag. >>>>> >>>>> Â Â Â Â aBrowser >>>>> Â Â Â Â Â Â Â Â addLowerPanesTo: window >>>>> Â Â Â Â Â Â Â Â at: (0@hSepFrac corner: 1@1) >>>>> Â Â Â Â Â Â Â Â with: editString. >>>>> Â Â Â Â window >>>>> Â Â Â Â Â Â Â Â addMorph: mySingletonClassList >>>>> Â Â Â Â Â Â Â Â fullFrame: ( >>>>> Â Â Â Â Â Â Â Â Â Â Â Â LayoutFrame >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fractions: (0@0 corner: 0.5@0) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â offsets: (0@0 corner: 0@switchHeight) >>>>> Â Â Â Â Â Â Â Â ). >>>>> >>>>> Â Â Â Â aBrowser >>>>> Â Â Â Â Â Â Â Â addMorphicSwitchesTo: window >>>>> Â Â Â Â Â Â Â Â at: ( >>>>> Â Â Â Â Â Â Â Â Â Â Â Â LayoutFrame >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fractions: (0.5@0 corner: 1.0@0) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â offsets: (0@0 corner: 0@switchHeight) >>>>> Â Â Â Â Â Â Â Â ). >>>>> >>>>> Â Â Â Â window >>>>> Â Â Â Â Â Â Â Â addMorph: aBrowser buildMorphicMessageCatList >>>>> Â Â Â Â Â Â Â Â fullFrame: ( >>>>> Â Â Â Â Â Â Â Â Â Â Â Â LayoutFrame >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fractions: (0@0 corner: 0.5@hSepFrac) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â offsets: (0@switchHeight corner: 0@0) >>>>> Â Â Â Â Â Â Â Â ). >>>>> >>>>> Â Â Â Â window >>>>> Â Â Â Â Â Â Â Â addMorph: aBrowser buildMorphicMessageList >>>>> Â Â Â Â Â Â Â Â fullFrame: ( >>>>> Â Â Â Â Â Â Â Â Â Â Â Â LayoutFrame >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â fractions: (0.5@0 corner: 1.0@hSepFrac) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â offsets: (0@switchHeight corner: 0@0) >>>>> Â Â Â Â Â Â Â Â ). >>>>> >>>>> Â Â Â Â window setUpdatablePanesFrom: #(messageCategoryList messageList). >>>>> Â Â Â Â ^ window >>>>> >>>>> For me, it's not a Model behavior to add panes ... >>>>> >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>>> >>>>>> Evaluate it, show the windows side by side and then click >>>>>> in one: two views on the same model and the changes are >>>>>> propagated to all dependent views. >>>>>> >>>>>> So they ARE MODELS: >>>>>> Take a browser for example. It should know about which class >>>>>> is selected, which methods to display, ... it's a code holder >>>>>> and manager thing. Nothing more ... it doesnt even need a UI. >>>>>> >>>>>> But it's "view parts" could be (one or more) real windows >>>>>> layouted in either morphic or a view in Squeaks old MVC or >>>>>> browser on a Seaside webpage (actually Seaside really has an HTML >>>>>> based browser). >>>>>> >>>>>> The browser model does for instance care if you are working >>>>>> on the instance or class side (see #metaClassIndicated >>>>>> and senders) - but it doesnt care if you switch either using >>>>>> buttons or radio buttons or whatever ... thats up to the view/presentation >>>>>> layer. >>>>>> >>>>>> In general you should be able to also drive this model >>>>>> without ever really having to open a view ... >>>>>> >>>>>> So that even the tools are models (although most people think of them >>>>>> as windows) is a major difference in Smalltalk's UI design compared to >>>>>> most UI frameworks in other languages. >>>>>> >>>>>> VisualWorks uses a special class ApplicationModel to subclass >>>>>> for tools and application windows to make this more clear. >>>>>> >>>>>> Java's Swing (written by people who designed VisualWorks UI first) has a >>>>>> similar but more excessive model design JButton -> ButtonModel, ... >>>>>> The other extreme is VB6/Delphi where you dont have a model at all >>>>>> and have to write an own if you want separation ;) >>>>>> >>>>>> Nothing said about the code quality of the current implementation >>>>>> in Pharo... >>>>>> >>>>>> Bye >>>>>> T. >>>>>> -- >>>>>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>>>>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > >

April 1, 2011

[Pharo-project] [update 1.3] #13125

by Marcus Denker

13125 ----- Issue 3922: Add ClassHierarchy Checks Issue 3920: String has extension for *graphics Issue 3896: 1.3 core has wrong theme enabled Issue 3769: Printing an object depends on #isKindOf: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 1, 2011