Hi, On Fri, Aug 07, 2015 at 04:52:36PM +0800, "Matthew J. Francis" <mjay.fran...@gmail.com> wrote: > How specifically should that be changed, though. In this case, merely > changing the declared type to short would leave it such that its value > is defined by the set of integer values of an enum, which is still > annoying in terms of manipulation using PyUNO and peculiar in terms of > the IDL.
If the documentation says that this is a short, exact possible values are defined here and there, I don't see that worse than the current situation. :-) > An equivalent constant group could be added, although that would be not > ideal in a different way - the original enum definition couldn't be > removed, as it may still be used for instance by existing Python code > to blindly assign values to the property. I think we add equivalent constant groups only in case the enumeration would be extended (but isn't to avoid incompatibility), e.g. text::WritingMode vs text::WritingMode2. > Any advance then on the idea of: > - Making the declared type short I would do this. > - Adding a constant group for it > - Deprecating the enum I would only these if there will be a new item for the enumration in the future. > I note that for this particular case, css::report::XReportControlFormat > declares a ParaAdjust attribute which is actually a short - the > documentation would need changing there to reference the new constant > group, but not the definition. This is a problem for Writer paragraphs' ParaAdjust property, too: text::Paragraph refers to style::ParagraphProperties, which says ParaAdjust is a style::ParagraphAdjust, which is an enum. In reality, sw/source/core/unocore/unomap.cxx says UNO_NAME_PARA_ADJUST is a sal_Int16. In case all other ParaAdjust implementations (I'm sure at least editeng has one) also deal with a sal_Int16 in fact, then just changing '[property] com::sun::star::style::ParagraphAdjust ParaAdjust;' to '[property] short ParaAdjust;' in the IDL file (and using a comment to still refer to the enumeration informally) would make sense, I think. Even if the in-build check complains that this is nominally an incompatible change. Regards, Miklos
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
