[Squeak-dev] World Menu Registry
Locked
123
123
[Squeak-dev] World Menu Registry
 
|
I have published this morning to Squeak Source a package that provides broader menu registry capability to the World Menu. The package is WorldMenuRegistry-sbw.1.mcz. With this package installed into Squeak 4.1, a developer can easily extend, and later on remove if required, menus entries for the following World menus using a registry system:
open - Already existed and works with this package without changing existing entries appearance changes project help There is also a unit test which exercises each of these menus and can be perused for examples of menu registry use. The next step is to enhance the new menu/world dock to add registry support. When all of that is working, I'll publish an update to the Desktop Background Screens package that will use the new menu registries dynamically. Cheers, - Steve |
|
|
On 25.04.2010, at 16:58, Stephan Wessels wrote:
> I have published this morning to Squeak Source a package that provides broader menu registry capability to the World Menu. The package is WorldMenuRegistry-sbw.1.mcz. As I said previously about the DesktopBackgroundLoader package this is not the right way to package your changes for the trunk. You must not make a package that modifies the Morphic package. Instead, please commit an updated Morphic package to the inbox (take a look at the packages I mention below for an example). There are now two contenders for customizing the docking bar in the inbox, Morphic-kb.428 and Morphic-phite.428. We should discuss the advantages of either approach in this thread. And I think it would be a good idea to unify the docking bar registry and the world menu registry - at least they should use a similar mechanism. - Bert - |
|
|
On Apr 25, 2010, at 5:28 PM, Bert Freudenberg wrote: > On 25.04.2010, at 16:58, Stephan Wessels wrote: >> I have published this morning to Squeak Source a package that >> provides broader menu registry capability to the World Menu. The >> package is WorldMenuRegistry-sbw.1.mcz. > > As I said previously about the DesktopBackgroundLoader package this > is not the right way to package your changes for the trunk. You must > not make a package that modifies the Morphic package. Instead, > please commit an updated Morphic package to the inbox (take a look > at the packages I mention below for an example). I've published a version to the trunk that does not modify any outside methods. The latest version published takes advantage of the dock refactoring published to the trunk in Morphic-kb.428. If we choose not to go ahead with those changes I'll change my code again. > > There are now two contenders for customizing the docking bar in the > inbox, Morphic-kb.428 and Morphic-phite.428. We should discuss the > advantages of either approach in this thread. And I think it would > be a good idea to unify the docking bar registry and the world menu > registry - at least they should use a similar mechanism. Unifying the docking bar and world menu registry is a good idea and I would like to see a uniform approach. I'm frankly unattached to how we do it just that we get over this and do it. It's an old problem with multiple solutions proposed in the past. We should pick a strategy and go forward. And to further minimize churn I recommend that if someone is going to write this code it should be stated here and we can all evaluate it. > > - Bert - > > |
|
|
My mistake. I see you were no longer referring to the desktop loader
code. It seems to me that I should hold off publishing any revision to the world menu registry stuff until we get some discussion resolved about the approach to take with both the dock and regular menus. If we agree that the registry approach makes sense it would be a trivial matter for me to update the previous code so that it's a proper Morphic update. On Apr 25, 2010, at 9:39 PM, Steve Wessels wrote: > > On Apr 25, 2010, at 5:28 PM, Bert Freudenberg wrote: > >> On 25.04.2010, at 16:58, Stephan Wessels wrote: >>> I have published this morning to Squeak Source a package that >>> provides broader menu registry capability to the World Menu. The >>> package is WorldMenuRegistry-sbw.1.mcz. >> >> As I said previously about the DesktopBackgroundLoader package this >> is not the right way to package your changes for the trunk. You >> must not make a package that modifies the Morphic package. Instead, >> please commit an updated Morphic package to the inbox (take a look >> at the packages I mention below for an example). > > I've published a version to the trunk that does not modify any > outside methods. The latest version published takes advantage of > the dock refactoring published to the trunk in Morphic-kb.428. If > we choose not to go ahead with those changes I'll change my code > again. > >> >> There are now two contenders for customizing the docking bar in the >> inbox, Morphic-kb.428 and Morphic-phite.428. We should discuss the >> advantages of either approach in this thread. And I think it would >> be a good idea to unify the docking bar registry and the world menu >> registry - at least they should use a similar mechanism. > > Unifying the docking bar and world menu registry is a good idea and > I would like to see a uniform approach. I'm frankly unattached to > how we do it just that we get over this and do it. It's an old > problem with multiple solutions proposed in the past. We should > pick a strategy and go forward. And to further minimize churn I > recommend that if someone is going to write this code it should be > stated here and we can all evaluate it. > >> >> - Bert - >> >> > > |
|
|
In reply to this post by Bert Freudenberg
On Mon, 2010-04-26 at 00:28 +0200, Bert Freudenberg wrote:
> There are now two contenders for customizing the docking bar in the inbox, > Morphic-kb.428 and Morphic-phite.428. We should discuss the advantages of > either approach in this thread. And I think it would be a good idea to unify > the docking bar registry and the world menu registry - at least they should > use a similar mechanism. I like Philipp's approach to unify the world menu and the bar, however, as we are starting to use pragmas for preferences as well, we might want to go into the direction of pragmas for different kinds of configurable behaviour. Then again, windowColorSpecs work much like Philipp's approach, too, and I like and understand them (not to mention I can easy and fast grep for 'Specification' using Cmd+W). I would tend to favor Philipp's approach right now, especially as as adding nested menus seems more straightforward to me. But we might want to start generalizing configuration and if we use pragmas for that a newcomer might find it easier to recognize configurations as such. Just my 2 pieces of eight -Tim |
|
|
The "Pragma" approach is easier to utilize in code. However we are
giving up the ability to dynamically change menu contents with that approach. Yes, we can modify a menu on install and release of a package, and that's currently the immediate problem we are trying to solve. But if a developer wants the application to change a menu dynamically after the package is installed, I don't think the coded "pragma" approach will work. I may be the only voice asking for real dfynamic menu management. - Steve On Apr 26, 2010, at 8:31 AM, Tim Felgentreff <[hidden email]> wrote: > On Mon, 2010-04-26 at 00:28 +0200, Bert Freudenberg wrote: >> There are now two contenders for customizing the docking bar in the >> inbox, >> Morphic-kb.428 and Morphic-phite.428. We should discuss the >> advantages of >> either approach in this thread. And I think it would be a good idea >> to unify >> the docking bar registry and the world menu registry - at least >> they should >> use a similar mechanism. > > I like Philipp's approach to unify the world menu and the bar, > however, > as we are starting to use pragmas for preferences as well, we might > want > to go into the direction of pragmas for different kinds of > configurable > behaviour. > Then again, windowColorSpecs work much like Philipp's approach, too, > and > I like > and understand them (not to mention I can easy and fast grep for > 'Specification' using Cmd+W). > I would tend to favor Philipp's approach right now, especially as as > adding nested menus seems more straightforward to me. But we might > want > to start generalizing configuration and if we use pragmas for that a > newcomer might find it easier to recognize configurations as such. > > Just my 2 pieces of eight > -Tim > > |
|
|
On 4/26/10, Steve Wessels <[hidden email]> wrote:
> The "Pragma" approach is easier to utilize in code. However we are > giving up the ability to dynamically change menu contents with that > approach. Yes, we can modify a menu on install and release of a > package, and that's currently the immediate problem we are trying to > solve. But if a developer wants the application to change a menu > dynamically after the package is installed, I don't think the coded > "pragma" approach will work. > > I may be the only voice asking for real dfynamic menu management. > > - Steve > You are not the only one asking for dynamic menu management. The ability to change a menu dynamically is a _MUST_ these days. Programs coded in C++ do this as well. -- Hannes |
|
|
On Mon, 26 Apr 2010, Hannes Hirzel wrote:
> On 4/26/10, Steve Wessels <[hidden email]> wrote: >> The "Pragma" approach is easier to utilize in code. However we are >> giving up the ability to dynamically change menu contents with that >> approach. Yes, we can modify a menu on install and release of a >> package, and that's currently the immediate problem we are trying to >> solve. But if a developer wants the application to change a menu >> dynamically after the package is installed, I don't think the coded >> "pragma" approach will work. >> >> I may be the only voice asking for real dfynamic menu management. >> >> - Steve >> > > You are not the only one asking for dynamic menu management. The > ability to change a menu dynamically is a _MUST_ these days. Programs > coded in C++ do this as well. Can C++ programs do it in another way? How dynamic should the menu management be? How complicated should it be? What about thread-safety? Should it be compatible with other forks? Levente > > -- Hannes > > |
|
|
In reply to this post by Steve Wessels-2
On Mon, Apr 26, 2010 at 8:54 AM, Steve Wessels <[hidden email]> wrote: The "Pragma" approach is easier to utilize in code. However we are giving up the ability to dynamically change menu contents with that approach. Yes, we can modify a menu on install and release of a package, and that's currently the immediate problem we are trying to solve. But if a developer wants the application to change a menu dynamically after the package is installed, I don't think the coded "pragma" approach will work. In the VW scheme there is the possibility to add an enablement selector and an indication selector, which between them decide whether an entry is visible and whether it is enabled. So there's nothing in the pragma approach per se that prevents dynamic menus.
e.g. browseVersions <menuItem: #(#Versions #store 'Versions') nameKey: nil
enablement: #areConnectedAndSelected indication: nil menu: #(#listMenu)
position: 90.01> DbRegistry doIfOnlineImage: [ self selection notNil
ifTrue: [ self spawningBrowserClass browseVersionsOfNamespaceOrClass: self selection ] ]
|
|
|
That would work splendidly. In fact, that's lovely because you would create your own "private" registry and then kill it when your code leaves. A blended approach like this covers my concern and I admit I never considered it. Silly of me. Thanks for the tip. - Steve
|
|
|
On Mon, Apr 26, 2010 at 11:20 AM, Steve Wessels <[hidden email]> wrote:
You're welcome! But if you add it use visible: and enabled:, I thing VW's is very confusing. enabled: means visible and indication: means enabled: :)
|
|
|
In reply to this post by Steve Wessels-2
On 26.04.2010, at 20:20, Steve Wessels wrote:
Philipp, do you see any strong advantage your registry-based variant would have over that? - Bert - |
|
|
The consensus so far is that you can do dynamic menus with the pragma
based approach as well. Bert, what you call here 'annotation based' is called 'Pragma' in the code. Which is confusing, see the other thread. I prefer the registry-based approach. --Hannes On 4/26/10, Bert Freudenberg <[hidden email]> wrote: > On 26.04.2010, at 20:20, Steve Wessels wrote: >> That would work splendidly. In fact, that's lovely because you would >> create your own "private" registry and then kill it when your code leaves. >> >> >> A blended approach like this covers my concern and I admit I never >> considered it. Silly of me. Thanks for the tip. >> >> - Steve >> >> On Apr 26, 2010, at 1:12 PM, Eliot Miranda <[hidden email]> >> wrote: >> >>> >>> >>> On Mon, Apr 26, 2010 at 8:54 AM, Steve Wessels >>> <[hidden email]> wrote: >>> The "Pragma" approach is easier to utilize in code. However we are >>> giving up the ability to dynamically change menu contents with that >>> approach. Yes, we can modify a menu on install and release of a package, >>> and that's currently the immediate problem we are trying to solve. But >>> if a developer wants the application to change a menu dynamically after >>> the package is installed, I don't think the coded "pragma" approach will >>> work. >>> >>> In the VW scheme there is the possibility to add an enablement selector >>> and an indication selector, which between them decide whether an entry is >>> visible and whether it is enabled. So there's nothing in the pragma >>> approach per se that prevents dynamic menus. >>> >>> e.g. >>> >>> browseVersions >>> <menuItem: #(#Versions #store 'Versions') >>> nameKey: nil >>> enablement: #areConnectedAndSelected >>> indication: nil >>> menu: #(#listMenu) >>> position: 90.01> >>> >>> DbRegistry doIfOnlineImage: >>> [ self selection notNil >>> ifTrue: [ self spawningBrowserClass browseVersionsOfNamespaceOrClass: >>> self selection ] >>> ] >>> >>> >>> I may be the only voice asking for real dfynamic menu management. >>> >>> - Steve >>> >>> >>> On Apr 26, 2010, at 8:31 AM, Tim Felgentreff <[hidden email]> wrote: >>> >>> On Mon, 2010-04-26 at 00:28 +0200, Bert Freudenberg wrote: >>> There are now two contenders for customizing the docking bar in the >>> inbox, >>> Morphic-kb.428 and Morphic-phite.428. We should discuss the advantages >>> of >>> either approach in this thread. And I think it would be a good idea to >>> unify >>> the docking bar registry and the world menu registry - at least they >>> should >>> use a similar mechanism. >>> >>> I like Philipp's approach to unify the world menu and the bar, however, >>> as we are starting to use pragmas for preferences as well, we might want >>> to go into the direction of pragmas for different kinds of configurable >>> behaviour. >>> Then again, windowColorSpecs work much like Philipp's approach, too, and >>> I like >>> and understand them (not to mention I can easy and fast grep for >>> 'Specification' using Cmd+W). >>> I would tend to favor Philipp's approach right now, especially as as >>> adding nested menus seems more straightforward to me. But we might want >>> to start generalizing configuration and if we use pragmas for that a >>> newcomer might find it easier to recognize configurations as such. >>> >>> Just my 2 pieces of eight >>> -Tim >>> >>> >>> >>> >>> >> > > > It seems there is consensus brewing for the annotation-based variant of > Balázs. Which obviously could be extended for to the world menu too. > > Philipp, do you see any strong advantage your registry-based variant would > have over that? > > - Bert - > > > |
|
|
In reply to this post by Bert Freudenberg
Am 26.04.2010 23:27, schrieb Bert Freudenberg:
> It seems there is consensus brewing for the annotation-based variant of Balázs. Which obviously could be extended for to the world menu too. > > Philipp, do you see any strong advantage your registry-based variant would have over that? > > - Bert - > Hello again :) I enjoy reading the discussion as it means everyone seems to get a clearer view of the system and especially pragmas (or whatever we are supposed to call them ;) ) - a pity that I went to bed early that evening. I see and understand most of the arguments, but some stay unclear to me: Am 27.04.2010 02:13, schrieb Igor Stasenko: > MenuEntrySpec newFrom: (Dictionary newFromPairs: #( > contents 'Well... hello?' > help 'Displays the Hello World' > location ('Help') > target MenuMorph selector inform: arguments ('Hello World!') > position first)) > > introducing a rigid factors, because of use of globals (here - > MenuEntrySpec and MenuMorph). BTW: MenuMorph may be a bad example there could be *any* Object (eg. self) associated to target. > > In contrast, if we turn it into a set of declarations like this > > <createDockingBarMenuWithPriority: 50> > <fillDockingBarMenu: #extras priority: 20> How am I supposed to contribute to Extras->Window Colors (say submenus)? Am I right that a method which includes <createDockingBarMenuWithPriority: 50> says: "Hey I am a method that can contribute in creating a Menu in the DockingBar"? If yes, that means we need something along <createMenuFor: #dockingBar WithPriority: 50> to generalize over different menu-systems, right? What about the priority thing. Isn't that fragile? What if someone with a higher priority changes the menu I refer to? How do I get the right priority for the menuEntry I want to create? Also, priorities in other systems have led to people including lots of random, magic numbers in their code (having magic numbers in an annotation is not really any better, is it?). True, strings are "magic", too, but at least I can *see* them in the menu. I can *see* where my item is going to show up, as opposed to trying to find out from code. To get to the point of "introducing rigid factors" by using globals: The method which uses pragmas/annotations should look somehow like the following, right?: MyMenuMethod: extrasMenu "Adds myMenu to the Extras-menu" <fillDockingBarMenu: #extras priority: 20> extrasMenu subMenu addItem: [ :item | item contents: 'MyMenu'; ... ] I see my approach in those issues somehow equal to the pragma-approach. A class says: "Hello, I offer you a menuSpec to integrate into your menu" by implementing #menuEntrySpecification. As MenuSpecs are created with Dictionaries - you can change the things (eg. by adding a new menu-system besided DockingBar and WorldMenu) without braking any code (by adding new possible options the dictionary takes). If you do not like to use the MenuEntrySpec global - it is easy to get rid of it. (Make class implement #menuItemFrom: aDict, which answers the MenuEntrySpec instance. So you could write: self menuEntryFrom: (Dictionary newFromPairs: { ... }) I could go on with more points.. but to cut a long story short: I see both approaches somehow equal. (Just different in style) It looks like most people prefer the pragma-style as we already use them for preferences and may use them for system-changing-things in general. I am perfectly fine with Balázs' approach if it supports the following points (or is able to support that in the near future): - it unifies both (and possibly more) menu types - allows adding/removing menus dynamically (as I've shown in http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149641.html) - is easy to use ( it allows short, readable code for contributing to menus; readable, documented code for the implementation) - allows positioning (eg.: I want my menu to be shown just before the Help-menu; I want my menu to be placed in some sub-menu) without reverting to some magic numbers - changing things (eg. adding a on-click-highlight-color or something) doesn't break existing code As far as I this is already done or is at least possible (Am I right? I'm not sure on the dynamically adding menus issue). May the DockingBar be with you :) Philpp |
|
Administrator
|
Pharo 1.1 uses annotations for both preferences and the world menu.
It would be very nice (for both forks) if we could be compatible on such a fundamental piece of integration with the system, so that projects, especially tools, will not have to manage platform-specific code for both forks (I've already run into this with SSpec and my own projects). Of course, not at the expense of coming up with something that blows the approach out of the water, but why not lean toward compatibility and make everyone's lives easier. Also, it seems like all these points would have been thought of when Pharo implemented. And, more importantly, the users have some experience with using the annotation approach. I'll post a link to this thread to the pharo project list. Sean
Cheers,
Sean |
|
|
Thank you Sean for pointing out this important fact.
--Hannes On 4/27/10, Sean P. DeNigris <[hidden email]> wrote: > > Pharo 1.1 uses annotations for both preferences and the world menu. > > It would be very nice (for both forks) if we could be compatible on such a > fundamental piece of integration with the system, so that projects, > especially tools, will not have to manage platform-specific code for both > forks (I've already run into this with SSpec and my own projects). > > Of course, not at the expense of coming up with something that blows the > approach out of the water, but why not lean toward compatibility and make > everyone's lives easier. > > Also, it seems like all these points would have been thought of when Pharo > implemented. And, more importantly, the users have some experience with > using the annotation approach. > > I'll post a link to this thread to the pharo project list. > > Sean > -- > View this message in context: > http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067703.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > |
|
Administrator
|
I will post replies I get in pharo-project here as a resource in this conversation:
Pharo menus can have pre-condition blocks: Hi Sean, you can declare a menu item with a precondition block. the menu item is not added to the menu if the precondition is false. We have one example in the core. See the precondition in the #'Software update' item. WorldState class>>systemOn: aBuilder <worldMenu> (aBuilder item: #System) order: 4.0; withSeparatorAfter; icon: MenuIcons smallConfigurationIcon; with: [ (aBuilder item: #'About...') order: 0; action: [Smalltalk aboutThisSystem]. (aBuilder item: #'Software update') order: 1; precondition: [self showUpdateOptionInWorldMenu]; action: [Utilities updateFromServer]; help: 'Load latest code updates via the internet'] A take on the pros and cons of existing preference style v.s. Pharo menu style: Comparing Settings to Preference Annotations might gleam at the difference you might expect between menu annotations in Pharo and Squeak. In Pharo the method contains a simple annotation with no args, and the method contains code for building a menuitem using the builder passed as argument, My speculation: If following the existing preference-style, Squeak will probably use an annotation with more args, with the method body containing the actual action. i.e. Alains example would be written something like: WorldState class>>aboutMenuItem <menuItemIn: #('WorldMenu' 'System') order: 0 label: 'About... '> Smalltalk aboutThisSystem WorldState>>updateFromServertMenuItem <menuItemIn: #('WorldMenu' 'System') order: 1 label: 'About... ' visible: #showUpdateOptionInWorldMenu help: 'Load latest code updates via the internet'> Utilites updateFromServer Both approaches have their pros and cons. The one in Pharo depends on a builder responding to certain messages, so expanding the API might lead to breakage if you try to load into an old image. You also have to define new annotation keywords for each menu you want to build this way, . The one for Squeak might suffer a risk of needing a large amount of permutations of annotations , depending on which PluggableMenuItemSpec properties you'd want to be able to leave optional. In short: In Pharo you have access to the builder in the method, while in Squeak (based on how Preferences annotations work) I'd expect they end up with a builder parsing an annotation instead.
Cheers,
Sean |
|
|
2010/4/27 Sean P. DeNigris <[hidden email]>:
> > I will post replies I get in pharo-project here as a resource in this > conversation: > > Pharo menus can have pre-condition blocks: > Hi Sean, > you can declare a menu item with a precondition block. > the menu item is not added to the menu if the precondition is false. > We have one example in the core. See the precondition in the #'Software > update' item. > > WorldState class>>systemOn: aBuilder > <worldMenu> > (aBuilder item: #System) > order: 4.0; > withSeparatorAfter; > icon: MenuIcons smallConfigurationIcon; > with: [ > (aBuilder item: #'About...') > order: 0; > action: [Smalltalk aboutThisSystem]. > (aBuilder item: #'Software update') > order: 1; > precondition: [self showUpdateOptionInWorldMenu]; > action: [Utilities updateFromServer]; > help: 'Load latest code updates via the internet'] > > A take on the pros and cons of existing preference style v.s. Pharo menu > style: > Comparing Settings to Preference Annotations might gleam at the difference > you might expect between menu annotations in Pharo and Squeak. > > In Pharo the method contains a simple annotation with no args, and the > method contains code for building a menuitem using the builder passed as > argument, > My speculation: If following the existing preference-style, Squeak will > probably use an annotation with more args, with the method body containing > the actual action. > i.e. Alains example would be written something like: > WorldState class>>aboutMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 0 > label: 'About... '> > Smalltalk aboutThisSystem > > WorldState>>updateFromServertMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 1 > label: 'About... ' > visible: #showUpdateOptionInWorldMenu > help: 'Load latest code updates via the internet'> > Utilites updateFromServer > > > Both approaches have their pros and cons. > The one in Pharo depends on a builder responding to certain messages, so > expanding the API might lead to breakage if you try to load into an old > image. > You also have to define new annotation keywords for each menu you want to > build this way, . > > The one for Squeak might suffer a risk of needing a large amount of > permutations of annotations , depending on which PluggableMenuItemSpec > properties you'd want to be able to leave optional. > Would it be possible to use known techniques like cascading? <menuItemIn: #('WorldMenu' 'System'); order: 1; label: 'About... '; visible: #showUpdateOptionInWorldMenu; help: 'Load latest code updates via the internet'> The idea would be to send messages to a Builder. The builder would have a current target (created by #menuItemIn:) to which subsequent messages would be sent... Not sure at all cascading is allowed now, but it eventually could. > In short: In Pharo you have access to the builder in the method, while in > Squeak (based on how Preferences annotations work) I'd expect they end up > with a builder parsing an annotation instead. > My first impression is that while Pharo is reacher, it is also weaker w.r.t. core system evolutions because exposing more API. The difference is subtle though, because my above cascade example is also exposing an API... But it is different : we don't have to just execute the cascade, we could catch and ignore every not-understood message, and proceed with the next one... ... or we could also preprocess and transform the messages etc... One advantage of Pharo is the possibility to insert a halt in the constructing phase, but hey, we could place a halt: in the cascade too... Pharo solution also gives reflection on the builder, which is powerfull, the pragma/annotation does not. If we can't agree though, the nice thing with pragmas/annotations is that both menu declaration can co-exist (as long as keyword don't conflict). Package developpers would have to provide two hooks, and code critics might complain of some missing API, but that's not a drama. Nicolas > -- > View this message in context: http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > |
|
|
What are the reasons for not going for the Pharo solution?
--Hannes On 4/27/10, Nicolas Cellier <[hidden email]> wrote: > 2010/4/27 Sean P. DeNigris <[hidden email]>: >> >> I will post replies I get in pharo-project here as a resource in this >> conversation: >> >> Pharo menus can have pre-condition blocks: >> Hi Sean, >> you can declare a menu item with a precondition block. >> the menu item is not added to the menu if the precondition is false. >> We have one example in the core. See the precondition in the #'Software >> update' item. >> >> WorldState class>>systemOn: aBuilder >> <worldMenu> >> (aBuilder item: #System) >> order: 4.0; >> withSeparatorAfter; >> icon: MenuIcons smallConfigurationIcon; >> with: [ >> (aBuilder item: #'About...') >> order: 0; >> action: [Smalltalk aboutThisSystem]. >> (aBuilder item: #'Software update') >> order: 1; >> precondition: [self showUpdateOptionInWorldMenu]; >> action: [Utilities updateFromServer]; >> help: 'Load latest code updates via the internet'] >> >> A take on the pros and cons of existing preference style v.s. Pharo menu >> style: >> Comparing Settings to Preference Annotations might gleam at the difference >> you might expect between menu annotations in Pharo and Squeak. >> >> In Pharo the method contains a simple annotation with no args, and the >> method contains code for building a menuitem using the builder passed as >> argument, >> My speculation: If following the existing preference-style, Squeak will >> probably use an annotation with more args, with the method body containing >> the actual action. >> i.e. Alains example would be written something like: >> WorldState class>>aboutMenuItem >> <menuItemIn: #('WorldMenu' 'System') >> order: 0 >> label: 'About... '> >> Smalltalk aboutThisSystem >> >> WorldState>>updateFromServertMenuItem >> <menuItemIn: #('WorldMenu' 'System') >> order: 1 >> label: 'About... ' >> visible: #showUpdateOptionInWorldMenu >> help: 'Load latest code updates via the internet'> >> Utilites updateFromServer >> >> >> Both approaches have their pros and cons. >> The one in Pharo depends on a builder responding to certain messages, so >> expanding the API might lead to breakage if you try to load into an old >> image. >> You also have to define new annotation keywords for each menu you want to >> build this way, . >> >> The one for Squeak might suffer a risk of needing a large amount of >> permutations of annotations , depending on which PluggableMenuItemSpec >> properties you'd want to be able to leave optional. >> > > Would it be possible to use known techniques like cascading? > <menuItemIn: #('WorldMenu' 'System'); > order: 1; > label: 'About... '; > visible: #showUpdateOptionInWorldMenu; > help: 'Load latest code updates via the internet'> > The idea would be to send messages to a Builder. > The builder would have a current target (created by #menuItemIn:) to > which subsequent messages would be sent... > Not sure at all cascading is allowed now, but it eventually could. > >> In short: In Pharo you have access to the builder in the method, while in >> Squeak (based on how Preferences annotations work) I'd expect they end up >> with a builder parsing an annotation instead. >> > > My first impression is that while Pharo is reacher, it is also weaker > w.r.t. core system evolutions because exposing more API. > The difference is subtle though, because my above cascade example is > also exposing an API... > But it is different : we don't have to just execute the cascade, we > could catch and ignore every not-understood message, and proceed with > the next one... > ... or we could also preprocess and transform the messages etc... > > One advantage of Pharo is the possibility to insert a halt in the > constructing phase, but hey, we could place a halt: in the cascade > too... > Pharo solution also gives reflection on the builder, which is > powerfull, the pragma/annotation does not. > > If we can't agree though, the nice thing with pragmas/annotations is > that both menu declaration can co-exist (as long as keyword don't > conflict). > Package developpers would have to provide two hooks, and code critics > might complain of some missing API, but that's not a drama. > > Nicolas > >> -- >> View this message in context: >> http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> >> > > |
|
|
In reply to this post by Sean P. DeNigris
Good summary, but some things are better explained in a more persistent
format, so I've written up the motivation here: http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/ (does anyone know how to fix up the font for <pre> at wordpress?) Cheers, - Andreas On 4/27/2010 9:45 AM, Sean P. DeNigris wrote: > > I will post replies I get in pharo-project here as a resource in this > conversation: > > Pharo menus can have pre-condition blocks: > Hi Sean, > you can declare a menu item with a precondition block. > the menu item is not added to the menu if the precondition is false. > We have one example in the core. See the precondition in the #'Software > update' item. > > WorldState class>>systemOn: aBuilder > <worldMenu> > (aBuilder item: #System) > order: 4.0; > withSeparatorAfter; > icon: MenuIcons smallConfigurationIcon; > with: [ > (aBuilder item: #'About...') > order: 0; > action: [Smalltalk aboutThisSystem]. > (aBuilder item: #'Software update') > order: 1; > precondition: [self showUpdateOptionInWorldMenu]; > action: [Utilities updateFromServer]; > help: 'Load latest code updates via the internet'] > > A take on the pros and cons of existing preference style v.s. Pharo menu > style: > Comparing Settings to Preference Annotations might gleam at the difference > you might expect between menu annotations in Pharo and Squeak. > > In Pharo the method contains a simple annotation with no args, and the > method contains code for building a menuitem using the builder passed as > argument, > My speculation: If following the existing preference-style, Squeak will > probably use an annotation with more args, with the method body containing > the actual action. > i.e. Alains example would be written something like: > WorldState class>>aboutMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 0 > label: 'About... '> > Smalltalk aboutThisSystem > > WorldState>>updateFromServertMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 1 > label: 'About... ' > visible: #showUpdateOptionInWorldMenu > help: 'Load latest code updates via the internet'> > Utilites updateFromServer > > > Both approaches have their pros and cons. > The one in Pharo depends on a builder responding to certain messages, so > expanding the API might lead to breakage if you try to load into an old > image. > You also have to define new annotation keywords for each menu you want to > build this way, . > > The one for Squeak might suffer a risk of needing a large amount of > permutations of annotations , depending on which PluggableMenuItemSpec > properties you'd want to be able to leave optional. > > In short: In Pharo you have access to the builder in the method, while in > Squeak (based on how Preferences annotations work) I'd expect they end up > with a builder parsing an annotation instead. > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |