- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec new release :)

by btc＠openinworld.com

Benjamin wrote: > Hello everyone, > > I am glad to announce a step has been made in Spec with the introduction of five new models: TreeNodeModel, TreeColumnModel, MenuModel, MenuGroupModel and MenuItemModel. > > I. Trees > > The two first models (TreeNodeModel, TreeColumnModel) are used to build and specify trees (in addition with TreeModel). > > a) TreeNodeModel > > TreeNode represent a node of the tree, and hold some basic information like what the children of the node are, or which icon to use. > > Previously, one could use directly subclasses of MorphTreeNodeModel directly. This has been removed to loose the bonds between Spec and Morphic. > > If you used direct Morphic nodes in your tree, you will need to replace them by TreeNodeModel instances. > > You could also have used TreeModel methods used to generically describe your nodes. > In this case, the only change you will need is how you access the content of a node. > The MorphTreeNodeModel method used for this is #item while in TreeNodeModel it is #content. > > TreeNodeModel also support filtering out of the box with an extensible mechanism. > > b) TreeColumnModel > > TreeColumnModel is used to specify the columns used to render the tree nodes. > Where one used to use TreeColumnMorph, now TreeColumnModel have to be use. > > The mainly behave the same, only the API differs to provide a less morphic oriented set of methods. > TreeColumnModel also resolve some some updating issue encountered in TreeColumnMorph. > > II. Menus > > The three remaining models are used to build menus for the spec models. > The way to build menus has been rethink to provide a more natural way to think menus. > > a) MenuModel > > A MenuModel is a quite a simple object with only an optional name, an optional icon and a list of menu groups. > A MenuModel can also be turned into an auto-refreshing menu. > > The main method of MenuModel is #addGroup: which takes a block as argument and build a group before adding it to the menu model groups list. > > Example: > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix ]. > aGroup addItem: [ :anItem | > anItem name: 'Browse Class'; > action: [ self browseSelectedObjectClass ] ] ]. > > b) MenuGroupModel > > A MenuGroupModel represent a set of menu items which belong to a same logical set by providing related actions. > A menu group only hold a list of menu items. > > The main method of MenuGroupModel is #addItem: , as you have seen in the previous example. > Example: > aGroup addItem: [ :anItem | > anItem name: 'Browse Hierarchy'; > action: [ self browseSelectedObjectClassHierarchy ]; > shortcut: $h command mac | $h alt win | $h alt unix ] > > c) MenuItemModel > > A menu item is the core of a menu. It is the object that can actually perform an action. A MenuItemModel holds multiple information related to this action like the name of the menu entry, the optional icon you want to use, if the action is doable in the current context, and the optional shortcut triggering the action. > > An interesting feature is that by applying a menu to a spec model, the shortcuts of its items will be used to automatically bind the corresponding key combination to the menu item action (taking in account the context to prevent to fire action when it does not make sense). > > So far, this feature has been introduced only in NewListModel to fix the possible issues before a global deployment. > > > Thanks for reading this long email, thanks for your support and your feedback, and see you soon :) > > Ben > > Thanks for your efforts. I'll try them out soon. regards -ben

Nov. 12, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by Sean P. DeNigris

Sean P. DeNigris wrote > Fix in inbox (for 2.0) And for 3.0... Fix in inbox: SLICE-Issue-12146-Port-to-30-12145-Settings-Replace-references-to-FileDirectory-SeanDeNigris.1 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-dev] Unexpected block variable change of value

by btc＠openinworld.com

Nov. 11, 2013

Re: [Pharo-dev] About MenuModel

by Benjamin

I will :P Indeed the comment should be improved to reflect the current implementation :) Ben On 12 Nov 2013, at 00:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 11, 2013, at 8:24 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> It used to be a block. >> >> Now you can actually use both of them, with a subtile difference which is that the result of the block will not act one the model >> unlike a MenuModel which will add its shortcuts to the model by its own. >> >> I will write a presentation mail this evening to explain this a bit better :) > > ok please log all my stupid question for the book chapter. > And we should improve the method comments and class comment too. > > >> >> Ben >> >> On 11 Nov 2013, at 20:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi Ben >>> >>> We do not understand MenuModel >>> in the example we have >>> >>> >>> menu := MenuModel new. >>> â¦ >>> group1 := MenuGroupModel new. >>> item11 := MenuItemModel new >>> name: [ TimeStamp now asString ]; >>> enabled: [ TimeStamp now seconds even ]; >>> yourself. >>> >>> ... >>> model := NewListModel new. >>> model menu: menu >>> >>> >>> then on the NewListModel >>> >>> NewListModel >> menu: aBlock >>> <api: #block getter: #menu registration: #whenMenuChanged:> >>> "Set the block used to defined the menu" >>> >>> menuHolder value: aBlock >>> >>> so it is a block? or a MenuModel? >>> >>> I'm totally confused. >>> >>> Stef >> >

Nov. 11, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by Sean P. DeNigris

Sean P. DeNigris wrote > Aspetta! Okay, that's long enough... here: Fix in inbox (for 2.0): SLICE-Issue-12145-Settings-Replace-references-to-FileDirectory-SeanDeNigris.1 - Add SettingDeclaration>>#inputWidgetForDirectory to replace old FileDirectory code - Update MC Settings to use new API ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 11, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by Sean P. DeNigris

StÃ©phane Ducasse wrote > please enter a bug entry (and fixes) Aspetta! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 11, 2013

Re: [Pharo-dev] About MenuItemModel

by StÃ©phane Ducasse

Ok course and I knew it. Stef > Indeed :) > > Ben > > On 11 Nov 2013, at 19:17, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> #action is most probably a ValueHolder, no? >> >> On 2013-11-11, at 19:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi ben >>> >>> do I get it correctly that we pass a block to a block for action >>> >>> action: aBlock >>> >>> action value: aBlock >>> >>> are you sure that you want a block as argument of a block. >>> >>> I would prefer that action is simply a block. >>> >>> Stef >>> >> >

Nov. 11, 2013

Re: [Pharo-dev] About MenuModel

by StÃ©phane Ducasse

On Nov 11, 2013, at 8:24 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It used to be a block. > > Now you can actually use both of them, with a subtile difference which is that the result of the block will not act one the model > unlike a MenuModel which will add its shortcuts to the model by its own. > > I will write a presentation mail this evening to explain this a bit better :) ok please log all my stupid question for the book chapter. And we should improve the method comments and class comment too. > > Ben > > On 11 Nov 2013, at 20:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Ben >> >> We do not understand MenuModel >> in the example we have >> >> >> menu := MenuModel new. >> â¦ >> group1 := MenuGroupModel new. >> item11 := MenuItemModel new >> name: [ TimeStamp now asString ]; >> enabled: [ TimeStamp now seconds even ]; >> yourself. >> >> ... >> model := NewListModel new. >> model menu: menu >> >> >> then on the NewListModel >> >> NewListModel >> menu: aBlock >> <api: #block getter: #menu registration: #whenMenuChanged:> >> "Set the block used to defined the menu" >> >> menuHolder value: aBlock >> >> so it is a block? or a MenuModel? >> >> I'm totally confused. >> >> Stef >

Nov. 11, 2013

Re: [Pharo-dev] declareTempAndPaste:

by StÃ©phane Ducasse

for your info this is fixed now :) Tx alex and objectprofilers for this nice fix. Stef On Nov 11, 2013, at 3:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Many of us have discovered that in the last Pharo adding a temporary variable is added before the | .. | part of the section. > > Pablo Estefo and I spend time on understanding where this comes from. But since this is deep into the compilation chain, it would be great if an expert (Marcus ? :-) could check what we have done. > > OCUndeclaredVariableWarning>>declareTempAndPaste: is the culprit method. We have changed: > tempsMark := self methodNode body leftBar ifNil: [ self methodNode body start ]. > into > tempsMark := self methodNode body rightBar ifNil: [ self methodNode body start ]. > > > So, the new version of the method should be: > -=-=-=-=-=-=-=-=-=-=-=-= > OCUndeclaredVariableWarning>>declareTempAndPaste: name > | insertion delta theTextString characterBeforeMark tempsMark | > > theTextString := self methodNode source. > tempsMark := self methodNode body rightBar ifNil: [ self methodNode body start ]. > characterBeforeMark := theTextString at: tempsMark-1 ifAbsent: [$ ]. > > (theTextString at: tempsMark) = $| ifTrue: [ > "Paste it before the second vertical bar" > insertion := name, ' '. > > characterBeforeMark isSeparator ifFalse: [insertion := ' ', insertion]. > delta := 0. > ] ifFalse: [ > "No bars - insert some with CR, tab" > insertion := '| ' , name , ' |',String cr. > delta := 2. "the bar and CR" > characterBeforeMark = Character tab ifTrue: [ > insertion := insertion , String tab. > delta := delta + 1. "the tab" ] > ]. > tempsMark := tempsMark + > (self substituteWord: insertion > wordInterval: (tempsMark to: tempsMark-1) > offset: 0) - delta. > self methodNode scope addTemp: name. > ^ (node owningScope lookupVar: node name) > ifNil: [self error: 'should not happen'] > -=-=-=-=-=-=-=-=-=-=-=-= > > We have tried different cases and it seems to work. > Does this makes sense? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Nov. 11, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by StÃ©phane Ducasse

> > or of course, you start looking at porting XStreams to pharo ;), which on the long run will > solve many more problems. The current situation is not that satisfactory having experience with it and thinking about a plan for the beginning of 40 would be great. I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice. Stef

Nov. 11, 2013