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"))
e 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
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 Fram
der 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, ht
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 Ex
r* 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 (Fran
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
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 i
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.
cts 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 - Pla
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
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
rty
> 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 i
27;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
read, 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
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&#x
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 propo
is about the job itself
needing to pop up a dialog. KIO's jobs already do that just fine. It's the
same job going on, the dialog is just an additional step, it can take care of
re-enqueuing into its own execution manager if that's needed.
I'm not saying some frameworks won't
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
g/projects/kde/kdelibs/repository/show/tier1/kcoreaddons/src/lib/jobs?rev=frameworks
--
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-indepe
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 com
dardPaths, 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
___
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
>
"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 Expe
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 | dav
;
+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
results.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 Gro
X 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-i
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 QSta
ell 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.
--
David Fau
58fa1c5d565090a9577a (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 mail
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
ind
d 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.
Test::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"
fact, is that I don't see a way to fix this without
a custom iodevice, so QDebug(QIODevice*) should probably be documented as
"doesn't support QT_MESSAGE_PATTERN, use qMessageFormatString if you want to
format the string" ?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
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 pa
rable?
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 con
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
>
On Friday 22 June 2012 17:08:48 David Faure wrote:
> 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 fo
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("
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.
> >
> >
-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
dow/QWidget.
};
(not sure if it should be a QObject for easier memory management)
--
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
On Thursday 21 June 2012 22:05:24 Mark wrote:
> On Thu, Jun 21, 2012 at 9:55 PM, David Faure 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 informatio
d 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
his 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-
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
mpat 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
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, f
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)
> 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 r
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 Feb
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"
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.
> >>
e (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.
x27;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
[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
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 "somethin
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
> > n
TERN 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 S
On Thursday 16 February 2012 16:23:28 Robin Burchell wrote:
> On Thu, Feb 16, 2012 at 4:08 PM, David Faure wrote:
> > On Wednesday 15 February 2012 11:10:35 Lincoln Ramsay wrote:
> >> Warnings have always been unconditional and will remain so.
> >
> > Not exactly. T
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.
r, 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
On Sunday 05 February 2012 10:50:48 BRM wrote:
> > From: Diego Iastrubni
> >
> >On Fri, Feb 3, 2012 at 1:10 PM, David Faure wrote:
> >
> >Once this goes in I'll add support for %pid%, %processname% and
> >%timestamp%,>
> >>and we'll be
session-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.
> 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?
--
Davi
On Thursday 02 February 2012 14:56:49 Robin Burchell wrote:
> On Thu, Feb 2, 2012 at 2:22 PM, David Faure wrote:
> > 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
> > th
bled 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
buted 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
able, 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
me
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
__
fforts from developers, this at least gives a
way to configure debug output on/off for each application separately.
I am, too, interested in hearing whether there are better solutions to the
problem.
--
David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KD
On Wednesday 28 December 2011 16:43:10 David Faure wrote:
> 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:
> > > > QUr
d 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
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 ReadOn
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 bee
way.
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
On Friday 06 January 2012 17:11:29 Thiago Macieira wrote:
> On Friday, 6 de January de 2012 18.34.21, David Faure wrote:
> > On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote:
> > > What happens if you open the file in read or read-write mode while the
> > > f
lback(), 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 solutio
On Friday 06 January 2012 14:43:30 Artur Souza (MoRpHeUz) wrote:
> On Fri, Jan 6, 2012 at 2:36 PM, David Faure wrote:
> > 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
On Friday 06 January 2012 09:50:14 Artur Souza (MoRpHeUz) wrote:
> On Thu, Jan 5, 2012 at 8:32 PM, David Faure 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
> >
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 safet
urse it means
file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Development mailing list
De
On Thursday 05 January 2012 22:21:54 Richard Moore wrote:
> 2012/1/5 David Faure :
> > 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.setUseT
p file.
The other question is, would one have to call commit/rollback explicitely, or
should QFile::close() (and the dtor) do the committing?
And how should one rollback? Explicit file.rollback(), or in the existing
file.remove()?
Oswald suggested doing that in close()/remove() directly, a
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: I8d467014d2238
t 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
ople 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
On Tuesday 20 December 2011 11:18:21 lars.kn...@nokia.com wrote:
> On 12/16/11 8:37 PM, "ext 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
> >>
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
7;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
would be to remove it from QTemporaryDir, and then have
> another merge request adding this as API to QDir.
Done:
http://codereview.qt-project.org/#change,9870
http://codereview.qt-project.org/#change,8297
--
David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.
OnError |
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 8
On Thursday 17 November 2011 17:14:06 Robin Burchell wrote:
> On Thu, Nov 17, 2011 at 5:11 PM, David Faure wrote:
> > 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
> >
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
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
&
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, si
eader 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 :)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Fr
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 softw
99 matches
Mail list logo
