[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.tools] Re: editor extensions registration options?
|
Gary,
Do you have to call your "goober" files *.goober.java? Or was this just an
idea for a possible solution? If the "goober" files are just regular *.java
files, then you might use the same solution that other plugin developers are
using for editing *.xml files.
Look at the api IEditorRegistry::setDefaultEditor(IFile, String). You can
use this api to set what editor will be used by default to edit the file.
The navigator view uses the icon of the file's default editor. Doing so
would address your three "requirements" as listed below (distinct icon in
nav view, default "goober" editor on dbl-click, and use of java editor via
Open With menu).
Assuming these "goober" files are created by a wizard, then the wizard could
call this api to set the default editor to be the "goober" editor. (i.e.
PlatformUI.getWorkbench().getEditorRegistry().setDefaultEditor(...))
Good luck!
Simon :-)
"Gary Johnston" <gjohnsto@xxxxxxxxxx> wrote in message
news:9ivi3v$2md$1@xxxxxxxxxxxxxxxx
> We are building a graphical editor for a certain kind of "goober" (and
> let's just leave it at that so that I don't have to spend space describing
> what a "goober" is, which isn't really relevant). A goober is actually
> saved as a Java source file (i.e., a .java file and corresponding compiled
> class file), one goober class definition per .java/.class file in our
> case. So, every goober shows up in the Navigator as a .java file, but not
> all .java files are goobers, of course. We'd like to register our goobers
> (with the editor extension point) such that 1) goobers have a distinct
> icon in the navigator (so user's can tell which .java files are goobers
> and which aren't), 2) double-clicking on a goober source file opens our
> goober editor (rather than the Java source editor), and 3) the file is
> otherwise treated as a normal .java file (e.g., the Java source editor
> could be opened on it via "Open with" from the context menu).
>
> The approach we're considering is to register (in our plugin.xml) the
> extension "goober.java", specifying our own goober icon and our goober
> editor. I have a few questions about this approach:
>
> 1) Would this basically work the way we want it to? Would our icon be
> used by the Navigator for .goober.java files, or would it just be ignored
> (i.e., .java file icon would override it)? Would our editor be invoked if
> one double-clicked on a .goober.java file, or would the Java source editor
> still be invoked? Would the Java source editor still be available via
> "Open with" from the context menu? More generally, does an "foo.bar"
> editor extension registration override a "bar" extension registration
> while still leaving "bar" registered tools available via the context menu,
> etc.?
>
> 2) Are we making any trouble for ourselves WRT the Eclipse Java tools due
> to the fact that our goober .java and .class files won't follow the common
> convention that, for example, MyClass.java contains the definition for a
> single class, MyClass, and compiles to MyClass.class? Our approach
> violates this convention because the class defined in, say,
> MyGoober.goober.java would be MyGoober and would, of course, compile to
> MyGoober .class. This is perfectly valid Java, of course, and so
> shouldn't be any problem for the Eclipse Java tools unless they assume the
> convention is being followed.
>
> 3) Is there some other (better) approach we should take?
>
> Thanks for any help or advice.
>