Thanks for feedback, I'll make some comments...
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 05 December 2007 2:11 AM To: ui@lists.squeakfoundation.org Subject: [UI] More feel observations
Gary,
I did some more "real" programming today (working on a port of my home-grown file backup system), and am starting to find that one of my larger complaints (which I consider to be a sign of progress) is the apparent lack of support for virtual keys - the home and end in particular - in the unix VM. My searching so far has not turned up anything specifically useful, so I will probably submit a question to Squeak-dev soon.
Yes, virtual keys... my main gripe is lack of support for function keys. As for home/end what's the problem with those? Or do you mean just on the numeric keypad? (only just noticed now you mention it... ok in Windows though :-) ).
Vistary, at least on my hardware, is slow enough that I can easily type faster than it can keep up. Soft squeak is much harder to outrun on the same hardware. Note that I still cannot fully clobber it due to the virtual key hassles. Part of my input speed comes from home/tab/past/space/etc/end, sometimes with shift depressed to make selections. Some of this stuff is so engrained I don't even realize I do it until it doesn't work.
Been a while since I noticed any keyboard lag from Squeak... SoftSqueak is certainly the most responsive theme, more than StandardSqueak. Vistary, due to translucency, is only expected to work well on modern hardware (is fine on my 1.73 GHz Centrino laptop). What's your hardware?
One thing that is in our general area is mouse interaction. It will be difficult to catch this in the act, but there is pretty clearly something to it. Have some code in plain sight; now try to drag-select it, quickly. I get unpredictable results; sometimes it selects what I want, usually it does not. When I have had similar problems in other systems, it suggests that the code is picking up current mouse coordinates when it should be using event coordinates.
Not noticed any problems like this... of course, a slower system might highlight such issues.
Re #mouseClickForKeyboardFocus, it appears to be selectively necessary. AFAICT, with other changes you have made, it is somewhat redundant. The message name browser is horribly broken without it. A few times, I have found that when adding methods, I get into a situation where the input focus is undefined, or not where I want it anyway, making it necessary to click in the code pane of the system browser. The weird thing is that in that situation, the cursor needs to be in the code pane for it to get focus. I have #mouseClickForKeyboardFocus set to true.
Best to set #mouseOverForKeyboardFocus to false when #mouseClickForKeyboardFocus is enabled (see PluggableTextMorph>>mouseLeave:). I'll probably rework that method since it is now the only sender of #mouseOverForKeyboardFocus (PluggableListMorph used to release the keyboard focus regardless!). Or, possibly, make changes to properly honour the #mouseOverForKeyboardFocus pref in the usual morphs (lists, text etc.).
Sorry for the incomplete observations and guesswork, but it is hopefully better to write down what I can remember.
Bill