Re: [Development] Minimum Deployment Platforms for 5.7 onwards?

[John Layt]

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/tree/dist/changes-5.5.1
>
>
>
> For 5.6 the current list of supported platforms and compilers is the
> following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we
> are working to add OS X 10.11 to CI and fully support it)
>
>
>
> The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older
> (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent
> versions. Those who have such older platforms to support, are recommended
> to stay with the LTS version for a while. This approach allows us to move
> faster for new features planned for future Qt releases.
>
>
>
> For application developers the documentation is often the best source to
> find the list of supported platforms:
> http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been
> updated to 5.6, but will be before the final release.
>

Thanks Tuukka, but that's all a bit messy and hard to work out (not to
mention the LTS email threads here which are impossible to follow). It
makes my point really that there's no one canonical source telling us Qt
contributors what platforms we need to design or code features for in the
next Qt release, or for fixes in the last bug release. I need to know what
versions of the platform API's I can use, not what's Official, Reference,
CI, or Community supported.

I've taken the liberty of starting a wiki page to try summarise things the
way I'd like to see them laid out:

https://wiki.qt.io/PlatformSupport

Feel free to edit or fix or move to a more appropriate place.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Minimum Deployment Platforms for 5.7 onwards?

[John Layt]

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 6.6
Ubuntu 11.10?

There really should be a wiki page for this...

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[John Layt]

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 other end there's
> a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
> Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
> out what behaviour *we* want to give, implementing it is going to depend
> on knowing what the platform mktime gives us to work with.
>
> I know glibc's behaviour (2.19-22), although confirmation of it from
> elsewhere and version variation may be worth knowing.  We have a kludge
> for MS-Win that suggests what it does (actually quite sensible, though
> different to GNU), but I'd be glad of confirmation.  The 'net suggests
> FreeBSD may even treat some of it as errors; I may need to follow up on
> that, and on Mac.  So I wrote a simple test program.
>
> If you're willing to compile and run the attached simple C program,
> please let me know its output and your platform's details - ideally
> off-list - I'll give a summary in a few days' time.  Those not in Europe
> shall need to amend the data in two statics at the top of the file
> (there are comments to guide you) to hit when your DST transitions are.
> (I'd also be glad to know what those are, if you include a diff.)
>
> Eddy.
>

Hi Eddy,

I'm the original author of a lot of the current QDateTime/QTimeZone code,
thanks for looking into this, I'm sadly not in a position these days to
give much time to Qt.

There's a serious problem with mktime() and ambiguous hours, i.e. the hour
that gets repeated at daylight savings changeover. The root of the problem
is that the C/POSIX spec doesn't define the correct behaviour, so every
implementation decides what to do. I've previously documented the exact
details in a previous email to the list a few years back which I can dig up
if needed, but here's what I recall. On Windows they default to the second
occurrence of the time. On Mac/BSD they default to the first occurrence,
except on some versions where the first 43 or so minutes are the first
occurrence and the rest are second occurrence! On GNU it just uses whatever
the last time calculation had cached as the occurrence, or the first
occurrence if nothing is cached, so is completely unreliable! On Windows
mktime() in general use can also return different results than the higher
level Win32 api.  I concluded that we cannot reliably use mktime() for the
ambiguous time conversions, or even in general cross-platform use. My
conclusion was we needed to improve QTimeZone to be fast enough to replace
mktime() if we wanted 100% reliable and compatible behaviour across all
platforms. That may all have changed now we have more recent minimum
versions of each OS. As a rule, I favour going with a default of assuming
first occurrence, I think I found it easier to calculate from the tz
database rules and slightly more logical.  I've even got patches floating
around trying different ways of implementing a clean API to control this
based on the KDE api.

I'll try have a look at the bug on the weekend, but I can't promise
anything.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QDateTime is missing shared null optimization

[John Layt]

[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
using Qt::TimeZone? Otherwise there would be issues with date input
fields that expect years up to  to be valid. I'm also not sure if
you've taken the internal StatusFlag field into account as well as the
TimeSpec field, I'm not sure all that would fit properly into 64 bits.
Also OffsetFromUTC supports weird offsets that are not 15 minute
intervals.

It would require a lot of shuffling code around, as a lot of code is
in the d_ptr, it would horribly complicate things and there's the
potential for interesting corner cases, like say adding enough years
to a date to push it from one implementation to another... Is the
complexity worth it?

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Location and Geoclue 2

[John Layt]

On 9 June 2015 at 06:22, Aaron McCarthy mccarthy.aa...@gmail.com wrote:

 Hi,

 On Mon, 8 Jun 2015 22:25:12 Lisandro Damián Nicanor Pérez Meyer wrote:
  Hi! I have just received a bug [debbug] in which geoclue maintainrs
 states
  that he wants to get geoclue removed in favor of geoclue2. 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/bugreport.cgi?bug=788108
  [fedbug]

 John Layt started working on a Geoclue 2 plugin some time ago[1]. I'm not
 sure
 how much progress was made.

 [1] https://codereview.qt-project.org/88630


 Hi,

I was halfway through migrating it to using the Qt DBus compiler which is
the state shown in that code review. That's about as far as I got before I
burnt out last year, but I'm just starting to get back into Qt work again
so I may be able to progress it soon, unless someone else wishes to pick it
up. I know the Geoclue maintainer is organising another Geoclue hack
weekend in London soon, so maybe I can finish it off then.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS2014 - Expiring bug reports

[John Layt]

On 18 June 2014 07:15, Knoll Lars lars.kn...@digia.com wrote:
 On 17/06/14 18:31, Robert Löhning robert.loehn...@digia.com 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. If nobody feels inclined to do anything, the bug will eventually
 get closed.

Even simpler, when changing the status to Need more Info if the
reporter account is marked as Inactive/Closed, then note that fact in
the message and tell the watchers they they need to take action.

In fact, when writing the Needs Info message on any bug the request
should be addressed to all the watchers rather than just the reporter,
seeing as very old bugs are likely to have bouncing reporter email
accounts.

And +1 to transferring to new accounts where they exist.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS2014 - QtPrintSupport Session

[John Layt]

On 17 June 2014 03:29, Christian Gagneraud chg...@gna.org 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
 support for Windows.

 Link support would be very nice to have, not sure if it's on the
 priority list or not, but I'm sure lot of people would like to have
 support for this.

Yes, it is an existing feature request (see QTBUG-25379 for a list of
all the PDF bugs and feature requests), and by strange coincidence I
had an email from someone just yesterday about implementing it.  I'll
be posting an email to the list discussing it soon-ish.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Disable printing support

[John Layt]

 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 cause the print library is still there) but that's a start.

I do try keep QT_NO_PRINTER working, glad to know it works for you.
You probably shouldn't need QT_NO_PRINTDIALOG as it is implied by
QT_NO_PRINTER, it's really there to allow people to disable the
dialogs but still keep printing available for non-gui apps.

As for the library still being there, yes it only ifdefs out the code
and not the actual library creation, which would be far better.  I've
added it to my TODO list, see QTBUG-39634 :-) Anyone have comments on
just keeping the -D QT_NO_PRINTER for this, or should we add a
configure option for -printsupport / -no-printsupport like we have for
gui and widgets?  We can probably remove the -cups / -no-cups /
QT_NO_CUPS options now too, there is no other printing option on Linux
(QTBUG-39636).

On 13 June 2014 16:29, Thiago Macieira thiago.macie...@intel.com wrote:
 Note that print support also includes PDF generation. Your device might
 still want to do that.

Actually no it doesn't, not since the GUI/PrintSupport split, but we
do have QT_NO_PDF that does that, and by implication disables printing
too on all platforms as they all need PdfFormat.  What QT_NO_PRINTER
does do though is remove the print() method from QTextDocument when it
shouldn't, as that now takes a QPagedPaintDevice rather than a
QPrinter (QTBUG-39635).

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtCS2014 - QtPrintSupport Session

[John Layt]

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 tasks other people could take on, primarily greatly
improving our PDF writer support and adding equivalent XPS file format
support for Windows.

For those in attendance, I've done a little more work on Windows XPS
format support, basically despite what MSDN says full XPS based print
workflow is available from Vista SP2 onwards, so that's likely to be
the minimum support level for the new library.  Details at
http://qt-project.org/wiki/Qt-5-QtPrint#5a06d2a1c54c0764bb13f0440156e4c7.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 header diff

[John Layt]

On 30 April 2014 16:28, Andrey Ponomarenko aponomare...@rosalab.ru 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
Value of member NPageSize has been changed from 30 to 118.

But only reports a Low severity problem for:

qlocale.h
enum QLocale::Language
Value of member LastLanguage has been changed from 311 to 314.

This is a common pattern in Qt to indicate the last valid value, so is
OK afaik, it's just weird the same issue reports with different
severity.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: Proposal: Location hackfest

[John Layt]

Hi,

Please see the below email from Zeeshan Ali of Gnome and GeoClue who is
organising a Location hackfest in London in May/June time-frame to get
Gnome, KDE, Qt, Mozilla, Jolla and others working together on improving
location services on the Linux desktop.  If anyone is interested in
attending, in particular to work on porting Qt from GeoClue1 to GeoClue2,
addressing any missing features in GeoClue2, or to work on cool new desktop
features using location, then please contact him directly or add your
details to the wiki.

Cheers!

John.

-- Forwarded message --
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
Date: 2 April 2014 17:00
Subject: Proposal: Location hackfest
To: John Layt jl...@kde.org, Aaron McCarthy 
aaron.mccar...@jollamobile.com, Hanno Schlichting hschlicht...@mozilla.com

Cc: Bastien Nocera had...@hadess.net, Ekaterina Gerasimova 
kittykat3...@gmail.com


Hi everyone,

I'm planning a combined hackfest in the spirit of cooperation between
our projects to ensure we all have a stable, well-documented and free
location infrastructure for both desktops and mobile devices:

https://wiki.gnome.org/Hackfests/Location2014

If you folks (or others from your projects) can participate, please
add your names on the list and propose date and duration for the
event. I'm hoping to organise it mid/late May or sometime in June.

Once I know who can join, I can contact our board for making it
official and organising the event.

Aaaron, From the changelog on geoclue rpm on my Jolla phone, I
gathered you are the person to contact about this in your company but
if that is not the case, kindly forward this mail to the right person.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Release blocker: printing on OSX 10.9

[John Layt]

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 at all on 10.8 or 10.7.  Any help from Mac experts in debugging
this would be appreciated as I have no clue as to the cause or how to
practically debug it.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Printing Bug Triage

[John Layt]

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   QtPrintSupport - Mac Issues
QTBUG-25384   QtPrintSupport - Windows issues
QTBUG-25380   QtPrintSupport - Page Layout Issues
QTBUG-37693   QtPrintSupport - Painting Issues
QTBUG-25378   QtPrintSupport - Font Issues
QTBUG-25379   QtPrintSupport - PDF Issues
QTBUG-37701   QtPrintSupport - Color Issues
QTBUG-25377   QtPrintSupport - Remote Printer Issues
QTBUG-37698   QtPrintSupport - Dialog Issues
QTBUG-25385   QtPrintSupport - New Feature Requests

Most of 29 issues issues under Page Layout Issues should be resolved
by the new code in 5.3, but I'm then faced with deciding which of them
also need fixing in 4.8 before I can close any.

For the other bugs, there are a few areas I'm a bit concerned about.
In particular my strength lies in the print work-flow management and
not the painting code itself where I'd appreciate any help in
evaluating and fixing the reported issues.

From the 38 painting issues and 42 PDF issues I've identified 26
issues I'd like to be assesed with regards to 5.3 and grouped them
under Task QTBUG-37713.  Many of these seem at least partly related.
If anyone has some time spare I'd appreciate if they can have a look,
confirm if they still apply to 5.3 Beta 1 or only to 4.8, if they're
small enough to resolve for 5.3, and if possible fix them.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Current problems in CI

[John Layt]

On 13 March 2014 10:06, Sarajärvi Tony tony.saraja...@digia.com 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 changes won't make the beta
after all...

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Current problems in CI

[John Layt]

On 13 March 2014 18:08, Frederik Gladhorn frederik.gladh...@digia.com wrote:
 Torsdag 13. mars 2014 16.32.22 skrev John Layt:
 On 13 March 2014 10:06, Sarajärvi Tony tony.saraja...@digia.com 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 changes won't make the beta
 after all...

 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 were quite a few things comming together making it hard to fix.

 The printing patches are going to be staged as one of the first things, as
 agreed.

That's good news.  Thanks to the team for all the hard work getting it
sorted out, I know it can't be easy keeping it running with us devs
constantly changing things :-)

I'll be here all night if anything goes astray with my changes...

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Current problems in CI

[John Layt]

On 13 March 2014 18:21, John Layt jl...@kde.org wrote:
 On 13 March 2014 18:08, Frederik Gladhorn frederik.gladh...@digia.com 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 were quite a few things comming together making it hard to fix.

 The printing patches are going to be staged as one of the first things, as
 agreed.

 That's good news.  Thanks to the team for all the hard work getting it
 sorted out, I know it can't be easy keeping it running with us devs
 constantly changing things :-)

 I'll be here all night if anything goes astray with my changes...

And inevitably the iOS build went astray...  I now have a patch to fix
the QT_NO_PRINTER build for this set of changes and other breakages
from earlier code.  I've done it as an extra change at
https://codereview.qt-project.org/#change,80901 to save having to
reset the approval status of all the other changes so anyone can
approve just this small change and we can push the whole lot again.
If someone can approve I'd be grateful, otherwise I can abuse my
maintainer privilege later to push it through overnight.

Remind me later to find out why  we even bother trying to build the
module and plugins if QT_NO_PRINTER is set, it has to be smarter than
having every file wrapped in ifdefs.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Current problems in CI

[John Layt]

On 12 March 2014 11:08, Sarajärvi Tony tony.saraja...@digia.com 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 crashed and lost track of qtbase_dev and crashed a few other builds.
 In the aftermath one of the build nodes ended up not being able to clean the
 work areas. Had to go in and do that manually.

 Services have now been reset, and we're trying to build the autotest fixes
 currently. After that we'll open the gates again.

Hi Tony,

Thanks for your work on this, and sorry to nag, but do we have an ETA for this?

Thanks!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Use of resolution in QtPrintSupport.

[John Layt]

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 device resolution.

QtGui / QPaintDevice
 - No resolution
 - PdmDpiX / PdmDpiY default to 72

QtGui / QPdfEngine
 - Can set resolution to any value
 - Used for PdmDpiX / PdmDpiY
 - Used to calculate PdmWidth / PdmHeight in Device Pixels
 - PdmPhysicalDpiX / PdmPhysicalDpiX fixed at 1200
 - Scale factor in pageMatrix() calculations = (72.0 / resolution)

QtGui / QPdfWriter
 - In 5.3 have added api to set/get resolution which is passed to QPdfEngine

QtPrintSupport / QPrinter
 - Constructor takes PrinterMode of ScreenResolution / PrinterResolution / 
HighResolution to set initial resolution, defaults to ScreenResolution
 - No way to set/get PrinterMode afterwards, but can set/get resolution value
 - ScreenResolution is documented as using screen resolution
 - HighResolution is documented as using printer resolution, or 1200 on PDF
 - PrinterResolution is deprecated, documented as ScreenResolution on X11 and 
HighResolution on Mac/Win
 - Can set/get resolution, passes request to QPrintEngine, documented as 
Requests that the printer prints at dpi or as near to dpi as possible.
 - Can get QList of supportedResolutions(), passes request to QPrintEngine, 
documented as printer resolutions, except on X11 where is always 72
 - Used in pageRect / paperRect calculations

QtPrintSupport / QPdfPrintEngine
 - If ScreenResolution then qt_defaultDpi()
 - If HighResolution then 1200
 - If PrinterResolution then 72
 - Can set resolution to any value
 - PPK_SupportedResolutions only ever returns 72
 - Used in pageRect / paperRect calculations
 - Uses QPdfEngine::metric()

QtPrintSupport / QCupsPrintEngine
 - Derived from QPdfPrintEngine
 - No code for printer physical resolution, uses PDF's 1200
 - Assume relies on CUPS to do any scaling to real physical

QtPrintSupport / QWinPrintEngine
 - If ScreenResolution then screen LOGPIXELSY (or 96 if error)
 - If HighResolution or PrinterResolution then printer LOGPIXELSY
 - Can set resolution to any value
 - PPK_SupportedResolutions returns printer resolutions
 - Used in pageRect / paperRect calculations
 - Used for PdmDpiX / PdmDpiY
 - Used to calculate PdmWidth / PdmHeight in Device Pixels
 - PdmPhysicalDpiX / PdmPhysicalDpiX returns printer LOGPIXELSX and LOGPIXELSY
 - Scale factor in pageMatrix() calculations = (physical dpi / screen dpi)

QtPrintSupport / QCocoaPrintEngine
 - If ScreenResolution then qt_defaultDpi()
 - If HighResolution uses highest physical resolution, or 600 if error
 - If PrinterResolution uses lowest physical resolution, or 600 if error
 - set resolution coded to find nearest supported physical resolution, but 
doesn't actually set the value
 - PPK_SupportedResolutions returns printer resolutions
 - Used in pageRect / paperRect calculations
 - Used for PdmDpiX / PdmDpiY
 - Used to calculate PdmWidth / PdmHeight in Device Pixels
 - PdmPhysicalDpiX / PdmPhysicalDpiX returns printer physical resolution
 - Scale factor in calculations = (72 / resolution)

The good news is none of the platforms actually change the physical 
resolution, they all use the paint resolution and scale to fit the physical 
resolution.  The bad news is this is not what the docs say happens, and Mac in 
particular doesn't behave correctly or consistently with the others.

What I want to change now:
 - All docs to say we don't change physical resolution, but scale instead
 - All platforms to prevent setting resolution = 0
 - PDF PrinterResolution to set ScreenResolution, not 72
 - Cups supportedResolutions() to return printer resolutions, not just 72
 - Mac to default to current physical resolution for HighResolution
 - Mac setResolution() to allow setting to any resolution
 - Some default values may need synchronising

I still need to check that when the user changes the physical resolution in 
the print dialog, usually by changing the Print Quality option, that 
everything gets updated correctly.  I also need to look more into why PDF and 
Mac scaling uses (72 / resolution) but Windows uses (physical resolution / 
resolution).

Longer term, we'll probably need to implement the Print Quality api to support 
changing the physical resolution, but that's a later release.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plans for printing in 5.3 onwards

[John Layt]

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 we'll get it done in time, but it's worth a crack, otherwise
  I'll have to slog through the old code again fixing all the bugs I found
  for 5.3, only to replace the code again in 5.4.
 
 If people don't quite feel confident taking all the changes at once, one
 option is to take up Morten's earlier suggestion of not using the new
 platform plugin code just yet, i.e.
 * Merge the QPageLayout and QPageSize code and its use in QPrinter and
 QPrintEngine, as this is the code that fixes many bugs and removes the
 duplicated inconsistent code that is at the root of many issues.
 * Change the existing platform code to use QPageSize and QPageLayout
 internally
 * Merge the new QPA code, but don't use it as yet,and  have the auto tests
 and manual tests available for people to test it more thoroughly.
 * Keep the patches switching to the new platform plugin code in reserve to
 either switch for 5.3 if testing proves the plugin is stable enough, or more
 likely to use in 5.4 if not.

Hi,

As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug fixed in 
time, and using just the layout code without the plugin proved too much work 
to be stable in time, so *none* of this change set has made it for 5.3.   
Apologies and thanks to everyone who put so much effort into testing and 
reviewing the changes.

The question is what to do now.  I could look at porting some of the layout 
fixes to the old code as bug fixes for 5.3, but I'm not sure that's the best 
use of my time, plus most of the fixes are heavily dependent on the new 
QPageSize class to manage things without writing the same page size conversion 
code over again in 8 different classes.

One option is to make the QPageSize and maybe QPageLayout classes private for 
5.3 to allow them to be used in bug fixes, which could also allow the new QPA 
class in be included for wider testing via tests/manual/qprintdevice_dump 
before being used in 5.4, but that feels like cheating the freeze.

Thoughts?

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plans for printing in 5.3 onwards

[John Layt]

On 17 February 2014 14:04, Knoll Lars lars.kn...@digia.com 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 the patch set is almost there.

 The API is pretty much ok now, so there won¹t be a lot more changes coming
 anymore. The main thing that¹s missing is bug fixing certain areas, and
 that¹s what the stabilisation period is there for.

 So please go ahead with your changes so that we can get them in within the
 next few days.

OK, thanks Lars :-)  I now have a version of the Mac code that runs
and passes repeated tests on 10.7 so I'll post that up tonight for
testing, so hopefully we can rebase to stable and merge once the the
repos reopen.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plans for printing in 5.3 onwards

[John Layt]

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 people use the printing and we need to try and get these
 changes tested and fixed where necessary in good time for the final so the
 transition is not really noticed by the users. So is there any update on
 these patches or should we consider waiting until Qt 5.4 to ensure they are
 all ready correctly?

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 
we'll get it done in time, but it's worth a crack, otherwise I'll have to slog 
through the old code again fixing all the bugs I found for 5.3, only to 
replace the code again in 5.4.

Apologies for the rebase, but it was needed.

Main changes are:
* Removed QPageMargins and added QMarginsF instead
* QPageLayout uses QMarginsF and now has an enum and attribute for 
QPageLayout::Units to track what units are used for all the margins.  Turns 
out while this complicates some public api, it also simplifies the way the 
class is used in real code.
* QPageSize also has a QPageSize::Unit, that duplicates QPageLayout::Unit but 
I couldn't find a nice place to put a common enum.
* Both QPageLayout::Unit and QPageSize::Unit don't have a value for 
DevicePixels anymore as it doesn't make sense.  That simplifies api in a 
number of places by removing the resolution parm.

The main issues outstanding I see:
* Mac issue with PMPaper: in my testing I need the extra PMRetain to prevent a 
crash, but Morten gets a memory leak with it, and Andy reports it crashes for 
him anyway.  Try the latest code, if the issue still persists I'll look for an 
alternative way of doing things.
* Win is reported as being slow, that's an issue with the old code too, but 
the new code may make it slightly slower.  It's due to the DC being refreshed 
every time a setting is changed, which is plain slow.  Once the new code is in 
and handling the layout calculations, I think it's possible to remove the DC 
refresh at every step and just init the DC when start() is called.

If anyone else wants to test this, there's a few things you can run besides 
the auto tests:

examples/widgets/richtex/textedit
tests/manual/dialogs 
tests/manual/qprintdevice_dump

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plans for printing in 5.3 onwards

[John Layt]

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 missed some updates or something? I am concerned because I
  know how many people use the printing and we need to try and get these
  changes tested and fixed where necessary in good time for the final so the
  transition is not really noticed by the users. So is there any update on
  these patches or should we consider waiting until Qt 5.4 to ensure they
  are
  all ready correctly?
 
 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 we'll get it done in time, but it's worth a crack, otherwise I'll have
 to slog through the old code again fixing all the bugs I found for 5.3,
 only to replace the code again in 5.4.

If people don't quite feel confident taking all the changes at once, one 
option is to take up Morten's earlier suggestion of not using the new platform 
plugin code just yet, i.e.
* Merge the QPageLayout and QPageSize code and its use in QPrinter and 
QPrintEngine, as this is the code that fixes many bugs and removes the 
duplicated inconsistent code that is at the root of many issues.
* Change the existing platform code to use QPageSize and QPageLayout 
internally
* Merge the new QPA code, but don't use it as yet,and  have the auto tests and 
manual tests available for people to test it more thoroughly.
* Keep the patches switching to the new platform plugin code in reserve to 
either switch for 5.3 if testing proves the plugin is stable enough, or more 
likely to use in 5.4 if not.

 The main issues outstanding I see:

I missed the issue around the QPageLayout flag setters/getters which needs 
clarification.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Bug fixes to Stable or Dev branch?

[John Layt]

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 communicate them 
to this list, not everyone is in the office or on IRC.

Thanks!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Plans for printing in 5.3 onwards

[John Layt]

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 consistent across
 platforms
 * Remove all the ifdef'd api and platform-specific code from QPrinter,
 ensuring api and behaviour is consistent across platforms
 * Remove all platform-specific code from the widgets and dialogs
 * Improve the auto test framework

Hi,

I've just pushed a 33 commit change set for this to Gerrit, my apologies to 
the people I've tagged as reviewers :-)  Any one else interested, feel free to 
jump in and help.

There's 4 main new classes:
* QPageSize
* QPageMargins
* QPageLayout 
* QPlatformPrintDevice, with backends for Windows, Mac and Cups

These are then used in a fairly major rewrite of the platform and PDF print 
engines and QPrinter itself.  I've tested these changes using my limited set 
of printers and some test painting code, but obviously I can't test for 
everything, especially the wide variety of drivers and the dodgy data they may 
return.  I'd appreciate if people could check out the last commit in the chain 
[1] and see if it works OK with your printers and apps and report any problems 
back here.

Cheers!

John.

[1] https://codereview.qt-project.org/#change,76918

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Plans for printing in 5.3 onwards

[John Layt]

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 workflow including cloud printing.  However it's
been hard to get started as it's an all-or-nothing approach, and we
still need to maintian the old code in parallel.  The existing code
itself is in a strange state and needing quite some clean-ups still,
with a QPA plugin that has been only partially implemented, a lot of
code still in the main module behind platform ifdef's rather than in
the plugins, major inconsistencies between the behaviour of the
platform implementations and even ifdef'd public api.

Given my limited time, I've decided to take a different approach to
try build the new code over the next few releases as a new set of QPA
classes that are then used by the current public api in place of the
old plugin code, before later being used for the new public api.  This
would allow the new code to be throurghly tested with a working
front-end in progressive steps, give us a single platform plugin
code-base for both apis to be maintained throughout the Qt5 life-span,
improve the quality and consistency of the existing print support, and
allow new cloud-print plugins to be worked on in the interim so we
better understand their requirements.  Working on this as a qpa also
allows the api to develop organically over the next few releases
without having to worry about compatability issues.  Once the new qpa
classes are completed, then the new public api can be developed to
expose all the new features.

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 consistent across
platforms
* Remove all the ifdef'd api and platform-specific code from QPrinter,
ensuring api and behaviour is consistent across platforms
* Remove all platform-specific code from the widgets and dialogs
* Improve the auto test framework

Longer term, 5.4 could see the addition of the new qpa job ticket and
print settings api and their integration into the engines and dialogs,
and 5.5 could see the new public api.  One major sub-task in there
will be to try upgrade our PDF support to full PDF/A standard which
may affect the timing.

I have a work branch at [1] which implements the new
QPlatformPrintDevice api for the 3 platforms and integrates it so far
into QPrinterInfo and the Linux QPrintEngine.  It also has some new
classes QPageSize, QPageMargin and QPageLayout to remove lots of
duplicated and error-prone page and margin handling code.  Once the
Windows and Mac print engine integration is completed I'll start
pushing these for review.

Cheers!

John.

P.S. If anyone wants this completed sooner, I'd be happy to discuss
sponsorship to allow me to work on it full-time for the next 6 months
:-)

[1] 
https://qt.gitorious.org/qt/odysseus-qtbase/commits/a19d77f78f071c207fc07e6c5f003f789d0daa3c
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping XP?

[John Layt]

On 10 December 2013 16:29, Thiago Macieira thiago.macie...@intel.com 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Minimum CUPS version vs RHEL 5 support

[John Layt]

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.3 I want to set a minimum version of 1.4, which was
released in 2008 and adopted by most Linux distros in 2009/2010.

The problem comes with RHEL.  RHEL 6 has CUPS 1.4, but RHEL 5 only has
1.3.  I note on http://qt.digia.com/Product/Supported-Platforms/ that
RHEL 5 is shown as a secondary supported platform in 5.1, albeit using
a number of self-built unsupported packages.  Any change to require
CUPS 1.4 would effectively render RHEL 5 unsupported, or at least
without the option of printing support.

Would this be acceptable, or should I only set the minimum at 1.3?

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping XP?

[John Layt]

On 9 December 2013 23:23, Thiago Macieira thiago.macie...@intel.com 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?

I would like to, but I'm not sure we can quite yet given how
widespread its use still is.  OTOH people won't move unless the
industry gives them reason to do so by dropping support :-)

Localization would benefit, or at least would be cleaner.  Vista added
a lot of new APIs and features I'd like to use without having to fudge
things on XP, like we do in QCollator.  It would also mean the WinRT
port wouldn't need to ifdef everywhere to replace LCIDs with locale
names and the potential for behaviour differences that brings.

Printing I haven't noticed any new API at all.

If 5.3 is a stabilization release and on a shorter release cycle, and
comes out about the XP EoL date, then perhaps it would be a good final
release to offer XP users, with 5.4 giving us more time to replace XP
code and make sure there's no regressions?  Or would the WinRT port
benefit from us doing it sooner?

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QTimeZone fixes pushed to Release branch

[John Layt]

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 fix 
the private code to keep the patch against release as small as possible.

2) https://codereview.qt-project.org/#change,70985

This fixes a very inefficient loop under Windows that is needed for 3) and 4) 
below to pass CI tests without timing out.

3) https://codereview.qt-project.org/#change,70986

This fixes a crash on Linux for abbreviations in some time zones, and thus in 
QDateTime::toString().  It also adds a stress test that validates all 
available time zones.  This was previously approved against stable but not 
merged due to 2) causing CI failure.

4) https://codereview.qt-project.org/#change,70987

This fixes an infinite loop in converting to/from UTC for some time zones when 
used in QDateTime.  This was previously reviewed for stable but not merged due 
to 2).

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[John Layt]

On 9 November 2013 12:50, Olivier Goffart oliv...@woboq.com 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. giving
 access to the information that an application needs to perform color
 management tasks itself. In a much later iteration Qt could perhaps
 perform color management operations. Qt should IMHO avoid automatic
 color management under the hood, especially without providing API to
 control it.

 Milestones could be:
 1) QImage[Reader] gives access to image color profile. Either whole
 profile or just an identifier in case of standard spaces such as sRgb.
 2) QScreen gives access to the current display color profile for that
 specific screen.
 3) There are notifications (signals?) when the a window changes to
 another screen, or when a screen profile is changed in the system.
 4) Same as 2 but for installed Printers on the system.
 ...
 99) QColorEngine can do color conversions using an input profile, a
 source Image an output profile plus different parameters.

 Ideas? Kai-Uwe, what color management feature (or enabler) are you
 missing most in Qt?

 Allow me to disagree :-)
 How usefull are 1-4 without 99?  What exactly can you do with that
 information.

Well, I'm no expert at the graphics side of things, but I think before
you can start applying a color profile you need to know what color
profile to apply :-)  If we at least expose that config for apps to
use then they only need to apply the transforms themselves, rather
than also having to abstract the system config.  Then afterwards we
can start using the config ourselves in our own code.  OTOH we don't
want to ship api that we may have to change later when we start using
it ourselves in anger.

I think step 1 is very definitely a cross-platform api to access the
host system config and profiles, regardless of whether we make it
public or not.  That's easy enough for Windows and Mac where each has
a single color management framework built-in, but on Linux we still
have two competing systems (perhaps Kai-Uwe can update us on that
situation, is there a single combined config yet?).

Now, to really expose my lack of knowledge, AFAIK Mac especially and
Windows graphics contexts can apply the required transforms themselves
internally, so wherever we use the native context it's surely just a
case of configuring them to do the work for us?  It's really only on
Linux or XP that we would have to have code for doing the transforms
ourselves using LCMS?  But like I said, I know nothing of our graphics
internals :-)

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Is possible to remove ICU dependency for Qt5Webkit?

[John Layt]

On 5 November 2013 05:09, Yuchen Deng loa...@gmail.com 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 use.  This
can reduce the size of ICU by about a half.

Which reminds me, I was going to write a build script to automate that
for people...

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTimeZone (was: Re: Qt 5.2 header diff: QtCore)

[John Layt]

On 5 November 2013 12:03, Marc Mutz marc.m...@kdab.com 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_BOOTSTRAPPED
 +QDateTime(const QDate date, const QTime time, const QTimeZone
 timeZone);
 +#endif // QT_BOOTSTRAPPED

 IMO, it would be more readable to use QT_NO_TIMEZONE, which is then set by
 QT_BOOTSTRAPPED.

Yes, making time zones optional was something I was going to look at
for 5.3 along with configure flags to choose native or TZ/ICU time
zones.  However I could probably change just this if people want.
Someone would just need to point me to where/how to do the configure
magic :-)

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Solaris support in Qt 5?

[John Layt]

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 on Solaris then I won't worry, but if anyone is
working on support then I'd like to work with them to add tz support
as I have no intention of setting up a Solaris build system for
myself.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Solaris support in Qt 5?

[John Layt]

On 2 November 2013 16:52, Thiago Macieira thiago.macie...@intel.com 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
 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 on Solaris then I won't worry, but if anyone is
 working on support then I'd like to work with them to add tz support
 as I have no intention of setting up a Solaris build system for
 myself.

 It builds. I've seen Sergio do some Solaris fixes a couple of months ago.

 But it's not something you have to worry about, John, unless you want to. More
 importantly, without a Solaris machine to test with, you really can't be
 expected to work on anything.

 The most we can ask of you is some assistance if someone wants to add Solaris-
 specific QTimeZone support.

OK, it's just David Faure wasn't keen on ripping the working Solaris
code out of ktimezoned unless Qt had replacement code.  Now we know
that Qt 5 at least builds we'll try leave the old code in KDE for now.
 I think it's mostly just different paths to the TZ files, but the
zonetab file format may be a little different too, so I don't want to
do it blind.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtLocation offline Navigation support

[John Layt]

On 25 October 2013 15:55, Ramakanthreddy Kesireddy
ramakanthreddy.kesire...@techmahindra.com 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 consider Marble (http://marble.kde.org) which besides being a cool
mapping app also provides a pure-Qt library for online and offline
mapping and navigation.  It's currently only available for Qt4, but
patches for Qt5 support are currently under review so should be
available soon.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Where and how does Qt define which platforms are supported?

[John Layt]

On 22 October 2013 15:33, Vladimir Minenko vmine...@blackberry.com 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 are classified.

I think there was work done at QtCS to define these, see
http://qt-project.org/groups/qt-contributors-summit-2011/wiki/Qt5ProductDefinition#4582cf86974b397c8f3a2ed2fd502f8c
.  There was also the list of platforms in 5.0 at
http://qt-project.org/wiki/Qt_5.0

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Types

[John Layt]

On 17 October 2013 19:30,  qt...@madagon.com 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 like to specially hear from you.

Hi,

QCalendarSystem is on my TODO list for Qt5.3, but there's a series of
steps we need to complete first to get there.

I do have working code for most of the calendar systems at [1], but
while the API is close to what we will use, the formulas are unlikely
to get used now.  This is because the data required for the names
would add 3-5 MB to the QtCore library size which was deemed too much.

We instead decided to use ICU for all our localization, but that ran
into other problems and so that was shelved too.  There's an outline
of the ICU-based api design at [2], but obviously that now needs to be
reviewed.

The design we will now use is for QCalendarSystem (and other locale
code) to be a thin wrapper around each platforms native support, just
like I did for QTimeZone.  I'll be starting on updating the design
next week.

The problem is that before starting on QCalendarSystem we need to
change QLocale to only use the native platform locale code and
database instead of Qt's own.  The biggest part of that is changing
Linux to always use ICU instead.  I have most of the code for that but
it needs more work.

So, once all that is done we can then add QCalendarSystem, after which
we will need to integrate it into QLocale and QDateTime and the
datetime widgets, so a lot of work to do.

The one thing that won't happen is that QDate will start returning
local calendar values, it will only ever return Gregorian dates to
maintain backwards compatible behaviour.  To get local calendar values
you access the calendar via QLocale.

So, for now wait a little and I'll have an updated design ready in a
couple of weeks to be discussed on list before we get started.

Cheers!

John.

[1] 
https://qt.gitorious.org/qt/odysseus-qtbase/commit/9c1b7ec7772ba2ae1da904c4054bd9032836adff
[2] http://qt-project.org/wiki/Qt-5-ICU
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Contributors Day

[John Layt]

On 22 August 2013 21:24, John Layt jl...@kde.org 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 Monday October 7th.  We have been allocated a room
 for the day to hold formal sessions, informal discussions, code
 reviews, hack around, or just hang out.  A key topic again will be KDE
 continued contributions of features to Qt and KDE Frameworks 5
 development, but the floor will be open for any topic that affects Qt
 development, governance or community.  There's limited space in the
 room, so if you wish to attend then please register your interest and
 any discussions topics on the wiki page [1].

 See you at Dev Days!

 John.

 [1] http://qt-project.org/wiki/Qt-Contributors-Day-2013-Berlin

Hi,

Just a reminder if you're attending Qt Dev Days that tomorrow we have
the Qt Contributors Day from 10am onwards.  Feel free to drop in to
the room during the day to discuss any Qt development related topics,
or just to say hi :-)

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

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 improvements
 which will also improve things like daysTo(), but they will always be
 slower now.
 
 One other note, these are only after the msecs change, adding in the
 missing hour fix has a marginal effect except on toValid() which balloons
 out to 8.576 as it has to check the tz now.

OK, I've submitted some QDateTime speed-ups, and also the QTimeZone changes  
which are mostly unchanged since last time, just with a couple of 
optimisations and bug fixes.

In QDateTime we make good gains from msecs but then lose some of it to tz, but 
mostly it's still a net gain.  I still need to look at optimising isValid() 
and the date()/time() related code, but I doubt there's much to be gained 
there, we're simply doing more work.

Interestingly the QTimeZone performance figures are a 75% saving over using 
mktime, which gives hope for the plans in 5.3 of using a global QTimeZone 
instead.  The code is 100% slower than using localtime however, but I have 
done no real performance optimisations on the QTimeZone code yet.

Action  BaseMsecs   MissTZ   %
create():   0.299   0.405   0.494   0.601101
isValid():  0.087   0.150   5.642   5.844   6617
date() / time():0.060   0.288   0.306   0.306410
offsetFromUtc():6.929   5.001   5.621   5.689-18
toMSecsSinceEpoch():6.256   4.738   5.602   5.738 -8
toMSecsSinceEpoch1950():7.065   3.374   4.144   4.216-40
toMSecsSinceEpoch2050():8.143   6.559   7.615   7.673 -6
toMSecsSinceEpochTz():  0.143
toMSecsSinceEpoch1950Tz():  0.145
toMSecsSinceEpoch2050Tz():  0.298
setDate() / setTime():  0.449   0.817   0.866   0.911103
setTimeSpec():  0.386   0.406   0.591   0.728 89
setMSecsSinceEpoch():   6.512   3.942   4.161   4.434-32
setMSecsSinceEpochTz(): 8.666
addDays():  0.456   0.805   6.123   6.700   1369
addMSecs():12.600   6.416   7.498   8.314-34
addMSecsTz():   5.698
daysTo():   0.117   0.591   0.634   0.770558
currentDateTime():  1.110   0.315   0.358   0.430-61
fromMSecsSinceEpoch():  6.083   2.480   2.758   3.048-50
fromMSecsSinceEpochTz():8.680

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Mac build fails due to qlobal.h being modified?

[John Layt]

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 besides passing -no-pch?

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

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 creation in the timings, remove that and 
they're the same or faster.  Here's some revised numbers for just the 
functions themselves, as before 3650 different dates per iteration:

Action  BaseMsecs   %
create():   0.299   0.418   40
isNull():   0.082   0.103   26
isValid():  0.087   0.152   75
date(): 0.060   0.290  383
time(): 0.060   0.292  387
offsetFromUtc():6.929   8.242   19
toMSecsSinceEpoch():6.256   8.201   31
toMSecsSinceEpoch1950():7.065   3.262  -54
toMSecsSinceEpoch2050():8.143   9.983   23
setDate():  0.449   0.814   81
setTime():  0.428   0.812   90
setMSecsSinceEpoch():   6.512   3.971  -39
addDays():  0.456   0.828   82
addMonths():1.598   1.989   24
addYears(): 1.574   1.965   25
addMSecs():12.600   9.766  -22
toTimeSpec():   6.642   8.647   30
toOffsetFromUtc():  6.983   8.691   24
daysTo():   0.117   0.603  415
msecsTo(): 12.850  16.660   30
equivalentDiffSpec():   6.290   8.089   29
lessThanDiffSpec(): 6.288   8.054   28
currentDateTime():  1.110   0.315  -72
fromMSecsSinceEpoch():  6.083   2.462  -60

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 improvements which 
will also improve things like daysTo(), but they will always be slower now.

One other note, these are only after the msecs change, adding in the missing 
hour fix has a marginal effect except on toValid() which balloons out to 
8.576 as it has to check the tz now.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 19:24:15 Knoll Lars wrote:
 On 9/12/13 9:06 PM, John Layt jl...@kde.org 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 might be able to simply cache the time zone offset once and cache it.
 Then it should be at the same speed.

No, because we don't know the rules for when to apply Daylight Time, that's 
why we'd need to call mktime for every new datetime creation.  It can't be 
avoided.

Besides, we already have a spec that offers this style behaviour: OffsetFromUTC.

 The second is it means that the behaviour of the local
 date/time staying constant over time zone changes will no longer be true.
  It would be up to the app to realise a time zone change has happened and
 to know what to do with the datetimes as a result.
 
 Well, IMO that's in most cases what you'd want in any case. I can't see
 how a date time specifying 5pm for a meeting should stay at 5pm when I fly
 to finland...

You also don't say I want an appointment at 2pm UTC whatever that happens to 
be in local time, if you do and the daylight conversion rules change your 
local appointment time also ends up changing.  You instead say I want an 
appointment at 3pm local time *in Oslo*.  You only convert that to UTC if you 
need to see what that local time is in another tz.  QTimeZone will give us a 
proper way to do that.  You'd be crazy to currently be using LocalTime for 
such things, you'd use UTC or OffsetFromUTC or KDateTime instead.

Where the local date/time stays constant is what's normally known as Clock 
Time or Wall Time, i.e. I want to wake up at 7am no matter where in the world 
I am.  That's what LocalTime is closest to.  If we switched LocalTime then 
we'd need to add a new spec for ClockTime/WallTime/SystemTime to replicate 
that behaviour.

The problem with LocalTime is it's neither fish nor fowl, it's just This local 
time, if you want UTC just use whatever the system time zone currently is.  
We don't know what the most common use case is, but I suspect it's getting the 
current local time, and showing a local date as a string.  Most other use 
cases will revolve around whatever the current system tz is, or even not 
care at all.  It's the local time value they mostly want, not the UTC 
equivalent.

The biggest problem I see with switching the behaviour is to define how to 
update a datetime if needed after a time zone change.  If we cache whatever 
offset mktime returns at QDateTime creation, then when the tz changes any new 
dates will immediately be created with the new offset, but the old instances 
will still have the old offset, leaving things inconsistent and still not under 
the apps control.  You would also then need api for the app to tell the old 
instances to update to the new offset, which seems ugly and inefficient and 
prone 
to failure.  The alternative is to use a cached QTimeZone to look up the offset 
every time, that way the offset remains consistent until the app chooses to 
refresh the cached QTimeZone, but then you lose any efficiency gains and you 
might as well keep the old behaviour for now.

We also need to think about the serialization behaviour: do we still serialize 
as the local time as we currently do, or as the UTC time?  And how does that 
affect serializing a time expressed in a QTimeZone?  Is it a time in UTC to be 
interpreted into a given tz, or is it a given local time to be interpreted 
into UTC?  If I make an appointment for 3pm Oslo time then I want that to stay 
in Oslo time regardless if the rules for conversion to UTC change between 
serialize/deserialize, so that still needs to serialize as local.

We'd also need to think about de-serializing old formats and how to convert 
them correctly.

We may not need to implement all this in the first cut, but we at least need to 
think about how it will work, otherwise we could end up releasing something 
half-way there and then finding we can't actually make it work in teh full 
solution.

If we do make the change, I'd also rather do it in a different way.  Keep the 
LocalTime spec behaving as it does so legacy code can easily switch to using 
it, but create a new spec called something like SystemTime that behaves the 
way you want, then possibly change the default spec from LocalTime to 
SystemTime.

 Wouldn't the issues here be solved by storing all time values in UTC? In
 any case, I don't believe this is a showstopper for 5.2.

No, because you still need to make that initial conversion from local time to 
UTC using mktime, so you'll still get the same inconsistencies.  But yes, it's 
a problem for later.

 These are corner cases (as the OSes don't really solve them as well
 apparently). I'd not worry too much about this for 5.2. If we get this
 settled in 5.3 it's good enough.

Corner cases, yes, thankfully most people don't schedule appointments for 2am 
in the morning of daylight time conversion

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote:
 On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars lars.kn...@digia.com 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, making
 changes like b9ef4a9c3047228ec007ac81ff0a304f8cc274b7 in qtbase
 unnecessary. I'd like to see this for that reason :)

Well, that patch is taking advantage of the fact that creating a LocalTime is 
currently cheap, as is calling setTimeZone, neither of those steps currently 
require a conversion to UTC.  As explained in my reply to Lars with any change 
in storage you would always have to call mktime in the creation, so you 
immediately lose the speed-up from your patch.  There's probably a lot of 
places this will happen in Qt, not to mention other people's code.  There's no 
such thing as a free lunch :-)

The real problem is that the file code uses LocalTime internally when it should 
use UTC and only convert to LocalTime as the last step in the public api.  My 
understanding is Unix stores file times as time_t, and Windows as a FILETIME 
which is nsecs since 1601, both are UTC, so at the moment there is already a 
conversion from UTC to LocalTime required to create the LocalTime.  Creating 
and passing them around internally as UTC could be a big saving, however I 
suspect that would take a large change to achieve.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More on QDateTime / QTimeZone

[John Layt]

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 implement. We're running out of time, so I'd
 rather stick to the implementation you have and your best recommendation.

I've spent the evening writing and running some benchmark tests (amazingly we 
didn't have any before).  Each benchmark creates a date a day for 10 years and 
calls the tested method, so 3650 consecutive dates.  The numbers here are from 
1000 iterations on my i7.  As expected they're a mixed return with some things 
faster and some things slower (not all tests shown):

Action  BaseMsecs %
--  -   -  
create():   0.294   0.39233
isValid():  0.339   0.49245
date(): 0.313   0.632   102
time(): 0.311   0.639   105
timeSpec(): 0.311   0.40330
offsetFromUtc():7.466   9.00921
toMSecsSinceEpoch():6.690   8.83632
toMSecsSinceEpoch1950():7.522   3.642   -52
toMSecsSinceEpoch2050():8.618  10.79025
setDate():  0.418   0.83299
setTime():  0.385   0.820   113
setTimeSpec():  0.340   0.50849
setOffsetFromUtc(): 0.347   0.43826
setMSecsSinceEpoch():   6.020   2.564   -57
addDays():  0.701   1.12961
addMonths():1.836   2.27024
addYears(): 1.826   2.25523
addMSecs():12.820  10.370   -19
toTimeSpec():   6.900   9.24734
toOffsetFromUtc():  7.251   9.29228
daysTo():   0.365   0.953   161
msecsTo(): 13.510  17.78032
equivalent():   0.367   0.43920
equivalentUtc():6.730   9.01834
lessThan(): 0.355   0.44425
lessThanUtc():  6.714   8.90633
currentDateTime():  1.118   0.314   -72
fromMSecsSinceEpoch():  6.094   2.451   -60


* Things that start with an msecs value (i.e. use localtime) are 60-80% faster
* Things that start with a date and time (i.e. use mktime) are 30% slower.
* Focusing on optimising toMSecsSinceEpoch() will cause most other methods to 
speed up, if I remove a tzset call it runs faster than the baseline.
* The getting and setting of the date and time are obviously slower as they 
now involve conversions.
* 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.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] More on QDateTime / QTimeZone

[John Layt]

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 uses local msecs and not epoch msecs.  This allows 
the originally set date and time to always stay constant and be returned even 
if the time spec or system time zone changes during the life of the instance.  
This is a long standing and documented behviour of QDateTime.  Lars has 
suggested that we instead use epoch msecs, which has the advantage of 
simplifying a lot of code and solving a lot of corner-case bugs.  There are 
two disadvantages though.  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.  The second is it means that the behaviour of the local 
date/time staying constant over time zone changes will no longer be true.  It 
would be up to the app to realise a time zone change has happened and to know 
what to do with the datetimes as a result.  We would need to implement a 
QEvent for this.  We would also need to decide if this means the offset is set 
as at the time the QDateTime is created, or if the same offset is always used.  
There's good arguments to both sides, but the behaviour change is not 
something that has been fully thought out yet and so I don't think should be 
done for 5.2.

Ambiguous times at the Daylight to Standard transition: it is probably 
impossible to fix this bug using the standard C/Posix mktime call in an 
efficient 
way.  This is due to mktime having different behaviour and various bugs on all 
3 main platforms (one way to consistently deal with the differences would be to 
know the actual transition time, which is not provided).  The only way to fix 
this is to either write our own universal version of mktime using only calls 
to localtime(), which might be possible but would likely be very inefficient, 
or 
to use QTimeZone instead, which is probably not efficient enough yet and the 
change of system time zone problem still needs solving first.  None of this can 
be done for 5.2 either.

For those interested the problems with mktime are:
* Windows assumes an ambiguous time to be the second occurrence / standard 
time, but is at least consistent in doing so
* Mac assumes an ambiguous time to be the first occurrence / daylight time, 
except after about 46 minutes when it assumes the second occurrence
* Linux assumes whatever occurrence resulted from the previous call to mktime, 
i.e. effectively randomly

If we can settle these, I can get on with finishing this for 5.2:

* Choose either local msecs or epoch msecs, if epoch then that change can't be 
done for 5.2
* Accept second occurrence won't be solved for 5.2, document behaviour as 
undefined
* Integrate QTimeZone

Note that the QTimeZone code is unchanged since the last attempt for 5.1 so 
should be a quick review.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fwd: Change in qt/qtbase[dev]: Enable -Werror for all of qtbase

[John Layt]

-developer-buildOn 4 September 2013 15:21, Poenitz Andre
andre.poen...@digia.com 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: comparison between signed 
 and unsigned integer expressions [-Werror=sign-compare]
 cc1plus: all warnings being treated as errors

 Together with the recent insistence that it's fine to submit non-compilable
 chances I start wondering about the direction.

 Andre'

Apologies, that's a change I recently merged that has been on Gerrit
since before Thiago's change, so snuck past.  There's a patch for it
already at https://codereview.qt-project.org/#change,64642 .  I
suspect there will be a few pain points like that until the Gerrit
backlog drains.

The real problem is not Thiago's change per se, but instead CI
allowing changes with warnings like mine to be merged.  Perhaps we
need to revert until CI has the required -developer-build instances?

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Windows: Building QtCore without ICU while still using it for QtWebKit?

[John Layt]

On 20 August 2013 08:41, Koehne Kai kai.koe...@digia.com 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 
 QT_CONFIG+=icu ' only in qtwebkit.

 Haven't tried that, though :)

 Regards

 Kai

That should work, as far as I'm aware QtWebKit does not depend on any
ICU stuff in QtCore, it's only there for WebKit itself to use.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Status of QTimeZone

[John Layt]

On 27 March 2013 20:11, John Layt jl...@kde.org wrote:
 On 26 March 2013 18:15, Thiago Macieira thiago.macie...@intel.com 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 machines to
 CET is out of the question.  I'd say to run the tests with TZ set to
 the right region, but on Windows that fails as while the C library
 respects the setting the Win32 api doesn't so it just breaks the tests
 in other interesting ways.  So I guess we're left with modifying the
 tests to Finnish time, even though it just perpetuates the problem.

 All work up a patch once I've fixed the bug in Windows.

 John.

FYi, the bug is in the tests, or more exactly Microsoft's poor handing
of time zones.  CET in the Olsen database doesn't apply Daylight Time
before 1980, but Windows does.  Up to now all the dates auto-tested
before 1980 have purely by chance always fallen in Standard Time, but
the new min test for qint64 in 5.0 falls into Daylight time thus
exposing the difference.  I'll amend the tests to expect Daylight time
from Windows.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Status of QTimeZone

[John Layt]

On 26 March 2013 18:15, Thiago Macieira thiago.macie...@intel.com 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 machines to
CET is out of the question.  I'd say to run the tests with TZ set to
the right region, but on Windows that fails as while the C library
respects the setting the Win32 api doesn't so it just breaks the tests
in other interesting ways.  So I guess we're left with modifying the
tests to Finnish time, even though it just perpetuates the problem.

All work up a patch once I've fixed the bug in Windows.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Status of QTimeZone

[John Layt]

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 
certainly go in without QTimeZone as they address a number of open bugs and 
clean up code.

I have added in a couple more reviews to change the QDataStream version number 
(needed for QDateTime OffsetFromUTC), change the QDateTime debug stream 
format, and add a new TimeSpec of ClockTime.

There are a few outstanding issues left:

1) QTimeZone needs a move constructor and operator, but my compiler errors on 
my attempts apparently as it doesn't have the right level of C++11 support.  
Is there an existing Qt class with it done the right way for lesser compilers 
that I can copy?

2) There's a WIP proposal for adding a NoCountry value to QLocale::Country. 
This is to help simplify the QTimeZone API where AnyCountry and NoCountry can 
have different meanings, but it complicates QLocale as I note in the commit 
message.

3) I've separated adding QTimeZone support to QDateTime from adding support 
for second occurrence as the second occurrence code is not ready and won't be 
for a while due to problems with making it work with Qt::LocalTime.  This 
revolves around QDateTime's current behaviour with problems like the way it 
doesn't handle the missing hour when clocks go forward, and mktime() behaving 
differently on all 3 platforms.  Until I have both TimeZone and LocalTime 
working I can't add the new api required.  I don't see this as a reason to 
hold back QTimeZone as it is consistent with current behaviour.

4) The QDateTime QDataStream was changed in 5.0 to write all times as UTC, but 
I think this is wrong.  Qt::LocalTime is clearly documented as being the same 
local time (i.e. ymd hms) regardless of the underlying system time or time 
zone or any changes in the system zone.  The consistent behaviour when 
serialising would then be to save and restore as the local time and not its 
UTC equivalent.  For example if I serialise an alarm time of 7am local time, I 
don't expect that to unserialise as 9am because I changed the system time 
zone.  If I want a time relative to UTC then I would use UTC, Offset or Time 
Zone.

5) tst_qdatetime on Windows with a European time zone throws up 8 failures for 
me on a clean build without my changes.  Does this happen for anyone else?  Is 
this test disabled in CI, because I don't see how anything could be passing 
otherwise?  I still need to investigate why, but the tests all fail with a 
minimum qint64 msecs value.

6) Just a reminder that existing format/parse behaviour is maintained, i.e. we 
will format the time zone but not parse it.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QTimeZone available for review

[John Layt]

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.org/50065

QDateTime - Extend fromMSecsSinceEpoch API
https://codereview.qt-project.org/50066

QTimeZone - Define new class and api
https://codereview.qt-project.org/50067

QTimeZone - Add ICU support
https://codereview.qt-project.org/50068

QTimeZone - Add TZ File Backend
https://codereview.qt-project.org/50069

QTimeZone - Add Mac backend
https://codereview.qt-project.org/50070

QTimeZone - Add Windows backend
https://codereview.qt-project.org/50071

WIP QDateTime - Add QTimeZone support
https://codereview.qt-project.org/50072

I'd appreciate particular attention to the API review, and the Mac and Windows 
backends which are not my usual dev environment.

What remains to be done:
* The QDateTime integration is not quite finished and so marked as WIP, but 
the API changes need review.
* The Windows backend can have support for historic data added from Vista 
onwards.
* Lots more test cases
* A decision on parse/format (see below)

One big change since I first posted the code is there is now no system time 
zone that tracks the underlying system time zone as we already provide this 
facility in QDateTime using Qt::LocalTime.

The main issue outstanding is parse/format.  Our current support for time 
zones is inconsistent, asymmetrical, and broken in places.  You can format 
time zones in QLocale and QTime (albeit often the wrong name) but not 
QDateTime, and not parse them anywhere, so round-trip using LongFormat is 
currently broken.  The  existing code is messy, and while format is fairly 
easy to make work, parsing is near impossible to support in our current code.  
It would probably require major changes to the complex and fragile 
QDateTimeParser and QDateTimeEdit classes, but would still be deeply ambiguous 
due to our only supporting a format code for abbreviations.  Full support 
would require either breaking the current behaviour or implementing all new 
code and api names, which seems pointless for just 5.1 when I hope to have the 
new ICU based parser ready for 5.2. Instead I propose to:

* Remove the QDateTime formatter which doesn't support tz and use the QLocale 
formatter instead which does support tz
* Modify the QLocale formatter to properly format time zones, including the 
Win/Mac system locales
* To not support parsing of time zones in the old code and clearly document as 
such, recommending apps use a combo-box instead, or use the Qt::ISODate which 
does support parsing of an offset.
* To leave parsing support until 5.2 using ICU

I realise that might be controversial, and I have had some feedback that this 
is a blocker issue, but I feel the benefits of having most of the Time Zone 
support in 5.1 far out-weighs the few use-cases requiring parsing, especially 
as the existing behaviour is already asymmetrical and broken.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ICU and Windows

[John Layt]

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, located in
   a ICU 
  data directory that can be specified e.g. at compilation time. So how
  about creating a bare minimum icudt.dll, and rather ship .data files in
  a well-known place ($$[QT_INSTALL_ICU])? This would allow anyone with
  enough
  knowledge to tailor what exactly they want to ship, while reducing the
  footprint of I don't care about localization for hello world types of
  applications.
 
 Alright, this is what I found out so far: You can configure ICU to either
 place all the data in the icudt49 library, or in one big .dat file at a
 specified location, or as individual files. Having multiple .dat files is
 supported too, but that requires someone deciding how they should be
 split up.
 
 Shipping the library is what we have right now, which is IMO not
 acceptable. Just check out the comments on the 5.0.1 release blog, there
 are people still caring about 20 MB overhead :) Shipping the default .dat
 file would mean hat either your app doesn't have any codec support etc at
 all, or has everything. If we ship individual files we'd need to ship
 2345 files... that gives full flexibility, but good luck for the poor
 developer trying to find  out what he needs :)
 
 So the bottom line for me is: _We_ have to come up with an ICU profile that
 contains what we consider important, and which we want to ship in our
 default icudt library. If someone needs additional things he could add it
 by just shipping e.g. an additional .dat file. [...]

 Thoughts? Comments? Praises? ;)

This is an issue that will only get worse if/when we hard require ICU for all 
the localization data, so we do need to work out an acceptable solution.

One of the ideas behind moving to ICU was to allow embedded devs to decide 
what locales they wanted to ship to save space, rather than having them all 
embedded in QtCore.  It's obviously a feature that the Windows devs would 
appreciate too, although 20MB really doesn't seem that much to me :-).

I assume the idea of your patch is to use the 
http://apps.icu-project.org/datacustom/ to create the minimal .dat file and 
include that in Qt 
along with the empty dll?

One option to note is that according to 
http://userguide.icu-project.org/icudata in the Reducing the Size of ICU's 
Data sections you can 
modify the ICU build to put less data in the dll simply by removing the mk 
files for the conversion tables and locale and collation data you don't need.  
Keeping only the core conversion tables apparently reduces the data to about 
5MB.  This would also save any messing with having to load a .dat file.

It's clear that we can't require devs to know how to pick and choose what ICU 
resources they do and don't need, as they won't know what ones are needed and 
which are optional.  Perhaps we need to write a tool or build script that 
helps devs with choosing what resources to include, and then deletes the mk 
files and builds ICU for them.  In this way we avoid having to build or ship 
ICU ourselves, but still make life easier for devs.  If the script could also 
tell qmake what features to enable/disable in Qt as a result then even better.

The first step is obviously to compile the list of all the resources we 
currently need and don't need, and the conversion tables are the obvious main 
target for reducing the size.

I'll make sure when I do the QLocale changes that devs can choose to only use 
the system locale resources on the understanding that they won't have custom 
locales or advanced features like collation available.

Cheers!

John.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Including QTimeZone in Qt 5.1

[John Layt]

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::currentMSecsSinceEpoch()).
 
 Then please change to use QDateTime.

OK, so you would prefer the API uses QDateTime everywhere instead of MSecs?  
That will make the QDateTime internal use less efficient with converting back 
and forth, but I guess I could make QDateTime a friend of the private so it 
directly accesses the MSecs methods.  I'll just need to be careful about 
setting up circular dependencies.

  The thing with caching the System time zone is to prevent unexpected time
  zone changes.  If the system time zone was to dynamically change then an
  app could be left in an inconsistent state, with QDateTime instances
  having
  changed but gui strings and other cached details or calculations still
  reflecting the old system time zone.  My thinking was that we would have a
  QEvent::TimeZoneChange that the app would respond to by calling the reset.
 
 You're creating an API call to resolve a problem of the implementation. That
 sounds wrong. Instead, solve the problem of the implementation.

OK, I'll talk to the PIM guys about how they would expect it to behave, but in 
the meantime I'll remove it from the public api.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Including QTimeZone in Qt 5.1

[John Layt]

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 NotStandardTimeOrDaylightTime. 
  We can't use CommonTime as that has a different meaning.
 
 I see. Well, if you explain it, it might make sense.

I'll try write a good explanation, perhaps that might clarify it for me.  I'll 
also ask at the KDE PIM sprint this weekend.

  So possibly:
   - daylightTimeOffset()
   - isDaylightTime()
   - isCurrentlyDaylightTime()
 
 Sounds good. I don't like currently (using adverbs in the API sounds
 weird). Is it too expensive to do
 isDaylightTime(QDateTime::currentDateTime()) ?

Currently is now dropped, we'll wait and see if there's any demand later.  It 
would actually be isDaylightTime(QDateTime::currentMSecsSinceEpoch()).

   - transition() doesn't make sense in view of
   nextTransition() and previousTransition(), it needs a better name.
  
  Perhaps effectiveTransition()?
 
 You'll have to explain what it is. That's why I don't like it.
 
 Before this email, I thought transition() just didn't make sense.
 
 Now it looks like it returns the change that one is supposed to make at a
 given transition, whereas the other two methods return the dates of the
 next/previous transition.
 
 Either way, sounds bad.

You're right transition() doesn't actually describe what it does, probably 
because it's not actually returning a transition per se.  It's actually all 
the values you would get from calling offset(), standardTimeOffset(), 
abbreviation() etc for a given time in one efficient convenience call.  It 
would be valid to call regardless of whether a Time Zone has Transitions or 
not so it shouldn't have transition in the name at all.  I'll try come up with 
a better name, or switch it to be internal only for now as it's useful there.

The transitions(), nextTransition() and previousTransition() are explicitly 
there to allow a specialised app to navigate through transitions when for 
example calculating recurrences, so the exclusive case would be far more 
common.

- resetSystemTimeZone() needs a very good explanation.
  
  Hmmm, perhaps reloadSystemTimeZone() or refreshSystemTimeZone() would be
  clearer?
 
 I see. Sounds extremely internal detail. Do we need it? QDateTime does
 tzset() all the time, so I suggest we always reload.

The thing with caching the System time zone is to prevent unexpected time zone 
changes.  If the system time zone was to dynamically change then an app could 
be left in an inconsistent state, with QDateTime instances having changed but 
gui strings and other cached details or calculations still reflecting the old 
system time zone.  My thinking was that we would have a QEvent::TimeZoneChange 
that the app would respond to by calling the reset.

Perhaps I'll leave the System and Default stuff out of the public api for now 
until we have a clearer idea how this is all going to work.

- availableTimeZones() for a given offset: maybe unnecessary.
  
 Drop it too. Way too specific a use-case.

I'll drop it from the public api for now and keep it private, but I'll ask at 
the KDE PIM sprint this weekend if there's anything that might need it, like 
dealing with iCalendar files.  If not, I'll delete it.

 If you call them ID, then I'd agree with you. If you're just calling them
 time zone names, then keep as QString. We could return and accept the
 expanded names of those locations.
 
 E.g.: America/Sao_Paulo - America/São Paulo

No, they are strictly ID's, they must match the standard Olsen ID's as listed 
by availableTimeZones() or they get rejected.  Lets keep it simple that only 
Olsen ID's are used and not confuse things.  I could have accepted the Windows 
ID's in the constructors too, but didn't for the same reason.  Expanded names 
could be returned by displayName using a new TimeZoneNameType enum value, but 
would probably need a look-up table to be maintained so I won't do that for 
now.

Ideally the ID would actually be an enum, but they change too frequently and 
depend so much on what's installed on a given system that it would cause 
problems.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Including QTimeZone in Qt 5.1

[John Layt]

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:
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?
  
  I prefer separate commits, but Ossi generally disagrees.
 
 in this broadness, this statement most certainly contradicts reality. ;)
 
 there are two question clusters to answer here:
 - does it actually buy us anything to split this up?
   - are these changes logically distinct? (i'm not convinced)
   - is it easier to review? (not really - the parts are pretty well
 separated)
   - is undoing these additions separately a plausible scenario?
 (unlikely)
 - does it hurt to split it up?
   - is the frontend even testable without a backend? if not, then adding
 at least one halfways generic backend together with the frontend
 would be required to satisfy strict atomicity. you could cheat and
 make the tests QSKIP if no backend is found, but you shouldn't do that
 if running without backends is not actually a supported case.

Some good points.  I've decided to squash the default UTC backend and basic 
tests into the first commit so we have a fully working and tested albeit 
limited implementation with that commit.  I'll keep the platform backends and 
their specific tests separate so they're easier for the Win and Mac 
maintainers to review without the noise of the rest of the reviews, and for me 
to fix the inevitable bugs in them.

That reduces the QTimeZone commits to 5, and 1 for the QDateTime changes.

Thanks!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Including QTimeZone in Qt 5.1

[John Layt]

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 StandardTime are too close in name.

Both Mac and ICU use these terms as defined in CLDR, so no hints there.  
Standard/Daylight are the most commonly used names, including on Windows, so 
Generic must change. Usage examples are:

Standard : Pacific Standard Time
Daylight : Pacific Daylight Time
Generic  : Pacific Time

I'm struggling to think of something different, I can only think of uglies 
like UnspecifiedTime, NonspecificTime or NotStandardTimeOrDaylightTime.  We 
can't use CommonTime as that has a different meaning.

  - name() is too simple, but there's precedent (QLocale::name())

QLocale::name() is really the code, so best to avoid it.  ICU and Win use 
displayName() and Mac uses localizedName().

So displayName()?

  - I'm wondering if we should expand DST - dstOffset, isDst,
isCurrentlyDst 

Mac and Windows use DaylightSavingTime, ICU uses DaylightTime.  Not using 
the Saving is shorter and avoids arguments over Saving verses Savings.

So possibly:
 - daylightTimeOffset()
 - isDaylightTime()
 - isCurrentlyDaylightTime()

We'd change the enum to match.

I wonder if utcOffset() might then be more consistent as standardTimeOffset()?  
Might save confusion with the QDateTime OffsetFromUtc.

 - transition() doesn't make sense in view of
 nextTransition() and previousTransition(), it needs a better name.

Perhaps effectiveTransition()?

Or switch it around to transitionForTime() and transitionAfterTime() and 
transitionBeforeTime().

Or ICU just has the one method that takes an enum for TransitionType of 
Before, BeforeInclusive, After and AfterInclusive?

  - do we need createTimeZone()?

I wasn't sure if we'd hit a scenario where factory methods with different 
names but the same parms would give better control over what backend gets 
used.  Now I can't really think of a scenario where the constructor wouldn't 
work, other than point 2) below.  For the general case constructors would make 
for simpler client code, and we can add custom factory methods if really 
needed later.

So change to be constructors instead?

  - resetSystemTimeZone() needs a very good explanation.

Hmmm, perhaps reloadSystemTimeZone() or refreshSystemTimeZone() would be 
clearer?

  - static isValid() needs a better name.

Could be isAvailableId() or isAvailableTimeZone() or isValidId()?

  - availableTimeZones() for QString: maybe one of the QLocale enums?

We'd have to change regionCode() to return it as well.  We'd need to have 
internal code conversion routines, we do have QLocalePrivate::codeToCountry() 
but we'd need a new countryToCode().  

It would be nice to expose the conversion routines as public api in QLocale 
for anyone who only has the ISO code, it's what the outside world uses :-)

  - availableTimeZones() for a given offset: maybe unnecessary.

It's in the ICU api and I've seen it used a couple of places to help choose a 
time zone, i.e. you know the offset is +1 hour so what are the possible 
options.  That said Mac and KDE don't offer it so I wouldn't really miss it.


A couple of general questions:

1) The Olsen ID's are defined to only ever be ASCII, so we could make the API 
use a QByteArray instead, but QString just seems more future proof to me?

2) I'm trying to think of a nice way to allow an app on Windows to choose to 
use the ICU or TZ File backend instead of the Windows backend, i.e. a PIM app 
may want more accurate and consistent conversions.  I initially thought to 
have methods like createTzTimeZone() and availableTzTimeZones() that they 
called when they wanted instances, but that doesn't make for very portable 
code.  An alternative would be to allow them to set the System Time Zone, but 
I could see confusion then with the default time zone (they're separate 
currently with the system being immutable so that the availableTimeZones() 
list always returns the system list, for example in case you set the default 
to be a UTC offset instance which you then don't want used for the list).

3) I'm also thinking about api to load a TZ File from a given QFileInfo, but 
I'm not sure the the use or wisdom of doing that.

Cheers!

John.

___
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

[John Layt]

On 14 February 2013 19:21, Lorn Potter lorn.pot...@gmail.com 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 use either
 system on all platforms (at least names)
 If you want to look at them, I can dig up those files.

Cool, I'll attach your name to my review requests then :-)  There's a
patch set attached to the bug which I've just had a look at, it's a
very different implementation, mine is closely modelled on the OSX and
ICU api as it's really just a wrapper around them, but I'll see if
there's anything useful.

CLDR/ICU actually now provide a file of standard conversions to the
Windows ID's that I've copied.  I only directly support the Olsen
names, but provide api to convert between the two on all platforms.

 Yes, the windows tz stuff is limited. At that time, I believe Thiago
 wanted the tzdatabase to be shipped.

The problem with shipping and using tz by default is that we have to
keep it up-to-date with the frequent changes upstream (less of an
issue with our shorter release cycles now), it doesn't provide zone
names or translations so we have to which again will be hard to keep
up to date, and may create inconsistencies when using the Windows
system locale to format times.  I think it's better to use the native
support by default for general locale stuff, then perhaps provide a
factory method to create tz based instances for apps that have more
specialised needs.

Better news is that from Vista onwards the Windows support has
improved, with the ability to query for historical zone data which is
a big improvement. My code currently only supports the limited XP api,
but I plan to add Vista support soon.

Thanks!

John.
___
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

[John Layt]

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.
 * Friday 1. March: Feature branch must be tested new functionality
 documented and ready to integrate.
 * Friday 15. March: Feature freeze. Merge from dev to stable.
 
 Cheers,
 Lars

Cool, I need a few more days before the new QTimeZone support for QDateTime 
will be ready for pushing to a feature branch.  I'll drop a mail to release 
about it.

I decided the full ICU change was too big to try in the shorter release cycle 
so picked out the time zone support as a more achievable aim, and a 
requirement for KDE in Qt 5.1 to allow us to switch from KDateTime to 
QDateTime in KF5.

My work branch is at [1] if anyone's interested.  It has ICU, Windows and Mac 
support done, basic integration into QDateTime, and TZ file support soon to 
follow.

[1] http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qtimezone

Cheers!

John.

___
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

[John Layt]

On 13 February 2013 15:13, Koehne Kai kai.koe...@digia.com 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 cover it:

supplementalData.res
timezoneTypes.res
windowsZones.res
zone/*.res

I'm still trying to decide if / how to even enable the ICU time zones
in Windows.  I think by default on Windows we'll use the host system
even if QT_USE_ICU is set.  If QT_NO_SYSTEMLOCALE is set and
QT_USE_ICU is also set then I think it's implied to use ICU for time
zones, otherwise we'll just fall-back to UTC.

However, there are two special cases where we might want to use ICU on
Windows anyway:
1) An app may want to always use ICU on Windows due to the poor native
Time Zone support on Windows, so we may need a way to allow them to do
that.
2) The Windows zone names are currently only supported in the system
language, and may not match the Olsen names due to the Windows ID
mapping.  We may prefer to use the ICU translations instead if
available.

Always using ICU on Windows if available would be an option, except
ICU is missing support in it's C api for one important feature.

On Linux there's a similar dilemma with the TZ file not having
translations, but on Mac there is no reason to use ICU as the Mac
classes already wrap ICU and are easier to use.

Cheers!

John.
___
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

[John Layt]

On 13 February 2013 18:37, John Layt jl...@kde.org wrote:
 supplementalData.res
 timezoneTypes.res
 windowsZones.res
 zone/*.res

Oh, also looks like:
metaZones.res
zoneinfo64.res

I wish ICU wrote better documentation :-)

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ICU and Windows

[John Layt]

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 to be the same in their project files) or we should
 consider adding them to the 3rdparty section (like we do for libegl and so
 on) so we can control the situation better.
 
 Either way I feel that this needs to be fixed ASAP because we could end up
 seeing bug reports that are in effect caused by this and end up creating
 more noise as a result.   A short term option (and potentially permanent)
 would be to link against a different version of the ICU libraries and point
 out that if they want to use Qt in debug they would need to build ICU
 themselves and make the relevant modifications to the output library names.

Hi Andy,

I'm no expert on the various build and link issues, but in trying to write the 
new ICU backend for QLocale which would make ICU a hard requirement in the 
future I've started running into problems which may affect your choice of 
solution.

For those interested, I have working code for ICU-based number and date 
formatter classes at:
  http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale-icu

Up to now I've been using the ICU C api due to ICU not providing a binary 
compatibility guarantee on their C++ api between major versions.  This C api 
is a simplified wrapper around the C++ implementation.  This works fine for 
the most commonly used functions like number and date formatting, but the C 
api is completely inadequate for using the calendar and time zone functions, 
which are a primary reason for switching to ICU.  For example, you can't even 
find out what the current time zone is via the C api, let alone create and 
query a custom timezone in an efficient way.

I'm trying to find a way around this with just the C api, but right now the 
easiest solution does appear to be using the C++ api and somehow dealing with 
the binary compatibility problem.  Could we make that work?

On Linux, I have heard that some/many distro's automatically rebuild all 
packages depending on ICU whenever the ICU major version changes due to its 
bad reputation.  Could we simply just state that it is a requirement to 
rebuild Qt if the ICU major version on a system is changed?

On Mac, because OSX doesn't ship with the ICU headers installed, my 
understanding is we currently require people to install ICU via MacPorts or 
HomeBrew and build against that instead of the system ICU libraries.  I don't 
see that as a long-term solution when we start requiring ICU as it's not very 
portable or reliable as to the version used.  The alternative is to manually 
install the headers from opensource.apple.com and use the system library (how 
I'm currently building), but I've heard there's been issues in the past with 
published headers not actually matching?  The best option is probably not to 
use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually 
just a thin wrapper around ICU and for localization at least is complete for 
our current purposes.  However, I'm not sure this is an option for the other 
proposed uses of ICU, such as code tables.

On Windows, well it almost seems we have to require people to either build 
their own ICU and keep it in sync with Qt, or we have to start providing it 
ourselves.

Perhaps the best solution is going to be including ICU in 3rdparty:
* On Linux always build with 3rdparty ICU, unless the distro/dev chooses to 
use their system library and accepts the need to rebuild Qt with a major 
version change.
* On Windows always build with the 3rdparty ICU, unless the dev wants to use 
their own and takes responsibility for maintaining compatibility
* On Mac don't use ICU for QLocale, but use the native api instead, only build 
3rdparty ICU if other features are enabled that need it. Alternatively trust 
the opensource.apple.com headers and use the system library.

One plus point to shipping in 3rdparty is that we can use a more modern 
version than the ICU 4.0 we're currently stuck with due to Snow Leopard 
support. The big minus is ICU is big and possibly icky to build.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

[John Layt]

On 2 August 2012 13:26, Thiago Macieira thiago.macie...@intel.com 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 down-under I am currently unsure how well we can maintain and
 develop them going forward. If things turn out well, we can still move them
 into the Essentials list in a 5.1 or 5.x release.

 For 3D and Location, I have a feeling it's a little premature, but I can't
 blame you for it. Especially in Location's case, with lots of plugins to be
 kept in working order, it might be tricky in the current situation.

A few points I picked up from the QtLocation session at QtCS:
* It depends on Qt3D, so if Qt3D is out so must QtLocation
* It wasn't yet in feature freeze?
* It only has QML support in 5.0, C++ support is planned for 5.1? I
assumed this just meant the map widgets?
* Nokia Maps might be interested in maintaining it


With my KDE hat on, I'm not entirely sure QtLocation in it's current
form meets our requirements, most of KDE only needs the data container
metatypes or Position services so pulling in Qt3D and Maps and Places
and Routing seems overkill.  We could probably live with it if
QtLocation is in Essentials and installed everywhere, but as an add-on
it would be nice if we could split them up and only depend on what we
really need.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

[John Layt]

On 1 August 2012 04:00,  lorn.pot...@nokia.com 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.

 The individual developers still retain their status within the Qt Project. 
 Whether they choose to remain working on Qt is up to them.  Personally, I 
 will continue is possible because I still have plans/research I want to do.

 Except for the CI hardware. which still has employment in the EU.

Firstly, commiserations to the Brisbane guys, while not entirely
unexpected it's still not a nice experience.  Best wishes and good
luck to them all.

Secondly, I think it's pointless to prolong this thread with endless
speculation on the future of Qt within Nokia, we on the outside just
don't know enough and it diverts energy from our primary focus right
now, getting Qt5 out the door while we still have the Nokia resources
to help with the push.  Postings here also get picked up by a wider
audience and carry some weight as a consequence, so lets try keep it
positive.

However, there are a few obvious questions here affecting the release.

Firstly, how does this affect the CI/QA/Release process if the
Brisbane guys responsible have been let go?  Will any of them be kept
on, or will the valuable work they do be picked up by paid people in
Europe?

Secondly, what is the status of each of the affected modules?  Are
they ready for the 5.0 release?  What is their bus factor?  Do we
still include them in the 5.0 release if we have doubts about their
future maintenance?  Are there any development artefacts
(documentation, feature branches, etc) that we need released if the
community is to pick up maintenance?

It comes down to the individuals involved, and I'm hopeful most will
choose to stay with us, at least to see out the 5.0 release.  It's a
big ask of them and probably too soon to be asking them today, but we
need to be prepared either way.  I'm sure Lars is working with them to
figure that out.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Profile support on Qt

[John Layt]

On 1 August 2012 17:56, Olivier Goffart oliv...@woboq.com 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 ideas on API or implementation?

 Argh..  Pointers?!
 I tought it would be like an enum (or an int)
 The problem with raw pointers is that it also add more question about the
 ownership.

 I don't really like this API i must say.

Not keen on it either, I definitely don't like introducing API and
class names and especially pointers like that when we have no idea
what the future implementation will look like. Seems we're locking
ourselves into something that we don't know is the right way.  Do we
really need to do this in 5.0?  Was there an API review done on this?

I'm a bit late to the party, but with my printing hat on I'm
interested in this for the new print module which we want to be color
management aware.  We will need equal support for Windows, Mac, colord
and Oyranos.  There is a Linux color management hackfest [1] planned
for November that I plan to attend that others may wish to join as
well.

John.

[1] http://www.freedesktop.org/wiki/OpenIcc/Events/Hackfest/2012
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Migrating widgets out of qtbase into their own repo

[John Layt]

On 4 July 2012 07:03,  gunnar.sle...@nokia.com 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
plugin and not in the printsupport plugin.  It's deeply entangled in
the Mac painting code, we'd have to duplicate or export a lot of code
to separate it out.  Windows probably has a few small entanglements
but are less of an issue.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtCS - Printing, ICU Locale, Date/Time

[John Layt]

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 QTimeZone.  If you’re interested and won’t be about Saturday let me
know and I’ll try schedule them for Friday.

I have been working on designs for these which I had hoped to have finished
in time for people to read before QtCS, but the same work problems held
that up.  You can find my WIP on the wiki.

Locale:
http://qt-project.org/wiki/Qt-5-ICU
http://qt-project.org/wiki/Qt_5_QTimeZone

Printing:
http://qt-project.org/wiki/Qt_Printing
http://qt-project.org/wiki/Qt_5_QtPrint

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Mobility in Qt5

[John Layt]

On 16 June 2012 08:35,  song.7@nokia.com 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] SIC: QAbstractPrintDialog QAbstractPageSetupDialog

[John Layt]

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 gets reimplemented in the platform specific QPrintDialog derived
 class, only new methods get added.

I've posted a quick proof of concept at https://codereview.qt-
project.org/#change,26596 which basically does the name replace and removes 
the obsolete api.  A real change would do more clean-ups, and would probably 
only deprecate the obsolete options api.

The page setup dialog is even simpler.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] SIC: QAbstractPrintDialog QAbstractPageSetupDialog

[John Layt]

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
  standards, and were marked to be merged with QPrintDialog and
  QPageSetupDialog in Qt5.
 
 Hi John
 
 What's the benefit of this change? Do you have something planned for the
 future that would require this?
 
 From what I can tell, this would only remove the abstract base class...

Initially it was just it clean things up, but I do have an idea to move all 
the platform-specific dialog code into the platform plugin.  I'd prefer to 
have a public factory method to create the dialog but that's a huge SIC break, 
so instead I'm looking at making the private be created by a factory method in 
the plugin with the public class creator calling the plugin to create the 
private.  I suspect this would be a lot easier without QAbstractPrintDialog 
confusing things, I'd just have QPrintDialog with the common methods in the 
base and the rest calling into the private platform methods.

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 
gets reimplemented in the platform specific QPrintDialog derived class, only 
new methods get added.

So not vital, mostly just to make ongoing maintenance easier.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] SIC: QAbstractPrintDialog QAbstractPageSetupDialog

[John Layt]

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 Qt5.

Give the modules 'Done' status, I had thought to just leave them as I got to 
them too late, but while doing some bug fixing I realised this is ridiculously 
easy to do and would make fixing the code easier.

This is obviously a SIC change:
1) QAbstractPrintDialog and QAbstarctPageSetupDialog are removed, but I know 
of no-where else they are used so that impact is minimal.
2) The QAbstractPrintDialog::PrintDialogOption enum would become 
QPrintDialog::PrintDialogOption
3) The QAbstractPrintDialog::PrintRange enum would be removed and we'd use the 
identical QPrinter::PrintRange enum instead, saving confusion.  Alternatively 
we make it QPrintDialog::PrintRange but that seems pointless.

There's one optional change:

4) The old QAbstractPrintDialog get/set options methods had already been 
deprecated in Qt4 and replaced with QPrintDialog methods, we could remove them 
entirely or make the deprecation explicit.

So apps would only have to replace a couple of enum namespaces, but not the 
values themselves, and optionally the get/set options calls to something more 
standard.

Thoughts?

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtPrintSupport - Platform Support

[John Layt]

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:
  snip
  
  I've been testing the Mac printing and unfortunately hit a couple of
  release blockers that it would be great if a Mac person could have a
  look at sometime and give an opinion:
  
  https://bugreports.qt-project.org/browse/QTBUG-2
  
  Christoph has fixed this one:
  
  https://codereview.qt-project.org/#change,25065
  
  This one covers only the PrintPfdViaMac.pdf case. Not the other one yet.
 
 Now it covers both cases. Feel free to review.
 
 
 The crash from QTBUG-25553 is fixed as well now.
 
 
 Christoph

Many thanks Christoph for sorting it so quickly.  The crash fix works 
perfectly, and using Patch Set 4 does fix the NativeFormat problem but not the 
PdfFormat.  With PdfFormat the layout is now correct, but the actual glyph 
size is tiny.  I'll post a copy of the PDF to the bug report.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtPrintSupport - Platform Support

[John Layt]

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 printsupport, or let it live in the
 cocoa plugin and export it using QCocoaNativeInterface.  I don't like
 duplicating code so we went with the latter approach.
 
 Morten

Thanks Morten, I understand it now, you never understand a thing properly 
until you try break it apart :-)  I'll document that somewhere and set a task 
for some future release to see if we can at least untangle QMacPrintEngine 
and QCocoaPrinterSupport from QCoreGraphicsPaintEngine and move them into the 
printer plugin.

I've been testing the Mac printing and unfortunately hit a couple of release 
blockers that it would be great if a Mac person could have a look at sometime 
and give an opinion:

https://bugreports.qt-project.org/browse/QTBUG-2
https://bugreports.qt-project.org/browse/QTBUG-25553

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtPrintSupport - Platform Support

[John Layt]

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 QMacPrintEngine should be, should it go to
 plugins/printsupport/cocoa, or to printsupport/kernel like the current
 Windows and Cups implementations?  The QMacPrintDialog could have the same
 question, does it belong in plugins/printsupport/cocoa, or to
 printsupport/dialogs?  I'm inclined to have all the platform specific code
 in the plugin if possible, and change Windows and Cups to match.

Hi,

Well I've tried doing this and ended up moving QCocoaPrinterSupport, 
QQMacPrintEngine and QCoreGraphicPaintEngine all into the the printsupport 
plugin as they are all only used by QtPrintSupport, and as the plugin returns 
the native QPrintEngine as its main purpose so it seems logical.

Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa 
platform plugin to use classes/methods in QCocoaAutoReleasePool and 
QCocoaHelpers, but I can't figure out how to do that in qmake.  QtGui and 
QtWidget both use these classes/methods as well, but I can't figure out how 
they are linking against the Cocoa plugin.  Any hints on linking qtcocoa into 
cocoaprintersupport, or is that just not possible?

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtPrintSupport - Platform Support

[John Layt]

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
   - QCoreGraphicsPaintEngine
   - QCocoaPrinterSupport
src/plugins/printsupport/cocoa - QCocoaPrinterSupportPlugin

Windows:

src/plugins/platforms/windows  - none
src/plugins/printsupport/cocoa - QWindowsPrinterSupportPlugin
   - QWindowsPrinterSupport
src/printsupport/kernel- QWin32PrintEngine
   - QAlphaPaintEngine


Linux:

src/platformsupport/genericunix - QGenericUnixPrinterSupport
src/printsupport/kernel - QPdfPrintEngine
- QCUPSSupport
- qprinterinfo_unix

Can anyone explain why we have these differences, or any objections why we 
shouldn't move them around to be consistent:

src/plugins/platforms/xxx- QxxxPaintEngine
src/plugins/printsupport/xxx - QxxxPrinterSupportPlugin
 - QxxxPrinterSupport
 - QxxxPrintEngine

We could then move all the CUPS specific stuff into 
src/plugins/printsupport/cups

I'm also concerned about QT_NO_CUPS and QT_NO_LPR.  I'd like to make it more 
explicit that we only support Linux printing using CUPS and remove all 
references to LPR and QT_NO_LPR altogether (including all the 
AIX/HPUX/Solaris/IRIX code still left!).  QT_NO_CUPS would then also be 
redundant as we have QT_NO_PRINTER already.

Thoughts?

John.

P.S. Please also note that the auto tests are seriously broken and shouldn't 
be relied upon when making changes. I'm working on sorting this out.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] System Locale Update broken

[John Layt]

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.cpp and QWindowSystemInterface::handleLocaleChange() in 
Qt5.

Symbian and QNX also support this in Qt4.8 but OSX and Linux do not.

As this is a regression from 4.8 I assume it must be fixed for 5.0, rather 
than just hacking the test to make it pass?  I also assume I need to open a 
separate bug report for it?

The fix I was thinking of is making the QSystemLocale implementations detect 
any change in the system locale and call QLocalePrivate::updateSystemPrivate() 
themselves, which would also emit the QEvent::LocaleChange.

Any thoughts on this?  Any Windows hackers willing to try adapt the old 
qapplication_win.cpp code to fit in qlocale_win.cpp?

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QLocale private members

[John Layt]

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 to pack an index into locale_data
// and NumberOptions.
// ### Qt 5: change to a QLocaleData *d; uint numberOptions.
union {
void *v;
Data p;
};
const QLocalePrivate *d() const;


Can anyone enlighten me about why this is organised this way and what the plan 
was for Qt5?

I'd like to clean this up for 5.0 and try have only a *d as in 5.1 we'll get 
rid of the locale_data and use libicu instead.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt and printing

[John Layt]

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 some of my plans.  You can find a more detailed description on my blog 
at http://www.layt.net/john/blog/odysseus/kf5_localization_and_printing_plans

As Lars has explained, the Qt4 print module has been cleaned up a little in 
Qt5 but we do not plan to add any new features to this code in the future.  
Instead we are planning a new module for 5.1 or 5.2 that conforms to modern 
printing standards and features.  However that is a long time for KDE4 apps to 
wait for the missing features and bug fixes.

My current work plan is to complete the last few localisation features needed 
for Qt 5.0, then to move on to a bug triage on the QPrintSupport module to get 
it ready for 5.0.  The bug fixes here will where possible be back-ported to Qt 
4.8.  For example, I really want to get the CUPS settings bug fixes in to 4.8.

Once that work is done, I plan to fork off a Qt4 version of QPrintSupport and 
apply on top of it my old patches for adding many of the currently missing 
features.  Once that is stabilised I'll release it as an interim experimental 
print library that KDE4 apps can use if they want.

From there I plan to start working on the new print module, which we will hold 
design session for at the next Qt Contributors Summit.  Hopefully it will be 
ready for Qt 5.1 and so the first full release of KDE Frameworks 5.

I hope that answers a few of your questions.

Cheers!

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze and Alpha

[John Layt]

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.

Hi Lars,

Apologies for the late reply, snowed under at work this week.

I need to bring up the plan for the QLocale backend switch to ICU switch and 
whether you still want to complete that for 5.0 or not.

There are 4 must-do changes to the API to prepare for ICU/CLDR regardless of 
whether the backend switch happens in 5.0 or 5.1:

1) Change QLocale date/time format API to match ICU/CLDR features.  This is by 
necessity a source-incompatible change.

2) Change the date/time format codes to match ICU/CLDR codes.  This is by 
necessity a source and behaviour incompatible change.

3) Add a QCalendarSystem API. While not 100% necessary for 5.0, it sets up the 
API usage pattern for when ICU is introduced.

4) Change the QLocale number settings API like decimalPoint() from returning 
QChar to QString.  This is by necessity a source-incompatible change.

I have patches for most of that just about ready to go that I'll get finished 
at the KDE PIM sprint this weekend, and will post separate review emails for 
these.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale work

[John Layt]

On Wednesday 18 Jan 2012 13:21:24 lars.kn...@nokia.com wrote:
 On 1/18/12 12:35 PM, ext Thiago Macieira thiago.macie...@intel.com
 On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote:

  Other classes call public QLocale methods for number symbols like
  decimalPoint() and negativeSign() to use in their own custom
 char-at-a-time
  parse/format routines which will cause an issue as ICU / CLDR define
 these
  symbols as strings and not chars.
 
 I think we need to change the QLocale API here. IIRC there are a few
 locales where the decimal point is more than one char. The only safe thing
 is a QString, but we might want to also offer a lower level API that gives
 a const QChar * pointer and a length.

Yep, it's marked as API needing to change in Qt5, I just need to change the 
code that calls it in QTextStream and QSpinBox first.  I suspect QSpinBox 
doesn't really need the low level parse access and can use QLocale directly, 
but QTextStream will probably still need its own parser.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale work

[John Layt]

On Monday 16 Jan 2012 23:13:39 Thiago Macieira wrote:

 I'd say that QLocale should return the information you need. If you need to
 display that, why shouldn't QLocale provide that info?
 
 *Setting* the info is, however, out-of-scope for Qt.

When I was discussing it with Denis at QtCS he was fairly clear he didn't want 
to clutter up the QLocale api with lots of getX/getY/getZ api (he didn't like 
what was already there), but was happy for it to be in another class embedded 
in QLocale, which is why I've mentioned in the past a QLocaleSettings class, 
or doing something more with QSystemLocale to make it return all settings not 
just a limited subset of host settings.

In fact, QSystemLocale is on my hit list, as both the implementation and its 
API seem to me ugly and awkward and a potential BIC problem.  Currently the 
public base class has 2 virtual methods defined on it with no base 
implementation in the main file and no private d class.  The main virtual 
query() method takes an enum and optional QVariant for the required setting 
and returns a QVariant holding the setting.  Each host system file then 
implements the two virtual methods at base class level, i.e. not actually 
derived or virtual, but usually using a private d class or structure for the 
actual implementation.  In the future as we add more features using CLDR, 
there's no guarantee the current API will stretch to fit and the virtual 
methods would normally make it fragile if they were actually being used that 
way.

What I would prefer is to make the public QSystemLocale class a default 
implementation with non-virtual methods and a private d class that is virtual 
and has derived implementations for each platform.  This seems safer and 
cleaner, and would also allow us to add a nicer more direct API, e.g. 
decimalPoint() instead of query(DecimalPoint).  This base class then looks 
just like what a QLocaleSettings class should be, if the base d class were to 
return the CLDR settings.  A system QLocale instance would have a pointer to 
the static global QSystemLocale instance to use, but a named QLocale instance 
would create it's own QSystemLocale without the system overrides.  The QLocale 
parse/format methods would then just have a single code path querying the 
settings and passing them to ICU to use.

That's one possible model anyway, there's still some thinking required on the 
finer details.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale work

[John Layt]

Splitting up some related issues into separate emails to make it easier for 
people to address.

Which ICU version to use?

The latest ICU version is 4.8.  See See http://site.icu-project.org/download 
for detailed release notes.

OS X 10.6 shipped with ICU 4.0.

The earliest versios of major distro's to ship at least 4.0 are:

 * openSuse 11.1 shipped Dec 2008 with ICU 4.0
 * Fedora 10 shipped Nov 2008 with ICU 4.0
 * Ubuntu Lucid LTS shipped Apr 2010 with ICU 4.2
 * Debian Squeeze shipped Oct 2011 with ICU 4.4
 
Harmattan shipped with ICU 4.4, and Android 1.6 possibly used ICU 4.2.  
Windows doesn't ship ICU so we get to choose.

So ICU 4.0 seems the minimum version to target, although we lose some nice API 
and features as a result.  ICU 4.0 implements Unicode 5.1 and CLDR 1.6.

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale work

[John Layt]

On Sunday 15 Jan 2012 22:53:31 Thiago Macieira wrote:
 On Sunday, 15 de January de 2012 23.09.35, John Layt wrote:
  * A QCldrLocale is not really needed for Qt purposes, it's only needed
  for anyone who wants to know what individual settings are, like KDE
 
 What would this class provide that the regular QLocale wouldn't?

In the Locale KCM we need to know what each individual setting is so the user 
can change them.  QLocale doesn't provide that, it's mostly just to/from 
routines with a few necessary settings like decimal point exposed mainly for 
other Qt classes like QString to use, and it really shouldn't be any more.

The KCM could probably get what it needs by using QSystemLocale and directly 
querying ICU when QSystemLocale returns a null.  Or we could change or remove 
the feature, but that's a flamewar for another list 

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale work

[John Layt]

On Sunday 15 Jan 2012 19:04:09 John Layt wrote:

 I think I'm favouring the second option as being cleaner and easier to
 implement in phases.

After reading more of the ICU number API and trying some things out, I now 
think sticking closer to the current model will actually match the ICU API 
better and require less code albeit in one big bang.

* QLocalePrivate holds instances of the ICU Locale, NumberFormat, DateFormat 
etc classes.  QLocale methods call these objects directly to obtain format 
codes and perform format/parse without any call to QSystemLocale.

* For Named locales, i.e. app creates QLocale instance for en_GB: 
QLocalePrivate is created, ICU Locale and format classes initialised.  All 
QLocale calls will thus use only the CLDR default settings for the named 
locale.

* For System locale, i.e. app creates default QLocale instance: QLocalePrivate 
created as per Named locales, but then calls QSystemLocale to obtain all the 
settings which are used to set the ICU NumberFormat and DateFormat default 
values.  All QLocale calls will thus pickup the system settings.

* A QCldrLocale is not really needed for Qt purposes, it's only needed for 
anyone who wants to know what individual settings are, like KDE.

Note the ICU Format class instances may have delayed initialisation for 
efficiency, i.e. only when toString() is called for the first time.

Cheers!

John.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPrintPreview: access to single pages

[John Layt]

On Monday 31 Oct 2011 09:37:18 Giovanni Bajo wrote:
 Hi John,
 
 thank you very much for accepting to be the printer maintainer.
 
 Last year, we (Develer) proposed a patch that was rejected:
 http://qt.gitorious.org/qt/qt/merge_requests/733
 
 We then opened a bug to discuss an alternative API to implement the features
 we require: https://bugreports.qt.nokia.com//browse/QTBUG-12168
 
 (the two links above summarize our needs quite well)
 
 If we could agree on the API at least, we could move on and submit a new
 patch.
 
 Thanks!

Hi Giovanni,

Thanks for bringing this to my notice.  I have to confess that QPrintPreview 
is something I haven't touched and so have little knowledge of and it is on my 
learning TODO list.  I'll need to get up to speed there before I can comment 
on the proposal properly, but it does feel somewhat awkward to me.

The big hurdle is that we don't really want to make any changes to the 
existing printing code in 5.0 other than the work done to split it into a 
separate module.  We want to leave any significant changes for the new module 
in 5.1 or 5.2.  That said, if the implementation is a single new method that 
doesn't change much of the existing code and doesn't change the existing api 
or its behaviour then I would consider it.

The bug report mentions 2 points, 1) to Aquire a separate preview for each 
page and 2) the ability to print page subsets like 1,8,12.  I can say now that 
2) is not supported by Qt currently and will not be supported in QPrintSupport 
in 5.0 as it would require considerable changes to the existing code and api.  
It is a feature that will be in the new printing module though in 5.1/5.2 (in 
fact, it was writing patches to do this that led to my becoming maintainer).  

Will fixing 1) still be useful to you without 2)?

Thanks again, and I'll try get back to you in the next week or two.

John.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development