| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I1ea95e0bfeaed88b9484403e6796574f1d06f133
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159612
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8c5c1d569d022ac679e4939d97fdd293000c23ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159300
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and annotate where necessary, mostly just suppressing the warnings
Change-Id: I8e39d797cde6c7c3f4e3e1bd93a128965ecec81d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159205
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The maximum value of the width in BrowserColumn is LONG_MAX. tools::Long
value range is the closest among other integer types. It is widely used
in these files. Also, other parameter types and return types have been
changed to match the width type.
Change-Id: Ia8b941a8ea02075a0d9b4d44675d5809005738bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157477
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Ib9f62be3acc05f24ca234dec0fec21e24579e9de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158911
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
To understand this, some look back in history will be needed to see
why it is as it is today. In some (reworked) comments 'poolable' is
described as flag to hold Items in the ItemPool, also always having
only one incarnation of each possible Item.
This is not the original intention, but a side-effect. The reason is
what the binary format in the office did: To save a document, the
Objects & the Pool were saved, *not* individual Items *together*
with the objects. The Pool was completely (binary) saved (and loaded)
in one run.
Temporary IDs were used to represent at the objects in file which
Items were referenced. This *required* to have only one incarnation
per item to have a minimal binary file size, thus this high effort
was put into this. At doc load, the pool was loaded, all Items were
set to RefCount 5000, the references from the objects were restored
and then for each Item the RefCount was lowered by 5000 again
and - if being zero - deleted. Items for UI were marked 'non-poolable'
to *not* safe them with the document, so poolable was a flag to decide
if that Info/Item was to be saved with the document - or more direct:
if it is Model Data.
Items are small, so if we prefer runtime it is okay to no longer being
strict with this, anyways does not happen often and has only marginal
memory effects - compared to runtime effects/savings.
Other problems which this caused: One example is that objects in the
UNDO stack were still in the pool, so e.g. deleted pictures were saved
with the document despite no longer being used (!). That is the reason
we have an UndoItemPool and a method MigrateItemPool to move stuff to
that Pool when objects go to the UNDO stack - all of this is also no
longer needed.
Cleaning this up means to ideally have all items in the SfxItemSet,
no longer at the Pool. The Pool should be reduced to a 'Default-Item-
Holder' and a 'Slot-to-whichId-mapper'.
This needs thorough cleanups/removals, but will be worth it because
that massive simplification(s) will increase safety an runtime and make
migrating to the goal of completely type-based ItemSet stuff easier for
the future. Hopefully only view code in the office working with items
will have to be changed for this.
In this 1st step I already found that some 'compromizes' will be
needed:
- There are still Items that have to be at the pool to make the
Surrogate-stuff working. This gives back all Items in a Pool of a type
and is used in ca. 80 cases. Each one looks at these Items *without*
context (e.g. a SfxItemSet at an Object would be a context), so if e.g.
a dialog is open that temporarily uses Items of that type you would
also get these - without knowing about it...
To make that work there is still a mechanism to have Items at the Pool,
but now just *registering* (and un-reg) them without any sort/search/
remove needs. Also only for Items that need that, so I evaluated the
GetItemSurrogates calls and added some asserts when GetItemSurrogates
tries to access an unregistered item type which needs to be added.
- Another caveat is that there are about 250 places that directly put
Items to the Pool (not all remove these, that is done at pool deletion,
so some kind of silent 'garbage-collection' is in place). To have an
overview I renamed the accessing methods to separate them from the same
functionality at the SfxItemSet, which had the same names. An
implementation does still add these directly to the pool, there is no
way to cleanup those usages for now. In principle all these should be
changed to hold the data at an SfxItemSet.
I am still hunting problems. But you can build the office, all apps
work (including chart) and you can do speed comparisons already.
There are test throwing errors, so I hunt these now. It is hard to
give an estimation about how much more changes/corrections will be
needed.
Completed adaptions to new registered Items at Pool, that reduces the
failing tests. Still many that I need to hunt.
Added stuff to work around that 'compromize' in ScDocumentPool: It
overloads ::PutImpl of the pool to implement special handling for
a single Item in SC, the ScPatternAttr. In former code that method
was used from SfxItemSet and ::PutImpl at the pool directly, so it
was only used in one place. I am not sure if it was used from
the SfxItemSet functionality, but better offer it for now. To not
waste too much runtime the callbacks depend on the boolean
'NewItemCallback' at the SfxPoolItem, it gets set for that single
Item in SC and only then the callbacks trigger. I hope to get rid
of those again, e.g. newItem_UseDirect is only needed since we have
no 'real' StaticPoolDefaults currently - another thing that needs to
be cleaned up in a next step.
Since usages of impl(Create|Cleanup)ItemEntry and
Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to
unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it
globally available in svl and use it also directly for
Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing
tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that
fallback (e.g. tryToGetEqualItem) was used before, thus this is the
same class of errors (SfxPoolItem ptr-compare) as the others which I
will need to find anyways. Also fixed some missing stuff.
Have now idenified and redirected all SfxPoolItem ptr-compares
to be able to debug these - one cause for the remaining errors is
probably that before with bPoolable those often were sufficient, but
are no longer. Used the [loplugin:itemcompare] and a local clang
build to do so, see https://gerrit.libreoffice.org/c/core/+/157172
Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter
to implCreateItemEntry to signal that it gets called from DirectPool
stuff - currently needed. Hopefully when getting rid of that DirectPool
stuff we can remove that again
Added two more debug functionalities:
- Added a SerialNumber to allow targeted debugging for deterministic
cases
- Added registering & listing of still-allocated SfxPoolItems at
office shutdown
Found PtrComp error in thints.cxx - POC, thanks to
areSfxPoolItemPtrsEqual. Will hopefully help more with other tests
Found some wrong asserts/warnings where I was too careful and not
finding something/succeeding is OK, fixes some UnitTests for SC
For SC I now just tried to replace all areSfxPoolItemPtrsEqual with
the full-ptr-content compare SfxPoolItem::areSame. I also needed to
experiment/adapt the newItem_Callback solution but got it working.
Did that replacement now for SW too, found some places where the
direct ptr compare is OK.
Continued for the rest of occurrences, now all 160 places evaluated.
Also done some cleanups.
Massive cleanups of stuff no longer needed with this paradigm change.
Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now.
It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that
already needs many exceptions. Also useful for testing if errors
come up on this change to test if it is related to this.
Added forwarding of target Pool for ::Clone in SvxSetItem and
SvxSetItem, simplified SfxStateCache::SetState_Impl and returned
to simple ptr compares in SfxPoolItem::areSame to not do the test
in areSfxPoolItemPtrsEqual.
Debugged through UITest_calc_tests9 and found that in tdf133629
where BoxStyle is applied to fully selected empty calc the Item-
reuse fallback has to be used not only for ATTR_PATTERN, see
comment @implCreateItemEntry. Maybe more...
Problem with test_tdf156611_insert_hyperlink_like_excel. Found that
in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField
is found and returned as ptr, but it's usage crashes. That is due to
the SfxItemSet aEditSet used there gets destroyed at function return
what again deletes the SvxFieldItem that is holding the SvxURLField
that gets returned.
This shows a more general problem: There is no 'SfxPoolItemHolder'
that safely holds a single SfxPoolItem - like a SfxItemSet for a
single Item (if Items would be shared_ptrs, that would be a safe
return value).
That will be needed in the future, but for now use another solution:
Since I see no reason why EE_FEATURE_FIELD should not be shareable
I wil change this for ow in the SfxItemInfo for EditCharAttribField.
That way the Item returned will be shared (RefCnt > 1) and thus not
be deleted.
I changed the return value for GetURLField() and
GetFirstURLFieldFromCell() in ScEditShell: At least for
GetFirstURLFieldFromCell the return type/value was not safe: The
SvxFieldItem accessed there and held in the local temporary
SfxItemSet may be deleted with it, so return value can be
corrupted/deleted. To avoid that, return a Clone of SvxFieldData
as a unique_ptr.
With all that UnitTest debugging and hunting and to get the paradigm
change working to no longer rely on shared/pooled items I lost a
little bit focus on speed, so I made an optimization round for the
two central methods implCreateItemEntry/implCleanupItemEntry to
get back to the speed improvements that I detected when starting this
change. It was mainly lost due to that 'strange' chained pool stuff
we have, so I added to detect the target pool (the one at which the
WhichID is registered) directly and only once. Next thing to cleanup
will/should be the pool and it's concept, all this is not needed
and really costs runtime.
Since implCreateItemEntry/implCleanupItemEntry are executed millions
of times, each cycle counts here.
Had an error in the last changes: pool::*_Impl methods use index
instead of WhichID - most of them. Another bad trap, I really need
to cleanup pool stuff next.
Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
This allows to use the same interaction handler there, as used in
DocumentMacroMode::adjustMacroMode. hasTrustedScriptingSignature
used to find its own interaction handler; and that would conflict
with e.g. ODatabaseModelImpl::adjustMacroMode_AutoReject, which
passes nullptr to adjustMacroMode, with intention to not show any
UI; but with signed macros (see tdf#97694), the UI would still
appear.
Change-Id: Ia209f96bef67dccfe1da23c4d172ac47497f8eb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159070
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
|
|
Added accessibilty to some UI files
Change-Id: Id9d1eae93151e232040fdcf22810ba67ead05609
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151138
Tested-by: Jenkins
Reviewed-by: Samuel Thibault <sthibault@hypra.fr>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Iad9c4f234833ce4c605040b9d0f9b86150791c99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158210
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I5f92e390ef57ae8f2aba43782c11ca5ee31dba93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158187
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Compare and use same order as in dbaccess/source/core/dataaccess/datasource.cxx
Change-Id: Id025e6e801387c2c377af88d2816c68ed9183e55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158171
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
to only use "m_xSharedConnectionManager".
For this, it required some refactoring but except the removing, logic hasn't been changed.
Change-Id: Iccfe5c45381f31019a0751a61cea6661c88188f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158107
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I0804518ce97e3f5f8098c4a4416675409746aaea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158044
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I660813058077a36bcf80a3128b53767c851c2672
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158105
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I30b2ac77b58e2ae1d1e997a0c830c513542b973d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158101
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In dbaccess/source/core/dataaccess/SharedConnection.hxx, we got:
35 typedef ::cppu::WeakComponentImplHelper< css::sdbc::XConnection
36 > OSharedConnection_BASE;
37 typedef ::connectivity::OConnectionWrapper OSharedConnection_BASE2;
38
39 class OSharedConnection : public ::cppu::BaseMutex
40 , public OSharedConnection_BASE
41 , public OSharedConnection_BASE2
so first OSharedConnection_BASE ctr is called before OConnectionWrapper ctr
therefore OConnectionWrapper dtr should be called before OSharedConnection_BASE dtr
It doesn't fix the bug but investigating in all this mess, I'd like to fix these things since it may help.
Change-Id: I47255357b4ca02261f31ebf500f3f1ff55642e69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158096
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Avoids overwriting source location in message
Change-Id: Ia0290c7dd1ab3ea1357712a27ecab75c7b583dd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157893
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
So test the SQL type of the column and:
- if it's css::sdbc::DataType::BIT treat it specifically
- otherwise, use plain getString method
Thank you Noel for the idea!
Change-Id: Ib5003d96c1b5ce541fb17e6e31592858f8cd61d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157849
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Regression of https://cgit.freedesktop.org/libreoffice/core/commit/?id=afe99617707c92460e66486c0057ef327e8aa017
"tdf#43369: Specific UI for collecting PostgreSQL connection settings"
in 2023-04
Change-Id: Id6e9c9a1aa8586cb4081e22988060476183369d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157193
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
For the moment, we don't implement insert field at specific position
It's not SQL standard and each database has made its choice (some use "BEFORE", other "FIRST" and "AFTER")
and some, like Postgresql, don't allow this.
So for the moment, test if the table already exists (and so it's an edition), in this case only
we remove "Insert fields" entry. Indeed, in case of new table, there's no pb.
The real fix is to implement the insert for each database + error message for those which don't support this
Change-Id: I27010ed2dddee3f8746245406f2a0cb629b3d8e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156948
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Retrieve odb file https://bugs.documentfoundation.org/attachment.cgi?id=102977
Open the file and edit the only table
Right click at left on a field (except first one)
(soffice:271527): Gtk-CRITICAL **: 14:35:42.787: gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed
(soffice:271527): GLib-GObject-CRITICAL **: 14:35:42.787: invalid (NULL) pointer instance
(soffice:271527): GLib-GObject-CRITICAL **: 14:35:42.787: g_signal_handlers_unblock_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
If primary key entry is removed, don't try to call xContextMenu->set_active on it
Change-Id: Ice57d840d12e986eb60514326806782e40f249fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156946
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I7a28204ababc9fec4e90ccbd2f0a485d6bc8d560
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156849
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the delegating class already implements the interface and forwards the
method calls
Change-Id: I8b0c74be87656675a887ddda2e7c44b63f165c2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156699
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I12b0fe811d141873aaa64af5b6c457051c3356b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156297
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156424
Tested-by: Jenkins
|
|
Generally import new DataType identification constants from OpenJDK's
java.sql.Types
Use same values for compatibility.
Change-Id: I6e3eb986dc34e8a5e2af75669363177785ff56e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155866
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
which warns against using the 'operator bool' conversion of
std::optional<bool> which can lead to interesting bugs
The bugs that this plugin have been submitted independantly,
so this change is just using has_value() in relevant places.
Change-Id: I259b837feeecddcb8cd1d7e5db1e85bf505907cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155978
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
no need to use two different ImplHelpers here
Change-Id: I1c871f8e0e49ff8a0a540e8051f3a89a54130322
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155457
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
of unknown type
e.g. provided by extension or future code.
The core assumption is that an embedded database doesn't need a user-configured "connection URL"
configured so don't ask for one.
Change-Id: I7d11cc0b492782634dd49f74d9d709dca434e990
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154989
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib932de42ffec6d71b31a25d53f46f18a26b0b2b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154762
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Jenkins
|
|
It has been always typedef'd to basegfx::B2DPoint since:
commit 5e218b5c51f7d9cd10bd9db832879efca41b9c75
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>
|
|
Change-Id: I95ab7581dec35b113cb657ce8e5ee27c89c73593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153746
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
around dealing with operator[] on map data-types
Change-Id: Idd6654948ae2d03d634fcf30a8d98530a78ab4ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153740
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iad2564853a2a0d74cd526b1574e421e121fd6986
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153644
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
that can be initialised at compile-time instead of runtime
Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
+ Moved static strings to ui file, handled by Glade
+ added extended tips to widgets
+ deleted references to strings in the controller.
Change-Id: I0acb444eff37adbfc0225656669af9d5650b7bd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153127
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Change-Id: If395b0784d9bdcdc1200c15fca60647da825ea1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153150
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: I879e4d93e1da222d9acabb776552ca1cf819574b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152136
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Change-Id: Ic6d4c80813286d6b5dbe33dc0289d0f0d9cedfc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152569
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Lionel Mamane <lionel@mamane.lu>
|
|
There is no need to do this, as the documentation of
css.lang.XComponent::dispose at
udkapi/com/sun/star/lang/XComponent.idl
states:
After this method has been called, the object should
behave as passive as possible, thus it should ignore all calls
Otherwise, the effect of throwing here is mostly to disturb the flow of
logic in caller code, preventing other parts of teardown from proceeding
smoothly.
Change-Id: I30e6d1b35f85b727debf4405a995fdc0a4fccde6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152450
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It seems "label" doesn't exist for AtkObject so rather use "AtkObject::accessible-description"
Regression from afe99617707c92460e66486c0057ef327e8aa017
tdf#43369: Specific UI for collecting PostgreSQL connection settings
Change-Id: I1f4f7ebe5e20a9ff7b75e6f82ffdd2bdebe7417c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152406
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If7b4320e199a01f2614e3bf582e5d96fade22aa2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152353
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I875e94e47d44101a840b711de174f38ad4b85b4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152357
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: Iaa7ce9165da835a638bcc1d633bed0a2ff2c4108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152308
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Thank you Michael Stahl for having spotted this! :-)
Change-Id: I4e643b562e6dc653a511109531837c228f0e0e0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152305
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I462cb28c15a0cd1d3c93f2335bcac02ca09c78e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152289
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
