[Development] Qt3D features plan ?
Hi everyone, I'm happy to see that the Qt3D component is finally being actively developed. I guess such a complex piece of software has some plans behind, in terms of architecture and features. I would like to know if it possible for Dr. Harmer and pals to share a rough features plan within this list. Not asking for promises :) I'm well aware of the open source business. I'd only like to peek what's going on to know if my project can count on Qt3D in the future or if I have to move my steps on other technologies. I'd love to stay on Qt for the cross-platform promise. I need to write a real time 3D visualizer for a lighting control application, so my key stones are deferred rendering and multiple lights (30-50 would do) On a footnote, as a pure suggestion, it would be nice to have a test suite for Qt3D like the one three.js has: http://threejs.org/examples/ Keep up the awesome job ! Massimo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Detecting new ports in QSerialPortInfo
Hi. No, as I know, this issue wasn't discussed yet in plans. But this feature was available at the primogenitor - QSerialDevice library: https://gitorious.org/qserialdevice/qserialdevice/source/55692a7caf58fba51f859b8e015b2bbd7d92e1b6:src/qserialdeviceenumerator/serialdeviceenumerator.h so, you can take appropriate code from there.. PS: also you can look to the QExtSerialPort's code. Best regards, Denis 2014-03-28 13:19 GMT+04:00 Àlex Fiestas afies...@kde.org: Are there any plans to add a non-polling based system to detected added/removed ports in QSerialPortInto? If not, would such feature be welcomed? Cheers. ___ 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] New snapshot build from Qt 4.8.6 available
I confirm that this change is needed, and I have multiple workarounds for it in the code that uses Qt 4.8. Thanks, Kuba On Mar 18, 2014, at 6:25 AM, Adam Strzelecki o...@java.pl wrote: Hi, I there any chance to backport object_parallel_to_source to 4.8.6 as reported here: https://bugreports.qt-project.org/browse/QTBUG-34871 This is really tiny change: https://qt.gitorious.org/qt/qtbase/commit/47df12225918ba82abe35921af19e547717da58b?format=patch Best regards, -- Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D features plan ?
Hi, On 28/03/2014 16:35, Massimo Callegari wrote: Hi everyone, I'm happy to see that the Qt3D component is finally being actively developed. I guess such a complex piece of software has some plans behind, in terms of architecture and features. I would like to know if it possible for Dr. Harmer and pals to share a rough features plan within this list. Not asking for promises :) I'm well aware of the open source business. I'd only like to peek what's going on to know if my project can count on Qt3D in the future or if I have to move my steps on other technologies. I'd love to stay on Qt for the cross-platform promise. I need to write a real time 3D visualizer for a lighting control application, so my key stones are deferred rendering and multiple lights (30-50 would do) Nice! Interesting use-case. The exact features will depend partly upon your platform. If you are using a desktop-based system then yes we are aiming to support deferred rendering or in fact any other rendering technique. Unfortunately ES 2 doesn't support multiple render targets. We don't have any documentation ready yet (we will start on this soon) but here's some key points: * Front end will be accessable via QML or C++ * Uses Entity/Component/System architecture for flexibility and ease of future development * Systems are implemented as aspects that operate on their own copy of the scene data that is relevent to them. This allows the aspect systems to only care about Entity's composed of certain combinations of Components and to process them with only minimal locking. * The aspects will use a job-based approach to doing their work for each frame. * It should be quite easy to add addition Components and aspects/systems later e.g. for physics, audio, AI, logic, whatever. * One component provided by the renderer aspect/system allows us to completely define the rendering method used by means of a framegraph. So whether you wish to use a forward renderer, deferred renderer or anythng else can be completely defined through data only in the Entity/Component object tree (defined from either QML or C++). * We will provide a default set of Effects and accompanying framegraphs to make it easy to use out of the box. We also aim to make it as simple as possible to extend/reconfigure whilst maintaining the flexibility we are after. There are still some parts of the puzzle that need to be worked out but I don't think there is anything insurmountable there. On a footnote, as a pure suggestion, it would be nice to have a test suite for Qt3D like the one three.js has: http://threejs.org/examples/ Yes. We will build up a set of examples, tests and benchmarks as we progress. If you have any further questions, please feel free to ask here or ping us on #qt-3d. Keep up the awesome job ! All the best, Sean Massimo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] XDG icon theme support
Hi friends, Current Qt's implementation of QIcon::fromTheme violates xdg icon naming specification ( http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html ). By specification if icon drive-removable-media-usb is not found implementation should fallback to drive-removable-media and so on until the icon is not found. If icon is not found at this theme is should make lookup at parents' themes. The dash “-” character is used to separate levels of specificity in icon names, for all contexts other than MimeTypes. For instance, we use “input-mouse” as the generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style. For example this makes possible to use most of icons provided by Oxygen theme (which has really specific icons like network-wireless-connected-50) with more generic fallbacks under with other themes (like network-wireless). In C++ the possible workaround is to use something like QIcon::fromTheme(network-wireless-connected-50, QIcon::fromTheme(network-wireless-connected. QIcon::fromTheme(network-wireless, QIcon::fromTheme(network but it's not the most efficient and elegant solution. And it still violates the specification in the case if: 1. Current theme contains icons network-wireless-connected-50 and network-wireless 2. Parent's theme contains icons network-wireless-connected-50 By specification current theme's network-wireless icon should be choosed, but not the parent's network-wireless-connected-50 for better user experience as current implementation does. Also the pain starts if one would decide to change the icons theme at runtime (i.e. by changing KDE's settings). Original icon's names are already lost at this point (as we iterated by prefixes until the valid icon) so invalid or no icon will be chosen after the theme change. In QML the situation is even worse, it's not possible at all to determine from QML if icon is correct one so it's totally impossible to do anything and it ruins my life :( Was this done specially or it should be considered as a bug? If the first option what was the main idea? I would like to implement the correct behavior by the following changes: 1. Never return fallback from QIcon::fromTheme if it is null. So it will be possible to show the icon once the correct theme will be shown. 2. Change the logic of QIconLoader::findIconHelper to fit the specification by adding check for fallback icons. If the changes will be done and accepted is there any hope to have them in Qt 5.2.* (so it will come once to Ubuntu Trusty)? -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
