| Age | Commit message (Collapse) | Author |
|---|
|
`QWidget::isVisible` only returns `true` if the widget is actually
visible on screen.
Therefore, even if the menu itself has been set to be visible
in `QtMenu::ShowMenuBar`, the call to `mpQMenuBar->isVisible()`
will still return `false` as long as the corresponding window
the menu belongs to isn't shown on screen (yet).
However, since the menu bar height may be used to calculate
the position of other items (e.g. in the macro dialog) before the
corresponding window gets shown, what should be relevant
is whether the menu bar itself is meant to be hidden or
not. Therefore, use `QWidget::isHidden` instead.
Quoting the Qt doc [1] for `QWidget`'s `visible` property:
> This property holds whether the widget is visible
>
> Calling setVisible(true) or show() sets the widget to visible status if
> all its parent widgets up to the window are visible. If an ancestor is
> not visible, the widget won't become visible until all its ancestors are
> shown. [...]
>
> Calling setVisible(false) or hide() hides a widget explicitly. An
> explicitly hidden widget will never become visible, even if all its
> ancestors become visible, unless you show it.
This makes the menu show properly in the macro dialog
while still not reserving any space for the menu in the
main window in case of using the "Tabbed" interface (where
no "traditional" menu is present).
[1] https://doc.qt.io/qt-6/qwidget.html#visible-prop
Change-Id: Ifb6e22db8224013f06320d090a19d80d9e38a990
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139910
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Calculate the position at which to open the popup
menu from the passed window and rectangle, rather
than always opening the native popup menu at the
cursor position.
The commit message in
commit 1e0b16f8695498e4eea7c2208aabf7e7664ce749
Date: Wed Feb 12 08:07:42 2020 +0100
tdf#128921 tdf#130341 tdf#122053 qt5: Native PopupMenus
which had implemented native poup menus, already said:
> For now, this always shows the popup menu at cursor position, which
> can be changed by taking the Rectangle passed to
> 'Qt5Menu::ShowNativePopupMenu' into account if there should be any
> need.
Change-Id: If1a44b6d53f3dcd6fa7ceec0738219f11cfc22c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136356
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
... and renove the wrong framesize hack in the Qt backend
This wastes a few additional pixels in the frame backing store,
actually covered by the real native menu bar, to get rid of all
the hacks and eventually fix quite a bunch of bugs in Qt (and
maybe other backends).
This seems to work correct with Qt using either QPainter or Cairo
as the painting backend. It's much simpler then my previous failed
attempts to fix the Qt related bugs. I would like to convert every
implementation to my interpretation of the API (at least I now
documented the API). It looks like Win and Mac will just work,
because Win has no native menu bar and Mac uses a global menu,
so always returns the size of 0. And Gtk also seems to work, if
it also lies about the menu bar size being zero. That just seems
consequent, if the frame size is reduced by the menubar size.
This fixes at least:
tdf#64438 - Dockable panels in LibreOffice not dockable using KDE
Works.
tdf#130893 - XWindow::SetPosSize resizing based on
XWindow::GetPosSize shrinks the window
The document macro from tdf#130841 now doesn't resize the window.
This is just fixed for Qt.
tdf#134704 - KDE5 - unable to dock sidebar by dragging frame
not fixed, because the sidebar window is now a dialog, which is
not dockable. FWIW the same has happend the Navigator (F5), which
also renders it non-dockable. No idea, if this is intentional.
tdf#137471 - CMIS dialog advances beyond lower right corner of the
screen
So commit 3f8d3fd4649ef09e86c735617383a4bda0425540 ("tdf#137471 Qt
return frame pos + client area size") was really not enought as a
fix (at least it didn't break anything). The whole parent-based
repositioning is wrong and it really depends on the correct frame
size, so I'm keeping this as fixed by this patch.
Change-Id: I7faeace61b456c2b0f42c7a826f58018b70d46ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135082
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This turned out much more complicated then expected:
1. The QMenuBar needs explicit adjustSize() calls to position a
changed corner widget (or a resize...).
2. The adjustSize() results in a temporary, minimal QMenuBar
layout, so GetMenuBarButtonRectPixel needs to account for the
extra space itself, instead of just a mapTo call.
3. I didn't know, that you can't add shown widgets to a layout,
but must call show() after add / insert, otherwise they are
ignored in the layout (but show up as the layout items) and
are painted in strange positions.
This also includes the transparency flags for our QtWidget, so the
updater "bubble window" is properly alpha-masked / shaped.
And this maybe has too many asserts...
Change-Id: I86a708175e9f9be786f5dc1810ae0197a0d3fc39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135021
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
When the QMenuBar of a QMainWindow is replaced, an existing
corner widget is preserved / transferred, but its connections
are still severed; a bit unexpected...
The documentation for QMenuBar::setCornerWidget is not really
clear what is happening, but the code has this nice comment:
"// Reparent corner widgets before we delete the old menu".
At least there is no need to explicitly delete the button.
Still we must reconnect an existing button on each SetFrame.
Regression from commit 9c4ef8ce3183e27ca174475cf4a8d15cc0368f60
("tdf#145954 Qt unshare QMenubar usage").
Change-Id: I13c31734e665b78231a08cd76ca6305122e08879
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132836
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I988cabf4c07d5efd298c53b696f6d114f4f594bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132637
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The Qt code was sharing the menu bar from the top level frame, but
LO expects independent menu bars per SetFrame calls. So instead of
showing the new bar and then hiding the old one, this was always
show and hiding the same menu bar, resulting in a hidden menu bar.
As a result of unsharing, LO now must check that its menu bar
pointer is still valid for usage. The QMainWindows takes ownership
when a QMenuBar is assigned and destroy old ones.
Change-Id: I2c6b12199a1e17a5d9f88686a4b27b1413beda47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132581
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
AKA the "*nix SalData untangling" commit.
The original plan was to get rid of vcl/inc/saldatabasic.hxx and
even SalData for all the *nix backends. But after many backs and
forths, reinspecting the code and imagining the resulting code, I
decided against that plan. All these variants would have resulted
in reinterpret_cast calls, I wanted to prevent. And they would
have required larger renames for no benefit.
An other, related idea was to include all SalData implementations
in the vcl/inc/svdata.hxx header, but that seemed like an include
explosion, so was also dropped.
I tried to untangling iOS from using GenericUnixSalData, as it
doesn't use any of it's features. The new, minimal SalData should
be sufficient.
I'm leaving the easier drop of mpInstance from the Windows and
MacOSX backend as a minimal interesting EasyHack.
Change-Id: I5be01c1f42131a7e31cb30899392308e1e2de53b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128402
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This adds a new "qt6" VCL plugin based on Qt 6.
Building the plugin is enabled by autogen option '--enable-qt6'
(and optionally setting 'QT6DIR' as needed).
Use the 'SAL_USE_VCLPLUGIN=qt6' environment variable
before running LO to select this VCL plugin.
Taking qt6 into account at all relevant places certainly
still requires follow-up changes, but
this builds and runs with a self-compiled
qtbase from the 'dev' git branch as of commit
3ce0672143d2eb3c3809f82998a4d71c5800d77a.
I didn't see anything obviously broken
in a quick run, but didn't test much.
This reuses and shares the qt5 VCL plugin code;
the qt6 headers and sources for now just
'#include' the qt5 ones.
Version checks are used for the code places that
need different handling to be built against Qt 6.
The build system parts in this commit were mostly done by
copying the qt5 equivalents, then adapting as needed.
Some notes on things I came across while porting
to qt6:
1) At least in my self-compiled Qt versions,
'moc' (the meta-object compiler) is located
in the 'libexec' subdirectory in 'QT6DIR', while the
Qt 5 equivalent is located in the "bin" subdirectory
of 'QT5DIR', so the configure.ac check uses the former.
2) moc does not process classes from the included headers.
Since the headers in 'vcl/inc/qt6' just '#include' the ones
from 'vcl/inc/qt5', running moc on the qt6 headers doesn't work,
so moc is currently run on the qt5 headers for qt6 as well
(s. 'vcl/CustomTarget_qt6_moc.mk').
That will have to be adapted in case the qt6 VCL plugin
uses "own" headers instead of just including the qt5 ones
at some point.
3) QX11Extras has been removed from Qt 6.
[1] says:
> Changes to Qt X11 Extras
>
> The QX11Info class has been removed.
>
> Clients that still rely on the functionality can include the private
> header <QtGui/private/qtx11extras_p.h> as a stopgap solution. To enable
> private headers use QT += core-private with qmake, or add a project
> dependency to Qt::CorePrivate with CMake.
I didn't take any closer look, just dropped the use of
QtX11Extras for qt6 for now.
4) XCB_ICCCM is no longer needed.
It is only used in qt5 to workaround a Qt bug fixed in Qt 5.12, s.
commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca
Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de>
Date: Tue Dec 3 08:32:58 2019 +0100
Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP
5) X11-specific code is still used for key modifier handling.
Therefore, still check for the XCB headers when 'USING_X11'
is set in configure.ac, and use a 'QT6_USING_X11' define
(as qt5 uses 'QT5_USING_X11').
6) There's currently no Qt 6 video sink for GStreamer.
As of today, qt-gstreamer is unmaintained and there is no Qt 6 version.
The project's README [2] says:
> 0. Maintenance Notice
> ---------------------
>
> This code is unmaintained. You can use it at your own risk.
>
> If you want to integrate video display in your QML-based UI,
> you should consider using 'qmlglsink', from gst-plugins-good.
> This is a well supported video sink that uses the generic
> gstreamer-gl stack and is in many ways superior to 'qtquick2videosink'
> that is provided by qt-gstreamer. You can use this code as an example:
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsink
>
> If you are not interested in using QML in your UI, then you
> may use one of the other elements provided by this module
> (see below). If you do that, it would be helpful to let us
> know that this code is still useful to you. We may consider
> adding these elements in one of the core gstreamer modules.
>
> If you are here for the Qt-style bindings, I'm sorry to disappoint you.
> The alternative is to use the C API, or the GStreamermm C++ API.
> Qt-style bindings are cool, but unfortunately they are very hard
> to maintain because they are written by hand. If you are interested
> in continuing this project, you are welcome to implement a
> generator for them, probably based on GObject-Introspection.
> I am happy to provide directions if you want to pursue such a thing.
Therefore, the Qt video sink handling is qt5-only and the
corresponding handling for GOBJECT (used for the GStreamer
video sink handling) was not taken over for qt6.
This presumably means that video playback in Impress presentations
does not work when using qt6 with they Qt Wayland plugin,
s. tdf#125219 for the corresponding bug for qt5/kf5.
(I did not build the qtwayland module to actually test this, though.
Video playback with the Qt xcb plugin in a Wayland session works.)
[1] https://doc-snapshots.qt.io/qt6-dev/extras-changes-qt6.html
[2] https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README
Change-Id: Ib105ccfb2c3630ec5d5403793a3cd9ba31d85bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122808
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This renames the source and header files according to the
new class names without a "5" in them, as mentioned in
Change-Id: Idf422f82ca9dafbb70e9a64de9c8cfc4cc8c0909
(qt5: Remove "5" from class names in qt5 VCL plugin):
> Renaming the headers and source files will be done
> in a separate commit to make tracking git history easier.
Change-Id: If955e77c8ba508d0a2e01e3a9df1be6dc04c4e4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122806
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
