Possible KnowledgeManager Features
...and notes on their implementation
(I'm laying out a strategy for implementation of some KMan features instead
of just doing them myself immediately, because these are the bug-prone ones
that don't necessarily have a straightforward design. I had delayed putting
them in because I wasn't sure they'd all be necessary, and I didn't
have a good feel for how to integrate them at the time the basic
Knowledge Manager program was being designed. And now I'm leaving in
a month and that's not enough time to put them in and make sure everything
works together.)
Find-in-Hierarchy operation
Mon, 21 Aug 1995 15:13:30 -0700 (PDT)
Jim Brinkley
> For the Find operation it might be nice to list, in Find panel browser,
> the names of hierarchies in which the term is found
>
> Then when you double click on one of these lines the appropiate hierarchy
> will be displayed. I found it a pain to have to keep changing the hierchy
> in the browser before I could see where the term is.
Alternate DB's
Mon, 21 Aug 1995 15:13:30 -0700 (PDT)
Jim Brinkley
> One nice way [to use alternate DB's] in the interface might be that as soon
> as the program is started the user will see in the hierarchy editor a list
> of KBs that are visible from the client. Those that can be modified by the
> user will be in black, those that are read-only would be in gray. For
> read-only kb's maybe the operations window would dissapear.
Improving code modularity
(Kraig, 8/24/95) -- There are a bunch of routines in panhandler.m which
refer to the hierarchy window as a single fixed object, and would break
badly if we want multiple simultaneous hierarchies showing. When I find out
how one would create multiple instances of a window object and how the
program can figure out the user's focus of attention, there are several
routines that need to be broken out and put into the hwindow.m module:
insertTermAsRoot
insertTermAsChild
cutSelection
pasteAsRoot
pasteAsChild
deleteSelection
reorderSelectionUp
reorderSelectionDown
getChildren
findMatrixRowContainingTerm
expandSubtreeContainingTerm
findInHierarchy
The "findMatrixRowContainingTerm" and "getChildren" methods do a little better;
they at least use a parameter to tell WHICH matrix to modify and don't refer
to the particular browser object in use. But these are only supporting
routines anyway, called by other routines which do have fixed references.
And besides, panhandler is 977 lines and no other module is much over 200, so
it's clearly too big for what it is (a miscellaneous everything-handler).