Re: [Development] Vulkan

Hi, Sean's summary is perfect. If you are after integrating your Vulkan renderer into a non-Quick app, use a QWindow and QWidget::createWindowContainer, like the D3D12 samples did. All you need is a native window handle (e.g. a HWND on Windows which is exactly what QWindow::winId() will give

Re: [Development] Approver status for Michal Klocek

+1. Good job on Qt Location! Laszlo From: Development on behalf of Michael Brüning Sent: Monday, February 8, 2016 3:26 PM To: development@qt-project.org Subject: Re: [Development]

[Development] Nominating Samuli Pippo for Approver status

Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard:

[Development] Nominating Pasi Petäjäjärvi for Approver status

Hello, I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project. Pasi is the maintainer of the VxWorks port and has also been contributing a lot for other embedded platforms over the years. Public Gerrit dashboard:

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

a <gun...@sletta.org>; Agocs Laszlo <laszlo.ag...@theqtcompany.com> Subject: Re: [Development] Qt 5.6.0 header diff: QtGui.diff New QImage::pixelColor and setPixelColor methods, looking good New QImageReader::gamma/setGamme methods, looking good QMouseEvent has a new constructor, looks o

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

sted in targeting certain modern desktop systems. Those continue to have separate classes for each version/profile. Cheers, Laszlo -Original Message- From: Knoll Lars Sent: 21. september 2015 13:58 To: Agocs Laszlo <laszlo.ag...@theqtcompany.com>; development@qt-project.org Cc: Gun

Re: [Development] Qt 'minimal' platform no rendering alpha/opacity.

It won't write anything to the framebuffer though. As long as you do not create an actual window (only use QOffscreenSurface, not QWindow) and do not call swapBuffers() there will be nothing written out. How and when the EGL implementation opens the framebuffer is not under Qt's or the

Re: [Development] Qt 'minimal' platform no rendering alpha/opacity.

From: Paul Knopf theonlylawisl...@gmail.commailto:theonlylawisl...@gmail.com Date: Friday 17 April 2015 17:45 To: Agocs Laszlo laszlo.ag...@theqtcompany.commailto:laszlo.ag...@theqtcompany.com Cc: development@qt-project.orgmailto:development@qt-project.org development@qt

Re: [Development] Rotating JPEG images by default

Hi Rainer, Which bug reports are we talking about? Are you saying that newer versions of Qt would automatically apply rotation to certain images? That's clearly a regression and cannot be done by default. At this stage it can be an opt-in feature at best. The difference to formats like TIFF

Re: [Development] Qt 'minimal' platform no rendering alpha/opacity.

You do have alpha because the minimal's backingstore uses ARGB32_Premultiplied for the backing QImage. What you do not have is setWindowOpacity(). You would need to implement QPlatformWindow::setOpacity() for that, but that is not possible with minimal since there is no compositor that could

Re: [Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

On Monday March 30 2015 08:15:09 Agocs Laszlo wrote: Hi, That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both

Re: [Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both the Qt libs and the app makefiles generated by qmake.

Re: [Development] Code Coverage Statistics for QtBase

Hi, Most of the platformsupport and platform plugin code was there in 5.4 too. Perhaps they were filtered out in the previous reports? Best regards, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org

Re: [Development] QOpenGLContext::currentContext()-functions()-glCreateShader(GL_VERTEX_SHADER) returns 0

Do set QT_LOGGING_RULES=qt.qpa.gl=true in the command prompt before launching the app. Then check the debug output with DebugView. During application startup a bunch of lines starting with qt.qpa.gl: ... will be printed. This will tell you which OpenGL implementation is in use. Alternatively,

Re: [Development] Under Windows QWindow receiving QExposeEvent on window drag.

Because some unfortunate code in the Windows platform plugin generates expose events even when the size has not changed. This is of course wrong. It will be corrected by https://codereview.qt-project.org/#/c/103932 Cheers, Laszlo From:

Re: [Development] when building a -opengl dynamic win32 config, gui still depends on libgles2.dll

Hi, It is not normal at all. In such builds no Qt DLLs should have a dependency on opengl32.dll, libEGL.dll or libGLESv2.dll. BR, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org

Re: [Development] QtWayland windows decoration on the Raspberry Pi

You are most certainly using the brcm backend since you don't have decorations. wayland-egl (the only one that has decoration support atm) does not work on the Pi with the default graphics stack. Not sure about the state of Mesa. Cheers, Laszlo From:

Re: [Development] Qt3D on windows

Hi Sean, What Gunnar refers to is a pattern we use in a few places to get things functioning correctly with certain embedded GLES implementations. With such drivers, creating sharing contexts on different threads behaves incorrectly as you won't actually get sharing. The workaround was to

Re: [Development] Platform maintainers

With all the embedded and graphics stuff on my plate QtWayland would be too much at this stage, I think. Jørgen would be an excellent candidate indeed, given that he is the original maintainer anyhow. Cheers, Laszlo From:

Re: [Development] Nominating Louai Al-Khanji as approver

+1 Cheers, Laszlo From: Sean Harmermailto:sean.har...@kdab.com Sent: ‎9/‎19/‎2014 12:58 PM To: development@qt-project.orgmailto:development@qt-project.org Subject: Re: [Development] Nominating Louai Al-Khanji as approver On Friday 19 September 2014 10:31:51

Re: [Development] QOpenGLWidget vs. QGLWidget

Hello, Yes, setViewport() will continue to work with QOpenGLWidget too. Note that all this does not mean existing code has to migrate away from QGLWidget. It is not going to disappear. If it works, just keep using it. Best regards, Laszlo From:

Re: [Development] Access to depth and stencil buffers in QOpenGLFramebufferObject

Hello, What is the use case for accessing the renderbuffers? It is probably left out since access to them was not seen important. (given that it is the texture that matters for the 2D UI development scenarios Qt has traditionally been targeting) The getters should probably be added

Re: [Development] Qt 5.3 header diff: QtGui

It is called GLES2 because there used to be a GLES1 value too, until a recent purge for ES 1.x support. The version could be omitted now. Laszlo -Original Message- From: development-bounces+laszlo.agocs=digia@qt-project.org

Re: [Development] QWindow::setScreen() and QQuickWindow

Hi, Option #2 is good enough, isn't it? QWindow::setScreen() already states If the window has been created, it will be recreated on the \a newScreen. This could be extended with a note about the visibility, like in QWindow::create(): the window remains hidden until setVisible() is called. As

Re: [Development] Nominating Giulio Camuffo (giucam) as an Approver

+1 From: development-bounces+laszlo.agocs=digia@qt-project.org [development-bounces+laszlo.agocs=digia@qt-project.org] on behalf of Jorgen Lind [jorgen.l...@digia.com] Sent: Tuesday, April 01, 2014 1:17 PM To: development@qt-project.org Subject:

Re: [Development] QPA / QWindow / QPainter

I'm implementing a QPA plugin (now with 5.3 snapshot) and there's something I do not understand: When I use native widgets, every widget creates a QPlatformWindow, but only a toplevel window creates a QPlatformBackingStore, which is the class which delivers the paintDevice

Re: [Development] QPA / QWindow / QPainter

Laszlo Subject: Re: [Development] QPA / QWindow / QPainter On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote: I'm implementing a QPA plugin (now with 5.3 snapshot) and there's something I do not understand: When I use native widgets, every widget creates a QPlatformWindow, but only

Re: [Development] The Dynamic OpenGL on Windows Change

To: development@qt-project.org Cc: Gunnar Sletta; Agocs Laszlo Subject: Re: Re: [Development] The Dynamic OpenGL on Windows Change Hi Gunnar, On Friday 28 February 2014 07:14:24 Gunnar Sletta wrote: On 27 Feb 2014, at 22:17, Agocs Laszlo laszlo.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM

Re: [Development] The Dynamic OpenGL on Windows Change

@qt-project.org Cc: Agocs Laszlo; Sean Harmer Subject: Re: [Development] The Dynamic OpenGL on Windows Change Since i haven't followed the discussion in detail, based on which assumptions do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds like a very bad idea. Relying

Re: [Development] The Dynamic OpenGL on Windows Change

and QtGui, I am afraid we will continue to disagree but perhaps that's fine. One cannot agree on everything. :) Best regards, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 14:07 To: Agocs Laszlo Cc: Björn Breitmeyer; development@qt-project.org

Re: [Development] The Dynamic OpenGL on Windows Change

Yes, it should be pretty simple: Just remove qopenglproxy_win.cpp and leave everything else in place. This provides an excellent foundation for continuing the feature with a different approach. The other modules are not an issue since the related changes have not been merged (with the

Re: [Development] GLSL Optimizer

-bounces+laszlo.agocs=digia@qt-project.org [mailto:development-bounces+laszlo.agocs=digia@qt-project.org] On Behalf Of Agocs Laszlo Sent: 3. februar 2014 12:41 To: development@qt-project.org Subject: Re: [Development] GLSL Optimizer Hello, This might be useful indeed, but it should be noted

Re: [Development] GLSL Optimizer

Hello, This might be useful indeed, but it should be noted that you really do not want to add this to the Qt OpenGL module (as in qtbase/src/opengl). This module should not be used anymore and is destined to be deprecated completely once QGLWidget gets a proper replacement. The modern OpenGL

Re: [Development] Dev branch build failing due to missing header mtdev.h

From the commit log of this file, it looks I'll have to run configure again where it'll detect the missing header? Yes. There is now a configure time test for mtdev. Best regards, Laszlo From: development-bounces+laszlo.agocs=digia@qt-project.org

Re: [Development] Qt5 documentation for Embedded Linux

Correct. This is a bit unfortunate since platforms like eglfs and linuxfb most certainly deserve a page in the documentation. I have created http://bugreports.qt-project.org/browse/QTBUG-36412 for this. Cheers, Laszlo From:

Re: [Development] Virtual GUI framework

The Ideally, this would still capture information about what is being drawn part is a bit more tricky but is perfectly doable. When it comes to raster painting, pretty much all existing platform plugins direct it into a QImage. That will not be suitable here since you are interested in the

Re: [Development] Removing libudev dependency from binary packages?

Hello, Not having libudev results in not having hotplugging and proper device discovery for the evdev inputs plugins (and platforms that have the input stuff built-in, like eglfs). This does not mean those plugins will not build or will not work since there is a (limited) fallback option that