[squeak-dev] menu pragmas (was "The Trunk:
Monticello-eem.617.mcz")
Tobias Pape
Das.Linux at gmx.de
Thu Sep 3 06:44:57 UTC 2015
Hi all
On 03.09.2015, at 01:21, Craig Latta <craig at netjam.org> wrote:
>
> Hi all--
>
> This is just a new thread to make Eliot's description of menu
> pragmas more prominent in the list archives. Perhaps there are others
> who, like me, don't read all the "trunk" threads in their entirety and
> might miss stuff like this.
I read that and I'll comment on all that later.
Still on vacation and on my way to the beach.
Probably tonight (CEST) :)
Best
-Tobias
>
>
> thanks,
>
> -C
>
> ***
>
> Tobias writes to Eliot:
>
>> Can you explain what you want to achieve [with menu pragmas] and how
>> I can make [their use] more convenient?
>
> Eliot responds:
>
>> We can talk this over when we meet in Palo Alto, but the idea is an
>> important one, and I'm paying for having been too lazy to write it up
>> properly. Let me try and give a quick sketch here.
>>
>> The goals are to:
>>
>> - allow package load to augment menus without the original definitions
>> of those menus knowing anything about the subsequently loaded
>> packages.
>> - to allow menus to be augmented with single actions defined in
>> methods that implement those actions
>> - and, depending on menu implementation, either
>> - if menus are created every time a user invokes a menu, then to
>> simply include the relevant extensions in the menu
>> - if menus are stored in variables, to automatically construct, or
>> reconstruct the menu when either loading or unloading of a package
>> changes the items in a menu
>>
>> We design menu pragmas in action methods to specify:
>
>> - the (name of the) menu to be extended
>> - the text of the menu entry
>> - information regarding what group of items the menu item belongs with
>> - information regarding the menu item's relative order with respect to
>> other elements in the group
>>
>> Rationale:
>> With this specification a package can extend any number of menus in
>> tools simply by being loaded, with no collisions with any other
>> packages defining extensions on those menus. Tools become freely
>> pluggable, and system configurations constructed from different sets
>> of loaded packages are decoupled; we don't need many menu
>> definitions, just an initial base menu which is extended with the
>> current set of extensions.
>>
>> For this to work we need to "name" menus, and to use some numbering
>> scheme to define groups (menu entries between lines) and elements
>> within each group. One simple scheme is to use numbers:
>>
>> - the definitions of initial base menus number groups, so that the
>> first group (the items before the first line) is numbered group 10,
>> and the second group 20, and so on, allowing extensions to specify
>> new groups by using group numbers that are not a multiple of 10
>> - the definitions of entries within groups are numbered, again in
>> multiples of 10, so that the extension can fit anywhere in the
>> group
>>
>> So given:
>>
>> MenuMorph fromArray: {
>> {'find...(f)' translated. #find}.
>> {'find again (g)' translated. #findAgain}.
>> {'set search string (h)' translated. #setSearchString}.
>> #-.
>> {'do again (j)' translated. #again}.
>> {'undo (z)' translated. #undo}.
>> #-.
>> {'copy (c)' translated. #copySelection}.
>> {'cut (x)' translated. #cut}.
>> {'paste (v)' translated. #paste}.
>> {'paste...' translated. #pasteRecent}.
>> #-.
>> {'set font... (k)' translated. #offerFontMenu}.
>> {'set style... (K)' translated. #changeStyle}.
>> {'set alignment...' translated. #chooseAlignment}.
>> "
>> #-.
>> {'more...' translated. #shiftedTextPaneMenuRequest}.
>> "
>> }
>>
>> you could imagine the following numberings:
>>
>> 10.01 find
>> 10.02 findAgain
>> 10.03 setSearchString
>> -
>> 20.01 again
>> 20.02 undo
>> -
>> 30.01 copySelection
>> 30.02 cut
>> 30.03 paste
>> 30.04 pasteRecent
>> -
>> 40.01 offerFontMenu
>> 40.02 changeStyle
>> 40.03 chooseAlignment
>>
>> So I can specify e.g. a new group inserted before the first one by
>> using, e.g. 5.005 as an index, and can slot an item between again and
>> undo using 20.015, etc.
>>
>> This gives us menu pragmas that look like:
>>
>> TextEditor methodsFor: '*SpellChecker-extensions' stamp: 'mad hacker
>> 9/9/1999'
>> spellCheck
>> <menuAction: #yellowButtonMenu
>> label: 'spell check selection (s)'
>> position: 10.035>
>> ...code implementing spell checking...
>>
>> (note that the action, #spellCheck, is implicit, it is the selector of
>> the method containing the pragma)
>>
>> and:
>>
>> - if menus are created every time a user invokes a menu, then search
>> for pragmas within the relevant class hierarchy, compute, sort and
>> insert individual extensions to the menu
>> - if menus are stored in variables, to have compilation and method
>> removal send a message to the class to/from which method(s) are
>> added/removed so that the class can recompute menus (as in the line
>> above) when code is added/removed.
>>
>> What I saw in ChangeSorter was quite different. It seems to be a way
>> of specifying entire menus, and I'm not sure how these menus are to be
>> combined. Maybe I'm misunderstanding the way the scheme is supposed
>> to work. What I've described above is very close to the one that
>> pragmas came from in the first place, which was my attempt to
>> decouple the components that could be loaded into VisualWorks when we
>> decomposed the system into easily loadable parcels. Up until that
>> point VisualWorks had had all its tool menus predefined, disabling
>> items that were to do with components delivered as file-ins that
>> weren't yet filed-in. It was too rigid. It didn't allow for future
>> expansion. And so I had the idea of menu pragmas to decouple
>> things. Steve Dahl then came up with the scheme to define a base
>> menu, number its items appropriately, and extend the menu.
>>
>> One of the things that's really nice about the VisualWorks scheme is
>> that the menu pragma itself is actually implemented (remember that
>> pragmas are Message instances with literal parameters). The class
>> MenuBuilder (IIRC) implemented various menu pragma methods so the
>> pattern is:
>>
>> - in the method that defines the base menu, define the base menu,
>> create an editor on it, ask the editor to collect the pragmas and
>> augment the menu with those found
>> - the menu editor then collects the menu pragmas and then performs
>> each one to collect the information from it
>>
>> So one can find other menu pragmas using senders, and find the editor
>> using implementors, and one can extend the scheme by adding additional
>> methods to MenuEditor, again possibly loaded from packages.
>>
>>
>> HTH
>>
>> _,,,^..^,,,_
>> best, Eliot
>
> --
> Craig Latta
> netjam.org
> +31 6 2757 7177 (SMS ok)
> + 1 415 287 3547 (no SMS)
>
>
More information about the Squeak-dev
mailing list
|