On 27.10.2015, at 10:56, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> You mean the class 'Model' and method #addItem: ?
> 
> 

No. I meant Model>>menuPragmasFor: aMenuSymbolOrCollection in: aClass.

Do we actually talk about the same thing?
I'm unsure :)

Best regards
	-Tobias

> addItem: classAndMethod
> 	"Make a linked message list and put this method in it"
> 	
> 
> 	self flag: #mref.	"classAndMethod is a String"
> 
> 	MessageSet
> 		parse: classAndMethod
> 		toClassAndSelector: [ :class :sel | | list |
> 			class ifNil: [^self].
> 			list := OrderedCollection with: (
> 				MethodReference new
> 					setClass: class
> 					methodSymbol: sel
> 					stringVersion: classAndMethod
> 			).
> 			ToolSet
> 				browseMessageSet: list
> 				name: 'Linked by HyperText'
> 				autoSelect: nil
> 		]
> 
> 
> 
> --Hannes
> 
> On 10/24/15, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> On 23.10.2015, at 16:44, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> 
>>> On 10/21/15, tim Rowledge <tim at rowledge.org> wrote:
>>>> I wanted to add a little cmd key hack to the debugger to print numbers
>>>> in
>>>> hex - useful when debugging the VM in sim etc. Eventually I found a way
>>>> to
>>>> solve my immediate needs but along the path I found a dazzlingly complex
>>>> intertwingled mess of code for menus and cmd key handling.
>>>> 
>>>> Part of it is likely  because of the confusion inherent to having two
>>>> separate UI systems that aren’t quite separate. For example StringHolder
>>>> class>>#yellowButtonMenuItems includes
>>>> 			{'make project link (P)' translated.	#makeProjectLink}.
>>>> which
>>>> a) annoyed me because I want to use cmd-shift-p for my printItHex
>>>> b) seems to be a bit odd to have in a text editor menu, and very much so
>>>> in
>>>> a code editor menu
>>>> c) doesn’t even work in Morphic so far as I can tell (PluggableTextMorph
>>>> does not understand #makeProjectLink)
>>>> 
>>>> Also when building menus - which is done for every menu button press! -
>>>> we
>>>> end up doing a scan of all the methods (for menu related pragmas) of
>>>> every
>>>> class that could possibly be involved.
>>> 
>>> 
>>> Just curious -- where is this scanning of all methods done in version
>>> 5.0?
>>> It does not seem to involve the TheWorldMenu
>>> http://wiki.squeak.org/squeak/6213
>>> ?
>> 
>> Its in Model, for use with tools.
>> The world menu is a different beast, still/yet.
>> 
>> Best
>> 	-Tobias
>> 
>>> 
>>> --Hannes
>>> 
>>> 
>>> 
>>> This is even more insane than using
>>>> #isKindOf: within UI code. Perhaps one could argue that it isn’t quite
>>>> completely insane on multi-core/multi-GHz/megaRam machines but on
>>>> anything
>>>> slower ( like the Pi, a rather important platform for public awareness
>>>> and
>>>> outreach) it can ruin the UI experience.
>>>> 
>>>> The current system reminds me unpleasantly of the PenPoint/Go UI dating
>>>> back
>>>> to ’89 or so; their hardware was nominally several times faster than our
>>>> Active Book, and they proudly proclaimed how it was all carefully
>>>> optimised
>>>> code and yet it was grindingly slow to do anything in the UI. The Active
>>>> Book was a mere 8MHz ARM2 (no caches, not even an instruction prefect
>>>> queue,
>>>> 1Mb RAM for everything including the screen and filing system) and
>>>> running
>>>> that terrible slow nonsense called Smalltalk that everyone knew was slow
>>>> as
>>>> slow. Many years later I met one of the developers and it turned out
>>>> that
>>>> their framework carefully built menus by checking here, looking there,
>>>> seeing if a string needed translating, having a tea-break and finally
>>>> asking
>>>> a complex graphics subsystem to render something. The Active Book code
>>>> bitblt’d a menu form to the screen.
>>>> 
>>>> Ideally menus should be pre-built and cached, with some cache-flushing
>>>> algorithm connected to anything that changes what should be in them. Such
>>>> as
>>>> adding a new menu related pragma.
>>>> 
>>>> I also spotted some code where menu getting selectors are examined to
>>>> see
>>>> how many arguments they take and then assorted #perform incantations are
>>>> used. In general abetter option is to make use of the execution
>>>> machinery
>>>> and just send the most flexible message. Implement it at some sensible
>>>> root
>>>> to re-try with a simpler version if needed.
>>>> 
>>>> I wish I had time to clean this up but I have to make VM changes to
>>>> support
>>>> a largish number of Scratch users and my brain is about ready to
>>>> explode.
>>>> 
>>>> tim
>>>> --
>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>> 29A, the hexadecimal of the Beast.