Age | Commit message (Collapse) | Author | Files | Lines |
|
as in interim measure for SfxTabDialogs we throw
away the TabPage if its not suitable for reuse
Change-Id: Ic5776ca3d2a8cb6bf41f33df01b211f81c62a842
Reviewed-on: https://gerrit.libreoffice.org/43134
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This tiny inconsistency with other software has annoyed me for too long.
Change-Id: Ieef8cdcf13f1cea0e414fbe086e45a4e05895467
|
|
Change-Id: I405b347b404ed0acb3b6a0204e0b914a7698ce25
Reviewed-on: https://gerrit.libreoffice.org/42284
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I0bd4cb463575af843c72d9c8aaf91742203532a4
Reviewed-on: https://gerrit.libreoffice.org/42283
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ibb7d8c59c0e61b0e87455bd78f241d8691dd9dce
Reviewed-on: https://gerrit.libreoffice.org/42282
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I7739c4f77c856d34f8484754244df13d8fef840e
Reviewed-on: https://gerrit.libreoffice.org/42151
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic72693ad8f33fb94c171751f82680eabad1d3d6d
Reviewed-on: https://gerrit.libreoffice.org/41900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ief8bd59c903625ba65b75114b7b52c3b7ecbd331
Reviewed-on: https://gerrit.libreoffice.org/41019
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is considerably less verbose
Change-Id: Ifa373e8eb09e39bd6c8d3578641610a6055a187b
Reviewed-on: https://gerrit.libreoffice.org/40978
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
make them all the same and share std::locales more
various OModuleClient, etc, classes go away
Change-Id: I7e3ff01a69332eeacd22e3078f66a60318de62d5
Reviewed-on: https://gerrit.libreoffice.org/40634
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
and the vast majority of translations is to the ui language so default
ctor with that arg
and now drop OModuleResourceClient
Change-Id: I3b85a560ffdfe5f019c2271ac56a5fe4a361522b
|
|
Change-Id: I1c987d991a5b292df327d1bb921099233b5531fe
Reviewed-on: https://gerrit.libreoffice.org/40584
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I21e538b8e9c7a5f0fb233019efac37a3555e3c93
Reviewed-on: https://gerrit.libreoffice.org/40438
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I96bbca8e6d91448fbb27fe95a57ce62a78d1b2c5
Reviewed-on: https://gerrit.libreoffice.org/40242
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I9fe10986270117495628817b56ddf31f9f315454
|
|
e.g. helpid[s].hrc -> helpids.h
and insert include guards where missing
move "ordinary" defines into .hxx files
remove .hrc entries that are used as arguments to dialog factory
when a dedicated method can be added instead
Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Change-Id: I6f6fcdab24a426d0f62052fa2d31f4098d1d893a
|
|
Change-Id: I32488373bd22e644ee06920045008f3d9e20e985
|
|
... and not read after having been set in FillControls()
Change-Id: I09ae5655b6187bcedc95232797bddb24b9064847
|
|
Code is already confusing enough..
Change-Id: I5b6f5bce32342623374df67727c44cc50b77930c
|
|
This is based on glibs classification of tasks, but while glib uses
an int for more fine grained priority, we stay with our enum.
1. Timers start with DEFAULT priority, which directly corresponds
with the previous HIGH priority
2. Idles start with DEFAULT_IDLE priority instead of the previous
HIGH priority, so idle default becomes "really run when idle".
As RESIZE and REPAINT are special, and the DEFAULTS are set, there
is just one primary decision for the programmer: should my idle
run before paint (AKA HIGH_IDLE)?
If we really need a more fine-grained classification, we can add it
later, or also switch to a real int. As a result, this drops many
classifications from the code and drastically changes behaviour,
AKA a mail merge from KDE is now as fast as Gtk+ again.
Change-Id: I498a73fd02d5fb6f5d7e9f742f3bce972de9b1f9
|
|
Change-Id: I76c0ac6cbd8475884fb80002ebb91f2ba84818a0
|
|
Author's Enter key must had been broken as well, not only Space key..
Change-Id: I61c947a988f36cb55d1037ca0bd277fca181b09e
|
|
Now that ScCompiler compiles ScTokenArray we can finally handle
FormulaToken::IsInForceArray() as well.
Still missing is the evaluation of the selected sub expression of a formula.
Change-Id: I801859498569e4369db13144fe8ba08ca576350b
|
|
This reverts commit ff10bc47abe0b04480c9fb5db025afbb5e402b4b.
commit ff10bc47abe0b04480c9fb5db025afbb5e402b4b
Date: Tue Jul 11 10:24:51 2017 +0200
loplugin:casttovoid
...as introduced with f6574be0e375e215e6f21830b9e09d77d01b5097
"FormulaDlg_Impl::MakeTree: pass down current function/operator token: In
preparation of better argument evaluation."
That (void)pFuncToken was there to not break the build with unused parameter..
and all work in progress.
Commit actually using pFuncToken follows immediately, I'm just too lazy
to resolve the merge conflict for an already ready patch.
Change-Id: I572c3087a1cca9efa217e1e1818192d251e3345d
|
|
So this actually obeys all application specific rules when generating RPN code.
Change-Id: I5e1a89efffe5188d3c4b68176cc410a6cd76483a
|
|
...as introduced with f6574be0e375e215e6f21830b9e09d77d01b5097
"FormulaDlg_Impl::MakeTree: pass down current function/operator token: In
preparation of better argument evaluation."
Change-Id: I2ea39115bc2d2dbbea6fd899c347c98949ec281a
|
|
In preparation of better argument evaluation.
Change-Id: I364fe03c58a975ae95f070112e11a9eec9505f3d
|
|
Change-Id: I8d782b109eb390838b6c4f3a85e9b344ecef87ec
Reviewed-on: https://gerrit.libreoffice.org/39606
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Icbe27f697aed9a67e3e1783783df0c6ad598b582
|
|
Change-Id: I002f9ecea2933642399667caaa1a9d77e30751a9
|
|
Change-Id: I0edd454c03b0c3e502d4ef87db584a0cec2884be
|
|
Actually only the SvTreeList::InsertEntry() needs a non-const void*
Change-Id: I63eb05ba63264efd63bfa287f0ab0bf2840b4414
|
|
Somehow opening the Function Wizard always still has a keyboard input pending
when breaking in the debugger so the first calculateValue() call was bypassed.
Change-Id: I1ad2fdf1724ae793edc7497895c8d8cead733f86
|
|
... with what was actually meant (worked though).
Change-Id: Ie7fb5f25bc45e8c224f0cc5853a45fc6e1574f3c
|
|
Parameter count is size byte, so.. SUM(1,1,1,...) with 256 arguments resulted
in 0 (uint8 wrapping around).
Change-Id: Ib9997ad0d0d13d4c5171f276148b6c5cad570d5b
|
|
... to have it at one central place instead of two. And add comments why
changing the value is not just easily done.
Change-Id: I266ea55c79c02a653a0704c33f9fa712bbcd104e
|
|
Change-Id: I5d8fe8869087efda68d040448b2d9e0e7e5611f6
Reviewed-on: https://gerrit.libreoffice.org/39493
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4b0dd08963cf50daa41901975c6f92fe21db2048
|
|
Change-Id: Ice54ac31c7b1153220895359e3df5b15b54d5484
|
|
Change-Id: I96d6af49c1994ebd7d6dcc41469127e3151b4350
Reviewed-on: https://gerrit.libreoffice.org/39186
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib0c083803024d223f62b91ec54850b84eb68a758
Reviewed-on: https://gerrit.libreoffice.org/39033
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
This one has no extra functionality at all, and its only purpose is to
be used in range-based for loops. If there is a cleaner way to do
this, feel free. Not sure if this functionality could or should be
combined with either of the two existing iterator classes related to
FormulaTokenArray (FormulaTokenIterator and
FormulaTokenArrayPlainIterator). Probably not.
Change-Id: I32599b0800fd2585624d3742a46ad4896ce7e47a
|
|
Change-Id: I06dd3639e4110700e070f1224112a9fa6597a832
|
|
Change-Id: I9a947078d9f2c1c06cb8524be137ba5e36e97a0b
|
|
Change-Id: I3b50e45fdb99e9cd8bfda07356ee3ddb4dd0f8bb
Reviewed-on: https://gerrit.libreoffice.org/38905
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
Instead, use FormulaTokenArrrayPlainIterator everywhere, especially in
the FormulaCompiler.
This is the final step of a long chain of commits. (Split up into many
"uncontroversial" bits, and then this, to make potential bisecting
easier.)
Also added a logging operator<< for FormulaTokenArray, for SAL_DEBUG,
SAL_INFO etc goodness.
Change-Id: I02fe29f3f1e0dc33e5cba69e594223b4178a12bc
Reviewed-on: https://gerrit.libreoffice.org/38851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I087f0fe99e6631d5b62ea773c83404e11d64d060
|