ividually or together, +1 from me.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
at if someone else could step up and take over, as I
still believe QtQuick is a key component of the premier native GUI
framework. Any volunteers?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/ma
On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa wrote:
> On 9/21/2015 10:51 PM, Alan Alpert wrote:
>>
>> I found part of the previous discussion, see my essay from 2012 which
>> explains the versioning system:http://alan.imagin-itis.net/?p=322
>
>
> Not a new discussi
below.
On Mon, Sep 21, 2015 at 11:58 AM, Attila Csipa wrote:
> On 9/21/2015 6:51 PM, Alan Alpert wrote:
>> On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon
>> wrote:
>>> or Go, then we can see that the approach of automatically always importing
>>> the latest vers
mport QtQuick from ../project.qmldir" to
give a direct link to the program configuration file.
An explicit file link would also help with modules, which presumably
need to package their import versions and use them instead of the
application settings.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
k // Automatically imported with the latest version installed
> import QtQuick.Controls // Automatically imported with the latest version
> installed
>
If you don't break from the name resolution case, you'll break when
the major version updates and things ar
run time when the system Qt
updates :( .
By using "import QtQuick 2.4" explicitly, that can't happen. That is
the value offered by minor version numbers. It is the mechanism by
which we achieve "Code written for older versions will Just Work on
newer versions".
The QML versioning
QtQml.Models 5.3
It could be running against 6.1, but was developed against 5.6 most
recently. Since they aren't using QtQuick features added in 5.6,
there's no need to change the import, the most recent features they
used from QtQuick came from 5.5. They originally developed it again
On Thu, Jun 18, 2015 at 11:48 PM, Simon Hausmann
wrote:
> On Thursday, June 11, 2015 02:21:22 AM Stottlemyer, Brett wrote:
>> Hi Alan. Hi Simon.
>>
>> On 6/10/15, 4:23 PM, "Alan Alpert" <4163654...@gmail.com> wrote:
>> >On Wed, Jun 10, 2015 at 6:5
ccurred() as the standard
signal name (which I still think is more trouble than it's worth) then
classes exposed to QML will migrate (slowly) to onErrorOccurred, and
that's fine. It would be an additional layer of confusion and
implementation to make QML diverge in order to still have onError in
Qt
is just wrong, "error" is also past tense.
I consulted a linguist. She said that if you wanted to use error as a
verb (it's not normally one), errored would be the past tense. But
that it's probably not the best choice of word.
She also said to link to thi
On Wed, Jun 10, 2015 at 7:21 PM, Stottlemyer, Brett (B.S.)
wrote:
> Hi Alan. Hi Simon.
>
> On 6/10/15, 4:23 PM, "Alan Alpert" <4163654...@gmail.com> wrote:
>>On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann
>> wrote:
>>> On Tuesday, June 09, 20
27;s
worthwhile, so I'm with Simon on that it's better to stick to error()
for now. At least for the QML exposed APIs.
> If I break out the thesaurus, then we also have
>
> errorBefell
If we want to sound fancy, we can use an obscur
On Wed, Jun 10, 2015 at 2:19 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert <4163654...@gmail.com> wrote:
>> I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the
>> imports in qtdeclarative/src/imports. Re
eems) since 5.1.1.
Given the status of those modules, our track record is indicating the
former (at least to me).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert <4163654...@gmail.com> wrote:
> I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the
> imports in qtdeclarative/src/imports. Results are attached. Results
> come from generating and parsing new qmltypes files from eac
On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann
wrote:
> On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote:
>> There was late-scheduled session on QtRemoteObjects at QtCS on
>> Saturday. QtRemoteObjects is a playground module for object remoting
>> of QObjects, and ca
ast tense so it is visibly odd. But it's nice to
be so short, so maybe a direct past-tense-ify of "onErrored"? If you
don't like using error as a verb, we can use a similar (yet shorter)
verb: "onErred". Not that I really mind the exa
le QtQuick 2.5). I
compared the 5.4 file to each of the two 5.5 files separately in the
two output files. But it's a lot of noise, and I'm not quite awake
enough to filter it out right now.
--
Alan Alpert
folderlistmodel.out
Description: Binary data
localstorage.out
Description: Bina
0
>
> ** qtscript:
> http://code.qt.io/cgit/qt/qtscript.git/tree/dist/changes-5.5.0?h=5.5.0
I just went through the git log to confirm. There is nothing of
interest to put in the changelog for QtQuick1 or QtScript (I'd be
surprised if I found otherwise). Do you really need an empty file
there?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Sat, Jun 6, 2015 at 1:14 AM, Thiago Macieira
wrote:
> On Friday 05 June 2015 10:11:20 Frederik Gladhorn wrote:
>>
> Looks good.
Looks good to me as well. I'll try to produce a QML API diff to look
through later today.
--
Alan Alpert
__
rk than just listing
changes).
--
Alan Alpert
On Sat, Jun 6, 2015 at 2:23 AM, Liang Qi wrote:
> On 6 June 2015 at 10:52, Allan Sandfeld Jensen wrote:
>>
>> On Friday 05 June 2015, Frederik Gladhorn wrote:
>> >
>>
>> Would there be any way to generate dif
om options will need to have a path to a
deployed conf.qml file which has supplemental set on it, so they can
pass that to -f in their #! line.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
g objectName with QObject is primarily a hack for convenience, I
don't like the "promotable" name so when someone thinks of a better
name we can use something like Name.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
1,n,z
isn't showing a huge burden, Simon said the issue was just JIRA. So
maybe rename "Declarative (QML1/QtQuick1)" to "Declarative (2010 ed.)"
to give the right impression?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
* Example of when you need to go off getter value instead of member is
usually sometime like implicit width, where the getter looks like
getWidth() {
if (m_width == -1)
return m_implicitWidth;
return m_width;
}
In this case, if you
found if you extend the QWindow test to hide
windows and check the resultant focus, but that test case does not
currently exist in the QWindow autotest. Since it seems controlled by
the window manager, I don't think it should be in the QQuickWindow
autotest either. https://code
drag
and drop (one of the more immature parts of QtQuick, I'll admit). It
should certainly be possible in theory to do custom binary mime data
from a custom QQuickItem, and it sounds like the current
implementation doesn't support that as well as it should.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
I currently imagine to be
implemented mainly by import restrictions and easy local file I/O
would go in a separate QtQml.* import (like how creating new windows
goes in a separate QtQuick.Window import). That's the goal, and makes
it easy in both directions, but it does mean local I/O should be
han
e state in another object
(such as in a QtObject{} on the Loader) and bind your internal state
to that so that you can use the Loader approach to recreate whole
instances.
PS: Moving to qt-interest since you didn't seem to be offering to
develop this feature as a part of Qt.
--
Alan Alp
On Tue, Dec 2, 2014 at 5:27 PM, Chris Adams
wrote:
> Sure. I think there are advantages to be had from bundling, obviously,
> but those don't really exist right now. +1 from me.
>
I'm of the same opinion. Can't defend keeping it, if it's not actually
providing
wn and
the key gets sent to the appropriate QQuickImageProvider.
The idea is that the key should be something human readable, but if
you need to pass through machine-readable UUIDs then probably just use
the URL decoding functions on it.
See also: http://qt-project.org/doc/qt-5/qquickimageprovid
w
much of a break we want QtQuick 3 to be. We already know that we want
it to be less of a break than QtQuick 1->2; since we don't expect to
replace SceneGraph that could mean that QtQuick 3 and QtQuick 2
elements could co-exist on the same scene.
It's also expected that the new Model
ght contain new import versions, too [1].
> - Import versions do not need to be "bumped" in a Qt release.
This is all correct, although I prefer my explanation ;) .
> Regards
>
> Kai
>
> [1]: There's precedence for this in Qt 4.x times, and actually one of the
> rea
log("Derived::method1()...post")
>}
> }
>
This is not currently possible. I think a mechanism for it was
proposed at QtCS (can't find the notes) but is not yet implemented.
As a workaround, you can do something like the following
Base.qml
--
QtObject {
property var me
property, deferredLoading, on Item, to solve the less
dynamic uses of Loader. Proposed new element, StateChange, to allow
more declarative state changing. Big solutions of pull bindings and a
pragma strictly-declarative are a lot of work, unlikely to occur soon.
--
Alan Alpert
dating qmltypes, it can do some replacement logic to pick the minor
version for new features instead of people having to guess.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
QuickItem itself? (but
> Q_PRIVATE_PROPERTY)
The QString state property and setState/state setters/getters are
public API in my checkout of QQuickItem (release branch).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Tue, Apr 29, 2014 at 11:32 PM, Rutledge Shawn
wrote:
>
> On 29 Apr 2014, at 7:51 PM, Alan Alpert wrote:
>
>>> (3) Document that accessing ids from other .qml files without any interface
>>> (just relying on the fact that they are in the context) creates har
-type-like objects can be exposed as JS objects when you want
more control at the cost of convenience
https://bugreports.qt-project.org/browse/QTBUG-21844 (in conjunction with above)
But there's probably some additional research to be done too.
> As a second step the actual work has to
On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz wrote:
> On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote:
>> Yes, I agree that more rigorous and agreed definitions would be
>> helpful. It also takes time, and impedes innovation, so I'm not sure
>> if we'
On Mon, Apr 28, 2014 at 12:16 PM, Bubke Marco wrote:
>
>
> Alan Alpert:
>> That said, part of the path from becoming a trailblazer to being the
>> dominant force ruling the world is IDE and tooling support. We want to
>> improve tooling capabilities wherever we can do
erformance which makes the work even harder).
> Any others models/options?
>
> Previously, I called (2) "QML". But after considering how people use
> this language, and studying other markup languages, I've changed my
> mind and think that (3) should b
ably ready to go).
Also qtdeclarative, which I didn't see in the attachments, but running
the script and adding the output to the existing changelog gives
another 'first' draft: https://codereview.qt-project.org/#change,83983
--
Alan Alpert
___
7;t have
compiled before anyways.
The Q_REVISIONs look like they're on new signals, in which case they
are actually needed. But this means the changes look fine from the QML
side :) .
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
al desktop. These
cases are quite a pain to implement right now, if at all possible (I
haven't tried, but I assume something could be hacked together which
no-one would be proud of).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
But I believe
that's scheduled for after we harmonize the multi-window APIs to work
consistently on mobile (i.e. Android).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
worked reliably. So
the strange stuff happening could be related to the platform
implementation, as we have no other platforms to compare it with. It
also makes it hard to determine the "correct" multi-screen API, when
there's no clear picture of how it would work on the majority
e to ask whoever is working on the QML test case stuff if these
>> are features that could be included in the near future (perhaps even as the
>> default behavior).
If you find a way to change keyboard focus inside the window without
changing the window focus, I would love to see a patch submitted for
that on gerrit. As always, the best chance of seeing it included in
the near future is to submit a patch.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
plementation part.
> If there was a review board (supported by more automated testing) making
> sure each change passes all those criteria before a developer gets to
> see it, it would be a lot easier to focus on the API.
>
One thing's for sure, if we have a review board we need a
d honing it for beta. While the real time chat can be nice,
it does automatically preclude certain timezones so keep that drawback
in mind.
- Amend the commit policy to require real-world examples (not
necessarily as new examples in the qt repo) fo
On Wed, Jan 29, 2014 at 12:54 AM, Olivier Goffart wrote:
> On Tuesday 28 January 2014 11:28:42 Alan Alpert wrote:
>> On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser wrote:
>
>> > While browsing through the code (qquickdrag.cpp) i found these two
>> >
>> > co
On Tue, Jan 28, 2014 at 3:02 PM, Mark Gaiser wrote:
> On Tue, Jan 28, 2014 at 11:32 PM, Alan Alpert <4163654...@gmail.com> wrote:
>> On Tue, Jan 28, 2014 at 1:25 PM, Mark Gaiser wrote:
>>> On Tue, Jan 28, 2014 at 8:28 PM, Alan Alpert <4163654...@gmail.com> wrote:
&
On Tue, Jan 28, 2014 at 1:54 PM, Steve Gold wrote:
> Alan,
>
> Thank you for your very informative response.
>
> Please see my comments below.
>
> Steve
>
> -Original Message- From: Alan Alpert
> Sent: Tuesday, January 28, 2014 2:43 PM
> To: Steve Gold
>
On Tue, Jan 28, 2014 at 1:25 PM, Mark Gaiser wrote:
> On Tue, Jan 28, 2014 at 8:28 PM, Alan Alpert <4163654...@gmail.com> wrote:
>> On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser wrote:
>>> On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan wrote:
>>>> Hi,
>
mance critical).
> Thanks.
>
> Steve
>
> BTW, I'm also posting this in the Qt forums
If you linked to that post, I could have easily checked it for possible overlap.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ap could be added,
similar to the setPixmap in QDrag (although not actually accepting a
QPixmap type).
So without a good solution handy, that part has been left "for later".
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Fri, Jan 17, 2014 at 7:01 AM, Alberto Mardegan
wrote:
> On 01/15/2014 10:48 PM, Alan Alpert wrote:
>> This approach could also apply to the original suggestion by Alberto,
>> in the absence of a separate add on module (which Sean couldn't use
>> because of the Q
On Wed, Jan 15, 2014 at 12:43 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jan 15, 2014 at 12:48 AM, Rutledge Shawn
> wrote:
>>
>> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>>
>>> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
>&
On Wed, Jan 15, 2014 at 12:48 AM, Rutledge Shawn
wrote:
>
> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>
>> On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
>> wrote:
>>> Hi all!
>>> For one of my projects, I found the need to merge several models i
e statement
"import QtFoo x.y as Name". A dependency from QtFoo->QtBar is fairly
straight forward, it gets complex when you add the version numbers
(because it will be compatible with any minor versions) and it gets
ugly when you realize that you can't import it in a namespace anymo
from me.
Aside from his immense contribution to the engine re-write, he's been
doing a lot of cleanup on the JIRA tasks recently: the gritty,
realistic side of maintainer-ship.
--
Alan Alpert
___
Development mailing list
Development@qt-project.o
dule? Or am I a little behind in my terminology?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ntally treat anything that hasn't been touched
in a year as "deferred".
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Tue, Dec 17, 2013 at 3:42 AM, Knoll Lars wrote:
> Hi,
>
> I’d like to nominate Paul Tvete as the formal maintainer of the QPA
> architecture. He’s the original architect behind it anyway, and I don’t
> think there are many people out there who know it better :)
>
+1 from m
qt-project.org/doc/qt-5/qtquick-qtquicktest.html
>
The other alternative is the qmltestrunner utility.
qmlscene is not expected to work, nor planned to, but ideally support
will be added to the new qml utility (such support is not currently in
place but wouldn't be too
ules to get their own github/gitorious/playground repo and then
we'd have to organize them with something like inqlude...
Anyone else want a qml-extras repository for collecting small QML imports?
And should it be qt-labs, playground, or qt (add on, not essential!)?
--
Alan Alpert
On Sun, Dec 8, 2013 at 11:28 PM, Alberto Mardegan
wrote:
> On 12/09/2013 12:54 AM, Alan Alpert wrote:
>> On Sun, Dec 8, 2013 at 5:38 AM, Alberto Mardegan
>> wrote:
> [...]
>> What do you mean "current context"? The problem you seem to be hitting
>> is tha
I'd recommend all context property usage be migrated
to use singleton APIs. As it is, I only recommend that for all module
APIs (basically, if you used setContextProperty inside
initializeEngine you should probably use singleton APIs now instead).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
\instantiates it, then any C++
properties need to be considered QML properties as well (it helps if
\internal works with \qmlproperty for the ones that are meant to be
hidden ;) ).
--
Alan Alpert
___
Development mailing list
Development@qt-projec
docs. It has been fixed
>> in Qt 5.2.0:
>> - https://bugreports.qt-project.org/browse/QTBUG-35018
>> - https://codereview.qt-project.org/#change,72391
>>
>> --
>> J-P Nurmi
>
> That's awesome!
> It still makes me wonder, how many more are "hidden&
r. The only time I hear about qt5.git is around release time
and I'd rather not hear about it at all (that is to say, the process
should work so smoothly and well that it never comes up ;) ). Do what
you feel is necessary.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
urs. Because there's no
way to handle construction exceptions gracefully, you'd need to be
able to declare an object and then for error handling (which could
mean no backing object could be created) then they bind to a property
like this.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Mon, Nov 25, 2013 at 2:29 PM, Thiago Macieira
wrote:
> On segunda-feira, 25 de novembro de 2013 13:21:15, Alan Alpert wrote:
>> The * is for some interesting things I noticed. Of the 3 usages, 2 of
>> them were after Thiago's original email. Which means that if he had
were after Thiago's original email. Which means that if he had
run the script on QtDeclarative as well, he'd have gotten only 1 hit.
2 of them had the wrong module name, and 1 of them was arguably
ineligible (but I'm still following that up). So there's still quite
the manual pass
On Mon, Nov 25, 2013 at 10:47 AM, Marc Mutz wrote:
> On Monday, November 25, 2013 06:26:38 PM Alan Alpert wrote:
>> On Mon, Nov 25, 2013 at 7:49 AM, Thiago Macieira
>>
>> wrote:
>> > On segunda-feira, 25 de novembro de 2013 12:49:11, Marc Mutz wrote:
>> >
g entries, I still
haven't gone through those 3016 commits yet to check ;) .
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Tue, Nov 19, 2013 at 11:17 AM, André Pönitz
wrote:
> On Fri, Nov 15, 2013 at 03:07:41PM -0800, Alan Alpert wrote:
>> On Fri, Nov 15, 2013 at 1:58 PM, Richard Moore wrote:
>> >
>> > The idea that QML deprecates ui files is frankly utter rubbish. UI
>> >
like
QQmlComponent. That works well with QML, even though it does diverge
from the WebSocket spec.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
m convinced he will make en excellent approver.
>>
>> I support this.
>> I have worked together with Fabian on the QNX QPA plugin, where he did good
>> work.
+1 from me. He also makes good QML games to show off all that code ;) .
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ic, it could move out of
the JS files and start using that module from QML directly as passing
the score to the "logic module" is UI logic. The advantage here is
that new UIs can bring in modular secondary functionality easily, like
web highscores or time-decay highscores, without needing to touch the
application logic. Sorry I don't have a very clear example/story here,
as I said we're not up to this point for realistically sized apps ;) .
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Fri, Nov 15, 2013 at 1:58 PM, Richard Moore wrote:
> On 15 November 2013 19:51, Alan Alpert <4163654...@gmail.com> wrote:
>> On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer
>> wrote:
>>> On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:
>>>
>
omes out, the only officially supported
route is a C++ app which loads a QML UI. There still are a lot of
important features to work on until I would suggest JS/QML app with
C++ extensions for the majority of app developers (stick to C++ app
with QML UI for now).
--
Alan Alpert
___
ith qmlscene, the "Qt application" is a pure QML application.
Ah, well if you're running the app with qmlscene that's not supported
anyways :P . But have a look at the new qml runtime in 5.2.
--
Alan Alpert
___
Development mai
ah, QML doesn't deprecate widgets - it deprecates .ui files because
now you can construct your widget UIs in QML :D . Long ago we
discussed deprecating widgets because Nokia wanted to reallocate those
development resources to QML/QtQuick, but thankfully open governance
foreseeable future it's still young,
and immature, and that means change. Especially since we have total
control and we need to take advantage of that lack of public API as
much as possible ;) .
But at least the creators are still around, unlike the other engines.
Hopefully they'll add some insight when they wake up, and you can
always ask questions in #qt-v4vm on freenode (CET hours at least).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
tance cost. So *long-term* I would expect a public value
type API, which would probably work with straight JS as well as
QML/JS. Unless QObject becomes free per-instance ;) .
PS: One feature on the list for the "qml" runtime is to just run
straight JS files in v4:
https://bugreports.qt-p
there's still tons of work to do. Until v4vm is ready to
take over from QtScript, which will still be a while, I believe the
recommendation is to keep using QtScript. It's deprecated and "done"
because we've reallocated development priorities, but until we've
finished i
A source integration, but it's easy enough
to put in a comment with the link to the codereview change (mitigating
the 'searchable' problem) or filling out the changes field yourself
(ah, that takes me back ;) ).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
to merge.
It should be ready, and all the dependent changes have already merged,
but it hasn't quite yet.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
prioritize them
for more accurate auto-completion?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
#x27; addWidget methods reparent to their parent widget.
>
> Therefore one option might be to just not call set parent on widget objects
> and let the list property code deal with reparenting.
I'm surprised this works. There's implicit QObject parenting built
into the language, for
ifferences short
and document them all here:
http://qt-project.org/doc/qt-5.0/qtquick/qtquick-porting-qt5.html . If
something's missing on that page, it should be added. Not sure if bugs
qualify though, I'd rather just fix them than amend the docs.
PS: inter...@qt-project.org is probably a
er list. Something will happen.
I'd like to limit the set of possible somethings, for a theoretically
simpler structure.
Back from the general to the specific, I'm definitely happy with
Richard and Peter stepping up if Shane no longer has time. It's better
to have too
e even more considered, show some code on gerrit (or github or
similar, if you've already written versions of these components that
you want to share as an example).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
In case anyone's wondering why a deprecated module had a header
change, it was just a backport of removing a compiler warning (VS2010
specific). No new functionality here.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
in QML without hacks (specifically, that exact
hack you found already which doesn't allow intermingling).
--
Alan Alpert
On Thu, Oct 31, 2013 at 12:17 PM, Konrad Rosenbaum wrote:
> Hi,
>
> I'm trying to port KDAB's DeclarativeWidgets[1] to Qt5. I've got it running
&g
lly not be used.
+1, we have a good process and it seems to be working fine in this case.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Mon, Oct 21, 2013 at 1:37 AM, Mitch Curtis wrote:
> On 09/21/2013 12:15 AM, Alan Alpert wrote:
>>
>> A while ago it came up that the rules for license headers in QML files
>> isn't clearly defined. Here's my suggestion for how to define it, and if
>> th
licenses. If nothing else, think of the poor
people on dialup ;) because that's above the "large file warning" the bot
hands out so freely.
--
Alan Alpert
<><><>___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
1 - 100 of 350 matches
Mail list logo
