On 8 January 2016 at 07:18, Turunen Tuukka
wrote:
>
>
> Hi John,
>
>
>
> This item was discussed at Qt Contributor’s Summit, please see session
> notes: http://wiki.qt.io/QtCS2015_LTS
>
>
>
> For compilers this is also documented to the Qt Base change log:
> http://code.qt.io/cgit/qt/qtbase.git/t
Hi,
Can I just clarify what the minimum deployment platforms are for 5.7
onwards? That is, the lowest version of each OS that the code must still
run on? Far as I can tell it's something like:
Windows 7 (or Vista?)
Windows Embedded Compact 2013
OSX 10.8
iOS 5.0?
Android 4.1 (API Level 16)?
RHEL
On 3 November 2015 at 14:28, Welbourne Edward <
edward.welbou...@theqtcompany.com> wrote:
> Hi all,
>
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the
[Reply to list this time...]
This could work, as Qt::LocalTime / Qt::UTC / Qt::OffsetFromUtc don't
actually create or use QTimeZone for anything (at least not yet,
LocalTime may yet). I'm assuming dates outside the 1970-4207 year
range would still use the d_ptr implementation, as would anything
us
lue2. And it seems
> I'm
> > not alone [fedbug].
> >
> > I searched the web and it seems the work on this has stoped. Does anyone
> > knows the state for this?
> >
> > Thanks in advance, Lisandro.
> >
> > [debbug] <https://bugs.debian.org/cgi-bin/
On 18 June 2014 07:15, Knoll Lars wrote:
> On 17/06/14 18:31, "Robert Löhning" wrote:
>>By the way: What will happen to bug reports from now closed identities?
>>The reporter won't get any notification and I'm afraid the watchers
>>won't feel addressed by the "Need more info" comment.
>
> Simple
On 17 June 2014 03:29, Christian Gagneraud wrote:
> On 14/06/14 05:06, John Layt wrote:
>> While a lot is dependent on me finding
>> time, there are tasks other people could take on, primarily greatly
>> improving our PDF writer support and adding equivalent XPS file format
&
Hi,
The notes form the QtPrintSupport session are available at
https://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtPrintSupport
. Basically it's a long list of all the work needing to be done to
finish the new print library. While a lot is dependent on me finding
time, there are tas
> Em sex 13 jun 2014, às 10:21:08, Massimo Callegari escreveu:
>> I've added QT_NO_PRINTER and QT_NO_PRINTDIALOG to my qmake.conf
>> Qt5 base 5.3.0 still builds fine. libQt5PrintSupport is still created but
>> it's only 43k now. Unfortunately QtWebKit doesn't seem to change in size (I
>> guess cau
On 30 April 2014 16:28, Andrey Ponomarenko wrote:
>
>
> ABI report for 5.3.0-rc:
> http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-rc/abi_compat_report.html
Hi,
Interesting that it reports a Medium severity problem for:
qpagedpaintdevice.h
enum QPagedPaintDevice::PageSize
: Zeeshan Ali (Khattak)
Date: 2 April 2014 17:00
Subject: Proposal: Location hackfest
To: John Layt , Aaron McCarthy <
aaron.mccar...@jollamobile.com>, Hanno Schlichting
Cc: Bastien Nocera , Ekaterina Gerasimova <
kittykat3...@gmail.com>
Hi everyone,
I'm planning a combined hackfest
Hi,
Bug report https://bugreports.qt-project.org/browse/QTBUG-38023 is a
release blocker as it causes an immediate crash in any Mac app using
printing when run as an app bundle on OSX 10.9 Mavericks. It does not
crash if the binary is run directly from the command line in 10.9, nor does
it crash
Hi,
I've been doing a bug triage for printing to see what I can close due
to the new code, and what high priority issues still need fixing.
I've grouped all 177 bugs by linking them to Tasks:
QTBUG-37696 QtPrintSupport - Bug Triage
QTBUG-25372 QtPrintSupport - CUPS Issues
QTBUG-25383 QtPri
Hi,
Thanks to some sterling work form the CI and Release teams, we've managed to
finally get the QtPrintSupport changes merged in time for Beta 1 :-) If you
run into any printing issues please let me know. I'll post a blog to Planet
Qt detailing how the beta testers can help test the new code
On 13 March 2014 18:21, John Layt wrote:
> On 13 March 2014 18:08, Frederik Gladhorn wrote:
>> Looks like we're somewhat back on track. We got a first run for qtbase
>> passing
>> and hopefully start getting the backlog down. Thanks for bearing with us,
>> there
On 13 March 2014 18:08, Frederik Gladhorn wrote:
> Torsdag 13. mars 2014 16.32.22 skrev John Layt:
>> On 13 March 2014 10:06, Sarajärvi Tony wrote:
>> > Hi
>> >
>> > No ETA. There are quite a few problems in the autotest side. Just a minute
>> &
On 13 March 2014 10:06, Sarajärvi Tony wrote:
> Hi
>
> No ETA. There are quite a few problems in the autotest side. Just a minute
> ago the last try failed. Have to fix more...
>
> -Tony
Thanks Tony. I guess we won't have it back now before Friday? Just
getting a little concerned my printing c
Hi,
[Mostly notes for Andy Shaw to review, but thought I'd post for anyone
interested]
In QtPrintSupport you can set the resolution to be used in printing, but as
with many parts of painting and printing there is confusion and inconsistency
between the painting resolution and the physical devi
On 12 March 2014 11:08, Sarajärvi Tony wrote:
> Hi
>
> Currently we are blocking QtBase_dev and qt4. We need to get a fix for an
> autotest through so that any commit will have a chance to pass the CI.
>
> Also, you might have noticed a few problems in the CI with breaking builds.
> Jenkins crashe
On 17 February 2014 14:04, Knoll Lars wrote:
> I¹ve been discussing a bit with Friedemann and Andy on IRC, and I¹m
> willing to give this change set an exception to the feature freeze. The
> reason is that I believe that this significantly improves our level of
> support in this area, and that th
On Wednesday 12 Feb 2014 15:37:29 John Layt wrote:
> On Wednesday 12 Feb 2014 12:03:53 John Layt wrote:
> > Sorry, needed to wait until the full stack of changes had been completed
> > and integrated before pushing. The revised patches are up for review, I'm
> > not sure
On Wednesday 12 Feb 2014 12:03:53 John Layt wrote:
> On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote:
> > Since the feature freeze is on the 14th I have been eagerly awaiting the
> > changes that have been indicated already have been done so I can carry on
> > testing. Have I m
On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote:
>
> Since the feature freeze is on the 14th I have been eagerly awaiting the
> changes that have been indicated already have been done so I can carry on
> testing. Have I missed some updates or something? I am concerned because I
> know how many peop
Hi,
I've seeing contradictory advice on Gerrit as to which branch to push bug-
fixes to, some say there will be no 5.2.2 so to use dev instead, others say to
keep using stable in case there is. What is the current "official" policy?
Oh, and please remember when making such decisions to clearly
On Monday 06 Jan 2014 22:40:44 you wrote:
> My aims for the 5.3 release will be to
> * Define the new qpa print device api and implement support for the 3
> core platforms
> * Use this new class in QPrinterInfo and QPrintEngine to replace the
> current print device code, ensuring behaviour is cons
Hi,
I've spent the last few weeks going over the current print support and
trying to map out a plan to improve things. We've long intended to
create a new QtPrint module to replace QtPrintSupport in which we
separate the painting code from the print job management code and
support a more modern w
Hi,
I'm refactoring the CUPS printing code (more on that in another email)
and noticed we don't currently have a minimum required version set,
i.e. we're currently restricted to the 1.0 api released in 1999. CUPS
is now at 1.7. There's some nicer api I'd like to use from 1.2 and
1.4, so for Qt 5
On 10 December 2013 16:29, Thiago Macieira wrote:
> John has one point: he could remove the fallback code for the timezone
> support.
Not for QTimeZone, the Vista stuff only extends the XP support, it
doesn't replace it. For QLocale and QCollator we could remove
fallback code.
John.
___
On 9 December 2013 23:23, Thiago Macieira wrote:
> As Kenneth reminds us[1], Microsoft is ending the security updates for Windows
> XP in April 2014. That's about when we plan to release Qt 5.3.
>
> Should we stop supporting Windows XP? Is there anything we can improve in our
> codebase if we do?
Hi,
I've pushed 4 fixes for QTimeZone to the release branch for review for
inclusion in 5.0:
1) https://codereview.qt-project.org/#change,70984
Rather embarrassingly I misspelt the name Olson as Olsen, including in new
public api for 5.2. This patch fixes the public api and docs, but doesn't
On 9 November 2013 12:50, Olivier Goffart wrote:
> On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote:
>> I like the idea of re-starting small, and quite a bit of what was done
>> in Nokia times can certainly be re-used.
>> What if Qt started by simply *enabling* color management. I.e
On 5 November 2013 12:03, Marc Mutz wrote:
> On Tuesday, November 05, 2013 01:07:32 Thiago Macieira wrote:
>> +// ### Qt 6: Merge with above with default offsetSeconds = 0
>> +QDateTime(const QDate &date, const QTime &time, Qt::TimeSpec spec, int
>> offsetSeconds);
>> +#ifndef QT_BOOTSTRAP
On 5 November 2013 05:09, Yuchen Deng wrote:
> The ICU dependency is very heavy, I did not like it.
> Is there any possible to make the ICU depend is optional?
> Thanks!
Sorry, it is not possible to remove the dependency, all you can do is
to reduce the size of ICU by not shipping data you don't
On 4 November 2013 08:22, Sletta Gunnar wrote:
> The work that was done is here:
> https://codereview.qt-project.org/#dashboard,1002033
>
> The work was abandoned after the transition to Digia and the author is no
> longer in the Qt community, so little has happened since then.
Thanks. It's a
On Monday 07 Oct 2013 10:35:26 David Boddie wrote:
> On Sun Oct 6 20:51:40 CEST 2013, Lars Knoll wrote:
> > I think this is fully correct, and doesn't assert any copyright over the
> > generated PDF. It states that the PDF got produced by the PDF generator of
> > Qt 5.1.1, which is (C) Digia.
>
>
On 2 November 2013 16:52, Thiago Macieira wrote:
> On sábado, 2 de novembro de 2013 13:06:43, John Layt wrote:
>> Hi,
>>
>> Just wondering if anyone knows about the state of Solaris support in
>> Qt 5, or if anyone is actively working on it? Over in KDE we're
&g
Hi,
I'm wondering if anyone is working on color management support in Qt
5? I know there was some thought about it before 5.0 and vague
suggestions about support in 5.1 or 5.2, but I suspect that was lost
in the move from Nokia to Digia?
Cheers!
John.
___
Hi,
Just wondering if anyone knows about the state of Solaris support in
Qt 5, or if anyone is actively working on it? Over in KDE we're
ripping out some time zone code that currently supports Solaris and I
was wondering if I needed to add Solaris tz support in Qt 5? If Qt 5
doesn't even build o
On 25 October 2013 15:55, Ramakanthreddy Kesireddy
wrote:
> Hi,
>
> Please let me know if there is a plan to enable support for offline
> Navigation and Map in QtLocation module.
>
> Thanks and Regards,
>
> Ramakanth
Until QtLocation does offer offline maps and navigation, you may want
to conside
On 28 October 2013 10:42, Simon Hausmann wrote:
> On Monday 28. October 2013 10.34.44 Sergio Ahumada wrote:
>> On 10/28/2013 10:32 AM, Simon Hausmann wrote:
>> > Hi,
>> >
>> > It looks like some locale or date time related change in qtbase broke
>> > qtdeclarative test integration on Windows. Does
On 22 October 2013 15:33, Vladimir Minenko wrote:
> The purpose of this email is not to point out something what is not done or
> wrong. The purpose of this email to initiate a discussion and a work to get
> this done and create a clear definition where Qt runs on and how related
> platforms a
On 23 October 2013 22:30, André Pönitz
wrote:
> One point that seems to be missing in these considerations is a clearly
> communicated distinction between "actual state" and "intended state".
>
> The use of "Tier" currently sems to close to "actual" state, and "reference
> platform" close to "int
On 17 October 2013 19:30, wrote:
> finally, I'm going to update date time classes to support world calendar
> types while keeping the binary compatibility.
>
> here's an overview of the new changes to be done at this level. Please
> review and let me know if something wrong.
>
> #JohnLayt I'd lik
On 7 October 2013 08:54, Samuel Gaist wrote:
> Hi,
>
> In which room are you hidden ? :-)
We are on the first floor, in a meeting room next to the coffee at the
end of the corridor past the toilets. If you can't find it come and
see me at the KDE booth in the 1st floor exhibition room.
Cheers!
On 22 August 2013 21:24, John Layt wrote:
> Hi,
>
> Qt Dev Days Europe is coming up on October 7-9 and once again this
> year KDE e.V. is partnering with Digia, KDAB and ICS in the running of
> the event. In particular KDE is once again helping organise a Qt
> Contributors Day
On 27 September 2013 15:37, Mitch Curtis wrote:
> On 09/27/2013 01:57 PM, Mandeep Sandhu wrote:
>> Hi All,
>>
>> I'm a Linux (Ubuntu) user. I've recently made some changes for a bug
>> report and wanted to test them on Windows as well.
>>
>> For that I've installed Windows (I've installed 7, do I
On Saturday 14 Sep 2013 17:11:50 John Layt wrote:
> As I said, I'm testing a speed-up for toMSecsSinceEpoch() which makes it
> faster than the old version, which feeds through to most of the other slower
> functions. I'll also have a look at date() and time() for improvement
Hi,
I'm trying to do a clean build on Mac of current dev branch, but I
keep getting the error:
fatal error: file
'/Users/odysseus/Development/Qt/src/qt5/qtbase/src/corelib/../../include/QtCore/qglobal.h'
has been modified since the precompiled header was built.
Any clues on how to fix that besid
On Saturday 14 Sep 2013 03:04:45 John Layt wrote:
> * Rather strangely timeSpec() is 30% slower despite now only returning the
> member directly instead of having to do a switch based on the member, a few
> other calls are equally confusing.
Ah, stupid me, I was including the creati
On Thursday 12 Sep 2013 13:48:24 Thiago Macieira wrote:
> On quinta-feira, 12 de setembro de 2013 21:06:03, John Layt wrote:
> > * Choose either local msecs or epoch msecs, if epoch then that change
> > can't
> > be done for 5.2
>
> Choose the easiest for you to
On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote:
> On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars wrote:
> > We might be able to simply cache the time zone offset once and cache it.
> > Then it should be at the same speed.
>
> This would also probably provide hidden wins in various places, mak
On Thursday 12 Sep 2013 19:24:15 Knoll Lars wrote:
> On 9/12/13 9:06 PM, "John Layt" wrote:
> >The first is it means creating a QDateTime becomes a
> >lot slower as we need to calculate the epoch offset up-front, instead of
> >only when/if needed.
>
> We m
Hi,
Another QDateTime email. I'm still trying to get a fully working
reimplementation of QDateTime as well as the QTimeZone support in for 5.2, but
there's a couple of issues outstanding.
Storage format / Change of System Time Zone behaviour: My current changes on
Gerrit for storing as msecs
-developer-buildOn 4 September 2013 15:21, Poenitz Andre
wrote:
>
> That's wasting our time, as predicted.
>
> ../../corelib/tools/qdatetime.cpp: In function 'time_t qt_mktime(QDate*,
> QTime*, QDateTimePrivate::Spec*, QString*, bool*)':
> ../../corelib/tools/qdatetime.cpp:258:34: error: comparis
Hi,
Qt Dev Days Europe is coming up on October 7-9 and once again this
year KDE e.V. is partnering with Digia, KDAB and ICS in the running of
the event. In particular KDE is once again helping organise a Qt
Contributors Day on Monday October 7th. We have been allocated a room
for the day to hold
On 20 August 2013 08:41, Koehne Kai wrote:
>> Is there any way to avoid the ICU dependency in QtCore while still building
>> QtWebKit with it?
>
> That would be part of the discussed changes, but it's not there yet.
>
> For Qt 5.x, I suggest you configure Qt with '-no-icu', and then run 'qmake
>
On 27 March 2013 20:11, John Layt wrote:
> On 26 March 2013 18:15, Thiago Macieira wrote:
>> On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote:
>>> As far as I understand, the CI is all in Finland, so GMT +2.
>>
>> In other words, the tests are
On 26 March 2013 18:15, Thiago Macieira wrote:
> On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote:
>> As far as I understand, the CI is all in Finland, so GMT +2.
>
> In other words, the tests are effectively disabled.
Yeap, and on all platforms too. I assume changing the CI ma
Hi,
I've just pushed another set of patches for the QTimeZone and QDateTime
changes. The current status is I think the code is now stable enough for a
final review and decision on whether to include in 5.1 or not.
The QDateTime changes for OffsetFromUTC and the formatter improvements can
cert
On Thursday 07 Mar 2013 16:16:05 Koehne Kai wrote:
> >> On 02/06/2013 11:20 PM, Koehne Kai wrote:
> >> > [...]
> >> > That is what we should do indeed. I learned from
> >> >
> >> > http://userguide.icu-project.org/icudata
> >> >
> >> > that one can also ship the ICU data in separate .data files,
Hi,
I've finally pushed my proposed QTimeZone support to Gerrit for initial review
for possible inclusion in 5.1.
The reviews are:
QLocale - Add private countryToCode() method
https://codereview.qt-project.org/50064
QDateTime - Improve and expose Qt::OffsetFromUtc
https://codereview.qt-project
On Wednesday 27 Feb 2013 13:49:48 Thiago Macieira wrote:
> On quarta-feira, 27 de fevereiro de 2013 20.57.22, John Layt wrote:
> > Currently is now dropped, we'll wait and see if there's any demand later.
> > It would actually be isDaylightTime(QDateTime::currentMSec
On Wednesday 27 Feb 2013 10:26:51 Oswald Buddenhagen wrote:
> On Tue, Feb 26, 2013 at 04:12:07PM -0800, Thiago Macieira wrote:
> > On terça-feira, 26 de fevereiro de 2013 22.42.31, John Layt wrote:
> > > On Wednesday 20 Feb 2013 16:16:55 Thiago Macieira wrote:
> > >
On Tuesday 26 Feb 2013 16:12:07 Thiago Macieira wrote:
> On terça-feira, 26 de fevereiro de 2013 22.42.31, John Layt wrote:
> > I'm struggling to think of something different, I can only think of uglies
> > like UnspecifiedTime, NonspecificTime or NotStandardTimeOrDaylightTim
On Wednesday 20 Feb 2013 16:16:55 Thiago Macieira wrote:
> For 12 commits, I'd just submit straight to dev.
Would you prefer it squashed to one big commit, or keep the platform backends
separate commits?
Except as noted below all other suggested changes are being made.
> - GenericTime and Sta
On 14 February 2013 19:21, Lorn Potter wrote:
> Back long ago
> https://bugreports.qt-project.org/browse/QTBUG-71
> (feel free to assign that one to yourself!)
> :)
Will do :-)
> I was working on porting qtopia's timezone class to qt.
> I added full windows <> olsen conversion. It was able to
On 13 February 2013 18:37, John Layt wrote:
> supplementalData.res
> timezoneTypes.res
> windowsZones.res
> zone/*.res
Oh, also looks like:
metaZones.res
zoneinfo64.res
I wish ICU wrote better documentati
On 13 February 2013 15:13, Koehne Kai wrote:
> Which parts of the ICU data are you using (from
> http://apps.icu-project.org/datacustom/ ) ?
> I'd really like us to strip down the default ICU libs on windows for 5.1 ...
Good question. I think the following under "Miscellaneous Data" would cov
On Wednesday 13 Feb 2013 08:49:56 Knoll Lars wrote:
>
> The detailed timeline will be as follows:
>
> * 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.
>
On Friday 11 Jan 2013 20:45:43 Konstantin Tokarev wrote:
> It's icky to cross-compile, otherwise bearable. Size comes only from bundled
> data, if you can use external dat file, your ICU may be quite small.
Unfortunately, the format of the the dat file is very tightly coupled with the
ICU major
On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote:
> Since ICU doesn't provide the debug version of the libraries in their binary
> packages then this means that either the user has to build them themselves
> (which means modifying the target as well since the output for debug and
> release defaults t
On 2 August 2012 13:26, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 12.02.45, lars.kn...@nokia.com wrote:
>>
>> I intend to move both Qt 3D and Qt Location out of the essentials list and
>> make them add-ons for now. They are fully usable as-is today, but with the
>> situation do
On 1 August 2012 17:56, Olivier Goffart wrote:
> On Wednesday 01 August 2012 18:37:14 Stephen Kelly wrote:
>> Given that https://codereview.qt-project.org/#change,31387 has been merged,
>> can you post any more information that will last until the QColorProfile
>> class can be implemented? Any ide
On 1 August 2012 04:00, wrote:
> Hi all,
>
> We have received word that the Brisbane Australia office, consisting of the
> teams working on Qt3D, QtDeclarative, QtMultimedia, QtSensors, and QtSystems
> modules, as well as the CI/QA team for Qt, will be shut down. Our last day is
> August 31.
>
Apologies for the late posting. The Qt Printing session consisted
mostly of a ramble by me on the current status and future plans,
followed by some discussion on areas of common interest.
Release status:
* Linux looking good, just some clean-ups and bug fixes in the print dialog
* Mac mostly goo
On 4 July 2012 07:03, wrote:
> While on the topic, if we move the widgets, we should also move
> libQtPrintSupport and libQtOpenGL to their own repositories.
That would be nice, but I don't think QtPrintSupport can go as yet as
the Mac plugin implementation is actually in the main Mac platform
Firstly, apologies for missing Day 1 of QtCS, production issues at work
prevented me from attending, but I am now on my way for the rest of the
event. I hope to run two sessions on either Friday or Saturday, one on
Printing, and the other on using ICU in QLocale, which will include plans
for QTime
On 16 June 2012 08:35, wrote:
> Thanks… Also do you know how to configure and build the qtpim module along
> with qtbase ?
>
If you follow the instructions at
http://qt-project.org/wiki/Building-Qt-5-from-Git there is a script
that does it all for you.
John.
On Wednesday 16 May 2012 23:49:42 John Layt wrote:
> Actually removing the "abstract" base class is just a case of
> s/QAbstractPrintDialog/QPrintDialog and tweaking the constructors, as the
> class is not really abstract, the only virtual method is exec(), nothing
> else get
On Wednesday 16 May 2012 10:14:27 Thiago Macieira wrote:
> On quarta-feira, 16 de maio de 2012 00.07.10, John Layt wrote:
> > The QAbstractPritnDialog and QAbstractPageSetupDialog classes are
> > completely unnecessary, are given as bad examples in the Qt API design
> > stand
Hi,
I want to request a late source incompatible change in QtPrintSupport.
The QAbstractPritnDialog and QAbstractPageSetupDialog classes are completely
unnecessary, are given as bad examples in the Qt API design standards, and
were marked to be merged with QPrintDialog and QPageSetupDialog in Q
On Friday 04 May 2012 09:26:26 Sean Harmer wrote:
> On 04/05/2012 08:11, Christoph Schleifenbaum wrote:
> > 3 maj 2012 kl. 21:41 skrev John Layt:
> >> Many thanks Christoph for sorting it so quickly. The crash fix works
> >> perfectly, and using Patch Set 4 does fix t
On Thursday 03 May 2012 20:50:44 Christoph Schleifenbaum wrote:
> 3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum:
> > 3 maj 2012 kl. 11:47 skrev Sean Harmer:
> >> On Tuesday 01 May 2012 23:21:50 John Layt wrote:
> >>
> >>
> >>> I've
On Monday 30 Apr 2012 09:06:28 morten.sor...@nokia.com wrote:
> That would be "not possible". QtGui and Widgets loads the Cocoa backend as a
> plugin and does not link agains it.
>
> I think the only options are either duplicating the neccesary code to
> support QCoreGraphicsPaintEngine in printsu
On Monday 23 Apr 2012 22:17:15 John Layt wrote:
> For Mac I propose moving QCocoaPrinterSupport into
> plugins/printsupport/cocoa and moving the private methods from
> QCocoaNativeInterface to
> QCocoaPrinterSupportPlugin. I'll do a patch.
>
> A harder question is where
On Monday 23 Apr 2012 13:20:08 morten.sor...@nokia.com wrote:
> On Apr 22, 2012, at 10:43 PM, ext John Layt wrote:
> > OSX:
> >
> > src/plugins/platforms/cocoa- QMacPrintEngine
> >
Hi,
While starting to review the current state of QtPrintSupport for Beta 1 and
one thing I've immediately noticed is an inconsistency in the platform
implementations as to which plugins have which classes where.
OSX:
src/plugins/platforms/cocoa- QMacPrintEngine
Hi,
QTBUG-24543 reports that the tst_QLocale::windowsDefaultLocale() test is
broken and is currently being skipped.
I've determined this is because the Qt4 mechanism for triggering a refresh of
the Qt system locale whenever the system locale is changed has been removed
from qapplication_win.cp
Hi,
In the QLocale header we have the following code:
//private:
// this should be private, but can't be
struct Data {
quint16 index;
quint16 numberOptions;
};
private:
friend struct QLocalePrivate;
// ### We now use this field t
On Friday 17 Feb 2012 15:28:49 Francesco R. wrote:
> Could you (as somebody involved in qt5 planning or development) clarify
> what the plan are for printing functionality, managment or whatever?
Hi Francesco,
I'm the new community maintainer for printing support in Qt, so I can fill you
in on
On Saturday 11 Feb 2012 13:26:49 you wrote:
> 2) Change format/parse API to support CLDR/ICU formats.
> 1) Keep one consistent API, minimise source compatability break by providing
> deprecated enum methods, but force everyone to switch to new format codes.
I've now pushed a patch to Gerrit impl
Hi,
Two essential areas need to be addressed. While these could be left for 5.1,
I believe it would be far messier as a result because we would have 2
different API's that are subtly different and would lead to confusion and
inconsistencies.
1) Change the Qt string format codes used to the CL
On Sunday 05 Feb 2012 14:12:48 lars.kn...@nokia.com wrote:
> Is there anything that I have now forgotten that really *must* be in 5.0
> (i.e. it really can't be done in a BC/SC way for Qt 5.1)? If you have such
> an item, please speak up, otherwise I'll consider the above exception list
> as final
On 24 Jan 2012 00:23, "John Layt" wrote:
>
> On Monday 23 Jan 2012 22:48:12 lars.kn...@nokia.com wrote:
>
> > I am very tempted to simply break this. localized binary numbers simply
> > don't make any sense.
> >
> > Cheers,
> > Lars
>
>
On Monday 23 Jan 2012 22:48:12 lars.kn...@nokia.com wrote:
> I am very tempted to simply break this. localized binary numbers simply
> don't make any sense.
>
> Cheers,
> Lars
Agreed it makes no sense.
My initial thought was just to move the code to say QString/QByteArray and
make it hard-code
On Monday 23 Jan 2012 19:42:57 Thiago Macieira wrote:
> You mean QLocale and QTextStream.
>
> QByteArray and QString do not need ICU since they are locale-independent.
> Parse LC_ALL=C in them only.
Yes, but the code is located in QLocalePrivate, and QSting/QByteArray create a
C QLocale to call
On Wednesday 18 Jan 2012 00:47:31 you wrote:
> * If we can port the QLocalePrivate number routines to call ICU instead of
> their current implementations, the rest of Qt will "just work",
Small wrinkle just turned up here, ICU only does parse/format for base 10
numbers and not for binary, octal
On Wednesday 18 Jan 2012 13:21:24 lars.kn...@nokia.com wrote:
> On 1/18/12 12:35 PM, "ext Thiago Macieira"
> >On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote:
> >> Other classes call public QLocale methods for number symbols like
> >> decima
On Wednesday 18 Jan 2012 09:35:02 Thiago Macieira wrote:
> On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote:
> > * QString will need a decision on the behaviour of toInt() / toLong() /
> > etc using the Default Locale.
>
> They should use the C locale, not the De
On Wednesday 18 Jan 2012 13:13:04 you wrote:
> 4.0 is certainly a minimum version. Do you know which ICU versions did the
> upgrade to 5.2 and 6.0?
>
> Lars
Yep, ICU 4.4 got Unicode 5.2 and ICU 4.6 got Unicode 6.0.
OSX 10.7 shipped with ICU 4.6.
John.
__
1 - 100 of 110 matches
Mail list logo
