[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"

		parse: classAndMethod
		toClassAndSelector: [ :class :sel | | list |
			class ifNil: [^self].
			list := OrderedCollection with: (
				MethodReference new
					setClass: class
					methodSymbol: sel
					stringVersion: classAndMethod
				browseMessageSet: list
				name: 'Linked by HyperText'
				autoSelect: nil


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