Menus and cmd keys considered quite, quite, mad

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

> Hi Tim,
>
> On 21.10.2015, at 23:35, tim Rowledge <[hidden email]> 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.

> Hi Tim,
>
> On 21.10.2015, at 23:35, tim Rowledge <[hidden email]> wrote:
> >
> > 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.
>

> On 21-10-2015, at 2:49 PM, David T. Lewis <[hidden email]> wrote:
>
> On Wed, Oct 21, 2015 at 11:47:12PM +0200, Tobias Pape wrote:
>> Hi Tim,
>>
>> On 21.10.2015, at 23:35, tim Rowledge <[hidden email]> wrote:
>>>
>>> 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.
>>
>
> Yay!
>
> Dave

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

> #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; [hidden email]; http://www.rowledge.org/tim
> 29A, the hexadecimal of the Beast.
>
>
>
>

> On 10/21/15, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
>> 29A, the hexadecimal of the Beast.

>
> On 23.10.2015, at 16:44, H. Hirzel <[hidden email]> wrote:
>
>> On 10/21/15, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
>>> 29A, the hexadecimal of the Beast.
>
>
>
>

> 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 <[hidden email]> wrote:
>>
>> On 23.10.2015, at 16:44, H. Hirzel <[hidden email]> wrote:
>>
>>> On 10/21/15, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
>>>> 29A, the hexadecimal of the Beast.

> On Oct 21, 2015, at 6:29 PM, Chris Muller <[hidden email]> wrote:
>
> Tim, Squeak is a complex system, with a lot of functions and a complex
> interaction between human and machine.  No system like that is going
> to be the toddler-coddler you want it to be.
>
>>>> 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
>
> So override it, you have a "live" system.  The code IS the
> user-interface, just as much as the menus are...
>
>>>> 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.
>
> That'll waste all the memory in your Pi...

> On 28.10.2015, at 00:25, Eliot Miranda <[hidden email]> wrote:
>> On Oct 21, 2015, at 6:29 PM, Chris Muller <[hidden email]> wrote:
>>>
>>>
>>> That'll waste all the memory in your Pi...
>>
>> No it won't :). First there's a gigabyte of ran on a Pi.
>
> You’re thinking of the Pi 2. The original Pi had 256 MB or 512 MB, and it
> sold by the millions:
>
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/models/specs.md
>
> Once all of Linux and X11 is loaded there is not much RAM left.
>
> The Pi 2 was only introduced this year.
>
> - Bert -
>
>

>
> On 10/28/15, Bert Freudenberg <[hidden email]> wrote:
>> On 28.10.2015, at 00:25, Eliot Miranda <[hidden email]> wrote:
>>> On Oct 21, 2015, at 6:29 PM, Chris Muller <[hidden email]> wrote:
>>>>
>>>>
>>>> That'll waste all the memory in your Pi...
>>>
>>> No it won't :). First there's a gigabyte of ran on a Pi.
>>
>> You’re thinking of the Pi 2. The original Pi had 256 MB or 512 MB, and it
>> sold by the millions:
>>
>> https://www.raspberrypi.org/documentation/hardware/raspberrypi/models/specs.md
>>
>> Once all of Linux and X11 is loaded there is not much RAM left.
>>
>> The Pi 2 was only introduced this year.
>>
>> - Bert -

> Hi Chris,
>
> _,,,^..^,,,_ (phone)
>
>> On Oct 21, 2015, at 6:29 PM, Chris Muller <[hidden email]> wrote:
>>
>> Tim, Squeak is a complex system, with a lot of functions and a complex
>> interaction between human and machine.  No system like that is going
>> to be the toddler-coddler you want it to be.
>>
>>>>> 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
>>
>> So override it, you have a "live" system.  The code IS the
>> user-interface, just as much as the menus are...
>>
>>>>> 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.
>>
>> That'll waste all the memory in your Pi...
>
> No it won't :). First there's a gigabyte of ran on a Pi.  Second, if the menu system saves the symbolic firm of the menu rather than the rendered but so it should be quite compact.
>
>

>
> On Tue, Oct 27, 2015 at 6:25 PM, Eliot Miranda <[hidden email]> wrote:
>> Hi Chris,
>>
>> _,,,^..^,,,_ (phone)
>>
>>> On Oct 21, 2015, at 6:29 PM, Chris Muller <[hidden email]> wrote:
>>>
>>> Tim, Squeak is a complex system, with a lot of functions and a complex
>>> interaction between human and machine.  No system like that is going
>>> to be the toddler-coddler you want it to be.
>>>
>>>
>>> So override it, you have a "live" system.  The code IS the
>>> user-interface, just as much as the menus are...
>>>
>>>
>>> That'll waste all the memory in your Pi...
>>
>> No it won't :). First there's a gigabyte of ran on a Pi.  Second, if the menu system saves the symbolic firm of the menu rather than the rendered but so it should be quite compact.