Only useful ones appear to be <tbody> and <thead> which doxygen doesn't
support but we only use those in 3 places so who cares.
Change-Id: I374f7d208873a8436fe76e0f800ce18df5b188b3
<listing> is called @code / @endcode in doxygen.
@example requires a file name in doxygen.
Also adapt various silly examples that use tools String in C++ or manual
syntax highlighting in Java etc.
Change-Id: I23cff1b688001f438526a6a1364cc5f754b504f7
It is amazing what some people believe autodoc supports.
Also, com::sun:⭐:uno::Any does not exist in IDL, that is part of
the C++ language binding.
Change-Id: I1f1f5cf5d27663ace6ff618ecbecb41fd2dfa1fc
What is sad about this is that autodoc doesn't even support <method>.
sed -i "s,<method>\([a-z][^<]\+[^)]\)</method>,\1(),g"
Change-Id: I702ef71423ced1d5195f2e0535e73b1bb4d3f6f2
This one is apparently often abused to link to a constant group, while
it can only link to constants within a group.
sed -i "s,<const>\([^<]\+\)</const>,\1,g"
Change-Id: Ic3d8099751340e4b046298c861bb659beb351eaf
Doxygen would probably recognize these without () too but add them for
consistency.
sed -i "s,<member>\([^<]*::[a-z][^<:]\+[^)]\)</member>,\1(),g"
Change-Id: I2615b99265b75633459e35164e54d9da7fe76b85
Doxygen will only recognize a un-qualified method name as such if it is
followed by "()".
sed -i "s,<member>\([a-z][^<]\+[^)]\)</member>,\1(),g"
Change-Id: I69bc17849e76f3a3d91c6daf0f1be8168a83cfc5
Doxygen does not know type element and will recognize strings that
contain capital letter (all API types do) automatically as type.
This patch removes 15k doxygen warnings.
git ls-files | grep \\.idl | xargs sed -i "s,<type>\([^<]\+\)</type>,\1,"
Change-Id: I45c07cf0b115d5fb5353f4aa9719839615ea1150
This reverts commit 02021163dbbcc8904da0b2138c8b53684dcc8ab4. The filter
appears to be split in two (com.sun.star.comp.oox.ppt.PowerPointImport
implementation oox::ppt::PowerPointImport from include/oox/ppt/pptimport.hxx for
im-/export, for export calling com.sun.star.comp.Impress.oox.PowerPointExport
implementation PowerPointExport from sd/source/filter/eppt/epptooxml.hxx) for no
good reason, so the com.sun.star.oox.PowerPointExport new-style service is
supporting a hack that should rather be cleaned up.
Conflicts:
offapi/UnoApi_offapi.mk
Change-Id: I875192a68a8e3458dbfd74b4981a6a2e86ce44d7
The reason to have both export-only XclExpXmlStream
("com.sun.star.comp.oox.ExcelFilterExport") and im-/export oox::xls::ExcelFilter
("com.sun.star.comp.oox.xls.ExcelFilter"), where the latter uses the former to
implement export, appears to be historic.
Get rid of the former service, but keep it as an independent C++ class for now
(still also deriving from XmlFilterBase)---this can likely be cleaned up by
somebdoy versed in those XmlFilterBase details.
With the last use (in oox::xls::ExcelFilter, to instantiate XclExpXmlStream) of
the recently introduced com.sun.star.oox.ExcelFilterExport new-style service
gone now, remove that service again.
Change-Id: Id3adacd293cbe4390242827615f074d4bbe9d85a
...recently introduced with c75a46fbd0ba4daf857fcd7d70badeed5aae8e28 "fdo#46808,
use DialogProvider service constructor." The general theme of this additional
ctor appears to be more about "Scripting" than "Listener," and the DialogLib
argument is actually expected to be of XNameContainer type.
Change-Id: Iea7d906d9b2ffc3b3ee5b2cbfaf7c58191037c9b
(Preventing documentation of macros via @cond ... @endcond is apparently at
least broken in Doxygen 1.8.3 and working in Doxygen 1.8.4.)
Change-Id: I2ee582119dba2c3d27db5298786d3076921af46d
The services already existed, they just needed IDL files.
API CHANGE:
The return type of XUIConfigurationManager#getShortcutManager()
is now XAcceleratorConfiguration instead of XInterface.
This should not be a problem because XUIConfigurationManager is
unpublished and the client code was relying on the service
returning that type.
Change-Id: I399fe35de3394b02a4166b75eb7ff93b28be8bef
This reverts commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce6708f0e8677dba9cc92e1479a44086 "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d4a6dcac28801cde82a211fb7e30654 again.
I wasn't able to revert without also reverting
be50ad28f5bbdaeff527f646481ce263843c2401 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8fda2a5848e11063028bf44d72f85431
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61b9cabceb9767fad87cd5822b300452
"Fix exception specifications," 2ce6828bbbf6ba181bb2276adeec279e74151ef6 "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce6708f0e8677dba9cc92e1479a44086
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
...in commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654,
"Convert awt::UnoControlDialogModel to new style"
I added an attribute "ResourceResolver" because some of the client
code was setting it using the property interface.
It turns out that this was a bad idea because the "ResourceResolver"
property is doing some very interesting stuff, so revert that part
of the change.
Change-Id: I62b890e60164e005867ced49c3e407a49ed09441
Reviewed-on: https://gerrit.libreoffice.org/4013
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
Changes done on UI code and IDL, not in comments
(cherry picked from commit fa88b1f1e227ad7530f6595d802a6ed1f5d54cb4)
Conflicts:
scp2/source/ooo/module_langpack.ulf
wizards/com/sun/star/wizards/letter/LocaleCodes.java
Change-Id: I9f66f697789965af79c1ea6db08c8e43f099ddf8
This reverts commit d256dbede60533369d1aac64cca34721183f6a8a:
For one, the new css.chart2.XTitle2 looked unfinished, in that it transfered the
direct properties of the old-style css.chart2.Title service into attributes, but
left out all the properties inherited by the old-style service from
css.style.ParagraphProperties, css.drawing.FillProperties,
css.drawing.LineProperties (and that missing FIXME css.layout.LayoutElement,
whatever that is supposed to be). This needs more thought, to either make
available all propertiers as attributes, or none.
For another, this broke JunitTest_chart2_unoapi (sch.ChXChartDocument,
sch.ChartTitle), for hard-to-debug reasons.
Conflicts:
chart2/source/model/main/Title.cxx
chart2/source/model/main/Title.hxx
offapi/com/sun/star/chart2/XTitle2.idl
sc/source/filter/inc/xlchart.hxx
Change-Id: I4747208a13984904d0e409ea49a73b0f667c86c7
Make it more readable by adding a table
(cherry picked from commit e7b7b284aca5f3936ab1a5902652af41ea849093)
Conflicts:
offapi/com/sun/star/ucb/Content.idl
Change-Id: I31d3fc46993cad81d57ba15f77b8fbc797e4c541
