On Monday 10 December 2012 10:05:06 Thomas Hartmann wrote:
I think we really should emphasise that QML is part of Qt and not
something different that has its own mailing list.
Right.
Also keeping the QML discussions in the core mailing list ensures
visibility and might even attract new people
-Original Message-
From: development-bounces+andy.shaw=digia@qt-project.org
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On
Behalf Of Marc Mutz
Sent: 9. desember 2012 14:23
To: development@qt-project.org
Subject: Re: [Development] RFC: What constitutes a
Please report the error issues on the bugtracker.
After a quick google, it seems that the CPXCInfoShlExt stuff come
from a PDF-XChange shell extension, and I don't understand why
such a shell extension is invoked when you try to playback video.
Maybe you get these messages when you open the
On Sunday December 9 2012, Sune Vuorela wrote:
On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote:
3. new features and bug-fixes that require new strings or BiC changes
should be submitted to 'dev' directly.
binary incompatible
Hi Andy,
On Monday December 10 2012, Shaw Andy wrote:
Ok, trying to summarise, I understand it this way:
1. release-critical fixes are submitted and merged to 'stable' now,
'release' later, when it exists.
No-brainer fixes are also welcome.
2. bug-fixes that don't violate string
QLocale data in Qt 5.0-rc1 is already up-to-date (generated from CLDR 22.1).
Konstantin
2012/12/10 El Mehdi Fekari mfek...@rim.com:
Hi,
We've got many issues concerning the current Qlocale data based on CLDR
v2.0. We currently have a critical bug concerning the default numbering
system
Is it also possible to updated Qlocale data to CLDR 22.1 in Qt4.8.4?
Thanks,
Mehdi
On 12-12-10 6:19 AM, Konstantin Ritt ritt...@gmail.com wrote:
QLocale data in Qt 5.0-rc1 is already up-to-date (generated from CLDR
22.1).
Konstantin
2012/12/10 El Mehdi Fekari mfek...@rim.com:
Hi,
We've
Locally? yes.
Feel free to cherry-pick a respective changes from 5.0:
https://codereview.qt-project.org/39558,
https://codereview.qt-project.org/39559,
https://codereview.qt-project.org/39560,
https://codereview.qt-project.org/39561,
https://codereview.qt-project.org/40038,
Thanks. We have already an internal change to update the concerned Qlocale
data, but we just want to avoid internal commits and deviate from upstream.
Mehdi
On 12-12-10 6:50 AM, Konstantin Ritt ritt...@gmail.com wrote:
Locally? yes.
Feel free to cherry-pick a respective changes from 5.0:
Wasn't 4.8.4 already released?
Anyways, I don't think this can be done for 4.8.x since CLDR 2.0.1
(and later) introduces a bunch of behavioral changes that must be
carefully tested. The Policy doesn't allow such changes in
patch-release(s).
Konstantin
2012/12/10 El Mehdi Fekari mfek...@rim.com:
On Friday, December 07, 2012 07:48:44 AM Thiago Macieira wrote:
On sexta-feira, 7 de dezembro de 2012 11.57.06, Ziller Eike wrote:
git://gitorious.org/qtwebkit/qt5-module.git
which is old, unused and deprecated.
Guys, wasn't there some consensus to announce changes that
That's a bigger effort. I'd rather consider using CLDR 2.0, fixing the few
problems you have in the data, and then regenerate it using the python scripts.
Cheers,
Lars
On Dec 10, 2012, at 12:38 PM, El Mehdi Fekari mfek...@rim.com wrote:
Is it also possible to updated Qlocale data to CLDR 22.1
Hi everybody,
we'll need a second release candidate, as the RC1 had a few issues that really
should get fixed. But we also hope very much that we won't need a 3rd one.
We'll try to get the next RC out on Wednesday evening. This means that all
changes blocking the RC2 need to get in by
On segunda-feira, 10 de dezembro de 2012 12.07.21, Marc Mutz wrote:
I was suggesting that bug-fixes initially be submitted for stable (blindly,
if you will) and that review decides whether to redirect them to dev
instead.
If you're a reviewer and you know you'd suggest moving it to dev, then
On 10/12/12 21:22, Erik van Pienbroek wrote:
Linos schreef op do 29-11-2012 om 18:37 [+0100]:
Hi!,
i just downloaded the new version to create the mingw32-qt Arch Linux
AUR
package and i get this error compiling it:
make[4]: Entering directory
On segunda-feira, 10 de dezembro de 2012 23.45.44, Marc Mutz wrote:
On Sunday December 9 2012, Marc Mutz wrote:
Burdening the maintainer with generating the changes file after an
onslaught of dozens of committers and 100s of changes without regards to
the changes file is - I repeat - not an
Thiago Macieira wrote:
So there is an awareness of what the Qt Jambi project is to both parties
and how the Qt Jambi project operates. For example contributions have
not been governed by any CLA for some time.
All contributions through the Qt Project infrastructure go through the Qt CLA.
For finer-grained control over QML it would make sense to have an API
allowing import restrictions. Two usecases come to mind, platform
security contexts and scriptable applications. Platform security
contexts is about when a platform using QML for the applications wants
to have restricted
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users
QAction served widgets well as an abstraction for an Action which is
exposed to the UI in a platform specific manner. This was shared
between menus and toolbars and some other things. I think we'll need
something similar for QML, so that the QtQuick controls can provide
platform styled menus,
On 11/12/12 13:23, Alan Alpert wrote:
Any comments on adding an API like this?
Are there any other usecases which this might need to support?
If we're talking device security and restrictions policy... then please
make this something that can fail softly at runtime.
I know most mobile
I'd like to remind people that qmlviewer and qmlscene are not meant
for deploying applications. They are not a complete runtime, they are
only meant for debugging. But the fact that people keep wanting to use
them for their applications suggests that it might be worth providing
a complete runtime.
People keep asking for enumerations in QML. See QTBUG-15483 and
QTBUG-14861, both assigned to old Nokia identities (so don't trust
that 'in progress' ;) ). Now I don't know when these issues will be
resolved, but there's an important discussion to have before it can
even be scheduled: What would
There was a discussion a while ago about a better settings API for
QML, http://permalink.gmane.org/gmane.comp.lib.qt.qml/3162 was the
best link I could find, but no progress has been made since. The main
concensus I got from that thread was just that no one likes QSettings
(ancient, file-based)
On 11/12/2012, at 1:25 PM, Alan Alpert 4163654...@gmail.com wrote:
APIs likely to come in later. So if we had an import QtAddons 5.0 it
could look like this:
import Qt3d 2.0
import QtSensors 5.0
import QtMobility.sensors 1.3
FYI QtMobility.sensors has been removed.
Lorn Potter
Senior
On segunda-feira, 10 de dezembro de 2012 19.25.57, Alan Alpert wrote:
Even if this is a good idea, I have no answers for the following questions:
Where will this be maintained? It practically depends on every Qt module
I think that we could implement this by a special qmldir file that simply
On 12/11/2012 04:39 AM, Alan Alpert wrote:
The QMenu API allows for adding menu separators too, but I haven't
seen those in apps for a while. Is it worth adding another type or
flag to integrate separators into the Action API?
Couldn't menu separators automatically be added between each
27 matches
Mail list logo
