incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: trunk build breaks in qadevOOo because of missing class TextFitToSizeType
Date Mon, 30 Jul 2012 13:56:19 GMT
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:
>> On 7/28/12 11:57 PM, Ariel Constenla-Haile wrote:
>>> Hi Regina,
>>> On Sat, Jul 28, 2012 at 6:41 AM, Regina Henschel
>>> <> wrote:
>>>> Hi,
>>>> I start to build trunk with MSVC Express on WinXP. The build breaks in
>>>> qadevOOo with error message
>>>> C:\AOO_2012_07_git\trunk\main\qadevOOo\runner\util\
>>>> cannot find symbol
>>>> symbol  : class TextFitToSizeType
>>>> location: package
>>>>     if (oldValue instanceof{
>>>>                                                 ^
>>>> Reason seems to be, that the changes in
>>>>   r1366087: #116001# TextToFitSize item/property optimized to boolean
>>>> are incomplete.
>>> IMHO besides of being incomplete, they are incompatible, and thus the
>>> API changes should be reverted: this kind of incompatible API changes
>>> should happen only on mayor versions, they should wait for AOO 4; in
>>> the meantime, the solution seems to be:
>> in general yes and I would agree but in this case Armin told me that the
>> implementation was always different and the IDL was wrong. 
> 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/
> 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
>> 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.


> Regards

View raw message