[ANN] PLUS 0.0.2 (Localization support)

Hello,
Subj. It have support for localizing in your plugins. I already start using it in my development, and it work such as ok... as far as me :))

I think that in nearest feature no new features will add in PLUS, only bug fixes. I start to write documentation "how to use it".

Also posted some screenshots and writen a little overview on:
http://www.intellij.org/twiki/bin/view/Main/PlusPlugin

Plugin can be dowloaded throught IDEA Plugin Manager or directly here http://plugins.intellij.net/plugins/view/?id=PLUS

Changes:
0.0.2
-


  • Sources of API bundled into binary distribution

  • Localizer service configuration for default system locale

  • Localizer service

  • JOptionPane in AboutPlugin service replaced by special splash

  • AboutPlugin service improvements

  • PluginDescriptor service improvements

  • Bug fixes


Thanks, and hope that this staff will be helpfull for somebody :)

PS. If somebody have any words, espeacialy "reproach" words, i'll be very pleasant to know, that is no good currently in PLUS. So, if you have a little time for me, please write some blames! :)

13 comments

cool ... will check this stuff out ...
another feature that is not on the list (and that almost every plugin
needs is (similar to the internationalized string) something like an
icon-cache) .. i have seen at least three different, similar
implementations of this functionality in different plugins.

another question i have is (i have not yet looked into it) how to
integrate this plugin with own plugins ... how can i enforce, that the
plus-plugin is installed, when my plugin needs it?

thanks

cK

0

cool ... will check this stuff out ...


Thanks :)

another feature that is not on the list (and that
almost every plugin
needs is (similar to the internationalized string)
something like an
icon-cache) .. i have seen at least three different,
similar implementations of this functionality in different
plugins.


If you talking about IconLoader - you can find it in openapi.jar. So, can you, please, describe a more your idea?

another question i have is (i have not yet looked
into it) how to
integrate this plugin with own plugins ... how can i
enforce, that the
plus-plugin is installed, when my plugin needs it?


It now realy "bad place"... Will be fine, if PluginManager have add to plugin.xml "depends" tag with names of depended plugins.

So, now, easiest way to check out PLUS installed is try to get "ServiceManager" from Application.getComponent(Class).

If plugin is installed in IDEA, them you just use them and thats all. If, not, then you should say "Ops" and throw some exception to break component initialization in IDEA.

Thank you!

0

Alexey Efimov wrote:

It now realy "bad place"... Will be fine, if PluginManager have add to plugin.xml "depends" tag with names of depended plugins.
If plugin is installed in IDEA, them you just use them and thats all. If, not, then you should say "Ops" and throw some exception to break component initialization in IDEA.


Exactly what I'd hate to see.. (as I described in a previous post). If
everybody takes this course, eventualy this would lead to a jEdit-like
situation, where in order to load a single plugin you need to resolve
all its dependencies and after you uninstall a plugin, you leave all its
dependencies "in case someone else needs them".

If IDEA has to manage the dependencies, this would lead to a whole new
host of bugs in the Plugin Manager with very little (compared to null)
benefit from the users standpoint.

As for the developers, if we assume that all the developers start to use
the plugin, guess what will happen when the API changes incompatibly?
Since you cannot load two versions of the same plugin side by side, if
two plugins depend on different versions of PLUS, they won't be able to
run in the same IDEA instance (already happened with jEdit).

And finaly, this introduces one more Actor (in the UML sense) who could
break the API incompatibly (so far only JetBrains could do this).

From my viewpoint, the PLUS should be just what it claims to be - a
library. A simple jar with utils, which the plugin authors could use -
no service repository, no central configuration.

my 2c,
Dimiter

p.s. I don't write or maintain any plugin now, so feel free to ignore my
comments.

0

Hello!

First of all, thank you for reply!

It now realy "bad place"... Will be fine, if PluginManager have add to

plugin.xml "depends" tag with names of depended plugins.

If plugin is installed in IDEA, them you just use them and thats all.

If, not, then you should say "Ops" and throw some exception to break
component initialization in IDEA.
>

Exactly what I'd hate to see.. (as I described in a previous post). If
everybody takes this course, eventualy this would lead to a jEdit-like
situation, where in order to load a single plugin you need to resolve
all its dependencies and after you uninstall a plugin, you leave all its
dependencies "in case someone else needs them".

>

If plugin.xml descriptor will have depends tag, then is it posible to
calculate
that no any depended plugins, and remove it too.

As for the developers, if we assume that all the developers start to use
the plugin, guess what will happen when the API changes incompatibly?
Since you cannot load two versions of the same plugin side by side, if
two plugins depend on different versions of PLUS, they won't be able to
run in the same IDEA instance (already happened with jEdit).

>

And finaly, this introduces one more Actor (in the UML sense) who could
break the API incompatibly (so far only JetBrains could do this).

>

The only one thing, that i want to leave - is version compability - i will
religiously
check all API changes, and PLUS will always backward compability in context
of current IDEA version.

From my viewpoint, the PLUS should be just what it claims to be - a
library. A simple jar with utils, which the plugin authors could use -
no service repository, no central configuration.

>

Why is a plugin? Becouse:
1. It can be installed and uninstalled by existing PluginManager, and i will
no have any support of this process.
2. It can be upgraded on all clients with out plugin recompiling - just
install new PLUS into idea (sure, with backward compability).
3. It have some user configurations (current Language for LocalizerService)
4. I like plugins :))

So, for resume.
1. PLUS will always have backward compability - as requirement.
2. PLUS is plugin, and must be upgraded as plugin from user side, not from
developer.
3. PLUS is dependent plugin, but now it not tracked by PluginManager, and i
don't know willit or not.

Hope to continue discussion! :)

Thank you very much!


0

Alexey Efimov wrote:

>> From my viewpoint, the PLUS should be just what it claims to be - a
>>library. A simple jar with utils, which the plugin authors could use -
>>no service repository, no central configuration.
i had a problem with different versions of libraries bundles with
plugins (namingly some jaxen-xml-stuff) ... i filed a bug, but i dont
know if it was reproducable enough ... in my case the (almost same)
classes got mixed up so that another plugin (the jira-browser) got an
classcast exception which lead to the question ... when are two classes
of the same name not equal :)) ... so only one version of a library in
the system would be better ... if the depends stuff is smart coded it
could recognize if someone uses a plugin and if not could mark them or
just throw them away :))

regarding the iconcachething we were discussing ... i checked the
sources (as in the openapoi_stub.zip) of the iconloader and the
iconloader does a caching of the disabled icons, but as far as i see not
of the images that are used for normal icons ... as said .. i saw the
iconcache thing in the psiviewer and some other plugins. i dont know if
the cache really gets a hit, when it is only "shared" from one plugin
but in dubio pro reo .. perhaps it is more lazy for the plugincreator to
refer to images always via the cache ...

cK




0

Hello Christian!

if the depends stuff
is smart coded it
could recognize if someone uses a plugin and if not
could mark them or
just throw them away :))

As i said before, PLUS is will have backward compability - you no need to use diferent version, just use current :)
But plugin must say "I need to use PLUS version 0.2". Then PluginManager will upgrade PLUS on system to curent version.

regarding the iconcachething we were discussing ...
i dont know if
the cache really gets a hit, when it is only "shared"
from one plugin
but in dubio pro reo .. perhaps it is more lazy for
the plugincreator to
refer to images always via the cache ...


I still not correctly understand you... Does this code is true logic?


Can you give some implmentation of Service for PLUS to see how it work?

Thank you!

0

Alexey Efimov wrote:

If plugin.xml descriptor will have depends tag, then is it posible to
calculate
that no any depended plugins, and remove it too.


The only one thing, that i want to leave - is version compability - i will
religiously
check all API changes, and PLUS will always backward compability in context
of current IDEA version.


Well, accept that at certain time you'd NEED to break compatibility for
various reasons, not the least of them is that rarely anybody gets the
things right the first time. Of course, you could always take the
Microsoft approach and provide I18nSupport1, I18nSupport2, etc. classes,
but this makes the mess even bigger, since then you'd have to handle all
the versions at once (not to mention backporting the bugfixes.)

Again it's not such big issue to break some dependent plugins - just
trying to explain my reasons against it.

Why is a plugin? Becouse:
1. It can be installed and uninstalled by existing PluginManager, and i will
no have any support of this process.


If it is a simple jar, it could be bundled with the plugins themselves.
Since each plugin has its own classloader, this would also solve the
versioning conflicts.

2. It can be upgraded on all clients with out plugin recompiling - just
install new PLUS into idea (sure, with backward compability).


Do all clients really need upgrade? Think that it's best to leave this
decision to the plugin author.

3. It have some user configurations (current Language for LocalizerService)


This is a valid reasons, but as I explained earlyer, I believe that the
place for the services shared between multiple plugins is in the
OpenAPI and the configurations should be provided by IDEA itself.
Currently the config is split in two domains - Project and IDE, each of
them with more or less clear designation. The PLUS configuration appears
to be entirely new domain and I can't imagine what should be its scope
and purpose (the "we'll put in there everything whe don't have place
for" approach doesn't look right to me.)

4. I like plugins :))


That's for sure :)

So, for resume.

]]>

2. PLUS is plugin, and must be upgraded as plugin from user side, not from
developer.


What is the exact benefit of having this feature?
(apart from the coolness factor)


Cheers and keep on the good work!

Dimiter

0

Hi!

If it is a simple jar, it could be bundled with the
plugins themselves.
Since each plugin has its own classloader, this would
also solve the
versioning conflicts.

I'm not so sure. Now plugin loaded by dedicated classloader, by all classloader is shared. For simplicity - you can't have a valid safe version in your plugin classpath - if you have different version of same lib in two plugin - in real is used only one library - who is loaded first.

Do all clients really need upgrade? Think that it's
best to leave this
decision to the plugin author.


Maybe... While PluginManager is not supported dependency - it a idle talking. So, if JetBrains will implement this, then lib jars is not very good. I know that PluginManager have such request to dependency, and not only for me.

The PLUS
configuration appears
to be entirely new domain and I can't imagine what
should be its scope
and purpose (the "we'll put in there everything whe
don't have place
for" approach doesn't look right to me.)

Did you look at PLUS configuration? It configure current language of IDE - it IDE setting only. And apeared in IDE setting, sure :)

4. I like plugins :))


That's for sure :)


Not at all :) I realy like plugins :)

2. PLUS is plugin, and must be upgraded as plugin

from user side, not from

developer.


What is the exact benefit of having this feature?
(apart from the coolness factor)


The short - PLUS versions independency. Developer use current version of PLUS, and not support any troubles with different versions. And also, problems with IDEA plugin classloader (or features :))... It not designed for using different versions of the same library in plugins...


Thanks you!

0

Hello Dimiter!

I try using PLUS in my plugin... and it's not to easy, as i think before. It
seems to be more easy, then it will be a library. I must put my words back,
you are right about version tracking. Becouse now i must check PLUS
installed.

So, i think we must start discuss how to get right distribution of this
utilities. For example, i think it must be whole changes in API, becouse if
library will used, then no Services is available, just lib with some
utilities.

But, i also think, that PLUS must be consists of two parts - one is
library - and second, is a plugin as interface to configure some PLUS
parameters.

Thanks!


0

Hi Alexey,

But, i also think, that PLUS must be consists of two parts - one is
library - and second, is a plugin as interface to configure some PLUS
parameters.


Now this one, I think is a good idea (no pun). As I am not involved with
developing any plugin now, my oppinion might be wrong, but here it is
for what it's worth:

The PLUS package, could be distributed in source form, the services
should be in separate packages with strictly imposed, documented
dependencies. This way a plugin author could include custom built PLUS
version in their jar. If you feel generous enough you could even provide
option in the ant script to specify the included features (you can use
partial build targets, following the order of documented dependencies).

Each service package could provide a configuration component. When a
plugin writer uses a service, he would include it's panel in his/hers
own configuration panel. On first glimpse it might look like unnecessary
duplication, but I could imagine that I'd like some settings for one
plugin and not another. Also it would give consistent high level UI for
some configurations.

This way, the plugin writer has the freedom to:

a) Include customized PLUS jar as a contained library

b) Include the PLUS classes in his own jar

c) (not recommended) To include a snapshot of PLUS sources in his
own project tree

Also, in my oppinion it is more or less acceptable to break the API when
needed, but you should NEVER change the stored settings format
incompatibly. Since you control the source, you have the right and
responsibility to not release a version until the conversion routine
from the old format(s) are tested.

And in the end, I think nobody would mind if you draw some "Powered by
PLUS" button.

cheers,
Dimiter (BREW-ing in the C hell)

0

Hello!

Ok, i'm get a picture. Now i try to get library jar with a source sure, and optional Plugin for setting some services in this library.

Your idea of "Settings Per Plugin" is very interesting, but i thing that also is concurent by configuration API of IDEA itself - every plugin may have such configuration, so my guess - PLUS is not better to solve this.

I also disagree with "putting sources into plugin repositary", becouse library jar must be used, and sources as documentation and source browsing only.

But, some common tasks - as About plugin service, maybe will be better to do with Wizard plugin - it will be performed only once - by generation... PLUS is not handle this in any case. But maybe i'm wrong.

Some services maybe generated, but some services must be in PLUS.

I think, that generated services - is for example:

  • About box

  • Localizer


PLUS services:

  • About action manager, to register your about box action in common "About Boxes menu"

  • Common localization engine, that be used in generated code.

  • PluginDescriptor service


Thanks!

0

Alexey Efimov wrote:

Ok, i'm get a picture. Now i try to get library jar with a source sure,

and optional Plugin for setting some services in this library.

Your idea of "Settings Per Plugin" is very interesting, but i

thing that also is concurent by configuration API of IDEA itself -
every plugin may have such configuration, so my guess - PLUS is not
better to solve this.

Nope, perhaps I didn't explain it right. What I mean is that each
service provided by PLUS should contain a widget (call it custom
control, panel, whatever) which can be embedded in the hosting plugin
configuration pannel. (No central PLUS configuration)

Imagine somebody wants to make a coffee maker plugin and you provide a
timer service. The timer service package would contain a TimerConfigUi
class, which would extend JPanel and would contain controls for setting
the length of a period, recurrence and other timer parameters. The
coffee maker plugin author would embed this panel in the coffee maker
configuration panel, so the timer settings looks like a part of the
coffee maker settings. Now if somebody wants to create alarm clock
plugin he could also embed the same panel in his configuration. This way
you have the timer controls in two places, but they serve for two
distinct purposes.

On the other hand, for some services like localisation it does make
sence. But still imagine that some plugin's translation is wrong or just
annoyingly stupid (I see this situation all the time with some OS
projects.) Now it would make sence for these to have a PLUS 'dashboard'
where you can set the DEFAULT settings for some services, but IMHO this
shouldn't be requirement. If the PLUS dashboard is present and a service
configuration is left as ]]>, the service should query for default
value, but if an user likes to change the config, he could do it per
plugin. Also if the 'dashboard' plugin isn't present, the coffee maker
should continue working.

I also disagree with "putting sources into plugin repositary", becouse

library jar must be used, and sources as documentation and source
browsing only.

And what if I'm doing a quick hack plugin for my company internal usage?
You don't have control over your clients, so keep in mind the worst case
(in this case it's not that bad.)

But, some common tasks - as About plugin service, maybe will be better

to do with Wizard plugin - it will be performed only once - by
generation...
PLUS is not handle this in any case. But maybe i'm wrong.

I can't see why the AboutDialog should be generated (I might be also
wrong..) About the localizer, I'm not sure what you mean -
ResourceBundle? I can't see a good way to generate something meaningfull
before tha app is developed (wasn't there a I18N plugin?)

PLUS services:

  • About action manager, to register your about box action in common "About Boxes menu"


Again, what is the advantage over having each plugin contain "About"
button (which would be provided in the 'about' service package.) The
disadvantage is that it would add more clutter to the menu (if JB
provide customizable menus I would even remove 'window' and 'help')

  • * Common localization engine, that be used in generated code.


I haven't looked at it so far, but what's the advantage compared to
using ResourceBundles?

  • * PluginDescriptor service


What is this?

I think that before going into even more planning, you should write down
all your ideas about services (even the stupid ones) together with some
simple descriptions. Then ask the plugin authors to take a look and to
add comments, what they think would be usefull, for which plugin, are
they satisfied with the way it's planned to work, etc. And then you'd
have some real input.

There are a lot of choices, and anyway you'd have to make some
compromises, but I think it's better to make them knowingly, judging the
price and the benefits of each decision.

cheers,
Dimiter

0

Hello,

Nope, perhaps I didn't explain it right. What I mean
is that each
service provided by PLUS should contain a widget
(call it custom
control, panel, whatever) which can be embedded in
the hosting plugin
configuration pannel. (No central PLUS configuration)

Ok, now i understand it clear! And will try implement this. It's a good idea.


If the PLUS dashboard is
present and a service
configuration is left as <default>, the service
should query for default
value, but if an user likes to change the config, he
could do it per
plugin. Also if the 'dashboard' plugin isn't present,
the coffee maker
should continue working.


If service is might be configurable per plugin, then it must. But if not, then only one configuration will supported. For example Localizer service - only one locale must be setted as Default (current).


And what if I'm doing a quick hack plugin for my
company internal usage?


Hmm... I can't image that you may use "custom" version of IDEA plugin... But in this case, PLUS library will have sources, and you just may use them, but not publish - it's no matter how you use plus library, but better if you will use jar.

I can't see why the AboutDialog should be generated
(I might be also
wrong..) About the localizer, I'm not sure what you
mean -
ResourceBundle? I can't see a good way to generate
something meaningfull
before tha app is developed (wasn't there a I18N
plugin?)


Maybe you not look at PLUS api yet? :) So, you can read about every service here:
http://www.intellij.org/twiki/bin/view/Main/PlusPluginGuide

Thanks!

0

Please sign in to leave a comment.