mohr@i90fs1.ira.uka.de (Thomas Mohr) (05/07/91)
I am currently implementing a editor for graphic objects, which are allowed to be hierarchical. The operation of "opening" an object, thus clicking on it and let the contents of the object replace the yet visible parts is next. It should look like double-clicking an an folder icon in GEM. Do I have to install another viewer ? Or a complete new editor object ? Can I achieve this with just another view ? Any hints are very appreciated. ------------------------------------------ Thomas Mohr mohr@i90fs1.ira.uka.de ------------------------------------------
vlis@lurch.stanford.edu (John Vlissides) (05/08/91)
In article <1991May7.142801.25575@ira.uka.de> mohr@i90fs1.ira.uka.de (Thomas Mohr) writes: > I am currently implementing a editor for graphic > objects, which are allowed to be hierarchical. > The operation of "opening" an object, thus clicking > on it and let the contents of the object replace > the yet visible parts is next. It should look like > double-clicking an an folder icon in GEM. Do I have > to install another viewer ? Or a complete new editor object ? > Can I achieve this with just another view ? I'm not sure if you want to expand the object in place but keep unrelated objects visible, or expand it in place and hide other objects, or create a new window containing the expanded object. I don't know what double clicking on a folder does in GEM. If it opens another window, then you could create another viewer containing a different (expanded) view of the hierarchical component and then insert the viewer (or an editor that contains it) into the world. If instead you want the expanded view to replace everything else in the viewer, then you could replace the view in the viewer with the expanded view. If you want the expanded view to replace only its elided counterpart (i.e., expanding it in place), then you could define a view that displays itself in one of two ways. In fact, that would be a good approach no matter which way you want the expansion to happen. Here's one way to implement this two-faced view. Say its subject is a GraphicComps (subclass) that defines the semantics of the potentially hierarchical object. The view (derived from GraphicViews) can present itself in one of two (or more) ways: one is the normal "show-all-your-children" way inherited from GraphicViews, and the other would replace the GraphicViews' graphic with a (simple) picture that shows the elided appearance. Which appearance is presented could be stored as an attribute of the subject; however this may not be part of the subject's semantics. Thus it may be better stored as an attribute of the view itself, or even of the editor---perhaps based on (or defined by) the current selection. You'll have to override GraphicViews::Update to update the view so that it reflects the desired appearance: It would switch the view's graphic to the simple picture if it's in elided mode, and it would switch it back to the original picture and call GraphicViews::Update if it isn't elided. -- John Vlissides Computer Systems Lab Stanford University vlis@interviews.stanford.edu