Hi Tim.

Just type a word. It will filter the menu and help you focus. ...maybe we should expand this search to submenus? :) Just thinking about our current state of tree-node filtering in the object explorer...

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 [mailto: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 [mailto:tim at rowledge.org]; http://www.rowledge.org/tim [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/8b8fa8af/attachment.html>