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
?

--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.
>
>
>
>