incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: trunk build breaks in qadevOOo because of missing class TextFitToSizeType
Date Mon, 30 Jul 2012 14:02:32 GMT

Hi,

On 30.07.2012 15:56, Jürgen Schmidt wrote:
 > On 7/30/12 2:36 PM, Ariel Constenla-Haile wrote:
 >> On Mon, Jul 30, 2012 at 10:08:05AM +0200, Jürgen Schmidt wrote:
[..]
 >>
 >> It doesn't matter what the implementation did internally, API users
 >> don't care about implementation details. And it is a mistake to assume
 >> that no API clients are using this API. In fact, it is more justified to
 >> asume it is being used, as it's been documented in the SDK example:
 >> main/odk/examples/DevelopersGuide/Drawing/TextDemo.java
 >>
 >> It also seems logical to assume that people read the documentation and
 >> follow the examples
 >>
 >>> We did such
 >>> changes in the past as well but always very seldom and carefully.
 >>
 >> But this change is *not* carefully done: the change is not tracked in
 >> the IDL documentation; as API user, I would expect a @deprecated tag in
 >> the IDL, not simple removal without further information (besides the
 >> Developer's Guide being updated too
 >> 
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Drawings/General_Drawing_Properties)
 >>
 >>
 >>> It doesn't help to keep wrong IDL types that never have worked and were
 >>> not really used.
 >>
 >> This is a wrong assumption, see the example from the SDK quoted above.
 >> You cannot mesure how many API users are using this API, but assuming
 >> that some people actually read the examples and follow them seems more
 >> reasonable.
 >>
 >
 > I agree and apologize to not go deeper in this special case. Under this
 > circumstance I would suggest that we revert the change and document it
 > in IDL. The enum has no real effect and is obsolete. We can postpone
 > this incompatible change for a 4.0 if we all agree that the change in
 > general make sense.

I also apologize for not checking deeper, I thought it was a simple 
cleanup/fix (see task). I think the simplest is to revert it for now, 
document the missing adaptions (which I have ready now) in the task and 
note in the API doc that all values not NONE do the same, thus not 
really being used.

Is that okay..?

 > Juergen
 >
 >
 >>
 >> Regards
 >>
 >
 >
-- 
ALG



Mime
View raw message