[squeak-dev] Browser searching suggestion

Levente Uzonyi leves at elte.hu
Sat May 25 00:27:38 UTC 2013


And this is also the reason why syntax highlighting might be too slow on a 
slower machine, because #hasBindingThatBeginsWith: uses a linear search 
instead of a binary search in Enviroments.


Levente

On Sat, 25 May 2013, Levente Uzonyi wrote:

> The cause of the slowdown is the lack of name cache in Environment. Class, 
> global and trait names were cached in SystemDictionary, so asking for 
> #classAndTraitNames was cheap.
> If you try it with a 4.4 image (or any image which doesn't use Enviroments), 
> then you'll find that it's it about 15 times faster there, which is probably 
> sufficient on a slower machines.
>
> Starting with an empty list might make the UI more responsive, but as soon as 
> you start typing, it will be just as slow as before.
>
>
> Levente
>
> On Fri, 24 May 2013, tim Rowledge wrote:
>
>> While I'm thinking of UI stuff, here's a suggestion that might be simple 
>> for a Morphite to try out -
>> For the class category and message protocol lists, add a 'spotlight' morph. 
>> The class category 'find class' menu entry work ok on a fast machine but is 
>> very slow on smaller machines at least in part because of building a large 
>> list and a full window in which to show them. If the top of the browser 
>> list were to be a typeable morph attached to a very lightweight drop-down 
>> list (a menu in essence) of matches for what was typed… so instead of doing
>> 
>> menu or cmd-f,
>> opening a somewhat complicated dialogue/window showing all classes,
>> typing the pattern,
>> selecting a matching one
>> 
>> we might have -
>> 
>> type into pattern field
>> fast, simple list displayed containing only matching entries
>> select choice
>> 
>> I'm thinking of this as both a lighter weight bit of work for the system 
>> (since the full list of all classes need not be built and formatted and 
>> displayed) and a slightly lower friction UI for the user (since the UI is 
>> right there in front of you). The same widget targeted at all messages of a 
>> class could be nice. I wonder if it might be even more effective if nothing 
>> were displayed until at least 'n' characters were entered, where 'n' is 
>> probably 2-4. Is it actually useful to see  a list of all classes 
>> containing a single typed letter? Could we sensibly link the pattern to 
>> regexp code, or at least basic matching with wildcards?
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: WDS: Warp Drive, Scotty!
>> 
>> 
>> 
>


More information about the Squeak-dev mailing list