If we have to cache menus and introduce some "cache-flushing
algorithm" merely for performance, then I think its a sign that we
should do a critical re-evaluation of the pragma-based preferences.
I'm starting to think the negative aspects they've brought to
Preference management within the system outweigh their positives, when
compared to simple object structures accessed by a unified API..

On Tue, Oct 27, 2015 at 6:25 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Chris,
>
> _,,,^..^,,,_ (phone)
>
>> On Oct 21, 2015, at 6:29 PM, Chris Muller <asqueaker at gmail.com> 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.
>
>