[Interest] Any change of a qt gamepad resurrection?
Hi list, I'm wondering whether there's any chance that the Qtgamepad module will be resurrected and made available for Qt 6+. While it may seem like an edge use case, this library is actually a fantastic fit for a cross-platform gamepad interface. There's really nothing else like it available -- all the other (maintained) cross platform libraries are all-in-one behemoths including support for sound, video, multimedia, ... . But in contrast qt gamepad was just a focused and streamlined library for gamepad handling alone. And it works so nicely for qt applications! So... is there any chance this could be revived? (fingers crossed) Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?
On Fri, 25 Feb 2022 at 01:40, Volker Hilsheimer wrote: > My question to you is: how can we make it easier, or more fun, or more > motivating to contribute to Qt, and to help with making things better? Speaking from my personal perspective: The situation with the open source releases and the new LTS update policy is the #1 thing holding me back from contributing to Qt. I just can't justify the time investment required to fix bugs in Qt if I'll only see the benefit of those fixes in 12+ months time, when the applications I use have been ported to Qt 6. Speaking from a downstream project's perspective: I'm heavily involved in the QGIS application (https://qgis.org/en/site/), which is an open-source GIS based on Qt. The QGIS project has a good history of contributing fixes to Qt for issues which impact us -- we contract out to KDAB to implement these fixes on our behalf. Over recent years we've probably invested around 20k EUR into Qt via KDAB. I'd like to think the QGIS project is a very well behaved open-source contributor in this regard! (And, for reference, there's plans to invest much more heavily in the future, especially in Qt's SVG support and QPainter framework). Unfortunately the LTS situation has made justifying the cost of funding these fixes difficult, as QGIS will remain on Qt 5 for the foreseeable future. Previously we could easily demonstrate the value of the fixes as ALL our users would (eventually!) see the fix, regardless of whether they were on Windows/Mac or linux builds. Now only a very tiny portion of our users receive the fixes (specifically, those using recent Fedora releases, as Fedora have moved away from Qt 5 upstream packages to instead following the KDE maintained 5.15 fork). Our Windows, Mac and debian based users will likely never get the fix for their Qt 5 versions. So, please, if you want to see more community contributions you NEED to reverse the LTS licensing situation (at least for the Qt 5.15 version). Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] New open source PDF support library for Qt + serveral PDF applications
On Thu, 23 Sept 2021 at 03:28, Jakub Melka wrote: > > Dear Qt users, > > I would like to inform you about my project, PDF4QT. I began this > project in year 2018 as my private project, and now, I think, it is > ready to be released for public beta testing. Long term goal of this > project is to offer full support of PDF 2.0 specification as add-on > library for Qt. I know, that Qt offers its own PDF module, but, it lacks > many functionality. My project offers much more, as optional content > handling, signature verification, encryption support, form filling, > color management, annotations, text to speech, optimalization, sensitive > content redaction, page manipulation, document merging and splitting and > much more. Also, I offer several applications, which use this library, > such as document viewer/editor, or command line tool. > > I am aware, that some other projects also implements this functionality, > but they are very often using viral licenses such as GPL/AGPL. I want to > be more benevolent, so PDF4QT project uses LGPL license, version 3, so > it is usable also in commercial applications. I do not want to restrict > people from using my library. > > Project can be found at this website: > https://github.com/JakubMelka/PDF4QT Thanks for the announcement Jakub! I had a quick look at the repo and I'm very happy to see that your library supports rendering PDF content directly to a QPainter. That's something I've lng desired! One quick question regarding this: is content rendered to QPainter devices as vector objects? Or is the PDF content rasterised and the drawn as images to the painter? Kind regards, Nyall > > And public beta release is available here: > https://github.com/JakubMelka/PDF4QT/releases > > I hope you will find my 3-year work useful. > > PS. I will be very happy if you can contribute in a form of testing, > advices, opinions... But I also want to keep control of the rights to my > project, so if you want to contribute, Contributor License Agreement > must be signed. > > Please do not respond on my email, but if you want to discuss this > software, use following discussion forum: > https://github.com/JakubMelka/PDF4QT/discussions > > Best regards > > Jakub Melka > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Retrieving view scale factor when painting a QGraphicsItem in Qt 6
Hi list, While attempting to port an application to Qt 6, I've hit a dead end. In the Qt 5 code we use the QStyleOptionGraphicsItem::matrix value in the paint override in order to determine the current view scaling, and then generate images using the corresponding dpi. We do this to avoid unnecessary work -- if the view is scaled out to 50%, then it's pointless generating the images at the same number of pixels as when the view is scaled to 100%. Now, in qt 6 QStyleOptionGraphicsItem::matrix has been removed, and I am struggling to find any alternative approach to handling this situation. There's horrible hacks you can do where you could retrieve views using QGraphicsScene::views(), but that method only works if a scene is used in a single view... because otherwise you still have no way of knowing from QGraphicsItem::paint exactly WHICH view the item is currently being painted for. (I can't use the "widget" argument of QGraphicsItem::paint because a QGraphicsEffect is set for the item, so the widget argument is always a nullptr value). How can this situation be handled in Qt 6? Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 23
On Tue, 23 Mar 2021 at 15:24, Tuukka Turunen wrote: > > > Hi, > > Feedback on the Qt 6 API is valuable and we are very interested in it. > Portability was one of the key design principles and we have avoided making > changes when not needed. That said, there can surely be some items that are > unnecessarily changed. > > Knowing what is the problem and the intended use case helps to have this > discussion. Our API review process is fully open, but it is natural that > users do not want to necessarily engage in it. So we welcome the feedback on > the API also now and will try to seek ways to improve based on it. Please Tuukka, your open-source users are BEGGING you to revisit the 5.15 LTR policy. Regardless of how actively we maintain our codebases and how proactively we've been at removing deprecated API the reality is that the vast majority of us just can't move to Qt 6 yet due to a whole range of reasons. PLEASE PLEASE PLEASE revisit this decision and open the 5.15.3+ patch releases for open source developers and projects. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt3DRender::QBuffer::dataGenerator() deprecated with no explanation?
Hi list, Building my project on Qt 5.15 ends with a handful of deprecation warnings coming from Qt3DRender::QBuffer::dataGenerator() and setDataGenerator(): warning: ‘void Qt3DRender::QBuffer::setDataGenerator(const QBufferDataGeneratorPtr&)’ is deprecated [-Wdeprecated-declarations] ... /usr/include/qt5/Qt3DRender/qbuffer.h:110:30: note: declared here 110 | Q3D_DECL_DEPRECATED void setDataGenerator(const QBufferDataGeneratorPtr ); But there's absolutely no hints anywhere on what to replace this with -- even the QBuffer docs don't flag these members as obsolete! (see https://doc.qt.io/qt-5/qt3drender-qbuffer.html#dataGenerator) How can I resolve these deprecation warnings? Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On Sun, 19 Apr 2020 at 10:48, Thiago Macieira wrote: > > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote: > > I guess that's the reason for dropping the comparisons in 6.0 and, > > eventually, reintroduce it in 7.0. With the hope that we've learned the > > lesson and proceed at _specifying_ the behaviour before implementing it. > > Indeed, and implement the QVariant comparator on top of each underlying type's > spaceship operator. That way, we could order elements of the same type. For > mismatched types, QVariant can return std::partial_ordering::unordered. > > We can't do that right now because we can't rely on C++20. In fact, no current > compiler supports the spaceship operator. So that has to be Qt 7. > > For now, the feature is badly implemented and yet too many people are using > it. We can't simply remove it without giving fair warning. The warning is > given. Just to clarify -- are you saying it's been deprecated IN qt 6, or removed in qt 6? Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt3D performance, and development resources
On Wed, 15 Apr 2020 at 01:51, Charles Martin wrote: > - Where can I find more examples, tutorials and introductory information? > There are only two C++ examples on the Qt website, and both of these are very > simple. The Qt docs are very limited and incomplete. There's some good ones here: https://github.com/wonder-sk/qt3d-experiments > - Is there a community of C++ Qt3D developers? Most online material was > produced by KADB, is 4 years or older, and focuses on QML. Where are the C++ > users? The QGIS desktop application is a c++ application which makes heavy use of Qt 3d. You may find some useful code in https://github.com/qgis/QGIS/tree/master/src/3d. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QtWebkit error while building Qt5.12.7 sources
On Fri, 21 Feb 2020 at 01:52, Florian Bruhin wrote: > > On Thu, Feb 20, 2020 at 09:02:13AM +1000, Nyall Dawson wrote: > > An example: qtwebkit allows rendering of HTML content direct to a > > QPainter surface, keeping text as text objects and other components as > > vectors. This isn't possible in the webengine classes, at best you can > > render a rasterized image of a page to a painter. Without this > > capability it's impossible in Qt to render HTML content to SVG or PDF > > files without loss of quality. > > There's QWebEnginePage::printToPdf() which does keep text as text and vectors > as vectors. That's useful for some cases, but it's not a replacement. It'd be far from trivial to accurately render a PDF to a painter surface, so printToPdf can only be used in the limited case that you just require an unchanged PDF output of HTML. If you want to render additional content around the HTML then you're out of luck... Nyall > > Florian > > -- > m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org >https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ >GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QtWebkit error while building Qt5.12.7 sources
On Thu, 20 Feb 2020 at 03:06, Konstantin Tokarev wrote: > > > > 19.02.2020, 10:53, "Thiago Macieira" : > > On Tuesday, 18 February 2020 16:29:13 PST Sze Howe Koh wrote: > >> On Wed, 19 Feb 2020 at 08:05, Thiago Macieira > > > > wrote: > >> > There's no good solution for using qtwebkit. You have to stop using it. This isn't actually a solution though -- the web engine alternative is still missing a LOT of critical functionality which is exposed by qt webkit. An example: qtwebkit allows rendering of HTML content direct to a QPainter surface, keeping text as text objects and other components as vectors. This isn't possible in the webengine classes, at best you can render a rasterized image of a page to a painter. Without this capability it's impossible in Qt to render HTML content to SVG or PDF files without loss of quality. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QT_DISABLE_DEPRECATED_BEFORE and external headers
Hi list, I've been defining QT_DISABLE_DEPRECATED_BEFORE in one of my projects to avoid use of deprecated Qt methods (in prep for Qt 6!). Unfortunately, one of the external libraries in use by my project (qwt) uses the deprecated QString::null member in a public header. If I try to bump the DEPRECATED_BEFORE version to 5.9 or later, the compilation (rightly) breaks when the headers for this library are imported. I'm wondering if there's anyway around this so that I can avoid applying QT_DISABLE_DEPRECATED_BEFORE to these external headers. As further info: - QT_DISABLE_DEPRECATED_BEFORE is defined via cmake (ADD_DEFINITIONS(-DQT_DISABLE_DEPRECATED_BEFORE=0x050800)) - I tried inserting a #undef QT_DISABLE_DEPRECATED_BEFORE #include "..." #def QT_DISABLE_DEPRECATED_BEFORE 0x050800 block around the library includes, but that had no effect and the compilation block still occurred at the point of the #include Any tips? Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Question about correct way to initialize HiDPI support
On Mon, 13 Jan 2020 at 20:37, coroberti . wrote: > > Hi, > I'm joining the question and would appreciate some kind of "Best Practices" > or guidelines for dummies, perhaps, platform-specific. While I hate to add to the noise here, I've also been confused for a long time about what the recommended approach is, and have found the existing documentation sorely lacking. https://doc.qt.io/qt-5/highdpi.html is sorely in need of a rewrite from someone knowledgeable about this issue. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Zooming with QGraphicsView/QGraphicsItem
On Sat, 10 Aug 2019 at 05:29, Israel Brewster wrote: > > So using QGIS to convert my .shp files to .svg, and then loading the result > in a QGraphicsSVGItem works like a charm - thanks! The only drawback I’m > seeing is zooming performance. It *looks* good, but is a tad sluggish. When > using QGIS, I noticed that it was compiled against Qt as well, but when they > zoom, the actual image redraw is delayed until the zoom is complete. That is, > when zooming in, things get pixelated until you pause, whereupon they are > re-drawn correctly. The end result is that things look worse when zooming, > but zoom performance is lag-free. Is this behavior easily obtainable, such as > through a setting on the QGraphicsSVGItem or perhaps the QGraphicsView, or is > QGIS doing something completely different, such that I would have to do a lot > of re-implementation to accomplish said effect? What QGIS is actually doing here is rendering the vector to a QImage in a background thread, and then when this rendering is complete the QImage is cached and used painted inside an item in the scene. Zooming triggers an update of the cached QImage from the vector content in the background, so you see the pixelated version temporarily until the new image is ready. This means the main GUI thread/scene is always responsive and isn't impacted by complex vector content. Unfortunately, it's not anything which can be achieved easily through the existing Qt API -- you'll need to setup the background thread and cached image updates yourself. The relevant code parts get a little tricky, because they rely on QGIS' map renderer, but look around: https://github.com/qgis/QGIS/blob/master/src/gui/qgsmapcanvas.cpp#L518 https://github.com/qgis/QGIS/blob/master/src/gui/qgsmapcanvas.cpp#L595 https://github.com/qgis/QGIS/blob/master/src/gui/qgsmapcanvasmap.cpp#L33 https://github.com/qgis/QGIS/blob/master/src/gui/qgsmapcanvasmap.cpp#L61 > When zooming out, areas that were outside the window remain empty until you > pause, at which point they are drawn. In recent versions we do things a little different, and: 1. render the visible portion of the vector to the cached image and show on the item as quickly as possible 2. trigger a separate background job when this is done, to render portions of the vector just outside the visible extent Again, this keeps the main view update as fast as possible, while giving nicer results when zooming out (less chance of missing image portions which were originally out of view). Hope this helps! Nyall > > --- > Israel Brewster > Software Engineer > Alaska Volcano Observatory > Geophysical Institute - UAF > 2156 Koyukuk Drive > Fairbanks AK 99775-7320 > Work: 907-474-5172 > cell: 907-328-9145 > > On Aug 8, 2019, at 8:19 AM, Francis Herne wrote: > > You should definitely look at QGIS: > https://qgis.org/en/site/index.html > > It's open-source and has an excellent map-rendering implementation including > shapefile support. > > -Francis H > > > From: Israel Brewster > Sent: 8 August 2019 16:55:49 BST > To: Brad Pepers > Cc: Interest > Subject: Re: [Interest] Zooming with QGraphicsView/QGraphicsItem > > I do have .shp files for the coastlines - perhaps I could convert those to > something I could use? If I can get vector data, how would I go about > utilizing it? > > I played around a bit with loading different image files, but so far the > performance has been unacceptable - the entire app locks up for several > seconds when displaying the higher resolution images. I think Vector would be > a better way to go, if I can figure out how. Thanks! > --- > Israel Brewster > Software Engineer > Alaska Volcano Observatory > Geophysical Institute - UAF > 2156 Koyukuk Drive > Fairbanks AK 99775-7320 > Work: 907-474-5172 > cell: 907-328-9145 > > On Aug 7, 2019, at 10:12 PM, Brad Pepers wrote: > > In the end the answer is to get the coast as vector data instead of a raster. > The raster is going to be at a fixed map scale and any scale above or below > is going to extrapolate or interpolate the results eventually ending in poor > results because there just isn’t the information needed or too much > information is being lost. Having different resolutions should help and you > can keep multiple levels and switch between them at appropriate times (LOD). > Those are your best bets if you can’t get the actual vector data! > > -- > Brad > > > On Aug 7, 2019, at 12:01 PM, Israel Brewster wrote: > > I have a QGraphicsScene/QGraphicsView that I am using to display a map (and > some data). The map is in the mercator projection, with the x and y > coordinates of the scene corresponding to map coordinates, so the background > images are rather large. Images are loaded into a QGraphicsObject which is > then added to the scene. The object types are defined by a third-party > library, so I don’t have the option of using different objects, such as > QGraphicsPixmapObject or
Re: [Interest] Zooming with QGraphicsView/QGraphicsItem
On Sat, 10 Aug 2019 at 01:55, Israel Brewster wrote: > > Thank you. QGis did indeed allow me to open my Shapefiles and save them as > SVG (though it messed up the viewBox attribute, so I’m still trying to figure > out how to get that to not crop the image). That's due to an unfortunate, long-standing Qt bug (Qt SVG export from QPainter ignores clipping paths). Nyall > --- > Israel Brewster > Software Engineer > Alaska Volcano Observatory > Geophysical Institute - UAF > 2156 Koyukuk Drive > Fairbanks AK 99775-7320 > Work: 907-474-5172 > cell: 907-328-9145 > > On Aug 8, 2019, at 8:19 AM, Francis Herne wrote: > > You should definitely look at QGIS: > https://qgis.org/en/site/index.html > > It's open-source and has an excellent map-rendering implementation including > shapefile support. > > -Francis H > > > From: Israel Brewster > Sent: 8 August 2019 16:55:49 BST > To: Brad Pepers > Cc: Interest > Subject: Re: [Interest] Zooming with QGraphicsView/QGraphicsItem > > I do have .shp files for the coastlines - perhaps I could convert those to > something I could use? If I can get vector data, how would I go about > utilizing it? > > I played around a bit with loading different image files, but so far the > performance has been unacceptable - the entire app locks up for several > seconds when displaying the higher resolution images. I think Vector would be > a better way to go, if I can figure out how. Thanks! > --- > Israel Brewster > Software Engineer > Alaska Volcano Observatory > Geophysical Institute - UAF > 2156 Koyukuk Drive > Fairbanks AK 99775-7320 > Work: 907-474-5172 > cell: 907-328-9145 > > On Aug 7, 2019, at 10:12 PM, Brad Pepers wrote: > > In the end the answer is to get the coast as vector data instead of a raster. > The raster is going to be at a fixed map scale and any scale above or below > is going to extrapolate or interpolate the results eventually ending in poor > results because there just isn’t the information needed or too much > information is being lost. Having different resolutions should help and you > can keep multiple levels and switch between them at appropriate times (LOD). > Those are your best bets if you can’t get the actual vector data! > > -- > Brad > > > On Aug 7, 2019, at 12:01 PM, Israel Brewster wrote: > > I have a QGraphicsScene/QGraphicsView that I am using to display a map (and > some data). The map is in the mercator projection, with the x and y > coordinates of the scene corresponding to map coordinates, so the background > images are rather large. Images are loaded into a QGraphicsObject which is > then added to the scene. The object types are defined by a third-party > library, so I don’t have the option of using different objects, such as > QGraphicsPixmapObject or something. > > This works fine when I’m zoomed in to the map. Coastlines are nice and sharp, > with no issues: > > > However, when I zoom out, the coastline becomes quite pixelated, and > difficult to see in places: > > > How can I fix this? My first thought was to change the size of the background > image so it could scale better, but that didn’t seem to help. In retrospect, > this makes sense: at the end of the day, the background image has to be the > correct size for the mercator projection, so while I can certainly change the > pixel density, the overall size, and thus how much scaling is needed to > display a given area, is fixed. > > --- > Israel Brewster > Software Engineer > Alaska Volcano Observatory > Geophysical Institute - UAF > 2156 Koyukuk Drive > Fairbanks AK 99775-7320 > Work: 907-474-5172 > cell: 907-328-9145 > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QDockWidget alternative
On Sun, 23 Jun 2019 at 06:51, Martin Marmsoler wrote: > > Hello, > > I'm searching an alternative to the QDockWidget, because it has some > limitations. Maybe somebody knows an open source implementation of something > I'm searching for. > The alternative should be similar to the dock in Matlab. There is the > possibility to hide the dock by pressing a button when it is not floating. > Then only a tabed widget is visible. When hovering this label, the dockwidget > is visible, but it overlaps the Mainwindow and is not next to the MainWindow. > When leaving the dock it is minimized by it self. This is usefull to save > space if you have a small monitor. > > Here is a small demonstration how it looks like in Matlab: > https://www.dropbox.com/s/mehm4j1q5yxof2i/MinimizingDock.mp4?dl=0 I'm not sure what the current state of it is, but you could look at the Qt based Indigo Dock project ( https://github.com/nitramr/indigoDock ) Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] adding widgets to native file dialogs?
On Wed, 27 Feb 2019 at 20:27, René J.V. Bertin wrote: > > Hi, > > What options are there to add widgets (e.g. a preview widget) to QFileDialog > instances or descendants, which will work with "native" dialogs? > > I'm looking into an issue with Scribus where this is achieved by embedding > the entire QFileDialog instance into its parent, i.e. by setting it to be a > Qt::Widget. This works fine with non-native dialogs, but with the native > dialogs I've tested it with (KDE & Mac) the dialog still opens as an > additional window; on Mac it will even appear behind the window in which it's > supposed to be embedded (and which retains focus so the dialog cannot be > used). > That issue appears to be due to a design oversight (?) in Qt, where the user > and the application interact with 2 distinct dialog windows. > > I've looked around for answers in the usual places; there are quite a few but > they all use non-native dialogs... On this same note... is there any workaround which allows for setting of sidebar URLs with native dialogs? This is definitely supported on some platform's native dialogs, e.g. standard Windows file dialogs can be created with custom folder shortcuts in the sidebar. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Priority of bugs
On Fri, 21 Sep 2018 at 04:04, Krzysztof Kawa wrote: > > Christoph Feck wrote: > > in practice most bug fixing is spent to make the > > new features actually work. There is no point in adding features, if > > they are not useable because of bugs. > > Funny you should say that. I actually wish this was true, but take a > look at the sad history of QTBUG-52108 for an example of how it really > is. A new feature came out in 5.6 in a state that made it unusable > from the start and it also broke some previous stuff on the way. FWIW, I've also encountered some serious issues with this functionality under gnome, where floating docks will get stacked under main windows if they were previously tabbed and restoreState is called. The only "fix" is to disable this feature by not setting QMainWindow::GroupedDragging. Nyall ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Correct way to use QStyle::standardIcon/standardPixmap with QStyle::StandardPixmap
Hi list, In my code there is a bunch of calls which try to create QIcons from QStyle standard pixmaps, like: QIcon groupIcon; groupIcon.addPixmap( style()->standardPixmap( QStyle::SP_DirClosedIcon ), QIcon::Normal, QIcon::Off ); groupIcon.addPixmap( style()->standardPixmap( QStyle::SP_DirOpenIcon ), QIcon::Normal, QIcon::On ); While this works correctly, in that using the icon for a model's DecorationRole shows either an open or closed icon based on the item's expanded state, it has two issues: 1. It's not hi-dpi friendly, and the icons are tiny 2. QStyle::standardPixmap is marked as obsolete, with QStyle::standardIcon being described as the preferred approach. I'm unsure how to translate the above code to QStyle::standardIcon though. QIcon groupIcon( style()->standardIcon( QStyle::SP_DirClosedIcon ) ); works nicely for closed items, and looks great on hidpi. But I can't see how I would add the SP_DirOpenIcon state. There's no equivalent method like "QIcon::addIcon" like there is QIcon::addPixmap. What's the correct approach to take here, which is hi-dpi friendly and future proof? Cheers, Nyall ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
