[squeak-dev] The Inbox: Tools-topa.556.mcz
Tobias Pape
Das.Linux at gmx.de
Mon Mar 23 19:37:49 UTC 2015
On 23.03.2015, at 18:25, Levente Uzonyi <leves at elte.hu> wrote:
> The focus of this thread shifted towards performance, but that was just an advantage of using one "pragma" instead of two (or more).
> My question about the implementation was:
>
>> Is there any advantage of using two "pragmas", instead of one?
>
> You pointed out one such advantage: it keeps the simplest use case very simple.
> But do priorities add much complexity?
> For example: is <myMenu> - from the user's point of view - significantly simpler than <myMenu: 500> or <myMenu: nil> or <myMenu: #defaultPriority>?
> How common is this use case? How often will people not want to tweak the priority, but use the alphabetical sort order instead?
>
My view is:
I just want to add a menu entry. I am out of control what else
goes into the menu in any case, so _typically_ I want my
menu entry (or submenu) just show up. And yes, just putting <messageListMenu> there
is imho significantly simpler than having to think about
<myMenu: 500> or <myMenu: nil> or <myMenu: #defaultPriority>
because that tries to convey two concerns with one message. it also
reads strange. What read better would be
<myMenuWithPriority: 500> or <myMenuWithPriority: #default>
(I cannot transform you <myMenu: nil> to a better-reading version,
probably that is too low-level?)
Best
-Tobias
> Levente
>
> On Mon, 23 Mar 2015, Tobias Pape wrote:
>
>>
>> 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:
More information about the Squeak-dev
mailing list
|