Age | Commit message (Collapse) | Author |
|
Change-Id: I028d108b3a83bd5541d873c4d03b87339cd3be52
|
|
Changes done to the code in framework, comphelper and unotools,
in no particular order
- add an interaction handler dedicated to WebDAV
The stock interaction handler can be missing depending on the need of
the framework performing its tasks, so a dedicated handler is
provided, this one is always present.
- force opening of a WebDAV file.
A WebDAV file sould be open r/o even if explicitly requested to open
as r/w.
This is a limitation of current WebDAV implementation, not of the
standard.
This change is needed in order to reopen correctly a file as
requested by a 'Edit Mode' GUI command.
Change-Id: I5368fa2c0511f1630e6d6139c6a986d33aa19082
Reviewed-on: https://gerrit.libreoffice.org/17182
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I8742db77a0cfd99257584d830162c1c7126da263
Reviewed-on: https://gerrit.libreoffice.org/17283
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
We're dealing here with 2 bugs:
1. Single shape buttons (like rectangle, ellipse etc.) don't get
the pressed state when active. The cause is that all commands of
the same kind (Basic Shapes, Symbol Shapes etc.) are handled as
one internally, allowing only one type of status updates. It used
to transport the current active shape, but it was changed to a
boolean value in the fix for i#41753, and since then used for
the pressed state of the group buttons.
2. The pressed state of a group button shows always, even when a
user activates a shape from a place other than the drop-down
of that button. But in this case the image of the group button
doesn't update with the current shape, thus confusing the user on
what is currently active. The cause here is that we use (since
i#41753) the XSubToolbarController interface to update the last
selected function (instead of the old-style status based update),
and ToolBarManager notifies a controller about a new selection
only if it was made from a particular toolbar that the controller
claimed to use in the getSubToolbarName method.
Since 7352a7c17875e5adcc4226c45f4a03e11c44ff49 there is a similar
regression for other group buttons in sd (like lines, 3D Objects
and other), with the same cause. This is also fixed now.
Change-Id: Ida074a001ff78bf5bd5bcb8151516daa6e27cbce
|
|
Change-Id: I5187364d420ab78c36a91632efab9c32951d867a
|
|
Change-Id: I52cbaad71560d73f5e24f3de3cd62b00d678dd6c
Reviewed-on: https://gerrit.libreoffice.org/17187
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
See no benefit of it here, and also it has some unexpected
results with some commands that have enum commands, and
use a string item to update the currently selected item.
Change-Id: Iae54c4e1fb7a3aa5a7c1a03904fb3629ed63c8f0
|
|
Change-Id: I1ad92d1496759007f770b86f9d24e322b3ae194b
|
|
Change-Id: I365b43f0327219f5ccd74984ec907088a8769785
|
|
Change-Id: I5601c7847f30a7d5fb7ede5f90b2a6a89f4c8693
|
|
Change-Id: I1b1cb7fcd2ae0e0f50e4d8e3900bc416435e60bf
|
|
Change-Id: Idebc8a926c6653c476c2507606d4a89b22e2eaaf
|
|
Change-Id: Ibfeb0ef753a083f458c84f446f0729f05c73e2d6
Reviewed-on: https://gerrit.libreoffice.org/17060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I69cd54f6fddc93f0cdf87651401fedb60aeeb1f4
|
|
Change-Id: I0a57d590d9e82d368b00ef11426e512ba7bc4dd4
|
|
Change-Id: I04ad31055c04a247faddf4311943ca769051473c
Reviewed-on: https://gerrit.libreoffice.org/17032
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
This global was crashing on exit, unsurprising as it contains UNO
services that reference VCL objects.
It turns out that there is already a UNO singleton
framework::ContextChangeEventMultiplexer that effectively contains this
mapping already, so try to hook that up without creating a public API of
it, which is made quite a bit harder by framework's inexplicable
multitude of libraries.
Change-Id: I4baf67b42c630191fa8879d650eeb62520c331a5
|
|
Currently many toolbar controllers are basically doing the
same thing - show some docked toolbar. So the idea here is
to have one generic controller that will handle all these
cases in a unified way. It will get the name of the toolbar
that it's supposed to show from the configuration, based on
the command it was registered for.
Right now it can handle both simple (i.e. with DROPDOWNONLY
bits) and split (i.e. with DROPDOWN bits) scenarios, where
for split kind it replaces the function (and the image) of
the main part of the button, with the last selected function,
for easy reusing. A button is considered to be a split one,
if the name of the initial default command was passed along
with the sub toolbar name, otherwise it will be a simple
button.
The core change is in framework/. Other parts are a usage
example, in form of converting the custom shapes buttons
to this new controller.
Change-Id: I087cc58c3db1889ca69a26546d4f00fe07e2a58d
Reviewed-on: https://gerrit.libreoffice.org/16967
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
One more step away from using the frame as key and moving to the
controller.
Change-Id: I438b7eea2161d49a6f2cbf649bf01b8a2e233ebd
|
|
It just includes a bunch of other boost headers; mostly we need
boost/noncopyable.hpp so include that directly.
This eliminates 831 MB(!) of boost/preprocessor/seq/fold_left.hpp
completely, which is the 2nd biggest header after ustring.hxx.
Change-Id: I3df55770adcb46e56f389af828e8ba80da2dc1f2
|
|
Change-Id: I40c504d086c8ae1fd825acdafaada283ad9db8d0
|
|
Change-Id: I70b03c152f63e48341dc5629a99b0eeab7b497c0
Reviewed-on: https://gerrit.libreoffice.org/16834
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
So that the sub-toolbar controller will pick the
right image size.
Change-Id: I70b642ac84377b461a001ef11f551a5e1448c0f1
|
|
The doc for XSubToolbarController::updateImage says:
"gets called to notify a controller that it should set an image
which represents the current selected function.
Only the controller instance is able to set the correct image
for the current function. A toolbar implementation will ask
sub-toolbar controllers to update their image whenever it has
to update the images of all its buttons." However, it didn't
work that way until now.
Steps to reproduce:
1. Open one of the custom shapes dropdowns, and choose a shape
other than the default. Note that the button is now updated
with the last selection.
2. Change the icon theme. Note that the button shows now the
default shape, despite the fact that a future activation
of that button, will still draw the last used shape.
Change-Id: I9345c9faa17dc82a5f590b242b60751ce5d8e648
Reviewed-on: https://gerrit.libreoffice.org/16781
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Ic136cce6abef44291b7236a6d709f0eee391f311
Reviewed-on: https://gerrit.libreoffice.org/16784
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Id884946cae0687d0b71c967e236e58df17567884
Reviewed-on: https://gerrit.libreoffice.org/16707
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I9dcc0ce882dfd533d98a4f71625bb85e44084283
|
|
Change-Id: I74c683cf1ca821733717348a7840feeb7fbff3e9
|
|
Change-Id: I1c5e4970d4e90bdea68a901294594104de5e189e
Reviewed-on: https://gerrit.libreoffice.org/16582
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: I1d7db630eb6d0c12c5eb8b507be114693689e4e1
|
|
Change-Id: Ic92709acff10386f22b633e9cd4c3ad6cd1fbc9b
|
|
Change-Id: I9009a96e09943b5339c6ef6995d9a28c3e4b596c
|
|
Change-Id: I7ddc62f0ee005652dba62adc359959e1eb09a41e
|
|
Change-Id: If5dcf42448f87888e9f6bab2209bc1f9dd1d525c
|
|
Change-Id: I80995af6459af9f647e66d1c85da2eedad2647b9
Reviewed-on: https://gerrit.libreoffice.org/16523
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ifd126a535f18db79a18aaec61b76cdf26ab33dff
Reviewed-on: https://gerrit.libreoffice.org/16522
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ie17c1d6c7664b3d3ad0255094b26ba433c2c1921
|
|
...although it was like that ever since its inception in
4718eab5490fd470945890d90427f87894952d5f "INTEGRATION: CWS keyconfig01," but
perhaps impl_st_normPath never actually gets called with a path with leading
slash, anyway.
Change-Id: Ia3cf4f4020b3a9ca7152777bfa0378c28948fb8f
|
|
Change-Id: I63f1b54cc9ef49a83800b671a60ea25df7fc2121
|
|
Change-Id: I60ed5eb658d50cbc7dc572facb5463b7527b4d9b
Reviewed-on: https://gerrit.libreoffice.org/16408
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Decouple the actual window from rendercontext in UserDrawEvent.
Change-Id: Ic440c4e7f59fcffb7800c578146e8eb528cbb7b4
|
|
Change-Id: Id30efd398cc5ee3df0c31cae53028e1a1b6ea025
|
|
Now, whatever the size of toolbar icons, the toolbar
context menu always shows small icons.
Change-Id: Id17df15278d74ae75a3e82d54ecf7af310e0ceb4
Reviewed-on: https://gerrit.libreoffice.org/16361
Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>
|
|
Renames some variable to ease the understanding of what does what
Change-Id: Idd84eb89b7c1fb56dd43d66edfbbeafedc319095
Reviewed-on: https://gerrit.libreoffice.org/16360
Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>
|
|
Change-Id: Ib6d91f1ee427d5f94eed75e478f0809346f38e05
|
|
Change-Id: Ibfa971952cd330ddf430e7e951c5c235d2ae6bd8
Reviewed-on: https://gerrit.libreoffice.org/16314
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
At least OutputDevice::acquire/release use a plain unguarded int and ++, --, so
apparently rely on the SolarMutex being locked whenever they are called. Fixed
those places that caused "make check" to fail for me when temporarily adding
DBG_TESTSOLARMUTEX() to OutputDevice::acquire/release. (A recurring pattern is
that a class fails to ensure the SolarMutex is locked around the destruction of
non-null VclPtr members.)
Change-Id: I77cba6f3908f2de1b516ce28f1c3c43b3f57a9c5
|
|
Change-Id: Id8c7cf460cba5af89891c470e1aaa61b227d356e
Reviewed-on: https://gerrit.libreoffice.org/16310
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Icfb885b72d51edc886851cf503c56fa12b8f559f
Reviewed-on: https://gerrit.libreoffice.org/16309
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I528752dfabeb31d14c350f79819b521537ab9b56
Reviewed-on: https://gerrit.libreoffice.org/16300
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|