Spec new release :)
Locked
1234
1234
Spec new release :)
 
|
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 |
|
|
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 > > regards -ben |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
>
> 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 ] ] ]. > I do not see the value of passing block to add element to groups why not the normal way i.e. passing an object. I do not get why executing a block with an object is better? Stef |
Re: Spec new release :)
|
|
It is not necessary better, but it saves you from having hundreds of temp vars :)
Ben On 12 Nov 2013, at 01:49, Stéphane Ducasse <[hidden email]> wrote:
|
|
|
On Nov 12, 2013, at 4:22 AM, Benjamin <[hidden email]> wrote:
he, I thought the same :)
|
Re: Spec new release :)
|
|
One can just use an object too.
It’s just that otherwise, it pollutes a bit the method with tons of inst vars (and then you forget to use them :P)
Ben On 12 Nov 2013, at 13:05, Esteban Lorenzano <[hidden email]> wrote:
|
|
|
In reply to this post by Stéphane Ducasse
I'm working on the changeSorter menus because they do not work anymore.
And we will see what we can learn from there. Stef On Nov 12, 2013, at 1:49 AM, Stéphane Ducasse <[hidden email]> wrote: >> >> 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 ] ] ]. >> > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > Stef > |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
biut that method can be written:
aMenu addGroup: (MenuGroupModel new addItem: (MenuItemModel new name: 'Browse Full'; action: [ self browseSelectedObject ]; shortcut: $b command mac | $b alt win | $b alt unix); addItem: (MenuItem new name: 'Browse Class'; action: [ self browseSelectedObjectClass ])). and you do not have to declare variables for that (and is a lot better than using a block, IMO). On Nov 12, 2013, at 9:36 AM, Benjamin <[hidden email]> wrote:
|
|
|
Yes this is what I did for the change sorter. I do not like this DSL like way of passing block over block over block
over blocks. I love blocks but methods are named blocks and I prefer them. Stef
|
|
|
I think there is some issue with TreeColumnModel. For example:
TreeModel exampleWithCustomColumnsAndNodes Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" Should I report in fogbugz? thanks, Martín On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse <[hidden email]> wrote: > Yes this is what I did for the change sorter. I do not like this DSL like > way of passing block over block over block > over blocks. > > I love blocks but methods are named blocks and I prefer them. > > Stef > > biut that method can be written: > > aMenu addGroup: (MenuGroupModel new > addItem: (MenuItemModel new > name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix); > addItem: (MenuItem new > name: 'Browse Class'; > action: [ self browseSelectedObjectClass ])). > > and you do not have to declare variables for that (and is a lot better than > using a block, IMO). > > > > On Nov 12, 2013, at 9:36 AM, Benjamin <[hidden email]> > wrote: > > One can just use an object too. > > It’s just that otherwise, it pollutes a bit the method with tons of inst > vars > (and then you forget to use them :P) > > Ben > > On 12 Nov 2013, at 13:05, Esteban Lorenzano <[hidden email]> wrote: > > > On Nov 12, 2013, at 4:22 AM, Benjamin <[hidden email]> > wrote: > > It is not necessary better, but it saves you from having hundreds of temp > vars :) > > Ben > > On 12 Nov 2013, at 01:49, Stéphane Ducasse <[hidden email]> > wrote: > > > 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 ] ] ]. > > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > > he, I thought the same :) > > > Stef > > > > > > |
|
|
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <[hidden email]> wrote: > I think there is some issue with TreeColumnModel. For example: > > TreeModel exampleWithCustomColumnsAndNodes > > Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" > > Should I report in fogbugz? > > thanks, > Martín > > On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse > <[hidden email]> wrote: >> Yes this is what I did for the change sorter. I do not like this DSL like >> way of passing block over block over block >> over blocks. >> >> I love blocks but methods are named blocks and I prefer them. >> >> Stef >> >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than >> using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <[hidden email]> >> wrote: >> >> One can just use an object too. >> >> It’s just that otherwise, it pollutes a bit the method with tons of inst >> vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <[hidden email]> wrote: >> >> >> On Nov 12, 2013, at 4:22 AM, Benjamin <[hidden email]> >> wrote: >> >> It is not necessary better, but it saves you from having hundreds of temp >> vars :) >> >> Ben >> >> On 12 Nov 2013, at 01:49, Stéphane Ducasse <[hidden email]> >> wrote: >> >> >> 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 ] ] ]. >> >> >> I do not see the value of passing block to add element to groups >> why not the normal way i.e. passing an object. I do not get why executing >> a block with an object is better? >> >> >> he, I thought the same :) >> >> >> Stef >> >> >> >> >> >> |
Re: Spec new release :)
|
|
In reply to this post by tinchodias
There is one reported since yesterday I think about missing morphic bindings ;)
Thanks for your feedback :)
Ben On 12 Nov 2013, at 14:48, Martin Dias <[hidden email]> wrote: I think there is some issue with TreeColumnModel. For example: |
Re: Spec new release :)
|
|
In reply to this post by Stéphane Ducasse
Then foo it :)
Both way are supported, so I do not really get the point of this discussion :)
Ben On 12 Nov 2013, at 14:21, Stéphane Ducasse <[hidden email]> wrote:
|
Re: Spec new release :)
|
|
In reply to this post by tinchodias
It’s this one: https://pharo.fogbugz.com/default.asp?12135
Ben On 12 Nov 2013, at 14:49, Martin Dias <[hidden email]> wrote: I forgot to specify: in latest Pharo (30565) |
|
|
Thanks Ben. It's neat to have Spec models for tree columns. It was
strange to instantiate MorphTreeColumnMorph directly from my Spec model. I found an issue in TreeModel: Only one level of children is shown. Reproduce with: TreeModel new roots: (1 to: 5); childrenBlock: [ :item | 1+item to: 5+item ]; openWithSpec Should I report? Martín On Tue, Nov 12, 2013 at 2:59 PM, Benjamin <[hidden email]> wrote: > It’s this one: https://pharo.fogbugz.com/default.asp?12135 > > Ben > > On 12 Nov 2013, at 14:49, Martin Dias <[hidden email]> wrote: > > I forgot to specify: in latest Pharo (30565) > > On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <[hidden email]> wrote: > > I think there is some issue with TreeColumnModel. For example: > > TreeModel exampleWithCustomColumnsAndNodes > > Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" > > Should I report in fogbugz? > > thanks, > Martín > > On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse > <[hidden email]> wrote: > > Yes this is what I did for the change sorter. I do not like this DSL like > way of passing block over block over block > over blocks. > > I love blocks but methods are named blocks and I prefer them. > > Stef > > biut that method can be written: > > aMenu addGroup: (MenuGroupModel new > addItem: (MenuItemModel new > name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix); > addItem: (MenuItem new > name: 'Browse Class'; > action: [ self browseSelectedObjectClass ])). > > and you do not have to declare variables for that (and is a lot better than > using a block, IMO). > > > > On Nov 12, 2013, at 9:36 AM, Benjamin <[hidden email]> > wrote: > > One can just use an object too. > > It’s just that otherwise, it pollutes a bit the method with tons of inst > vars > (and then you forget to use them :P) > > Ben > > On 12 Nov 2013, at 13:05, Esteban Lorenzano <[hidden email]> wrote: > > > On Nov 12, 2013, at 4:22 AM, Benjamin <[hidden email]> > wrote: > > It is not necessary better, but it saves you from having hundreds of temp > vars :) > > Ben > > On 12 Nov 2013, at 01:49, Stéphane Ducasse <[hidden email]> > wrote: > > > 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 ] ] ]. > > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > > he, I thought the same :) > > > Stef > > > > > > > > |
|
|
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <[hidden email]> wrote: > Thanks Ben. It's neat to have Spec models for tree columns. It was > strange to instantiate MorphTreeColumnMorph directly from my Spec > model. > > I found an issue in TreeModel: Only one level of children is shown. > Reproduce with: > > TreeModel new > roots: (1 to: 5); > childrenBlock: [ :item | 1+item to: 5+item ]; > openWithSpec > > Should I report? > > Martín > > On Tue, Nov 12, 2013 at 2:59 PM, Benjamin > <[hidden email]> wrote: >> It’s this one: https://pharo.fogbugz.com/default.asp?12135 >> >> Ben >> >> On 12 Nov 2013, at 14:49, Martin Dias <[hidden email]> wrote: >> >> I forgot to specify: in latest Pharo (30565) >> >> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <[hidden email]> wrote: >> >> I think there is some issue with TreeColumnModel. For example: >> >> TreeModel exampleWithCustomColumnsAndNodes >> >> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" >> >> Should I report in fogbugz? >> >> thanks, >> Martín >> >> On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse >> <[hidden email]> wrote: >> >> Yes this is what I did for the change sorter. I do not like this DSL like >> way of passing block over block over block >> over blocks. >> >> I love blocks but methods are named blocks and I prefer them. >> >> Stef >> >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than >> using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <[hidden email]> >> wrote: >> >> One can just use an object too. >> >> It’s just that otherwise, it pollutes a bit the method with tons of inst >> vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <[hidden email]> wrote: >> >> >> On Nov 12, 2013, at 4:22 AM, Benjamin <[hidden email]> >> wrote: >> >> It is not necessary better, but it saves you from having hundreds of temp >> vars :) >> >> Ben >> >> On 12 Nov 2013, at 01:49, Stéphane Ducasse <[hidden email]> >> wrote: >> >> >> 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 ] ] ]. >> >> >> I do not see the value of passing block to add element to groups >> why not the normal way i.e. passing an object. I do not get why executing >> a block with an object is better? >> >> >> he, I thought the same :) >> >> >> Stef >> >> >> >> >> >> >> >> |
Re: Spec new release :)
|
|
Confirmed and fixed :P
Ben On 12 Nov 2013, at 17:08, Martin Dias <[hidden email]> wrote: (Checked in Pharo 30567) |
|
Is there any new documentation planned ? On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <[hidden email]> wrote:
|
Re: Spec new release :)
|
|
Yes it is planned :)
The idea is to have it ready for the release of Pharo 3.0 (at last). There is a git repo I just opened[1] where the doc will be :) Every body is free to fork it and to pull-request me :) On 12 Nov 2013, at 23:09, kilon alios <[hidden email]> wrote:
|
|
|
Ben it would be good to do it pier format so that we get html and pdf
and also to avoid to have documentation spread all over. Stef On Nov 12, 2013, at 11:42 PM, Benjamin <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |