Re: Incompatible change for extensions

[Jürgen Schmidt]

On 8/1/13 12:10 AM, Mathias Röllig wrote:
> Hi!
> 
> I must correct myself:
> 
> I wrote
> 
>> But: It doesn't work for com.sun.star.frame.StartModule
> 
> With an other extension I saw, it works! So I searched for the problem.
> 
> For the first try to edit the Addons.xcu I have made a mistake and I
> inserted the new  not at the right place. So AOO doesn't
> read the title information and created the "Add-on 1" title.
> But after I corrected my mistake I uninstalled and installed my
> extension many times, but the title stays at "Add-on 1". The other
> modules that I doesn't started before shows the right name. That's why I
> was thinking that the title information doesn't work with the StartModule.
> 
> Now I find that the information about the title was stored in
> registrymodifications.xcu. I deleted the  with the title
> information manually - now it works as expected!
> 
> So the question and problem is: Why was the information about the (title
> of the) toolbar not deleted from registrymodifications after
> uninstalling the extension?
> 
> 
> But my suggestion resides;
> 
>> As stated in https://issues.apache.org/ooo/show_bug.cgi?id=121577#c2
>> "Setting the toolbar title in Addons.xcu will take precedence over the
>> WindowState.xcu."
>>
>> In my opinion the "normal" way is, that a special property overwrites
>> the default property. So, if only one module should have a different
>> title, there must be only this one WindowState.xcu.
>>
>> Could this behaviour be changed?

First of all we have to reproduce this and then we can investigate the
root cause. Maybe due the fact that you had incorrect config items in
between the workflow got broken in some way. I don't know you can try to
reproduce it with a valid old and valid new extension. But restart the
office after uninstalling the old and before the installation of the new.

Juergen

> 
> 
> Greetings, Mathias
> 
> -
> To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: api-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org

Re: Incompatible change for extensions

[Mathias Röllig]

Hi!

I must correct myself:

I wrote


But: It doesn't work for com.sun.star.frame.StartModule


With an other extension I saw, it works! So I searched for the problem.

For the first try to edit the Addons.xcu I have made a mistake and I 
inserted the new  not at the right place. So AOO doesn't 
read the title information and created the "Add-on 1" title.
But after I corrected my mistake I uninstalled and installed my 
extension many times, but the title stays at "Add-on 1". The other 
modules that I doesn't started before shows the right name. That's why I 
was thinking that the title information doesn't work with the StartModule.


Now I find that the information about the title was stored in 
registrymodifications.xcu. I deleted the  with the title 
information manually - now it works as expected!


So the question and problem is: Why was the information about the (title 
of the) toolbar not deleted from registrymodifications after 
uninstalling the extension?



But my suggestion resides;


As stated in https://issues.apache.org/ooo/show_bug.cgi?id=121577#c2
"Setting the toolbar title in Addons.xcu will take precedence over the
WindowState.xcu."

In my opinion the "normal" way is, that a special property overwrites
the default property. So, if only one module should have a different
title, there must be only this one WindowState.xcu.

Could this behaviour be changed?



Greetings, Mathias

-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org

Re: Incompatible change for extensions

[Mathias Röllig]

Hello!

Now I'm trying AOO 4.0 and have to work over my extensions.

First: Thank you for the change!

But: It doesn't work for com.sun.star.frame.StartModule
(Should I file a separate issue or comment bug 121577?)

Second:
As stated in https://issues.apache.org/ooo/show_bug.cgi?id=121577#c2
"Setting the toolbar title in Addons.xcu will take precedence over the 
WindowState.xcu."


In my opinion the "normal" way is, that a special property overwrites 
the default property. So, if only one module should have a different 
title, there must be only this one WindowState.xcu.


Could this behaviour be changed?

Greetings, Mathias

-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org

Re: Incompatible change for extensions

[Andrea Pescetti]

On 11/02/2013 Ariel Constenla-Haile wrote:

And this incompatible API change isn't arguable, that is: it has already
been discussed, I won't revert it, and won't accept anyone else reverting
it, period.


OK, and from the links and context I get this is a different issue than 
the one originally discussed here. What's the impact of this other 
change? Does it affect a narrow class of extensions or, like the other 
one, it requires that most code extensions are rewritten?


In any case, it is material for the Release Notes. I mentioned it in
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
but it would be good to know more.

Regards,
  Andrea.

Re: Incompatible change for extensions

[Jürgen Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2/11/13 12:24 PM, Ariel Constenla-Haile wrote:
> Hi,
> 
> Sorry for the delay, I'm on vacations mode.
> 
> On Mon, Feb 04, 2013 at 01:44:49PM +0100, Jrgen Schmidt wrote:
>> Hi Ariel,
>> 
>> after some talks about this topic at FOSDEM I was thinking about
>> it again. What do you think how much effort it would be to create
>> a new scheme for the new extended toolbars and keep the old one
>> at least for a while? I know it will be more work in the
>> underlying code but we should at least think about it or what do
>> you mean?
> 
> I guess you are talking about leaving the "OfficeToolBar" as
> before:
> 
>  
> 
> and adding a new set:
> 
>  oor:node-type="ToolBar"> 
> 
> 
> I don't see the point in having two sets, it's just adding more 
> complexity and awfulness to the one already there.

I totally agree and you confirm my assumption.

> 
> And compatibility is not an argument here: an extension that uses
> this configuration set is a code-extensions; an extension using
> simply toolbar merging might have no code in it, but extensions
> with own toolbars have code. Any extension having code, must be
> checked by the extension developer in order to adapt it to the
> incompatible API changes.
> 
> For this particular subject of the incompatible change of schema I
> see two options:
> 
> - leave the change as is
> 
> - revert commit in revision 1429069 
> http://svn.apache.org/viewvc?view=revision&revision=1429069
> 
> I'm fine with reverting it; if you think so, simply ask and Ill do
> it (side note: you knew it was an incompatible change 
> http://markmail.org/message/7qbzndiascunlx2i and gave the ok to
> commit it - at least Ii had inferred this from seeing my name in 
> http://markmail.org/message/fhsepy2a56yhubi2 ).

don't get me wrong I am still supporting this change 100%. I simply
wanted to make clear that we listening to raised concerns and think
about it at least. And I think that my opinion doesn't count more than
from anybody else ;-)

> 
> 
> 
> Back to the subject of this thread, that really misses the point
> mixing the configuration schema change: the incompatible API
> changes are not arguable, this has been already discussed several
> years ago; it's not "there is a major version, so let's change the
> API in an incompatible way"; on the contrary, it is about API
> changes that have been on the queue for a long time, waiting for a
> major release.
> 
> I will only put as example my first code contribution to
> OpenOffice.org: http://markmail.org/message/ntqgiwaclcuhuzfk
> 
> It would be interesting that people read the whole thread 
> http://markmail.org/thread/vdoydqphpsyw2mw6 because the whole thing
> is turning now into some kind of dej￠-vu.
> 
> This is a clear example of an incompatible API change that was
> known since the very first time it was developed, and that was
> waiting since 2008 for a major release; and the incompatible API
> change was applied in revision 1425458 
> http://svn.apache.org/viewvc?view=revision&revision=1425458 and is 
> tracked under bug 121542 
> https://issues.apache.org/ooo/show_bug.cgi?id=121542#c2
> 
> This is a rather illustrative example of me "cleaning up my own
> mess" (http://markmail.org/message/m7wousc55loekdxa the whole
> thread is worth reading in order to avoid the waste of time of
> discussing already discussed things
> http://markmail.org/thread/tid7fj6mg5wxlz4b), but there are several
> other obvious examples; if we had the time and resources (code
> contributors), the whole API should be reviewed, going through 
> every idl file.

+100 'I am totally with you here

> 
> And this incompatible API change isn't arguable, that is: it has
> already been discussed, I won't revert it, and won't accept anyone
> else reverting it, period.

+1

In general I believe we must be able to change things to correct
design errors or simply to improve things. We have proven that we made
a lot of mistakes and still tried to keep API's compatible, we should
look forward and should allow to fix such problems with major
releases. Important is that we show and document the migration path
clearly.

Juergen



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGOKoAAoJEM/u8xZRtf3oGEMP/1trm7GtR3wwvIlOsuzuxSdU
a1nSXZEgGZSkn2l1e9dSLi6B6pDkMiq4Em7lLaMKJku0A+52yzS8kVDGFRaVJesW
RhzzI2cNqVvVRA+A97q97Jf2zr5gezsKSRYaWvXEyDAHkpc2Bg/t0Yvo4lwv5be1
GzRn9S9jVHLoGwjWy8FKO0WPi6DjlFplFn6+tFhhb4y5XP52jZo/B8DEKoMrM0VK
4bd7i2D2rtUKAOJWjhBgvp/kBvFMNQpXOlbcMqzz4jJyWChfIynvNydM3CiU3fnk
kQuAs0uJruAuyCrr25FcQVHt9CSvWonjK78+pn4ATqxz5Q8SazRBcFfyeyu0S2Ku
UCOXTET452kIyehsXtmaPl+Sv32msusXRGjJeHGnB+xIwNOyN0riek1R41ZtmqzQ
zFV33Q7SlFyi6S7bzYHoHHGarijKhBOC3XDVeZDfDPSHAym03U3bMYqW4BCBaOTH
69lPFtjeaxjSk+xW3aOdKHasoMIv1v713sjZ1ZaeOo0kJhOa1KMQWSlr9AioTNwA
Zi/QBLliRUNBfUuwoI0kAgf2eyGCBFYPku081mY5Qr5iEIAe2i9WKRoKNd

Re: Incompatible change for extensions

[Ariel Constenla-Haile]

Hi,

Sorry for the delay, I'm on vacations mode.

On Mon, Feb 04, 2013 at 01:44:49PM +0100, Jürgen Schmidt wrote:
> Hi Ariel,
> 
> after some talks about this topic at FOSDEM I was thinking about it
> again. What do you think how much effort it would be to create a new
> scheme for the new extended toolbars and keep the old one at least for a
> while? I know it will be more work in the underlying code but we should
> at least think about it or what do you mean?

I guess you are talking about leaving the "OfficeToolBar" as before:




and adding a new set:





I don't see the point in having two sets, it's just adding more
complexity and awfulness to the one already there.

And compatibility is not an argument here: an extension that uses this
configuration set is a code-extensions; an extension using simply
toolbar merging might have no code in it, but extensions with own
toolbars have code. Any extension having code, must be checked by the
extension developer in order to adapt it to the incompatible API
changes.

For this particular subject of the incompatible change of schema I see
two options:

- leave the change as is

- revert commit in revision 1429069
  http://svn.apache.org/viewvc?view=revision&revision=1429069

I'm fine with reverting it; if you think so, simply ask and Ill do it
(side note: you knew it was an incompatible change
http://markmail.org/message/7qbzndiascunlx2i and gave the ok to commit
it - at least Ii had inferred this from seeing my name in
http://markmail.org/message/fhsepy2a56yhubi2 ).



Back to the subject of this thread, that really misses the point mixing
the configuration schema change: the incompatible API changes are not
arguable, this has been already discussed several years ago; it's not
"there is a major version, so let's change the API in an incompatible
way"; on the contrary, it is about API changes that have been on the
queue for a long time, waiting for a major release.

I will only put as example my first code contribution to OpenOffice.org:
http://markmail.org/message/ntqgiwaclcuhuzfk

It would be interesting that people read the whole thread
http://markmail.org/thread/vdoydqphpsyw2mw6 because the whole thing is
turning now into some kind of dejà-vu.

This is a clear example of an incompatible API change that was known
since the very first time it was developed, and that was waiting since
2008 for a major release; and the incompatible API change was applied in
revision 1425458
http://svn.apache.org/viewvc?view=revision&revision=1425458 and is
tracked under bug 121542
https://issues.apache.org/ooo/show_bug.cgi?id=121542#c2

This is a rather illustrative example of me "cleaning up my own mess"
(http://markmail.org/message/m7wousc55loekdxa the whole thread is worth
reading in order to avoid the waste of time of discussing already
discussed things http://markmail.org/thread/tid7fj6mg5wxlz4b), but there
are several other obvious examples; if we had the time and resources
(code contributors), the whole API should be reviewed, going through
every idl file.

And this incompatible API change isn't arguable, that is: it has already
been discussed, I won't revert it, and won't accept anyone else reverting
it, period.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgp5SkWv45YV2.pgp
Description: PGP signature

Re: Incompatible change for extensions

[Oliver Brinzing]

Hi Jürgen,

> see for example a toolbar entry for the new scheme:

thanks, i will have a look ;-)

Regards

Oliver
-- 

GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45



signature.asc
Description: OpenPGP digital signature

Re: Incompatible change for extensions

[Jürgen Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2/4/13 6:12 PM, Oliver Brinzing wrote:
> Hi
> 
>> What do you think how much effort it would be to create a new
>> scheme for the new extended toolbars and keep the old one at
>> least for a while?
> 
> +1

well it's just thinking nothing more.

> 
> due to api changes (e.g. toolsbars, com.sun.star.awt.XMessageBox,
> ...) i cannot run my oo32 extension with aoo 3.5 at the moment. so
> testing is pretty difficult.

you can test it quite easy and can adapt your Addon.xcu to the new scheme.

see for example a toolbar entry for the new scheme:


...

  

  Test Toolbar Title


  

 com.example.newaddonwithtoolbartitle:testcommand


  _self


  com.sun.star.text.TextDocument


  Test Command

  

  

...

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJRENKiAAoJEM/u8xZRtf3od6EQAKfAx4vswmfVw6k0iNF77ntZ
TuLAt4IJvoNPZJjiEZuIJYFp4IDce4ATcEG67o3+LvVLZTTLSDF0eVPJUE/a91IN
DPIusDQ996y+wwqrv04u6PiKPq/nr6gerSxI0lUKbUAxMAb7T8X904mTjIyzDBpA
d1Pdm3bWW29jK1UnFLLKMMM2EpWsIGkcmWcv1PRWyzydnFAgks43C5WovHNWNnjF
VTYUo6XYBwlGz367hRT4rB/dDk+/xs8hEZTrcrnvGH4b/l5DUBF2xqU9jadbO/LX
QKaLAJYa8/YM4b3V2vag+3+fvgIP/Sx1dxyvQU/XeOu4rESaZQze2FRJZqUQeuSa
cw1ZTvDWKeXVQ0fad1cxUq91bXv6gu5Y03d7WSTKjlsSQeHtS30RcQzqMJGbrYiE
mOAk8lIwW75N5cj5/2oJMBBNkVJi5pHTIYWQFX3DwUzmbHrVYBFugcMna/SaXbxZ
EjWo8lGRMcun2PrCX2uJTvL3mvr28508hj8yLDLtmE9XVTOPx2y/CTl68Tm//DRJ
DiC/VzTJ2snyT7mO+jdu8Op+h7WfcU5XE1Invusr3kmy0+YxHR4YNN1brv9n5LHo
Gp6tezv+AjqtHh19fPj8xB0uZbYfEA0u4vYminLPgcOJ+n1vQlb9XaUtx/UVxiTS
g5BMc4g2VceVUIb51xw+
=McZ8
-END PGP SIGNATURE-

Re: Incompatible change for extensions

[Oliver Brinzing]

Hi

> What do you think how much effort it would be to create a new scheme
> for the new extended toolbars and keep the old one at least for a while?

+1

due to api changes (e.g. toolsbars, com.sun.star.awt.XMessageBox, ...) i cannot
run my oo32 extension with aoo 3.5 at the moment. so testing is pretty 
difficult.

Best Regards

Oliver


-- 

GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45



signature.asc
Description: OpenPGP digital signature

Re: Incompatible change for extensions

[Jürgen Schmidt]

Hi Ariel,

after some talks about this topic at FOSDEM I was thinking about it
again. What do you think how much effort it would be to create a new
scheme for the new extended toolbars and keep the old one at least for a
while? I know it will be more work in the underlying code but we should
at least think about it or what do you mean?

Juergen

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/25/13 3:50 PM, Bernard Marcelly wrote:
> Message de Jürgen Schmidt  date 2013-01-25 13:55 :
>> On 1/25/13 12:44 AM, Andrea Pescetti wrote:
>>> Rob Weir wrote:
 I also like the idea of marking a function as deprecated, maybe even
 supporting the new and old together for a release, to give time for
 transition.
>>>
>>> If at all feasible, I would be for this. Ideally, we should be able to
>>> install a legacy extension by: recognizing it's using legacy APIs or
>>> conventions; displaying a warning; running it anyway, trying to be as
>>> compatible as possible.
>>
>> this would be indeed nice and if easy possible we would probably do
>> that. But the reality is that we don't have the resources to spent
>> enough time on this.
> 
> OK, we don't have enough resources, but then why spend scarce resources
> on secondary aspects of the API ? Even if it is simple to do, it's not a
> sufficient reason. Better develop or correct something that was
> requested by bug reports and that appears within available resources.

because you can't tell volunteers what they should do. If somebody like
to work on bugfixes, fine, perfect but if somebody prefers to improve
other areas it also fine. I am happy for anybody who is interested to
work on the code in general ;-)

> 
> I am not against incompatible changes, if it is inevitable in order to
> provide a new feature very valuable for the API users. But the changes
> proposed by Ariel, as far as they are described, do not add anything
> useful for the API user.
> 
>> We have as deprecated marked API's and I am sure that people will still
>> use it. These API's are probably deprecated since > 3-4 versions and we
>> should be save to remove them. But I am sure people would complain about
>> it if there macro, solution won't run anymore.
> 
> That's why I would prefer adding new services/interfaces, and keep the
> old ones with a mention : DEPRECATED, see so-and-so. A perfect example
> is service com.sun.star.document.DocumentInfo. You can be sure that
> there are still many users of this now obsolete service. They are not
> aware of the new service, and don't care.

I agree and the problem with this example is that it was not clear
communicated. We should include such changes clearly in the release
notes and should provide links to the migration path.

> 
> But you can also find many IDL pages flagged DEPRECATED without
> indication of an alternative, nor simply saying that the feature is
> killed. This is not helpful for the poor API user.

indeed and sometimes the intention is simply to drop this API's because
the mistake was to provide an API for it from the beginning and it makes
more problems than it helps. Or name it the missing feature of private
API's.

But where I am thinking about it, it could be so easy by simply putting
private API's in a private namespace/module. This can be easy filtered
when generating API reference docu etc.

Juergen

Re: Incompatible change for extensions

[Bernard Marcelly]

Message de Jürgen Schmidt  date 2013-01-25 13:55 :

On 1/25/13 12:44 AM, Andrea Pescetti wrote:

Rob Weir wrote:

I also like the idea of marking a function as deprecated, maybe even
supporting the new and old together for a release, to give time for
transition.


If at all feasible, I would be for this. Ideally, we should be able to
install a legacy extension by: recognizing it's using legacy APIs or
conventions; displaying a warning; running it anyway, trying to be as
compatible as possible.


this would be indeed nice and if easy possible we would probably do
that. But the reality is that we don't have the resources to spent
enough time on this.


OK, we don't have enough resources, but then why spend scarce resources on 
secondary aspects of the API ? Even if it is simple to do, it's not a sufficient 
reason. Better develop or correct something that was requested by bug reports 
and that appears within available resources.


I am not against incompatible changes, if it is inevitable in order to provide a 
new feature very valuable for the API users. But the changes proposed by Ariel, 
as far as they are described, do not add anything useful for the API user.



We have as deprecated marked API's and I am sure that people will still
use it. These API's are probably deprecated since > 3-4 versions and we
should be save to remove them. But I am sure people would complain about
it if there macro, solution won't run anymore.


That's why I would prefer adding new services/interfaces, and keep the old ones 
with a mention : DEPRECATED, see so-and-so. A perfect example is service 
com.sun.star.document.DocumentInfo. You can be sure that there are still many 
users of this now obsolete service. They are not aware of the new service, and 
don't care.


But you can also find many IDL pages flagged DEPRECATED without indication of an 
alternative, nor simply saying that the feature is killed. This is not helpful 
for the poor API user.


  Bernard

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/25/13 12:44 AM, Andrea Pescetti wrote:
> Rob Weir wrote:
>> I also like the idea of marking a function as deprecated, maybe even
>> supporting the new and old together for a release, to give time for
>> transition.
> 
> If at all feasible, I would be for this. Ideally, we should be able to
> install a legacy extension by: recognizing it's using legacy APIs or
> conventions; displaying a warning; running it anyway, trying to be as
> compatible as possible.

this would be indeed nice and if easy possible we would probably do
that. But the reality is that we don't have the resources to spent
enough time on this.

We have as deprecated marked API's and I am sure that people will still
use it. These API's are probably deprecated since > 3-4 versions and we
should be save to remove them. But I am sure people would complain about
it if there macro, solution won't run anymore.

We discussed incompatible changes probably 2 years ago and all people
participated in this discussion agreed on incompatible changes in a
major release. We agreed also that incompatible changes are allowed only
if a migration path is available and clearly documented.

For example merging interface XMyInterface, XMyInterface2, XMyInterface3
should be straight forward for Basic developers because the binding hide
the interface hierarchy anyway. For Java/C++ developers it means minor
code changes (removing the pseudo version number) and recompiling the code.

Other changes require potentially bigger changes but if they are well
documented it should be also possible with moderate effort.

It is really a tightrope walk to find the right balance but I believe
that we have to look forward and should improve things.

The API is of course not easy and far to complex and it is a shame that
we didn't put more effort in the past into better and well designed
API's. The overall idea of having one API for internal usage as well as
external (extensions, macros etc. from different languages) is of course
a good one. But is not complete and some things are still missing.

For some things it would be probably good to have some additional high
level API's with good defaults that cover 80% of all use cases (this is
for example the big plus of VBA).

A much better tooling like the NetBeans plugin that simplifies the
development a lot. Bernards XRay tool or the idea of the
InstanceInspector  A more powerful Basic IDE or an
integrated/bundled power IDE for Python would be also nice. Some core
work and API's for such integration is available but the developers who
are interested to help here are missing.

Eclipse which is probably more popular as NetBeans lacks of support for
OO development at the moment. I see there good opportunities but we need
help to work on such things.


> 
> Then of course I don't know how much of this is realistically
> feasible... but Hans is right, the ecosystem is extremely important and
> even unsupported extensions can have a high value for end users (while
> from a technical point of view it's hard to disagree with Juergen and
> Ariel).

The eco system is of course important but it is also important that we
work together. With a little more effort developers can help to improve
the user experience and can use version dependencies to ensure that
extensions work with the latest office. The auto update mechanism should
help to easy provide new tested versions after an office upgrade.

We have potentially detail problems here but this can and should be
fixed. I am nowadays a big friend of min/max dependencies because that
gave me the opportunity to satisfy my customers with always working
extensions.

There is probably no 100% correct way but I am for innovation and making
things better over time.

The key element for me with all this changes is a clear and well
documented migration path.

Juergen










> 
> Regards,
>   Andrea.

Re: Incompatible change for extensions

[Andrea Pescetti]

Rob Weir wrote:

I also like the idea of marking a function as deprecated, maybe even
supporting the new and old together for a release, to give time for
transition.


If at all feasible, I would be for this. Ideally, we should be able to 
install a legacy extension by: recognizing it's using legacy APIs or 
conventions; displaying a warning; running it anyway, trying to be as 
compatible as possible.


Then of course I don't know how much of this is realistically 
feasible... but Hans is right, the ecosystem is extremely important and 
even unsupported extensions can have a high value for end users (while 
from a technical point of view it's hard to disagree with Juergen and 
Ariel).


Regards,
  Andrea.

Re: Incompatible change for extensions

[Rob Weir]

On Thu, Jan 24, 2013 at 11:53 AM, Hans Zybura  wrote:
>> -Original Message-
>> From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
>> Sent: Wednesday, January 23, 2013 3:22 PM
>> To: api@openoffice.apache.org
>> Subject: Re: Incompatible change for extensions
>>
>> On 1/23/13 3:08 PM, Bernard Marcelly wrote:
>> > Message de Jürgen Schmidt  date 2013-01-23 10:12 :
>> >>
>> >> exactly and that means a minor code change and a rebuild. If this
>> >> kind of cleanup changes are not allowed with a major release than we
>> >> do something wrong. You should not forget the benefit for new
>> >> developers that we want to reach. A cleaner and better API is much
>> >> easier to learn for them. Existing developers will have no trouble
>> >> with adapting the changes but all new ones will benefit.
>> >>
>> > If you were reading real user questions in forums you would be
>> > appalled by the low programming level of those wanting to automate
>> > tasks, whether in social clubs, small businesses, administrations and
>> > even big companies. They are often non-programmers, or young trainees,
>> > that create applications that become indispensable. Don't suppose that
>> > they have time and knowledge to quickly debug a program that used to
>> > work for months or years. It will be hard for them to find out which
>> > change happened in the API and how to modify.
>>
>> if they are not maintained or if the code is not available anymore it's
> more a
>> question of time until they won't work. They probably work more by luck.
>>
>> >
>> > If you think that these changes will make the API easier, you are wrong.
>> > OpenOffice API is and will remain huge and complex for the casual
>> > programmer, because it was created by highly qualified programmers, to
>> > be understood and used by their peers; contrary to VBA that is
>> > customer oriented.
>>
>> yes I believe that these are minor step towards better APIs. If we would
>> have the power and resources to change many old style services into new
>> ones with supporting multiple inheritance interfaces many API could be
>> simplified a lot.
>> And I think we have to start to do this stuff and major release can be
> used for
>> this kind of changes.
>>
>> >
>> >> On 1/23/13 9:36 AM, Bernard Marcelly wrote:
>> >>> There is not enough good designers; better spend efforts on
>> >>> correcting reported real bugs, or on useful improvements (e.g. a
>> >>> real integration of Python into OpenOffice, like Basic; or add the
>> >>> new dialog controls in the IDE toolbox).
>> >>
>> >> feel free to join the project and help to improve things like the
>> >> Python support, or improving the basic IDE. Remember volunteers are
>> >> working on the code base and you can't force them what they should do.
>> >>
>> >> It's funny that people request and take more than they gave back.
>> >> Really if you think certain areas of the program need improvements
>> >> please join us and help to improve it.
>> >>
>> > I know my limits. I don't have the knowledge to modify OpenOffice code
>> > and don't like C++ as a language.
>> > I can say that I have given back a lot since 2003. Up to now 275 bugs
>> > reported; thousands of answers in users-fr, prog-fr mailing-lists,
>> > french and english web forums; corrections/improvements in the Wiki
>> > Dev'Guide and Basic Programming Guide; a french book of 900 pages
>> > demystifying OpenOffice programming; several free tools that help API
>> > users.
>> > I am not the only one with such background, others have done same in
>> > other countries/languages. I am just giving my advice: you are on the
>> > wrong path.
>>
>> I meant really on the development level not the other areas you have
>> mentioned. These are of course also very important areas where people
>> help a lot to grow the eco system.
>>
>> Don't get me wrong I appreciate this kind of work a lot.
>>
>> If we don't change things and improve certain areas over time I will lose
> my
>> motivation to work on this code.
>
> I think we all understand this feeling very well. And we surely can all
> agree on the fact, that change and improvements are necessary - API included
> . The question is: what kind of change at what speed and how disruptive, and
>

RE: Incompatible change for extensions

[Hans Zybura]

> -Original Message-
> From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
> Sent: Wednesday, January 23, 2013 3:22 PM
> To: api@openoffice.apache.org
> Subject: Re: Incompatible change for extensions
> 
> On 1/23/13 3:08 PM, Bernard Marcelly wrote:
> > Message de Jürgen Schmidt  date 2013-01-23 10:12 :
> >>
> >> exactly and that means a minor code change and a rebuild. If this
> >> kind of cleanup changes are not allowed with a major release than we
> >> do something wrong. You should not forget the benefit for new
> >> developers that we want to reach. A cleaner and better API is much
> >> easier to learn for them. Existing developers will have no trouble
> >> with adapting the changes but all new ones will benefit.
> >>
> > If you were reading real user questions in forums you would be
> > appalled by the low programming level of those wanting to automate
> > tasks, whether in social clubs, small businesses, administrations and
> > even big companies. They are often non-programmers, or young trainees,
> > that create applications that become indispensable. Don't suppose that
> > they have time and knowledge to quickly debug a program that used to
> > work for months or years. It will be hard for them to find out which
> > change happened in the API and how to modify.
> 
> if they are not maintained or if the code is not available anymore it's
more a
> question of time until they won't work. They probably work more by luck.
> 
> >
> > If you think that these changes will make the API easier, you are wrong.
> > OpenOffice API is and will remain huge and complex for the casual
> > programmer, because it was created by highly qualified programmers, to
> > be understood and used by their peers; contrary to VBA that is
> > customer oriented.
> 
> yes I believe that these are minor step towards better APIs. If we would
> have the power and resources to change many old style services into new
> ones with supporting multiple inheritance interfaces many API could be
> simplified a lot.
> And I think we have to start to do this stuff and major release can be
used for
> this kind of changes.
> 
> >
> >> On 1/23/13 9:36 AM, Bernard Marcelly wrote:
> >>> There is not enough good designers; better spend efforts on
> >>> correcting reported real bugs, or on useful improvements (e.g. a
> >>> real integration of Python into OpenOffice, like Basic; or add the
> >>> new dialog controls in the IDE toolbox).
> >>
> >> feel free to join the project and help to improve things like the
> >> Python support, or improving the basic IDE. Remember volunteers are
> >> working on the code base and you can't force them what they should do.
> >>
> >> It's funny that people request and take more than they gave back.
> >> Really if you think certain areas of the program need improvements
> >> please join us and help to improve it.
> >>
> > I know my limits. I don't have the knowledge to modify OpenOffice code
> > and don't like C++ as a language.
> > I can say that I have given back a lot since 2003. Up to now 275 bugs
> > reported; thousands of answers in users-fr, prog-fr mailing-lists,
> > french and english web forums; corrections/improvements in the Wiki
> > Dev'Guide and Basic Programming Guide; a french book of 900 pages
> > demystifying OpenOffice programming; several free tools that help API
> > users.
> > I am not the only one with such background, others have done same in
> > other countries/languages. I am just giving my advice: you are on the
> > wrong path.
> 
> I meant really on the development level not the other areas you have
> mentioned. These are of course also very important areas where people
> help a lot to grow the eco system.
> 
> Don't get me wrong I appreciate this kind of work a lot.
> 
> If we don't change things and improve certain areas over time I will lose
my
> motivation to work on this code.

I think we all understand this feeling very well. And we surely can all
agree on the fact, that change and improvements are necessary - API included
. The question is: what kind of change at what speed and how disruptive, and
how seriously you are adopting the eco system style of thinking.

Let's calmly sit back, forget release 4.0 for a moment, and think again.

>From your and Ariel Constenla-Haile's arguments I get the following
impressions:

1. Indisputable, the API is messy. The real, fundamental problem is that
nobody has a long time agenda for dealing with this messiness. The problems
are se

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/23/13 3:57 PM, Jürgen Schmidt wrote:
> On 1/23/13 3:23 PM, Andreas Säger wrote:
>> Am 23.01.2013 10:12, Jürgen Schmidt wrote:
>>>
>>> feel free to join the project and help to improve things like the Python
>>> support, or improving the basic IDE. Remember volunteers are working on
>>> the code base and you can't force them what they should do.
>>>
>>> It's funny that people request and take more than they gave back. Really
>>> if you think certain areas of the program need improvements please join
>>> us and help to improve it.
>>>
>>> Wake up this project is not longer driven by one single company but by
>>> individuals. All project volunteers have to take action if they want to
>>> help to make the project better and successful. Don't wait that other do
>>> it for you.
>>>
>>>
>>
>> Obviously, you do not know who Bernard Marcelly is. He contributed to
>> the project for a whole decade.
>> Without his outstanding contributions nobody could make any sense of
>> this ugly API beast.
>>
> 
> I know who he is and my comment was not related to Bertrand in person. I
> apologize if he feels personal attacked.

sorry I meant Bernard obviously

Juergen

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/23/13 3:23 PM, Andreas Säger wrote:
> Am 23.01.2013 10:12, Jürgen Schmidt wrote:
>>
>> feel free to join the project and help to improve things like the Python
>> support, or improving the basic IDE. Remember volunteers are working on
>> the code base and you can't force them what they should do.
>>
>> It's funny that people request and take more than they gave back. Really
>> if you think certain areas of the program need improvements please join
>> us and help to improve it.
>>
>> Wake up this project is not longer driven by one single company but by
>> individuals. All project volunteers have to take action if they want to
>> help to make the project better and successful. Don't wait that other do
>> it for you.
>>
>>
> 
> Obviously, you do not know who Bernard Marcelly is. He contributed to
> the project for a whole decade.
> Without his outstanding contributions nobody could make any sense of
> this ugly API beast.
> 

I know who he is and my comment was not related to Bertrand in person. I
apologize if he feels personal attacked.

Juergen

Re: Incompatible change for extensions

[Andreas Säger]

Am 23.01.2013 10:12, Jürgen Schmidt wrote:
> 
> feel free to join the project and help to improve things like the Python
> support, or improving the basic IDE. Remember volunteers are working on
> the code base and you can't force them what they should do.
> 
> It's funny that people request and take more than they gave back. Really
> if you think certain areas of the program need improvements please join
> us and help to improve it.
> 
> Wake up this project is not longer driven by one single company but by
> individuals. All project volunteers have to take action if they want to
> help to make the project better and successful. Don't wait that other do
> it for you.
> 
> 

Obviously, you do not know who Bernard Marcelly is. He contributed to
the project for a whole decade.
Without his outstanding contributions nobody could make any sense of
this ugly API beast.

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/23/13 3:08 PM, Bernard Marcelly wrote:
> Message de Jürgen Schmidt  date 2013-01-23 10:12 :
>>
>> exactly and that means a minor code change and a rebuild. If this kind
>> of cleanup changes are not allowed with a major release than we do
>> something wrong. You should not forget the benefit for new developers
>> that we want to reach. A cleaner and better API is much easier to learn
>> for them. Existing developers will have no trouble with adapting the
>> changes but all new ones will benefit.
>>
> If you were reading real user questions in forums you would be appalled
> by the low programming level of those wanting to automate tasks, whether
> in social clubs, small businesses, administrations and even big
> companies. They are often non-programmers, or young trainees, that
> create applications that become indispensable. Don't suppose that they
> have time and knowledge to quickly debug a program that used to work for
> months or years. It will be hard for them to find out which change
> happened in the API and how to modify.

if they are not maintained or if the code is not available anymore it's
more a question of time until they won't work. They probably work more
by luck.

> 
> If you think that these changes will make the API easier, you are wrong.
> OpenOffice API is and will remain huge and complex for the casual
> programmer, because it was created by highly qualified programmers, to
> be understood and used by their peers; contrary to VBA that is customer
> oriented.

yes I believe that these are minor step towards better APIs. If we would
have the power and resources to change many old style services into new
ones with supporting multiple inheritance interfaces many API could be
simplified a lot.
And I think we have to start to do this stuff and major release can be
used for this kind of changes.

> 
>> On 1/23/13 9:36 AM, Bernard Marcelly wrote:
>>> There is not enough good designers; better spend efforts on correcting
>>> reported real bugs, or on useful improvements (e.g. a real integration
>>> of Python into OpenOffice, like Basic; or add the new dialog controls in
>>> the IDE toolbox).
>>
>> feel free to join the project and help to improve things like the Python
>> support, or improving the basic IDE. Remember volunteers are working on
>> the code base and you can't force them what they should do.
>>
>> It's funny that people request and take more than they gave back. Really
>> if you think certain areas of the program need improvements please join
>> us and help to improve it.
>>
> I know my limits. I don't have the knowledge to modify OpenOffice code
> and don't like C++ as a language.
> I can say that I have given back a lot since 2003. Up to now 275 bugs
> reported; thousands of answers in users-fr, prog-fr mailing-lists,
> french and english web forums; corrections/improvements in the Wiki
> Dev'Guide and Basic Programming Guide; a french book of 900 pages
> demystifying OpenOffice programming; several free tools that help API
> users.
> I am not the only one with such background, others have done same in
> other countries/languages. I am just giving my advice: you are on the
> wrong path.

I meant really on the development level not the other areas you have
mentioned. These are of course also very important areas where people
help a lot to grow the eco system.

Don't get me wrong I appreciate this kind of work a lot.

If we don't change things and improve certain areas over time I will
lose my motivation to work on this code.

Juergen

Re: Incompatible change for extensions

[Bernard Marcelly]

Message de Jürgen Schmidt  date 2013-01-23 10:12 :


exactly and that means a minor code change and a rebuild. If this kind
of cleanup changes are not allowed with a major release than we do
something wrong. You should not forget the benefit for new developers
that we want to reach. A cleaner and better API is much easier to learn
for them. Existing developers will have no trouble with adapting the
changes but all new ones will benefit.

If you were reading real user questions in forums you would be appalled by the 
low programming level of those wanting to automate tasks, whether in social 
clubs, small businesses, administrations and even big companies. They are often 
non-programmers, or young trainees, that create applications that become 
indispensable. Don't suppose that they have time and knowledge to quickly debug 
a program that used to work for months or years. It will be hard for them to 
find out which change happened in the API and how to modify.


If you think that these changes will make the API easier, you are wrong. 
OpenOffice API is and will remain huge and complex for the casual programmer, 
because it was created by highly qualified programmers, to be understood and 
used by their peers; contrary to VBA that is customer oriented.



On 1/23/13 9:36 AM, Bernard Marcelly wrote:

There is not enough good designers; better spend efforts on correcting
reported real bugs, or on useful improvements (e.g. a real integration
of Python into OpenOffice, like Basic; or add the new dialog controls in
the IDE toolbox).


feel free to join the project and help to improve things like the Python
support, or improving the basic IDE. Remember volunteers are working on
the code base and you can't force them what they should do.

It's funny that people request and take more than they gave back. Really
if you think certain areas of the program need improvements please join
us and help to improve it.

I know my limits. I don't have the knowledge to modify OpenOffice code and don't 
like C++ as a language.
I can say that I have given back a lot since 2003. Up to now 275 bugs reported; 
thousands of answers in users-fr, prog-fr mailing-lists, french and english web 
forums; corrections/improvements in the Wiki Dev'Guide and Basic Programming 
Guide; a french book of 900 pages demystifying OpenOffice programming; several 
free tools that help API users.
I am not the only one with such background, others have done same in other 
countries/languages. I am just giving my advice: you are on the wrong path.


Regards
  Bernard

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/23/13 9:36 AM, Bernard Marcelly wrote:
> Hi Ariel and all,
> 
> Bug 121582 is very vague and does not detail the proposed changes. It
> looks like an intended obfuscation, so that nobody will react in time.
> The XSimpleFileAccess is indicated as merely an example, but I will
> develop on it.
> 
> If bug 121582 proposes for Apache OpenOffice 4.0 to create a new
> service+interface _and_ suppress the old service+interfaces, then it is
> exactly the same problem and methodology error as bug 121577 : force
> application developers to change working code without benefits. The
> change is only for esthetical reason.
> 
> I remember a saying: "If it ain't broke don't fix it".
> 
> And for the current multiplication of XSimpleFileAccess interfaces :
> this is completely transparent for programmers in OpenOffice Basic,
> Python, and COM-Automation, since they don't have to query interfaces.
> And they represent probably 90 per cent of all application codes.
> 
> If bug 121582 proposes to transfer the functions of XSimpleFileAccess2
> and XSimpleFileAccess3 into XSimpleFileAccess, and then delete
> XSimpleFileAccess2 and XSimpleFileAccess3 : the change will "only"
> affect Java, BeanShell, Javascript, C++ developers. I doubt they will
> appreciate.

exactly and that means a minor code change and a rebuild. If this kind
of cleanup changes are not allowed with a major release than we do
something wrong. You should not forget the benefit for new developers
that we want to reach. A cleaner and better API is much easier to learn
for them. Existing developers will have no trouble with adapting the
changes but all new ones will benefit.

> 
> 
> As says Hans Zybura, in the real world, various versions of OpenOffice
> are used in schools, companies, etc. Forcing different codes between
> versions is in fact a strong incentive to _not_ update existing and
> working versions.

I don't see it so dramatically because I expect regular updates on newer
versions to benefit from general improvements and bugfixes (especially
security fixes).

> 
> There is not enough good designers; better spend efforts on correcting
> reported real bugs, or on useful improvements (e.g. a real integration
> of Python into OpenOffice, like Basic; or add the new dialog controls in
> the IDE toolbox).

feel free to join the project and help to improve things like the Python
support, or improving the basic IDE. Remember volunteers are working on
the code base and you can't force them what they should do.

It's funny that people request and take more than they gave back. Really
if you think certain areas of the program need improvements please join
us and help to improve it.

Wake up this project is not longer driven by one single company but by
individuals. All project volunteers have to take action if they want to
help to make the project better and successful. Don't wait that other do
it for you.


Juergen


> 
> Regards
>   Bernard
> 
> 
> Message de Ariel Constenla-Haile  date 2013-01-22 12:51 :
>> Hi *,
>>
>> Replaying in general to the thread, that is based mainly on bug 121577.
>>
>> The discussion about incompatibility, centered on this bug, is
>> meaningless: bug https://issues.apache.org/ooo/show_bug.cgi?id=121582 is
>> the real code-incompatible change, every extension developer will have
>> to check the code and adapt it to API changes introduced by this task.
>>
>> It would be interesting to hear arguments against implementing the
>> changes needed to perform the task for bug 121582.
>>

Re: Incompatible change for extensions

[Bernard Marcelly]

Hi Ariel and all,

Bug 121582 is very vague and does not detail the proposed changes. It looks like 
an intended obfuscation, so that nobody will react in time.

The XSimpleFileAccess is indicated as merely an example, but I will develop on 
it.

If bug 121582 proposes for Apache OpenOffice 4.0 to create a new 
service+interface _and_ suppress the old service+interfaces, then it is exactly 
the same problem and methodology error as bug 121577 : force application 
developers to change working code without benefits. The change is only for 
esthetical reason.


I remember a saying: "If it ain't broke don't fix it".

And for the current multiplication of XSimpleFileAccess interfaces : this is 
completely transparent for programmers in OpenOffice Basic, Python, and 
COM-Automation, since they don't have to query interfaces. And they represent 
probably 90 per cent of all application codes.


If bug 121582 proposes to transfer the functions of XSimpleFileAccess2 and 
XSimpleFileAccess3 into XSimpleFileAccess, and then delete XSimpleFileAccess2 
and XSimpleFileAccess3 : the change will "only" affect Java, BeanShell, 
Javascript, C++ developers. I doubt they will appreciate.



As says Hans Zybura, in the real world, various versions of OpenOffice are used 
in schools, companies, etc. Forcing different codes between versions is in fact 
a strong incentive to _not_ update existing and working versions.


There is not enough good designers; better spend efforts on correcting reported 
real bugs, or on useful improvements (e.g. a real integration of Python into 
OpenOffice, like Basic; or add the new dialog controls in the IDE toolbox).


Regards
  Bernard


Message de Ariel Constenla-Haile  date 2013-01-22 12:51 :

Hi *,

Replaying in general to the thread, that is based mainly on bug 121577.

The discussion about incompatibility, centered on this bug, is
meaningless: bug https://issues.apache.org/ooo/show_bug.cgi?id=121582 is
the real code-incompatible change, every extension developer will have
to check the code and adapt it to API changes introduced by this task.

It would be interesting to hear arguments against implementing the
changes needed to perform the task for bug 121582.

Re: Incompatible change for extensions

[Ariel Constenla-Haile]

Hi *,

Replaying in general to the thread, that is based mainly on bug 121577.

The discussion about incompatibility, centered on this bug, is
meaningless: bug https://issues.apache.org/ooo/show_bug.cgi?id=121582 is
the real code-incompatible change, every extension developer will have
to check the code and adapt it to API changes introduced by this task. 

It would be interesting to hear arguments against implementing the
changes needed to perform the task for bug 121582.


On Thu, Jan 17, 2013 at 12:24:15PM +0100, Bernard Marcelly wrote:
> Of course an extension packager can be modified to the new addon syntax.
> The problem is not here, it is that all existing extensions will not
> work as designed unless they are each modified. 

Well, this is the concept of a mayor version change. Note that the mayor
version change was not decided for these API/extension related changes;
on the contrary, the mayor version change is a chance to perform API
clean-up task that may imply incompatible API changes. Bug 121582 is one
of these tasks, there are several other tasks for cleaning-up the API
but human resources to perform them are small.


> And modified extensions will not be compatible with previous versions
> or with LibreOffice.

Being compatible with LO is not OpenOffice's concern; in fact, they've
introduced new API since early versions[1]; so the fact that extension can
be installed on both programs is just a question of luck.



[1] An example:
http://api.libreoffice.org/docs/common/ref/com/sun/star/table/BorderLine2.html

Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpdfgIcPDtUv.pgp
Description: PGP signature

RE: Incompatible change for extensions

[Hans Zybura]

something that had never caused a problem before but was thought of as bad 
design. Please don't fix things that don't cause any problem at all.

Let me pose another question in all earnest: Will - after applying your small 
change to OO 4.0 - a broken extension even be loaded to the point, where the 
online update mechanism is called? 
 
4. Maintaining extensions over time
Jürgen, you recommend to use a max version dependency in extensions.

a) I would never do that, because it makes customers angry. And one really 
doesn't want to make customers angry. When an extension doesn't work anymore, 
they'll notice and ask for support or whether they need an update. On the other 
hand, when a message box comes up telling them something along the line that 
their version of the extension is outdated because they recently updated 
OpenOffice, they'll complain about unnecessary extra complexity - and rightly 
so! 

b) You wrote: "I [...] would do a micro release if I change nothing else".
How much work does a micro release for OpenOffice mean? Would you want to do a 
micro release just because OpenOffice on Windows, MacOS, or Linux had an 
in-built max version dependency concerning the operating system? I don't think 
so. This is just a bad fantasy!

Please, try to imagine what an otherwise totally unnecessary micro release 
means for us extension developers, for our customers, for support. You seem to 
assume that extensions are rather simple things. This is wrong, in my case it 
would take a lot of work, too, albeit scaled down to a one man enterprise. I 
simply don't have the time to make micro releases just because of max version 
dependencies.


Jürgen, OpenOffice is on a stable pathway again, I really used to admire your 
patience, your objectivity, and your leadership in getting Apache OpenOffice to 
work. But the reputation of Apache OpenOffice is still small and fragile, at 
least in the education systems of the German speaking countries, where I know 
the sentiments very well.

E.g. after the failure of Microsoft Office for Mac 2008, my extension has won 
thousands of users for OpenOffice, in spite of the rather long period of 
uncertainty of the future for OpenOffice some years ago. I fear to lose them 
again - not so much for me, because I have an alternative Microsoft Office 
add-in, but for OpenOffice in general.

An incompatible change for gaining nearly nothing and losing very much is just 
a bad idea!

Kind regards,

Hans Zybura

Hans Zybura Software
Waldquellenweg 52
33649 Bielefeld
Fon: +49-(0)521-9457-290
Fax: +49-(0)521-9457-292


> -Original Message-
> From: Juergen Schmidt [mailto:jogischm...@gmail.com]
> Sent: Friday, January 18, 2013 7:16 AM
> To: api@openoffice.apache.org
> Subject: Re: Incompatible change for extensions
> 
> Am Donnerstag, 17. Januar 2013 um 23:19 schrieb Rob Weir:
> > On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt
>  wrote:
> > > On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> > > > Message de Jürgen Schmidt date 2013-01-17 13:19 :
> > > > >
> > > > > I disagree, the old mechanism is a design bug and should be
> > > > > resolved. It was always planned to fix this a major release. Now
> > > > > with 4.0 we can make such changes and we had long discussions
> > > > > about incompatible changes for major releases. Extensions can be
> > > > > easy updated and by the way it is always a good idea to add a
> > > > > max version dependency and release a new version of your
> > > > > extension if you have ensured that it works with the newest
> > > > > office version. How many unpublished API's are used in extensions
> that can change at any time?
> > > > >
> > > > > We probably don't have enough time to fix many more design bugs
> > > > > in the API for 4.0 but this one is definitely worth the change.
> > > > > We will document it and the fix is easy. But for all new
> > > > > extensions the usage is much more intuitive and less error prone.
> > > > >
> > > >
> > > >
> > > > The current mechanism is not a design bug (because it works),
> > > > rather a clumsy design.
> > > >
> > > > To create a toolbar with the same name in Calc, Draw, Impress, you
> have to:
> > > > - create one WindowState xcu file
> > > > - make 2 copies of this file
> > > > - modify one line in each copy
> > > > - add entries for these files in the manifest.xml Is this really
> > > > complex, error prone ? I don't think so, compared to all other
> > > > features of an extension.
> > > >
> > > >

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/19/13 3:47 AM, Martin Groenescheij wrote:
> On 19/01/2013 9:43 AM, Andrea Pescetti wrote:
>> Juergen Schmidt wrote:
>>> https://issues.apache.org/ooo/show_bug.cgi?id=121577
>>> The change is really easy and no big thing.
>>
>> Do we have a way to automatically produce a 4.0-compatible extension
>> starting from a 3.x extension?

no, we only document the migration path. Well if somebody wants to play
with an xsl transformation it should be possible to unpack an oxt
transform the Addon.xcu in the new format and repackage the oxt.


> Is it possible to have these extensions tested for the next release and
> add a note like:
>  "Tested successful with release x.x"?

yes, anybody can do that


>>
>> I'm quite concerned to leave hundreds of extensions behind and asking
>> their authors to upgrade them. Some of the most popular extensions are
>> not very actively maintained, so we should definitely think about
>> fixing the 10-20 most popular extensions by the time 4.0 is released.

well unmaintained code is always bad and I don't think that we will do
the work for external developers. Either developers take care of their
code or the code is open source and new maintainers can step in.

We have thought about a automatic migration but the effort is too huge.
But hey if somebody will invest his time here we will give support where
possible. But we have noticed that the whole extension manager is very
complex and I tend to say again an example of over engineered code. The
live deployment feature is of course nice but the overhead and
complexity it brings in the whole process is in no relation to the
benefit it provides. A clean restart of the office after the
installation would be for example much easier. And very often you have a
mixed env anyway and it works more by luck than by design ;-)

We should in the future keep things as easy and simply as possible to
fulfill the requirements and keep enough room for improvements. We
shouldn't look for 150% solutions that introduce more overhead than
necessary. We noticed that when the leading devs disappear in certain
areas it becomes not easy too maintain this code in the future.

>>
>> Reading the issue, I assume dictionaries are not affected since they
>> don't attach to toolbars, right?

yes they are not affected

Juergen


>>
>> Regards,
>>   Andrea.
>>
>>
> 

Re: Incompatible change for extensions

[Martin Groenescheij]

On 19/01/2013 9:43 AM, Andrea Pescetti wrote:

Juergen Schmidt wrote:

https://issues.apache.org/ooo/show_bug.cgi?id=121577
The change is really easy and no big thing.


Do we have a way to automatically produce a 4.0-compatible extension 
starting from a 3.x extension?
Is it possible to have these extensions tested for the next release and 
add a note like:

 "Tested successful with release x.x"?


I'm quite concerned to leave hundreds of extensions behind and asking 
their authors to upgrade them. Some of the most popular extensions are 
not very actively maintained, so we should definitely think about 
fixing the 10-20 most popular extensions by the time 4.0 is released.


Reading the issue, I assume dictionaries are not affected since they 
don't attach to toolbars, right?


Regards,
  Andrea.

Re: Incompatible change for extensions

[Andrea Pescetti]

Juergen Schmidt wrote:

https://issues.apache.org/ooo/show_bug.cgi?id=121577
The change is really easy and no big thing.


Do we have a way to automatically produce a 4.0-compatible extension 
starting from a 3.x extension?


I'm quite concerned to leave hundreds of extensions behind and asking 
their authors to upgrade them. Some of the most popular extensions are 
not very actively maintained, so we should definitely think about fixing 
the 10-20 most popular extensions by the time 4.0 is released.


Reading the issue, I assume dictionaries are not affected since they 
don't attach to toolbars, right?


Regards,
  Andrea.

Re: Incompatible change for extensions

[Juergen Schmidt]

Am Freitag, 18. Januar 2013 um 04:26 schrieb Carl Marcum:
> On 01/17/2013 05:19 PM, Rob Weir wrote:
> > On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt  
> > wrote:
> > > On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> > > > Message de Jürgen Schmidt date 2013-01-17 13:19 :
> > > > >  
> > > > > I disagree, the old mechanism is a design bug and should be resolved. 
> > > > > It
> > > > > was always planned to fix this a major release. Now with 4.0 we can 
> > > > > make
> > > > > such changes and we had long discussions about incompatible changes 
> > > > > for
> > > > > major releases. Extensions can be easy updated and by the way it is
> > > > > always a good idea to add a max version dependency and release a new
> > > > > version of your extension if you have ensured that it works with the
> > > > > newest office version. How many unpublished API's are used in 
> > > > > extensions
> > > > > that can change at any time?
> > > > >  
> > > > > We probably don't have enough time to fix many more design bugs in the
> > > > > API for 4.0 but this one is definitely worth the change. We will
> > > > > document it and the fix is easy. But for all new extensions the usage 
> > > > > is
> > > > > much more intuitive and less error prone.
> > > > >  
> > > >  
> > > >  
> > > > The current mechanism is not a design bug (because it works), rather a
> > > > clumsy design.
> > > >  
> > > > To create a toolbar with the same name in Calc, Draw, Impress, you have 
> > > > to:
> > > > - create one WindowState xcu file
> > > > - make 2 copies of this file
> > > > - modify one line in each copy
> > > > - add entries for these files in the manifest.xml
> > > > Is this really complex, error prone ? I don't think so, compared to all
> > > > other features of an extension.
> > > >  
> > > > About max version dependency : application developers don't see the
> > > > future. It's not possible to know in advance when (and why) an extension
> > > > will become incompatible.
> > > >  
> > >  
> > >  
> > > exactly and that is the reason why I would today add a max version
> > > dependency always. I know 4.0 will be next, I would change the max
> > > version dependency to 4.0 after testing that everything works and would
> > > do a micro release if I change nothing else.
> > >  
> > > >  
> > > > In the context of a company that has created a specific extension,
> > > > happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
> > > > Releasing a new version will be difficult: the original developer may
> > > > have gone, or have forgotten the building details of an extension; a new
> > > > developer has to learn the syntax of an oxt file, and find out what has
> > > > to be changed to make it work again. Costs, delays. Benefits ? None.
> > > >  
> > >  
> > >  
> > > This would be a situation that is always bad. If you use unmaintained
> > > code you can run always in such trouble. In this specific case the oxt
> > > can be changed easily and the Addon.xcu can be adapted, repackage the
> > > oxt and that's it. No real code changes and you don't have to remove any
> > > XXXWindowState.xcu if you have one.
> > >  
> > > I would love to have much more time to fix API design bugs or change
> > > some bad API's to make the life for developers easier in the future. I
> > > was a big fan of compatible API's but learned over time that good API's
> > > have to evolve over time. We didn't do that and the API is often not
> > > easy to use and to understand in many areas. We can improve a lot here
> > > but probably not compatible. I have a mixed feeling about it but believe
> > > that it will help us to make the product better over time.
> > >  
> > > This is an easy change, other API changes that require real code changes
> > > will be more difficult to communicate.
> > >  
> > > As long as we communicate and document these kind of changes and provide
> > > migration paths we are on a good way I think. We have to look forward.
> > >  
> >  
> >  
> > So speaking of communications... What's the plan?
> >  
> > If we're really going to make incompatible changes, we should probably
> > do more than put it in release notes or Bugzilla. It should probably
> > go into a blog post, with advance notice and a link to technical
> > details.
> >  
> > How many month's notice would be enough? Can some update before a new
> > release? Or would we need to provide a "beta" SDK?
> >  
> > -Rob
> >  
> >  
> > > Juergen
>  
> Will this effect tools like the Netbeans plugin that would need updated  
> or modified to create a new extension compatible with 4.0?
>  
>  

yes the generated Addon.xcu has to be adapted.
>  
> If so where could I find the information needed?
see the issue above or take a look in the examples. It's no big thing

 Juergen
>  
> Thanks,
> Carl
>  
>  

Re: Incompatible change for extensions

[Juergen Schmidt]

Am Donnerstag, 17. Januar 2013 um 23:19 schrieb Rob Weir:
> On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt  
> wrote:
> > On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> > > Message de Jürgen Schmidt date 2013-01-17 13:19 :
> > > >  
> > > > I disagree, the old mechanism is a design bug and should be resolved. It
> > > > was always planned to fix this a major release. Now with 4.0 we can make
> > > > such changes and we had long discussions about incompatible changes for
> > > > major releases. Extensions can be easy updated and by the way it is
> > > > always a good idea to add a max version dependency and release a new
> > > > version of your extension if you have ensured that it works with the
> > > > newest office version. How many unpublished API's are used in extensions
> > > > that can change at any time?
> > > >  
> > > > We probably don't have enough time to fix many more design bugs in the
> > > > API for 4.0 but this one is definitely worth the change. We will
> > > > document it and the fix is easy. But for all new extensions the usage is
> > > > much more intuitive and less error prone.
> > > >  
> > >  
> > >  
> > > The current mechanism is not a design bug (because it works), rather a
> > > clumsy design.
> > >  
> > > To create a toolbar with the same name in Calc, Draw, Impress, you have 
> > > to:
> > > - create one WindowState xcu file
> > > - make 2 copies of this file
> > > - modify one line in each copy
> > > - add entries for these files in the manifest.xml
> > > Is this really complex, error prone ? I don't think so, compared to all
> > > other features of an extension.
> > >  
> > > About max version dependency : application developers don't see the
> > > future. It's not possible to know in advance when (and why) an extension
> > > will become incompatible.
> > >  
> >  
> >  
> > exactly and that is the reason why I would today add a max version
> > dependency always. I know 4.0 will be next, I would change the max
> > version dependency to 4.0 after testing that everything works and would
> > do a micro release if I change nothing else.
> >  
> > >  
> > > In the context of a company that has created a specific extension,
> > > happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
> > > Releasing a new version will be difficult: the original developer may
> > > have gone, or have forgotten the building details of an extension; a new
> > > developer has to learn the syntax of an oxt file, and find out what has
> > > to be changed to make it work again. Costs, delays. Benefits ? None.
> > >  
> >  
> >  
> > This would be a situation that is always bad. If you use unmaintained
> > code you can run always in such trouble. In this specific case the oxt
> > can be changed easily and the Addon.xcu can be adapted, repackage the
> > oxt and that's it. No real code changes and you don't have to remove any
> > XXXWindowState.xcu if you have one.
> >  
> > I would love to have much more time to fix API design bugs or change
> > some bad API's to make the life for developers easier in the future. I
> > was a big fan of compatible API's but learned over time that good API's
> > have to evolve over time. We didn't do that and the API is often not
> > easy to use and to understand in many areas. We can improve a lot here
> > but probably not compatible. I have a mixed feeling about it but believe
> > that it will help us to make the product better over time.
> >  
> > This is an easy change, other API changes that require real code changes
> > will be more difficult to communicate.
> >  
> > As long as we communicate and document these kind of changes and provide
> > migration paths we are on a good way I think. We have to look forward.
> >  
>  
>  
> So speaking of communications... What's the plan?
>  
> If we're really going to make incompatible changes, we should probably
> do more than put it in release notes or Bugzilla. It should probably
> go into a blog post, with advance notice and a link to technical
> details.
>  
>  

we will document it in the wiki with a detailed migration plan. Once we have 
this in place we will reach out to the extension developers. Release notes is 
one obvious thing but  a detailed blog post another one. We can ask Sourceforge 
to spread the new via the extension repo as well.  
>  
> How many month's notice would be enough? Can some update before a new
> release? Or would we need to provide a "beta" SDK?
>  
>  

we can start the communication asap when we have the docu in the wiki in place. 
We don't need necessarily a SDK for this. But the changed samples are part of 
the snapshot SDK.  

The change is really easy and no big thing.

I am planning a blog to talk about extension and the best way to maintain them 
over time.  

Juergen  
  
>  
> -Rob
>  
>  
> > Juergen  

Re: Incompatible change for extensions

[Carl Marcum]

On 01/17/2013 05:19 PM, Rob Weir wrote:

On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt  wrote:

On 1/17/13 3:00 PM, Bernard Marcelly wrote:

Message de Jürgen Schmidt  date 2013-01-17 13:19 :


I disagree, the old mechanism is a design bug and should be resolved. It
was always planned to fix this a major release. Now with 4.0 we can make
such changes and we had long discussions about incompatible changes for
major releases. Extensions can be easy updated and by the way it is
always a good idea to add a max version dependency and release a new
version of your extension if you have ensured that it works with the
newest office version. How many unpublished API's are used in extensions
that can change at any time?

We probably don't have enough time to fix many more design bugs in the
API for 4.0 but this one is definitely worth the change. We will
document it and the fix is easy. But for all new extensions the usage is
much more intuitive and less error prone.



The current mechanism is not a design bug (because it works), rather a
clumsy design.

To create a toolbar with the same name in Calc, Draw, Impress, you have to:
- create one WindowState xcu file
- make 2 copies of this file
- modify one line in each copy
- add entries for these files in the manifest.xml
Is this really complex, error prone ? I don't think so, compared to all
other features of an extension.

About max version dependency : application developers don't see the
future. It's not possible to know in advance when (and why) an extension
will become incompatible.


exactly and that is the reason why I would today add a max version
dependency always. I know 4.0 will be next, I would change the max
version dependency to 4.0 after testing that everything works and would
do a micro release if I change nothing else.



In the context of a company that has created a specific extension,
happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
Releasing a new version will be difficult: the original developer may
have gone, or have forgotten the building details of an extension; a new
developer has to learn the syntax of an oxt file, and find out what has
to be changed to make it work again. Costs, delays. Benefits ? None.


This would be a situation that is always bad. If you use unmaintained
code you can run always in such trouble. In this specific case the oxt
can be changed easily and the Addon.xcu can be adapted, repackage the
oxt and that's it. No real code changes and you don't have to remove any
XXXWindowState.xcu if you have one.

I would love to have much more time to fix API design bugs or change
some bad API's to make the life for developers easier in the future. I
was a big fan of compatible API's but learned over time that good API's
have to evolve over time. We didn't do that and the API is often not
easy to use and to understand in many areas. We can improve a lot here
but probably not compatible. I have a mixed feeling about it but believe
that it will help us to make the product better over time.

This is an easy change, other API changes that require real code changes
will be more difficult to communicate.

As long as we communicate and document these kind of changes and provide
migration paths we are on a good way I think. We have to look forward.



So speaking of communications...  What's the plan?

If we're really going to make incompatible changes, we should probably
do more than put it in release notes or Bugzilla.  It should probably
go into a blog post, with advance notice and a link to technical
details.

How many month's notice would be enough?  Can some update before a new
release?  Or would we need to provide a "beta" SDK?

-Rob



Juergen












Will this effect tools like the Netbeans plugin that would need updated 
or modified to create a new extension compatible with 4.0?


If so where could I find the information needed?

Thanks,
Carl

Re: Incompatible change for extensions

[Rob Weir]

On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt  wrote:
> On 1/17/13 3:00 PM, Bernard Marcelly wrote:
>> Message de Jürgen Schmidt  date 2013-01-17 13:19 :
>>>
>>> I disagree, the old mechanism is a design bug and should be resolved. It
>>> was always planned to fix this a major release. Now with 4.0 we can make
>>> such changes and we had long discussions about incompatible changes for
>>> major releases. Extensions can be easy updated and by the way it is
>>> always a good idea to add a max version dependency and release a new
>>> version of your extension if you have ensured that it works with the
>>> newest office version. How many unpublished API's are used in extensions
>>> that can change at any time?
>>>
>>> We probably don't have enough time to fix many more design bugs in the
>>> API for 4.0 but this one is definitely worth the change. We will
>>> document it and the fix is easy. But for all new extensions the usage is
>>> much more intuitive and less error prone.
>>>
>>
>> The current mechanism is not a design bug (because it works), rather a
>> clumsy design.
>>
>> To create a toolbar with the same name in Calc, Draw, Impress, you have to:
>> - create one WindowState xcu file
>> - make 2 copies of this file
>> - modify one line in each copy
>> - add entries for these files in the manifest.xml
>> Is this really complex, error prone ? I don't think so, compared to all
>> other features of an extension.
>>
>> About max version dependency : application developers don't see the
>> future. It's not possible to know in advance when (and why) an extension
>> will become incompatible.
>
> exactly and that is the reason why I would today add a max version
> dependency always. I know 4.0 will be next, I would change the max
> version dependency to 4.0 after testing that everything works and would
> do a micro release if I change nothing else.
>
>>
>> In the context of a company that has created a specific extension,
>> happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
>> Releasing a new version will be difficult: the original developer may
>> have gone, or have forgotten the building details of an extension; a new
>> developer has to learn the syntax of an oxt file, and find out what has
>> to be changed to make it work again. Costs, delays. Benefits ? None.
>
> This would be a situation that is always bad. If you use unmaintained
> code you can run always in such trouble. In this specific case the oxt
> can be changed easily and the Addon.xcu can be adapted, repackage the
> oxt and that's it. No real code changes and you don't have to remove any
> XXXWindowState.xcu if you have one.
>
> I would love to have much more time to fix API design bugs or change
> some bad API's to make the life for developers easier in the future. I
> was a big fan of compatible API's but learned over time that good API's
> have to evolve over time. We didn't do that and the API is often not
> easy to use and to understand in many areas. We can improve a lot here
> but probably not compatible. I have a mixed feeling about it but believe
> that it will help us to make the product better over time.
>
> This is an easy change, other API changes that require real code changes
> will be more difficult to communicate.
>
> As long as we communicate and document these kind of changes and provide
> migration paths we are on a good way I think. We have to look forward.
>

So speaking of communications...  What's the plan?

If we're really going to make incompatible changes, we should probably
do more than put it in release notes or Bugzilla.  It should probably
go into a blog post, with advance notice and a link to technical
details.

How many month's notice would be enough?  Can some update before a new
release?  Or would we need to provide a "beta" SDK?

-Rob


> Juergen
>
>
>
>
>
>
>
>

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> Message de Jürgen Schmidt  date 2013-01-17 13:19 :
>>
>> I disagree, the old mechanism is a design bug and should be resolved. It
>> was always planned to fix this a major release. Now with 4.0 we can make
>> such changes and we had long discussions about incompatible changes for
>> major releases. Extensions can be easy updated and by the way it is
>> always a good idea to add a max version dependency and release a new
>> version of your extension if you have ensured that it works with the
>> newest office version. How many unpublished API's are used in extensions
>> that can change at any time?
>>
>> We probably don't have enough time to fix many more design bugs in the
>> API for 4.0 but this one is definitely worth the change. We will
>> document it and the fix is easy. But for all new extensions the usage is
>> much more intuitive and less error prone.
>>
> 
> The current mechanism is not a design bug (because it works), rather a
> clumsy design.
> 
> To create a toolbar with the same name in Calc, Draw, Impress, you have to:
> - create one WindowState xcu file
> - make 2 copies of this file
> - modify one line in each copy
> - add entries for these files in the manifest.xml
> Is this really complex, error prone ? I don't think so, compared to all
> other features of an extension.
> 
> About max version dependency : application developers don't see the
> future. It's not possible to know in advance when (and why) an extension
> will become incompatible.

exactly and that is the reason why I would today add a max version
dependency always. I know 4.0 will be next, I would change the max
version dependency to 4.0 after testing that everything works and would
do a micro release if I change nothing else.

> 
> In the context of a company that has created a specific extension,
> happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
> Releasing a new version will be difficult: the original developer may
> have gone, or have forgotten the building details of an extension; a new
> developer has to learn the syntax of an oxt file, and find out what has
> to be changed to make it work again. Costs, delays. Benefits ? None.

This would be a situation that is always bad. If you use unmaintained
code you can run always in such trouble. In this specific case the oxt
can be changed easily and the Addon.xcu can be adapted, repackage the
oxt and that's it. No real code changes and you don't have to remove any
XXXWindowState.xcu if you have one.

I would love to have much more time to fix API design bugs or change
some bad API's to make the life for developers easier in the future. I
was a big fan of compatible API's but learned over time that good API's
have to evolve over time. We didn't do that and the API is often not
easy to use and to understand in many areas. We can improve a lot here
but probably not compatible. I have a mixed feeling about it but believe
that it will help us to make the product better over time.

This is an easy change, other API changes that require real code changes
will be more difficult to communicate.

As long as we communicate and document these kind of changes and provide
migration paths we are on a good way I think. We have to look forward.

Juergen

Re: Incompatible change for extensions

[Bernard Marcelly]

Message de Jürgen Schmidt  date 2013-01-17 13:19 :


I disagree, the old mechanism is a design bug and should be resolved. It
was always planned to fix this a major release. Now with 4.0 we can make
such changes and we had long discussions about incompatible changes for
major releases. Extensions can be easy updated and by the way it is
always a good idea to add a max version dependency and release a new
version of your extension if you have ensured that it works with the
newest office version. How many unpublished API's are used in extensions
that can change at any time?

We probably don't have enough time to fix many more design bugs in the
API for 4.0 but this one is definitely worth the change. We will
document it and the fix is easy. But for all new extensions the usage is
much more intuitive and less error prone.



The current mechanism is not a design bug (because it works), rather a clumsy 
design.


To create a toolbar with the same name in Calc, Draw, Impress, you have to:
- create one WindowState xcu file
- make 2 copies of this file
- modify one line in each copy
- add entries for these files in the manifest.xml
Is this really complex, error prone ? I don't think so, compared to all other 
features of an extension.


About max version dependency : application developers don't see the future. It's 
not possible to know in advance when (and why) an extension will become 
incompatible.


In the context of a company that has created a specific extension, happily used 
for years, Apache OpenOffice 4.0 will be a bad surprise.
Releasing a new version will be difficult: the original developer may have gone, 
or have forgotten the building details of an extension; a new developer has to 
learn the syntax of an oxt file, and find out what has to be changed to make it 
work again. Costs, delays. Benefits ? None.


Regards
  Bernard

Re: Incompatible change for extensions

[Jürgen Schmidt]

On 1/17/13 12:24 PM, Bernard Marcelly wrote:
> Hello,
> 
> I read report 121577 and did not notice the problem.
> 
> 
> Then I found this in the dev mailing list :
> 
> "I noticed that add-on extensions with toolbars have a problem on trunk.
> The ext can be installed but the toolbar is not visible and also not in
> the View -> Toolbars menu. Top-level menus coming with the same ext are
> visible. I am currently don't know if it is related to the bigger
> changes with the name or something else in the context of add-on, means
> the framework part."
> 
> As you can read in answers to this thread, it means that the next
> version of Apache OpenOffice will be _incompatible_ with _all_
> extensions created before.
> 
> Such a case should only happen for a compelling reason.
> I think this is not the case. Bug 121577 is introduced only for a futile
> purpose:
> "the extension developer has to create a configuration file
> WindowState.xcu for every office module where the toolbar is to
> be displayed, even if the toolbar name will be exactly the same in every
> module."
>

I disagree, the old mechanism is a design bug and should be resolved. It
was always planned to fix this a major release. Now with 4.0 we can make
such changes and we had long discussions about incompatible changes for
major releases. Extensions can be easy updated and by the way it is
always a good idea to add a max version dependency and release a new
version of your extension if you have ensured that it works with the
newest office version. How many unpublished API's are used in extensions
that can change at any time?

We probably don't have enough time to fix many more design bugs in the
API for 4.0 but this one is definitely worth the change. We will
document it and the fix is easy. But for all new extensions the usage is
much more intuitive and less error prone.


> This is futile because it is not a big simplification of the creation of
> the various xml files of an extension. In fact the only "human" way of
> creating the numerous files of an extension is to use a tool. Then the
> invoked complexity or tediousness (almost) disappears. See :
> 
> 
> Of course an extension packager can be modified to the new addon syntax.
> The problem is not here, it is that all existing extensions will not
> work as designed unless they are each modified. And modified extensions
> will not be compatible with previous versions or with LibreOffice.

as far as I know is LibreOffice changing a lot of API's as well and do a
lot of cleanup, remove deprecated etc. It is probably a good idea to
test extensions against both in the future. The differences will
probably become bigger if we won't find a way to work together.

Juergen