Actually that's an excellent idea - to compliment my current use of large size menus.
There are two use cases. One for my current use - and one to answer your suggestion.
My current use case - of large scale menus - is two fold. (A) To navigate a complex pattern
lexicon based on a '_tag' methodology. The other (B) is to quickly do a grep for some _tag
in the lexicon - that is outside the current code domain I am focused on. Thus if I am coding
some GUI code - and need to grep a tag in networks (socket, port, server target address) - I
can use the large scale menu (which is basically a lexicon dictionary) - to quickly find the grep
tag I need - and then grep in file, project or workspace scope.
Your excellent suggestion can compliment that use case with another use case of code _tag
lexicons. The use case is a (2) _tag lexicon reference window. My use, in this case, would require a dockable
tabbed window (see attached screenshot) - rather than a dialog box. The tabs are variable and hold dynamic
tree controls filled out via XML files - that hold subsets of the overall _tag lexicon. Thus one tab could be GUI,
while another tab could be State (state space lexicon).
The attached screen shot - shows the 'Project window' - that has tabs for Projects, Defs, Class, Symbols and Open.
A similar GUI construct - containing an expandable, collapsible tree in each tab - would work for me. I would need
to be able to 'Name' each tab (such as State, GUI, Event, Network, etc) - and then edit each tree manually - in addition
to import/export of the tree using a XML based file storage/persistance paradigm.
The second use case could be used for 'grep actions' - at the nodes of the dynamic tree leaves. But other
action types could be programmed (using SE Macros) - to execute other types of actions - or even a set of
actions.
This excellent suggestion of yours - would, in my mind (for the (2) use case above) require a somewhat complex
GUI construct. That construct would be the multi-tabbed window (see atttached screen shot) where each tab
window - contains a separate dynamic tree (ie; expandable and collapsible hierarchy - based on an XML file
to be loaded in each tab window).
Because of the implementation complexity (a tabbed window construct -VS- a simple dialog with a dynamic tree) - I
would consider writing my own plug for SE in C++ (which I have never done before).
In summation : An alternate third use case (3) - could use a single persistent dialog - that would allow a user to
have the dialog box (with a single big dynamic tree). In this use case the tree leaves are 'actions' programmed by
the user. My current use would be simple single shot grep actions on _tag targets in (A) file, (B) project and (C) workspace
scope.
In use case (3) : It would be nice if the dialog box dynamic tree could be expressed in the current _menu() paradigm
of the SE macro language. That way my current code could port easily to the new feature. On the other hand - I could
morph my current _menu() based code - to other code artifact type for a structurally similar SE module (to express the
dynamic tree structure). Note in this design context we use SE macros as the basis of the custom tree design expression,
followed by the XML storage/persitence paradigm. I prefer the SE macro paradigm as the primary design expression
medium - since all the stuff I do revolves around the SE Macro language. The ability to export, import to other SE
users in my local user group (academic environment - students in the K12U pipeline) - via the XML construct - allows a
senior software engineer to genesis the lexicon - via the SE Macro paradigm - and then mentor the junior members
of the software engineering culture - via the XML import/export paradigm.
Good feature recommendation, and yes : I could see an open dialog (that allows me to use the main SE GUI - and go
back and forth between dialog and main GUI) - as being a perfect solution - to single shot grep actions - outside the
current code domain of interest.
Note, as a parting note : The current code domain of interest (in my use of SE) - always has 2 or more toolbars (sometimes
6) - with 'grep action buttons' - to view code artifacts and then navigate to them (via the _tag lexicon). So the dialog with
a dynamic tree - would be a really neat way to have some visibility and navigation - for any _tag in the lexicon.