[Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8 at least). Reproducible test case included.
Use of Qt Keyboard shortcuts has been broken in Qt for years. There are lots of bugs about it in Qt and KDE projects. This one looks close to what I'm seeing, Can't assign keyboard shortcut with Meta modifiers https://bugreports.qt.io/browse/QTCREATORBUG-9846 This one got mentioned in a few KDE bugs Qt LineEdit incorrectly truncates "Password" dialog elements when entered with a KDE Custom Shortcut ... https://bugreports.qt.io/browse/QTBUG-24304 There are lots of others. Anyway, the point is -- shortcuts don't work. I have a reproducible test case. It's 100% reproducible on 4 machines. Here anyway. The Qt shortcuts fail only when used in Qt-based applications. They work fine in NON-Qt apps (GTK, JAVE, etc). I can't create a Qt account, can't add to any bug (not that I'm clear on which one). Posting the testcase here. I'm cc'ing to a couple of developer's named I saw in those bugs. Maybe somebody will stick this in the right place. - on: /usr/bin/systemsettings5 -v systemsettings 5.6.2 exec: /usr/bin/systemsettings5 open: Configure Desktop Workspace Shortcuts Custom Shortcuts Configure Input Actions settings in: 'Name' pane right-click: New Global Shortcut Send Keyboard Input rename New action: TEST select: TEST in: 'Trigger' Pane click: Shortcut "None" enter: Meta-Ctrl-Alt-L click: Apply in: 'Action' Pane enter: Shift+3:X click: Apply (1) open: LibreOffice Writer v5.1.2.2.0 10m0(Build:2) document press: Meta-Ctrl-Alt-L OUTPUT: "#X" (2) open: Eclipse Editor v4.6 (Build:I20160405-0800) document press: Meta-Ctrl-Alt-L OUTPUT: "#X" (3) open: KDE Kate v15.12.3 document press: Meta-Ctrl-Alt-L OUTPUT: (none); window flashes (4) open: QtCreator v3.6.0 (based on Qt 5.6.0) document press: Meta-Ctrl-Alt-L OUTPUT: (none); window flashes - If someone knows a bug report that this'll get fixed at, pls post it there, and let us know here. Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Vulkan
Thanks guys for the detailed updates. I an appreciate any big sweeping changes, aren't lite nor simple. I was after using Vulkan (to learn the API) with a widgets interface for now and going with the native window handle sounds simplest and best. I'll give it a try (a D3D12 type vulkan widget) and see what I come up with and if it's going to be of use to anyone I'll post it. Thanks again On Sun, 10 Apr 2016 02:45 Agocs Laszlo wrote: > 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 you; on other platforms there are > backend-specific means to acquire the native window via > QPlatformNativeInterface). > > Integrating Vulkan rendering into an OpenGL-based Qt Quick scene can be > more complicated, so at first I would rather look at the (unfortunately > vendor-specific) GL_NV_draw_vulkan_image extension. This, in combination > with GL_KHR_vulkan_glsl, is likely the easiest way to get started and > combine the two worlds. > > Right now Qt Quick is undergoing certain changes to make it more modular, > focusing on OpenGL, D3D, and the QPainter-based 2D Renderer for the time > being. This will allow multiple backends in the future, instead of being > tied to OpenGL (or the current iteration of the separate, somewhat hackish > 2D renderer). There are a number of issues to be investigated still, but we > expect most of the work to become available in Qt 5.8 and beyond. > > However, it is important to note that a full-blown Vulkan (or Metal for > that matter) backend for Qt Quick is not something that will be rushed, so > I wouldn't expect much on that front short-term. The benefits of the new > low-level APIs are expected to be fairly limited for the workloads typical > user interfaces generate. (this naturally does not apply to Qt 3D) > > Best regards, > Laszlo > > From: Development theqtcompany@qt-project.org> on behalf of Sean Harmer < > sean.har...@kdab.com> > Sent: Saturday, April 9, 2016 11:06:23 AM > To: development@qt-project.org > Cc: Tom Kulaga > Subject: Re: [Development] Vulkan > > On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote: > > Hi All, > > > > Is anyone actively working on vulkan integration? Or even a > QVulkanWidget? > > I saw that d3d12 had a preview widget so thought it was reasonable to > ask. > > > > If anyone isn't I'm keen to have a crack. In terms of implementation, is > it > > as naively simple as creating a new widget similar to the QOpenGLWidget > > one, just to get a drawable canvas up and running? I believe that on > Linux > > a xcb_window_t is used for vulkan samples and deep in the QPA I saw it > too. > > > > I was wondering if for a novice like me this would be feasible to > actually > > do? > > > > Does the whole rendering stack need to transfer over to vulkan? > > It all depends what level of integration you are after. Using a QWindow and > using Vulkan with it doesn't require much. Making something equivalent to > QOpenGLWidget is much more work as you have to worry about compositing > QPainter content into the window too. > > Making a Vulkan backend for Qt Quick 2 is also more work, considerably more > work than much of the other low hanging fruits that could be used to > improve > performance there on the existing OpenGL backend. Although, like the D3D12 > backend it might give better results on windows (for Vulkan capable > hardware). > > Putting a Vulkan backend on Qt 3D is a very real possibility and one where > Vulkan could potentially make a big impact. This is something I want to > investigate later after we have done a stable release or two of Qt 3D. The > good thing is that Qt 3D's architecture maps very well to Vulkan (by > design). > > Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can > use > both Vulkan and OpenGL on the same surface which would be another > interesting > option if this support becomes widespread. > > If you want to have a go, then certainly nobody is going to stop you and > you > may well get some help. We have some early proof of concept stuff we can > look > to tidy up and publish along these lines. > > Cheers, > > Sean > -- > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 you; on other platforms there are backend-specific means to acquire the native window via QPlatformNativeInterface). Integrating Vulkan rendering into an OpenGL-based Qt Quick scene can be more complicated, so at first I would rather look at the (unfortunately vendor-specific) GL_NV_draw_vulkan_image extension. This, in combination with GL_KHR_vulkan_glsl, is likely the easiest way to get started and combine the two worlds. Right now Qt Quick is undergoing certain changes to make it more modular, focusing on OpenGL, D3D, and the QPainter-based 2D Renderer for the time being. This will allow multiple backends in the future, instead of being tied to OpenGL (or the current iteration of the separate, somewhat hackish 2D renderer). There are a number of issues to be investigated still, but we expect most of the work to become available in Qt 5.8 and beyond. However, it is important to note that a full-blown Vulkan (or Metal for that matter) backend for Qt Quick is not something that will be rushed, so I wouldn't expect much on that front short-term. The benefits of the new low-level APIs are expected to be fairly limited for the workloads typical user interfaces generate. (this naturally does not apply to Qt 3D) Best regards, Laszlo From: Development on behalf of Sean Harmer Sent: Saturday, April 9, 2016 11:06:23 AM To: development@qt-project.org Cc: Tom Kulaga Subject: Re: [Development] Vulkan On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote: > Hi All, > > Is anyone actively working on vulkan integration? Or even a QVulkanWidget? > I saw that d3d12 had a preview widget so thought it was reasonable to ask. > > If anyone isn't I'm keen to have a crack. In terms of implementation, is it > as naively simple as creating a new widget similar to the QOpenGLWidget > one, just to get a drawable canvas up and running? I believe that on Linux > a xcb_window_t is used for vulkan samples and deep in the QPA I saw it too. > > I was wondering if for a novice like me this would be feasible to actually > do? > > Does the whole rendering stack need to transfer over to vulkan? It all depends what level of integration you are after. Using a QWindow and using Vulkan with it doesn't require much. Making something equivalent to QOpenGLWidget is much more work as you have to worry about compositing QPainter content into the window too. Making a Vulkan backend for Qt Quick 2 is also more work, considerably more work than much of the other low hanging fruits that could be used to improve performance there on the existing OpenGL backend. Although, like the D3D12 backend it might give better results on windows (for Vulkan capable hardware). Putting a Vulkan backend on Qt 3D is a very real possibility and one where Vulkan could potentially make a big impact. This is something I want to investigate later after we have done a stable release or two of Qt 3D. The good thing is that Qt 3D's architecture maps very well to Vulkan (by design). Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can use both Vulkan and OpenGL on the same surface which would be another interesting option if this support becomes widespread. If you want to have a go, then certainly nobody is going to stop you and you may well get some help. We have some early proof of concept stuff we can look to tidy up and publish along these lines. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.6.1 ETA?
It is in the works, but priority is to get Qt 5.7 Beta released. So probably towards end of April. -- Tuukka > Rex Dieter kirjoitti 9.4.2016 kello 16.44: > > Curious what plans or eta is for a Qt 5.6.1 release? > > http://wiki.qt.io/Qt-5.6-release > > doesn't mention it. > > -- Rex > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.6.1 ETA?
Curious what plans or eta is for a Qt 5.6.1 release? http://wiki.qt.io/Qt-5.6-release doesn't mention it. -- Rex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QColor and HSL's hue
Is there any technical reason (besides compatibility) why QColor::hslHueF() can't return a value between 0 and 1? I see that other projects do this: https://developer.mozilla.org/en/docs/Web/CSS/color_value#hsl() https://github.com/bgrins/TinyColor/issues/12 If the colour being represented by QColour is black, QColor::hslHueF() will return -1: http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qcolor.cpp#n1787 This makes it difficult to construct colours from the HSL getters of QColor (when making a HSL-based colour picker, for example); how would I work around the case of a negative hue? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Vulkan
On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote: > Hi All, > > Is anyone actively working on vulkan integration? Or even a QVulkanWidget? > I saw that d3d12 had a preview widget so thought it was reasonable to ask. > > If anyone isn't I'm keen to have a crack. In terms of implementation, is it > as naively simple as creating a new widget similar to the QOpenGLWidget > one, just to get a drawable canvas up and running? I believe that on Linux > a xcb_window_t is used for vulkan samples and deep in the QPA I saw it too. > > I was wondering if for a novice like me this would be feasible to actually > do? > > Does the whole rendering stack need to transfer over to vulkan? It all depends what level of integration you are after. Using a QWindow and using Vulkan with it doesn't require much. Making something equivalent to QOpenGLWidget is much more work as you have to worry about compositing QPainter content into the window too. Making a Vulkan backend for Qt Quick 2 is also more work, considerably more work than much of the other low hanging fruits that could be used to improve performance there on the existing OpenGL backend. Although, like the D3D12 backend it might give better results on windows (for Vulkan capable hardware). Putting a Vulkan backend on Qt 3D is a very real possibility and one where Vulkan could potentially make a big impact. This is something I want to investigate later after we have done a stable release or two of Qt 3D. The good thing is that Qt 3D's architecture maps very well to Vulkan (by design). Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can use both Vulkan and OpenGL on the same surface which would be another interesting option if this support becomes widespread. If you want to have a go, then certainly nobody is going to stop you and you may well get some help. We have some early proof of concept stuff we can look to tidy up and publish along these lines. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
