(13 intermediate revisions by the same user not shown)
Line 1:
Line 1:
{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
== Team Members ==
== Team Members ==
Line 73:
Line 74:
* QDate/QTime don't have a qHash?
* QDate/QTime don't have a qHash?
== Geolocation ==
Qt5 Proposal: Move QGeoCoordinate and maybe QGeoAddress from QtLocation to QtCore as fundamental data types.
Discussed with Torstan / Marble guys and they are in favour. Torstan may be at QCS so can add input there.
Move QGeoCoordinates from QtLocation to QtCore:
* Basic structure is fine
* Extra to/from string methods would be very good to add, probably acceptable to Qt
* Marble stores matrix/quaternion for performance, not sure how acceptable to Qt
QGeoAddress hasno equivalent in Marble, may be useful as is other fundamental type in Geolocation, is a clean stand-alone implementation if not very sophisticated.
=== GeoCoordinate ===
Key differences:
* Marble stores in qreal Radians, Qt in double Decimal Degrees
* Marble stores int Detail level
* Marble caches Quaternion/Matrix for performance
* Marble defines M_PI to 41 decimal places, Qt to 20
* Marble defines Earth radius as xxx, Qt as 6371.0072
* Marble returns coords in Decimal Degrees or Radians
* Marble is designed to be shared and subclassed (has virtuals, ref counter), Qt is not
* Marble is a Qt Meta Type, Qt is not
* Qt provides some calcs which use pi and radius, Marble does these elsewhere
[https://projects.kde.org/projects/kde/kdeedu/marble/repository/revisions/master/entry/src/lib/geodata/data/GeoDataCoordinates.h Marble API (simplified)]:
<code type=cpp>
class GEODATA_EXPORT GeoDataCoordinates
{
public:
enum Unit{
Radian,
Degree
};
enum Notation{
Decimal,
DMS
};
// Type definitions
typedef QVector<GeoDataCoordinates> Vector;
typedef QVector<GeoDataCoordinates*> PtrVector;
GeoDataCoordinates( const GeoDataCoordinates& other );
GeoDataCoordinates();
GeoDataCoordinates( qreal lon, qreal lat, qreal alt = 0,
GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian,
int detail = 0 );
virtual ~GeoDataCoordinates();
void set( qreal lon, qreal lat, qreal alt = 0,
GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian );
void geoCoordinates( qreal& lon, qreal& lat,
GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian ) const;
void setLongitude( qreal lon,
GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian );
qreal longitude( GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian )
const;
void setLatitude( qreal lat,
GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian );
qreal latitude( GeoDataCoordinates::Unit unit = GeoDataCoordinates::Radian ) const;
QString toString(CoordinateFormat format = DegreesMinutesSecondsWithHemisphere) const;
private:
QGeoCoordinatePrivate *d;
friend class QGeoCoordinatePrivate;
};
</code>
== Locale ==
== Locale ==
Latest revision as of 16:31, 6 June 2011
Warning
This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.
Team Members
Olivier, Volker,John, Helios, Ishmail.
Post-it Notes
Merge, Augment, Kill
Small changes in Qt to improve KDE contributions
How can we get mindset change in KDE towards Qt
Bigger things like Printing, QDateTime, maintainerships
Fixing QUrl so that KUrl is not necessary
Replacing QSettings with KConfig DConf? Kiosk?
KAction - Add default shortcut to QAction, global shortcuts
Kconfig / QSettings / DConf - No-one felt qualified to discuss this, needs a separate break-out group
A Good Thing (TM), let's do it
Freeze kdelibs4, but not too hard may need changes or can backport some KDE5 stuff
Must start now to get what we need into Qt5 or will miss the chance
Not everything needs to be in Qt 5.0, but do need to be structured so we can cleanly add new features in 5.1, 5.2
Much depends on success of OpenGov
All contributions from KDE must be seen as for better of Qt not just KDE, we need to be pragmatic
If get in early with quality contributions can establish position of trust and authority
Start small with some test cases to prove process, gain trust:
KUrl/QUrl - Very simple case with minimal change required
KLineEdit/QLineEdit(?) - More involved case
QDateTime - Test for working with Qt Brisbane to develop common requirements
Printing - Big test case for major changes + maintainership
Review progress at Desktop Summit, if good progress then commit to full process
Need class-by-class review:
Work with dependencies team, need common notes somewhere
Will need expert advice on each class, we can't know every reason for duplication
Find if a Qt equivalent (not always obvious!)
Determine why KDE version exists
Determine if Qt version is already good enough (may have improved since K class created)
Determine if we really still need any extra features
Need to consider features, quality, performance
Reach a conclusion:
Keep K class entirely
Keep K class but move some features to Qt
Remove K class, use Q class completely
Remove K class, use Q class with new K helper class
Licence:
Need review by eV lawyers to reassure contributors they don't lose rights, are fully informed of consequences, start asap as may take time
Create list of known contributors who have/will agree to Qt license so we can reuse their code if appropriate (will still need explicit agreement per contribution?)
Need to be very careful don't copy code of those who oppose code donations
Automated tools for convert?
Specific classes/modules
Some obvious stuff from off top of our collective head:
QtLocation: Move QGeoCoordinate and poss QGeoAddress from QtLocation to QtCore as fundamental data type
Gtk/Qt apps running under kde-workspace don't use KDE locale
KDE apps running under other platforms/workspaces do not use host locale
Class merges settings, formatters, parsers and translations in one giant blob
Unnecessary dependency for Qt-Addon libraries
What's great about KLocale:
Users can change settings
Apps can change settings
Superior settings, date/time, etc support
What's wrong with QLocale:
Not all settings are supported
Apps and users unable to change settings
What's good with QLocale:
Uses host settings on all platforms
Low-level common class so good for Qt Addons
The Plan:
Add all KDE settings that already exist in CLDR to QLocale
Use QLocale to replace KLocale's role as settings container
Gives correct Windows, Mac, Gnome, Meego settings
KDE Workspace to set locale envvar on login if KDE locale different to system locale
Gives correct locale Gtk/Qt apps
KCM to load settings from QLocale, write out as both POSIX and CLDR format files only if user chooses different settings
locale envvar then set to absolute path to users POSIX file so all Gtk apps get right settings
QLocale loads CLDR file so KDE/Qt apps get right settings
Apps use parser/formatter classes/api's to alter settings for one-off calls rather than changing the locale itself, or create a whole new locale object.
Big Questions:
Date/Time formats: Keep POSIX formats (need own formatter/parser that translates Unicode format) or switch to Unicode format (not SC, QDateTime may not support all our features)
How will QLocale load custom CLDR? Fallback to custom POSIX but lacks some features.