[squeak-dev] Menus and cmd keys considered quite, quite, mad
H. Hirzel
hannes.hirzel at gmail.com
Tue Oct 27 09:56:02 UTC 2015
You mean the class 'Model' and method #addItem: ?
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 <Das.Linux at gmx.de> wrote:
>
> 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.
>
>
>
>
More information about the Squeak-dev
mailing list
|