Age | Commit message (Collapse) | Author |
|
Change-Id: Ib48f6c8e0424e6843d2b3a7b3558d1d8714a80ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119792
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Main problem is, that Qt::Popup grabs the focus and therefore
generates a focus-out event for the combobox, which then closes
the just shown popup window. The grab happens inside QWidget
private code and there is no way around it. But instead of
"faking" Qt::Tooltip, this uses Qt::Widget with additional flags.
Regression from commit 7e6fee830116823b9cd8e46d6962df4ea2bc1ea6
("Qt5 fix Qt::Popup window handling").
Change-Id: Ia1f8e33d98f7ec36cf1ebc350886121dfaadd658
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119691
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
I guess to get popup windows somehow working, they were matched
to Qt::ToolTip. Fixing that by removing SalFrameStyleFlags::FLOAT
from the tooltip check, resulted in rather bizarre bahviour. The
Qt::Popup window is modal, as documented, but wouldn't close when
clicked outside, like normal popups. And I neither got any mouse
button or focus events, just some leave or enter. The only way
to interact with anything again, was by clicking somewhere on the
popup where it can't take focus... and it has nothing to do with
the transition setting either.
In the end it turned out that Qt::StrongFocus prevented the mouse
events to happen. Even without it the widget accepts mouse and
keyboard focus, so nothing seems lost by omitting that for the
Qt::Popup case; hopefully...
Change-Id: Icda7bbe87268293a400fe0da551d2804675d4c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119236
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
I originally omitted this in the Qt implementation, as I couldn't
find any non-working use case.
The implementation got a bit hacky, because Qt doesn't have a non-
native way to identify different L/R modifier keys, so we must
process the X11/xkb keycode ourself, which obviously won't work on
Wayland... but most times this is not relevant, so the default
modifier notification may be good enough.
P.S. it's basically the same code then X11 and Gtk...
Change-Id: I37fbfde4a33a966b6017f3e0c280e2c7ea91e4db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119235
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This bug was "unveiled" by commit
963f252cd1ea9c268a6ced68a3454b10cbee1a89 ("Qt5/KF5 get rid
of unneeded own grahics handling"). I'm not sure why I ever came
up with that code. Eventually we would need a paint event, but at
least changing the theme correctly updated LO UI, so that seems
to be handled correctly.
Change-Id: I528b551180be184427eeeeeb2977e2b7da073ce6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119237
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: If927a834f5b5d722fc36cce40e161597af6234ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116972
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Handle SalFrame::Show's bNoActivate. The missing implementation
became visible with commit 001cf630f14109b4200b218161418350562713fa
("register navigator individually in each module that it exists in")
Change-Id: I5edf43bdf2b0460410fdd846c7698d00299088bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114116
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This was hiding tdf#141623, when I decided to implement the override
to run the kf5 VCL plugin with the qfont text rendering.
Change-Id: Id1fcd363bd77a756cb27e3a171c872ce792da5ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113956
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The QFont based rendering path directly uses the widgets size to
initialize the QImage buffer image, so do the same for the Cairo
surface, instead of the arbitrarily size of 640x480.
Change-Id: I91326dab67cbbb5e75b78b02c34eaca61ad26482
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113955
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I8e08c4e5c5b92df4cbdb8ea32f40dbde25f7afd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111433
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
with an eye to making it on-demand
Change-Id: If6cefd68a336dc6afe23591c857bd71034215b54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109929
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is in the spirit of tdf#108151, based on the information Qt
provides for the IM setting. I don't know how correct it is,
especially looking at Caolans comment 3 in that bug report
regarding the assumed validity of GtkIMContextInfo. OTOH it seems
to work well enough for my simple tests.
Some BG info: while the QInputMethod object is a global one, it's
"bound" to the focused window. So you'll get change events, when
you change the input window, with the correct IM settings for the
new one, be it a real window or just the menu bar.
To prevent unneeded flushes of buffers and language lookup, this
caches the current IM language of a window.
The language is not affected just by changing keyboard mappings,
which the bug reporter requested! It just works with a configured
input method, like fcitx or ibus (which can have keyboard mappings
too, which work correctly).
Change-Id: Ia9133edf4d1ce77d29adbfe57c180db15db0a560
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106354
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I58fb6477222a26455f5db0a7d972c46f290c085c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105261
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia8e2a7ce75bfded98e85fa583d1404710069d335
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105249
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The default background color of the frame is APPBACKGROUND, which
is matched to GetWorkspaceColor(). That color is visible in Writer
as the default document workspace background.
Originally I just saw the dark background of the button box in the
start center, and thought the workspace color in Qt is wrong and
changed it in the reverted commit, missing the change of the color
around the Writer document.
Now that the button boxes's background color isn't fixed via the
"branding" setting, we also must react to changed style settings,
so we override the DataChanged function.
This also reverts commit e0c72e31c1d455c26110c35e8780d420e17cdea6.
Regressed-by: a927e0964ba0442d53fffb22c577e54bcf183ed7
Change-Id: I62396355054523baef1197a8a8af61c2f0d29ef3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104740
Tested-by: Jenkins
Reviewed-by: Thorsten Wagner <thorsten.wagner.4@gmail.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This was uncovered by the fix for tdf#136555. The current color
for the start center button bar is too dark.
Regressed-by: a927e0964ba0442d53fffb22c577e54bcf183ed7
Change-Id: I36356117f03255cfbf1fa24a6391cb81cf1883db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104578
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I6a4a0f90239686ff1c94e1a550540223324184e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104540
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I271cc67ecf34acbf0edbda960e33315fb6a1f9dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100041
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
So I tested a lot of stuff, but missed the missing focus for new
dialog windows :-( This is IMHO a far worse problem, then the
popup, so just revert the fix.
This reverts commit 06fb3e7b7f1079c276ad2f048cd94299b4bd7006.
Change-Id: I391ad91ded90e4518ab024572d3f182769b0bcda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99451
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
I investigated the state of isWindow() and the SalFrameToTop
flags for the detached find toolbar (tdf#126607) and the Impress
presentation and the tabbed "page size" drop-down and all had the
same status (isWin: 1, flags: 12). Than I had a look at the gtk3
implementation, which just handles focus requests, if the widget
is already mapped (gtk_widget_get_mapped).
So I also dumped the visibility as the nearest equivalent in Qt to
the X11 mapped state, and that was different. In the end Qt now
also just handles the focus for already visible widgets, like
gtk3, which works for all the cases I tested (incl. tdf#125517).
And omiting either activateWindow or setFocus breaks some cases...
and I still don't understand the GrabFocusOnly flag, which is just
handled in the X11 backends at all...
Note: this doesn't happen with 7.0+, because the weld'ed version
of that control (commit 3afc718eddcd81232392d46fccc24b8ec626c8df
"rework PageSizePopup to be a PopupWindowController") doesn't
expose this bug (and also doesn't support mouse-over highlight).
Change-Id: Id085732f6a52bbc69ed47fbd3d57454756a03121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97549
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The title is self-explanatory.
The QIcon::themeName() actually uses Qt Platform Abstraction plugins, i.e.
it's aware of KDE preferred icon theme via Qt Plasma integration module.
(note that it is _currently_ broken due to KDE bug
https://bugs.kde.org/show_bug.cgi?id=402172, which causes themeName to
return empty string; however, it's being worked on)
Change-Id: Ibc7cf9ee9ae73b492046219487760561d7d2ea45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94691
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <bubli@bubli.org>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For tdf#124292, Qt's own HiDPI scaling was explicitly disabled,
but it turns out, you can't really scale QStyle painting then.
This patch series had a 2nd approach also used by Gtk+ currently,
which relied on the scaling of ths Cairo surface, which works
surprisingly good, but has to lie about the real DPI value, so
nothing is scaled twice. Also all icons are then scaled instead
of rendered with the proper resolution.
When HiDPI support in Qt is enabled, and the application is
started using QT_SCALE_FACTOR=1.25, Qt simply lowers the reported
resolution, keeps the logical DPI value of 96 and changes the
devicePixelRatio to the specified value. But LO still expects
the real DPI values and sizes, so we have to multiply a lot of
rectangles, sizes and positions.
The current result is far from perfect, which you can see with
the various graphics glitches, but it at least doesn't crash
anymore in the ControlType::Editbox sizing code.
The main problem is all the up and downscaling in the
getNativeControlRegion code, so LO knows the size of the widgets
for the correct layouting, since there seem to be no API to
get the scaled values from Qt / QStyle.
Change-Id: I687b1df6ef27724ce68326d256e9addccd72e759
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86239
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I58ce75e711504553c8fc606382866754286f1aa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89313
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is a preparatory patch for merging the initial fix for
tdf#127687, the Qt5 HiDPI scaling support, and generally to make
the style handling code a little bit more readable.
It includes:
* Moving all lcl_ Qt5Graphics_Controls functions into the class as
private functions without lcl_ prefix.
* Add three additional helpers - pixelMetric, sizeFromContents and
subControlRect - to cut down boilerplate QApplication::style()->
prefixes for the style calls everywhere.
* Drop the superfluous Qt5Frame::TriggerPaintEvent functions.
* Drop the single, broken maGeometry.nTopDecoration filling.
* Split some very long lines of nested call code by using some
intermediate variables.
* Move a Qt5Data include from hxx into cpp
Change-Id: Iae1bfafd14c4163447f3d55e2307f0f617e68a0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89751
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Qt5Frame::GetPointerState expects the cursor position relative to
the frame position.
Change-Id: Icaf7dcd8fc80d712f5138a9f9b843ccf345c5543
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89244
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...now that macOS builds are guaranteed to have std::optional since
358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as seen with qt5-qtbase-devel-5.13.2-1.fc31.x86_64:
> vcl/qt5/Qt5Frame.cxx:481:73: error: 'screenGeometry' is deprecated: Use QGuiApplication::screens() [-Werror,-Wdeprecated-declarations]
> toSize(pScreen ? pScreen->size() : QApplication::desktop()->screenGeometry(0).size()));
> ^
> /usr/include/qt5/QtWidgets/qdesktopwidget.h:79:5: note: 'screenGeometry' has been explicitly marked deprecated here
> QT_DEPRECATED_X("Use QGuiApplication::screens()") const QRect screenGeometry(int screen = -1) const;
> ^
[...]
> vcl/qt5/Qt5Frame.cxx:490:56: error: 'screenNumber' is deprecated: Use QGuiApplication::screenAt() [-Werror,-Wdeprecated-declarations]
> int nLeftScreen = QApplication::desktop()->screenNumber(QPoint(0, 0));
> ^
> /usr/include/qt5/QtWidgets/qdesktopwidget.h:75:5: note: 'screenNumber' has been explicitly marked deprecated here
> QT_DEPRECATED_X("Use QGuiApplication::screenAt()") int screenNumber(const QPoint &) const;
> ^
[...]
Change-Id: I7db00ee0e7cd7f652af4f7426f9ea0172206d485
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86660
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I93ebdcae5c39566660edbe1d5e76cc548f5b7c49
Reviewed-on: https://gerrit.libreoffice.org/84670
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is the application level equivalent of the Qt5 fix for bug
QTBUG-46626 / commit 0de4b32 ("xcb: fix issue with dialogs hidden
by other windows"), which was broken since Qt 5.4 and is just
fixed since Qt 5.12.
It is needed for some window managers, which don't know about the
WM_CLIENT_LEADER property. Both settings are the same, but just
the latter is set by older Qt5 releases. This probably isn't a
real problem, as GNOME or XFCE would use the gtk VCL plugin, but
since I already wrote the code when debugging tdf#129071, there
is also no reason to drop it (except: more code, more bugs...).
This fix is optional and needs development headers for xcb-icccm,
which can actually be compiled into Qt5. If missing configure will
just print a warning, since it's a runtime requirement and we
explicitly drop the linked Qt version symbol, so the potential
build Qt version won't matter.
Change-Id: Ifc5a8f8a40ee13779a911efb53e8b8b868614d0b
Reviewed-on: https://gerrit.libreoffice.org/84299
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This is the main fix for this bug. Qt Xcb is a little picky here.
It won't tell the window manager about the transient state, using
WM_TRANSIENT_FOR, for all Qt::WindowTypes. The QPA internal list
(see isTransient function) doesn't include the Qt::Window, which
is qt5 VCL's primary used window type.
This has two consequences:
1. LO dialogs show up in the plasma task manager as seperate
windows.
2. LO has to handle the transient state itself, instead of relying
on the window manager. This results in flickering, because LO
can just push a transient window to the top again, after the
parent window was activated and therefore drawn in front.
So this just declares all windows with parents to be dialogs.
Almost everything else should be a top-level window anyway. If
not, there is SalFrameStyleFlags::DIALOG to create a parent-less
dialog window.
Change-Id: I89a6d46fd09e4f1d1d2904e152a26733eb266079
Reviewed-on: https://gerrit.libreoffice.org/84298
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...in preparation for wholesale replacement of boost::optional with
o3tl::optional, which will be an alias for either std::optional or
boost::optional, and std::optional only has value_or.
boost::optional::value_or was added with <https://github.com/boostorg/optional/
commit/3984c9f9a157ef116cea69bc8bb20f433320eb61> "Added function value_or()",
which according to git-describe first appeared in tag boost-1.56.0. We appear
to have no strict Boost baseline (the closest we get is with
> [AC_MSG_ERROR(boost/spirit/include/classic_core.hpp not found. install boost >= 1.36)]
in configure.ac), and at least CentOS 7 TDF machine tb76 only has
boost-devel-1.53.0-27.el7.x86_64. However, any environment using Xcode < 10
that needs to make o3tl::optional fall back to boost::optional should use
--without-system-boost, and external/boost is currently at 1.69.0, so should be
safe.
ATTENTION: In isolation, this commit will break in any environment that uses
Boost older than 1.56.0. It requires the following commit introducing
o3tl::optional. (But doing these changes in individual commits was deemed more
valuable than supporting a hypothetical future git-bisect against an old Boost.)
Change-Id: Ib31affa3eebf0d0029d8620dc6abb7a60f6c7629
Reviewed-on: https://gerrit.libreoffice.org/84127
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
.., and prevent Qt5MainWindow to take any focus.
Our top level Qt5MainWindow shouldn't handle focus directly, as
it's always completely drawn by the child Qt5Widget, which also
handles input. So prevent any direct focus handling by setting
the Qt5Widget as the focus proxy of the Qt5MainWindow.
Also setting the focus of the child widget on its own seems to
do nothing at all. At least I didn't see any difference after
commenting the code block. But it at least has some effect, if
you call setFocus on the real window, but that breaks Impress
full screen mode, which somehow gets scroll bars?!
Not that I understand why this is needed. At least the original
X11 code just calls XSetInputFocus in this case.
Change-Id: I591c031a17a7ae0b5486760cd1802522d4088678
Reviewed-on: https://gerrit.libreoffice.org/83689
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I8aacadbef404cdad474a58d92b947fea2aa22604
Reviewed-on: https://gerrit.libreoffice.org/82384
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
(and streamline those data members' names)
Change-Id: Ifdd596c7a54dd507045d412c30b463468c2f798b
Reviewed-on: https://gerrit.libreoffice.org/80313
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...since 5926b22b5dc33490d23d594b129eb8a70b94ffb0 "The SystemEnvData passed into
the canvas factories appears to be unused". (And the user-provided SvpSalObject
ctor can be removed, at which point the use in SvpSalInstance::CreateObject
should be written without "()" to avoid loplugin:subtlezeroinit.
Change-Id: I4392fa2d697b29c814d7b577a7b1f8c984c05e70
Reviewed-on: https://gerrit.libreoffice.org/80298
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1ee81de7ef03447991e12dcf01aef7858408dc40
Reviewed-on: https://gerrit.libreoffice.org/77975
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The patch has still one problem: the key-modifier state isn't
reflected by the cursor, unless the user moves the mouse. There is
an upstream Qt bug, reported in 2016-09 against Qt 5.6.1! It is
supposed to be fixed in Qt 5.12, according to the bug report at
https://bugreports.qt.io/browse/QTBUG-56218, which is still open.
I thought about adding a configure test, but I couldn't imagine
any realistic way to write it. And after Michael Weghorn found the
bug is actually not fixed, as claimed in one of the comments, I
decided to drop the warning.
Change-Id: Ice8ebc4ea149282b4c1551e755efe3d4856cf782
Reviewed-on: https://gerrit.libreoffice.org/77174
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as
it is based on the KDE frameworks 5 libraries.
This also includes:
* a convenience alias to load the kf5 VCL plugin in case someone
requests the kde5 plugin.
* keep convenience kde5 configure switch, but warn about it
* rename detected desktop from kde5 to plasma5
Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735
Reviewed-on: https://gerrit.libreoffice.org/75313
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
At least maths element docking window has a floating height of zero.
So the original gtk comment about broken values is still true.
And the initial SalFrameGeometry is ok, so no need to initialize it.
And set default size and position on show, if not explicitly set.
Change-Id: Ibe4969a164b50b666745ce010f5100af4b3ff2f6
Reviewed-on: https://gerrit.libreoffice.org/74614
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I357c004e724ebe580a121bf7ecdc63da9c02343f
Reviewed-on: https://gerrit.libreoffice.org/74593
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
I'm not sure why this redirection was implemented, which also ommited
the provided help area. I tried hard to use vc::Window code in the
beginning, but that also mirrors the cursor position for the window.
Using Qt here is simply straight forward, so just do that,
Change-Id: Ia8c4efc1e43b915c4b071ee26d4da37d7580817c
Reviewed-on: https://gerrit.libreoffice.org/74548
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The tooltip in the bug is actually not one, but the VCL implementation
of Gtk's popover widget triggered by SalFrame::ShowPopover. This has
no Qt equivalent, so we currently rely on the crude VCL version.
But for this maGeometry must contain the correct information, AKA the
absolute, unmirrored, paintable system geometry of the frame. Then the
window can be positioned correctly.
The patch gets rid of most of the code initially copied from gtk, when
this VCL backend was in a very early state.
Change-Id: Id44e4dc2aac41f1f01d51c4d8107892e644ef243
Reviewed-on: https://gerrit.libreoffice.org/74546
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I27a00608a5dba9fc467c61d5919233972b293811
Reviewed-on: https://gerrit.libreoffice.org/74093
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iab82151b8d1a8281c9999983b9de5f35dfb0442e
Reviewed-on: https://gerrit.libreoffice.org/74013
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Uses the same naming then the gtk3 backend, i.e. "libreoffice"
for the instance name and different class names for the module
windows, like "libreoffice-writer".
These names are referenced in the desktop files a StartupWMClass
and for example used to pin an app to the task bar.
Change-Id: Ic9b8890536f6413ab59d2e0da866e2280ab3181a
Reviewed-on: https://gerrit.libreoffice.org/74014
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
There will presumably be more X11 specific code later to implement some
"fix" for tdf#119202. Moving the screensafer inhibitor is rather
uncontroversial in comparion, so start with it and use it to carry the
matching configure.ac changes.
A little "nightmare" are all the clashing X11 / Qt type undefs, but I
couldn't find a better solution while the inhibitor continues to
include the X11 headers in it's header.
Change-Id: I55c89c76726d30a890178488484e954207267e89
Reviewed-on: https://gerrit.libreoffice.org/74015
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|