Bug 58265 - [Palette] Palette view should be 'hookable' to the view parts
Summary: [Palette] Palette view should be 'hookable' to the view parts
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy GEF (MVC) (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-13 09:30 EDT by Dmitry Stadnik CLA
Modified: 2010-11-04 17:29 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Stadnik CLA 2004-04-13 09:30:40 EDT
Currently class PaletteView considers only IEditorPart being an 'important'
workbench part that may provide palette contents (see isImportant(...) method).
This is an absolutely needless limitation. I suggest to consider IViewPart to be
asked for palette contents as well.
Comment 1 Randy Hudson CLA 2004-04-13 10:56:39 EDT
If the palette view is sensitive to all workbench parts, then when you select 
Navigator, Outline, PropertySheet, etc., the palette will turn blank.  This 
would be annoying to the user.
Comment 2 Dmitry Stadnik CLA 2004-04-14 03:28:34 EDT
Well, that depends on how you will implement this. I suggest that
isImportant(part) should check that part.getAdapter(PalettePage.class)!=null.
Comment 3 Randy Hudson CLA 2004-04-14 12:01:23 EDT
Can you explain what type of view would make use of a palette view?  Thanks.
Comment 4 Dmitry Stadnik CLA 2004-04-15 03:51:53 EDT
Class diagram opened for a package; of course we store node and link positions
in some file, but there is an option to create this file for each package or to
have a single file for the whole project. Anyway editor paradigm is not quite
applicable here (user should not edit positions file directly) so we use view
part to host the diagram. Plus critical feature that changes in java class made
in java editor should be reflected immediately on diagram - user would have two
dirty editors that sync contents and an option to save changes in one and do not
save changes in another? If not then what an editor is it? In other words in
this case we treat diagram as a derivative view of the java editor(s) contents
that should always be in sync with it(them), just like an overview view or the
property sheet (they are not editors, right?).
Comment 5 Randy Hudson CLA 2004-04-15 14:42:27 EDT
All class diagram editors I can think of create a "diagram file" which is 
coupled to the resource(s) which correspond to the classes, etc. They all use 
editorparts to edit the diagrams, not views.  It is possible to place two 
editors side-by-side.  Also, it is possible to share the documents between the 
java source editor and your own class editor.

This is all O.T. though.  I like the idea of determining whether the part is 
important based on whether or not it has a palette.  That way, if you have a 
diagram and a java source editor open side-by-side, and the java editor does 
not have a palette, the user can keep using the diagram's palette without first 
clicking on the diagram editor to activate.
Comment 6 Dmitry Stadnik CLA 2004-05-27 05:52:47 EDT
The same problem with CommandStackInspector; the following code solves it )))

public class GdeCommandStackInspector extends CommandStackInspector {

 protected boolean isImportant(IWorkbenchPart part) {
  return part.getAdapter(CommandStackInspectorPage.class) instanceof
CommandStackInspectorPage;
 }
}