Re: [Development] Implementing small SVG 1.1 features (as opposed to SVG Tiny 1.2)
On 10/13/21 11:58, Giuseppe D'Angelo via Development wrote: On 13/10/2021 11:43, Albert Astals Cid via Development wrote: Should we allow some small features outside of the declared SVG Tiny 1.2 support? I'm not against in principle (liberal in what you accept, etc.etc.), but as you say, it's going to become a nightmare to document exactly what it's supported or not. It is simplest to not document any extra features. A Tiny conformant renderer is not supposed to render Full features wrong on purpose; if it renders those correctly, so be it. If it doesn't, nobody is to blame. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How bad QList really is
On 04/28/20 11:04, Kevin Kofler wrote: QList and QVector should remain as they are in Qt 5. But ... some developers are not able to understand the difference, so we need to remove one class!!1! ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using SSE/NEON in Qt 6
On 02/06/20 12:45, Lars Knoll wrote: As a side note: SSE 4.1 offers some nice additional instructions that would simplify some of the operations. Should we keep the minimum requirement for SSE at version 2, or can we raise it to 4.1? I have a classroom-sized deployment of Intel Centrino Duo based tablets which only support sse, see2, and pni (sse3), but not tni (ssse3) or any later additions. Christoph ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/04/19 12:56, Volker Hilsheimer wrote: Hi, QApplication::globalStrut is a property that has outlived its purpose. IIRC, then I added that in the early Qt 2 days, anticipating that with Qt/Embedded we might see our widgets landing on touch screens “any moment now”. The idea was to have a global setting that ensured that widgets and other interactables (such as menu items, list items, checkbox markers etc) are at least x,y pixels large. Well, the world has moved on, and the value has never been consistely used in styles or widgets anyway. I am not in the position to object code changes, but the Skulpture widget style fully respects the globalStrut for all widgets since many years. https://kdepepo.wordpress.com/2009/03/12/global-strut-feature/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to get Qt_5.9.1_PRIVATE_API
On 11.10.2017 08:56, Martin Koller wrote: on openSuse 42.2 I have a self-built 5.9.1 version and also the openSuse 5.9.1 installed one. For some reason (which is not important for my question) my application picks up the openSuse library but fails with the error libQt5Core.so.5: version `Qt_5.9.1_PRIVATE_API' not found (required by /usr/lib64/libQt5Quick.so.5) I just want to know how do I have to configure my self-built Qt so that the missing private_api symbol is included? See patch 'tell-the-truth-about-private-api.patch' at https://build.opensuse.org/package/show/KDE:Qt5/libqt5-qtbase ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How is Quick Controls 2 deployment meant to be ?
On 08.07.2017 13:24, Massimo Callegari via Development wrote: 2) Security ? There is none. If you deploy an application using a TextField control with echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a password. In general, an end user can seriously mess up an application by changing a few text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and compromise my system. If you have root access. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QT expert's help required for mentoring Linux Foundation GSoC project.
On 09.06.2017 17:17, Aveek Basu wrote: This is Aveek from Linux Foundation. Currently myself and Till Kempeter, are working as the org admins of the LF GSoC project. This year have undertaken a project of developing the Common Print Dialog for Linux ( https://wiki.linuxfoundation.org/gsoc/google-summer-code-20 17-openprinting-projects). This project will for sure improve the user experience on how we all print in Linux today. The project involves development of the complex Common Print dialogs in QT. We are badly in need of someone who has development experience in QT upstream to guide our students. It will be of great help if someone from the community could could show interest. Is the aim to merge this printing dialog into Qt sources to replace the current Qt print dialog? http://doc.qt.io/qt-5/qprintdialog.html If yes, then the GSoC students should contact Qt developers at the Qt development mailing list, and discuss their plans. Unfortunately, the former QPrinter maintainer is busy with his paid job, so I see difficulties here. If not, then I suggest that the GSoC students just post questions to the Qt interest mailing list, #qt IRC channel, or official Qt forum at https://forum.qt.io/ Please do not use any other Qt mailing list. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
On 25.05.2017 19:03, André Somers wrote: On 25 May 2017, at 18:40, Christoph Feck <cf...@kde.org> wrote: On 25.05.2017 13:53, André Somers wrote: Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning or taking it as and argument in various places. That's almost only reason why I use QList in my code[*]. If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with this APIs will break, unless QList will become an alias of QVector. [*] And, fwiw, almost only reason I use QString, but that's off-topic here I think you bring up a good point there. Would not the best way out be to fix exactly this problem? If these functions would not return a container, but some type of view into such a container, that would leave users free to choose the type of container they need for their job instead of being forced into the direction Qt choose for its API. A view might take the form of a pair of iterators, a range, or perhaps even some specialized class that basicaly wraps a pair or iterators and that provides convenience functions to/from the Qt containers. If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?) Indeed in most cases you really do not need this feature, but unless there will be a compile-time error, we will see subtle bugs/crashes introduced where that feature was relied upon. I have seen many crashes in the big KDE code base from Qt3->Qt4 porting just because the code compiled fine (e.g. after mass-renaming class or method names), but semantics changed in subtle or unexpected ways. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
On 25.05.2017 13:53, André Somers wrote: Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning or taking it as and argument in various places. That's almost only reason why I use QList in my code[*]. If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with this APIs will break, unless QList will become an alias of QVector. [*] And, fwiw, almost only reason I use QString, but that's off-topic here I think you bring up a good point there. Would not the best way out be to fix exactly this problem? If these functions would not return a container, but some type of view into such a container, that would leave users free to choose the type of container they need for their job instead of being forced into the direction Qt choose for its API. A view might take the form of a pair of iterators, a range, or perhaps even some specialized class that basicaly wraps a pair or iterators and that provides convenience functions to/from the Qt containers. If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Printer-specific options in Qt5's print dialog (Linux, CUPS)
On 31.01.2017 09:55, Michael Weghorn wrote: [...] The links about the plans for the Qt print system that John provided in his email [1] give some kind of overview, but are currently not enough for me to deduce the concrete next steps that need to be taken for the implementation. If you (or somebody else) can give more information on that, this is certainly something we would be happy about and that we will examine more closely. According to http://www.layt.net/john/blog/odysseus/focusing_on_printing_in_qt_5 John also did a big triage of reported issues in the printing system, which has a master bug at https://bugreports.qt.io/browse/QTBUG-37696 [1] http://lists.qt-project.org/pipermail/interest/2015-September/018700.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 05.01.2017 17:12, Edward Welbourne wrote: Sérgio Martins very helpfully linked to KCalendarSystem - thank you. One of the things we should clearly aim for is to make it easy for KCalendarSystem to (when its developers care to and can find the time, with no pressure to do so) adapt to use QCalendarSystem and the adapted QDate. TODO: I also need to find and talk to its maintainers. Maintainer for KCalenderSystem was John Layt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [HiDPI] Rethinking the scaling algorithm
On 16.11.2016 17:22, Niccolò Belli wrote: Hi Morten, I'm sorry, I missed your reply. RoundPreferFloor Round up for .75 and higher RoundPreferFloor is the new default. Do you think this is sufficient? qFloor would help for my monitor, of course. Unfortunately the default (RoundPreferFloor) wouldn't be enough, because my monitor is 282.42 PPI and 282.42/96=2.94 Also RoundPreferFloor would break the 4K 27" monitor previously mentioned, because 161.18/96=1.6998 I thought about a better default: round up for ratios lesser than 2 but always round down for ratios higher than 2. Such a way the new formula will work for both categories of monitors: it will basically keep the current algorithm but it will be a bit more conservative when handling extreme scalings (>=3x). The 4K 27" will get 2x scaling, the 13" 3200x1800 will get 2x scaling and both a 13" and a 15" 4K monitors will get 3x scaling. It seems perfect to me, especially if you plan to change the base DPI on a per-OS basis. There is no perfect solution except to make sure the user can configure the pixmap scale (as he can configure the font size). I have Firefox set to 1.5 scaling on a 163 DPI display. Neither 1, nor 2 looks good. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 17:20:04 Guido Seifert wrote: Minor OT, but I am too curious... do you have an example? Are there really cases were turning lower case into upper case or vice versa changes the length of a string? office (4 code points) - OFFICE (7 code points) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wednesday 11 February 2015 17:23:51 Christoph Feck wrote: On Wednesday 11 February 2015 17:20:04 Guido Seifert wrote: Minor OT, but I am too curious... do you have an example? Are there really cases were turning lower case into upper case or vice versa changes the length of a string? office (4 code points) - OFFICE (7 code points) Looks like I cannot count, but you get the idea. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 subpixel rendering differs from Qt4
On Monday 10 November 2014 12:04:27 Stanislav Baiduzhyi wrote: Have anyone noticed that Qt5 subpixel font rendering is different from Qt4? Yes, https://bugreports.qt-project.org/browse/QTBUG-40971 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
On Tuesday 07 October 2014 23:19:23 Tony Van Eerd wrote: The problem is serious enough, indeed, that Python 3 has resorted to a hack where they use a private Unicode range to encode the bytes between 128 and 255 in strings that fail normal decoding. I think that putting this hack into QString is unthinkable, and the concept of a platform string has to be taken with heads up and in a manner that will make it useful, usable and unobtrusive. I don't claim that it's a trivial task, but then I'm not asking anyone else but myself to deal with it :) Cheers, Kuba I think that hack should be given serious consideration. Sure it is a hack, but it might still be the best solution. We are using the same hack in KDE4Libs, but it relies on QFile::setDecodingFunction. Unfortunately, this function is no longer available in Qt5, so in a few years, we will see the same long discussion as in https://bugs.kde.org/show_bug.cgi?id=165044 -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New company name for Qt part of Digia and unified web site
On Tuesday 16 September 2014 14:11:26 Knoll Lars wrote: In addition, we also now have a new company name for the Qt part of Digia. It’s simply ‘The Qt Company’. How boring! But you can rename the company hundred times... For me, it will always be The Trolls™ ;) Christoph Feck (kdepepo) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Debugging crashes in QML / QtDeclarative [was: Question about Qt's future]
On Tuesday 22 April 2014 23:11:59 Kleint Friedemann wrote: Hi Christoph, Christoph Feck wrote: Not speaking for Michael, but let me add that C++ is much easier to debug compared to QML, if you get a crash. We have nearly hundred backtraces in the Plasma bug tracker that point back to crashes in QtDeclarative, without a single clue where the crash comes from. For examples see bugs 328234, 332131, 331060, 333621, 333532, 34, 332995, or 332646 to cite only some fairly recent ones. Please take a look at https://bugreports.qt-project.org/browse/QTCREATORBUG-11144 and the related changes in Qt Creator 3.1 . When doing pure C++ debugging, Qt Creator now has a context menu entry Load QML frames in the stack window. This basically checks the stack trace for a value of a QV4::ExecutionContext *, tries to extract the JavaScript stack frames from it and displays those frames in addition to the C++ frames. I wasn't aware it's actually possible to get QML backtraces. I filed an enhancement request for KDE's crash handler DrKonqi as KDE bug 333816, citing your and Simon's reply. Thanks! -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team openSUSE Review Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On Monday 21 April 2014 05:27:33 Joshua Kolden wrote: I’m curious why you are not interested in QML. [...] I see no reason to stay with Qt Widgets at all other than legacy application support. So what is your concern? [...] Not speaking for Michael, but let me add that C++ is much easier to debug compared to QML, if you get a crash. We have nearly hundred backtraces in the Plasma bug tracker that point back to crashes in QtDeclarative, without a single clue where the crash comes from. For examples see bugs 328234, 332131, 331060, 333621, 333532, 34, 332995, or 332646 to cite only some fairly recent ones. I am not blaming QML here, all those bugs are possibly caused by errors in Plasma itself, but the fact that you cannot see from the backtrace what caused the crash is a major concern for me. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team openSUSE Review Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FTP in Qt5
On Friday 07 March 2014 12:05:09 Tom Isaacson wrote: I needed this functionality in our application so I've written a demo app to handle pausing and resuming HTTP and FTP downloads: https://github.com/parsley72/QtDownloadManager We use Qt 4.8.2 so the FTP download is implemented with QFtp. We're intending to migrate to Qt5 later this year but since QFtp is deprecated in Qt5 this functionality isn't possible. Is https://qt.gitorious.org/qt/qtftp/source/readme.txt an option? -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team openSUSE Review Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling SSE2 by default on x86 builds (32-bit)
On Sunday 10 November 2013 08:19:03 Thiago Macieira wrote: [...] Here's what we're proposing: 1) in the Linux 32-bit packages generated by the Qt Project, we switch to generating SSE2 code by default and also ask GCC to use that instead of x87 for FPU operations (add to the command-line: -msse2 -mfpmath=sse). [...] From http://en.wikipedia.org/wiki/SSE3 : There is also a new instruction to convert floating point values to integers without having to change the global rounding mode, thus avoiding costly pipeline stalls. According to http://www.taffysoft.com/pages/20120418-01.html the SSE3 set is available on all CPUs since 2005, so I suggest to go for SSE3 (not SSSE3) as the default. Additional benefits of this change are: a) all FP math done in Qt will be done using SSE instead of the slower x87 stack Note that x87 math has higher precision, because it computes with 80 bits internally before rounding final results, but I doubt it has any impact on the computations that Qt does. b) the drawhelpers will be unconditionally enabled c) the SSE2-based code for the Latin1 and UTF-8 codecs will be unconditionally enabled I have seen crashes ending in Qt SSE2 helper functions, probably because they access more data than needed due to the SIMD nature of the instructions. This can cause access violations on page boundaries. Has the Qt SSE2 code been audited for avoiding these? -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Saturday 09 November 2013 12:50:24 Olivier Goffart wrote: I think milestones could rather be: 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space Needs a 48 bit QImage. I remember a proposal to add support for larger bit depths was rejected, but cannot find the reference right now (to check how old the proposal was). Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Beta, possible memory leak(s)
On Wednesday 30 October 2013 11:36:12 Luka Vilar wrote: Hi all, using Qt 5.2 beta on Windows 7 x64, compiled with Visual Studio 2012 update 3 i am getting two annoying reports of memory leaks. First is from using ICU and not calling u_cleanup() API on module unload and the second is from QPrinterInfo::defaultPrinter() not cleaning up QPlatformPrinterSupport singleton. I know this is not high priority issue but still i would be nice to get rid of this annoyances, so when using leak detection tools developers would only get their own leaks. Best regards, Luka Please use https://bugreports.qt-project.org/ to report issues. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wednesday 02 October 2013 00:41:56 Thiago Macieira wrote: On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote: On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. In order to properly do that, we should remove all try/catch blocks in QtCore and replace with scoped pointers and scoped values. We should let the destructors handle the cleanup. Sounds a bit more work than simply disabling exceptions, so might be something out of scope for 5.x. Turning exceptions off may or may not get you the backtrace. It may also get you a std::terminate or a crash. A crash is fine, as long as I see the origin, or are you implying that those crashes would record no backtrace at all? For example, https://bugs.kde.org/show_bug.cgi?id=325360 shows the backtrace of a re-thrown exception, but unless there are reproducible steps, the report is useless, because the trace originates from the event loop. We have hundreds of those reports, and the hope to find a reporter who can follow linked gdb instructions is next to zero. Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A bug or not a bug, that's the question
On Monday 26 August 2013 13:53:38 Kurt Pattyn wrote: QTextCodec *codec = QTextCodec::codecForName(UTF-8) codec-toUnicode(someUtf8StringContainingNonCharacters, …); When toUnicode is called with a string containing Unicode non-character codes, QTextCodec returns a conversion error. [...] But, non-character codes are valid in Unicode, and should be maintained as is; Unicode published a corrigendum clarifying the handling of non-characters: http://www.unicode.org/versions/corrigendum9.html. What do you mean with maintained as is? The document you cite does not mention anything related to invalid UTF-8. Since this is the Qt development list, please discuss code changes needed to clarify what you mean. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A bug or not a bug, that's the question
On Monday 26 August 2013 14:39:50 Kurt Pattyn wrote: On 26 Aug 2013, at 14:26, Christoph Feck christ...@maxiom.de wrote: What do you mean with maintained as is? The document you cite does not mention anything related to invalid UTF-8. Unicode strictly requires no loss of information when going between the different representations. Currently the QTextCodec class replaces the non-character codes with a replacement character. Because there was much confusion whether non-character codes were valid or not, the corrigendum was published. That document clearly states that they are valid for interchange. I did the test with UTF-8 encoded non-characters, and QTextCodec fails, so it is not unicode compliant. Since this is the Qt development list, please discuss code changes needed to clarify what you mean. I don't have any problem of solving this myself, but first I want to be sure if this is considered by the Qt developers as a bug, before I move on. I am quite new to this list, so I don't know whether this was intentional or not. For that, I don't need to point to code I think. Looking into the unit tests of QTextCodec, you can clearly see that non-characters are explicitly not allowed (so, the QTextCodec behaves as intended). So, was this intentional? Sorry, I was misunderstanding you. I thought you were talking about invalid UTF-8. I looked at the code, and it indeed has explicit handling for QChar::isNonCharacter, which should probably get removed. Christoph ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-dpi Qt best practices
On Tuesday 09 October 2012 10:37:50 Sorvig Morten wrote: While preparing an upcoming blog entry I've collected some best practices regarding raster graphics (QImage and QPixmap). These apply to internal Qt development as well. The patch is still pending so they are open for discussion. From what I know, OS X applications do not use something similar to QLayout. Widgets are positioned in absolute pixel coordinates, so they cannot adapt to different font sizes. To make it less of a burden to port those applications, Apple decided to keep the metrics, and let the OS scale them to larger pixels. To be honest, I do not like the idea to introduce the same artificial scaling factor to Qt. Our layout system already adapts to different text pixel sizes automatically. The added API looks complicated and I am irritated where I have to apply a scaling factor, and where not. Additionally, it is not clear, if I have to multiply with or divide by that factor. Examples: Lets say I want to draw text to a high resolution pixmap. What should I be doing? Does fontMetrics.height() return physical pixels or artificial points? Do I have to multiply the font point size, or use the font size the user has configured unmodified? What if I place text besides a pixmap that has text rendered into it, i.e. how can I make sure they are equally sized? How does font.setPixelSize() work? Can widgets be positioned exactly on high-DPI applications, not only in steps of 2 pixels (widget coordinates are integers)? This could introduce gaps, which can be visible even on high-DPI displays (imagine a white line between two black boxes). What happens when I save() a pixmap to a file? Is the scaling factor kept in a way, so that loading it again results in pixel-identical resolution? Is the DPI reported by the file changed as well? If I understand correctly, existing applications will automatically be upscaled by the Quartz compositor, so here we do (and cannot) change anything. For new applications, that say they are aware of high-DPI displays, we want to address each pixel on the screen individually. To do this, the dimensions of pixmaps must be in pixels. How big they eventually appear physically on screen is controlled by the screen's DPI setting, which is also used to convert font point sizes to pixel sizes. Applications that want to use units such as cm, need to query the screen's DPI setting anyway. What I would be doing is this: For applications that say they are high-DPI aware, simply return the screen's DPI, which could be 144 dpi, or even 384 dpi. For other applications, return a legacy DPI (e.g. half the value, depending on what scaling factor the compositor uses for legacy applications). QStyle has functions to return different icon sizes, and the values they return should be bigger for aware applications. If the graphics supplied is not large enough, Qt should automatically scale it (as far as I know, it refuses to do it in current versions). To me this sounds much less work to adapt an application. What am I missing? Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing Wacom support in Qt5
On Thursday 06 September 2012 00:53:37 Ariel Molina wrote: 5) Nobody cares about Wacom anyway I do, every day. I reported bugs for Qt 4, until it worked correctly on a Tablet PC, and expect me to do the same for Qt 5. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
On Monday 16 July 2012 17:42:45 alessandro.port...@nokia.com wrote: (Sorry for top-posting, as-well) Great to see Qt soon supporting color profiles! I agree with Johan that color profile handling and conversion should be an opt-in feature. I agree with the previous posters that any color correction should be in control of the application author. A single convert to appropriate colors for screen/printer call is nothing compared to the trouble of automatic conversions that cannot be undone, or only undone with loss of quality. Just a few questions: 1) Would Qt use (and ship) a color conversion library, or would the system library be used where available (e.g. on OSX and Windows)? Regarding native platform support, we should work together with Oyranos developers. While their API is horrible (maybe because it is so non-Qt'ish), they have in-depth knowledge about the theory and the praxis of color management. Maybe with their expertise, we can create a nice API for application developers to interface the platforms. 2) Would the screen color profiles that are specified in the system screen settings automatically be used? 3) Sometimes, there are different profiles defined -one per screen (and printer)-. Would we have an additional parameter to specify the screen id? Color correction opens another can of worms: Qt only supports 8 bit per component images, which was state of the art twenty years ago. Having QImage support at least 16 bit per component would not only increase precision when doing conversions, but also allow it to load modern image formats, such as PNG, PBM, TIFF, EXR, JPEG-LS, JPEG-2000, etc. (I am not talking about pixmaps or rendering here, the final result may be displayed at 8 bit precision, but internally Qt needs more depth when it comes to correctly colored images). Also, the new printing framework in Qt should use the new QtColorManagement module, so some coordination with experts would be needed. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team I hope not to complicate things with my questions :) From: development-bounces+alessandro.portale=nokia@qt-project.org [development-bounces+alessandro.portale=nokia@qt-project.org] on behalf of Dermenakis Alexandros (Nokia-MP/Oslo) Subject: [Development] Color Profile support on Qt Hi, I am working on adding support for color profiles on Qt 5. It is under discussion if the default behavior of QImage shall be: 1) converting from an embedded color profile to the screen color profile when loading an image OR 2) keep the loaded image in the source color space, until the programmer explicitly requests color conversion. Solution 1 : QImage(, QColorProfile = Preserve_Embedded) * Keeps the old Qt behavior (providing backwards compatibility without the need of tweaking the code) Solution 2 : QImage(, QColorProfile = Convert_To_Screen) * Fixes some bugs in applications that use QImage directly for visualizing images (i.e. okular) * Better for newly developed applications since color profile conversion takes place automatically Presently when an image is loaded it always gets interpreted as sRGB and no color conversion takes place. Thanks in advance! From: development-bounces+alessandro.portale=nokia@qt-project.org [development-bounces+alessandro.portale=nokia@qt-project.org] on behalf of ext e8jo...@gmail.com [e8jo...@gmail.com] Sent: Monday, July 16, 2012 17:03 To: development@qt-project.org; Dermenakis Alexandros (Nokia-MP/Oslo) Subject: Re: [Development] Color Profile support on Qt Sorry for top posting. Be aware that all usages of QImage goes not target the local screen. I.e. explicitly requesting a conversion seems to be the best option to me. Regards, Johan On 2012-07-16 16:31 alexandros.dermena...@nokia.com wrote: Hi, I am working on adding support for color profiles on Qt 5. It is under discussion if the default behavior of QImage shall be: 1) converting from an embedded color profile to the screen color profile when loading an image OR 2) keep the loaded image in the source color space, until the programmer explicitly requests color conversion. Solution 1 : QImage(, QColorProfile = Preserve_Embedded) * Keeps the old Qt behavior (providing backwards compatibility without the need of tweaking the code) Solution 2 : QImage(, QColorProfile = Convert_To_Screen) * Fixes some bugs in applications that use QImage directly for visualizing images (i.e. okular) * Better for newly developed applications since color profile conversion takes place automatically Presently when an image is loaded it always gets interpreted as sRGB and no color conversion takes place. Thanks in advance! ___ Development mailing list Development@qt-project.org http://lists.qt
Re: [Development] Move math3d from QtGui to QtCore
On Thursday 05 July 2012 14:08:45 Laszlo Papp wrote: Using eigen for managing some coordinates sounds utterly overkill. Either you haven't looked at Eigen, or you haven't understood it. Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Late API addition in QScreen for 5.0
On Monday 07 May 2012 15:03:29 Samuel Rødal wrote: On 05/04/2012 04:22 PM, ext Samuel Rødal wrote: As for the open source drivers I don't know of any reliable way of enabling vsync. There's the GLX_SGI_video_sync extension which is supposed to give a uniform way to sync rendering regardless of graphics driver, but when I've tried it I've gotten the same tearing in a single location issue as described above. Actually, I take that back, it seems at least Intel's Mesa DRI drivers do proper vsync by default, which is great news. So the question is, if the API for driving animations should be based on QTimer and per-screen refresh interval values, or if there should be a special QScreenTimer or QAnimationTimer, which fires a signal whenever the vblank is received. It could fall back internally to an interval based QTimer, in case the platform's screen cannot handle the VBlank signal. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Late API addition in QScreen for 5.0
On Friday 04 May 2012 13:37:04 Samuel Rødal wrote: Hello, to be able to achieve smooth animations in QML 2, the animations should ideally use a fixed timestep, and not a timer which might have inaccuracies depending on the platform and won't give fully smooth results. Does OpenGL 2 have API to drive animations by vertical blanking interrupts instead of using a timer? From my experience with movie players, you always get tearing or stuttering, if the frame rate of the display is not a 100% exact multiple of that of the animation or the video. In the context of this, and to avoid having values of 60 hard-coded (we have a couple of those in qtdeclarative/src/quick already), we really need to know the refresh rates of the screens we're rendering to. I've therefore added QScreen::refreshRate(), which gives the screen's vertical refresh rate, and thus can be used to run visual animations with a fixed timestep without the animation running faster or slower on different displays. The change is up for review at https://codereview.qt-project.org/#change,25317 -- Samuel ___ 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] Qt5 missing features
On Wednesday 11 April 2012 11:40:15 BogDan wrote: There is no QMenu::show, and this is the problem !:) QMenu::show() calls QWidget::show(), which simply calls QWidget::setVisible(true). And this one is virtual, case closed ;) -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Girish Ramakrishnan for Approver status
On Tuesday 06 March 2012 19:52:42 Girish Ramakrishnan wrote: Most of my work predates the qt-project. I can review anything in graphicsview, itemviews, styles, widgets and gui/kernel. Great! Having someone who also cares about style and widgets, even if it is not a complete maintainership, will be much appreciated by those who plan to submit patches for those rusty areas ;) -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
