On 23.03.2015, at 11:43, Levente Uzonyi <leves at elte.hu> wrote:

> On Mon, 23 Mar 2015, Tobias Pape wrote:
> 
>> Hi Levente,
>> 
>> [Sorry for the late reply]
>> 
>> 
>> On 19.03.2015, at 23:39, Levente Uzonyi <leves at elte.hu> wrote:
>> 
>>> The implementation looks very similar to what Balázs did back in 2010 to the Docking Bar[1], even though his changes never made it into the Trunk.
>>> One main difference I see is that he used a single "pragma", instead of two separate "pragmas". Performance-wise a single "pragma" is better. Is there any advantage of using two "pragmas", instead of one?
>>> 
>> 
>> In spirit, these implementations indeed are similar. Balázs' code however
>> only deals with the World main docking bar while _this_ proposal deals
>> with context menus in tools like the browser.
> 
> That's exactly what I meant. My point is that the two should be quite similar.
> 
>> 
>> I don't understand what you mean by “Performance-wise a single "pragma" is better”.
>> Can you elaborate a bit?
> 
> Using two separate "pragmas" means that you have to look up the priority in a separate query for each entry. While using a single "pragma", the priority is available without these extra lookups.
> 

Ok, I thought you meant that.
The point is that I want to make the simple case (just a menu)
very simple:

	• Create an instance of MenuMorph or similar.
	• Create a method that should build the menu entries:
		someMenu: aMenu
		    <myMenu>
		    ^ aMenu addList: #(
		            ('use'      use)
		            ('remove'   remove)
		            ('copy'     copyName));
		        yourself
	• Send `self menu: aMorph for: #myMenu`

(that should be it) but complex cases possible nonetheless.

I don't want to bother the average tool writer with shifted states, priorities or whatnot.
I have seen Pragma>>allNamed:in:sortedByArgument:, but I cannot handle
default values with that.

Do you think performance is actually a bottleneck here?

Best
	-Tobias


> Levente
> 
>> 
>> Best
>> 	-Tobias
>> 
>> 
>>> Levente
>>> 
>>> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149345.html
>>> 
>>> On Wed, 18 Mar 2015, Tobias Pape wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On 18.03.2015, at 15:11, commits at source.squeak.org wrote:
>>>> 
>>>>> A new version of Tools was added to project The Inbox:
>>>>> http://source.squeak.org/inbox/Tools-topa.556.mcz
>>>>> 
>>>>> ==================== Summary ====================
>>>>> 
>>>>> Name: Tools-topa.556
>>>>> Author: topa
>>>>> Time: 18 March 2015, 4:09:54.221 pm
>>>>> UUID: 563dd431-ffbf-43b8-b78f-79a7a55f924d
>>>>> Ancestors: Tools-topa.555
>>>>> 
>>>>> Pluggable Menus for many tools
>>>>> ==============================
>>>>> 
>>>>> A lot of tools, especially the Browser, rely on context menus
>>>>> (aka yellow button menus). Dynamically extending these is possible
>>>>> but requires a lot of care. The Pluggable Menus allow to add menu
>>>>> entries easily via extension methods. The Services package serves
>>>>> as example here.
>>>> 
>>>> An easier to read version of the commit message is at https://gist.github.com/krono/5f7f5197df5f1d1da052.
>>>> 
>>>> If nobody objects, I move this to trunk on friday :)
>>>> 
>>>> Best
>>>> 	-Tobias