13bb5a4b09
This is a follow-up to 45a7f5b62d "Keep WID ranges
sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the
m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the
various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT)
that each individual range has an upper bound not smaller than its lower bound.
Arguably, all SfxItemSet instances should fulfill the stronger guarantees
required and checked by MergeRange.
And in many cases the ranges are statically known, so that the checking can
happen at compile time. Therefore, replace the two SfxItemSet ctors taking
explicit ranges with two other ctors that actually do proper checking. The
(templated) overload taking an svl::Items struct should be used in all cases
where the range values are statically known at compile time, while the overload
taking a std::initializer_list<Pair> is for the remaining cases (that can only
do runtime checking via assert). Most of those latter cases are simple cases
with a single range covering a single item, but a few are more complex.
(At least some of the uses of the existing SfxItemSet overload taking a
const sal_uInt16* pWhichPairTable
can probably also be strengthened, but that is left for another day.)
This commit is the first in a series of two. Apart from the manual changes to
compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and
svl/source/items/itemset.cxx, it only consists of automatic rewriting of the
relevant SfxItemSet ctor calls (plus a few required manual fixes, see next).
But it does not yet check that the individual ranges are properly sorted (see
the TODO in svl::detail::validGap). That check will be enabled, and the ensuing
manual fixes will be made in a follow-up commit, to reduce the likelyhood of
accidents.
There were three cases of necessary manual intervention:
* sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in
braced-init-list syntax now, so needs explicit narrowing conversion to
sal_uInt16.
* In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the
definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually.
* In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx,
sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx,
sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx,
some comments had to be put back (see "TODO: the replaced range can contain
relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx).
A few uses of the variadic form erroneously used nullptr instead of 0 for
termination. But this should have been harmless even if promoted std::nullptr_t
is larger than promoted sal_uInt16, assuming that the part of the nullptr value
that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly,
some uses made the harmless error of using 0L instead of 0.
Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35
Reviewed-on: https://gerrit.libreoffice.org/38861
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
LibreOffice
LibreOffice is an integrated office suite based on copyleft licenses and compatible with most document formats and standards. Libreoffice is backed by The Document Foundation, which represents a large independent community of enterprises, developers and other volunteers moved by the common goal of bringing to the market the best software for personal productivity. LibreOffice is open source, and free to download, use and distribute.
A quick overview of the LibreOffice code structure.
Overview
You can develop for LibreOffice in one of two ways, one recommended and one much less so. First the somewhat less recommended way: it is possible to use the SDK to develop an extension, for which you can read the API docs here and here. This re-uses the (extremely generic) UNO APIs that are also used by macro scripting in StarBasic.
The best way to add a generally useful feature to LibreOffice is to work on the code base however. Overall this way makes it easier to compile and build your code, it avoids any arbitrary limitations of our scripting APIs, and in general is far more simple and intuitive - if you are a reasonably able C++ programmer.
The important bits of code
Each module should have a README file inside it which has some
degree of documentation for that module; patches are most welcome to
improve those. We have those turned into a web page here:
However, there are two hundred modules, many of them of only peripheral interest for a specialist audience. So - where is the good stuff, the code that is most useful. Here is a quick overview of the most important ones:
| Module | Description |
|---|---|
| sal/ | this provides a simple System Abstraction Layer |
| tools/ | this provides basic internal types: 'Rectangle', 'Color' etc. |
| vcl/ | this is the widget toolkit library and one rendering abstraction |
| framework | UNO framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from /uiconfig/ files |
| sfx2/ | legacy core framework used by Writer/Calc/Draw: document model / load/save / signals for actions etc. |
| svx/ | drawing model related helper code, including much of Draw/Impress |
Then applications
| Module | Description |
|---|---|
| desktop/ | this is where the 'main' for the application lives, init / bootstrap. the name dates back to an ancient StarOffice that also drew a desktop |
| sw/ | Writer |
| sc/ | Calc |
| sd/ | Draw / Impress |
There are several other libraries that are helpful from a graphical perspective:
| Module | Description |
|---|---|
| basegfx/ | algorithms and data-types for graphics as used in the canvas |
| canvas/ | new (UNO) canvas rendering model with various backends |
| cppcanvas/ | C++ helper classes for using the UNO canvas |
| drawinglayer/ | View code to render drawable objects and break them down into primitives we can render more easily. |
Finding out more
Beyond this, you can read the README files, send us patches, ask
on the mailing list libreoffice@lists.freedesktop.org (no subscription
required) or poke people on IRC #libreoffice-dev on irc.freenode.net -
we're a friendly and generally helpful mob. We know the code can be
hard to get into at first, and so there are no silly questions.