[Development] QLocale changed?
This:
QCOMPARE(QLocale::c().toString(1234.0, 'f', 0), QString("1,234"));
was the behavior until Qt 5.5
With Qt 5.6, this happens:
Actual (QLocale::c().toString(1234.0, 'f', 0)): "1234"
Expected (QString("1,234")) : "1,234"
Is this an expected change?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths::writableLocation() on OSX in test mode
On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote: > I mean the API returns a single value, not a list. Yes, and the value returned by writableLocation() is supposed to be user-specific (something under $HOME) rather than system-wide. So /Applications should be in QSP::standardLocations(ApplicationsLocation) but QSP::writableLocation(ApplicationsLocation) should return something under $HOME, like on XDG unixes (where it's ~/.local/share/applications). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths::writableLocation() on OSX in test mode
On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote: > Feel free to do whatever you like for test mode but do not change the > existing writable paths. Jake, I would like to understand why you say that. As the QSP author and maintainer, I am 100% sure that the value of writableLocation(x) should be under $HOME. Spot the wrong value in this list of results: Writable locations: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/Library/Application Support/qtpaths AppLocalDataLocation = $HOME/Library/Application Support/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/Library/Caches/qtpaths ConfigLocation = $HOME/Library/Preferences DataLocation = $HOME/Library/Application Support/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/Library/Caches GenericConfigLocation = $HOME/Library/Preferences GenericDataLocation = $HOME/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR This is a bug, it was never intended for writableLocation to return a system-wide path. I can imagine that there is actually no use case for users writing into an ApplicationsLocation under $HOME on OSX (KDE code excluded). But in that case making the value more consistent with the other ones can't possibly hurt. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mime database size
On Monday 23 February 2015 14:39:49 Arnaud Vrac wrote: That's true, but the binary file in QStandardPaths::GenericDataLocation + mime/mime.cache should have been rebuilt with those additional XML files. Only on systems with shared-mime-info installed. The XML provider makes things work also on systems where shared-mime-info isn't installed - such as Windows and Mac OS X, typically (and Android, iOS, etc.) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mime database size
On Monday 23 February 2015 12:00:51 Knoll Lars wrote: Yes, I still don’t like the fact we’re embedding a 1.7M xml file in Qt Core at all. I’m not too fond of checking the binary file into the repositories, but it’s probably still better than continuing with the XML file. Yes. The binary file would be 109KB, much smaller already. David, I can’t see how the use case of the app installing additional mime types is supported today (as there is no API to register additional XML files or anything like that. Trust me (or read the unit test), it works :-) Additional XML files are found by looking at the filesystem, QStandardPaths::GenericDataLocation + mime/packages/, as per the mime spec. So I can’t see how embedding the binary blob instead of the XML file will give us a feature regression today. See previous email. Can be fixed, of course, but it's a bit more effort (I won't have time in the near future, but maybe later). -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mime database size
On Thursday 19 February 2015 01:55:01 Kevin Kofler wrote: Arnaud Vrac wrote: Commit fbeeaf2 in qtbase adds QT_NO_MIMETYPE: The mime type stuff generates one of the biggest translation units in QtCore due to the compressed 1.7MB freedesktop.org.xml resource. With QT_NO_MIMETYPE, libQt5Core.so is almost 400Kb smaller (4.8MB-4.4MB gcc 4.9 stripped release build) It would be nice to be able to find a middle ground between disabling the mime database completely and adding 1.7MB of data to Qt. The update-mime-database binary from the shared-mime-info package can generate a binary file from the XML, which is 100KB large and still allows finding the mimetype of any file. The only difference with the XML is that you don't have the translated pretty string for the mime type. The binary file can also be mmapped and used for every request very efficiently, instead of allocating all mime types data in memory. This won't help the other platforms, but on GNU/Linux, can't we just use the system shared-mime-info database? We do. The builtin XML is for the case where it's not available (Windows/Mac) or not found (reduced Linux system, e.g. some embedded linux systems). Lars suggested long ago that we put the binary instead in QtCore (like Giuseppe just did). This would be good for performance too - parsing this XML is a horrible performance penalty. The reason I didn't do that yet is that on systems without update-mime-database we still need to be able to parse XML files (e.g. for additional mimetypes installed by applications), so the current design (XML *or* binary backend) doesn't work for that, we need a way to use both. Being able to skip embedding the DB altogether, in whichever form, as suggested by Thiago, can help desktop linux distros on top of that. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
On Thursday 27 February 2014 17:09:59 Thiago Macieira wrote: Maybe techbase is deprecated and everything is moving to the newer wikis. It's not deprecated. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote: But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. Let me rewind a bit here... I thought QtCore would have query stuff, not mount functionality - which most apps don't need. Is this because you want to offer mounting devices in QFileDialog? But in practice QFileDialog is reimplemented on almost all platforms via the QPA, or should be, right? So that seems a bit pointless. And QtQuick.Controls.FileDialog might not be currently reimplemented via the QPA, but then that's a bug - it should be, to provide consistent dialogs to the user. So e.g. KDE can provide the same mounting capabilities (via the Solid framework) in both dialogs. Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick is not so great? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] src/plugins/platforms/eglfs compilation error
On Monday 30 December 2013 19:26:58 Thiago Macieira wrote: On segunda-feira, 30 de dezembro de 2013 21:20:06, David Faure wrote: Xlib.h is included by src/3rdparty/angle/include/EGL/eglplatform.h I do have /usr/include/EGL/egl.h btw. What provides it? Mesa-libEGL-devel-9.0.2-34.24.1.x86_64 I'm guessing you have a non-Mesa GL driver then. Doesn't seem so. But I forced a regeneration of the include subdir and the issue seems to have gone away. Apparently QTDIR/include/EGL/ doesn't get generated by syncqt.pl anymore -- which is good. Problem solved. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday 13 January 2014 18:04:24 Tony Van Eerd wrote: 1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I'm not familiar with the details there, can you briefly explain why dbus is necessary and why it is a bad thing for qtcore? QtCore can't link to QtDBus, since QtDBus links to QtCore. Mounting can still be done with `mount`, no? Notifications mean listening to dbus signals though, indeed. Tricky. Maybe by using libdbus directly, but this contradicts the long term plan of not using libdbus in QtDBus (AFAIK). -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday, January 13, 2014 10:32:12 PM abba...@gmail.com wrote: I think, mount requires root privileges, doesn't it? Not if the entry is present in fstab, with the option user or users. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] Platform maintainers
Could we add a table at the bottom of http://qt-project.org/wiki/Maintainers with the platform maintainers, for each platform? ... unless I'm wrong and the concept doesn't exist within the Qt community, but AFAIK it does? I can't find who's the official maintainer for each platform. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Removing QT_NO_DEBUG_STREAM?
On Monday 06 January 2014 19:43:45 Konstantin Ritt wrote: I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself doesn't build with it (which is fixable), one might define it globally after it built, to avoid building an unnecessary code in his/3rd-party modules. You don't gain anything by defining it in your app, compared to just not calling qDebug. This isn't the intended usage of QT_NO_* - this was about reducing the size of Qt. But yeah at this point QT_NO_DEBUG_STREAM should just be removed, the maintainance pain is not worth it. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] src/plugins/platforms/eglfs compilation error
Same old story: the Xlib.h headers #define None, breaking the None in qurl.h This breaks compilation of qtbase/src/plugins/platforms/eglfs in stable branch for me. Including Qt headers after egl headers works around it, but it would have to be done in many .cpp files... (I only tried on qeglfsintegration.cpp) Investigation: Xlib.h is included by src/3rdparty/angle/include/EGL/eglplatform.h which is included by include/EGL/eglplatform.h which is included by src/3rdparty/angle/include/EGL/egl.h which is included by include/EGL/egl.h which is included by qeglfsscreen.h which is included by qeglfsintegration.h which is included by qeglfsintegration.cpp before it includes Qt headers, such as qguiapplication_p.h - qwindowsysteminterface.h - qevent.h - qurl.h I am very surprised that this passed the CI and that others aren't affected. Well, src/3rdparty/angle isn't supposed to be in the include path on Linux? And/or it shouldn't generate forwarding headers, when angle is not used. I do have /usr/include/EGL/egl.h btw. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] A QtCore class for event-driven jobs
On Tuesday 17 September 2013 15:08:15 Buddenhagen Oswald wrote: agreed, but for the same reason composite jobs are a non-starter: they are managers with unlimited potential for scheduling policy api growth. Don't go there. Very different; composite jobs are an optional feature useful as an implementation helper for the job. Optional feature for internal implementation detail means no limitation, you don't have to use it if you don't want to. Anyway, I'm postponing this, possibly for ever. If anyone wants to use exactly what I described in this email thread, you are welcome to use the KCoreAddons framework, a standalone library that sits directly on top of QtCore. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] A QtCore class for event-driven jobs
On Tuesday 10 September 2013 21:09:55 Peter Kümmel wrote: On 06.09.2013 19:52, David Faure wrote: connect(job, SIGNAL(result(QJob*)), this, SLOT(handleResult(QJob*))); This looks so old-school like in times of futures and monads. I'm an old-timer, clearly ;-) Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Can we forget about threads for a second? The main point of event-driven jobs is to have them use the event loop, NOT threads. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] A QtCore class for event-driven jobs
On Friday 06 September 2013 17:20:59 Thiago Macieira wrote: On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote: * relation to QNetworkReply? If that one didn't exist yet, we'd definitely write it as a QJob subclass. So instead, I propose to wrap QNetworkReply into a QNetworkJob or something, in order to offer the QJob interface for QNAM requests. On one hand this doesn't have to go in at the same time as QJob itself, but OTOH it could be a real- world testcase for it, proving its usefulness and correctness... Any other questions? What if we put the QJob class and convenience derived classes like QNetworkRequestJob, QProcessJob, QThreadJob, etc. in one new library. This library could be extended later with more job types. I understand that you want to limit the growth of QtCore, but, hmm, a separate library/module QtJobs seems very strange. It's not like it's separate technology, the core of QAbstractJob's technology is the QtCore event loop. Can you see yourself at the next Dev Days presenting the Qt modules with Qt Core, Qt Gui, Qt Network, Qt Multimedia and ... Qt Jobs ? It doesn't fit that list, because it's not a separate technology with separate dependencies. In addition, this prevents using these job classes within Qt itself: if QNetworkReply didn't exist yet, and if QAbstractJob was in QtCore already, then surely we'd call it QNetworkRequestJob and make it derive QAbstractJob, and we'd put that in QtNetwork. The only reason we got QNetworkReply instead is that QAbstractJob didn't exist yet. By putting the jobs on top of everything else, we will always have the QNetworkReply/QNetworkRequestJob redundancy everywhere a Qt API would benefit from returning a job class. I still think the best solution is: QtCore: QAbstractJob, and later QProcessJob and QThreadJob QtNetwork: QNetworkRequestJob (wrapping QNetworkReply) QtDBus: (later) QDBusCallJob (wrapping QDBusPendingCallWatcher) The latter is another reason why a QtJobs library wouldn't work. In order to provide an async-dbus-call job, it would have to link to QDBus, forcing a QDBus dependency onto every user of core-only jobs like QThreadJob. Looking at my initial email, I think that's all. There isn't going to be 20 more job classes in qt itself, the only async operations that happen in there are all on top of sockets, processes and threads. (and timers, but a QTimerJob isn't terribly useful ;) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] A QtCore class for event-driven jobs
On Friday 06 September 2013 22:22:20 Andre Somers wrote: . However, I'd hope the design would not limit itself to just event-driven jobs, if I understand correctly what that means. Some of my jobs are just heavy processing that require multi-threading. That sounds more like QRunnable than QJob then. But we could have a QThreadJob, for instance like this: it would inherit from both QJob and QRunnable, its doStart() would queue itself as a runnable into a QThreadPool. This creates issues with methods on the same class being called from two different threads though, so maybe better to have QThreadJob and QThreadJobRunnable (which inherits QRunnable and adds signals for progress and completion, optionally cancellation). All this however is experimental, so definitely not for 5.2. Would this API suport that too, or would that be hacky again to implement? Another aspect that I build into my own solution and that I find valuable, is that I have added a mechanism to prevent the same work being done twice. If different parts of the code ask for the same calculation to be performed (that can happen in my case), they actually get a pointer to the same job back. That turns out to be very convenient. Note however, that that requires a job manager, and it doesn't look like that is in this design. In my case, I submit a request to the manager, who then returns a job. You can do that on top of the QJob framework I have in mind. Instead of new CalculationJob you'd ask manager-createCalculationJob() and the manager would take care of reuse and deletion. I don't think this is necessary in the core framework. Note that in my case, I return QSharedPointerJob, so it is clear to everyone that the code that everyone that requests a job and gets one, can't treat it as if it was theirs exclusively. Yep, that can be done on top. Most use cases I've seen are about separate operations rather than calculations, so they don't need the extra syntactic overhead of QSharedPointerJob everywhere. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] A QtCore class for event-driven jobs
I would like to propose the inclusion of a QJob class in QtCore, based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation into a job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket (like akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an IDE, unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(), calling pure
virtual methods doStart() and doKill(), and signals, most importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing, for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge warning about not
using that in GUI apps (ideally only to be used in unittests or separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows generic GUIs
to be built on top, so that your app or your desktop can show the progress of
multiple concurrent jobs, of different types (file download, CD burning, mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support sub-jobs.
The job implementation would choose when to create these subjobs (all at once
initially, to have them run in parallel, or one after the other, for sequence
of operations). KDE currently does that in a subclass (KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have it all in
one class instead.
We also have a standard interface for error handling so that all jobs from a
given framework can have their error handled the same way, but thinking about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to, and to gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods for getting
the value, even available as casting-to-the-value. If we imagine a QFuture
that wraps a QJob, and the blocking method calling exec(), we'd have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is completely
different: a runnable is one sync method, while a qjob is all signals/slots
based, with start() returning immediately. So one can't be used like the
other, a given task implementation is either a blocking task for a thread with
no event loop (QRunnable) or an async task that can actually be used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob subclass. So
instead, I propose to wrap QNetworkReply into a QNetworkJob or something, in
order to offer the QJob interface for QNAM requests. On one hand this doesn't
have to go in at the same time as QJob itself, but OTOH it could be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QStandardPath search paths
On Tuesday 27 August 2013 08:47:18 Juergen Bocklage-Ryannel wrote: or the alternative of deprecating search paths. Anyone have an opinion here? My opinion is to deprecate search paths. That's what QStandardPaths::locate is for. If this is about QDir::addSearchPath read on: We use it for embedded projects to easily change asset paths between developer and target environment. I found it always useful to abstract away my own asset locations. Maybe we could also use QStandardPaths but only if we could add own path locations (which then would not be standard anymore). QStandardPaths doesn't currently allow to add extra search paths, but I've been wondering if anyone would need that, indeed. My fear is that people add paths which don't work on all platforms, but I guess if they are constructed relatively to standard paths returned by QStandardPath then it's fine. Or indeed for apps that target only one OS there's no issue. For apps there's always the solution of wrapping QStandardPaths into your own method. But indeed as soon as Qt itself or any Qt-based framework uses QStandardPaths, apps have no way to change what that code sees. So I'm open to something like this (but I won't have time to implement it for 5.2). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] staging in qt dev branches temporarily disabled
On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote: the lock can be removed on friday evening, i think. at least i hope all integrations are done and everyone got that by this time. Now that all modules have had dev merged into stable, could the lock be removed? dev is Qt 5.2 now, so new features (or performance fixes, for instance) should be fine, right? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] staging in qt dev branches temporarily disabled
On Tuesday 26 March 2013 14:25:35 Oswald Buddenhagen wrote: On Tue, Mar 26, 2013 at 01:30:26PM +0100, David Faure wrote: On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote: the lock can be removed on friday evening, i think. at least i hope all integrations are done and everyone got that by this time. Now that all modules have had dev merged into stable, could the lock be removed? yes, removed now. let's hope everyone got the correct branches now. Thanks! dev is Qt 5.2 now, so new features (or performance fixes, for instance) should be fine, right? correct (though, if it really is a performance *fix*, you should consider 5.1/stable). Well, performance *improvements*. AFAIU these should go into dev, because of the higher risk of regressions. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Qt 5.1 feature set and freeze date
On Wednesday 13 February 2013 08:49:56 Knoll Lars wrote: * Friday 22. February: If you have a larger feature/feature branch (not yet merged) that you want to have in the release you must have told the release team (by mail to releases@) by then. QLockFile is almost ready, I've been revising it countless times since initial submission, based on [conflicting...] feedback, can we aim at including it in 5.1 if I can get it merged soon? https://codereview.qt-project.org/46583 by mail to releases@ Did you mean releasing@ ? Nice trap :) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote:
To see the changes, check out (or diff against) the
wip/android branch.
Looking at the patch with git diff origin/dev...origin/wip/android
[not very convenient for commenting on code changes...]
I see changes that are unrelated to android:
--- a/src/corelib/codecs/qiconvcodec_p.h
+++ b/src/corelib/codecs/qiconvcodec_p.h
@@ -55,7 +55,7 @@
#include qtextcodec.h
-#if defined(Q_OS_UNIX) !defined(QT_NO_ICONV) !defined(QT_BOOTSTRAPPED)
+#if (defined(Q_OS_UNIX) || defined(__MINGW32__)) !defined(QT_NO_ICONV)
!defined(QT_BOOTSTRAPPED)
#ifdef Q_OS_MAC
typedef void * iconv_t;
This adds MINGW !?
+if (d-goToSleep.testAndSetAcquire(1,1)) // don't go to bed if someone
just woked you up !
Typo :-) woked - woke
--- a/src/gui/kernel/qplatforminputcontext.cpp
+++ b/src/gui/kernel/qplatforminputcontext.cpp
@@ -114,7 +114,7 @@ void QPlatformInputContext::commit()
/*!
Notification on editor updates. Called by QInputMethod::update().
*/
-void QPlatformInputContext::update(Qt::InputMethodQueries)
+void QPlatformInputContext::update(Qt::InputMethodQueries queries)
{
}
Well, this is just bogus, it creates a compiler warning.
--- a/src/widgets/widgets/qtextbrowser.cpp
+++ b/src/widgets/widgets/qtextbrowser.cpp
@@ -156,7 +156,12 @@ QString QTextBrowserPrivate::findFile(const QUrl name)
const
else if (name.scheme().isEmpty())
fileName = name.path();
else
-fileName = name.toLocalFile();
+{
+if (name.scheme() == QLatin1String(assets))
+fileName = QLatin1String(assets:) + name.path();
Urgh. This is a pretty broken way to construct a URL. Think of a path with a
'#' in it...
--- a/src/widgets/widgets/qabstractbutton.cpp
+++ b/src/widgets/widgets/qabstractbutton.cpp
@@ -1119,6 +1119,11 @@ void QAbstractButton::mouseReleaseEvent(QMouseEvent *e)
return;
}
+#ifdef Q_OS_ANDROID
+d-repeatTimer.stop();
+d-click();
+e-accept();
+#else
Urgh, I thought we didn't want OS-specific defines in widgets anymore, after the
whole QPA re-architecture. Didn't we get rid of such Q_WS_X11 hacks on purpose?
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows
Hi Jan Arve, This test has failed the last 3 times I've been trying to merge an unrelated change to qtbase, and I remember seeing similar failures before too. Autotest `tst_qaccessibility' failed :( Testing tst_QAccessibility QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failed, running again to see if it is flaky... * Start testing of tst_QAccessibility * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QAccessibility::initTestCase() [...] PASS : tst_QAccessibility::accelerators() QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failure could be reproduced twice consecutively QtQA::App::TestRunner: end tst_qaccessibility: 13 seconds, exit code 3221225477 Build log: http://testresults.qt- project.org/ci/QtBase_dev_Integration/build_00101/win32- msvc2010_Windows_7/log.txt.gz The next method is bridgeTest(), which is a Windows-specific test. Could you take a look? Thanks. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] QLibrary and QCoreApplication::libraryPaths()
QCoreApplication::libraryPaths() is documented as the search paths for loading plugins, but it turns out that only plugins for Qt itself are looked up there [by the internal QFactoryLoader class]. Application plugins are not searched in these paths. I expected them to be :) Can I add (in Qt-5.1, I guess) a static QString findLibrary(const QString libname) in QLibrary? The alternative would be to change what load() does, in case of relative paths, but I think we'd rather keep its current behavior (load the plugin relative to the current directory, like QFile would do), for speed reasons. QLibrary::findLibrary would allow to look up a library in the paths before calling the constructor. It would have to share the code that tries various suffixes though This is why it should be in Qt: to encapsulate the OS differences, this isn't just about a foreach(path, libraryPaths)+QFile::exists. The goal is to be able to write this in a qt-based library: QLibrary lib(QLatin1String(kf5/ktranscript)); and it should find PREFIX/lib64/plugins/kf5/ktranscript.so (.dll on windows) after ensuring QT_PLUGIN_PATH contains PREFIX/lib64/plugins (when PREFIX is different from Qt's). Thoughts? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Two bugs in the QIcon which broke my life.
On Wednesday 08 August 2012 17:00:29 David Faure wrote: On Wednesday 08 August 2012 14:32:36 Mark wrote: As for the second bug report (https://bugreports.qt-project.org/browse/QTBUG-12874) shouldn't the standard icon paths be defined in the new class QStandardPaths? Then QIcon can use QStandardPaths to find icons - obviously. Right now i don't see any icon related thing in http://doc-snapshot.qt-project.org/5.0/qstandardpaths.html Since the icon stuff is defined by freedesktop (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.h tm l#directory_layout) it might as well be added in there. Adding David Faure to the cc since he invented QStandardPaths. QStandardPaths::locateAll(QStandardPaths::GenericDataLocation, icons, QStandardPaths::LocateDirectory); will give you all the base icon paths where to look for icon themes. Sorry, now I read the bug report which also talks about /usr/share/pixmaps. Interesting :-) The KDE icon loader code says that locating one icon can be done with: QStandardPaths::locate(QStandardPaths::GenericDataLocation, searchPath + '/' + iconName) where searchPath iterates over a list containing 1) the application-specific directory + /pics 2) icons 3) pixmaps, but with a comment that this is historical and mostly for gnome compatibility. I had no idea that it was actually in the spec :-) I'll fix that comment. Now what's interesting is that the spec hardcodes /usr/share/pixmaps, while the KDE code makes this more generic, i.e. $XDG_DATA_DIRS/pixmaps. Anyway, to come back to the Qt code, this means: A) yes, QStandardPaths should be used to find $XDG_DATA_DIRS/icons, but that's unrelated to QTBUG-12874, which is about B) yes, Qt icon loading should look into /usr/share/pixmaps, as the spec says. I don't know qiconloader.cpp so I can't approve the rest of the patch, but the hardcoded /usr/share/pixmaps looks fine, it's as per the spec. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QPA triggers nested event processing
This was quite unexpected: in Qt5, creating a QApplication instance triggers event processing already, much before calling QApplication::exec(). This comes from QWindowSystemInterface::sendWindowSystemEvents calling sendPostedEvent(), see bt below. Shouldn't it be more specific about which posted events, for which targets, should be flushed at that point? I'm pretty sure that nobody expects other events (timers, sockets, dbus, etc.) to be handled yet. Even processing GUI-related events doesn't sound like a good idea to me, so early in the game. #7 0x73ba16fd in q_dbus_connection_dispatch (connection=0x61c6b0) at qdbus_symbols_p.h:115 #8 0x73ba6e6e in QDBusConnectionPrivate::doDispatch (this=0x612600) at qdbusintegrator.cpp:1125 #9 0x73bee5fe in QDBusConnectionPrivate::qt_static_metacall (_o=0x612600, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x61c220) at .moc/debug-shared/moc_qdbusco nnection_p.cpp:130 #10 0x770ab991 in QMetaCallEvent::placeMetaCall (this=0x61f770, object=0x612600) at kernel/qobject.cpp:467 #11 0x770ac8f8 in QObject::event (this=0x612600, e=0x61f770) at kernel/qobject.cpp:1048 #12 0x770728e8 in QCoreApplicationPrivate::notify_helper (this=0x626750, receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.cpp:837 #13 0x770725dc in QCoreApplication::notify (this=0x7fffd330, receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.cpp:783 #14 0x73f0a80e in QGuiApplication::notify (this=0x7fffd330, object=0x612600, event=0x61f770) at kernel/qguiapplication.cpp:1052 #15 0x770724e8 in QCoreApplication::notifyInternal (this=0x7fffd330, receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.cpp:721 #16 0x7707622d in QCoreApplication::sendEvent (receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.h:207 #17 0x770735ac in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x607df0) at kernel/qcoreapplication.cpp:1321 #18 0x7707316d in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1181 #19 0x73efd466 in QWindowSystemInterface::sendWindowSystemEvents (flags=...) at kernel/qwindowsysteminterface.cpp:509 #20 0x73f0a449 in QGuiApplicationPrivate::init (this=0x626750) at kernel/qguiapplication.cpp:880 #21 0x73f0860d in QGuiApplication::QGuiApplication (this=0x7fffd330, p=...) at kernel/qguiapplication.cpp:348 #22 0x746b4d15 in QApplication::QApplication (this=0x7fffd330, argc=@0x76bf5568, argv=0x624270, GUIenabled=true, _internal=327680) at kernel/qapplication .cpp:577 [...] #26 0x00402cf8 in main (argc=1, argv=0x7fffd598) at /d/kde/src/kf5-qt5/kdelibs-frameworks/staging/kde4support/autotests/kuniqueapptest.cpp:93 What's the reason for the sendWindowSystemEvents in QGuiApplicationPrivate::init ? It comes from ef2efafcc6b28791df6258fa1c5d565090a9577a (hi Simon), but the above looks like a rather unexpected large side effect for a small issue... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTest::mouseClick doesn't set QApplication::keyboardModifiers anymore
A testcase like the attached one, which sends a mouse event to a QWidget using
QTest::mouseClick, used to adjust QApplication::keyboardModifiers() in Qt4,
but doesn't do so anymore in Qt5.
It seems the code that changes modifier_buttons is now in
QGuiApplicationPrivate::processMouseEvent, which is not called by
QTest::mouseClick.
qapplication.cpp:2983 (which is called) says
// capture the current mouse/keyboard state
but it only captures the mouse state, not the keyboard state.
Should it capture keyboard state again, like in Qt4?
But the interesting thing in all this is that outside of unit tests, it's all
working fine (when I click on an actual widget,
QApplication::keyboardModifiers() is set).
So maybe the real fix would be that QTest::mouseClick works more like a real
mouse click, going via the QWindow first, before being sent to the
target QWidget? Not sure what this means exactly in terms of code changes
though.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
diff --git a/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp b/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
index 1b4cacf..14a856d 100644
--- a/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
+++ b/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
@@ -387,6 +387,8 @@ private slots:
void touchEventSynthesizedMouseEvent();
+void keyboardModifiers();
+
private:
bool ensureScreenSize(int width, int height);
QWidget *testWidget;
@@ -9443,5 +9445,28 @@ void tst_QWidget::touchEventSynthesizedMouseEvent()
}
}
+class KeyboardWidget : public QWidget
+{
+public:
+KeyboardWidget(QWidget* parent = 0) : QWidget(parent), m_eventCounter(0) {}
+virtual void mousePressEvent(QMouseEvent* ev) Q_DECL_OVERRIDE {
+m_modifiers = ev-modifiers();
+m_appModifiers = QApplication::keyboardModifiers();
+++m_eventCounter;
+}
+Qt::KeyboardModifiers m_modifiers;
+Qt::KeyboardModifiers m_appModifiers;
+int m_eventCounter;
+};
+
+void tst_QWidget::keyboardModifiers()
+{
+KeyboardWidget* w = new KeyboardWidget;
+QTest::mouseClick(w, Qt::LeftButton, Qt::ControlModifier);
+QCOMPARE(w-m_eventCounter, 1);
+QCOMPARE(int(w-m_modifiers), int(Qt::ControlModifier));
+QCOMPARE(int(w-m_appModifiers), int(Qt::ControlModifier));
+}
+
QTEST_MAIN(tst_QWidget)
#include tst_qwidget.moc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextBoundaryFinder behavior change in Qt-5.0
On Saturday 28 July 2012 14:34:25 Konstantin Ritt wrote: I have a patch that changes QTBF's behavior so that . won't be treated like a word at all. This patch hardly depends on some other patches that are in review stage, though. The hardly and the though seem contradictory to me. Did you mean This patch has a hard dependency on, or This patch doesn't really depend on (== hardly depends)? I would appreciate if you extend the QTBF autotests with some of Sonnet's testcases. https://codereview.qt-project.org/#change,31717 -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTextBoundaryFinder behavior change in Qt-5.0
Hi Konstantin,
I'm seeing a unittest failure in KDE Frameworks (sonnet framework) due to
changes in QTextBoundaryFinder. This isn't my domain of expertise, so can I
ask you to take a look at the information below, to find out if it's an
intentional change or a bug, and/or if maybe the sonnet code is buggy?
static bool
finderNextWord(QTextBoundaryFinder finder, QString word, int bufferStart)
{
QTextBoundaryFinder::BoundaryReasons boundary = finder.boundaryReasons();
int start = finder.position(), end = finder.position();
bool inWord = (boundary QTextBoundaryFinder::StartWord) != 0;
while (finder.toNextBoundary() 0) {
boundary = finder.boundaryReasons();
if ((boundary QTextBoundaryFinder::EndWord) inWord) {
end = finder.position();
QString str = finder.string().mid(start, end - start);
if (isValidWord(str)) {
word = str;
bufferStart = start;
qDebug().nospace() Word at start word=
str , len= str.length();
return true;
}
inWord = false;
}
if ((boundary QTextBoundaryFinder::StartWord)) {
start = finder.position();
inWord = true;
}
}
return false;
}
The unittest starts from the string
QString buffer( This is a sample buffer.Please test me .)
and calls the above method repeatedly.
The result with Qt5 is
QDEBUG : SonnetFilterTest::testFilter() Word at 0 word=This, len=4
QDEBUG : SonnetFilterTest::testFilter() Word at 5 word=is, len=2
QDEBUG : SonnetFilterTest::testFilter() Word at 12 word=a, len=1
QDEBUG : SonnetFilterTest::testFilter() Word at 14 word=sample, len=6
QDEBUG : SonnetFilterTest::testFilter() Word at 21 word=buffer.Please,
len=13
FAIL! : SonnetFilterTest::testFilter() Compared values are not the same
Actual (w.word): buffer.Please
Expected (hits[hitNumber].word): buffer
The result with Qt4 is
QDEBUG : SonnetFilterTest::testFilter() Word at 0 word=This, len=4
QDEBUG : SonnetFilterTest::testFilter() Word at 5 word=is, len=2
QDEBUG : SonnetFilterTest::testFilter() Word at 12 word=a, len=1
QDEBUG : SonnetFilterTest::testFilter() Word at 14 word=sample, len=6
QDEBUG : SonnetFilterTest::testFilter() Word at 21 word=buffer, len=6
QDEBUG : SonnetFilterTest::testFilter() Word at 28 word=Please, len=6
QDEBUG : SonnetFilterTest::testFilter() Word at 35 word=test, len=4
QDEBUG : SonnetFilterTest::testFilter() Word at 40 word=me, len=2
So the dot character is no longer a word separator?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML pixmap caching
On Monday 23 July 2012 23:58:16 martin.jo...@nokia.com wrote:
So maybe this should be configurable?
Perhaps. I'm wary of exposing details of the current implementation in API.
I'm not sure how this is an implementation detail. It can be as high level as
cache size in MB.
QPixmapCache has that. ListView has bufferSize for something similar (but
PathView is
missing it, which is what's creating this problem in the first place). Overall,
I think giving tools
to tune the RAM vs CPU tradeoff is important, especially with a focus on
animations
and embedded... (therefore both CPU and RAM can be important limitations,
depending
on the actual use cases).
Or is the only option to create my own QDeclarativeImageProvider which
keeps everything in memory?
This is the only option at the moment.
So, I've done that, and discovered another small issue: since I do my own
caching in the
provider, I want to bypass the internal caching, which I do with cache: false
in the
image elements. However when the images are unref'ed, they still count as part
of the m_unreferencedCost,
which triggers cache shrinking.
Shouldn't this be skipped for non-cached images?
@@ -646,12 +646,15 @@ void
QDeclarativePixmapStore::unreferencePixmap(QDeclarativePixmapData *data)
if (!m_lastUnreferencedPixmap)
m_lastUnreferencedPixmap = data;
-m_unreferencedCost += data-cost();
+if (data-inCache) {
+m_unreferencedCost += data-cost();
-shrinkCache(-1); // Shrink the cache incase it has become larger than
cache_limit
+shrinkCache(-1); // Shrink the cache incase it has become larger than
cache_limit
-if (m_timerId == -1 m_unreferencedPixmaps)
-m_timerId = startTimer(CACHE_EXPIRE_TIME * 1000);
+if (m_timerId == -1 m_unreferencedPixmaps) {
+m_timerId = startTimer(CACHE_EXPIRE_TIME * 1000);
+}
+}
}
void QDeclarativePixmapStore::referencePixmap(QDeclarativePixmapData *data)
@@ -670,14 +673,18 @@ void
QDeclarativePixmapStore::referencePixmap(QDeclarativePixmapData *data)
data-prevUnreferencedPtr = 0;
data-prevUnreferenced = 0;
-m_unreferencedCost -= data-cost();
+if (data-inCache) {
+m_unreferencedCost -= data-cost();
+}
}
This works great here, but I'm wondering if un-cached pixmaps should go into
m_lastUnreferencedPixmap
and m_unreferencedPixmaps. Maybe the above patch makes that list grow forever,
if all images
are uncached?
I'll do that for now, but it seems like there should be an easier way to
tell QML keep stuff in cache as long as the cache isn't too big (and
the cache size could possibly be made configurable, too, like in
QPixmapCache).
I agree that the current strategy is too aggressively discarding
images. The simplest solution I can think of is to have a lower and upper
bound, so that the cache allows up to say 25% of its capacity to remain
indefinitely.
That would work ok in some cases and it would already be an improvement IMHO,
but of course one might want to tune this number too...
It should be possible to set the cache size too. This is a
task that has been around for some time
https://bugreports.qt-project.org/browse/QTBUG-19507
Could you advise the guy in that report, about which API would be good for this?
Then he can finish the patch and contribute it...
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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] QML pixmap caching
QDeclarativePixmapStore (called QQuickPixmapStore in Qt5, but it's the same
code) seems to throw away cached pixmaps, every 30 seconds, even if the cache
is far from full.
This creates a performance issue when an image are being loaded during
animations, and was supposed to be in cache already.
Here's my analysis of qdeclarativepixmapcache.cpp:
The timer (called 30s after a pixmap becomes unused)g calls
shrinkCache(_unreferencedCost / CACHE_REMOVAL_FRACTION);
i.e. it wants to remove 1/4 of the unused pixmap data.
And the shrinkCache method, if called with a positive number, will always
remove at least one element from the cache:
while ((remove 0 || [...]) m_lastUnreferencedPixmap) {
// remove last unreferenced pixmap
}
So if you have a 10MB cache and an Image element that alternatives between two
states by changing its source property, each image being 1MB, then it would
all nicely fit into the cache, but shrinkCache will be called with an argument
of remove=250KB and will delete the currently-unused image from the cache.
Of course it's a matter of tradeoffs -- do you want to use more RAM to save on
IO+CPU, or to minimize RAM usage, at the expense of IO+CPU the next time the
image is necessary
It's just that in the use case I'm seeing here, loading images from the SD
card is too costly, so keeping them in RAM would be preferred.
So maybe this should be configurable?
Or is the only option to create my own QDeclarativeImageProvider which keeps
everything in memory?
I'll do that for now, but it seems like there should be an easier way to tell
QML keep stuff in cache as long as the cache isn't too big (and the cache
size could possibly be made configurable, too, like in QPixmapCache).
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Native event filter
On Tuesday 26 June 2012 13:17:27 Thomas McGuire wrote: Hi, On Tuesday 26 June 2012 12:48:56 David Faure wrote: So I looked further into this, and discussed it with several people at QtCS, and decided that not only the implementation needed fixing, the API too. The current API can lead to crashes if removing install event filters in a different order than the reverse-order-of-setting, and leads to ugly code (global C function, which basically requires having a singleton). In https://codereview.qt-project.org/#change,29260 I'm proposing a new API: QCoreApplication::instance()-installNativeEventFilter(obj); I very much support this change and hope it will get into Qt 5.0. Currently the system is very brittle once you try to install more than one EventFilter, as the filters are chained, and the user of the API needs to remember to call the previous filter in the chain, or everything breaks. In addition, if one of the filters in the chain gets deleted, there are dangling pointers and again the whole chain is broken. Yet using EventFilters is unavoidable, for example the Blackberry QtMultimedia backend needs it to get multimedia update events. As this API solves all this, I'd really like to see that in Qt. It's in, finally :-) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] App name in window title
On Friday 22 June 2012 15:24:48 David Faure wrote: * Doing this on all 3 desktop platforms, for more consistency among all Qt applications, and consistency between platforms for a given Qt application. This prevents the risk that a Windows Qt developer does setWindowTitle(foo - KMail), i.e. adds the app name himself in the title, and ends up with foo - KMail - kmail on X11. It seems to me that the second solution is better. Implemented in https://codereview.qt-project.org/#change,29254 -- please review. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] App name in window title
On Thursday 21 June 2012 23:41:12 Mark wrote: So: it's only being set afaict when setWindowTitle from QWidget is called otherwise it's the executable name minus extension. Thanks. Found that code in qwidget_win.cpp in Qt4. That's just fallback to avoid empty titles though, it doesn't touch titles set by the user indeed. There's no common standard for other windows on mac. OK, so this leaves two options. * Doing this only on X11 : http://www.davidfaure.fr/2012/caption.diff Tested, works. * Doing this on all 3 desktop platforms, for more consistency among all Qt applications, and consistency between platforms for a given Qt application. This prevents the risk that a Windows Qt developer does setWindowTitle(foo - KMail), i.e. adds the app name himself in the title, and ends up with foo - KMail - kmail on X11. It seems to me that the second solution is better. Brad wrote: Do it in QPlatformWindow. Did you mean in the XCB specific subclass, like I did above? (thanks for the hint) Or did you mean in the base class itself, by separating the virtual method from the public method, to have the add-the-app-name logic before calling the platform-specific implementation? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Native event filter
On Friday 22 June 2012 10:14:22 Thiago Macieira wrote: On sexta-feira, 22 de junho de 2012 10.07.54, David Faure wrote: QWindow and QWidget have a virtual method nativeEvent(), but this only works for window-specific or widget-specific event handling. Looking at the KDE code, I see a rather wide usage of process-level handling of native events. http://lxr.kde.org/ident?i=installX11EventFilter shows about 30 uses of that. From idle detection to desktop-wide clipboard handling, color picking, RANDR event handling, and so on. This was all done via QApplication::x11EventFilter(), which doesn't seem to have a replacement in Qt5 yet. It turns out that I'm wrong, there is QAbstractEventDispatcher::instance()-setEventFilter() already, for exactly this. Strangely enough, there's QCoreApplication::setEventFilter too, but it says It is not called for messages that are not meant for Qt objects. I guess this means messages meant for a Qt window, in practice. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] App name in window title
KDE4 (KDialog) has a nice feature that makes the application name appear in the window title bar. I think it's very nice to know which application a window comes from. Especially for the worst case: error message boxes :) QDialog itself doesn't do that, which leads to the question of: how should we do this with Qt 5? One solution would be to do this in QWindow. Maybe not on all desktop platforms, if some of them already do something about this... any idea if this would be good or bad, on Windows and Mac OS X? This requires to add a QCoreApplication::setApplicationDisplayName() though, we want a capitalized (and potentially translated) name like KMail, not applicationName() which is kmail. How does this sound? PS: I briefly thought of another solution, especially if this isn't needed on other platforms: letting KWin do it... I'm not sure how it could find out the translated application name (maybe via some X property?). And this might create the risk that apps (KDE4 apps, non-Qt apps) end up with the app name twice in the titlebar. So maybe this isn't a good solution after all, I just wanted to raise the idea in case I missed something that makes it good. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] App name in window title
On Thursday 21 June 2012 21:27:32 Иван Комиссаров wrote: Modal dialogs on Mac doesn't show any title at all. OK, thanks for this information. However what about non-modal windows on Mac? Dialogs were just an example, really, the same applies to all toplevel windows in KDE4. So this will be platform-dependent (kde only?) feature:) Depends what happens on Windows, really. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Os identification in Qt5
On Thursday 21 June 2012 16:51:16 Oleg Shalnev wrote: Hello all. How to identify operation system in Qt5. In Qt4 I use Q_OS_LINUX etc.. defines for OS identification What about this in Qt5. Q_OS_LINUX and other Q_OS_ defines still exist in Qt5. What has disappeared is Q_WS_*, which can be replaced with runtime checks on QGuiApplication::platformName() [for which I just submitted a documentation improvement]. and QSysInfo::WordSize for system bits. Seems to be exactly the same in Qt5. Did you look at global/qsysinfo.h? :-) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] App name in window title
On Thursday 21 June 2012 22:05:24 Mark wrote: On Thu, Jun 21, 2012 at 9:55 PM, David Faure fa...@kde.org wrote: On Thursday 21 June 2012 21:27:32 Иван Комиссаров wrote: Modal dialogs on Mac doesn't show any title at all. OK, thanks for this information. However what about non-modal windows on Mac? Dialogs were just an example, really, the same applies to all toplevel windows in KDE4. So this will be platform-dependent (kde only?) feature:) Depends what happens on Windows, really. Hi David, for windows the following applies: - Normal windows don't have a title at all since Windows Vista. Are you sure? Isn't that only the explorer and other core apps that don't? http://www.paulscomputerservice.net/articles/images/Vista_Computer_Management.jpg Same in Windows 7: http://screenshots.en.sftcdn.net/blog/en/2008/10/windows-7-screenshot.png - (error) dialogs do have a title with the application name in it. In the case of Qt programs, does Qt add the application name, or Windows itself ... or is it missing? If Qt, which string does it pick up exactly? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Q_EXPORT_PLUGIN_2 breaks source compat
commit 7443895857fdaee132c8efc643e471f02b3d0fa4 Author: Lars Knoll lars.kn...@nokia.com Date: Sat Jun 2 05:42:13 2012 +0200 Remove support for Qt 4 style plugins The new plugin format allows us to avoid loading the plugins in all cases. Remove the old format, as we could get bad behavior with the old format if Qt would try to dlopen a Qt 4.x plugin. Change-Id: I2193e6874d6cca3c0b12298c2b9beb4105a42fd5 Reviewed-by: Thiago Macieira thiago.macie...@intel.com Reviewed-by: Lars Knoll lars.kn...@nokia.com This commit breaks source compat for all other kinds of plugins too, not only style plugins, because it turns the Q_EXPORT_PLUGIN_2 macro into a failing static assert. Case at hand: kdelibs/tier2/kauth/src/backends/polkit-1/Polkit1Backend.cpp:227:1: error: invalid application of 'sizeof' to incomplete type 'QStaticAssertFailurefalse' Is it really desired to break source compat so much, after making the promise of almost no porting required? Porting to a different plugin framework doesn't sound trivial. Well, maybe it is, who knows -- there is no entry in dist/changes-5.0.0 about this! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote: a) The parser is too trivial and doesn't handle the normal levels of complexity of command line arguments out there. (tar, find, zip, and standard Qt (built-in) arguments anyone?) Who needs to reimplement tar, zip, or find in Qt? These programs have a weird notion of command-line argument handling, but I don't see the need for Qt to provide this. If it had something much more standard, it would already be useful for 99%, no, 100%, of the Qt applications out there. b) The parser is too complex, where it doesn't live up to the simplicity expected from Qt API and usage. It's not such an insurmountable task. After all, libc has getopt, Qt has many complex things, surely Qt can implement some sort of getopt without resulting in too complex code. c) The parser only focuses on the standard for a single platform. (Linux users will not go for Windows style /? options, and Windows users won't accept --help Linux options, etc) Right, that one is true of KDE's KCmdLineArgs (which I want to see disappear due to bad API and not great implementation). It knows -s and --long. But surely supporting /s on Windows where -s would work on Linux is trivial. The problems with writing a parser like this is to make it general enough to support most of the Qt users, to justify it being part of the core set of modules. If it doesn't, it probably shouldn't be in QtBase, and as such should be a separate Addon, IMO. I don't agree. We've had something in KDE for 10 years, and not general enough (for any app-specific needs) has not really been an issue. The issue is the API (static array full of QT_TR_NOOP equivalents) and the implementation (much more C than C++). Anyways, something to keep in mind when working on your implementation. It's a can of worms with a lot of bikeshedding ;) Yes, this has been said a few times already. However I don't think this is enough of an argument for not doing anything about this in Qt (I know for a fact that your email discouraged Laszlo of even trying). If the message, upfront, is you won't be able to get this into Qt, then a natural reaction is to just say OK, then I give up, we'll do something KDE- specific instead. But this goes against my main goal of removing the distinction between a KDE app and a Qt app as much as possible. I see no reason why command-line argument parsing can't be provided by Qt. It's not as complex as you say, all kde apps do fine with the features listed at http://api.kde.org/4.x-api/kdelibs- apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8ff766034 You're right, tar couldn't use this. But then again, tar is not a Qt application, and will probably never be. And for a new program, there's always the option of *choosing* a set of command-line options that is actually doable with the existing Qt class, rather than going for something as funky as tar xvf. Look at GNU getopt: same issue, it can't be used by tar. So what? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
On Friday 24 February 2012 10:07:52 Lincoln Ramsay wrote:
However, a format string of say, %{category}: %{file}:${line} %{func}
%{message} would look odd when the category is empty.
mycat: foo.c:23 main() qCDebug
: foo.c:23 main() qDebug
I took the easy way of declaring a category for qDebug so I wouldn't
have to figure out how to do conditional formatting :)
Fair enough. But then call it default, not legacy.
--
David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] (long) thoughts on categorized logging (qLog)
Hi Lincoln,
Thanks for this updated vision for logging. I like this very much.
On Wednesday 22 February 2012 16:37:20 Lincoln Ramsay wrote:
PART 1: The logging statements.
qCDebug(PLUGIN) Scanning for plugins in paths;
qCWarning(PLUGIN) Could not load plugin loader-errorString();
Perfect!
PART 2: Compatibility with qDebug/qWarning
qDebug() and qWarning() will be re-implemented as categorized logging
statements. Both will use the same, hard-coded category. [...]
Very good. Please don't deprecate it though (you're already calling it
legacy) ;)
I consider qDebug(foo) and qDebug() foo to be the very useful throw-
away debugging, so indeed it should be on by default, and it should not be
considered deprecated/legacy.
PART 3: Turning statements on/off.
However, since there are likley to be many apps that don't care about
logging (or may not expose a way to turn on logging in a third party
library) there will also be a text-based config file that the user can
create. Where should this file be located? Either the app sets the
location of this file by calling qSetLoggingConfigFile() or the user
sets the QT_LOGGING_CONFIG environment variable (which overrides the
app's default). If the config file exists, the C++ API has no effect.
QFileWatcher will be used to monitor the config file so that categories
can be turned on/off while the program is running by updating the file.
Sounds good, except that I would want something more global than one file per
application. When working on a framework or an entire desktop environment,
one needs to be able to toggle a debug area across all apps. But the
environment variable could be used for that, so that's a solution.
PART 4: Formatting.
There's a %{category} entry that can appear in the format string. This
will be in the default format string.
+1
PART 5: Saving logs to a file.
As a special case, the user can direct enabled messages to a file. This
is done from the config file.
# write output to a file (in the user's home directory)
logging.output.file = file.txt
I suppose Windows users would expect relative paths to be in the CWD, which
is usually the executable's directory? Not sure.
Looks good.
--
David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: I'm preferring having QLog active only if a config file is there. It doesn't make sense to me at all having an environment variable that can activate QLog but not config file to activate the categories. As long there is no config file QLog is disable and uses less performance as possible but still having the feature that you can activate it without recompiling the code. Why? IMHO things should go to stderr by default. So it makes perfect sense to see the output, even if one didn't configure output files in a config file. I guess this is a mobile platform vs desktop platform discussion. On a mobile platform the logs are only useful if they go to a file, while on the desktop the logs are useful also if they go to stderr, to get them in a terminal or in the session log file. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:02:23 kai.koe...@nokia.com wrote: I agree with that: On the desktop it's quite handy to see also detailed output on stderr/the shell (which one can redirect to a file if needed). But I also think that qLog() messages shouldn't show up by default for normal users, that is, unless the category has been explicitly enabled. True. So how about adding another QtMsgType called QLogMsg, that qLog() uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be processed by default, unless the configuration file (or an environment variable) says so ... Isn't the same information given by a category is present in the QMessageLogContext? All qLog calls are forced to get a category, right? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: On 21/02/2012, at 7:36 PM, ext David Faure wrote: On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: I'm preferring having QLog active only if a config file is there. It doesn't make sense to me at all having an environment variable that can activate QLog but not config file to activate the categories. As long there is no config file QLog is disable and uses less performance as possible but still having the feature that you can activate it without recompiling the code. Why? IMHO things should go to stderr by default. So it makes perfect sense to see the output, even if one didn't configure output files in a config file. The whole idea is to have noop by default. Nothing. Ziltch. Not even std err. Use qWarning if you want or need that. That's what it's for. If you need this, only when you do a magical incantation, such as a config file or env var, will it produce any output. I agree. However my point was: once turned on, it could just go to stderr, and not require configuration of an output file. I guess this is a mobile platform vs desktop platform discussion. On a mobile platform the logs are only useful if they go to a file, while on the desktop the logs are useful also if they go to stderr, to get them in a terminal or in the session log file. Not really. It's more of not wanting to have any performance hits in shipping code. Even on embedded systems, developers want and need console output, and support services might need detailed log file at times. qlog makes this possible. Nothing stopping anyone from doing a tail -f my.log But there won't be a my.log configured by default, so the user needs to set that up first. I'm aiming at something that is simple to use for the simple case. When a user comes on IRC with a bug and we want to see the output, it should be simple for him/her to get that output. Finding the right config file and editing it by hand isn't exactly simple. Well, OK, a GUI tool can fix that; maybe we can even make that part of qtconfig. That would fix the issue nicely, in fact. OK, so objections withdrawn. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:19:49 kai.koe...@nokia.com wrote: -Original Message- From: ext David Faure [mailto:david.fa...@kdab.com] Isn't the same information given by a category is present in the QMessageLogContext? All qLog calls are forced to get a category, right? Right, but that would mean we can't use categories for anything except qLog. If we use categories solely for the purpose of filtering that's probably fine, but I personally also see some value in having them available as free text in the log, for all log QtMsgType's ... I would agree (after all we've been doing the same in KDE, it helps to understand where a warning or error comes from). But for this to be possible, we're back at the discussion of how to specify a category when calling qDebug or qWarning, and I thought the conclusion was no... In other words I like your idea, but there's no API to actually make it possible... -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:47:18 lorn.pot...@nokia.com wrote: On 21/02/2012, at 8:28 PM, ext David Faure wrote: On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: On 21/02/2012, at 7:36 PM, ext David Faure wrote: On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: I'm preferring having QLog active only if a config file is there. It doesn't make sense to me at all having an environment variable that can activate QLog but not config file to activate the categories. As long there is no config file QLog is disable and uses less performance as possible but still having the feature that you can activate it without recompiling the code. Why? IMHO things should go to stderr by default. So it makes perfect sense to see the output, even if one didn't configure output files in a config file. The whole idea is to have noop by default. Nothing. Ziltch. Not even std err. Use qWarning if you want or need that. That's what it's for. If you need this, only when you do a magical incantation, such as a config file or env var, will it produce any output. I agree. However my point was: once turned on, it could just go to stderr, and not require configuration of an output file. Not all systems even have easy stderr output *cough windows*. How are you going to retrieve that from an app installed in a sandbox on a clients system, when there is no access to a terminal ouput? If you want stderr, use qDebug or friends. You keep assuming that the developer is working on ONE application, and has full control over everything. This isn't how it works, in particular in KDE and other opensource Qt apps. The developer uses qDebug or qLog because that suits him/her, the user ends up on a completely different OS, with different needs If there is no access to terminal output (well there's always DebugView.exe too...), then the user can set up files, this doesn't change anything compared to your initial idea. How are you going to configure what categories are being transmitted without a config file? A string list in an env var? Some logging frameworks actually do that, I think. (libACE, iirc?) But OK, I'm withdrawing the whole point - a GUI will do the job just fine, as long as the qLog config file *does* allow the output for a given to go to stderr, not only to files. Who said anything about editing by hand? Simply have them install a preconfigured config file you give them. Which still requires finding out where the config file must go, on the user's system. But OK, no better solution anyway, and the GUI app can find out automatically. Heck you can even do that at first install, so there is a log file, just in case. Again, with first install you assume pre-built binaries and an installer. Not the case when you download the sources for a random Qt application from sourceforge, or when you apt-get install or equivalent. I keep seeing this mindset of one big commercial application on this list, but Qt developers have to realize that there's also the opensource application use case, as well as the Qt-based framework use case (where changing the defaults for logging, or installing config files, is definitely not wanted). -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Monday 20 February 2012 12:25:07 Lincoln Ramsay wrote: On 02/17/2012 06:23 PM, ext David Faure wrote: Yes, end users don't like debug statements polluting their terminals and session log file. With the above reasoning, we could just keep saying do not use qDebug in committed code and the problem would be fixed. But in the case where developers don't follow that rule, users will appreciate an off switch :). Ok... I think I'm convinced. You can of course always drop these messages from the message handler. No, users cannot do that ;) Application developers can, but not library developers nor users. Especially in the open source world, where libraries and apps are developed by different people, and the app developers have little control over the code in the libs they are using. Well, I suspect this happens in commercial setups too :-). Proper usage of qLog with areas solves the lib issue, but there's also the case of using 20 different apps, which use qDebug without an area (that's what qDebug is for), and users then need to be able to switch it off. Turning off qDebugs using the if (!enabled); else pattern would make these ignored debugs cheaper so it makes sense to do that in the macro. Yep. Where I'm a bit less clear is how the API for this would look. Do you imagine something in the qLog config file? An environment variable? A C++ API? I think something in the qLog config file is the best option. It allows to provide a GUI tool that toggles the configuration, for users. An env var would be my second favorite, a C++ API is definitely a no since the goal is to let users toggle it. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
[oops, mail sent too early] On Monday 20 February 2012 16:38:50 David Faure wrote: On Monday 20 February 2012 14:33:26 Thiago Macieira wrote: On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote: Do you imagine something in the qLog config file? An environment variable? A C++ API? I think something in the qLog config file is the best option. It allows to provide a GUI tool that toggles the configuration, for users. Remember that QtCore has no configuration file. Clearly you haven't read http://codereview.qt-project.org/#change,13226 We've removed all traces of QSettings support so QSettings could be moved away. QFile is all that's needed to implement a basic config file, QSettings is not needed. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Friday 17 February 2012 09:19:04 Lincoln Ramsay wrote: The goal: that global_enabled() affects *all* qDebug statements, not only those with a category Unlike qLog (which defaults to off), qDebug must be on by default or we break all existing code. This means a runtime switch for qDebug would only serve to turn all qDebugs off. Breaking existing code in terms of changing the default in Qt5 isn't that big a deal, it's not like people will have to change their code, just to enable a setting. But I can see an interesting point here: with your current solution, qDebug is the one to use for throw-away debug statements added temporarily to a piece of code one is debugging, while qLog(area) is for debug statements that will stay into the committed code, and therefore the first one should be enabled by default (for convenience) and the second one should be disabled by default (for noise reducing reasons). This is a valid point for the different default, I can accept it. Is this really a useful thing? Qt itself has no qDebug statements but perhaps other, third party libraries have left them in. In that case, having a runtime disable option may be warranted. Is that what you meant? Yes, end users don't like debug statements polluting their terminals and session log file. With the above reasoning, we could just keep saying do not use qDebug in committed code and the problem would be fixed. But in the case where developers don't follow that rule, users will appreciate an off switch :). (try to explain to a new developer, the reason why the global switch to disable debug output There is no global switch to disable debug output with qLog. What's QLog::instance()-isEnabled() then ? Please read the code before commenting on the implementation. http://codereview.qt-project.org/#change,13226 Hey, I reviewed on that change before I even wrote here. But the global switch idea comes from your own email from 10/02, which says: if (!global_enabled() || !category_enabled(cat)) /*NOP*/; else qDebug() I didn't make up that notion of global_enabled(), it's from you... The only reason is well, I didn't dare to touch qDebug itself? I think it's the right time to touch it :-) As has already been covered, the C++ language does not let us overload the qDebug macro with category support and overloading at the function level results in a potentially large performance hit. Sorry I didn't mean the qDebug macro/API, but the QDebug implementation. I'd like qDebug() and qLog() to share as much as possible of the implementation. I can drop the idea of the global enabled switch affecting both, for the reason above, but still, QT_MESSAGE_PATTERN should affect both, qInstallMessageHandler should affect both, etc. More generally, sharing the same output subsystem (with the addition of logging to files, but that's downstream from the shared formatting and handler-hook code). -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Friday 10 February 2012 09:25:05 Lincoln Ramsay wrote: The only way to avoid some_expensive_function() is to not execute that code path at all. Thus the macro expansion: if (do_nothing) /*NOP*/; else qDebug() some_expensive_function(); I think this is missing the point that qDebug() itself is a macro already (now, in qt5). #define qDebug QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug So why not *change* the qDebug macro to something like if (!global_enabled()) /*NOP*/; else QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug and the function/macro that takes categories can add the check for categories in addition. The goal: that global_enabled() affects *all* qDebug statements, not only those with a category, leading to better integration, rather than to two competing frameworks inside QtCore itself (try to explain to a new developer, the reason why the global switch to disable debug output only works when a category is specified...). The only reason is well, I didn't dare to touch qDebug itself? I think it's the right time to touch it :-) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Wednesday 15 February 2012 11:10:35 Lincoln Ramsay wrote: Warnings have always been unconditional and will remain so. Not exactly. They can be disabled at compile time by -DQT_NO_WARNING_OUTPUT. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Work on qDebug and friends
On Sunday 05 February 2012 10:50:48 BRM wrote: From: Diego Iastrubni diegoi...@gmail.com On Fri, Feb 3, 2012 at 1:10 PM, David Faure fa...@kde.org wrote: Once this goes in I'll add support for %pid%, %processname% and %timestamp%, and we'll be all set :) You meant %threadid% of course... right? Wouldn't having both available be useful? Yes, the PID is definitely what I meant, it's very much needed, for the case of multiple daemons running in the background and outputting debug into the same file. The PID is then useful for killing a run-away daemon, or for attaching gdb to it, etc. Without the PID, impossible to notice that these two lines come from two different processes, for instance: 20:29:11 konqueror(2630) kdemain: Unknown class in session saved data! 20:29:11 konqueror(2625) KonqSessionManager::askUserToRestoreAutosavedAbandonedSessions: /home/dfaure/.kde4/share/apps/konqueror/autosave/owned_by_1.33/_1.60 -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Work on qDebug and friends
On Friday 03 February 2012 10:51:50 kai.koe...@nokia.com wrote: Finally I came around to actually implement something: http://codereview.qt-project.org/#change,15129 The idea is that you can customize the output by setting the QT_DEBUG_PATTERN environment variable. Setting it e.g. to [%type%] %file%:%line% %function% %message% Would generate lines like: [debug] ../helloworld/main.cpp:7 main HELLO WORLD Excellent idea!!! Much better than my 6 env vars in KDE! Once this goes in I'll add support for %pid%, %processname% and %timestamp%, and we'll be all set :) However, I'm not really sure whether that belongs into Qt Core or not. I would definitely like it to go there. A separate module that apps have to link to and initialize, only helps the case of a developer working on his own application. It doesn't help the more general case of an opensource developer/user debugging an existing application, or a whole set of applications in an existing framework/desktop. There's no way to patch all apps just to be able to distinguish their output in ~/.xsession-errors. I agree with logging to files, sockets, syslog etc. being in a separate addon. But I would say that making the basic output useful belongs in Qt Core, so that *all* Qt applications in the world can benefit from it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On Wednesday 01 February 2012 15:03:57 BRM wrote: It does the job for a very basic logging system, but when you need to start categorizing your log messagse it does not do well at all. Hence the idea of adding the category to the new QMessageLogContext class (see global/qlogging.h). However, we should also offer a more extensive logging system that can be used instead - which registers a message handler and takes over. Yes. I don't mind multiple outputs, I just want a single input, i.e. that the code uses qDebug() / qDebug(AREA) no matter what output (message handler) is being used. Or what about when you want to record to multiple facilities? E.g. sending to syslog and your own file logging. (This is useful in distributed logging situations so that you can capture a local log and still send out to the distributed log as well.) Yes, all that can be done by the QLog code, triggered by the qt message handler which would provide it the info it needs. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Thursday 02 February 2012 12:52:38 =?ISO-8859-1?Q?Andr=E9?= Somers wrote: I think there are plenty of implementations doing this already. Take a look at QxtLogger for instance. It can be used with the output handler just fine, but it also allows more finegrained access with more than four levels. It also supports multiple outputs. I see no need to make all this part of Qt *now*, especially not of core. The very existence of external libraries that integrate with the current structure shows that it is exendable enough. Well, Qxt and kdelibs are entire frameworks on top of Qt, but this makes the lib code very inconsistent, and not every little app wants to link to a big framework, especially for something as small as debug output handling. I want to get rid of KDE's kDebug so that there is less difference between a Qt-based library and a KDE-based library. The last hurdle for that is: 1) showing more information (file, line, method, process name and PID) in the default message handler, probably based on env vars (easy to add now that QMessageLogContext has the necessary information). 2) support for debug areas. QLog's way of defining areas looks very nice, but it should be integrated with qDebug, as discussed previously. Again, this is about standardizing the debug statements in all qt-based libs, it doesn't prevent external loggers handling for the output in customized ways in specific apps or frameworks. In fact, because of the lack of debug areas, Qt code itself can't leave a single debug statement uncommented. Parts of Qt are full of #ifdefs to disable debug output by default. This could be done much better by registering an area and asking for it to be disabled by default. Then people could enable debugging from e.g. qsslsocket or QNAM or qimagereader without recompiling Qt [qdbus has a custom solution for this, $QDBUS_DEBUG, showing that is really a need for this]. I think this clearly shows there is a need for something better in QtCore. Extra code in external libraries doesn't solve this core issue. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Thursday 02 February 2012 15:01:02 shane.kea...@accenture.com wrote: An important requirement is that it must be easy to enable debugging in Qt libraries without touching the application code. This is so that we can debug regressions affecting closed source applications. With the existing qDebug, we need to disable the qInstallMsgHandler call*, and recompile the relevant Qt libraries with debug logs enabled. How about submitting a patch to Qt 5 that makes qInstallMsgHandler a no-op when an environment variable $QT_NO_MESSAGE_HANDLER is set? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Wednesday 01 February 2012 11:20:17 Lincoln Ramsay wrote: In summary: 1) Generated default logging config file (for sanity). I agree (please use QStandardPaths::writableLocation(QStandardPaths::ConfigLocation) as the base directory for it) 2) QLog::setDefaultConfigFile for application writers. 3) QLOG_CONFIG_FILE for users. +1 However I would like this to be called qDebug(AREA) rather than qLog(AREA). Otherwise we are presenting a confusing situation of two competing debug- output frameworks inside Qt. Couldn't the definition and use of categories be done in the newly merged corelib/global/qlogging.h, and shipped as part of the QMessageLogContext class? Then the default message handler can do what your qlog code is doing, i.e. write the stuff into the right log file, if the app or the user chose log files (by default I think this should still go to stderr, logging to files should only be an additional option). I think this would be a much more integrated solution than asking people to choose between qDebug (stderr) and qLog (files) at development time, and then letting no choice to the final user, or to other developers working on the same code later on. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QLog ( Work on qDebug and friends)
On Wednesday 01 February 2012 10:02:00 BRM wrote: I would also suggest that the plugins use a standard public interface class such as QAbstractLogFacility, like QTcpSocket uses QAbstractSocket - so that people can add their own custom logging output easily This is already available, see qInstallMessageHandler in Qt 5 (qInstallMsgHandler in earlier versions) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QString::toHtmlEscaped()
On Thursday 19 January 2012 15:16:29 Robin Burchell wrote: Hi, On Thu, Jan 19, 2012 at 11:02 AM, lars.kn...@nokia.com wrote: Is there really any big value in having this? It feels wrong to have special handling for HTML in here. While it's one of the most prominent formats for rich text, there are so many other formats that would require different escaping and we certainly don't want to support them all. I can live with toHTMLEscaped(), since it cleans up a really messy part of the Qt 4 API, but I'm not sure I want to extend this a whole lot more. Big value, well... as you mentioned, it's common. I've needed to write code to do entity decoding in the past, I'm sure a lot of others have. Yep. http://lxr.kde.org/ident?i=resolveEntities shows 6 different KDE apps which have a need for it. Plus one using fromEntity. IMHO this shows that this functionality should really be in Qt indeed (but not necessarily in QString or even in QtCore) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QFile: writing via a temporary file
On Tuesday 10 January 2012 13:43:29 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote: On 6. jan. 2012, at 21.27, ext David Faure wrote: On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote: I don't support putting this in QFile as has been suggested as, from my experience with it, this will open a can of worms in maintenance and subtle issues cropping up in user code such as the ones being discussed: what's fileName()? Does it exists() before commit? What do remove() and rename(newName) do? If we go towards the idea that the temp file is really internal (as the idea of a mode flag would point to), then fileName() can keep being the target file, exists() will only be true if it already existed before starting to write. If it didn't exist before, then f.open(); f.write(); f.exists() is very fragile anyway, isn't it? It sounds like the result depends on whether OS flushed it to disk or not... So this doesn't seem like a valid use case anyway. If your argument that deriving or adding functionality to QFile is that we'll be able to use the transactional feature with old code, then we need to consider cases that previously were valid because there is code doing a lot of interesting things out there. Well it's not like the feature will be enabled by default, either. Developers will still to activate it, and look at the actual code writing into the file. Still, I feel we're discussing an impossible corner case here, checking exists() after open() and before write(). Adding something that we know no one is using because it didn't exist before allows us to focus on the features and use cases we want to support. Agreed. When it comes to remove and rename, they are already documented to close the file first, so this would finish the writing operation, and no surprises will happen to the user calling them. No issue of which file is it about, there is only one file after close() anyway. I'm coming to think that relying on close (explicit or implicit) to mean commit is a really bad idea. Particularly when interacting with legacy codebases that were not written with that assumption. Unless QFile itself remembers that an error happened, see the other email I just sent, which I think interacts perfectly with legacy code bases (doing f.write(foo); f.write(bar);). I think we would be well served by an API that exposes a QIODevice interface plus additional interface for commit/rollback. This represents more porting effort for the application developer. I have seen it in KDE in the past, where having to manage one more object, but only in writing mode, not in reading mode, and making sure to call commit/rollback on it, was a lot of trouble, compared to the initial code that was simply using a QFile for all that. Enabling a flag on that QFile would have been s much easier. If it's a QIODevice, it can handle reading and writing, but I'm not sure it's relevant in this context. Who are the readers and would they be reading a half-written version of the file? (Why?) I never said anyone would care about a half-written file... I meant that your loading and your saving code aren't symmetric. Instead of using QFile for both, you have to use a different class for saving. This creates difficulties in classes that want to share code between loading and saving (e.g. I had that in a zip handling class, which much like qfile, had a open(Mode) method). When writing to a file, you normally don't have to confirm yes I want to commit my changes. So the safer use of a temp file shouldn't require this either, others have convinced me in this thread. Because normally you don't get the transaction guarantee we'll be getting with your feature and normally you're not throwing away a good complete copy of your thesis ;-) Yes you are, when you're writing over it. And you're losing it, if the disk gets full while saving. Hence QFile::open(QIODevice::WriteOnly | QIODevice::Transactional) ;) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Friday 06 January 2012 19:09:26 Thiago Macieira wrote:
On Friday, 6 de January de 2012 21.38.19, David Faure wrote:
The first solution doesn't look nice. It would have to fail opening
completely.
Well, this is just like using ReadOnly | Truncate, for instance. These are
incompatible. What happens? Truncate will be ignored, and you don't even
get a warning. (Both the code and a quick test indicate this).
I'd have expected that to give you a read-only 0-bytes file.
Nope, ReadOnly isn't supposed to make changes to the file ;-)
In any case, both flags are specified at the same time. If we're going to go
with this feature in QFile, then the flag should be specified in the call to
open().
Yes, everyone agrees on that, then.
But I think I prefer a QSaveFile, derived from QFile, with the proper
semantics.
Heh, a 4th solution, to make this debate even more endless :-)
Fourth? I thought it was your first. I considered separate class from
QFile and QFile as the two options.
Ah, but my separate class initial idea was the KDE/QtCreator idea, i.e. a
class that isn't a QFile. So deriving from QFile is a new idea :) But indeed a
better one than the KSaveFile case which requires the developer to handle two
different class instances. So let's forget about separate and not deriving.
Why would this be better? It can't be because it's not clear which file
some methods should work on (Joao's argument), since it would still have
all the QFile methods. It can't be because we need additional API compared
to QFile, or is it, for one single rollback method? ;)
QTemporaryFile derives from QFile. I think a QSaveFile is the same as a
QTemporaryFile, except it's not temporary: when you close it, instead of it
going poof!, it gets made permanent.
The code that does the writing doesn't need to know that it's operating on a
regular QFile, a QTemporaryFile or a QSaveFile.
I used to disagree, for error handling reasons, but in fact there are many way
to do the error handling, and the best way would be inside QFile itself.
Otherwise, with the current proposal, we would have to write code like this:
class C
{
C(QFile* file) : m_file(file) {}
QFile *m_file;
};
One solution:
bool C::writeMoreData(const QByteArray data) {
if (m_file-write(data) != data.size()) {
return false;
}
return true;
}
And the caller, which creates C(new QSaveFile), then has to do
if (!c.writeMoreData(data)) {
m_saveFile-rollback();
}
A much better solution would be:
void C::writeMoreData(const QByteArray data) {
m_file-write(data);
}
And inside QFile::writeData(), we set a bool m_writeError if write couldn't
write data.size() bytes. And this way in finalize()/close() we call rollback if
an error happened. I think this is what Oswald called latching errors.
The existing calls to setError in writeData and flush are not helping because
1) they don't detect partial writes (ret len)
2) the error code is cleared on the next call to writeData.
So I think a new bool is needed, set by setError, and not reset until closing
the file.
And this way we can make close() (and the destructor) do the right thing: it
will commit (atomic rename) if there were no errors during writing, and it
will rollback (delete temp file), if there were any errors during writing.
I think we focused the discussion too much on forcing the developer to
confirm that he wants the file saved, which doesn't make sense to me.
If there were no errors, then yes you want it saved, of course. So if
QFile can know by itself, this makes the feature a lot easier to use.
Now that I think of it, this could be done in QFile itself or in a subclass,
just the same. Which still leaves me with two possible designs:
A) QFile subclass, with commit() and rollback() API.
B) QFile builtin mode.
Thiago's emails made me realize that this solution is only valid if no
additional API methods are needed (since otherwise we have methods that don't
make sense unless we're in a specific mode, so better put them in a subclass).
But do we still need additional methods? The developer can ask close() to
roll back by simply calling setError() on the file before closing, for errors
that QFile couldn't detect itself.
I want to make it correct, but also easy to use, for the simple case.
So I prefer B, using QFile and setting a flag. Shall I put that on gerrit or
are there objections on the idea itself?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote: On Thursday, 5 de January de 2012 22.48.32, David Faure wrote: Solution 2: how about making this functionality part of QFile itself? No need to port to another class anymore, just enable the safety feature by calling file.setUseTemporaryFile(true). What happens if you open the file in read or read-write mode while the flag is on? I think that should just ignore the request for a temp file, since it cannot possibly be honoured. Or if you prefer it could print a warning and fail. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QFile: writing via a temporary file
On Friday 06 January 2012 09:50:14 Artur Souza (MoRpHeUz) wrote: On Thu, Jan 5, 2012 at 8:32 PM, David Faure fa...@kde.org wrote: Now there's just one question remaining: even if the rule is that all operations apply to the temp file, between open and close... what should QFile::fileName() return? The temp file name, to obey that rule, or the target file name, for symmetry with setFileName()? I'm tempted to say: the latter, because the temp file is really internal, and to prevent surprises (breaking symmetry with setFileName). Of course it means file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :) But imagine the following scenario: file.setUseTemporaryFile(true) file.open() file.write() APP CRASHES If file.fileName() would return the original filename, how one can restore the temp file? Would the temporary filename be deterministic? No, no, the whole idea of this feature is not to use the temp file as a backup. If the app crashes, you lose your partially-writen temporary file. That's fine, it was partial anyway, why would you want to use it? I think you're confusing this with a backup feature, which is unrelated. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
this save file wrapper class, which is hard to picture in one's mind, and to name properly for what it does. API-wise, such a class has methods like commit() and rollback(), to decide what happens when we're done. If you forget to call either one, the destructor will decide for you. Funny, in KDE it commits, in QtCreator it rolls back... And still those are working examples from the real-world where exactly such solutions were preferred over extending QFile. We had no other choice back then! It was pretty much impossible to contribute to Qt, this is why we all had to have our own additional classes. This definitely doesn't mean it was the best way to solve the problem... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Removing QBool?
QBool was introduced in Qt4 because qt3 had int contains(...) so there was a need for a compile error when writing (if contains(...) == 2). But it surprises people, e.g. this code doesn't compile: QSettings::setValue(foo, qstringlist.contains(bar)); And I've seen customer code using QBool as a bool container... If it exists in Qt, it must be better... Shouldn't we clean that up for Qt5 and just use a bool for the contains method again? The Qt4 API ensures that nobody still has if (contains()==2) in their code anyway. I can make the change next week if it's okay with everyone. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] New QUrl implementation
On Tuesday 27 December 2011 12:24:23 Thiago Macieira wrote: On Tuesday, 27 de December de 2011 13.42.10, David Faure wrote: On Friday 23 December 2011 17:22:38 Thiago Macieira wrote: QUrl: Always lowercase the scheme Change-Id: I8d467014d22384f1be15fdd746e20b1153a82a4e Do we want this? I think so. I would say yes, too. This simplifies the checks in application code. PS: great work on QUrl! Isn't this going to go to gerrit for review before merging? I'm surprised that this is in gitorious branches for now, but I suppose that's because topic branches don't really work there iirc. I'm not allowed to submit to Gerrit. I can only publish as open source. Hmm, so what now? How do we get this into Qt? (I suspect that this is a touchy legal issue I probably shouldn't dig into, but this has a huge effect on kde frameworks 5, so I need to know if this is going to be solved...) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Qftp removal
On Saturday 24 December 2011 09:24:52 Thiago Macieira wrote: On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: I've been using it for a year now, have had no problems on Linux and Windows. I use it to check for application upgrade. Is there a recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp getting into Qt Commercial ? Qt Commercial and Qt Open Source are the same. If it's removed from one, it's removed from both. We can probably place it in a separate module for people who still need it. The recommended way is to use QNetworkAccessManager, which does not have API for listing directories. A solution with Qt5 will be to use KIO, since we (the KDE developers) are working on making it useable on top of Qt with much less dependencies than in the current code. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] New QUrl implementation
On Friday 23 December 2011 17:22:38 Thiago Macieira wrote: QUrl: Always lowercase the scheme Change-Id: I8d467014d22384f1be15fdd746e20b1153a82a4e Do we want this? I think so. I would say yes, too. This simplifies the checks in application code. PS: great work on QUrl! Isn't this going to go to gerrit for review before merging? I'm surprised that this is in gitorious branches for now, but I suppose that's because topic branches don't really work there iirc. What I would like to do with your new QUrl (after this week's vacations) is to import it into kdelibs-frameworks, to port kurltest to it and see what breaks. Or did you do that already locally? You have my permission to import any tests from kurltests that I wrote, into the qurl auto tests, of course. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Tuesday 20 December 2011 11:18:21 lars.kn...@nokia.com wrote: On 12/16/11 8:37 PM, ext David Faure david.fa...@kdab.com wrote: On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. While I understand the reasons, I want to state that this is going to make support a mess. Both versions are called 4.8.0, but do not contain the same code. So when someone says With Qt-4.8.0 I have the following issue, it will never be clear which 4.8.0 this is about, we'll have to educate everyone to say in addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version number be different, when the code is different, instead? E.g. 4.8.0c. That doesn't fit into the numerical QT_VERSION, but at least qmake -query and every other location which shows a qt version number (packages, qt creator, etc.) would show clearly 4.8.0c instead of 4.8.0. To some extent Linux distributions have always done that as well, and I still remember something called qt-copy in KDEŠ ;-) I see no relation at all. qt-copy was for the convenience of kde developers, definitely not for anyone else to build upon. And, there was nobody selling support for it, either. And, there was a #define to distinguish it from upstream qt, allowing ifdefs if necessary. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Saturday 17 December 2011 09:01:35 craig.sc...@csiro.au wrote: On 16/12/2011, at 10:37 PM, David Faure wrote: On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. While I understand the reasons, I want to state that this is going to make support a mess. Both versions are called 4.8.0, but do not contain the same code. So when someone says With Qt-4.8.0 I have the following issue, it will never be clear which 4.8.0 this is about, we'll have to educate everyone to say in addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version number be different, when the code is different, instead? E.g. 4.8.0c. That doesn't fit into the numerical QT_VERSION, but at least qmake -query and every other location which shows a qt version number (packages, qt creator, etc.) would show clearly 4.8.0c instead of 4.8.0. I'd actually prefer to *not* see fiddling with the version number format. That would just make it harder when creating automated scripts to build things and it can also break code that expects the Qt version number to be in the long established x.y.z form. Consider the common (recommended?) way to test for Qt versions in code: #if QT_VERSION 0x040800 // #endif As I said, this doesn't affect QT_VERSION. I'm only talking about the string representation of the Qt version. What should this do for something like 4.8.0c? Better to not confuse things and to leave the version number as it was. In practice, I'd be surprised if there was much confusion caused by Digia supplying a customised 4.8.0 which includes just fixes. If people are using Digia's 4.8.0 version, I suspect they are also likely to report bugs they find to Digia instead of to the general Qt bug tracker anyway. I disagree. They will post questions to forums, to consultants, on blog posts, etc. etc. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. While I understand the reasons, I want to state that this is going to make support a mess. Both versions are called 4.8.0, but do not contain the same code. So when someone says With Qt-4.8.0 I have the following issue, it will never be clear which 4.8.0 this is about, we'll have to educate everyone to say in addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version number be different, when the code is different, instead? E.g. 4.8.0c. That doesn't fit into the numerical QT_VERSION, but at least qmake -query and every other location which shows a qt version number (packages, qt creator, etc.) would show clearly 4.8.0c instead of 4.8.0. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QTemporaryDir API
On Friday 18 November 2011 11:32:09 Olivier Goffart wrote: On Friday 18 November 2011 05:01:44 Jason A. Donenfeld wrote: A general [static] recursive remove directory function belongs in QDir. A member recursive remove *this* particular *temporary* directory function belongs in QTemporaryDir. Putting a generalized recursive remove directory function into QTemporaryDir makes no organizational sense. Did you read the argumentation at http://developer.qt.nokia.com/forums/viewthread/9860/ ? One good reason for having it there, is that there are tons of different ways to handle errors. And the way that it picked by QTemporaryDir::removeDir is to keep going as much as possible. When removing a user's directory, maybe you want to stop at the first error, instead. Or to pop up a dialog about the error and offer continue/abort/skip/etc. So for the one particular implementation of remove as much as possible in order to free space in /tmp, having it in QTemporaryDir makes sense. I agree with that, IMHO it belongs to QDir. About the fact that the function is dangerous, yes it is, but it is something developers want to do anyway, and not only with temporary directories. I agree that dangerous is not a valid argument, QFile::remove is dangerous too. But error handling is a valid argument. The alternative is to have QDir::removeRecursive(StopOnError | ContinueOnError) of course. I'd be fine with that. But apparently we still need to convince Lars that it's ok :) -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QTemporaryDir API
On Thursday 17 November 2011 13:52:55 lars.kn...@nokia.com wrote: Hi David, looks good in general. I am however concerned about the static removeDir() method. This one is pretty much the equivalent of a 'rm -rf'. Since it's not limited to temporary directories, so it doesn't match the class. It's also a rather dangerous operation, and I'm worried we'll see bugs in it's usage leading to users home directories being blown away. Well this is actually one of the reasons for having it in QTemporaryDir rather than in QDir : to make it clear that this should only be used for programmatically created dirs (mostly temp dirs, but there are a few other use cases like apps saving stuff into dirs). Not as a general QDir method to be used . The method already asserts if the path is empty or is ., we could make that stricter to catch more bugs (error instead of debug-mode-only assert, and refuse more paths, including the home dir). But I fail to see why this API could be misused is a reason for not having it. I mean, one could make the same argument against having QFile::remove in the API -- it could be used to delete the document that a user spent days to write! In any case: see http://developer.qt.nokia.com/forums/viewthread/9860/ for the popular demand for such a method. I could be convinced to put it into QDir, I would also be very happy to leave it in QTemporaryDir, for almost-like a temp dir but not created by QTemporaryDir because a random naming isn't wanted. But I think it would be a mistake to not have any recursive deletion method, available, still, in Qt5. Note that KTemporaryDir had a removeDir method for many many years and nobody ever blamed the kdelibs developers for bugs in its usage leading to users home dirs being blown away... If the app developers implement their own version and call it wrongly, then the users still lose data, and worse, we make this more likely by not providing a well-tested method to app developers. E.g. it's not only about the starting directory. There's the issue of not following symlinks to directories. Any naive implementation based on QFileInfo will get this wrong, and will follow symlinks. Ouch! -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QTemporaryDir API
On Wednesday 16 November 2011 18:22:23 Harri Porten wrote: On Wed, 16 Nov 2011, David Faure wrote: Thiago suggested that I post the header file here, to see if anyone had feedback on the (rather short) API. Actually I'll post the .cpp file too, since the documentation of the API is there :) I tried without the documentation. Feedback based on that: Hi Harri! Thanks for the feedback. 1.) I found the argument name templateName a bit confusing as it could also refer to the name of a template. How about nameTemplate? :) QTemporaryDir(const QString templateName); Good idea. This is based on QTemporaryFile's similar naming, though. 2.) I cannot remember details of Qt's naming policies anymore but autoRemove() very much sounds like an action. isAutoRemoved() would be clearer? The auto abbreviation is still questionable. Same here, this is for consistency with QTemporaryFile, and that's part of the existing API so I wouldn't change that. 3.) Shouldn't QTemporaryDir::removeDir(const QString path) rather be a removeRecursive() function in QDir? Arguable. See what the documentation for it says :-) And the discussion at http://developer.qt.nokia.com/forums/viewthread/9860/ ending with http://developer.qt.nokia.com/forums/viewthread/9860/P15 -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] QTemporaryDir API
On Wednesday 16 November 2011 18:26:25 Andre Somers wrote: Op 16-11-2011 18:13, David Faure schreef: Hello, As previously discussed on qt5-feedback, I wrote QTemporaryDir and submitted it to gerrit at http://codereview.qt-project.org/#change,8297 After a few reviews from Thiago (and redoing the implementation on Windows) it's now ready for submission. Thiago suggested that I post the header file here, to see if anyone had feedback on the (rather short) API. Actually I'll post the .cpp file too, since the documentation of the API is there :) There is no need to assing copyright to nokia :-) I am being sponsored by Nokia for my work on KDE, and right now this involves putting into Qt 5 what KDE needs. So it kind of makes sense that Nokia owns the copyright for it. (Yeah it's confusing, I'm posting this email as kdab.com instead of nokia- sponsored kde.org, but that's because subscribing with my kde.org address did not work, despite several attempts... never got any subscription emails). -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
Re: [Development] Platform / compiler support
On Wednesday 09 November 2011 11:32:31 Thiago Macieira wrote: Q_NO_DECLARED_NOT_DEFINED - no clue what this is This sounds like the compilers where doing the usual trick of defining a constructor private and never implementing it, since it will never be called is not allowed. No idea which compiler that would be though. MSVC 6? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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
