- 23 May, 2019 6 kayıt (commit)
-
-
Michael Stahl yazdı
The remaining problem is that with the previous commit, the layout stops at some point and everything is crammed into the next-to-last page, with the following symptom: warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 This is apparently because of some very funny recursion that goes in circles until it formats some part of the "outer" table again. 0 SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642 ^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905 1 SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372 2 SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790 3 SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247 4 SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790 5 SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247 6 SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790 7 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247 8 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544 ^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332 10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313 11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point 12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479 ^ m_pLower -> 991 - SwRowFrame 13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614 14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691 15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082 ^ m_pFollow -> 905 - top-level SwTabFrame 16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504 17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372 18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790 ^ 866 - top-level SwTabFrame 19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483 20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375 21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380 The first attempt was to add a TextFrameLockGuard around the pFrame->MakeAll() call in PrepareMake(), with corresponding test in SwTabFrame::MakeAll() ... but a similar problem still occurred, just now on page 18 instead of page 12. Another idea is to prevent PrepareMake() from formatting the SwTableFrame's follow *again*; it was already formatted by SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc(). With this, we get 23 pages for the bugdoc, same as before that commit: (regression from 18765b9f) Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de Reviewed-on: https://gerrit.libreoffice.org/72799Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Caolán McNamara yazdı
Change-Id: I8d5bb318674311b1e21c6fdf487d69609af344a5 Reviewed-on: https://gerrit.libreoffice.org/72725 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
This is some copypasta, apply the same fix. Change-Id: I096594f6d54fef68e63c982c2963499d24af6d15 Reviewed-on: https://gerrit.libreoffice.org/72798 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The problem is that with the change in SwFlowFrame::MoveBwd(), a SwTextFrame in a table may move backwards during MakeAll(); if the next frame of the moved frame, and the "this" frame in PrepareMake(), is a SwTabFrame, then the pFrame->FindNext() will return not this SwTabFrame, but the first SwTextFrame *inside* the SwTabFrame - hence the iteration will never meet the "pFrame == this" termination condition and the SwTabFrame remains unformatted; this warning is printed: warn:legacy.osl:6874:6874:sw/source/core/layout/calcmove.cxx:296: :-( Layout unstable (this not found). (regression from 18765b9f) Change-Id: I68207ba9cf68cd5abe51d647cb757176261eda40 Reviewed-on: https://gerrit.libreoffice.org/72797 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
at paragraph deletion, because it's more annoying, than helpful. Note: ODT file saving copies the page break into the deleted paragraph, but not the DOCX export. See also commit 22639148 "tdf#54819 change tracking: keep paragraph style after full deletion" Reviewed-on: https://gerrit.libreoffice.org/72611 Tested-by: Jenkins Reviewed-by:
László Németh <nemeth@numbertext.org> (cherry picked from commit 23c159d9) Change-Id: Ib9cbb58266a9067b1f8fb1f15bfdf9ff752a1ba4 Reviewed-on: https://gerrit.libreoffice.org/72682 Tested-by: Jenkins Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Jim Raykowski yazdı
...and keep the 'More Characters...' button as first focused Change-Id: Iab4cb00aaed9250f0cc7f35f27af48eb326f2a48 Reviewed-on: https://gerrit.libreoffice.org/71834 Tested-by: Jenkins Reviewed-by:
Jim Raykowski <raykowj@gmail.com> (cherry picked from commit caa6de6c) Reviewed-on: https://gerrit.libreoffice.org/72772Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
- 22 May, 2019 18 kayıt (commit)
-
-
Michael Stahl yazdı
Fixes CVE-2019-5435. It looks like this is not a problem on 32-bit Windows because fortunately we don't use /LARGEADDRESSAWARE flag to set IMAGE_FILE_LARGE_ADDRESS_AWARE... but on 32-bit Linux the user-space VM is 3GB so an exploit might be possible. Apparently there's no code in LO that uses the CURLU_URLENCODE flag. The other one, CVE-2019-5436, doesn't matter because we disable tftp. Change-Id: I0d4f087befa5a3c4fb21ec36761dad68932425d9 Reviewed-on: https://gerrit.libreoffice.org/72732 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
at paragraph join, because file saving or changing to Hide Changes mode don't affect this. Also adding page breaks to every paragraph of a deletion is much more annoying, than helpful. See also commit 1bbbe57d "change tracking: show layout changes at paragraph join" Reviewed-on: https://gerrit.libreoffice.org/72469 Tested-by: Jenkins Reviewed-by:
-
Julien Nabet yazdı
Regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=3208fcb3a36d75d6290d9c548430682f153b09db Change-Id: I8f85f0a5838df87671ecb9bdb5751b7ec43c09ea Reviewed-on: https://gerrit.libreoffice.org/72701 (cherry picked from commit ff251f4a) Reviewed-on: https://gerrit.libreoffice.org/72777Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> Tested-by:
-
Michael Weghorn yazdı
Since 'QObject' and the 'Q_OBJECT' macro are used, the corresponding header needs to be included. Without the include and forward-declaration given here, the compiler doesn't know about 'QObject' and 'QAction' which are used further below, unless another header that takes care of this is included before 'QtMenu.hxx'. The error could be provoked e.g. by moving the '#include <Qt5Menu.hxx>' in front of all other includes in 'vcl/qt5/Qt5Frame.cxx'. Change-Id: I76c15eb445cbe26774d6e4177e12c93658daf0ad Reviewed-on: https://gerrit.libreoffice.org/65130 Tested-by: Jenkins Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 4ad69820) Reviewed-on: https://gerrit.libreoffice.org/72733Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Michael Weghorn yazdı
As the Qt documentation for 'QFileDialog::supportedSchemes' says, setting supported schemes to a non-empty list restricts the available options: "Setting this property allows to restrict the type of URLs the user will be able to select. It is a way for the application to declare the protocols it will support to fetch the file content. An empty list means that no restriction is applied (the default)." The call to 'QFileDialog::setSupportedSchemes' was copied over from the gtk3_kde5 VCL plugin in commit 6196b729, where it had been added by commit f1b60bd6 "Support opening of (some) remote URLs through the KDE file dialog". Since only either all schemes (if nothing explicitly set) or a whitelist of supported locations seems to be possible (s.a. the Phabricator changes referenced in the commit message of commit f1b60bd6), add the "" scheme that makes removable devices shown -- while there doesn't seem to be an official documentation on the available schemes, at least not in KFileWidget's API documentation [1]. A quick test with all new available options after removing the call to 'QFileDialog::setSupportedSchemes' altogether indicated that opening and saving files there doesn't work reliably in all cases, so rather excplicitly add the "" scheme rather than claiming support for all schemes (including e.g. "timeline", "search", "remote", "trash"). [1] https://api.kde.org/frameworks/kio/html/classKFileWidget.html Change-Id: I89dc37d0f06d280e5dd599f90768c13e8edb915b Reviewed-on: https://gerrit.libreoffice.org/71320 Tested-by: Jenkins Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de> (cherry picked from commit 2c69c93f) Reviewed-on: https://gerrit.libreoffice.org/72750Reviewed-by:
-
Michael Stahl yazdı
... and also convert KDE5FilePicker. And Qt5Frame. The UNO methods in Qt5FilePicker/KDE5FilePicker have to ensure that the thread actually owns SolarMutex, because if RunInMainThread() is called without that it will deadlock. Change-Id: Ie4d2f494ac81c799ec7c9a3acb3a9b0f77bb6361 Reviewed-on: https://gerrit.libreoffice.org/68357 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
This prints a warning "Cannot create children for a parent that is in a different thread"; let's fix it before it causes another hard to debug crash. 0 check_parent_thread(QObject*, QThreadData*, QThreadData*) (parent=parent@entry=0xe88ca0, parentThreadData=<optimized out>, currentThreadData=<optimized out>) at kernel/qobject.cpp:781 1 check_parent_thread (currentThreadData=<optimized out>, parentThreadData=<optimized out>, parent=0xe88ca0) at kernel/qobject.cpp:822 2 QObject::QObject(QObject*) (this=0x9ed2e80, parent=0xe88ca0) at kernel/qobject.cpp:810 3 Adwaita::GenericData::GenericData(QObject*, QWidget*, int) () at /usr/lib64/qt5/plugins/styles/adwaita.so 4 Adwaita::WidgetStateEngine::registerWidget(QWidget*, QFlags<Adwaita::AnimationMode>) () at /usr/lib64/qt5/plugins/styles/adwaita.so 5 Adwaita::Animations::registerWidget(QWidget*) const () at /usr/lib64/qt5/plugins/styles/adwaita.so 6 Adwaita::Style::polish(QWidget*) () at /usr/lib64/qt5/plugins/styles/adwaita.so 7 QWidget::event(QEvent*) () at /lib64/libQt5Widgets.so.5 8 Qt5Widget::event(QEvent*) (this=0x7321790, pEvent=0x7f90c27d3750) at vcl/qt5/Qt5Widget.cxx:416 9 QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 10 QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 11 QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7321790, event=0x7f90c27d3750) at kernel/qcoreapplication.cpp:1047 12 QWidget::ensurePolished() const () at /lib64/libQt5Widgets.so.5 13 QWidget::setVisible(bool) () at /lib64/libQt5Widgets.so.5 14 Qt5Frame::SetModal(bool) (this=0x9f411b0, bModal=true) at vcl/qt5/Qt5Frame.cxx:482 Change-Id: Ib6b4d1ee859dfce650422a6c7860abf2eb2686f1 Reviewed-on: https://gerrit.libreoffice.org/68356 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
During QFileDialog dtor, QSocketNotifier::setEnabled(false) is called, but it doesn't do anything other than print a stupid warning and so it's still registered and later it receives events after it's dead. 0 QSocketNotifier::setEnabled(bool) (this=this@entry=0x991c058, enable=enable@entry=false) at kernel/qsocketnotifier.cpp:240 1 QInotifyFileSystemWatcherEngine::~QInotifyFileSystemWatcherEngine() (this=0x991c030, __in_chrg=<optimized out>) at io/qfilesystemwatcher_inotify.cpp:260 2 QInotifyFileSystemWatcherEngine::~QInotifyFileSystemWatcherEngine() (this=0x991c030, __in_chrg=<optimized out>) at io/qfilesystemwatcher_inotify.cpp:258 3 QObjectPrivate::deleteChildren() (this=this@entry=0x991c240) at kernel/qobject.cpp:1997 4 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1025 5 QFileSystemWatcher::~QFileSystemWatcher() (this=0x9641b60, __in_chrg=<optimized out>) at io/qfilesystemwatcher.cpp:277 6 QObjectPrivate::deleteChildren() (this=this@entry=0x2a30130) at kernel/qobject.cpp:1997 7 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1025 8 QThread::~QThread() (this=0x2a079b8, __in_chrg=<optimized out>) at thread/qmutex.h:217 9 () at /lib64/libQt5Widgets.so.5 10 QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) (pointer=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:52 11 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() (this=0x98aa4d8, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:107 12 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:884 13 QFileSystemModel::~QFileSystemModel() () at /lib64/libQt5Widgets.so.5 14 QObjectPrivate::deleteChildren() (this=0x97bab00) at kernel/qobject.cpp:1997 15 QWidget::~QWidget() () at /lib64/libQt5Widgets.so.5 16 QFileDialog::~QFileDialog() () at /lib64/libQt5Widgets.so.5 17 std::default_delete<QFileDialog>::operator()(QFileDialog*) const (this=0x9770f90, __ptr=0x926e970) at /usr/include/c++/8/bits/unique_ptr.h:81 18 std::unique_ptr<QFileDialog, std::default_delete<QFileDialog> >::~unique_ptr() (this=0x9770f90, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:274 19 Qt5FilePicker::~Qt5FilePicker() (this=0x9770ed0, __in_chrg=<optimized out>) at vcl/qt5/Qt5FilePicker.cxx:155 Change-Id: Iddfa3d44de59e1760e20a389566d9e6815ab26f7 Reviewed-on: https://gerrit.libreoffice.org/68355 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The problem with the current approach of transferring calls to the main thread with Q_EMIT signals is that if the code that should run in the main thread needs SolarMutex, then the non-main-thread must use SolarMutexReleaser - but then the main thread will run not only the call that is needed right now, but will potentially process all pending events, and the other thread hasn't prepared for that. We need the inter-thread feature of Qt::BlockingQueuedConnection and the non-queued feature of Qt::DirectConnection, but this combination doesn't appear to exist. So the SolarMutexReleaser needs to go - but then the main thread does need SolarMutex for some things, and hence we need to trick it into believing it has SolarMutex with the m_bNoYieldLock hack. Then it becomes apparent that the main thread may be blocked on either Qt events, which is fine, or on the SalYieldMutex's m_aMutex, which will never be released now. So the main thread must never block on m_aMutex; the alternative is to use the same approach as the osx code (and, in a somewhat different form, the svp code), and add some condition variables on which the main thread can block if it fails to acquire the m_aMutex immediately. It's even possible to do this in a somewhat generic way with lambdas. This does appear to work, but it makes the Q_EMIT approach entirely untenable, because now the main thread will be blocked on the condition variable and the non-main-thread will be blocked until the Qt event is processed. Reviewed-on: https://gerrit.libreoffice.org/68232 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
should only disable/enable its parent container Change-Id: I002a525b7ac4c178c3db7efc06848315afb785e0 Reviewed-on: https://gerrit.libreoffice.org/72624 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
This was added in commit 2fcf3a87 (ooxml: preserve gradient shape fill, 2014-01-31), and assumes that the theme colors can be preserved, as the theme definition is grab-bagged as well. But the theme is grab-bagged only for DOCX, not for PPTX, so skip gradient grab-bag for PPTX, otherwise the gradient would refer to incorrect colors in the theme. Change-Id: I98e1c67d4b10e68916f81dd7fc508eb4146d506b Reviewed-on: https://gerrit.libreoffice.org/67386Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/72681Reviewed-by:
-
Michael Weghorn yazdı
Take over missing case from 'KDE5FilePicker::initialize' to 'Qt5FilePicker::initialize' and make 'Qt5FilePicker::addCustomControl' virtual, so that the subclass's implementation is called in the 'initialize()' method (in particular to avoid adding another autoextension checkbox). Drop the 'KDE5FilePicker::initialize' so that the base class implementation is used, which now does the same thing. Add 'override' keyword in KDE5Filepicker.hxx. Change-Id: Id151a4d4862af4275f6c21c6537a79c52e3ed513 Reviewed-on: https://gerrit.libreoffice.org/68059 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Add an option to Qt5FilePicker constructor to say whether the QFileDialog should be a native one or not, since 'QFileDialog::selectFile' does not preselect the correct name in the native dialog any more if the 'QFileDialog::DontUseNativeDialog' option has ever been set, i.e. QFileDialog fileDialog; fileDialog.setOption(QFileDialog::DontUseNativeDialog); fileDialog.setOption(QFileDialog::DontUseNativeDialog, false); fileDialog.selectFile("test.txt"); will not properly set the name in the native file dialog, which broke 'setDefaultName' for the KDE5FilePicker. This makes it work again, even though I think that the underlying issue is a Qt bug (s. https://bugreports.qt.io/browse/QTBUG-73682 ). Change-Id: I99a1e7c97d594925d600fa8eaf3303f9013551c2 Reviewed-on: https://gerrit.libreoffice.org/68058 Tested-by: Jenkins Reviewed-by: -
Michael Weghorn yazdı
Use the custom controls widgets from the parent class Qt5FileWidget and drop the own class members that were used for this. Also call the base class's implementations for the methods that interact with the custom controls. Since the native Plasma/kde5 file picker handles automatic file extensions by itself while the non-native qt5 one does not, the methods in KDE5FilePicker only forward those method calls that are not related to the corresponding control ('CHECKBOX_AUTOEXTENSION'). Change-Id: Ia2de3211ffba7814683914a5e629208b19b2ed82 Reviewed-on: https://gerrit.libreoffice.org/68057 Tested-by: Jenkins Reviewed-by: -
Grzegorz Araminowicz yazdı
preserving SmartArt allows editing it in PowerPoint after saving as pptx file * moved common parts for docx and pptx export to oox/drawingml * fixed export tests that expected shapes on output Change-Id: I3e70a9f4177bebf5e1671232f4cd0ef0e7212626 Reviewed-on: https://gerrit.libreoffice.org/69598 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
At least building on Flathub makes presence of this information a hard requirement now (see <https://blogs.gnome.org/hughsie/2019/03/28/ new-appstream-validation-requirements/> and witness the failed <https://flathub.org/builds/#/builders/32/builds/3597>). The suggested way to calculate that information is via the form at <https://hughsie.github.io/oars/generate.html>, which I filled in as follows (the answers I selected are prefixed with "=>"): > By answering all the questions you can generate AppStream-compatible markup > for the upstream AppData file. > > If the user is able to "enable" NSFW or "adult" content, then this should be > included in the assessment even if it is turned off by default. > > What type of component are you generating content for: => Application that can connect to the Internet > OARS has multiple versions, and the newer versions include more questions > involving specific cultural and religious sensitivities. What version of OARS > metadata do you want to produce: => 1.0 (works with all clients) > Advertising > > Defined as the activity of producing advertisements for commercial products or > services. > > For example, this would include banners showing the Coca-Cola logo shown in a > Soccer game. => None > Gambling > > Defined as taking a risky action in the hope of a desired result. > > For example, this would include spinning a wheel to get in-app credits. => None > In-App Purchases > > Defined as items or points that a user can buy for use within a virtual world > to improve a character or enhance the playing experience. => None > Online Text-only Messaging > > Defined as any messaging system connected to the Internet. => None > Online Audio and Video Messaging > > Defined as any multimedia messaging system connected to the Internet. => None > Contact Details > > Defined as sharing identifiable details with other users to allow out-of-band > communication. => None > Information Sharing > > Defined as sharing information with a legal entity typically used for > advertising or for sending back diagnostic data. > > For example, this would include sending your purchasing history to Amazon. => None > Location Sharing > > Defined as sharing your physical real-time location. > > For example, this would include uploading the GPS co-ordinates of your current > location. NOTE: This does not include heuristic based location services, e.g. > GeoIP and others. => None > The following markup can be pasted into the existing application AppData file. > > <content_rating type="oars-1.0" /> Change-Id: I063484d8031892c20f88999c5a9beeae3666511c Reviewed-on: https://gerrit.libreoffice.org/72581 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 0a136095) Reviewed-on: https://gerrit.libreoffice.org/72667Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Katarina Behrens yazdı
Change-Id: I6bdb9aa89a8a5181b096f47f90ab6fb5711e7447 Reviewed-on: https://gerrit.libreoffice.org/69541 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
This includes some not-so-nice lifetime handling of the button "clicked" connection handling. I decided to keep the code in one place, simply always forcing a disconnect on show, instead of a more "optimized" code version in SetFrame. First we try to get the icon from the system theme, but use LO's own icon theme as a fallback. Change-Id: Ic0459623ec907b9a54bef4670bf65cf587cd47ea Reviewed-on: https://gerrit.libreoffice.org/71784Tested-by:
Jenkins <ci@libreoffice.org> Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 8ea988f5) Reviewed-on: https://gerrit.libreoffice.org/71931 Tested-by: Jenkins Reviewed-by:
-
- 21 May, 2019 16 kayıt (commit)
-
-
Michael Weghorn yazdı
Take over functionality from 'KDE5FilePicker::addCustomControl' that has not been implemented in qt5 one yet. Change-Id: I9690e163b3b739bfec6813d9a4e1e0170b730187 Reviewed-on: https://gerrit.libreoffice.org/68056 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Directly access member 'm_pExtraControls' from parent class Qt5FilePicker for managing custom widgets, rather than maintaining an own one. This is meant as an intermediate step, further refactoring will follow. Change-Id: I0568d3db68dc24042e198d36f4b5e49608f93a0e Reviewed-on: https://gerrit.libreoffice.org/68055 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Turn existing functions in Qt5FilePicker into protected static class methods and reuse them in KDE5FilePicker. The qt5 implementation covers everything that kde5 had, and a little more (e.g. covers case 'ControlActions::DELETE_ITEM' in 'handleSetListValue' as well). Reviewed-on: https://gerrit.libreoffice.org/68054 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Base class's 'Qt5FilePicker::cancel' already does nothing just the same way. Change-Id: Ie125d117f27849b29f082c72e320c1021e81163e Reviewed-on: https://gerrit.libreoffice.org/68053 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
The non-native QFileDialog automatically adds the file extension for the selected filter in the listbox, therefore it was stripped from the filter title in 'Qt5FilePicker::appendFilter'. Since the native Plasma/kde5 file dialog does not add it automatically, introduce a new member 'm_bShowFileExtensionInFilterTitle' to specify whether or not to strip the extension and set it accordingly in KDE5FilePicker (so that it continues to show e.g. "ODF Text Document (.odt)" instead of just "ODF Text Document"). This allows for KDE5FilePicker to reuse the base class implementation and thus to drop all related own members and methods. Change-Id: Icfb77d065160d3f655e3e89ad69de4195781373a Reviewed-on: https://gerrit.libreoffice.org/68052 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Base class's 'Qt5FilePicker::setDescription' does the same, namely nothing. Change-Id: Ie89a1e1edaf20c49a1b16f43000a4a054b21f3b2 Reviewed-on: https://gerrit.libreoffice.org/68051 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Use base class's 'Qt5FilePicker::getDirectory' instead to reduce duplication. Strictly speaking, the 'KDE5FilePicker::implGetDirectory' implementation used by 'KDE5FilePicker::getDirectory' suggests that the display directory is returned rather than the selected directory, and the same method 'implGetDirectory()' was actually previously used by the 'KDE5FilePicker::getDisplayDirectory()' method as well (removed in a previous commit). The code worked fine inside KDE5FilePicker (where the native Plasma/kde5 file dialog is used) but would lead to incorrect results when used inside Qt5FilePicker, e.g. for the following scenario * open folder picker displaying $HOME that contains a directory "bar" * do a single mouse click on the "bar" directory * click "OK" The call to 'toOUString(m_pFileDialog->directoryUrl().url())' inside 'getDirectory()' would return '$HOME/bar' for the native QFileDialog on KDE Plasma 5, but '$HOME' when used with the non-native QFileDialog Anyway, the implementation inside 'Qt5FilePicker::getDirectory' works fine for both cases, so just drop the KDE5FilePicker one. Reviewed-on: https://gerrit.libreoffice.org/68050 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Base class's 'Qt5FilePicker::getDisplayDirectory' does the same. Change-Id: I835603848736a328d0cf63b0bdc87895761e229c Reviewed-on: https://gerrit.libreoffice.org/68049 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Base class's 'Qt5FilePicker::disposing' is the same. Change-Id: I91069385541a519f006d10b0580104f14beb551e Reviewed-on: https://gerrit.libreoffice.org/68048 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Change-Id: I4680cc4a8507d0d2409301b62ab81165fcfcdba1 Reviewed-on: https://gerrit.libreoffice.org/68047 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
... and related signals/slots. Those from the Qt5FilePicker base class do the same thing, except for one 'SolarMutexReleaser' that was commented out in 'KDE5FilePicker::getFiles' for no apparent reason since that line was added in commit 8fb0881a. Take over the slightly nicer syntax for the range-based for loop from 'KDE5FilePicker::getSelectedFiles' to 'Qt5FilePicker::getSelectedFiles'. Change-Id: I419f933d256f3b85eccaea85803b4890770efa24 Reviewed-on: https://gerrit.libreoffice.org/68046 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
... and related signals/slots. They are the same as in the Qt5FilePicker base class. Change-Id: I115d0daa6beace44b9c791fc892d7cf553c562bb Reviewed-on: https://gerrit.libreoffice.org/68045 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Base class's 'Qt5FilePicker::setTitle' is the same. Change-Id: I071bf5f962c2d8b0821d78e97793c8637f5c0a1b Reviewed-on: https://gerrit.libreoffice.org/68044 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Drop the 'm_xListener' member and methods using it. The inherited Qt5FilePicker methods do the same thing. This also avoids that two methods are called when a file or filter is selected, since the 'QFileDialog::filterSelected' and 'QFileDialog::fileSelected' signals had been connected to slots in both, the qt5 and kde5 fpicker constructors. Change-Id: I60e3eda29e6497f51165e87d0c4ab2e17f209a1c Reviewed-on: https://gerrit.libreoffice.org/68043 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Drop the '_dialog' member from KDE5FileDialog and use the one from Qt5FileDialog instead. Move up 'm_bIsFolderPicker' to Qt5FilePicker. Also, move some of the related functionality from the kde5 file picker to the qt5 one, in particular take over missing parts from 'KDE5FilePicker::setMultiSelectionMode' to 'Qt5FilePicker::setMultiSelectionMode' and drop the former (now inherited from the base class). This e.g. also makes sure that only folders are available for selection when using a FolderPicker in qt5 (e.g. in the dialog to add a JRE in "Tools" -> "Options" -> "Advanced"). The functionality had only been implemented for kde5 beforehand. Since the QFileDialog is set to non-native mode in Qt5FilePicker constructor, native mode needs to be excplicitly enabled again for kde5. Since Qt's signal/slot mechanism is used to connect signals on the object in both constructors (Qt5FilePicker/KDE5FilePicker), some events will trigger multiple actions. This will be taken care of in subsequent commits, along with further refactoring. Change-Id: I245d46c12945acb91c9b52dcff5c83248ac087dd Reviewed-on: https://gerrit.libreoffice.org/68042 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
While this does not make much sense by itself as of now, it will allow to reduce code duplication in follow-up commits. Change-Id: Ie1a9bf3e516044ad5e56c526d1cf49cf1cb76f8a Reviewed-on: https://gerrit.libreoffice.org/68041 Tested-by: Jenkins Reviewed-by:
-
