[squeak-dev] Maximum tree search depth

Chris Muller ma.chris.m at gmail.com
Thu Nov 2 21:16:49 UTC 2017


Hi Marcel,


> ... Just thinking about our current state of tree-node filtering in the
> object explorer...
>

While it's not elegant having to pop into the Preferences panel to adjust
"Maximum tree search depth" (it can be torn off), I do get quite a bit of
mileage from this one setting.  It basically lets me switch between
Filter[0], Navigate[1] and Search[2+] use cases as needed, but with a
clarity about *how* it is actually going to do them (traversal depth) that
is easily understood.

I do have to be extra careful with anything over 1 when exploring a
high-level Magma object with proxies out into a huge repository because,
with no way to abort, an accidental key press can become a frustrating
image-lock.

Getting Filter working better would also make it feel better.  Depth of 0
should just filter the selected items siblings, (and, if that causes a
mismatch on the selected item,  changing the selection), but without
affecting their expanded/unexpanded status of anything.

Best,
  Chris

[0] -- (Filter) I have a collection with 8000 elements, I want to filter
the list without changing expanded state of anything.  (Currently doesn't
work)

[1] -- (Navigate) I just explored a Morph and quickly want to navigate
to 'extension' -> 'otherProperties' -> 'layoutPolicy' -> 'properties'.
(Works!)

[2+] -- (Search) I'm looking for a data value, but don't know where it is,
let the machine do the work.


>
> Best,
> Marcel
>
> Am 02.11.2017 20:49:48 schrieb Chris Muller <asqueaker at gmail.com>:
> I could easily do without 6 items on that menu, but I need the rest.  It's
> possible others might like those features, though.
>
> It'd be neat if the IDE could somehow keep a collection of items to omit
> from the menu; with option to "restore all".
>
> On Thu, Nov 2, 2017 at 2:34 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>> Using Eliots screenshot as an example to hang some points on -
>>
>> That’s a way too long menu. I has hierarchical submenus *and* a ‘more…’
>> submenu. The refactoring stuff is probably less frequently used than many
>> items below, which is usually a bad idea. The usage of the ellipsis for
>> items like ‘senders of…’ at least indicates there is a further list to come
>> but it confuses with ‘more…’ indicating a submenu.
>>
>> At the very least I’d want to break this up into a better tree of menus,
>> though it seems to me that some of those options really would be better off
>> not in a menu at all but removed to some other UI element. We have the
>> button list in the Browser that subsumes the sender/implementors stuff and
>> there’s probably more that could be done there. I can’t see why ‘class
>> refs’ is in a method menu at all! Nor indeed the three browse options which
>> are all class list related.
>>
>> Another interesting UI idea from the past might be useful to consider for
>> the ‘senders of…
>> ‘ type entries; RISC OS menus can include attached dialogues of various
>> types. (In fact even entire application windows can be used but that’s
>> going a bit far in my opinion) Now clearly we could simply add a submenu
>> with the list of selectors used in the method for this particular case and
>> it would be an improvement. Using dialogues (like the ListChoosers we
>> currently open) directly from the menu offers the filtering and multiple
>> input field or multiple lists and hierarchies and buttons capabilities. One
>> might have a dialogue that lists all the selectors used, provides the
>> filtering (yes, I know menus can do basic filtering) and several buttons to
>> choose global or local searching for the implementing methods, limit to
>> this package, check the history database for implementors no longer in the
>> system, whatever. A crucial point would be to make sure the dialogues open
>> and display *fast* even on slower machines.
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: HCFI: Halt and Catch Fire Immediate
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171102/e25023a2/attachment.html>


More information about the Squeak-dev mailing list