Toggle on/off for visibility, locked state, and sensitivity,
the latter behind ExperimentalMode as it works only to suppress
the toolbar but not to make it always visible
Change-Id: Ia65a27045472d42fc013970bf9de64320f2dbcdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195836
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Move the so far framework-internal headers layoutmanager.hxx
and the uielement.hxx one that it includes to the
top-level include/ directory and mark LayoutManager as
FWK_DLLPUBLIC.
This is to prepare for a new version of Heiko's [1]
that doesn't require UNO API changes, but can use
the LayoutManager class directly.
[1] https://gerrit.libreoffice.org/c/core/+/195836/9
Change-Id: I7439274c29814ef23c6fde11770e1519e54bc0b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197338
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: I867ffc53254057e4bae43690214a2ab7ce0caa8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197493
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
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: Ie54aef229609f131d3d53874c9390339566880f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196947
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
-Extend ViewDataSupplier to work with window state for supported
applications like sw, sc, sd
-Extend sm DocumentPropertySupplier to work with window state
-Add OldWindowState string member to SfxViewShell inherited
classes for sw, sc and sd
-Add OldWindowState string member to SmDocShell class for sm
Imported window state is stored in the model shells
or the ViewShells if available. This data is accessed by services
like ViewDataSupplier and DocumentPropertySupplier used by
persistentwindowstate.cxx. It is needed to store the window state
data since frame is not available to get to resize
and reposition by the time importing document has finished.
-Add windowstatehelper header and source files in the framework
module for getting/exporting the size and position of
windows. Also add associated file and library to make files for
exporting/using these helper methods across different modules.
-Modify impl_searchRecycleTarget method in loadenv.cxx
New frames are created for saved documents when launched from
the start center. This is to apply their own window state
separately from the backing window.
New docs and templates still recycle the backing window frame.
-Make the backing window close afterwards after the new frame has
been created and the document gets loaded successfully
(modified in loadenv.cxx)
Change-Id: Ia5ad606e744621f267dae6cd468b0c430b2ebf1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185189
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Some of the exclusions were too aggressive. Restrict them to only the
important classes, which exposes some more places this plugin applies.
Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This script was broken, not only in the implementation
(it gives too many false positives in a suspiciously short, <1s time)
but in its approach as well: only considering stuff that is compiled
under Linux inherently leaves out other platform specific or experimental
stuff.
Rewrite it using another approach: grep for mentions of each
header in the modules or global ones in include/ everywhere.
Runtime of this script is about 15 minutes, seems to give only
a few relevant hits.
Change-Id: Ifb92f41f11ca9a2bf14eec617a469003becb78fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161234
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
...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>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ifcf713b0543e78a124f613bcbda496069a280dab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
An unified code, covering both vcl and weld cases. For
SidebarToolBox, the controller is created before items
are inserted, so we listen for item insert event to set
initially correct state.
Change-Id: I3841f21883104b4d3f8541c97ec7fa5fc0bec575
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139022
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
- Reset the icon each time, as there seems to be no easy
way to retrieve the existing icon from a gtk widget in
order to mirror it, like we used to do for vcl. Similar
approach is currently taken in
ToolboxButtonColorUpdaterBase::Update.
- Store the flipping state also in GtkInstanceToolbar,
similar to vcl's ToolBox. This seems to be the easiest
way to make flipping not break on icon theme change,
covering all 4 cases (ToolBarManager, SidebarToolBox,
ToolbarUnoDispatcher, GenericToolbarController), w/o
too involved changes in each. This might benefit from
some refactoring later on, but should be good enough
for now.
- One unsolved problem is the appearance of flipped
icons with svg themes, as the regular variant is handed
to gtk directly, whereas the flipped one is loaded by us,
resulting with a different (blurry) look.
Change-Id: I48c16827b46fb75fd798a041851af6e2648ae8fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139021
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
sfx2::sidebar::ControllerFactory::CreateToolBoxController
only supports creating controllers using the uno factory,
or GenericToolbarController as a fallback. Given that we
already handle the uno factory case in
ToolBarManager::CreateControllers, all this complexity is
really just for creating GenericToolbarController with a
different ctor, which we can do locally as well.
Change-Id: I3a5a3cda95a6c5db97615286e93630214f76cbfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137149
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
As reported by Julien, once the mediawiki extension is installed, the
xHandler in framework::DispatchProvider::implts_searchProtocolHandler()
points to an UNO component implemented in Java, and we crash in
dynamic_cast<>(), at least on Linux with gcc 7.5 and libstdc++.
This dynamic_cast<>() call was added in commit
c0fa456436 (tdf#149261 sdext: fix crash on
starting the presenter console for the 2nd time, 2022-05-26), to allow
the presenter console to opt out from protocol handler caching. It was
expected that the proxy object created for a Java UNO component would
simply return nullptr when we try to dynamic_cast<>() it down to a C++
interface.
Fix the problem by moving the interface to an UNO one: this side-steps
the dynamic_cast<>() crash at the price of introducing an UNO interface,
which is not meant to be part of the public UNO API (but at least it's
not published).
It may still make sense to improve the bridges/ code at some stage to
not crash in dynamic_cast<>() on generated Java proxy objects.
Change-Id: Iaac44515339e0dc15dddc3be45ef7dee7331e47a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135114
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This started with commit 3f768cddd2
(framework: avoid re-creating protocol handler instances all the time,
2022-05-02). In case there are 2 monitors, then one monitor shows the
slideshow, the other shows the presenter console. The presenter
console's protocol handler in
sdext::presenter::PresenterProtocolHandler::Dispatch::Dispatch() has
mpPresenterController->GetWindowManager() as an empty reference on the
2nd time the presentation starts.
The above commit started to cache protocol handler instances at a frame
level for performance reasons, and this is meant to be safe in general,
but the presenter console's window manager is re-created between
slideshow runs, so it depends on framework/ code to re-create the
protocol handler all the time, which is problematic here.
Fix the problem by introducing a framework::CacheInfo interface that
allows protocol handler implementations to signal if they want to avoid
being cached.
This should be good enough for now, but if later it turns out that there
are too many broken protocol handlers out there, then we can consider
flipping the default and only cache handlers which explicitly opt in for
this behavior. This is not done in this commit.
Change-Id: Ic159813b1b339540bc8c4e780c4d6d7d2d4d2445
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135020
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
and using GetXGraphic will return a vcl unographic::XGraphic which
also supports XBitmap as well as XGraphic so we can check if
the XBitmap we're passing around supports XGraphic and use that
if it does and drop the imagewrapper in favor of doing that
Change-Id: I3bd7963b53c3f715fca4b5cfb2ddad650ca92e1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126691
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Every callsite (bar one) calls setOwner and connectWithUntitledNumbers after construction,
so just pass them in the constructor.
And for that lone callsite we can just nullptr as an argument.
Change-Id: If838e068bb59a407225d853a0f67983be400f2f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124426
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
we spend a lot of time in ScAttrArray::GetLastVisibleAttr
which appears to be very expensive for this worksheet.
This is re-computed every time we enter SfxBaseModel::getArgs
Reduce the recomputation by introducing a new method which
only retrieves specific SfxBaseModel arguments.
This takes the load time from 5m9 to 1m9 for me.
Change-Id: I605fae0faa94760c7d6993877c9559ea5dc813cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114905
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
- used for SubToolBarController eg. framework shape toolbar popup
present in the sidebar fontwork panel
- add separate implementation for vcl and weld based ToolBarManager
- provide basic functionality for weld based (just inserting standard items with icons
and controllers)
- not implemented: addons items merging etc.
Change-Id: I8e460f34abd512d70e95a1d484d728b7d809ce9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113387
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Heiko Tietze