[Squeak-dev] World Menu Registry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Squeak-dev] World Menu Registry

stevewessels
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



Reply | Threaded
Open this post in threaded view
|

Menu Registries

Bert Freudenberg
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 -


Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Steve Wessels-2

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 -
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Steve Wessels-2
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 -
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Tim Felgentreff
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


Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Steve Wessels-2
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Hannes Hirzel
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

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Levente Uzonyi-2
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Eliot Miranda-2
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 ]
]


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






Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Steve Wessels-2
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







Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Eliot Miranda-2


On Mon, Apr 26, 2010 at 11:20 AM, Steve Wessels <[hidden email]> 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.

 
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: :)


- 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][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][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











Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Bert Freudenberg
In reply to this post by Steve Wessels-2
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][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][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 -




Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Hannes Hirzel
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 -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Philipp Tessenow-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Hannes Hirzel
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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Nicolas Cellier
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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Hannes Hirzel
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.
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Menu Registries

Andreas.Raab
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.
>


123