Unfortunately, when the client side shows
the "Macro Selector" dialog, it tries to show
a java interaction message box to locate the
files of the JVM, even if the code explicitly
option to not enable "DontEnableJava"
Change-Id: I2ef4373f58c3ba23a5b86c5dc984caf6c10821ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108421
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ifc70900022efcd089c0874bd46e0aacaef0efb72
Reviewed-on: https://gerrit.libreoffice.org/78767
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
just the straight-forward MessageDialog cases first
a) remove border_width from message dialog .ui so as to take
the default border width
b) retain 12 as default message dialog border for vcl widget case
c) remove layour_style from message dialog button boxes so as to
take the default mode (a no-op for vcl widget case)
d) use gtk response ids (vcl builder will converts to vcl ones)
Change-Id: I7de281093a1b64f92f71ca11e7cbba42bb658154
Reviewed-on: https://gerrit.libreoffice.org/50143
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
In commit 5785e4f4ab, initial work to only
show Java error dialogs once had been done. Still, in some cases, multiple
such dialogs can still be shown.
JavaInteractionHandler instances can be created in at least two contexts:
in JavaContext::getValueByName, and in DesktopContext::getValueByName.
Additionally, in the latter, it is not kept for subsequent reuse, but re-
created anew each time. So, it is possible that "Java Missing" (and friends)
dialogs will be shown multiple times per session. E.g., specific installed
extensions (not using Java, but rather Python) can trigger said behavior
in Desktop::doShutdown inside BackupFileHelper::tryPushExtensionInfo.
This patch makes the "already handled" flags static, thus sharing the
status among different handler instances.
Also, unchanged-after-const-initializing m_bShowErrorsOnce is removed.
Change-Id: I79d40639caa9764a04af9201c7e1a6fa624f03e5
Reviewed-on: https://gerrit.libreoffice.org/48678
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* 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
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Convert code like:
0 == aStr.compareToAscii("XXX")
to
aStr.equalsAscii("XXX")
which is both clearer and faster.
Change-Id: I2e906d7d38494db38eb292702fadb781b1251e07
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
use solenv/bin/add-modulelines script for the task
and remove all UTF bom from *.src and *.hrc files
svx/source/dialog/hdft.src
Change-Id: I745d4f0fe9b05436a142a03f8512970f91c41bd4
...instead of just telling the user to restart manually.
The one existing dialog (duplicated into svtools and cui) that got replaced by
this is the dialog asking to restart when the choice of JVM changed. There are
more similar dialogs that would benefit from replacing them, like
RID_SVX_MSGBOX_OPTIONS_RESTART (cui/source/options/optjava.src), but that one is
called when closing a dialog nested within the Options dialog, and calling
OfficeRestartManger.requestRestart in such a nested situation still leads to a
crash.
The design idea is that when more similar dialogs are replaced, restartdialog.ui
contains a list of hidden GtkLables with the appropriate prose why a restart is
required in the given case, and restartdialog.hxx's RestartReason enum contains
corresponding values that will show exactly one of those GtkLables.
The new svtools/uiconfig/ui/restartdialog.ui is probably still pretty rough and
could benefit from some UX love.
Change-Id: Id939188ee22f24301a8a3598b83afb31339bded5
Stephan Bergmann