Maximum tree search depth

Am 02.11.2017 22:17:32 schrieb Chris Muller <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HCFI: Halt and Catch Fire Immediate