Home » Eclipse Projects » Equinox » Update on Enablement and Disablement Subproject
| Update on Enablement and Disablement Subproject [message #23853] |
Fri, 02 May 2003 15:42  |
Eclipse User |
|
|
|
I've wanted to let the newsgroup know about work beginning in the
enablement and disablement of plugins area.
The web page has been reformatted and includes a development plan with
specific milestones. As progress is made, more details will be added.
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamicPlugins/EnableDisablePlugins.html
I'm currently working on the easiest end to end case which results in
the enablement of a plugin.
Rafael Chaves, from the Eclipse team, is working on milestone #3 which
involves incremental registry resolution. This is one of the most
difficult parts of the project.
We've struggled with the definition of enablement and disablement (see
the issues section) and were hoping for newsgroup comment. A summary of
the issue is:
On startup, the registry resolver is presented with a registry of
unresolved plugins. Many of the plugins are resolved but there may be
some which fail resolution.
Now we come along with a new plugin to be enabled.
One line of thought is that besides the new plugin and the currently
resolved plugins, we should also consider plugins which previous failed
resolution. The result is that by enabling one plugin, we could have an
entire set of plugins become resolved. On the negative side, by
considering a new plugin, we could have a currently resolved plugin go
unresolved.
The other line of thought is to only consider the new plugin and
currently resolved plugins. The operation succeeds if the new plugin can
be resolved into the registry without causing any plugins to become
unresolved. (Ignore extensions etc).
Comments?
Thanks,
Keith
|
|
|
| Re: Update on Enablement and Disablement Subproject [message #23896 is a reply to message #23853] |
Mon, 05 May 2003 09:50  |
| Eclipse User |
|
|
|
Keith,
I checked your documents and the progress you are making with Raphael are
great. Let us now when you are able to enable a simple plugin!!!
I have comments about the terminology and some other details:
- I find the "unresolved" state to be confusing with the existing
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
amicPlugins/state_description.html), especially in this area of the registry
resolution. To my opinion a clear distinction between the states unresolved,
disabled, etc. is necessary because they do not represent the same
information.
- In the bullet 3 of the "plugin diagram" section it is said "During
platform startup, a registry of unresolved plugins is presented for
resolution" however, I think it is "During platform startup, a SET of
ENABLED plugins is presented for resolution"
> One line of thought is that besides the new plugin and the currently
> resolved plugins, we should also consider plugins which previous failed
> resolution. The result is that by enabling one plugin, we could have an
> entire set of plugins become resolved. On the negative side, by
> considering a new plugin, we could have a currently resolved plugin go
> unresolved.
>
> The other line of thought is to only consider the new plugin and
> currently resolved plugins. The operation succeeds if the new plugin can
> be resolved into the registry without causing any plugins to become
> unresolved. (Ignore extensions etc).
From the two approaches stated above, I think the first one makes the
more sense because it is deterministic. The second one is not because the
resolution of plugins depend on enablement order. An other problem that I
can see in the second case is the difference between resolved and unresolved
plugins between two sessions: for example during a session I can try to
enable plugin (whose resolution fails). Then I shutdown and restart, the
plugin whose resolution failed during the previous startup is resolved this
time, and may cause other plugins to be resolved or unresolved.
Don't you think that the registry could keep track of the unresolved
plugins?
Could you give more details about the concept of DynamicExtensionPoint?
HTH
PaScaL
|
|
|
| DynamicExtensionPoint [message #23936 is a reply to message #23896] |
Mon, 05 May 2003 13:38 |
| Eclipse User |
|
|
|
I've been doing background thinking and not a lot of research regarding
how to handle dynamic extension points. So, please don't tear my random
thoughts to threads.
The issue I'm worried about is a plugin having a menu item up and we
want to disable it. For this to work, the plugin containing the
extension point needs to be able dynamically remove the menu item. The
idea would be that the extension point could declare itself as being
able to handle dynamicity and then corresponding extensions could be
safely disabled (provided all other conditions are met). This could be
done by having a class which extends ExtensionPoint (may be otherwise
identical?) and conveys the information.
We would have to work though all 4 combinations of extension/extension
point and static/dynamic to see if works. If it does, then we could
maintain compabitlity with existing plugins with the property of not
allowing disablement until the plugin is upgrade to handle dynamicity.
As I said, I'm currently focused on registry resolution and not on
extension points but at 1st glance it seems like a interesting path to
explore.
Thanks for your comments,
Keith
Pascal Rapicault wrote:
> Keith,
>
> I checked your documents and the progress you are making with Raphael are
> great. Let us now when you are able to enable a simple plugin!!!
>
> I have comments about the terminology and some other details:
> - I find the "unresolved" state to be confusing with the existing
> one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> amicPlugins/state_description.html), especially in this area of the registry
> resolution. To my opinion a clear distinction between the states unresolved,
> disabled, etc. is necessary because they do not represent the same
> information.
>
> - In the bullet 3 of the "plugin diagram" section it is said "During
> platform startup, a registry of unresolved plugins is presented for
> resolution" however, I think it is "During platform startup, a SET of
> ENABLED plugins is presented for resolution"
>
>
>
>>One line of thought is that besides the new plugin and the currently
>>resolved plugins, we should also consider plugins which previous failed
>>resolution. The result is that by enabling one plugin, we could have an
>>entire set of plugins become resolved. On the negative side, by
>>considering a new plugin, we could have a currently resolved plugin go
>>unresolved.
>>
>>The other line of thought is to only consider the new plugin and
>>currently resolved plugins. The operation succeeds if the new plugin can
>>be resolved into the registry without causing any plugins to become
>>unresolved. (Ignore extensions etc).
>
> From the two approaches stated above, I think the first one makes the
> more sense because it is deterministic. The second one is not because the
> resolution of plugins depend on enablement order. An other problem that I
> can see in the second case is the difference between resolved and unresolved
> plugins between two sessions: for example during a session I can try to
> enable plugin (whose resolution fails). Then I shutdown and restart, the
> plugin whose resolution failed during the previous startup is resolved this
> time, and may cause other plugins to be resolved or unresolved.
>
> Don't you think that the registry could keep track of the unresolved
> plugins?
>
> Could you give more details about the concept of DynamicExtensionPoint?
>
> HTH
>
> PaScaL
>
>
|
|
|
| States [message #23976 is a reply to message #23896] |
Mon, 05 May 2003 14:20 |
| Eclipse User |
|
|
|
Pascal,
So far little progress but it's great that Raphael joined the project.
We have a good division of labor as he's looking at the difficult area
of registry resoltion and I'm making broader changes needed to drive his
work.
I'll address you comments inline - prefixed by ** Keith **
Keith
Pascal Rapicault wrote:
> Keith,
>
> I checked your documents and the progress you are making with Raphael are
> great. Let us now when you are able to enable a simple plugin!!!
>
> I have comments about the terminology and some other details:
> - I find the "unresolved" state to be confusing with the existing
> one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> amicPlugins/state_description.html), especially in this area of the registry
> resolution. To my opinion a clear distinction between the states unresolved,
> disabled, etc. is necessary because they do not represent the same
> information.
** Keith **
What information is different? In either case, they are not resolved
with the registry. The main difference is that you want to consider
"unresolved" and not "disabled" plugins during the next registry resolution
>
> - In the bullet 3 of the "plugin diagram" section it is said "During
> platform startup, a registry of unresolved plugins is presented for
> resolution" however, I think it is "During platform startup, a SET of
> ENABLED plugins is presented for resolution"
>
>
** Keith **
Are we both correct? Aren't enabled plugins either resolved or
unresolved and aren't only unresolved plugins being presented for
resolution?
>
>>One line of thought is that besides the new plugin and the currently
>>resolved plugins, we should also consider plugins which previous failed
>>resolution. The result is that by enabling one plugin, we could have an
>>entire set of plugins become resolved. On the negative side, by
>>considering a new plugin, we could have a currently resolved plugin go
>>unresolved.
>>
>>The other line of thought is to only consider the new plugin and
>>currently resolved plugins. The operation succeeds if the new plugin can
>>be resolved into the registry without causing any plugins to become
>>unresolved. (Ignore extensions etc).
>
> From the two approaches stated above, I think the first one makes the
> more sense because it is deterministic. The second one is not because the
> resolution of plugins depend on enablement order. An other problem that I
> can see in the second case is the difference between resolved and unresolved
> plugins between two sessions: for example during a session I can try to
> enable plugin (whose resolution fails). Then I shutdown and restart, the
> plugin whose resolution failed during the previous startup is resolved this
> time, and may cause other plugins to be resolved or unresolved.
** Keith **
To me, the former seems more natural. I say plugin.enable() and the only
registry change is the enablement of that plugin. Your approach has
the advantage that enabling one plugin can cause an entire group of
plugins to become resolved but also has the disadvantage of potentially
causing a resolved plugin to become unresolved.
Interesting comment about deterministic - I hadn't thought of it.
>
> Don't you think that the registry could keep track of the unresolved
> plugins?
** Keith **
Easily and in a compatibley manner so that existing routines would
return the same results as today.
>
> Could you give more details about the concept of DynamicExtensionPoint?
** Keith **
Previous posting.
>
> HTH
>
> PaScaL
>
>
|
|
|
| Re: Update on Enablement and Disablement Subproject [message #24018 is a reply to message #23853] |
Mon, 05 May 2003 15:46 |
| Eclipse User |
|
|
|
Keith Kimball wrote:
>>
> We've struggled with the definition of enablement and disablement (see
> the issues section) and were hoping for newsgroup comment. A summary of
> the issue is:
>
> On startup, the registry resolver is presented with a registry of
> unresolved plugins. Many of the plugins are resolved but there may be
> some which fail resolution.
>
> Now we come along with a new plugin to be enabled.
>
> One line of thought is that besides the new plugin and the currently
> resolved plugins, we should also consider plugins which previous failed
> resolution. The result is that by enabling one plugin, we could have an
> entire set of plugins become resolved. On the negative side, by
> considering a new plugin, we could have a currently resolved plugin go
> unresolved.
>
> The other line of thought is to only consider the new plugin and
> currently resolved plugins. The operation succeeds if the new plugin can
> be resolved into the registry without causing any plugins to become
> unresolved. (Ignore extensions etc).
>
I think that in general, my preferred default behavior would be to try
to resolve while including formerly unresolved plugins. It seems
logical to me that a common reason for 'adding' a new plugin would be to
try to fix those unresolved dependencies.
Another option is to explicitely ask the user if that is what he wants.
I.E. he adds a new plugin and a UI for confirmation allows him to
select from other unresolved plugins to try to resolve. This would have
to be just one possible mode, though. It would not make sense in a
headless mode.
I believe that the simplest default case for handling the outcome of the
resolution should be that if the resulting configuration results in the
'unresolving' of previously resolved plugins that it be considered a
failure. However, one could, again, prompt the user with something like:
"Adding <the specified> plugin(s) would result in the unloading of
<specified other> plugins due to <conflicts>. Would you like to
continue? [Continue|Cancel]"
This would be appropriate in the case where the user specifically
doesn't care that a particular plugin is no longer resolved and thus
unavailable. In fact it may be he/she deterministically wants that to
happen.
I realize that providing these options presents additional complexity,
but flexibility usually pays off in the long run.
Just some thoughts.
Mel
|
|
|
| Re: States [message #24052 is a reply to message #23976] |
Mon, 05 May 2003 18:06 |
| Eclipse User |
|
|
|
> > I have comments about the terminology and some other details:
> > - I find the "unresolved" state to be confusing with the existing
> >
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > amicPlugins/state_description.html), especially in this area of the
registry
> > resolution. To my opinion a clear distinction between the states
unresolved,
> > disabled, etc. is necessary because they do not represent the same
> > information.
>
> ** Keith **
> What information is different? In either case, they are not resolved
> with the registry. The main difference is that you want to consider
> "unresolved" and not "disabled" plugins during the next registry
resolution
**Pascal**
The difference I see between unresolved and disabled, is that unresolved
is the result of a registry resolution and that disabled is the result of a
user operation who somehow decided to no longer use a plugin and disabled
it. A plugin that is disabled does not participate in registry resolution.
> > - In the bullet 3 of the "plugin diagram" section it is said "During
> > platform startup, a registry of unresolved plugins is presented for
> > resolution" however, I think it is "During platform startup, a SET of
> > ENABLED plugins is presented for resolution"
> >
> >
> ** Keith **
> Are we both correct? Aren't enabled plugins either resolved or
> unresolved and aren't only unresolved plugins being presented for
> resolution?
**Pascal**
To me, only resolved plugins are presented to the registry.
PaScaL
|
|
| | | | | |
| Re: States [message #24354 is a reply to message #24184] |
Wed, 07 May 2003 09:55 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b99243$obc$1@rogue.oti.com...
> Thanks for your comments!!!
>
> I will change the design such that unresolved plugins are considered
> during enable and disablement. This is not my preference but I believe
> in the principles of "when in Rome act like Romans" and "Respect those
> with more experience in an area than yourself". You and Jeff are clearly
> the Romans with the experience and I would be foolish not to follow your
> suggestions especially given the requirement to get code accepted by the
> Platform team.
Don't be too humble Keith. The dynamic plugins stuff is new and we are all
working through the issues. It is great to have "non-Romans" involved
because they don't carry all the baggage of having worked on this stuff for
a long time. In short, it is good to have assumptions questioned. Keep it
up.
> A technical nit, it's my reading of the existing code that during
> startup, the registry contains only unresolved plugins, resolution
> occurs, and then unresolved plugins are trimmed from the registy. After
> startup, the registry only contains resolved plugins. Thus the claim
> that only unresolved plugins are presented for resolution.
In the current model yes, only unresolved plugins are presented for
resolution. But that's not too surprising since the current model only
resolves the registry once. By definition then all plugins are unresolved
whenever the resolver runs.
Sidenote: It was an implementation convenience to populate "the registry"
with the unresolved plugins and then have the resolver trim. It would be
clearer if we think of the registry as the result of resolution. The
datastructure input to the resolver should really just be a collection of
plugins.
In the dynamic model the resolver runs more times. You could consider that
each time the resolver is run all plugins are marked unresolved. That seems
like semantic trickery. Under the model I have described, the resolver
simply considers all enabled plugins regardless of their resolved state.
The result is a registry that contains only resolved plugins (as with the
current approach). We should have API (on the registry or otherwise) to get
the set of enabled but unresolved plugins and prehaps reasons why the plugin
is unresolved. As you have pointed out, the current API should continue to
deal in resolved plugins.
Jeff
|
|
| | |
| Re: DynamicExtensionPoint [message #24478 is a reply to message #23936] |
Mon, 12 May 2003 19:35 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I have a similar issue with my own engine and handling dynamic
load/unload/reload of plugins. One thought I had on this, which also touches
on your other threads in enable/disable, is rather than resolve a plugin
when the engine first starts, only resolve at runtime. It would add a bit of
overhead, but only on each first time need to resolve. Once a given
dependent class is resolved it sits in the classloader cache.
I haven't actually implemented this yet. I am not sure if it is a bad idea
at this point, but I tend to believe it would work out well. If a plugin is
added after the app is running, and it attaches to an existing extension
point, things are fine. If the plugin that owns the existing extension point
is unloaded or disabled, then somehow all extensions "listening" to that
extension point need to be notified not to use it any longer, right? The
only way I really seeing this work properly is on a per plugin
implementation basis. Every plugin would have to be written to assume any
dependent code it uses might not be available. This actually fits in very
well with the concept of services as well. If code uses a service (such as
how OSGi may implement a service), it has to check to see that the service
is available before making any calls to it, otherwise NPEs or other nasties
could occur. So long as all plugins are handling these types of checks,
there should be no issues with pluging being
loaded/unloaded/enabled/disabled.
"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b967gr$p8j$1@rogue.oti.com...
> I've been doing background thinking and not a lot of research regarding
> how to handle dynamic extension points. So, please don't tear my random
> thoughts to threads.
>
> The issue I'm worried about is a plugin having a menu item up and we
> want to disable it. For this to work, the plugin containing the
> extension point needs to be able dynamically remove the menu item. The
> idea would be that the extension point could declare itself as being
> able to handle dynamicity and then corresponding extensions could be
> safely disabled (provided all other conditions are met). This could be
> done by having a class which extends ExtensionPoint (may be otherwise
> identical?) and conveys the information.
>
> We would have to work though all 4 combinations of extension/extension
> point and static/dynamic to see if works. If it does, then we could
> maintain compabitlity with existing plugins with the property of not
> allowing disablement until the plugin is upgrade to handle dynamicity.
>
> As I said, I'm currently focused on registry resolution and not on
> extension points but at 1st glance it seems like a interesting path to
> explore.
>
> Thanks for your comments,
> Keith
>
> Pascal Rapicault wrote:
> > Keith,
> >
> > I checked your documents and the progress you are making with Raphael
are
> > great. Let us now when you are able to enable a simple plugin!!!
> >
> > I have comments about the terminology and some other details:
> > - I find the "unresolved" state to be confusing with the existing
> >
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > amicPlugins/state_description.html), especially in this area of the
registry
> > resolution. To my opinion a clear distinction between the states
unresolved,
> > disabled, etc. is necessary because they do not represent the same
> > information.
> >
> > - In the bullet 3 of the "plugin diagram" section it is said "During
> > platform startup, a registry of unresolved plugins is presented for
> > resolution" however, I think it is "During platform startup, a SET of
> > ENABLED plugins is presented for resolution"
> >
> >
> >
> >>One line of thought is that besides the new plugin and the currently
> >>resolved plugins, we should also consider plugins which previous failed
> >>resolution. The result is that by enabling one plugin, we could have an
> >>entire set of plugins become resolved. On the negative side, by
> >>considering a new plugin, we could have a currently resolved plugin go
> >>unresolved.
> >>
> >>The other line of thought is to only consider the new plugin and
> >>currently resolved plugins. The operation succeeds if the new plugin can
> >>be resolved into the registry without causing any plugins to become
> >>unresolved. (Ignore extensions etc).
> >
> > From the two approaches stated above, I think the first one makes
the
> > more sense because it is deterministic. The second one is not because
the
> > resolution of plugins depend on enablement order. An other problem that
I
> > can see in the second case is the difference between resolved and
unresolved
> > plugins between two sessions: for example during a session I can try to
> > enable plugin (whose resolution fails). Then I shutdown and restart, the
> > plugin whose resolution failed during the previous startup is resolved
this
> > time, and may cause other plugins to be resolved or unresolved.
> >
> > Don't you think that the registry could keep track of the unresolved
> > plugins?
> >
> > Could you give more details about the concept of DynamicExtensionPoint?
> >
> > HTH
> >
> > PaScaL
> >
> >
>
|
|
| | | | |
| Re: DynamicExtensionPoint [message #24722 is a reply to message #24478] |
Sat, 17 May 2003 14:55 |
| Eclipse User |
|
|
|
Originally posted by: mkot.at.ru
It is looks like Service Configurator pattern.
See articles of Douglas Schmidt:
http://www.cs.wustl.edu/~schmidt/PDF/O-Service-Configurator. pdf
Michail
"Kevin" <kduffey@marketron.com> wrote in message
news:b9pb4c$mt7$1@rogue.oti.com...
> I have a similar issue with my own engine and handling dynamic
> load/unload/reload of plugins. One thought I had on this, which also
touches
> on your other threads in enable/disable, is rather than resolve a plugin
> when the engine first starts, only resolve at runtime. It would add a bit
of
> overhead, but only on each first time need to resolve. Once a given
> dependent class is resolved it sits in the classloader cache.
>
> I haven't actually implemented this yet. I am not sure if it is a bad idea
> at this point, but I tend to believe it would work out well. If a plugin
is
> added after the app is running, and it attaches to an existing extension
> point, things are fine. If the plugin that owns the existing extension
point
> is unloaded or disabled, then somehow all extensions "listening" to that
> extension point need to be notified not to use it any longer, right? The
> only way I really seeing this work properly is on a per plugin
> implementation basis. Every plugin would have to be written to assume any
> dependent code it uses might not be available. This actually fits in very
> well with the concept of services as well. If code uses a service (such as
> how OSGi may implement a service), it has to check to see that the service
> is available before making any calls to it, otherwise NPEs or other
nasties
> could occur. So long as all plugins are handling these types of checks,
> there should be no issues with pluging being
> loaded/unloaded/enabled/disabled.
>
>
>
> "Keith Kimball" <keith2@us.ibm.com> wrote in message
> news:b967gr$p8j$1@rogue.oti.com...
> > I've been doing background thinking and not a lot of research regarding
> > how to handle dynamic extension points. So, please don't tear my random
> > thoughts to threads.
> >
> > The issue I'm worried about is a plugin having a menu item up and we
> > want to disable it. For this to work, the plugin containing the
> > extension point needs to be able dynamically remove the menu item. The
> > idea would be that the extension point could declare itself as being
> > able to handle dynamicity and then corresponding extensions could be
> > safely disabled (provided all other conditions are met). This could be
> > done by having a class which extends ExtensionPoint (may be otherwise
> > identical?) and conveys the information.
> >
> > We would have to work though all 4 combinations of extension/extension
> > point and static/dynamic to see if works. If it does, then we could
> > maintain compabitlity with existing plugins with the property of not
> > allowing disablement until the plugin is upgrade to handle dynamicity.
> >
> > As I said, I'm currently focused on registry resolution and not on
> > extension points but at 1st glance it seems like a interesting path to
> > explore.
> >
> > Thanks for your comments,
> > Keith
> >
> > Pascal Rapicault wrote:
> > > Keith,
> > >
> > > I checked your documents and the progress you are making with Raphael
> are
> > > great. Let us now when you are able to enable a simple plugin!!!
> > >
> > > I have comments about the terminology and some other details:
> > > - I find the "unresolved" state to be confusing with the existing
> > >
>
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > > amicPlugins/state_description.html), especially in this area of the
> registry
> > > resolution. To my opinion a clear distinction between the states
> unresolved,
> > > disabled, etc. is necessary because they do not represent the same
> > > information.
> > >
> > > - In the bullet 3 of the "plugin diagram" section it is said
"During
> > > platform startup, a registry of unresolved plugins is presented for
> > > resolution" however, I think it is "During platform startup, a SET of
> > > ENABLED plugins is presented for resolution"
> > >
> > >
> > >
> > >>One line of thought is that besides the new plugin and the currently
> > >>resolved plugins, we should also consider plugins which previous
failed
> > >>resolution. The result is that by enabling one plugin, we could have
an
> > >>entire set of plugins become resolved. On the negative side, by
> > >>considering a new plugin, we could have a currently resolved plugin go
> > >>unresolved.
> > >>
> > >>The other line of thought is to only consider the new plugin and
> > >>currently resolved plugins. The operation succeeds if the new plugin
can
> > >>be resolved into the registry without causing any plugins to become
> > >>unresolved. (Ignore extensions etc).
> > >
> > > From the two approaches stated above, I think the first one makes
> the
> > > more sense because it is deterministic. The second one is not because
> the
> > > resolution of plugins depend on enablement order. An other problem
that
> I
> > > can see in the second case is the difference between resolved and
> unresolved
> > > plugins between two sessions: for example during a session I can try
to
> > > enable plugin (whose resolution fails). Then I shutdown and restart,
the
> > > plugin whose resolution failed during the previous startup is resolved
> this
> > > time, and may cause other plugins to be resolved or unresolved.
> > >
> > > Don't you think that the registry could keep track of the unresolved
> > > plugins?
> > >
> > > Could you give more details about the concept of
DynamicExtensionPoint?
> > >
> > > HTH
> > >
> > > PaScaL
> > >
> > >
> >
>
>
|
|
|
| org.eclipse.core.registry.ui plugin [message #28404 is a reply to message #23853] |
Wed, 09 July 2003 17:05 |
| Eclipse User |
|
|
|
I recently created a plugin called 'org.eclipse.core.registry.ui' in the
DynamicPlugins branch. It presents 3 checkbox plugin lists (Resolved,
Unresolved, and Disabled) and 2 buttons (enable and disable). The only
implemented transformation is unresolved->disabled.
|
|
|
Goto Forum:
Current Time: Tue Nov 04 09:52:45 EST 2025
Powered by FUDForum. Page generated in 0.09509 seconds |
Home