- 27 Nis, 2019 1 kayıt (commit)
-
-
Caolán McNamara yazdı
Change-Id: I9d0204161a0efe91ebcddaf5b2931ab156221b79 Reviewed-on: https://gerrit.libreoffice.org/71308 Tested-by: Jenkins Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
- 26 Nis, 2019 8 kayıt (commit)
-
-
Stephan Bergmann yazdı
Don't know how this got broken, presumably somewhere along the line from 01344a8c "convert sysui to gbuild and add to tail_build" through 4430ace3 "tdf#90753: AutoInstall more packages" to the current state, where a spurious bin directory containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is placed in instdir/ and in the root window of .dmg files. As discussed in the <https://developer.apple.com/library/archive/documentation/ General/Reference/InfoPlistKeyReference/Articles/ AboutInformationPropertyListFiles.html> "Localizing Property List Values" section, those InfoPlist.strings files shall apparently be placed into the Contents/Resources/*.lproj/ directories. (And the zip wrappers were presumably needed in the past to transport their payload to the proper places in the installation set, and are now obsolete.) The list of Apple language IDs for the *.lproj directories was already duplicated in Makefile.in (test-install target) and solenv/bin/modules/installer/simplepackage.pm (sub create_package). Ultimately those lists should all be consolidated. Also, mapping from our language IDs (see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g., from zh-CN to zh_CN), and it is not clear to me why the old code explicilty added en-US to the gb_WITH_LANG list of languages for which to generate InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the non-localized strings stored in Info.plist itself). But as mentiond, those InfoPlist.strings files are all empty anyway (which may be due to another bug?), so it shouldn't matter much---at least for now---what Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an installation set. Change-Id: Iaadce2375ed319928891bace44f9866622ec3084 Reviewed-on: https://gerrit.libreoffice.org/71277 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 7a08bfea) Reviewed-on: https://gerrit.libreoffice.org/71297Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Noel Grandin yazdı
Seems like this is a somewhat pathological document, has lots of duplicated ranges. Checking for duplicates makes it load in <10s on my machine Change-Id: I25da24e0f8b1d4ad99d00474be168c75586ea579 Reviewed-on: https://gerrit.libreoffice.org/71251 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit e1ebb5cb) Reviewed-on: https://gerrit.libreoffice.org/71379
-
Caolán McNamara yazdı
since... commit a91992e7 Date: Fri Nov 16 16:26:38 2018 +0100 sw: SwTextNode::GetAttr() inconsistency Change-Id: I45a89a83332f964fc813f8083e09d816965d2658 Reviewed-on: https://gerrit.libreoffice.org/71313 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
Stephan Bergmann yazdı
For one, it is deprecated since Java 9, and for another it causes a NullPointerException when called from the JNI Invocation API (i.e., without a Java caller frame) at least with some Java 12. (Found when doing a test build with Java 12 and JAVA_SOURCE/TARGET_VER explicitly configured as 7 with d365f363 "Allow to pass JAVA_SOURCE/TARGET_VER into configure".) I have entered information about the NullPointerException at <https://bugreport.java.com/bugreport/start_form.do>, but haven't heard back yet, so duplicate that information here: Issue Type: > Bug Component: > Core Libraries Operating System: > Linux 64-bit Java Release: > 12 Synopsis: > Calling java.lang.Class.newInstance from JNI Invocation API causes NullPointerEx Description: > I can reproduce this with the OpenJDK 12 RPMs on Fedora 30, but from looking at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/java/lang/Class.java> it looks plausible that it is a common issue that Reflection.getCallerClass() returns null when java.lang.Class.newInstance is called from the JNI Invocation API, and that null is propagated to jdk.internal.reflect.Reflection.verifyMemberAccess as parameter currentClass, which dereferences it at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/jdk/internal/reflect/Reflection.java#l130>. > This is known to have been working with older OpenJDK (at least 1.8). Steps to Reproduce: > Compile the provided test.cc with `g++ -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include/linux /usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server/libjvm.so test.cc` and run it with `LD_LIBRARY_PATH=/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server ./a.out`. Expected Result: > exit 0 Actual Result: > Exception in thread "main" java.lang.NullPointerException > at java.base/jdk.internal.reflect.Reflection.verifyMemberAccess(Reflection.java:130) > at java.base/java.lang.reflect.AccessibleObject.slowVerifyAccess(AccessibleObject.java:673) > at java.base/java.lang.reflect.AccessibleObject.verifyAccess(AccessibleObject.java:666) > at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:638) > at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:490) > at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:166) > at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:404) > at java.base/java.lang.Class.newInstance(Class.java:590) > Aborted Source code for an executable test case: > #include <cstdlib> > > #include "jni.h" > > void handleError(JNIEnv * env) { > if (env->ExceptionCheck()) { > env->ExceptionDescribe(); > std::abort(); > } > } > > int main() { > JavaVM * vm; > JNIEnv * env; > JavaVMInitArgs args{JNI_VERSION_1_2, 0, nullptr, true}; > if (JNI_CreateJavaVM(&vm, reinterpret_cast<void **>(&env), &args) != JNI_OK) { > std::abort(); > } > auto const c1 = env->FindClass("java/lang/Class"); > handleError(env); > auto const id = env->GetMethodID(c1, "newInstance", "()Ljava/lang/Object;"); > handleError(env); > auto const c2 = env->FindClass("java/lang/Object"); > handleError(env); > env->CallObjectMethod(c2, id); > handleError(env); > } Workaround: > Call via JNI the suggested replacement of clazz.getDeclaredConstructor().newInstance() instead of the deprecated java.lang.Class.newInstance(). Change-Id: I85ff7102a18b98561f188e609873753546bc050d Reviewed-on: https://gerrit.libreoffice.org/71240 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ib4b6031b31500a8a2086721124b5b8f554f7c1c5 Reviewed-on: https://gerrit.libreoffice.org/71307 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Icd00e2aaa5932564668cd12ce4ee63aecc34419a Reviewed-on: https://gerrit.libreoffice.org/71305 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
so if that's active fallback to creating a vector of simple pams Change-Id: I282bd9f9675985ddbd88ba088aee81609e14d101 Reviewed-on: https://gerrit.libreoffice.org/71345 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
When 'QFileDialog::Directory' is set, the native Plasma QFileDialog does not consider the clicked directory to be selected, but rather the base directory shown in the dialog, s. https://bugs.kde.org/show_bug.cgi?id=406464 . Therefore don't set the option when in a KDE Plasma desktop environment (which the kde5 VCL plugin also doesn't do). This works around the above issue in the Plasma desktop integration. Change-Id: Ib3d0978ab56b6e50ee45f7ad997ec051b35faf54 Reviewed-on: https://gerrit.libreoffice.org/71223 Tested-by: Jenkins Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 9fc0dbcd) Reviewed-on: https://gerrit.libreoffice.org/71274Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de>
-
- 25 Nis, 2019 6 kayıt (commit)
-
-
Milan Crha yazdı
as noted here: https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00016.html wrt: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 Change-Id: I88f900b3adf12de545b1d2d16da67eae22fde748 Reviewed-on: https://gerrit.libreoffice.org/71282Reviewed-by:
-
Christian Lohmaier yazdı
Change-Id: I28e8d8e4ab940ae838fc555702b5580dc76931dd (cherry picked from commit 98213754)
-
Christian Lohmaier yazdı
Change-Id: Ib1d4c660ff8578d86dc2dddb1aeb55b95f127cb8 (cherry picked from commit 9575aa3b)
-
Ilmari Lauhakangas yazdı
* Update helpcontent2 from branch 'libreoffice-6-2' - tdf#124725 use window.location.pathname So any backslashes will be forward instead. Change-Id: I92aa4e0e6cb599431ba16da5bc481f5ad3877481 Reviewed-on: https://gerrit.libreoffice.org/71124Reviewed-by:Olivier Hallot <olivier.hallot@libreoffice.org> Tested-by:
-
Mike Kaganski yazdı
It seems that wusa.exe would fail with error code 0x80080005 if launched too soon after WU service was sent a stop control (which was added in tdf#123832). Change-Id: I470a8a8e933e8a0cd6208c095ed63c1761b3b434 Reviewed-on: https://gerrit.libreoffice.org/71045 Tested-by: Jenkins Reviewed-by:
Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/71062Reviewed-by:
-
Mike Kaganski yazdı
... which was obviously omitted in commit 6b678c13, which introduced the correct value of 0x0491 (1169) in addition to the pre-existing 0x043C (1084). The new value is used when user sets relevant entry in Region and Language control panel applet (intl.cpl); having the old value in MSI summary information blocks auto-detection of proper installer language. [MS-LCID] Appendix A mentions that the new code is available since Win7, so we are good with the fix. [MS-LCID] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9cCo-authored-by:
Eike Rathke <erack@redhat.com> Change-Id: Ic03b0e8eaf145c662fde48846cd5307e362d4d63 Reviewed-on: https://gerrit.libreoffice.org/71242Reviewed-by:
-
- 24 Nis, 2019 5 kayıt (commit)
-
-
Muhammet Kara yazdı
We can't use the MOZ API anymore. Let's disable it instead of showing a broken search window. Then we can spend some time on moving on instead of answering the -This is not working!- bug reports. Change-Id: Ice10bde804d1d9a7a13cd4781813fc794b1b0967 Reviewed-on: https://gerrit.libreoffice.org/67917Tested-by:
Muhammet Kara <muhammet.kara@collabora.com> Tested-by: Jenkins Reviewed-by:
-
Katarina Behrens yazdı
Use-case here is .ods document with 16k tracked changes. For every tracked change, Calc generates a formula cell. For every formula cell, clipboard content is queried (via ScDocument::IsClipboardSource, ScModule::GetClipDoc respectively). This is dog-slow on Windows Therefore don't query clipboard content while the document is in the process of being loaded. Instead return from ScDocument:: IsClipboardSource early and return 'false' because at this point of time it can't be reliably determined whether this doc is a clipboard source anyway Change-Id: If5aa62cbfb62fb326a3c73b4d9be839127d3c03b Reviewed-on: https://gerrit.libreoffice.org/71121Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by:
-
Luboš Luňák yazdı
b1118883 changed msfilter to use GraphicFilter::ImportUnloadedGraphic() to lazy-load images from the document. However, that function in some cases simply reads the entire rest of the passed SvStream, which in this case is the entire .xls file. And the document from tdf#124828 is ~50MiB and contains ~4000 images => 100+ GiB memory required. Change-Id: I74926383204ec642eabb28b62e2cf2e1ff8054a9 Reviewed-on: https://gerrit.libreoffice.org/71136 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit af84fc9d) Reviewed-on: https://gerrit.libreoffice.org/71221Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Caolán McNamara yazdı
interate and recurse through their contents for name collision check Change-Id: Ide7d1d051f6b9420b7ef7b3f6bed669dbde5697a Reviewed-on: https://gerrit.libreoffice.org/71078 Tested-by: Jenkins Reviewed-by:
-
Tomaž Vajngerl yazdı
This should prevent the crash - at least it did for me AFAICS. Change-Id: I489264d8054e6577b948b0ab307c863d3140788a Reviewed-on: https://gerrit.libreoffice.org/70755 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 9f392d0c) Reviewed-on: https://gerrit.libreoffice.org/70914Reviewed-by:
-
- 23 Nis, 2019 7 kayıt (commit)
-
-
Miklos Vajna yazdı
Regression from commit 59339dec (tdf#105150 PPTX import: try harder to handle <p:sp useBgFill="1">, 2017-01-06), the problem was that we gave a white solid fill to a shape which is meant to be transparent. Fix the problem by limiting the scope of the mentioned commit to solid colors only, and also extend to code to look for background fill from the masterpage as well. This allows not hardcoding the white solid fill and leaves the fill style of shapes as transparent where the slide background is a bitmap or other more complex fill type. (cherry picked from commit 943a534a) Change-Id: I0063e88d510250652d2b14856df3bd431681422d Reviewed-on: https://gerrit.libreoffice.org/71115 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
because NSS_Init wasn't called first Change-Id: Ib1b4c950dc2773af1fea7b64339b86566ee412e7 Reviewed-on: https://gerrit.libreoffice.org/70949Reviewed-by:
-
Tomaž Vajngerl yazdı
IsPaintTransparent() is preventing to paint the background but not sure why this is needed. removing this condition doesn't seem to have any ill effects. Reviewed-on: https://gerrit.libreoffice.org/70855 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: If03c6ff8043bb39f2efdf4cde19d8277886bf36f Reviewed-on: https://gerrit.libreoffice.org/70677 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I831d0dd62d0b28dc19b90b03de3eaa159984347c Reviewed-on: https://gerrit.libreoffice.org/70923 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Commit 3e009203 (tdf#112318 sd opengl: fix lack of initial animation, 2019-04-05) enabled processing of idle events between two updates of the slideshow to help OpenGL, which uncovered a problem with media shapes. On one hand, slideshow::internal::ViewMediaShape::implInitializePlayerWindow() calls EnablePaint(false) on the media window. OTOH, vcl::Window::ImplCallPaint() handles mbPaintDisabled by invalidating the relevant area of the window, which causes a paint<->invalidate loop. Fix the problem by nominally still enabling paints on the media window: nothing will change in practice (since the actual media overlay will be on top of it), but this way the loop goes away. mbPaintDisabled is handled like this since the initial import, the media window flag was added much later, so it makes more sense to adapt the later. (cherry picked from commit d7f4f565) Conflicts: slideshow/source/engine/shapes/viewmediashape.cxx Change-Id: Ib89b68d93aa9d09dbcad33eb6e75a8a25ef1b752 Reviewed-on: https://gerrit.libreoffice.org/70886 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Julien Nabet yazdı
Change-Id: Ie3e713786b096657571d0abe0806b1d45d2b5341 Reviewed-on: https://gerrit.libreoffice.org/69585 Tested-by: Jenkins Reviewed-by:
Andras Timar <andras.timar@collabora.com> (cherry picked from commit 1971c61a) Reviewed-on: https://gerrit.libreoffice.org/69645Reviewed-by:
-
- 20 Nis, 2019 2 kayıt (commit)
-
-
Michael Stahl yazdı
Change-Id: I3fe30de8140dce3d81cdfae7d41e0bd465b1d5f4 Reviewed-on: https://gerrit.libreoffice.org/70879 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
... that happens when you accept a delete redline (or reject an insert redline) with such end pos. The problem is that first a DeleteRange() will move the anchor position onto the table node (because check in SwUndoSaveContent::DelContentIndex() is surprisingly asymmetric and so the fly not deleted by the previous bugfix), then DelFullPara() creates a second SwUndoDelete then deleting the fly crashes because its anchors was moved. The code in lcl_AcceptRedline() / lcl_RejectRedline() doesn't make much sense (but always was like this), if we just call DeleteFullPara() once instead, the problem is avoided, and we don't even have to worry about why DelContentIndex() is so asymmetric (is "selection direction" really a meaningful concept?). Reportedly this started to crash with commit e07feb94, previously it was just wrong. Change-Id: Ib3d4b31e0255a6f4e7b49b40f204dec168ea3006 Reviewed-on: https://gerrit.libreoffice.org/70836 Tested-by: Jenkins Reviewed-by:
-
- 18 Nis, 2019 5 kayıt (commit)
-
-
Stephan Bergmann yazdı
...merging <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 2c72c8b2c9beb4995c5a57b4eedf05f6c7ff248d> "Disable OpenCL by default for LO Flatpak": "This fixes <https://github.com/flathub/org.libreoffice.LibreOffice/issues/82> 'LibreOffice cannot be launched with flatpak in normal mode on ASUS E402YA', where LO was found hanging (for as yet unclear exact reasons) on one machine when OpenCL was enabled. There have been other issues with OpenCL like <https://bugzilla.redhat.com/show_bug.cgi?id=1432468> 'LibreOffice crashes on startup' on Fedora, so for a Flatpak build targeting a wide range of distros, the conservative approach is probably to disable OpenCL by default and have users explicitly enable it instead." Change-Id: I887137d1ceb5d97f007f09cba636c59f197f1bff Reviewed-on: https://gerrit.libreoffice.org/70928 Tested-by: Jenkins Reviewed-by:
-
Katarina Behrens yazdı
Two use-cases here in kde5backend 1) kde or qt vclplug has already started qt event loop => just use this loop to read KDE settings 2) no qt event loop runs (we're most likely in gtk3_kde5 vclplug) => start a new event loop, read the settings and stop it In case 2) letting qt event loop run means subsequently all UI ops need to happen in main thread. This is problematic to enforce in non-qt-based vclplugs In both cases, cache those settings for future use - the assumption is, most of them are static during a session anyway. Change-Id: Ifa203f4cdb9a753db808f945762fb131ee83393c Reviewed-on: https://gerrit.libreoffice.org/70808 Tested-by: Jenkins Reviewed-by:
-
Tamás Zolnai yazdı
Change-Id: I00df0022a20e83d76484d7c6e7b903ecd3c54aa0 Reviewed-on: https://gerrit.libreoffice.org/70347 Tested-by: Jenkins Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 84d4125b) Reviewed-on: https://gerrit.libreoffice.org/70454Reviewed-by:
-
Caolán McNamara yazdı
which for the common case avoids the narrowing of hidpi outputdevices through non-hidpi bitmaps Change-Id: Ibdc004a0946e8cb118818e58a01e5791c869353a Reviewed-on: https://gerrit.libreoffice.org/69930 Tested-by: Jenkins Reviewed-by:
-
David Vogt yazdı
In old versions of LO/AOO, separator style was defaulting to a solid line. When you have an old document that doesn't have the style set explicitly, the line would disappear. Since newer versions explicitly set the style, we should set the default to what it was before. Change-Id: I8dacea75fcf2f95f9bc145442b22ab0d173e7c5a Reviewed-on: https://gerrit.libreoffice.org/69167 Tested-by: Jenkins Reviewed-by:
-
- 16 Nis, 2019 6 kayıt (commit)
-
-
Michael Stahl yazdı
nLen may be larger than the master SwTextFrame, but its follow can't have negative offset. (regression from 0acde751) Change-Id: I6177c748480cdf61e8f15a7032ba52d3ae2ea52c Reviewed-on: https://gerrit.libreoffice.org/70816 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
... due to change of default argument; the XHTML export is calling it from SwXTextPortion::getString(). This is complicated a bit by a bunch of changes to GetExpandText() callers. (regression from bf488abb) Change-Id: I0b1e10e17c8f3824d6fa1f21fc74cc59b310474f Reviewed-on: https://gerrit.libreoffice.org/70791 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
OpenGL just sets GtkSalGraphics::bNeedPixmapPaint to true, and the problem is specific to that flag (can be also enabled via SAL_GTK_USE_PIXMAPPAINT=1). Most other widgets are painted correctly in the GL case as they pass around a drawable explicitly; do the same for ControlType::ListNode as well in the GL case. The non-GL case still needs to go via the pixmap render macros to have correct position, leave that unchanged. (cherry picked from commit fb9c7e31) Change-Id: Ia82a6772e357b434d706e58664be3a8427e91669 Reviewed-on: https://gerrit.libreoffice.org/70762 Tested-by: Jenkins Reviewed-by:
-
Dennis Francis yazdı
ScDPCache field labels, else on export to xlsx, Excel will fail to load the pivot table due to case-insensitive duplicate field labels in the pivotCacheDefinition1.xml. This could be done just for xlsx export filter, but we do normalization in dpcache.cxx anyway and it would not hurt if we do a case-insensitive normalization here. The private member ScDPCache::AddLabel had code duplication and more importantly it is called in loop for every label in the database so results in O(n^2) time complexity where n is the number of labels, so removed it to reuse normalizeLabels() at the only call-site. Also added a unit test that checks case-insensitive normalization. Change-Id: Id563dee232a98a2aea9f4fc29254f6942e1c5ba7 Reviewed-on: https://gerrit.libreoffice.org/70498Reviewed-by:
Dennis Francis <dennis.francis@collabora.com> (cherry picked from commit 238cadd3) Reviewed-on: https://gerrit.libreoffice.org/70703
-
Dennis Francis yazdı
under colFields tag if there is only one data-field. <colFields count=[*]> <field x="-2"/> <--- -2 indicates data field. </colFields> Excel 2013/2016 seems to crash at the presence of '<field x="-2"/>' in colFields when there is only one data-field. Additionally, call GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) on all ScDPObject's in non-const mode, so that the internal pOuput member of ScDPObject is populated. Otherwise the const GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) call always return an invalid range. This also adds 2 unit tests :- 1. To check the presence of <field x="-2"/> in colFields tag if there are more than one data-fields. 2. To ensure the absence of <field x="-2"/> in colFields tag if there is only one data-field. Change-Id: I8f470bd1ab883f73586f04a3fcc30e3fbf948c4a Reviewed-on: https://gerrit.libreoffice.org/70316 Tested-by: Jenkins Reviewed-by: -
Michael Weghorn yazdı
Store the file extension associated with the named filters in a map, and use that information to set the default file extension in QFileDialog accordingly if the corresponding checkbox in the dialog is enabled. Change-Id: I66f4f35da5d4378ac6337429e39260a4ed710a24 Reviewed-on: https://gerrit.libreoffice.org/67392 Tested-by: Jenkins Reviewed-by:
-
