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
non
On Tue, Dec 11, 2012 at 1:39 PM, Alan Alpert <4163654...@gmail.com> wrote:
> 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 s
On segunda-feira, 10 de dezembro de 2012 19.51.32, Alan Alpert wrote:
> 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 f
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 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
On terça-feira, 11 de dezembro de 2012 13.43.08, Lincoln Ramsay wrote:
> 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 ple
On Tue, Dec 11, 2012 at 1:32 PM, Alan Alpert <4163654...@gmail.com> wrote:
> Finally Qt 5 brings better QtQml and QtQuick separation! Better, not
> perfect. The main things I've heard are missing is dynamic
> instantiation of non-Items. What I propose is a new element for the
> QtQml module which p
On Mon, Dec 10, 2012 at 7:43 PM, Lincoln Ramsay wrote:
> 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 so
Qt 5 gains this great new qmlRegisterSingletonApi function for
exposing global functionality from C++. This is great but sometimes
you want to write that global functionality in QML instead of C++. Use
cases that come to mind include UI constants and a fake business logic
backend when prototyping.
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) and
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 pr
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.
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 pl
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, too
Finally Qt 5 brings better QtQml and QtQuick separation! Better, not
perfect. The main things I've heard are missing is dynamic
instantiation of non-Items. What I propose is a new element for the
QtQml module which provides that functionality. Note that while some
people have suggested that Repeate
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 (
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 capabili
Okay, I'll send my mails to the main dev list. But there's a lot of
stuff to start it with (I'm bringing up a couple of old issues that
haven't been discussed on the ML before), so I hope no-one has a small
filesize limit on their inbox ;) .
--
Alan Alpert
On Mon, Dec 10, 2012 at 4:18 AM, Kevin K
On terça-feira, 11 de dezembro de 2012 01.06.56, Darryl Miles wrote:
> I think all of the other matters can be worked through except for the
> domain name issue and if that has to be changed (by renaming the
> project) then all the other other issues become moot.
>
> I can not think why Nokia would
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 Q
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 -
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 attractive prospect :(
How about we make qdoc generate a listing of
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
>> `/tmp/mingw32-qt/src/qt-ev
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
> `/tmp/mingw32-qt/src/qt-everywhere-opensource-src-4.8.4/src/plugins/imageforma
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, the
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 tomorrow.
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 wrote:
> Is it also possible to updated Qlocale data to CLDR 22.1 in Qt4.8.4?
>
On Saturday, 2012-12-08, Alan Alpert wrote:
> It seems that it's a different set of people who are interested, and
> this more targeted approach will help keep the dev ML relevant - after
> the discussions today I have 7 topics I want to start threads about,
> but most are for exposing to QML exis
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 announ
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 :
> Thanks. We ha
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" wrote:
>Locally? yes.
>Feel free to cherry-pick a respective changes from 5.0:
>https://coderevie
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,
https://codereview.qt-pr
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" 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 :
>> Hi,
>>
>> We've got many issues con
QLocale data in Qt 5.0-rc1 is already up-to-date (generated from CLDR 22.1).
Konstantin
2012/12/10 El Mehdi Fekari :
> 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 Qlocale pro
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 vio
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
Qlocale provides for some countries/region in the BlackBerry10 product:
* Qlocale (with CLRD2.0 Data) specifies native digits for most
On Sunday December 9 2012, Sune Vuorela wrote:
> On 2012-12-09, Sune Vuorela wrote:
> > On 2012-12-09, Marc Mutz wrote:
> >> 3. new features and bug-fixes that require new strings or BiC changes
> >> should be submitted to 'dev' directly.
> >
> > binary incompatible changes should not be submitt
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 file
> -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
I agree as well. Let's keep this on the main list.
Cheers,
Lars
On Dec 10, 2012, at 10:45 AM, R. Reucher
mailto:rene.reuc...@batcom-it.net>> wrote:
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 differen
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 peo
Hi,
My bad this time, I should've sent this heads-up a little earlier :(.
The Qt port of WebKit is integrated into Qt 5 by taking snapshots from WebKit
trunk (SVN) into a git repository and then applying (backported) fixes on top
if necessary. The location of this git repository used to be
On Friday, December 07, 2012 11:57:06 AM Ziller Eike wrote:
> On 07.12.2012, at 11:05, Sergio Ahumada wrote:
> > On 12/07/2012 10:56 AM, Ziller Eike wrote:
> >> Hi,
> >>
> >> On 07.12.2012, at 00:26, Yang Fan wrote:
> >>> Hi All,
> >>>
> >>> I'm trying building Qt5 from Git on Mac OS X 10.8.2,
Hi,
+1 for Andre.
I think we really should emphasise that QML is part of Qt and not
something different that has its own mailing list.
Also keeping the QML discussions in the core mailing list ensures
visibility and might even attract new people to QML.
Kind Regards,
Thomas Hartmann
Am 08/
44 matches
Mail list logo
