Re: [ve-dev] Disabling swing Palette

[Rich Kulp <richkulp@xxxxxxxxxx>]

Janak,

Ah, I think that is a missing idea on
my part. :-( I don't process the contributions in any particular order.
I'm thinking what is happening is that sometimes the ULC contributor is
run before the standard JFC palette contributions.

I have to think real hard on this because
I'm not sure what the best way is to control the contribution order. Should
it by order of the containers in the classpath, but then it would be required
to have the JRE first and then ULC. That would be difficult to control.
Usually I do things in plugin order. So should it be that I require you
to require (as optional) the org.eclipse.ve.jfc plugin, so that the jfc
plugin contributors run first and build up the jfc palette, then you run
and clear it all out. What this means is that if anyone adds any other
kind container, you won't know about it and it may come in after you and
their contribution will be there. I don't know of anyway to say "ME,
I'M the only one" when there could be several who say this.

As for the second question, the only
 thing I can think of is:

1. ULCContainer: Have it check the flag, and if not valid, then return an empty array for the classpath entries. That way there won't be ULC jars in the classpath so you won't be able to use any of the classes because they will be all undefined. not found.
2. Change ULCVisualEditorContributor. The major change is you will need to pull the <palette...> extension out and instead of the ULCVisualEditorContributor contribute the ULC category instead. Then in there check the flag and if not valid, then don't wipe the cats and don't add your own.

By doing this the palette won't have
anything in it, the ChooseBean won't show any ULC classes, the remote vm
won't have access to any of the ulc classes, and if they had code that
had ULC classes in it, the code should be full of red-x's because the classes
are invalid. And if the class is undefined, none of the codegen, proxy
adapters, or anything from the overrides file will be applied to the class.
I'm not sure if this will work if in the middle of a session you lose the
license. I'm pretty sure this will work if the license is turned off by
first request to see if the license is active. However, I don't think this
will work right if they put the ULC jar by hand into the classpath. If
they did that, then with the ULCContainer entry being there, and the jar
being there, the classes will be valid, and the overrides will be applied.
But does your runtime also have a license check? If it does, then even
though we will try to instantiate the classes, the runtime will reject
them, no?

"Janak Mulani" <janak.mulani@xxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx

10/08/2004 11:31 AM

Please respond to
ve-dev

To	"ve-Dev@Eclipse. Org" <ve-dev@xxxxxxxxxxx>
cc
Subject	[ve-dev] Disabling swing Palette

Hello,

We have the following issues with regards to our ULC VE plugin:

1. Trying to disable Swing Palette:

We implemented the extension point:

<extension
         point="org.eclipse.ve.java.core.contributors">
      <contributor
                  
               
  class="com.canoo.ulc.visualeditor.ULCVisualEditorContributor"
                  
               
  container="ULC_CONTAINER">
                  
  </contributor>

      <palette
            container="ULC_CONTAINER"
            loc="first"
            categories="palette/ulcbeanscats.xmi"
            plugin="com.canoo.ulc.visualeditor">
      </palette>

   </extension>


ULCVisualEditorContributor implements IVEContributor as follows to remove
all Swing palette.

public boolean contributePalleteCats(List currentCategories, ResourceSet
rset) {
                
// remove the palette categories of the plugins (i.e. the VE plugin) on
which ulc ve plugin depends
                
currentCategories.clear();
                
return true;
}

The arg currentCategories contains all the Swing and Awt palette categories.

This works fine in the Plug-in Development environment. However, it does
not
work when the ULC plugin is installed on a separate Eclipse installation.

Question: Is this a correct way of suppressing Swing palettes? If so why
does it not work outside of plugin dev environment?

2. As discussed earlier, we would like to disable/uninstall/stop running
ULC
VE plugin if the license for it is invalid.

Alternatively, in the VE, is there a way to disable the canvas, the bean
tree and code generation?

Thanks and regards,

Janak & Sibylle


_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ve-dev