Detect if DirectWrite 2 is available, and support color fonts if possible.
One limitation worth mentioning is that if the color font contains regular,
monochrome glyphs as well, then these will be drawn in black, and not in the
pen color. Fixing this would require some elaborate rewrites in the font
rendering system, since we would have to have two font caches per
color font (one for mono and one for colors), or do some sort of trick where
we make argb(r, g, b, 0) mean subpixel alpha instead, and detect glyphs that
are not correctly premultiplied when blitting to the screen.
Another limitation is that the approach does not work with distance field
rendering. In principle we could support this on Windows, since the
format is vector based, but it would also require substantial work and
it is not possible to support for Apple/Google fonts anyway, so it would
just lead to code which is not cross-platform.
[ChangeLog][Windows] Added support for color fonts (color emojis) when
DirectWrite 2 is available.
Change-Id: I6a608dd5d2aa3a7e762a06830902bddac7c550a5
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Not only we don't need Cocoa to display it for us, but it also
seems to take a lot of time after the call to -[NSView
setNeedsDisplayInRect:].
While resizing a large and busy widgets window, we can decrease
the relative time spent in -[QNSView flushBackingStore:region:
offset:] from over 15% down to around 3%.
Change-Id: I2a8d51be28b77c4c3da2588d9a14e461e7910167
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Don't create hwcursor if it is disabled in QT_QPA_EGLFS_KMS_CONFIG.
Task-number: QTBUG-52403
Change-Id: I4e6f45d5b773dc2d50cd012179cd23452d910537
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Unfortunately the functions in xcb-image are quite slow, both for the
subimage generation and the byte order swapping. xcb_image_subimage is
implemented as a pixel by pixel copy, and the xcb byte swapping is done
manually without utilizing potential CPU instructions to accelerate the
swap.
Replace both with their Qt equivalents.
Change-Id: I1fe1fe5d9576fdf2bab4a8c401d2a6bb842c2727
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
This patch improves support for non-32bit screen configurations on X. The
patch mostly touches the xcb platform plugin but the changes to the glx
convenience functions do affect e.g. the offscreen plugin as well.
Since QWindow instances are now by default of type RasterGL instead of
Raster the majority of all windows are in fact instances of QXcbGlxWindow.
This means that the eventual QSurfaceFormat that we use is chosen based on
the available OpenGL configurations. Here the GLX config resolution code
did not do a very good job in trying to find the closest match relative to
the requested QSurfaceFormat, instead preferring higher bit depths.
This is an issue since many configurations support 32-bit windows even
if the screen itself has a root window with depth 16. In particular,
servers supporting both GLX and Render are very likely to have such
visuals. Particularly affected are remote X connections - even if the
application itself makes no use of OpenGL at all!
The changes introduced by this patch are as follows:
1. Improve the GLX visual selection logic
2. Improve the xcb visual selection logic
3. Remove duplicated visual lookup for OpenGL-enabled windows
4. Configure the default QSurfaceFormat to match the primary screen depth
Change-Id: Id1c176359e63a4581410e20350db5ac2c083e1cf
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
... instead of using removeAt in a loop, with quadratic complexity.
Change-Id: I38b49e56b12c396db9fc0f1b75d8fb43c503a7f6
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It's urgent to fix the issue that on Android, it became impossible
to interact with any widget or MouseArea which handles only mouse
events but not tablet events, using the stylus, because stylus events
are sent only as QTabletEvents. Before 5.6 (change
01d78ba86a) they were sent as
touch events, and mouse events were synthesized from those. Whereas
on other platforms, every QTabletEvent is followed by a synthesized
QMouseEvent.
This fix proceeds in the direction that event synthesis should be done
in cross-platform code so that platform plugins don't have to repeat it,
following the same pattern as for touch->mouse synthesis. Just as
in that case, the application can disable it, and the platform plugin
can also report that it's unnecessary for Qt to do the synthesis
because the platform already does.
So QTBUG-51618 is fixed, but QTBUG-47007 requires us to remove the
tablet->mouse synthesis from all platform plugins, because the plugin
does not know whether the tablet event was accepted or not, so it does
not have enough information to decide whether to synthesize a mouse
event. Synthesis has been unconditional until now, which contradicts
what the documentation says: the mouse event should be sent only if
the tablet event is NOT accepted. We can now gradually make this
promise come true.
[ChangeLog][QtCore][Tablet support] A synthetic mouse event will
no longer be sent after every QTabletEvent, only after those which are
not accepted (as documented).
Task-number: QTBUG-47007
Task-number: QTBUG-51618
Change-Id: I99404e0c2b39bbca4377be6fd48e0c6b20338466
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
This is more concise, consistent with Windows, and fits the pattern
that all logging categories in QPA plugins should begin with qt.qpa.
Change-Id: Ica169b547cb3d816e6e2c0449f0e4a0c58883b9a
Reviewed-by: Gatis Paeglis <gatis.paeglis@theqtcompany.com>
We should mimic desktop Qt's behavior as close as possible. That means,
that a key release event is triggered between auto generated press
events for most keys. For some keys like modifiers, caps lock, scroll
lock etc. there are no auto repeated events if the key is held down.
The "last" release event after having held the key and several events
are triggered does not have the isAutoRepeat flag set so we should not
have that flag in this case either.
Task-number: QTBUG-52055
Change-Id: I001a73416c4b2072d307ee5d87c7cb8406c9575f
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
When keeping a key pressed CorePhysicalKeyStatus'
RepeatCount stays 1 while WasKeyDown changes from
false to true. Thus WasKeyDown should be used to
determine the auto repeat status of the key event.
Task-number: QTBUG-52055
Change-Id: I7cde6b92473bd5335e85418c2b92cfe8f338975c
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
When QT_XCB_GL_INTEGRATION=none we were printing:
1) qt.xcb.glintegration: QT_XCB_GL_INTEGRATION is set to "none"
2) qt.xcb.glintegration: Choosing xcb gl-integration based on following priority ()
3) qt.xcb.glintegration: Failed to create xcb gl-integration
Omit line 2 (useless) and line 3 (misleading).
Change-Id: If5e65a5bc8cc4a1fa97858049a26aac9a9535950
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
Separate factors in QWindowsCursor::createPixmapCursor()
and apply factor to the hotspot.
Task-number: QTBUG-52276
Change-Id: Ia5a5db39ddc2bc4215a23ff8625431af9b4a76d8
Reviewed-by: Adam Light <aclight@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
The instance of QWindowsStaticOpenGLContext has been observed to be 0.
Task-number: QTBUG-52387
Change-Id: I1ca97c6df0d96e732ae62354e03f465cd461bcb4
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Native applications do open the native input pane when the touch release
happens, not during press. Widget applications seem to not ask the
theme, so it was acting like native there already. For Qt Quick
applications the platform theme is queried, now returning true for
SetFocusOnTouchRelease.
As a side-effect this also fixes QTBUG-52295, as showInputPanel() at
press time causes issues with focus handling, causing the input pane to
disappear again.
Task-number: QTBUG-52295
Change-Id: I6da6a0126f695233b7c8a399a1549a8b7c824af2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Meta modifier is not found in some configurations which triggers an
assert. Instead of assert, ignore the modifier if it is not found.
Task-number: QTBUG-52298
Change-Id: I258cee4014a30162afebb423eadaf07ef0ed6a1f
Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com>
For these states, geometry change will be sent from the code called
by setWindowState(); the geometry obtained immediately after window
creation is then no longer valid.
Task-number: QTBUG-52231
Change-Id: Ia7cbe95e73c5dd4126bb63d448b83f2cab6a53a1
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Fixes the position of the input method window when High DPI scaling
is active.
Task-number: QTBUG-51923
Change-Id: I35ee4bcf320f8c2b7d5cc7fb8484348b18e1d833
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
In case Qt::WindowTransparentForInput is set on a window, we
usually call [super someRelatedMethod] on a corresponding QNSView, for example,
[super mouseDown:theEvent]. Unfortunately, Cocoa will continue
to report the subsequent mouse dragging events to the first view where
mouse down occurred, despite of us passing mouse down to the next reponder.
Dragging events we'll also 'propagate' by calling super's method,
but it's not working properly, since the current view below
probably did not have that first mouse down event thus it does not have m_buttons set
correctly. And even worse with the closing mouseUp event. So, let's use
-hitTest: returning nil on such a 'transparent' view so that it's ignored by mouse events.
Task-number: QTBUG-40583
Change-Id: I5e0fef3e246a29332df758a692300d478b862069
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Cleaning out the workarounds for the discontinued "Embedded Android"
platform of Boot2Qt.
Change-Id: I0ff9d770e82a43457fb7e5da0428f4597ead4038
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Both QFont::handle() and QFont::freetypeFace() used to
be available in Qt 4 but were removed in Qt 5. There's
currently no API to get access to the native font handle,
which the font engine holds in a way or another.
Similar to the way it was in Qt 4, the actual handle type
depends on the font engine currently in use. The types map
as follows:
Font Engine Native Handle
------------------------------------
DirectWrite IDWriteFontFace *
Freetype FT_Face
Mac CTFontRef
Win HFONT
All other font engines return a null handle.
Change-Id: I3bea8259ac1378fd24079723aa6603bf9e74834c
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Qt crashes when opening a native file dialog. Disable this feature to
fix this issue.
Change-Id: I1ee17d858238c2531964a63ddbe3e11c5a85483c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Update files using old header.LGPL3 to header.LGPL
Update files using old FDL template to use new one
Update files using old BSD template to use new one
Change-Id: I36a78272516f9953d02956522f285b40adfc8915
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Match correct number of digits and entire string, amending
change 4347e81161.
Task-number: QTBUG-33962
Task-number: QTBUG-51373
Change-Id: I56de00bd5ffb3a3a700efbb20970154faf86f923
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This makes minimal a bit more useful for apps needing to access
QFonts from non-UI environments.
Change-Id: Idc5ca13f0c385ab9b4258e11fea7ec886515eea4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
The QPA plugin was deleting the screen object manually, which
is not needed or the recommended approach. The screen(s) are already
maintained by QGuiApplication and destroying the screen object(s) should
be done by calling QPlatformIntegration::destroyScreen().
This change removes the need to keep a reference to the screen(s) in the
mir platform integration class, and removes the warning printed on exit.
Change-Id: I61f37c25ebabf3e96e4cea458c4af454d025926a
Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com>
The plugin builds as a static plugin.
It is based on the Linuxfb plugin.
It uses the INTEGRITY FB API for framebuffer for display, and HID API
for input (mouse, keyboard, touch).
Because this is the only supported plugin and requires to be included
as a static plugin, automatically add the platform to any application
through qmake.conf.
Change-Id: Ic228afb59cb39dd02c2d538de46caf6e6ea7d153
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
To solve menu item roles from their text, we need to find
its depth in the menubar hierarchy. Unfortunately, there's
no trivial way to access that hierarchy from the QPA side,
so we need to come with an ad-hoc solution.
Previously, we were using a dynamic proprety to keep track
of the 'parent' object. However, as the life span of the
different objects has changed since 09acf326db,
we need a way to keep track of the parent's existence.
This is what we do in this patch by having both QCocoaMenu
and QCocoaMenuItem also inherit QCocoaMenuObject. This class'
sole role is to store the menu hierarchy's parent object and
wrap it in a QPointer.
Change-Id: Ia18d95171af76d26f6325eef04c77b40d99c4285
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Forward mouse events hitting the a masked out window
area to the next responder by calling the superclass
event handler.
Implement "inverse mouse grabbing": Qt will not take
dragged and up events if the mouseDown was in a masked
out area.
Change-Id: Ie86281245513cad515b77a468ac63f31ae41bfe0
Task-number: QTBUG-41839
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Forward rejected key events to the next responder
by checking the return value from QWindowSystemInterface
and calling the superclass event handler.
This is useful when Qt is running as a plugin in a
host application; the host can now react to key
events even if Qt has focus.
Qt will often not accept keyUp events, even if the
corresponding keyDown was accepted, for example in
the case of text controls. We don't want to forward
'bare' keyUps, so keep track of which keyDowns have
been seen.
Change-Id: I976448a5d305a657a0e91aeb271b158f8b598286
Task-number: QTBUG-45768
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reduce the code duplication for the various button
type handlers. Fan in: (example)
rightMouseDown
handleMouseDownEvent
handleMouseEvent
The primary mouseDown function is still separate
with some duplicated logic.
Remove the "invalid button tracking" warning. qWarnings
are for application developers in case of improper
use of API etc, not internal Qt errors.
Change-Id: Idb1a311e37446399668c2a207831fccc84716ca1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Remove QT_COCOCA_ENABLE_WINDOW_DEBUG. Replace/Add
logging for window state changes and drawing.
The window identifier is now the QWindow (not the
platform window) everywhere since this object provides
more debug output.
Change-Id: I4ae56626015241279ab1b44d2b81c9d462b532a0
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
When EnableHighDpiScaling is enabled, qGuiApp->inputMethod()-
>inputItemRectangle() returns the position divided by pixel density,
therefore all the controls positions must by multiplied by pixel density
to translate them into screen coordinates.
Task-number: QTBUG-52001
Change-Id: Iea92a912cfbab03a9497fc8cddc24bebd0db2192
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
This reverts d5fde51410 and makes
that enum value the default for QWheelEvent::phase() with non
phase-aware mice.
[ChangeLog][QtGui] QWheelEvent::phase() returns NoScrollPhase with
non phase-aware mice. This is most mice and input devices except,
for now, Apple's trackpads and Magic Mouse.
Change-Id: I929fb39889cf116e89dcd134c1b1ec6587b8f05e
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
This makes possible to set custom _NET_WM_STATE hints before
showing the window.
Change-Id: I86ad3863f7a8b3bb610a31b9af4b02c9d38eb111
Task-number: QTBUG-26978
Reviewed-by: Ilya Kotov
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
Reviewed-by: Uli Schlachter <psychon@znc.in>
QPlatformBackingStore::composeAndFlush() handles an empty texture list
just fine, and results in the same blitting of the backing store image
as we're doing today using the OpenGL paint engine, except the compose
and flush code path is a lot more optimized.
Among other things it clears the render buffer as the first step (as
recommended by Apple on iOS), doesn't re-create the backing store
texture each pass just because the image has changed, and respects
the flushed region for both the texture upload (using glTexSubImage2D)
and when blitting the texture.
The result is a 10x increase in frames per second when blitting full
screen updates.
Change-Id: I163fab473751f8201758a5684b18d80bb90d42fb
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
While Cocoa requires an NSMenu to be coupled to an NSMenuItem
(just as Qt requires a QMenu to be coupled to a QAction), making
that a hard coupling comes with some limitations. This is because
Cocoa won't allow the NSMenu object to be simultaneously coupled
to more than one NSMenuItem and, similarly, an NSMenuItem can
only be added to a single parent NSMenu. Therefore, it becomes
difficult to share one QMenu between two different QMenuBars in
different windows, or to use a QMenu as context menu while being
accessible from the menu bar.
Previous solutions to circumvent those limitations were less than
ideal (see 119882714f for the
QMenuBar shared QMenu issue). Other workarounds that relied on
that hard coupling, like 996054f5e6,
also added gratuitous complexity.
In this patch, we break that hard NSMenuItem-NSMenu coupling, and
we replace it with a temporary, looser coupling. As a consequence,
* QCocoaMenu only contains and manages a NSMenu instance,
removing the previously used NSMenuItem. It gets a temporarily
attached NSMenuItem instead.
* QCocoaMenuItem gains a safe pointer to its QCocoaMenu property
removing the necessity containingMenuItem() in QCocoaMenu.
* QCocoaMenuBar manages its own NSMenuItems.
With this setup, we bind the NSMenu to its parent NSMenuItem at the
last moment. In QCocoaMenuBar, when we call updateMenuBarImmediately().
In QCocoaMenu, we use the delegate's -[QCocoaMenuDelegate menu:
updateItem:atIndex:shouldCancel:] method which is called when Cocoa
is about to display the NSMenu.
Note: There's still one use case we don't support, which is sharing
a toplevel QMenuBar menu. This is because Cocoa's menu bar requires
each of its menu items to have a submenu assigned, and therefore we
can't rely on that last moment assignment.
Task-number: QTBUG-34160
Task-number: QTBUG-31342
Task-number: QTBUG-41587
Change-Id: I92bdb444c680789c78e43fe0b585dc6661770281
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Liang Qi
Eskil Abrahamsen Blomfeldt
Gabriel de Dietrich
Elena Zaretskaya
Louai Al-Khanji
Anton Kudryavtsev
Shawn Rutledge
BogDan Vatra
Oliver Wolff
Gatis Paeglis
Friedemann Kleint
Maurice Kalinowski
Joni Poikelin
Andy Shaw
Timur Pocheptsov
Eirik Aavitsland
Andreas Holzammer
Jani Heikkinen
Simon Hausmann
Christian Strømme
Rolland Dudemaine
Morten Johan Sørvig
David Rosca
Tor Arne Vestbø
Frederik Gladhorn
Jochen Seemann