as part of the process of merging the Outliner code into the normal EditEngine paths.
So instead of keeping a bunch of information "on the side" and then having to merge information
from multiple sources, it all lives where it logically belongs.
Also take the chance to rename the depth/getdepth/setdepth
fields and methods to NumberingDepth, which makes the purpose
more obvious.
Change-Id: I314673ee1b9efa14f178ac34a122995a554cd788
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10551
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 284bbe0af12b96844976f30bb35ade3a327ea76d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210503
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
It now uses LocaleDataWrapper::getNum to format the number of seconds so
that the right decimal separator can be used.
Change-Id: Ic433e6b9f91619bf32526befce00006a6021f79e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206349
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
These strings are being used to build up a declaration for either a
Basic subroutine or a method from an IDL file. In the English original
they are the actual keywords used by the code. If they get translated it
is confusing because it looks like a new programming language. For
example in French the acess2base.Module.ProcOfLine function looks like
this in the description pane:
ProcOfLine(Facultatif pvLine Comme Variant,
Facultatif pvProcType Comme Variant) Comme String
The “Facultatif” and “Comme” are translations of the “Optional” and “As”
keywords.
This patch just replaces them with string literals.
Change-Id: Icb427ebaa587f99ee2ce81a2e6997787a535001e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206335
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This patch brings the Object Browser's information panels to life,
activating the main details pane and the bottom status bar.
When a user selects an item, the details pane now displays a rich,
formatted view of its properties, such as its full signature or a summary
of its contents. The status bar provides helpful context, like member
counts, and displays the total time taken for the initial data load.
(GSoC 2025 - Object Browser: Rich Information Display)
Change-Id: Iadbc2f3dfeb8eba357558d8a98e7ef663a3e2683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192079
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This patch brings the Object Browser's right-hand members pane to life.
The right pane now supports on-demand expansion for nested UNO types.
Double-clicking items now performs a context-aware action: opening
the relevant Doxygen API page for UNO types or navigating to the
source code for BASIC macros.
(GSoC 2025 - Object Browser: Right-Pane UI Enhancement)
Change-Id: Ibcc2a0479746f3724372c9bd89853626506d42f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192050
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This patch brings the Object Browser's scope mechanism to life. It
connects the UI's "Scope" dropdown to the data provider, allowing the
view to be filtered between "All Libraries" and "Current Document".
The browser now also automatically updates its view to reflect the
currently active document when in "Current Document" mode.
(GSoC 2025 - Object Browser: Scope Activation and Dynamic UI)
Change-Id: Icd3679330c9b05eaa0cb351d81fd4d2415f91d71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191886
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This patch integrates the user interface for the new Object Browser.
It introduces the UI definition file and the C++ logic to create,
display, and manage the window's lifecycle within the IDE.
(GSoC 2025 - Object Browser: UI Shell Integration)
Change-Id: I9a2d7c319a7590e44eafe3d575eb3b0aeffb7e86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191206
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This is a similar change to previous commit
Change-Id: I86754be7c0ce068ceb6216fd0463657b05f4ca41
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Aug 7 16:15:12 2025 +0200
tdf#130857 svx: Don't use GtkBox as GtkFrame label child
, but for a different dialog.
See the commit message of the above-mentioned commit for more
background.
The dialog adjusted in this commit can be triggered from Writer
using "Tools" -> "Macros" -> "Organize Macros" -> "Basic".
Change-Id: Ibe1f3ea10d27c6032906ca716859f1d961239304
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189113
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(make from 5 existing only one)
Much of what makes up this patch is adapted from existing code that is
used to organize and select macros and to assign macros to shortcut
keys. Comments in the patch say where code is borrowed from.
Known issues:
+ Scripting framework library rename for BeanShell, Java, and JavaScript
always returns fail when there are no macro entries in the library even
though it actually succeeds. The same thing happens using
SvxScriptOrgDialog::renameEntry.
+ Deleting Basic macros from the Macro Manager dialog is not implemented
yet.
Change-Id: If4da04549f8b39675910cbbd1f94dd9a6b73c31a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176254
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
There is no general solution to this that I am aware of, so just
implement a rather specific solution that will need periodic extending
to check for other dangerous properties
Change-Id: Ie09d89416fea5b7cdf782319ed9921657faa5a5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176593
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This patch implements a color scheme selector for the Basic IDE. With this new feature the user can either:
1) Choose to stick with "Application Colors", meaning that the colors defined in "Tools - Options - Application Colors" are applied.
2) Use one of the available color schemes in the dialog
To access the color scheme dialog, go to View - Color Scheme.
A color schema was defined in the "BasicIDE.xcs" file and six color schemes were defined in "BasicIDE.xcu" to be shipped with LibreOffice.
This way, it is possible to install more color schemes via extensions;
Change-Id: I5d382d19f982d02ba3c0fda5d1596aed2c38f13c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155928
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
(*) Make all of it use a "Scoped" paradigm
(*) pass by value, no need to allocate on heap
(*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods.
(*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places.
Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr
paths into a new TranslateId::getId. And demonstrate constexpr'ability by
making the aCategories var in OApplicationIconControl::Fill
(dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more
such cases that could now be made constexpr.)
Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Don't allow access to member variables of ComplexColor and makes
them private. Needs a lot of changes.
Change "scheme" to "theme" to be more consistent. In LO we usually
call the "theme color" what is usually refered to as "scheme color"
in OOXML, where it is sometimes refered to as "scheme" and other times
as theme color.
Remove ThemeColor class which was replaced with CmplexColor some
time ago.
Remove un-needed includes and un-needed components.
Use isValidThemeColor in many places where we check that the
ComplexColor is of "Theme" type and that ThemeColorType is set to
a valid value.
Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
It has been always typedef'd to basegfx::B2DPoint since:
commit 5e218b5c51
Date: Wed Jan 12 21:19:32 2022 +0000
always use B2DPoint for DevicePoint
Change-Id: I9f5202d5a71c77dd79f1759923917c26bf68a9af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154632
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
Standardize on OUString, which is the main internal string class.
Convert from/to OUString only when communicating with respective
external APIs.
Removes about 200 conversions from the code.
Change-Id: I96ecee7c6fd271bb76639220e96d69d2964bed26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149930
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
As discussed in the ticket the Basic IDE does not make it clear that the currently opened module is read-only, which can cause confusion to the user, since they may be pressing keys and seeing no result.
With this patch the IDE clarifies that the module/dialog is read-only in two ways:
1) In the status bar the string "(Read-only)" is added after the module/dialog name
2) When a module/dialog is opened an infobar is shown warning that it is read-only.
3) In a module, if the user closed the infobar and tries to edit the code, the infobar is shown again.
Change-Id: I15197c4316bb2ed19e54be0c33f4fb61b5bbd862
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145307
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
The emphasis is not quite right. An animation is made up a sequence of
*frames*, not bitmaps. A frame includes such things as position, size,
timeout till the next frame *as well as* a bitmap.
Note: had to regenerate a bunch of precompiled headers
Change-Id: Ib1959452653857555f41e01ac0151d08c41a3b1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/76460
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reorganized and streamlined, use IDiagramHelper as main interface
now also for existing code.
Had to adapt oox::Shape && Diagram handling since there the
import gets handled very different. This ensures that a Diagram
is detected at export and that the same happens for now as before
Had to add a detection that resetting the GrabBag is meant to
disable the Diagam functionality. That is very indirect, but
has to stay for compaibility reasons for now
Change-Id: I620b7d61cd84b5f9dd8ae4dc890ebf70ce779cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130389
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
(*) rename the enum to make it's purpose more obvious
(*) remove the enum header - it belongs to this class, no need to have
it somewhere else
(*) return property name by const&, no need to copy here
(*) use a o3tl::enumarray instead of a std::unordered_map - there are
only 3 entries here, and two of them are ALWAYS used, so just flatten
the data structure.
Change-Id: Ic496bd5220d55be1209a3243c095d461df0a02ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129788
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
plugin code needed some updating because it was interacting badly with
PCH code in pluginhandler::ignoreLocation
Change-Id: I228f94a4e285747bd1d5b8536010f8617118cafa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115212
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin