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.