Instead of returning a reference to the abstract
XModel3 interface, return the more concrete
SfxBaseModel.
Drop some now unnecessary casting/UNO querying in callers.
More simplification to avoid UNO querying elsewhere
will follow in upcoming commits.
Change-Id: I05ad3a4bccfb080ccbee3af956451def3bcc94fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211053
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use the XModel3 interface instead of only the very
basic XInterface base interface for the document
as the object that is passed is known to implement
this more specific interface.
The DevelopmentToolDockingWindow ctor passes the
result of calling SfxObjectShell::GetBaseModel
(which returns XModel3) for the param.
This also prepares for switching the return type
of SfxObjectShell::GetBaseModel to a reference of
the concrete SfxBaseModel in an upcoming commit (without
introducing ambiguity due to multi-inheritance from
XInterface in places using only an XInterface
reference).
Change-Id: I61f531caea266286fe51b5231c13f56e5b9d82b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211050
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
With the refactoring from previous commits in place, it's
clear that all callers pass a non-null SfxBindings*
param.
Switch the param to a reference, to make that clear
and prepare for further refactoring.
Change-Id: Id9f1487dba4b84860f9afa52ff9ffb4dd7b1d2c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208387
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
With refactoring from previous commits in place, it's
now clear that all callers pass a non-null
SfxChildWinInfo*. Pass by reference instead to make
that clear, which also allows to drop some null
checks.
Change-Id: I39bfe179c68afecf9b7aa209feb69d33e57e5388
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208371
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the parameter from a pointer to a reference.
The only 2 callers in SfxChildWindow::CreateChildWindow
always pass a non-null param.
Using a reference makes clear that the param is always
non-null and makes clear that those implementations previously
unconditionally dereferencing the pointer were unproblematic.
Change-Id: Ia2b893aac6c94c3b0e1024cc5500da2463bf9996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208312
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the parameter from a pointer to a reference.
The only 2 callers in SfxChildWindow::CreateChildWindow
always pass a non-null param.
Using a reference makes clear that the param is always
non-null, allows dropping some null checks and makes
clear that those implementations previously unconditionally
dereferencing the pointer were unproblematic.
Change-Id: I6734dfe6fe4fa1cb6aa80f4e67eb69603e8d86fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208300
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Rename weld::TreeView::connect_column_clicked
and weld::TreeView::signal_column_clicked to make
clear that they are not about a click anywhere in a
column, but about the column *header* being clicked.
The GTK 4 doc for the corresponding
GtkTreeViewColumn::clicked signal [1] by which the API
was apparently inspired is clear about this:
> Emitted when the column’s header has been clicked.
[1] https://docs.gtk.org/gtk4/signal.TreeViewColumn.clicked.html
Change-Id: I0b4b337b5ca938bb1526d9857ed2b0b244daf23c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207591
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
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 anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the param for the signal and handlers used when
the selection in a weld::TreeView changes from weld::TreeView&
to the base class, weld::ItemView&.
This is in preparation of moving the logic to the weld::ItemView
base class in an upcoming commit.
Handler implementations that require a weld::TreeView
instance can use the one that the signal is connected
to, e.g. use the class member directly inside of the
implementation instead of using the param (as is done
in most of the places anyway).
Change-Id: I0bbf8fe1dbd95906a5224155d48d832bcd144532
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203366
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I86edb8abe2178862269f2fc2a1629fb682a6a752
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198790
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop the weld::TreeView-specific logic for signalling
CommandEvent of type ContextMenu and reuse the existing
logic implemented in the weld::Widget base class instead,
which was moved there in previous commit
Change-Id: I9367bdbb8be7994057667fab539aaf135751e063
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Dec 10 23:08:21 2025 +0100
tdf#130857 weld: Move CommandEvent handling to weld::Widget base
Make weld::Widget::connect_command virtual to override
it in GtkInstanceTreeView, as was previously the case
for the now dropped weld::TreeView::connect_popup_menu.
The existing handlers previously connected using
weld::TreeView::connect_popup_menu already check whether the type
of the event is CommandEventId::ContextMenu, so no change in behavior
is expected.
In a quick test, the sample scenario of the template dialog as
described in
commit 5d28767654
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Dec 9 20:13:07 2025 +0100
tdf#130857 qt weld: Forward TreeView context menu event
still worked as expected with gtk3 and gen as well as with
an experimental branch for qt6 where support for using native
Qt widgets for that dialog is declared.
Change-Id: I13baf51eda2c9f0adc9c167ab50e920d23ada07e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195415
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not all objects implement XServiceInfo. Any query must either be
UNO_QUERY_THROW, or check its result after UNO_QUERY.
Change-Id: I8b1d7c719c4a43a4d658957ad5a91181dc265186
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188080
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
...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>
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>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ibc2511c8521923c854e4b450649ea616581af2fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144141
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Use a natural string sort for all strings in the object inspector
tree view. This is more useful for properties as those can have
indices, which are shown as numbers, so having them in natural
order makes the tree view easier to digest.
Change-Id: I7d036cd755f6595fa302c7a28a005684897f2963
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134541
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
since we've got all the information from the beginning.
The static_cast is to fix this error:
/home/julien/lo/libreoffice/sfx2/source/devtools/ObjectInspectorTreeHandler.cxx:976:39: error: type 'float' cannot be narrowed to 'int' in initializer list [-Wc++11-narrowing]
std::vector<int> aMethodsWidths { nMethodsDigitWidth * 30, nMethodsDigitWidth * 15,
^~~~~~~~~~~~~~~~~~~~~~~
/home/julien/lo/libreoffice/sfx2/source/devtools/ObjectInspectorTreeHandler.cxx:976:39: note: insert an explicit cast to silence this issue
std::vector<int> aMethodsWidths { nMethodsDigitWidth * 30, nMethodsDigitWidth * 15,
^~~~~~~~~~~~~~~~~~~~~~~
static_cast<int>( )
Change-Id: I7d59d947bd54bf97dd559b6813cabd3ea4216efe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115582
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
In development tool we need GtkPaned for only properties tab.
Unnecessary hide() show() calls for the other tabs(Interfaces, Services,
Methods) causes complex problems about inital height of the second pane
with gen plugin.
Change-Id: I7523ef0bc425d7fc97ec5bd9e30e874f88e354f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115450
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Michael Weghorn