Re: Incompatible change for extensions

2013-07-31 Thread 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 prop Title ... 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 node ... 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
ModuleWindowState.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 ModuleWindowState.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

2013-07-30 Thread 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 
ModuleWindowState.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 ModuleWindowState.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

2013-02-04 Thread 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

2013-01-23 Thread 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

2013-01-23 Thread 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

2013-01-23 Thread 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

2013-01-23 Thread 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

2013-01-22 Thread 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

2013-01-17 Thread Jürgen Schmidt
On 1/17/13 12:24 PM, Bernard Marcelly wrote:
 Hello,
 
 I read report 121577 and did not notice the problem.
 https://issues.apache.org/ooo/show_bug.cgi?id=121577
 
 Then I found this in the dev mailing list :
 http://www.mail-archive.com/dev@openoffice.apache.org/msg02906.html
 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
 ModuleWindowState.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 :
 http://wiki.openoffice.org/wiki/Extensions_Packager
 
 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




Re: Incompatible change for extensions

2013-01-17 Thread 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

2013-01-17 Thread 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