On 21.10.2015, at 23:47, Tobias Pape <Das.Linux at gmx.de> wrote:

> Hi Tim,
> 
> On 21.10.2015, at 23:35, 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. 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.
> 
> Speaking for the pragma-based menu system, yes, there's room for 
> improvement, and once Start-of-Semester stress settles down,
> I'll take on it.

Also, keybindings in general…
-t