| commit | 3e4b8463f288d87f91cd5bc864d30ae02d4f5579 | [log] |
|---|---|---|
| author | Maxim Monastirsky <momonasmon@gmail.com> | Mon Apr 10 00:38:33 2023 +0300 |
| committer | Maxim Monastirsky <momonasmon@gmail.com> | Tue Apr 18 01:09:21 2023 +0200 |
| tree | 0716bc9ea72532d4fded3920742c6fa1ee5e58f5 | |
| parent | 6feafa2c5a2c593b1852ac44e2ea88eb9375c01d [diff] |
sc drawstyles: Maintain comment formatting with styles Up to now the look of comments was maintained with the comment shape's DF, with the default formatting being reapplied on import (for hidden comments), on changing Tools > Options... > LibreOffice > AC > Notes background, and on changing the default cell style, while keeping the user-applied DF to some extent. However, as we attempt to support drawing styles, this approach is no longer viable, as applying DF on top of styles at random times makes styles useless in the context of comments. (One might argue, that the look of comments should ideally be treated as an app view setting, and not as a formatting of an individual shape. This definitely makes sense, but has compat. implications, as both LO and Excel allow formatting individual comments (e.g. show a comment, right click > Area...). However we will probably do it anyway if we ever implement threaded comments like in recent Excel [1], as the callout shape based approach seems to not scale to it.) One way around it could be to explicitly disable any style interaction with comments. But this will be unfortunate, as styles have a clear advantage of being able to consistently maintain the same formatting for several elements, much more that the fragile approach of mixing the default formatting and user-applied formatting in the same formatting layer. Not to mention the possibility to define several custom styles. In addition there is a request in tdf#55682 to disconnect the formatting of comments from the default cell style, having a dedicated style instead, which I find reasonable. So this commit introduces a comment style, and uses it for new comments instead of DF, making it easy to format all comments at once. And a style based formatting is never overriden with DF, unless explicitly set by the user. Changing Tools > Options... > LibreOffice > AC > Notes background still has an effect in two ways: (1) Sets the default background of the comment style for new documents, and (2) if changed while a document is open, changes also the comment style of the current document. An undo action is also added, in case changing the current document wasn't deliberate. Changing the default cell style no longer has any effect on comment formatting. One unfortunate side effect of this change, is that newly created and permanently visible comments will lose their default look when opened in an older version. But there is not much I can do here, as older versions don't support styles, and I believe the advantage of using styles outweigh this concern. Hidden comments are not affected by this. [1] see https://support.microsoft.com/en-us/office/the-difference-between-threaded-comments-and-notes-75a51eec-4092-42ab-abf8-7669077b7be3 Change-Id: I84215791b9e6ce393c6d979aa2b19ef70c76dff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150352 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
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.
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 and Developers Guide. 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.
These are the current minimal operating system and compiler versions to run and compile LibreOffice, also used by the TDF builds:
Java is required for building many parts of LibreOffice. In TDF Wiki article Development/Java, the exact modules that depend on Java are listed.
The baseline for Java is Java Development Kit (JDK) Version 11 or later. It is possible to build LibreOffice with JDK version 9, but it is no longer supported by the JDK vendors, thus it should be avoided.
If you want to use Clang with the LibreOffice compiler plugins, the minimal version of Clang is 12.0.1. Since Xcode doesn't provide the compiler plugin headers, you have to compile your own Clang to use them on macOS.
You can find the TDF configure switches in the distro-configs/ directory.
To setup your initial build environment on Windows and macOS, we provide the LibreOffice Development Environment (LODE) scripts.
For more information see the build instructions for your platform in the TDF wiki.
Each module should have a README.md 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. |
Use the "..." form if and only if the included file is found next to the including file. Otherwise, use the <...> form. (For further details, see the mail Re: C[++]: Normalizing include syntax ("" vs <>).)
The UNO API include files should consistently use double quotes, for the benefit of external users of this API.
loplugin:includeform (compilerplugins/clang/includeform.cxx) enforces these rules.
Beyond this, you can read the README.md 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.libera.chat - 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.