Table of Content

• Qt 5 product definition
  • Background
  • How Qt is structured
    • Modules and Repositories
    • QML, C++ and qmake guidelines for Qt Essentials and Qt Add-On modules
    • Guidelines for the QML import statement of other Qt-related modules
    • Module version numbers
  • Moving modules between categories
  • Scope
  • Releases
    • Qt 5 minor releases
    • Independent module releases
    • Patch level releases
  • Configuration Tiers and Platform support
  • Cross-platform promise
  • Compatibility promise and Qt release numbering
  • Qt 5.0

Qt 5 product definition

This document summarizes the outcome of Qt 5 product definition discussions at QtCS, and the follow up discussions on the qt5-feedback mailing list.

Background

This document is the Qt 5 product definition. It discusses the naming, module structure, forward and backward compatibility promises, cross-platform promise, platform tiers, and high level principles about Qt releases.

The targets for the definition include

• Simple and clear structure and naming that works for existing users of Qt, new users of Qt, and creators of Qt, in all environments (desktop, embedded, mobile)
• Consistency between different parts of Qt and consistency between “marketing” and Real World
• There should be room for Qt Add-ons that provide additional benefits on specific environments, without bloating Qt for everyone.
• We want to send the correct message to the users of QWidget classes: they are 1st class citizens in the desktop environment, but not necessarily available in the embedded or mobile environments

How Qt is structured

Qt consists of the Qt Essentials, Qt Tools and Qt Add-Ons. The following table summarizes these categories.

The naming convention for all modules and tools that originate from the Qt project is to start with “Qt”, followed by a descriptive name of the module. For example Qt Designer, Qt Core, Qt Quick 3D and Qt Contacts.

Please pick just one name for the module, and use it consistently in documentation, QML import statement, library name, and the header file name. This makes Qt appear more consistent and guessable.

A recommended way for other Qt-related modules and tools to refer to Qt is to follow the pattern “Foo for Qt”.

Modules usually have a C++ API and a QML API. In the official documentation, we shouldn’t refer to “QML bindings” or “QML plugins” or “QML modules” when we actually mean the QML API provided by a Qt module.

Modules and Repositories

This section has been moved to the Qt Project wiki at http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository.

QML, C++ and qmake guidelines for Qt Essentials and Qt Add-On modules

This section has been moved to the Qt Project wiki at http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code

Guidelines for the QML import statement of other Qt-related modules

It’s a good practice to pick a name that is likely to be unique among Qt related modules. One way to avoid clashes in the QML import statement is to use a reverse domain name:

Alternatively, it is possible to use a prefix in the module name, making the probability of a clash lower:

Module version numbers

The owners of each module decide how they number their releases. Not everything needs to be numbered from the 5.x range but it is fine to have Qt Quick 2.0 in Qt 5, for instance.

Versions in the 0.x range are used for experimental releases of add-on modules. Experimental modules are not included in Qt Essentials.

A Qt release will have different versions of different modules, so the developer will have to look up the version anyways. Documentation or auto-complete features in Creator will help here.

There should be no new features in the patch level releases of Qt 5. Not all modules need to be updated in every minor release.

Recommendation: each module should have just one name and one version number. Currently this is not the case, but we have stuff like lilbqtwebkit.so.4.8, which is the same as Qt WebKit 2.1 in the documentation and you import it with “import QtWebKit 1.1”. There is a similar problem with Qt Declarative/Qt Quick.

Moving modules between categories

Some of the Qt Add-Ons for Qt 5.0 were a part of Qt 4. These modules become add-ons mainly because they are not available on all environments (for example the QWidget classes), or because the primary solution for the problem in Qt 5 is different from Qt 4 (e.g. Qt Script). We should not move any modules from Qt Essentials of Qt 5.0 into Add-ons later during the Qt 5 series. Because of the Qt 5 source compatibility target, we will not put the former Qt 4 modules in the QtAddOn C++ namespace.

It should be very easy to start a new Qt Add-On in the Qt project. When a new project is started, a module name is reserved (mechanism TBD). This module name will be used in the library name, import statement and in the C++ namespace (see above).

When a new Qt Add-On module is ready, stable and considered useful on some of Qt’s platforms, it can be included in the Qt release. This is a major decision that indicates endorsement by the Qt project. A high level quality, API reviews etc. are expected. No changes to the naming of the module, import statement, or C++ naming are required.

If a Qt Add-on module is considered essential and important for all users of Qt, then the add-on module can be moved to Qt Essentials. This requires a full compatibility and cross-platform promise. The module can be renamed at this point. A complete API review should be done to make the API consistent with the rest of Qt Essentials.

The C++ namespace is removed when an add-on module becomes an essential module.

Scope

Qt is a toolkit for developers and designers. It consists of libraries, developer tools, design tools, documentation, demos, examples. Qt’s main technologies are QML, C++ and JavaScript.

The following areas are not in scope of the Qt Essentials (but may be in scope of Qt Add-Ons)

• Applications
• Operating system functionalities such as window manager, process manager, application lifecycle management
• Other programming languages besides QML, C++ and !JavaScript

Releases

Qt 5 minor releases

Qt is released commonly for everyone. Global releases maintain the integrity and identity of Qt as a single toolkit instead of a fragmented collection of related toolkits.

Synchronized releases allow API review rounds and enable pervasive changes such as code refactoring to be done, because the project has a maturization period.

Global releases should be schedule based (Qt 5.0 is an exception).

Even though Qt is developed in a modular way and modules are generally independent, Qt is released as a collection of modules, where a certain combination of module versions is released together. Most Qt users should not need to care about the detailed version numbers of the modules but they should be able to consider Qt as a single non-fragmented toolkit.

Independent module releases

A new version of a module is developed against the latest released versions of other modules, and can be released as an independent module release. An independent module release must ensure that there is no regression. Also the new features need to be tested and new APIs need to be reviewed.

The developers of Qt modules and advanced users who are willing to take additional risks may also create “pick and mix” builds with other module version combinations. However, because the bigger Qt releases get a lot more review and validation from users and the developers of other modules, it is possible to discover problems or conflicts with other new modules, when an intermediate module release is finally included in the Qt release. Therefore, the new features in the intermediate module releases should be considered experimental.

Patch level releases

Patch level releases are meant for critical bug fixes and security updates only. Some modules (for example Qt WebKit) may need to issue security related patch level releases on a very short notice. Modules make patch level updates independently. Qt patch level releases consist of module patch level releases.

Configuration Tiers and Platform support

A configuration is a detailed specification of an operating system version, a tool chain version, a graphics system, and possibly other dependencies. The supported configurations of Qt are defined by what is used in the build bots. For user documentation, it is possible to “extrapolate” platform support from the tested configurations using common sense.

In Qt 5, the configuration tiers should be a matter of documenting the facts: if a configuration meets the criteria, it becomes Tier 1. A configuration can move between tiers during the lifetime of a release.

Reference configurations:

• The Qt Project defines a small number of reference configurations, which are the primary configurations used in developing Qt. The number of reference configurations should not be a lot more than 5.
• All Qt releases must support all reference configurations
• Reference configurations must meet the Tier 1 criteria and never drop to Tier 2.

Tier 1 configuration criteria:

• The configuration participates in the CI system and any other automated testing
• Availability of beta, alpha packages for the platform, and timely participation in manual testing for the packages
• Bug metrics criteria like # of P0 and P1 bugs on the platform
• Community committed to maintain the configuration for patch level releases, and commitment is credible (capacity exists)
• Other possible criteria, for example any required platform specific documentation exists and is of high quality

Tier 2 configuration criteria:

• The configuration participates in the CI system and any other automated testing
• Availability of release packages for the platform

Tier 3 configurations are not officially a part of Qt. Platforms that do not meet the Tier 2 criteria fall into this category, for example because the platform is not in the CI system or “upstream”.

For new platforms, the contributors should start with a branch that tracks the master branches of the Qt, and provide a CI system for the branch. It is perfectly fine to make releases out of such platform specific branches. Once the platform has been proven to track the master successfully, the platform-specific branches can be integrated to the Qt module master branches and the platform can become an official part of Qt.

Cross-platform promise

The cross-platform promise of Qt 5 differs from Qt 4 slightly, because some important functionalities are provided by add-on modules for which the platform support is defined separately.

We should aim at releasing new versions of each module for all the reference platforms and Tier1 platforms of the module. That results in the same mix of module versions in the Qt release. This has a couple of benefits:

• Synergies in testing and validating the new designs and fixing bugs. A significant portion of Qt’s bugs are cross-platform issues, so having all the platforms work on the same module version mix creates synergies and improves the quality of the release.

• We avoid releasing designs that haven’t been validated on some of the important platforms

• We maintain the integrity of Qt as a single toolkit, which makes it easier for developers to understand what Qt is and to reuse code across platforms. It also makes it easier for the SDK to include documentation, demos, and examples.

Making a new release of a module and choosing to not support a platform that is normally Tier1 should not be done. Similarly, defining a different module version mix for different platforms in a Qt release should not be done.

Compatibility promise and Qt release numbering

We will continue with the current major.minor.patch numbering scheme for Qt releases. The modules in Qt Essentials have the same forward and backward compatibility promises as Qt 4: New Qt 5 minor releases will not break binary compatibility, and patch level releases are forward and backward compatible. Qt Add-On modules specify their compatibility promise separately.

Qt 5.0

See the Qt 5.0 page on the roadmap for a list of modules in Qt Essentials and Qt Add-Ons for Qt 5.0:
http://developer.qt.nokia.com/wiki/Qt_5.0

Qt Quick Components for Qt 5

Goal

1. Qt Quick Components for multiple platforms
   • Cross platform achieved through, “One code base”
2. Provides Qt look & feel and behavior
   • For developers would mean good looking applications that works similarly on various platforms (not necessarily with native look&feel)
3. Customizable components
   • Platform specific components could use these components as baseline so that common API and behavior for components would be met

Current status

1. Each platform is providing its own widget set (Symbian, Meego Harmattan Nokia, MeegoUX Intel)
2. Some commonality on the Common API on the Nokia component set, but not enough to provide a solid cross-platform solution
3. Component set between Symbian / Meego differs
   • common api, but behaviors are not guaranteed to be the same
4. Desktop components is out of scope for this discussion (on the desktop we can provide a QWidget like cross-platform api)

Context

There are now at least 3 component sets developed, during this process we learned that it is extremely difficult to create a cross platform offering for platforms that are still in development. This effort involves synchronizing teams working on different platforms, with different requirements (for styling and theming, for example), to do a collaborative development that in the end might slow the whole process down, which is critical in the device release context.

It is natural that platforms provide their own widget set, but Qt should ease the task of application developers that want to target the highest share of devices/platform possible. Qt needs a widget set with an api to be used as basis for app developers and also as a reference implementation for new platforms.

Reasoning

1. We’re lacking clear 3rd party story “Code once, run everywhere”
2. Demand for UI components that runs across multiple platforms
3. It is not worth trying to do 100% merge of code base of different platforms: for example, Meego and Symbian
   • We have seen in Meego/Symbian components activities that when developing for a specific platform, the focus is tightly related to platform specific problems. Thus, creating platform dependencies.

What to do (plan)

1. Mission: “provide a style for mobile devices that works everywhere, as a cross-platform solution for application developers”
2. Cross platform achieved by using the same code base!
3. Easy to use mobile friendly navigation model
   • Page concept provides a browsing like experience that is understood by end-user
   • Most mobile UIs have a similar concept
4. Platform neutral Qt look and feel
   • promote collaborative design in the open source community
5. API and behaviors defined by Qt
6. Start as Qt 5 add-on

Way to get there

1. Develop project openly as Qt 5 add-on
2. Use the custom/template branch of qt-components repository as basis for customization possibilities
   • Styling APIs would not be opened at the first phase. (we still can have a private styling api internally)
3. No platform specific code involved, would run on top of Qt Quick (Qt Quick 2?)
   • In spirit of “Code once, run everywhere”
   • Best would be QML code only, without compilation needs (this is not a hard requirement)
4. What components?
   • basic core controls: button, checkbox, radiobutton, switch, buttongroup, buttonrow, slider, progress, TextArea, TextField
   • advanced (later): page, dialog, window, screen, context menu, toolbar
   • out of scope: tooltip, menu

Schedule

DO NOT UPDATE THIS SCHEDULE DURING THE SUMMIT TO ADD SESSIONS! USE THE PAPER VERSION IN THE ENTRANCE AREA!

NOTE: “x” is a placeholder that can (and should!) be replaced with a real title. :)
The training sessions in GEO will be filmed and made available online after the event.

PDF version of the Saturday schedule as of 10:00 is at http://bit.ly/iNEMAK

Thursday

Friday

Saturday

LDAP Integration

Michael Schloh von Bennewitz

Cafe Moskau Mars A, 14:30-15:30

Qt Contributor Summit Minutes

A one timeslot meeting was scheduled after hallway chats which led to interest in pursuing integration of LDAP in Qt.

• Discussion about licensing was discussed, probably due to developers’ concern of prototyping using OpenLDAP or integrating code from KDE.

• Lecture sheet is wrong to state that OpenLDAP includes the GPL. Instead it includes the BSD. This is not true either! After the fact, it was determined that OpenLDAP distributes its own license called the ‘OpenLDAP Public License’ which is similar to BSD.

• KLDAP [api.kde.org] has been available for a while, seems to be actively developed but not that popular.

• KLDAP is qualified by the GPL, and could be a very important clue in progress towards LDAP integrating.

Use cases for LDAP integration in Qt abound, and many closely resemble use cases served (sometimes inappropriately) by the QSQL classes.

• Use cases abound including QNetwork LDAP authentication. Several examples were mentioned such as input completion in email clients and IP telephones.

• Many use cases served by QSQL could benefit from a QLDAP library.

• The differences between SQL and LDAP technology were mentioned.

• It was emphasized that SQL and LDAP are similar in many ways, at least in the sense that the problems that they solve overlap.

• To reduce API (re)structure, LDAP components could be integrated into the QSQL classes. It was agreed that any LDAP logic placed in or near Qt should not be integrated into the existing QSQL library. Instead it should be its own library, and probably take a back seat to priority libraries by means of becoming a addon component.

• Lecture sheets corresponding to the presentation will be published.

• Update! The sheets are available from the Europalab Fileserver [ftp.europalab.com]

Current topic list

This is a living list that will most likely change over the coming weeks.

1 slot is meant to take 50 minutes to allow for easy changing of rooms and coffee I/O. Longer sessions can book 2 slots.

At the session titled ‘Build System’ two use cases of “Building Qt itself” and “Building applications using Qt Creator” were primarily discussed. The case of building Qt applications from the command line was discussed but not emphasized.

For “Building Qt itself” it was noted that –

1. qmake can build Qt 5 now,
2. even if it is not nice, it is there and works,
3. there is no need to change anything for the sake of change only,
4. people do not care much about the process as long as builds Qt.

For “Building applications using Qt Creator” it was noted that –

1. qmake is difficult to control due to its imperative nature,
2. cmake started its life imperative, mixed in declarative constructs for KDE.
3. qmake does not do project configuration (easily),
4. qmake does not cover the actual building (delegated to make/nmake),
5. qmake does not handle deployment/packaging (easily),
6. qmake does not offer cheap “null builds”,
7. qmake can only parallelize build to the degree the make/nmake/ib does it,
8. an existing build system called ‘incredible’ can parallelize builds but is not portable.
9. cmake basically shares all these shortcomings with notable exceptions of configuration.

For “Building applications using a command line tool” it was noted that –

1. while logic from a new build system could be shared across a CLI tool and a IDE (by a common library) the IDE would actively run the logic while a CLI tool explicitly on demand only.
2. there were a lot of Qt Creator developers in the room, leading to the sense that work towards any new build system would probably need to be geared at an IDE.
3. one development strategy for a new build system would involve abstracting code into a library which could be integrated into a command line tool as well.

While some limited discussion was heard of premake, gyp (generate your projects), and wxwidgets build system (not sure about that one), most attention was placed on cmake. Cmake is developed by primarily by Kitware and whose developers are active on mailing lists including Qt. Although some interest was shown by these members regarding this topic, unfortunately none of them were able to attend the summit and seem quite busy.

All in all there was a general feeling of: What is there (both qmake and cmake) sort-of-works, within limits, but is painful to use at times, and the missing/broken parts do not look easily fixable. Starting from scratch looks like an interesting alternative, but would also require a significant amount of work. Some developers are disillusioned with the current state with no clear solution.

#inqlude – The Qt library archive

Notes from the Qt Developers’ Summit session of a Qt library archive aka “CPAN” for Qt

Getting a better overview and more easy access to all the great Qt based libraries out there, especially also those done independently of the core Qt libraries. Having something like CPAN or Ruby gems would be great. Let’s discuss what we can do here. We already discussed this topic at the KDE Platform sprint and collected some input and ideas.

It shall not be just an archive on a website, but also include a system to install stuff. It’s inspired by Perl’s CPAN or Ruby’s gem.

A prototype is available on http://inqlude.org
Git repository is at https://github.com/cornelius/inqlude
The metadata git repo is at https://github.com/cornelius/inqlude_data
Mailing list for discussing Inqlude: https://mail.kde.org/mailman/listinfo/inqlude

implemented as a git repository with metadata for the “packages”

There is a prototype command line tool

The installer is hooked into the native package manager (e.g. rpm, dep). It installs the operating system’s packages if available.

Dependencies

• not yet fully designed and implemented
• is needed in the long term

Use of native package managers

Pros

• using the infrastructure that’s already there

Cons

• Mixing native packages and manually installed ones is messing up the system
• No native packages for various platforms (including Mac, Windows)

Build Systems

• force the libs to provide a qmake .pro file or allow different build tools (qmake, CMake, autotools)
• possible tools to look at:
  Gentoo ebuilds
  Ruby gems

Metadata

• use own format or adapt an existing one (deb, gems)?
• what info to put in?
  • dependencies (on qt libs and/or external libs)
  • which type of build system is used
  • supported platforms
  • licenses
  • required Qt version (min, probably max)
• who will create the metadata (bootstrapping?)
• where is it stored (file inside the tarball?)

QML Components

Search for a particualar component should be possible (where to find it, which package to install it)

Misc

• rating a lib (centralized? or on different sites focusing on specialized audiences)

Metadata Followup Session

Field description

schema_version

• identifies the version of the used metadata schema

name

• identifies the add on
• must be unique
• first come, first server

version

• to distinguish different versions of an add on
• is the same as the upstream version
• there is no QPAN/inqlude specific versioning

release_date

• date when the library was released upstream

summary

• a short string (one line) describing the library

urls

with subkeys:

• homepage
  for the project homepage
• api_docs
  for the API docs
• readme
• logo
• screenshots
  with a list of URLs

licenses

• list of multiple licenses
• well known licenses are identified by keywords
• custom licenses with a keyword only, no link

description

• a long description
• can include multiple paragraphs
• format plain text (newlines for separating paragraphs)

authors

• list of authors consisting of author’s name and a url/email address in a string

maturity

• inspired by sourceforge, but leaving out some states

platforms

• list of platforms (Linux, Windows, Mac…)

packages

• with subkeys for various systems
• source is mandatory
  • optionally scm repositories (scm specific)
  • build systems (may be more)
• platform/distribution specific formats

keywords

• should be obvious :-)

dependencies

• dependencies within the metadata space and external
• name, min version, max version
• this are hard dependencies which are required to build the lib/app
• optional requirements should go into the description

languages

• list of programming languages. Mostly will be C++, but could be something like Python, with bindings, or QML, if we want to extend to that.

notes

• update_date (reflecting the last change of the metadata) is not required

Example for meta data

—————————————————-
Summary:

• Different stakeholders will consume metrics from different places
• Contributors would benefit from metrics when committing, so for example links from Gerrit to pages showing how the commit would affect Qt. Also test results would be useful.
• Contributors would also benefit from test coverage metrics, to show where test coverage is lacking. Either on a general level or on commit level, showing coverage for the code to be checked in.
• Static analysis metrics / comments would also be useful on a commit level.
• Static analysis such as spell checking would be useful for Qt Creator code, for example capitalization checks for dialogs

• Metrics on a general level (such as a metrics page) should include: test coverage per platform, most used parts of the code, most changed files, bugs in components / files
• Get/present usage stats for a set of Qt apps, to show which parts of the code is being used most. Can be useful for Approvers, to help them know importance of performance when reviewing for example

• Integration / release managers would be interested in trends on quality, to help them explain why contributions don’t get “accepted”

• For people optimizing for different platforms, performance metrics on different platform configurations might be useful.

• Social metrics -> Nbr contributors, nbr commits / time, changed parts of Qt / time, top ten contributors

• Start collecting common reasons for contributions being rejected, collect and publish those to help contributors get their code into Qt.

Let’s follow up using http://lists.qt.nokia.com/mailman/listinfo/qt-metrics-feedback

QDateTime

This page details the discussions about QDateTime in the Date/Time and Localisation sessions.

This page was written by John Layt from KDE (jlayt@kde.org).

KDE would like to phase out using our own KDateTime, KLocalizedDate and KCalendarSystem implementations in favour of QDateTime but many changes would be required to do so. We believe most of these changes will be of use to other app developers, especially the QtMobility calendaring team. More details on the issues can be found on the KDE wiki at http://community.kde.org/KDE_Core/QtMerge/QDateTime. KDE code can be found at https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/show/kdecore/date.

It is proposed that Qt will fully implement the Unicode CLDR standard for date/time handling across all platforms.

Code Quality

Important code is inline and no d_ptr makes it impossible to change the implementation without breaking BC, this should be fixed.
Poor overflow checking in places returns incorrect results instead of an invalid date, fixing this in Qt4 was impossible as it is inline code.

John Layt to provide patches.

Calendar Systems

Calendar System support is standard in Windows and Mac and fully integrated into their date localization systems. Unicode CLDR defines Calendar System support and ICU implements it. Qt does not properly localise dates and date formats for those users who have selected an alternative Calendar System on these platforms. Linux does not have standardised support, but both KDE and ICU implement support.

Note that some of these calendars are just the Gregorian calendar with different Epochs or Eras, i.e. ISO8601, Japanese Era, Thai, RoC, North Korean (same as RoC). The Coptic and Ethiopean are also the same calculation with different Epochs. The various Asian Lunisolar calendars are all derived form the Chinese Lunisolar. Windows uses separate implementations of the Gregorian for different digit sets or translations (Arabic, English, localized, etc) but others cover this using api.

Lars in favour of minimal set of calendars common to all platforms, but this will not solve the issue of say .Net and Qt apps running side-by-side and showing different format dates. Compromise may be that on Windows and Mac the date formatting/parsing internally uses Win/Mac system calendar system, but on Linux Qt only supports minimal set which are then available for explicit use on all platforms.

One consequence of this will be separate Calendar System support for Gregorian and Julian calendars, the current hybrid calendar would be removed and it would be up to the app to decide if/when they need to switch between the different calculations.

Proposed api:

The enum will list all possible calendars for all platforms with a calendarSystems() returning which ones are available on a given platform.

Implement QCalendarSystem which is embedded in QDateTime, possibly doesn’t need to be public? QCalendarSystem to provide names to QDateTime (but how does that affect the QLocale month/day methods?). KDE can sub-class and extend using platform backend for calendars Qt does not want to support directly?

John Layt will work on a design and merge request for this.

Time Zones

Proper timezone support is required to allow apps like calendaring to use QDateTime. While full support inside QDateTime would be ideal, it should at least be able to act as the data container with apps providing their own advanced manipulation tools. KDE has full cross-platform time zone support which could be adapted. Qt Mobility is also interested in this area and any solution should be coordinated with them.

Cross platform support is a major issue, apps need a consistent api and naming standard, for example to create a QTimeZone instance for Central European Time (CET). Lars in favour of a single implementation and database in Qt common to all platforms to give apps a consistent experience, with Qt providing a conversion layer to system time zone, especially on Windows.

Using a tz file shipped with Qt would quickly go out of date as the tz file is updated very frequently, sometimes even weekly. The system tz file should be preferred if available as it is more likely to be automatically kept up-to-date. Only if no system file is found should Qt fall back to its own file.

Unix tz zones.tab is regularly updated by OS, but no translations and no canonical ID’s.

Mac uses own tz file and translations. Mac api should provide inspiration for Qt api.

Windows does have its own time zone database stored in the registry and is regularly updated, but the names and definitions are very different to the Unix tz / Olsen zones. KDE implements a translation layer to convert Windows zones and names into Olsen zones and names which could be used.

CLDR time zones (http://www.unicode.org/reports/tr35/tr35-15.html#Timezone_Names) based on Olson zones.tab but provides canonical ID’s for each zone and translations for all zone names. Problem comes with lack of regular system updates.

Possible api:

• add enum value TimeSpec::TimeZone
• add new QTimeZone class
• add QDateTime timeZone() api to return the zone value if TimeSpec set to TimeZone, otherwise return null QTimeZone

Date/Time Span/Duration

QTime is restricted to a range from 00:00 to 23:59. However there is often a need for time durations such 52 hours or 52:00 which QTime is unable to represent or format. Either QTime should be extended to allow for a duration mode or a QDuration/QTimeSpan class created. Basically a period of x milliseconds, but able to be relative to a start date, and having various maths and formatting functions.

KDE has an implementation in KCalCore::Duration http://api.kde.org/4.x-api/kdepimlibs-apidocs/kcalcore/html/classKCalCore_1_1Duration.html using KDateTime

QTimeSpan is a merge proposal at https://qt.gitorious.org/qt/qt/merge_requests/1014.

Does QtMobility Organizer have a similar class?

Valid Date Range

The date is stored as a Julian Day Number in a uint with jd == 0 erroneously considered to be invalid. This restricts dates to a range of 2 January 4713BC to about 11 million AD. Changing the uint into an int32 or a int64 will make this date range more useful scientifically:

• int32 = 5.8 million BC to 5.8 million AD
• int64 = 25 Quadrillion BC to 25 Quadrillion AD
• Geological time: Age of Earth = 4.5 billion years old
• Astronomical time: Age of Universe = 13.75 billion years old

So an int32 is sufficient for geological time, but int64 seems overkill to gain astronomical time.

In theory every value of JD will be considered valid, although the lowest negative number may be designated the null value rather than using a bool.

Currently used Gregorian/Julian formulas do not reliably support converting JD’s to/from Dates outside of 8000BC to 8000AD, but this can be later extended.

isValid() will indicate if the current JD lies in a valid date range, i.e. one supported by the conversion formulas of the current Calendar System.

isNull() will indicate an uninitialised date or completely invalid date, e.g. where date maths has overflowed the JD storage size.

Nothing should stop setting Julian Days outside the isValid() date range as this will still be scientifically useful, you just won’t be able to convert them to Date form or do Date maths beyond adding days.

John Layt to submit patches.

Date Locale Functions

Some additional localization options could be added to QLocale to support date formatting, these are all defined by Unicode CLDR:

• Short Year Window
• Digit Sets
• Calendar System
• Week Number System (support US weeks as well as ISO)

Note Week Start Date and Working Week have been added for 4.8.

Extra Calendar/Date Attributes

Add additional standard date attributes defined in the CLDR such as quarter, months in year, etc, that are useful for calendar systems and date formatting support.

Proposed api:

See also Name functions and Date Format Codes which implement string versions of some of these.

John Layt to submit patches.

Date Name formatting

The current QLocale and QDate api for month/weekday names is rather messy and mixed up due to incremental changes and is marked for clean-up in Qt5. The following new api based on CLDR is proposed:

Alternatively NameFormat and NameContext could be merged but this is less future proof, i.e. if more contexts are later required:

Date/Time Format Codes

The Qt to/from string format codes are mostly based on the Unicode CLDR formats but have a couple of problems:

• Only a small sub-set of CLDR codes are supported
• A few Qt format codes are not in the CLDR standard
• Currently 3 different implementations of parsers/formatters, need simplifying to one

These format codes also have equivalents in the standard Posix, Windows and OSX date/time formats which are used in localization, so by not supporting them Qt may not be correctly localizing dates to the users system date/time formats. Many apps also need more flexibility in formatting dates.

Most of the missing format codes are just string forms of existing Qt api.

Reference http://www.unicode.org/reports/tr35/tr35-15.html#Date_Format_Patterns

Qt currently supports the following format codes:

Note that:

• ddd and dddd formats are not valid CLDR forms but derived from Windows, they should be EEE and EEEE instead.
• AP and ap are not valid CLDR forms
• h and hh do not exactly match the CLDR definition
• t is not a valid CLDR form

The following CLDR codes should be supported:

It was suggested to use a regex based fromString() method like in QTimeSpan. This can wait for 5.1 or later.

Agreed to remove non-standard format codes, implement as many standard CLDR codes as possible. Initial implementation may not be most efficient but can be improved later. Must be in 5.0 as changes Source Compatibility and changes behaviour.

John Layt to submit patches.

Date/Time Named Formats

QDateTime supports a number of named date/time formats:

This enum is used by QDate, QTime and QDateTime so being called DateFormat is a misnomer and should be fixed, either by splitting into date/time/datetime enums or making the value names more generic.

The CLDR standard defines standard date formats for Full, Long, Medium, and Short, all of which are also supported by Mac and Windows. The extra Full and Medium formats should be added.

The difference between the System* and Default* formats should be investigated and if possible split to a second enum? The deprecated ones should be removed, and TextDate investigated to see if it is meaningful anymore.

The following common formats supported in KDE could also be added:

• ISOTime – ISO 8601 format time
• ISODateTime – ISO 8601 format date and time
• RFCDateTime – RFC 822/850/1036/1123/2822 format
• RFCDateTimeDay – RFC format including day of the week
• RFC3339DateTime – RFC 3339 format
• ISOWeekDate – ISO 8601 Week Date format
• ISOOrdinalDate – ISO 8601 Ordinal Date format

The ISO dates should accept both basic and expanded formats.

Note KDateTime uses regex’s for some of these in an inefficient way so don’t just copy the code.

Possible api:

Where the context of the class will determine if it is a date, time or datetime version. Where a format is inappropriate the default format will be returned.

Alternative api

Date Eras

Many locales have an optional Era system for dates, others such as Japan use an era system in its official date formats. Proper localisation support requires this to be added, especially if Calendar Systems are supported.

Proposed api:

John Layt to submit patches.

ISO Ordinal Date

The ISO 8601 standard defines an Ordinal Date standard of yyyy-ddd for day ddd in year yyyy. Qt already provides api for dayOfYear(). Support could be added to to/from string using the standard Unicode format codes and a named date format, and api provided for directly setting the date using the ordinal date.

Proposed api:

John Layt to submit patches.

ISO Week Date

The ISO 8601 standard defines a Week Date standard of yyyy-Www-d for weekday d in ISO week ww of year yyyy. Qt already provides api for weekNumber(). Support could be added to to/from string using the standard Unicode format codes and a named date format, and api provided for directly setting the date using the week date.

Proposed api:

If support for week number systems other than ISO Weeks is added (e.g. US Weeks) then the api would be changed to remove the ISO form the name and optionally add the week number system as a parameter.

John Layt to submit patches

Date Maths

Qt currently only provides standard date math functions for adding years, months or days. Some more convenience functions could be added.

• Date difference (inverse of addYMD())
• Years difference (inverse of addYears())
• Months difference (inverse of addMonths())

The following are useful with Calendar System support:

• First day of year
• Last day of year
• First day of month
• Last day of month

Possible api:

Look in KCalCore and QtOrganizer to see what other date math / classes might be useful.

Widgets

The various widgets will need modification to match the new features and api and to resolve old bugs.

QDateTimeEdit needs to support null dates and extend the supported date range.

QCalendarWidget needs to use Start of Week and Working Week Start/End from QLocale, but be able to override if needed.

Some new widgets may be needed,perhaps based on KDE combo box versions.

Table of Content

• Session 1
  • Notes
• Session 2
  • Notes

Session 1

• 16/Jun/11 Thursday 13:30 – 14:30
• VEGA A

Notes

• Introduction to QtQuick3D
  • 3D programming in QML making it easy to add 3D contents to 2D applications.
  • http://doc.qt.nokia.com/qt-quick3d-snapshot/
  • Code walkthrough on SpaceTyper as an example and code distribution for hacking challenge http://gitorious.org/spacetyper
• Feedback
  • Q. Relationship between Qt5 Scenegraph and QtQuick3D? A. We do not have a separate scenegraph for 3D. Item3D writes to FBO.
  • Q. Any software fallback if OpenGL is not available? A. Qt5 requires OpenGL so that is the baseline.
  • Q. Any plan to add video texture? A. That is doable but not currently planned.
  • Car industries are interested in 3D.
  • Qt Partner using QtQuick3D to model industrial machines. http://www.youtube.com/watch?v=g_cf-7uoK5o

Session 2

• 18/Jun/11 Saturday 13:30 – 14:30
• VENERA A

Notes

• QtQuick3D roadmap on JIRA
  • http://bugreports.qt.nokia.com/secure/Dashboard.jspa?selectPageId=11096
• QtQuick3D tutorial on Youtube
  • http://www.youtube.com/watch?v=OXcxFZbKUNI
• Feedback
  • Community ported QtQuick3D to iOS (IanFromAfrica on IRC)
  • Demoed iPad running QtQuick3D, one patch made to handle defualt framebuffer
  • Qt for Android is yet to support OpenGL.
  • Q. Does QtQuick3D work with 4.8? A. It works with 4.7 and 4.8 but the official 1.0 will be released aligned with Qt5.
  • Q. (Digia)How about 0.x pre releases? A. That is not our normal practice but we will consider it if that helps comercial customers.
  • More video tutorials the better.
• SpaceTyper challenge winner
  • Thorbjørn http://gitorious.org/~bjorn/spacetyper/bjorns-spacetyper
  • The original code had one Viewport for each 3D item which did not give proper perspective when there is more than one items. Thorbjørn changed the code to have only one Viewport for the whole game. This is better for the performance but makes the game a bit harder to play.