Rename weld::TreeView member + methods to clarify
that these are about selection changes:
* m_aChangeHdl to m_aSelectionChangedHdl,
* signal_changed to signal_selection_changed
* connect_changed to connect_selection_changed
In GtkInstanceTreeview, also rename the
related methods calling signal_selection_changed
accordingly for consistency.
Change-Id: I299d7930484677395a0bdd0ff105df18688f2e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178023
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>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Use the known string length into account (and I definitely like to
not rely on the undocumented implementation detail that OUString is
null-terminated).
Change-Id: I0e7478d25e802f8f8e31f02cf8d77613c1325bc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172170
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since
commit ea36e0502c
Date: Tue Oct 4 12:42:33 2022 +0100
tdf#150786 use a 'standard' theme for form controls
, form controls in Writer/Calc/Impress documents are
supposed to no longer make use of the system style,
but use style settings independent of the platform
and system style/theme.
Edits in forms actually use the standard font (set
in `ImplStyleData::SetStandardStyles`) by default
since that commit.
However, the font dialog in the control properties
was still showing data for the application default
font that depends on the system style for font
attributes not explicitly set for the control, which
was incorrect and inconsistent with the visual
appearance of the font actually used.
Take `PROPERTY_STANDARD_THEME` introduced in the
above-mentioned commit into account for the dialog
as well when deciding what default font to use.
Add inline comments that the 2 places setting and
making assumptions about the default style of
controls need to be kept in sync.
With this in place, the actually used font height
of 8 (as set in `ImplStyleData::SetStandardStyles`)
is now displayed in the dialog for a newly inserted
edit in Writer instead of something dependent on the
style (e.g. 10 for the kf5 VCL plugin with the Breeze
style in use, or 9 for the qt6 VCL plugin with the Fusion
style).
For the font family, the dialog now shows
"Segoe UI;Tahoma;Arial Unicode MS;Lucida Sans Unicode;DejaVu Sans;Albany AMT;Albany;Arial;Nimbus Sans L;Interface User;Geneva;Dialog;Lucida;Helvetica;Helmet;Interface System;Sans Serif"
(and "This font has not been installed. The closest available
font will be used.") instead of "Noto Sans", which seems a bit
odd, but is presumably "correct" based on the standard style
font. (In order to change that, it would potentially be necessary
to adjust what style settings are set in the
"standard style settings" for controls.)
Change-Id: I1fbee69fdcd6f73a126df64294eb1bcc44078642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171426
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4ccc647bb794515c8c11f8dfd9a26563f4aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166819
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...(that was defined iff OSL_DEBUG_LEVEL >= 2) and replace its uses with
OSL_DEBUG_LEVEL directly
Change-Id: I807c15a02cc8ced9852287df0afb4808761d19d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/sw/source/ui/dbui/addresslistdialog.cxx(426): warning C4312: 'reinterpret_cast': conversion from 'int' to 'void *' of greater size
Change-Id: Idbfbe8add89c8e219bdabcf28b741e2e31a5e345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163781
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/oox/source/export/shapes.cxx(2411): warning C4459: declaration of 'XML_line' hides global declaration
Change-Id: I74738753254ad1c468025d25bfb0bfe21787180f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
With ItemInfoPackages we now can have a buffered, static
global translation table from SlotIDs to WhichIDs since
the ItemInfoStatic used already contains all the needed
information.
Register that in registerItemInfoPackage at the Pool and
use it for lookup. That speeds up the lookup from O(n)
to O(1). Since that lookup is used in UI and UNO API
implementations this has positive effect on load/safe,
but also all interactive stuff in the whole office.
NOTE: I tried to use a merged version of that translation
table in the parent pool, but this shows double SlotIDs,
what is no wonder since that's what those are used for:
To get different WhichIDs for a SlotID in Item handling.
This *might* prevent getting rid of the chanined Pools
at all - sadly. The returned WhichID directly depends
on which Pool the function(s) GetWhichIDFromSlotID and
GetTrueWhichIDFromSlotID are called.
NOTE: Very strange is that the parameter 'bDeep' in that
functions is *not* passed down to the call to the
secondary Pool - probably an error, but risky to fix,
that may change already the behaviour :-(
Change-Id: Iea77ffad0f6a5401ab74fea0bbfc2589c66680ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163597
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Secured usage of FontList in SvxFontListItem
usage (a test)
Change-Id: I412a7681b3ece4e5d3751165d4b566ccdf5b2da9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163257
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Driving forward the Item reworks I now take the
ItemPool in focus: It now does not hold any items
anymore and should be renamed to something like
ItemInfoProvider/ItemHelper, since it's main purpose
is to provide the Defaults for the Item functionality.
There is that SfxItemInfo, only a struct and bundling
SlotID and ItemFlags. There are also the DefaultItems,
just handled as ptrs in an array. It is/was always
error-prone to keep these in sync. Remember that it's
also necessary for the order to not only being sorted
but being increments of one with no gaps allowed in
the WhichIDs to which the Items are bound.
I now bundled that to a new class ItemInfo that joins
WhichID, SlotID, ItemFlags and the default Item. This
is a pure virtual base class, it comes in three
derivations:
(1) ItemInfoStatic:
This is supposed to be global static and hosts the
Item in a std::unique_ptr to ensure cleanup. It is
designed to be constructed once during runtime and
being shared globally. It allows the ItemPtr to be
nullptr to mark as non-static (if initial static is
not possible for some reason) but still offers the
needed data. Most cases (95%+) are of that case.
The contained Item is owned by that instance. The
flag isStaticDefault() is set at the Item.
(2) ItemInfoDynamic:
This is supposed to be used for cases where the Item
cannot be static: Mainly for SfxSetItem (that needs
a Pool itself in the contained SfxItemSet, so lifetime
is bound to that Pool), but other cases showed up in
the transition. These instances live while the Pool
lives and get destructed when the Pool goes down.
Also uses std::unique_ptr for the Item instance for
as much automated cleanup as possible, the contained
Item is owned by that instance, the instance by the
Pool. The flag isDynamicDefault() is set at the Item.
(3) ItemInfoUser:
This is used for UserDefaults that can be set for
every ItemInfo entry to 'overshadow' the default
from the 'outside'. It uses a regular Item and
the central access methods implCreateItemEntry/
implCleanupItemEntry to manage the Item instance,
thus works like a SfxPoolItemHolder. The Item
instance can be globally shared and re-used even
when the Pool goes down. Instances belong to the
Pool and are cleaned up when the Pool goes down.
This Item does not need any further flag to be
set.
The ItemInfos are organized using a class
called ItemInfoPackage:
This bundles groups of ItemInfoStatic to
functional instances. There are derivations/
implementations of this e.g. for Writer ItemPool
bundling all the needed defaults for Writer,
similar for draw/impress, Calc and other usages.
These ItemInfoPackage can be 'registered' at an
ItemPool using it's method registerItemInfoPackage.
This does all the needed stuff to setup that
group of ItemInfos at the Pool (It even sets
internal vars First/LastWhich, that info can just
be derived from the buildup ItemInfo Ptrs).
The ItemInfoPackage has methods 'size()' and
'getItemInfo(index) to allow looping over it
and deliver the infos the Pool needs. The
(forced, pure virtual) overloads of getItemInfo
in the specific implementations check for the
ItemPtr being nullptr and create a exclusive
incarnation of ItemInfoDynamic for the Pool if
needed, returning that. The Pool owns the
ItemInfoDynamic incarnations and uses the
ItemInfoStatic directly. On shutdown it cleans
up the ItemInfoDynamic as needed.
The ItemInfoUser is used by the Pool when a
UserDefault is set/used: for SetUserDefaultItem,
GetUserDefaultItem, ResetUserDefaultItem. It
is not held in a 2nd list, but directly in the
list of ItemInfo'ptrs: To keep track of this
an unordered_map is used that helds the original
ItemInfo associated with the WhichID. That way
no two lookups (as before) are needed to get the
current Pool's default for any WhichID.
The derivations of ItemInfoPackage are
encapsulated and just allow access to an
ItemInfoPackage& with a single method as
return value. All use a static local instance
of a std::array<ItemInfoStatic, FIXED_SIZE>
which constructs all ItemInfoStatic and the
static Item instances - if already possible.
Sometimes it is necessary to overload the
constructor to set some static instances
for Items later than the lib init. These are
also just marked with nullptr as Item instance.
Some need to overload getItemInfo to complete
instances of ItemInfoStatic, if needed, or
create and deliver instances of ItemInfoDynamic.
The registerItemInfoPackage also offers a
optional lambda callback: there were two cases
where local data from the Pool was needed to
incarnate the item - just add that to the
call to registerItemInfoPackage if needed,
see examples in the adapted code.
For the re-use of Items this means that now
in SfxItemSet/SfxPoolItemHolder *true* static
Items can and will be used without RefCount
directly and globally. This is also the case
for dynamic Items, with the exception of
differing Pools for SfxSetItems which cannot
be done.
Future:
That design is already prepared to allow
solving that Pool-chaining problem: currently
there are master/sub-pools and all accesses
have to traverse that structure before even
doing anything.
For the future the idea is more to 'compose'
a Pool by registering ItemInfoPackages, e.g.
for Writer pool you may start with SfxItemPool,
register the writer-specific ItemInfoPackage,
then the one for DrawingLayer (if needed) and
the one for EditEngine.
It should also be possible to get to smaller
granularities of that packages. Ideas for
new ones will emerge. We might also think
about composing Pools which can e.g. run Writer
and Chart, so allowing to use Chart *without*
OLE stuff in Writer - just ideas...
More changes:
- Adapted all stuff, cleaned up old stuff/
definitions
- Removed FreezeIdRanges, that can be done
once per Pool on-demand (and cannot be
forgotten to be called)
- Merged XOutdevItemPool with SdrItemPool
and offered a ItemInfoPackage which joins
both needed sets of Items
- All the cleanup hassle with Pools and
defaults cleaned up
- Adapted all access methods of the pool
to use that new stuff. Pool chaining
currently stays, but I use a central
method 'getTargetPool' instead of
recursive calling to get the correct
Pool for the action
Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
