| Age | Commit message (Collapse) | Author |
|---|
|
'sc' module was cleaned.
Change-Id: Ia491d741a4c1c5314f35ebb4baa82dd516948ae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165699
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The ::Put methods at SfxItemSet had an extra WhichID
parameter that was not really documented, but I would
guess often asked why it exists: An extra WhichID, just
called 'nWhich' (which makes things NOT clearer). That
is 'strange' since the Item given to be put already
internally has a WhichID, so why a 2nd one?
If you were really interested and read all that code
(no, no comments on that anywhere) you might know
that this a kind of 'Target-WhichID' under which
the Item shall be put to the ItemSet. Since this
is unclear for most people it is even dangerous and
explains why so many code places just hand over the
WhichID requsted from the Item that already gets
handed over.
To make it short: I removed that. For the 19 places
where this was really needed I added a new method
besides ::Put called ::PutAsTargetWhich that takes that
extra WhichID (now called TargetWhich) and takes the
needed actions. These are quite some because that may
be combined with the bPassingOwnership flag, see new
SfxItemSet::PutImplAsTargetWhich method.
This makes usage of ItemSets/Items less dangerous. It
also simplifies and thus makes safer the central helpers
implCreateItemEntry/implCleanupItemEntry which have some
less cases to handle.
Debugged the failing UnitTests showed that there is
an incarnate Item != SfxVoidItem that causes problems.
I checked for errors in the change, but no luck.
Afterr some time I found out that a ::Clone
implementation caused the problem: These need to
also copy the WichID of the original, but the
SfxFrameItem failed to do so. This did not cause
problems in the former version because
implCreateItemEntry was designed to set a missing/
different WhichID.
I corrected that in SfxFrameItem, also removed not
needed costructor that caused that. Also added a
SAL_WARN and a correction in implCreateItemEntry.
I could have added an assert (did so for running
local UnitTests), but should be enough.
NOTE: When hunting for Items except SfxVoidItem
that get crerated using a WhichID '0' i learned
that this indeed happens: There are some (5) calls
to SfxRequest::SetReturnValue that incarnate an
SfxBoolItem with WhichID '0' (ZERO). This is not
good and I think about how to change that...
Change-Id: I9854a14cdc42d1cc19c7b9df65ce74147d680825
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162124
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
ScPatternAttr is traditionally derived from SfxPoolItem
(or better: SfxSetItem) and held in the ScDocumentPool
as Item.
This is only because of 'using' the 'poolable'
functionality of the Item/ItemSet/ItemPool mechanism.
Lots of hacks were added to sc and Item/ItemSet/
ItemPool to make that 'work' which shows already that
this relationship is not optimal.
It uses DirectPutItemInPool/DirectRemoveItemFromPool
to do so, also with massive overhead to do that (and
with not much success). The RefCnt in the SfxPoolItem
that is used for this never worked reliably, so the
SfxItemPool was (ab)used as garbage collector (all
Items added and never removed get deleted at last
for good when the Pool goes down). For this reasons
and to be able to further get ItemSets modernized
I changed this. I did two big changes here:
(1) No longer derive ScPatternAttr from SfxItemSet/
SfxSetItem, no longer hold as SfxPoolItem
(2) Add tooling to reliably control the lifetime of
ScPatternAttr instances and ther uniqueness/
reusage for memory reasons
It is now a regular non-derived class. The SfxItemSet
formally derived from SfxSetItem is now a member. The
RefCnt is now also a member (so independent from
size/data type of SfxPoolItem). All in all it's pretty
much the same size as before.
To support handling it I created a CellAttributeHelper
that is at/owned by ScDocument and takes over tooling
to handle the ScPatternAttr. It supports to guarantee
the uniqueness of incarnated ScPatternAttr instances for
a ScDocument by providing helpers like registerAndCheck
and doUnregister. It hosts the default CellAttribute/
ScPatternAttr. That default handling was anyways not
using the standard default-handling of Items/Pools.
I adapted whole SC to use that mainly by replacing calls
to DirectPutItemInPool with registerAndCheck and
DirectRemoveItemFromPool with doUnregister, BUT: This
was not sufficient, the RefCnt kept to be broken.
For that reason I decided to also do (2) in this change:
I added a CellAttributeHolder that owns/regulates the
lifetime of a single ScPatternAttr. Originally it also
contained the CellAttributeHolder, but after some
thoughts I decided that this is not needed - if there
is no ScPatternAttr set, no CellAttributeHolder is
needed for safe cleanup at destruction of the helper.
So I moved/added the CellAttributeHolder to ScPatternAttr
where it belongs more naturally anyways. The big plus is
that CellAttributeHolder is just one ptr, so not bigger
than having a simple ScPatternAttr*. That way, e.g.
ScAttrEntry in ScAttrArray did not 'grow' at all. In
principle all places where a ScPatternAttr* is used can
now be replaced by using a CellAttributeHolder, except
for construction. It is capable to be initialized with
either ScPatternAttr instances from the heap (it creates
a copy that then gets RefCounted) or allocated (it
supports ownership change at construction time).
Note that ScAttrEntry started to get more a C++ class
in that change, it has a constructor. I did not change
the SCROW member, but that should also be done.
Also made registerAndCheck/doUnregister private in
CellAttributeHelper and exclusively used by
CellAttributeHolder. That way the RefCnt works, and a
lot of code gets much simpler (check ScItemPoolCache,
it's now straightforward) and safer and ~ScPatternAttr()
uses now a hard
assert(!isRegistered());
which shows that RefCnt works now (the 1st time?).
There can be done more (see ToDo section below) but I
myself will concentrate on getting ItemSets forward.
This decoupling makes both involved mechanisms more safe,
less complex and more stable. It also opens up
possibilities to further optimize ScPatternAttr in SC
without further hacking Item/ItemSet/ItemPool stuff.
NOTE: ScPatternAttr *should* be renamed to 'CellAttribute'
which describes what it is. The experiencd devs may know
what it does, but it is a hindrance for understanding for
attacting new devs. I already used now names like
CellAttributeHelper/CellAttributeHolder etc., but
abstained from renaming ScPatternAttr, see ToDo list below.
SfxItemSet discussion:
ScPatternAttr still contains a SfxItemSet, or better, a
SfxSetItem. For that reason it still depends on access to
an SfxItemPool (so there is acces in CellAttributeHelper).
This is in principle not needed - no Item (in the range
[ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that.
In principle ScPatternAttr could now do it's own handling
of those needed Items, however this might be done (linear
array, hash-by-WhichID, ...). The Items get translated
to and from this to the rest of the office anyways.
Note that *merging* of SfxItemSets is *still* needed what
means to have WhichID slots in SfxItemState::DONTCARE,
see note in ScPatternAttr::ScPatternAttr about that. And
there is also the Surrogates stuff which would have to be
checked.
The other extreme is to use SfxItemSet *more*, e.g. directly
derive from SfxItemSet what would make stuff easier, maybe
even get back to using the 'regular' Items like all office,
I doubt that that would be much slower, so why...?
Also possible is to remove that range of Items exclusively
used by ScPatternAttr from ScDocumentPool *completely* and
create an own Pool for them, owned by CellAttributeHelper.
That Pool might even be static global, so all SC Docs could
share all those Items - maybe even the ScPatternAttr
themselves (except the default per document). That would
remove the dependency of ScPatternAttr from a Pool
completely.
ToDo-List:
- rename ScPatternAttr to CellAttribute or similar
- use SfxItemSetFixed with range [ATTR_PATTERN_START
.. ATTR_PATTERN_END] instead of regular SfxItemSet
(if the copy-construtor works now...?)
- maybe create own/separate Pool for exclusive Items
- make ScAttrEntry more a C++ class by moving SCROW
to the private section, add get/set methods and
adapt SC
Had to add some more usages of CellAttributeHolder
to the SC Sort mechanism, there were situations where
the sorted ScPatternAttr were replaced in the Table,
but the 'sorted' ones were just ScPatternAttr*, thus
deleting the valid ones in the Table already. Using
CellAttributeHolder makes this safe, too.
Added a small, one-entry cache to CellAttributeHelper
to buffer the last found buffered ScPattrnAttr. It
has a HitRate of ca. 5-6% and brings the UnitTest
testSheetCellRangeProperties from 0m48,710s to
0m37,556s. Not too massive, but erery bit counts :-)
Also shows that after that change optimizations in
the now split functionality is possible and easy.
Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.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>
|
|
various null checks can be seen to be redundant and removed
Change-Id: Icf49c1de4b0302795d2769a370af3abceaad0221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia7ff651d1cbc119b36a9f8052594d03650988f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137848
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can assert that it has the correct tag type
Change-Id: I984c22ae2527d652f2d4194227dc1173793300c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
as a first step to wrapping up the internals of this class and adding
some asserts
Change-Id: Ic13ddd917948dbf3fd6d73f44b8efcc727726baf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135994
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is a follow-up to f15e6293cf78d67963a6e512f60a11ae58da72c5.
Change-Id: I3f1e6bbb1fe83fab48a0c3889fb53c6919f6351d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133967
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
During the normal spell-checking in Calc, the user may change the
language on the string segment with a spelling error, which is supposed
to be applied back to that segment in the cell, but was not. This change
should fix it.
In case the new language is applied to the entire cell string, we will
set the new lanuage to the cell as a cell attribute and keep the string
as a simple string. Otherwise, the new language gets applied to the
edit engine string.
This commit also changes the return value of EditEngine::GetLanguage()
to include the string span information in addition to the language
value.
Change-Id: I713ec7aefe571f721321cd8ea687f616ab4dd61a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133966
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
OUString default ctor already uses a static instance
(through rtl_uString_new), no need to have another
module-specific static.
Commit d8037ae18a297229d1b79f8f76331abfd548350d had
removed its sw counterpart some time ago.
Change-Id: I140fe13bc1f6b0cbe188e83e602fdebe995e467a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125061
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
All these returned their value using a reference argument, for
apprently no good reason.
Change-Id: I6a33417e7df2aac67427c16e5003dfaaa1a814d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124872
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
use std::optional where the code needs to control the lifetime of the
object explicitly
Change-Id: Ia550ce051360f68911abc68c945a97d62a637b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116291
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#42949 for motivation
Change-Id: Ifc253bf800bb1468b5774663a93f4fb30bec81d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113657
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and pass in an explicit parent to use
Change-Id: I1aa768ec5ac13b2097b78499f964a3590a0ac14e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113695
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Check col against GetAllocatedColumnsCount()
instead of MaxCol(). This prevents allocating
a new column just for converting an empty cell.
Change-Id: I5c8dcfffc2661ab9c4fd9c2c53ed389e57351517
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and similar, allowing a few redundant null checks to be dropped
Change-Id: Ice0d6d57df112a09d3e1af3d34126b3519529daf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103278
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
so its clear that it is not an override of baseclass EditEngine::SetText
Change-Id: I85ee9c9b212fe9248fb7e5fcb1ec83679ffb633d
Reviewed-on: https://gerrit.libreoffice.org/84553
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia56c712deaaef5581a7f3f544843b44fc5c485da
Reviewed-on: https://gerrit.libreoffice.org/81000
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie47dff381392ef57cb857184c179bf82d3b55862
Reviewed-on: https://gerrit.libreoffice.org/77258
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I050b4bdff4eaa645316538725c69e83bee4a90c5
Reviewed-on: https://gerrit.libreoffice.org/74526
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
a) use EditEngine instead of TextEngine as the former can be hosted in a
foreign widget
b) use a SfxGrabBagItem to hold the custom spellchecking info inside the
EditEngine
c) in longer paragraphs the current word is now auto-scrolled into view
d) rename Invalidate to InvalidateDialog
Change-Id: Ic6db019c32cdfd5f354c58ee7394fdaa040b86e1
Reviewed-on: https://gerrit.libreoffice.org/74119
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
After the gettext migration there is no point to have two
APIs for reading the same .mo file.
This patch is for sc/source/ui/view/ for easier review.
Change-Id: Ic07f7e924236d29f3cafd69c5ee634ae92105459
Reviewed-on: https://gerrit.libreoffice.org/54137
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
etc.
Change-Id: Ic5e6031fe99347f19002d5d8527b5632333fefb0
Reviewed-on: https://gerrit.libreoffice.org/50431
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I91d828e38d96264cf4a76f30940942556b8f78d8
Reviewed-on: https://gerrit.libreoffice.org/50205
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
instead of a mix of short/sal_uLong/sal_uInt32
Change-Id: Ie5bd26e1a6f716c0c4e174a6d560827084b3f421
Reviewed-on: https://gerrit.libreoffice.org/45159
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2ed763e0584a188032c80fde60890de3c6985cbd
|
|
When opening a file that triggers Dialogs (e.g. cannot
read/repair/FileType) the Frame from which it was
initialized gets blocked. This irritates quite some
people. Changed this to a non-modal Dialog so that
the user can continue to work with all opened docs,
open new ones, close and print/PDF/export these.
Change-Id: I048d3de3369527cec20d26396b87439254764b8a
Reviewed-on: https://gerrit.libreoffice.org/41534
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
and fix harmless bug in ImpSVGDialog::ImpSVGDialog, which there since
commit 6456f1d81090dd5fe44455c09ae3ede7ec6ac38a
Date: Fri Feb 4 14:52:54 2011 +0100
ka102: added/removed files for SVG import and module cleanup
Change-Id: I66b2ec2b029431ab453e54e962863e4ed7d78962
Reviewed-on: https://gerrit.libreoffice.org/41412
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If99a944f7032180355da291ad283b4cfcea4f448
Reviewed-on: https://gerrit.libreoffice.org/36629
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and drop unused EE_SPELL_NOLANGUAGE enumerator
Change-Id: I74a5f89335883a13d77b39f78b7de55bddb1f107
|
|
since...
commit ba81e5c6bd420b41a84ade6ccd774011a8089f7f
Date: Thu May 28 21:35:43 2015 +0100
tdf#91702 - fix stack-based MessBox allocation.
There is no special ScopedVclPtr<X>::Create or
ScopedVclPtrInstance<X>::Create just
VclPtr<X>::Create and a raw VclPtr<X>::Create()->foo
doesn't call dispose on the owned X
Change-Id: Ifacc8d5e742820701307c3c37b9b86487667d84f
|
|
Change-Id: I2707d16e6dd7bc5617094963933fced147a496e8
|
|
Change-Id: If8aa0158c60d5727d9bdd66aa351c50c987c3e5f
Reviewed-on: https://gerrit.libreoffice.org/23662
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I765d2a600f9c57da50c85354688e3ae796750d94
|
|
replaced use of PTR_CAST, IS_TYPE, ISA in
idl, editeng, sc, sd, sw, sfx2, sot, starmath
Change-Id: I4a5bba4fdc4829099618c09b690c83f876a3d653
Reviewed-on: https://gerrit.libreoffice.org/19132
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
|
|
Change-Id: I7f3bb094f116103c1146a7d60e3af94c0b37d9ea
Reviewed-on: https://gerrit.libreoffice.org/18677
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I82c7084f203a834c2d42f9527705288e6036019b
|
|
Change-Id: I1e6a7fd66f90e6acd803c6cd464f1d73252f7bcb
|
|
Not very useful these days, since we have the css:: prefix to reduce
verbosity.
Found with a search like:
git grep -nP 'typedef .*uno::Reference.*<.*>\s+\w+;'
| grep -v 'std::'
Change-Id: I16f41c53837ec5c613545ae45df38b0daddcbadd
Reviewed-on: https://gerrit.libreoffice.org/16730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I62dd164e281911d9db3de453789a5badc7cd5fd7
Reviewed-on: https://gerrit.libreoffice.org/15954
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I912187d6c481a2ba61fed9c01998bf6f3c08a6a0
|
|
Change-Id: I616c8c28255e0d90ae90033a128bd34d7570530c
|
|
They need to be wrapped in ScopedVclPtr in order to be disposed properly.
Change-Id: Ib64dba353774f54711e4de7f5d15d859c6a4dc7e
|
|
Change-Id: Ia8b0d84bbf69f9d8f85505d019acdded14e25133
Conflicts:
sw/qa/tiledrendering/tiledrendering.cxx
|
|
Put the VCL Window class in the vcl namespace. Avoids clash with the X11
Window typedef.
Change-Id: Ib1beb7ab4ad75562a42aeb252732a073d25eff1a
|
|
Put the VCL Font class in the vcl namespace. Avoids clash with the X11
Font typedef.
Change-Id: I1a84f7cad8b31697b9860a3418f7dff794ff6537
|
|
Change-Id: Ib15413e73409cc33de01fa92a47b9d1237cfc4b2
|
