Re: [Development] ChangeLogs
On Jan 29, 2013, at 1:31 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Jan 28, 2013 at 4:21 AM, Jason McDonald macadd...@gmail.com wrote: On Fri, Jan 18, 2013 at 1:05 AM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: as some certainly noted, the completeness of dist/changes-* severely deteriorated over the last few minor releases, and in particular 5.0.0 is one of the poorest qt changelogs seen in a while. also, sergio is now attempting to make 5.0.1 changelogs in a heroic one-man-effort - not entirely surprisingly, this turns out to be a tad more tedious than planned. I was quietly wondering to myself how long it would take for someone to notice that I stopped acting as editor for the changelogs when I left Nokia. As Sergio has no doubt discovered, manually generating the changes file is a tedious and time-consuming process, particularly when the level of co-operation from developers is low to non-existent. [...] So, based on my bitter experience, here are my recommendations: 1. Let's acknowledge that writing the changes file is going to have to be a manual process due to the complexity of the decision-making and the lack of a strict development process. Yes, it will have to be an ultimately manual process. But I like how your later suggestions provide hope that tools and processes can make the manual part easier. Agree. I can't really see a way to automate this neither. 2. Let's agree that module maintainers should be responsible for their module's changes file, and clearly document that responsibility on the part of the wiki that lists a maintainer's duties. +1. Release manager would still be responsible for chasing them up though ;) . 3. Let's call for volunteers to prototype a new changelog tool along similar lines to the old one, but this time with a better UI, the ability to share data between users via a git repo, and some kind of checklist to assist the decision-making process. I'm happy to help with setting requirements, but I regret that I won't be able to do much more than that as my new full-time job does not involve Qt. I'd start playing around with a QML prototype (nothing I love better ;) ) but requirements like better UI are too vague to even get started. Especially since I can't recall what the old Trolltech tool looked like. Could you flesh out initial ideas a little more, so potential volunteers could prototype their prototype? The old Trolltech tool was nothing more then a list view showing all the perforce changes between two revisions. Clicking on a change set would show you the detailed description and diff in a view on the right (a bit like gitk). It had a checkbox, so you could mark a particular change as processed, and it would store this locally. This allowed you to do the work in chunks and you would at least always know what you've already processed. IIRC, you could also limit the change sets you were interested in to a certain directory/set of files. 4. Let's try to make the job of our maintainers that little bit easier by writing good commit summaries and diligently reviewing the commit summaries of our peers. +1, but I think the tool is a more realistic way of making the task easier for the maintainers. Yes, I remember that the Trolltech tool, simple as it was, was a tremendous help. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Missing documentation makes QML ListView unusable
On Mon, Jan 28, 2013 at 11:56 PM, Rainer Keller rainer.kel...@digia.com wrote: Hi, Having a MouseArea by default would most likely lead to it being disabled in the majority of cases, on all platforms except desktop. I agree. But this doesn't this affect mobile touch devices too? Some mobile UIs have tap to select in a list. Others have scroll to select, which I think is more common (or would be if the components supported it ;) ). They also use a lot of lists just as menus of actionable items, where they would also be disabling the 'selection' mouse area because they want to trigger the action, not select a list item (although they could use that extra level of indirection if they wanted too). Only the first case would benefit from a default mouse area, the rest would have to explicitly turn it off. This is a different problem (probably easiest solved with a link to the examples, like Laszlo suggested). That sounds strange. Because there's a lot of value in running and playing with the examples, there are a lot of simple examples in the examples directory for QtQuick which would probably be better classified as snippets and integrated better in the documentation. But doing that makes them a lot harder to run right now, so they're left in the examples directory. If I submit a code snippet only for the documentation together with some text will this be an acceptable way to go? Sure, just add me as a reviewer. Practical upshot being that to be introduced to most of the QtQuick items you'll need to flip through the examples directory, which shouldn't be too hard even though it might be a different workflow for some. In my opinion the documentation should to complete enough to use it for development without the need for further sources. I agree, it's just not quite there yet. If we could have the smaller examples embedded in the documentation without cost (cost of maintaining a second copy, cost of not being able to easily run them, cost of adding all the qdoc commands, that sort of cost) then they'd be there already. That's the different problem that I was talking about, the problem with the docs as opposed to any specific problem with ListView. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLogs
On terça-feira, 29 de janeiro de 2013 08.10.17, Knoll Lars wrote: It had a checkbox, so you could mark a particular change as processed, and it would store this locally. This allowed you to do the work in chunks and you would at least always know what you've already processed. IIRC, you could also limit the change sets you were interested in to a certain directory/set of files. Actually, no. It uploaded your changes to an FTP server. There was also a hidden release manager mode, which caused it to list the directory in the FTP server and download everyone's files. That way, the release manager got a listing of all the changes that had been checked by everyone and what was left. That's how the release manager knew who to nag to write their changelogs. This is brought to you from the secret society of release management. In the next installment, Jason will tell you about a tool called jollybumper. :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5 does not build with Python 3.3 anymore
It happens somewhere while building WebKit, when build script starts to use tools from gnuwin32\bin. Unfortunately, Windows cmd utility has no facility of saving the commands history, so I can't recall the full context. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 does not build with Python 3.3 anymore
You can get cmd to tell you the command history with this: doskey /history Cheers Rich. On 29 January 2013 11:34, Дмитрий Волосных dmitry.volosn...@gmail.comwrote: It happens somewhere while building WebKit, when build script starts to use tools from gnuwin32\bin. Unfortunately, Windows cmd utility has no facility of saving the commands history, so I can't recall the full context. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository is too open
On Tue, Jan 29, 2013 at 12:52 AM, Sergio Ahumada sergio.ahum...@digia.com wrote: On 01/28/2013 03:52 PM, Peter Kümmel wrote: Seems currently everybody could merge to staging. I as non-approver have a merge button in gerrit. Or is this only a new feature to see if the request passes all tests? Peter see http://lists.qt-project.org/pipermail/development/2013-January/009467.html I think there is a problem here. The announcement in the link seems to indicate that the intention was only to present non-approvers with a Merge patchset x to Staging button once the commit has at least one +2. I'm now seeing the merge button on commits without any +2's, and even on commits where the only score is a -1. For example, see https://codereview.qt-project.org/#change,43299. IMO, we don't want over-eager contributors pressing that button and staging a change before an approver has approved it. Granted, I am an approver, so I may not be seeing the same thing that a non-approver does, but even so, I don't think an approver should be able to stage an unapproved commit either. Cheers, -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository is too open
Hi, On 01/29/2013 12:57 PM, Jason McDonald wrote: On Tue, Jan 29, 2013 at 12:52 AM, Sergio Ahumada sergio.ahum...@digia.com wrote: On 01/28/2013 03:52 PM, Peter Kümmel wrote: Seems currently everybody could merge to staging. I as non-approver have a merge button in gerrit. Or is this only a new feature to see if the request passes all tests? Peter see http://lists.qt-project.org/pipermail/development/2013-January/009467.html I think there is a problem here. The announcement in the link seems to indicate that the intention was only to present non-approvers with a Merge patchset x to Staging button once the commit has at least one +2. I'm now seeing the merge button on commits without any +2's, and even on commits where the only score is a -1. For example, see https://codereview.qt-project.org/#change,43299. IMO, we don't want over-eager contributors pressing that button and staging a change before an approver has approved it. I sort of remember that if you try to stage/submit a change that doesnt have at least one +2 it should fail and give you an error message. Granted, I am an approver, so I may not be seeing the same thing that a non-approver does, but even so, I don't think an approver should be able to stage an unapproved commit either. Maybe you can try and see if you get the error message .. if it gets staged ping me on IRC and I can unstage it :) Cheers, -- Jason Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] abandoning stale changes on gerrit
moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. regards ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository is too open
On 29 January 2013 20:00, Sergio Ahumada sergio.ahum...@digia.com wrote: On 01/29/2013 12:57 PM, Jason McDonald wrote: I think there is a problem here. The announcement in the link seems to indicate that the intention was only to present non-approvers with a Merge patchset x to Staging button once the commit has at least one +2. I'm now seeing the merge button on commits without any +2's, and even on commits where the only score is a -1. For example, see https://codereview.qt-project.org/#change,43299. IMO, we don't want over-eager contributors pressing that button and staging a change before an approver has approved it. I sort of remember that if you try to stage/submit a change that doesnt have at least one +2 it should fail and give you an error message. I see that button now all the time too (I'm not an approver). However, when I tried to stage a patch which had a +2 code review but a -1 sanity review, Gerrit gave me an error message. Haven't tried it without a +2 code review, but I presume Gerrit should complain too :) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository is too open
On Tue, Jan 29, 2013 at 10:00 PM, Sergio Ahumada sergio.ahum...@digia.com wrote: On 01/29/2013 12:57 PM, Jason McDonald wrote: I think there is a problem here. The announcement in the link seems to indicate that the intention was only to present non-approvers with a Merge patchset x to Staging button once the commit has at least one +2. I'm now seeing the merge button on commits without any +2's, and even on commits where the only score is a -1. For example, see https://codereview.qt-project.org/#change,43299. IMO, we don't want over-eager contributors pressing that button and staging a change before an approver has approved it. I sort of remember that if you try to stage/submit a change that doesnt have at least one +2 it should fail and give you an error message. Granted, I am an approver, so I may not be seeing the same thing that a non-approver does, but even so, I don't think an approver should be able to stage an unapproved commit either. Maybe you can try and see if you get the error message .. if it gets staged ping me on IRC and I can unstage it :) I wasn't game to press the button before, in case I staged something that I couldn't then unstage right away. Attempting to stage gives Application Error Server Error Requires Code Review ...so it seems safe. Still seems strange to present a button that the system already knows is a dead-end, but I guess that's a P3, not a P1. Cheers, -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Jan 29, 2013, at 1:05 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. Please don't abandon my changes, I prefer managing the list myself. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. Wouldn't it be best to put a specific date on when the administrative action will take place? Rather than leaving it arbitrary, so people have time to look at this. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] registering vnd.qt.*qml types
Hi,
sorry for the noise, I had the wrong ML address.
after some discussion on the
development@qt-project.orgmailto:development@qt-project.org mailing list we
http://qt-project.org/ decided to register some qml
http://qt-project.org/wiki/Introduction_to_Qt_Quick types in the vendor tree.
Before heading to
http://www.iana.org/cgi-bin/mediatypes.pl
We wanted to post them here for review.
We would like to register
text/vnd.qt.qml = a file adhering to the QML grammar/syntax .qml suffix,
subclass of text/plain; charset=utf-8
and as subclasses of that
text/vnd.qt.qbs+qml = .qbs suffix
text/vnd.qt.meta-info+qml = .qmltypes suffix
text/vnd.qt.project+qml = .qmlproject suffix
I have also a patch for the free desktop shared-mime-info that reflects that
change.
I am pasting it at the end of this email for reference.
Fawzi
=== diff of free desktop shared-mime-info
diff --git a/freedesktop.org.xml.in b/freedesktop.org.xml.in
index 3bb477e..ffe0410 100644
--- a/freedesktop.org.xml.in
+++ b/freedesktop.org.xml.in
@@ -1625,13 +1625,26 @@ command to generate the output files.
/magic
glob pattern=*.ui/
/mime-type
- mime-type type=text/x-qml
+ mime-type type=text/vnd.qt.qml
_commentQt Markup Language file/_comment
-magic priority=80
- match type=string value=import Qt offset=0:256/
-/magic
+sub-class-of type=text/plain; charset=utf-8/
glob pattern=*.qml/
/mime-type
+ mime-type type=text/vnd.qt.qbs+qml
+_commentQt Build Suite file/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qbs/
+ /mime-type
+ mime-type type=text/vnd.qt.meta-info+qml
+_commentFile describing qml type information/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qmltypes/
+ /mime-type
+ mime-type type=text/vnd.qt.project+qml
+_commentQt Creator Qt Quick UI project file/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qmlproject/
+ /mime-type
mime-type type=application/x-desktop
_commentdesktop configuration file/_comment
sub-class-of type=text/plain/
diff --git a/tests/helloworld.qbs b/tests/helloworld.qbs
new file mode 100644
index 000..05c8af1
--- /dev/null
+++ b/tests/helloworld.qbs
@@ -0,0 +1,9 @@
+import qbs 1.0
+
+Application {
+name: HelloWorld
+Depends { name: cpp }
+files: [
+main.cpp
+]
+}
diff --git a/tests/list b/tests/list
index 6af5885..c607a7e 100644
--- a/tests/list
+++ b/tests/list
@@ -248,8 +248,14 @@ ssh-public-key.txt text/plain
test.vcf text/vcard
# Test Go source code
test.go text/x-go oxo
-# Qt Quick (QML) file
-rectangle.qml text/x-qml
+# Qt Markup Language file
+rectangle.qml text/vnd.qt.qml
+# Qt Build Suite file
+helloworld.qbs text/vnd.qt.qbs+qml
+# File describing qml type information
+plugin.qmltypes text/vnd.qt.meta-info+qml
+# Qt Creator Qt Quick UI project file
+main.qmlproject text/vnd.qt.project+qml
# QtiPlot (qti) file
test.qti application/x-qtiplot
# Scheme source code
diff --git a/tests/main.qmlproject b/tests/main.qmlproject
new file mode 100644
index 000..4d32f75
--- /dev/null
+++ b/tests/main.qmlproject
@@ -0,0 +1,18 @@
+import QmlProject 1.1
+
+Project {
+mainFile: main.qml
+
+/* Include .qml, .js, and image files from current directory and
subdirectories */
+QmlFiles {
+directory: .
+}
+JavaScriptFiles {
+directory: .
+}
+ImageFiles {
+directory: .
+}
+/* List of plugin directories passed to QML runtime */
+// importPaths: [ ../exampleplugin ]
+}
diff --git a/tests/plugin.qmltypes b/tests/plugin.qmltypes
new file mode 100644
index 000..ff35e72
--- /dev/null
+++ b/tests/plugin.qmltypes
@@ -0,0 +1,25 @@
+import QtQuick.tooling 1.1
+
+// This file describes the plugin-supplied types contained in the library.
+// It is used for QML tooling purposes only.
+
+Module {
+Component {
+name: QDeclarative1AbstractAnimation
+prototype: QObject
+exports: [QtQuick/Animation 1.0]
+Enum {
+name: Loops
+values: {
+Infinite: -2
+}
+}
+Property { name: running; type: bool }
+Signal { name: started }
+Signal {
+name: loopCountChanged
+Parameter { type: int }
+}
+Method { name: complete }
+}
+}
diff --git a/tests/rectangle.qml b/tests/rectangle.qml
index 1635c1d..cc5d859 100644
--- a/tests/rectangle.qml
+++ b/tests/rectangle.qml
@@ -1,4 +1,5 @@
-import Qt 4.7
+import QtQuick 1.1
+
Rectangle {
width: 400; height: 200
color: lightblue
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 12:41:13PM +, Sorvig Morten wrote: On Jan 29, 2013, at 1:05 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. Please don't abandon my changes, I prefer managing the list myself. just stick to the request above. if we made an exception for everyone who wants a different procedure, we won't get anywhere - do you have any idea *how* many dead changes there are? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 02:22:47PM +0100, Shaw Andy wrote: everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. Wouldn't it be best to put a specific date on when the administrative action will take place? Rather than leaving it arbitrary, so people have time to look at this. there is no fixed date for two reasons: a) so you start with it *now*, not shortly before the deadline b) i don't know what would be reasonable. i think the number of reviews i'm watching is sufficient for a representative survey, so i'll just watch the traffic and strongly suggest a specific deadline when things start to calm down. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 does not build with Python 3.3 anymore
doskey /history works only until the session is still alive. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 does not build with Python 3.3 anymore
On 01/29/2013 12:34 PM, Дмитрий Волосных wrote: It happens somewhere while building WebKit, when build script starts to use tools from gnuwin32\bin. The failure I saw on my machine was due to some deprecated use of a print format string. I took the easy route and directed the build process to use python 2.7... Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Jan 29, 2013, at 2:32 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Tue, Jan 29, 2013 at 12:41:13PM +, Sorvig Morten wrote: On Jan 29, 2013, at 1:05 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. Please don't abandon my changes, I prefer managing the list myself. just stick to the request above. if we made an exception for everyone who wants a different procedure, we won't get anywhere - do you have any idea *how* many dead changes there are? No, and that's my point : I don't really care how many changes others have. I'll deregister myself from those I'm not interested in. Can you elaborate a bit on what practical issue this would solve? (beyond there are many changes in gerrit). Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] registering vnd.qt.*qml types
the list has moved to the media-ty...@ietf.orgmailto:media-ty...@ietf.org
mailing list.
look there for the discussion.
Fawzi
On 29 Jan 2013, at 14:26, Mohamed Fawzi
fawzi.moha...@digia.commailto:fawzi.moha...@digia.com wrote:
Hi,
sorry for the noise, I had the wrong ML address.
after some discussion on the
development@qt-project.orgmailto:development@qt-project.org mailing list we
http://qt-project.org/ decided to register some qml
http://qt-project.org/wiki/Introduction_to_Qt_Quick types in the vendor tree.
Before heading to
http://www.iana.org/cgi-bin/mediatypes.pl
We wanted to post them here for review.
We would like to register
text/vnd.qt.qml = a file adhering to the QML grammar/syntax .qml suffix,
subclass of text/plain; charset=utf-8
and as subclasses of that
text/vnd.qt.qbs+qml = .qbs suffix
text/vnd.qt.meta-info+qml = .qmltypes suffix
text/vnd.qt.project+qml = .qmlproject suffix
I have also a patch for the free desktop shared-mime-info that reflects that
change.
I am pasting it at the end of this email for reference.
Fawzi
=== diff of free desktop shared-mime-info
diff --git a/freedesktop.org.xml.in b/freedesktop.org.xml.in
index 3bb477e..ffe0410 100644
--- a/freedesktop.org.xml.in
+++ b/freedesktop.org.xml.in
@@ -1625,13 +1625,26 @@ command to generate the output files.
/magic
glob pattern=*.ui/
/mime-type
- mime-type type=text/x-qml
+ mime-type type=text/vnd.qt.qml
_commentQt Markup Language file/_comment
-magic priority=80
- match type=string value=import Qt offset=0:256/
-/magic
+sub-class-of type=text/plain; charset=utf-8/
glob pattern=*.qml/
/mime-type
+ mime-type type=text/vnd.qt.qbs+qml
+_commentQt Build Suite file/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qbs/
+ /mime-type
+ mime-type type=text/vnd.qt.meta-info+qml
+_commentFile describing qml type information/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qmltypes/
+ /mime-type
+ mime-type type=text/vnd.qt.project+qml
+_commentQt Creator Qt Quick UI project file/_comment
+sub-class-of type=text/vnd.qt.qml/
+glob pattern=*.qmlproject/
+ /mime-type
mime-type type=application/x-desktop
_commentdesktop configuration file/_comment
sub-class-of type=text/plain/
diff --git a/tests/helloworld.qbs b/tests/helloworld.qbs
new file mode 100644
index 000..05c8af1
--- /dev/null
+++ b/tests/helloworld.qbs
@@ -0,0 +1,9 @@
+import qbs 1.0
+
+Application {
+name: HelloWorld
+Depends { name: cpp }
+files: [
+main.cpp
+]
+}
diff --git a/tests/list b/tests/list
index 6af5885..c607a7e 100644
--- a/tests/list
+++ b/tests/list
@@ -248,8 +248,14 @@ ssh-public-key.txt text/plain
test.vcf text/vcard
# Test Go source code
test.go text/x-go oxo
-# Qt Quick (QML) file
-rectangle.qml text/x-qml
+# Qt Markup Language file
+rectangle.qml text/vnd.qt.qml
+# Qt Build Suite file
+helloworld.qbs text/vnd.qt.qbs+qml
+# File describing qml type information
+plugin.qmltypes text/vnd.qt.meta-info+qml
+# Qt Creator Qt Quick UI project file
+main.qmlproject text/vnd.qt.project+qml
# QtiPlot (qti) file
test.qti application/x-qtiplot
# Scheme source code
diff --git a/tests/main.qmlproject b/tests/main.qmlproject
new file mode 100644
index 000..4d32f75
--- /dev/null
+++ b/tests/main.qmlproject
@@ -0,0 +1,18 @@
+import QmlProject 1.1
+
+Project {
+mainFile: main.qml
+
+/* Include .qml, .js, and image files from current directory and
subdirectories */
+QmlFiles {
+directory: .
+}
+JavaScriptFiles {
+directory: .
+}
+ImageFiles {
+directory: .
+}
+/* List of plugin directories passed to QML runtime */
+// importPaths: [ ../exampleplugin ]
+}
diff --git a/tests/plugin.qmltypes b/tests/plugin.qmltypes
new file mode 100644
index 000..ff35e72
--- /dev/null
+++ b/tests/plugin.qmltypes
@@ -0,0 +1,25 @@
+import QtQuick.tooling 1.1
+
+// This file describes the plugin-supplied types contained in the library.
+// It is used for QML tooling purposes only.
+
+Module {
+Component {
+name: QDeclarative1AbstractAnimation
+prototype: QObject
+exports: [QtQuick/Animation 1.0]
+Enum {
+name: Loops
+values: {
+Infinite: -2
+}
+}
+Property { name: running; type: bool }
+Signal { name: started }
+Signal {
+name: loopCountChanged
+Parameter { type: int }
+}
+Method { name: complete }
+}
+}
diff --git a/tests/rectangle.qml b/tests/rectangle.qml
index 1635c1d..cc5d859 100644
--- a/tests/rectangle.qml
+++ b/tests/rectangle.qml
@@ -1,4 +1,5 @@
-import Qt 4.7
+import QtQuick 1.1
+
Rectangle {
width: 400; height: 200
color: lightblue
___
Development mailing list
Development@qt-project.orgmailto:Development@qt-project.org
Re: [Development] Qt5 does not build with Python 3.3 anymore
The failure I saw on my machine was due to some deprecated use of a print format string. I took the easy route and directed the build process to use python 2.7... So did I. But that was not obvious. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 01:53:27PM +, Sorvig Morten wrote: On Jan 29, 2013, at 2:32 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: just stick to the request above. if we made an exception for everyone who wants a different procedure, we won't get anywhere - do you have any idea *how* many dead changes there are? No, and that's my point : I don't really care how many changes others have. I'll deregister myself from those I'm not interested in. all changes i'm subscribed to are somehow interesting to me, obviously. that means that i don't want to unsubscribe, as i'd miss any relevant activity. therefore they should be abandoned if they are dead, rather than having everyone remove themselves (and in the worst case spam all other subscribers with a request to be re-invited). Can you elaborate a bit on what practical issue this would solve? (beyond there are many changes in gerrit). apart from the above, it also skews the metrics (in case somebody ever decides to use the number of open changes for something). also, the matter is not up for discussion: the cleanup of dead changes was decided before we launched. i'm just executing. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On terça-feira, 29 de janeiro de 2013 16.21.17, Oswald Buddenhagen wrote: Can you elaborate a bit on what practical issue this would solve? (beyond there are many changes in gerrit). apart from the above, it also skews the metrics (in case somebody ever decides to use the number of open changes for something). The problem is that these changes accumulate and make it very difficult to manage one's dashboard. Take a look at the reviews I'm subscribed to: https://codereview.qt-project.org/#dashboard,1000329 I really have no clue anymore what is active and what isn't. So I simply review everything that is bold when I have the time and then forget about it. That means I might be missing comments I need because the list is too long. The only changes I'll add a comment on are João's submit-and-run. Anything else that hasn't had activity in months can be abandoned -- especially stuff that has master as the target branch. Also note that the mere act of abandoning those changes might get the contributor to come back and update the change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
Oswald Buddenhagen wrote: No, and that's my point : I don't really care how many changes others have. I'll deregister myself from those I'm not interested in. all changes i'm subscribed to are somehow interesting to me, obviously. that means that i don't want to unsubscribe, as i'd miss any relevant activity. therefore they should be abandoned if they are dead, rather than having everyone remove themselves (and in the worst case spam all other subscribers with a request to be re-invited). Can you elaborate a bit on what practical issue this would solve? (beyond there are many changes in gerrit). apart from the above, it also skews the metrics (in case somebody ever decides to use the number of open changes for something). also, the matter is not up for discussion: the cleanup of dead changes was decided before we launched. i'm just executing. Than this decision should be revised. My dashboard still fits a screen, even with a few old items in it. If yours doesn't and you don't like that (I wouldn't...) unsubscribe yourself. Destroying other people's work is not an option. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.0.0 - feedback on our ways of working
Hi, We are trying to improve our ways of working, and hope you would be willing to give us your feedback on the release related work for Qt 5.0.0. Please help us by answering the 9 questions in the survey on: http://www.webropolsurveys.com/S/1FB38EA6200A637A.par Br, Sinan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On terça-feira, 29 de janeiro de 2013 15.57.18, Poenitz Andre wrote: My dashboard still fits a screen, even with a few old items in it. If yours doesn't and you don't like that (I wouldn't...) unsubscribe yourself. Destroying other people's work is not an option. There's no destroying. All abandoned submissions can be un-abandoned by the author. I could unsubscribe from stuff that is stale. But it doesn't help me do my job as a maintainer, since I don't know what reviews are stuck and need a maintainer to make a decision. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.0.0 - feedback on our ways of working
On terça-feira, 29 de janeiro de 2013 16.02.43, Tanilkan Sinan wrote: Hi, We are trying to improve our ways of working, and hope you would be willing to give us your feedback on the release related work for Qt 5.0.0. Please help us by answering the 9 questions in the survey on: http://www.webropolsurveys.com/S/1FB38EA6200A637A.par Sinan forgot to say that this was about the release management ways of working. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Predefined platform dependent constants in QtQuick components
Hi all, During development of the QtQuick2 application for BlackBerry 10 I noticed that all lists scrolls very quite slow. Same thing with any move of Flickable's content. The reason is the high resolution of the device's display. The problem is that there are constants which predefine behaviour of Flickable, PathView. Here's a short list of some of such #defines and corresponding component properties: Flickable: - QML_FLICK_OVERSHOOT - QML_FLICK_DEFAULTMAXVELOCITY - QML_FLICK_DEFAULTDECELERATION - QML_FLICK_OVERSHOOTFRICTION - QML_FLICK_MULTIFLICK_THRESHOLD - QML_FLICK_MULTIFLICK_RATIO - QML_FLICK_MULTIFLICK_MAXBOOST PathView: - QML_FLICK_DEFAULTMAXVELOCITY The actual documentation states that these properties are platform dependent and that is not true now. I think, that the right way is to move these parameters to the platform plugins, so some platforms would be able to provide predefined constants while others like BlackBerry, Android or iOS would calculate them depending on device and display runtime information. I am unsure about the implementation and maybe there are other thoughts on this problem. So, I would be happy to hear any ideas and would like to volunteer for the implementation too. Thanks, Oleg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On 29.01.2013 13:05, Oswald Buddenhagen wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. What about WIP changes? Could they stay open? It is obvious that they don't need a review. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 10:43 AM, Rutledge Shawn shawn.rutle...@digia.com wrote: On 29 Jan 2013, at 1:41 PM, Sorvig Morten wrote: On Jan 29, 2013, at 1:05 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. I'm not opposed to the idea, but can we have a better implementation? How are you defining activity, and how old must the activity be for it to be affected? Without those answers, I'll need to add an explicit ossi, don't touch this one comment to every change on my dashboard (and I will...). I would assume it's anything with an Updated field in last year, but there will be strife if anyone's assumptions are more lenient than the actions which will be taken at an unspecified point in the future. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. Please don't abandon my changes, I prefer managing the list myself. I agree; I will not like being disrupted this way. I do actually abandon stuff when it's quite clear that it's dead, but due to the review and CI processes, there's quite a large percentage of what I write that has hit some sort of obstacle and yet is still a good idea to somehow get done. We're not talking about killing any changes. We're talking about making the state in the system match reality - that change has been abandoned in practice even if you don't like to face that harsh reality. Abandoned is not -2, you can reopen it when you want to do something with it again. To look at some concrete examples, here are several of your changes which I'm a reviewer on which haven't moved since November: https://codereview.qt-project.org/#change,38313 - Good idea, still needs to be done, but this patch is going nowhere and it could just be replaced when (if ever) the new implementation gets pushed. https://codereview.qt-project.org/#change,38433 - Seems to have been replaced by a new implementation already (https://codereview.qt-project.org/#change,46020) https://codereview.qt-project.org/#change,39624 - Nothing is, or will, happen to this patch until we have a proper Window module discussion, which could also lead to a different implementation. We can unabandon it then. I don't see what the problem is for these to be marked abandoned until work resumes on them. Unless you're using your gerrit dashboard as a todo list, in which case you need to learn to use JIRA for that. But just like JIRA, we need to have some consistency in the meaning of item states or no-one will know what is happening. New stuff that doesn't make it for 5.1 is still eligible for 5.2 anyway; that's what comes out of having time-based releases, and that's the point of having an ongoing dev branch too. I also don't pay attention to anyone else's clutter. I understand that some people receive too many review requests, but here are some ideas to deal with that: 1) At least they are sorted by date so you can pay more attention to the newer ones Are you saying that we should just ignore things past a certain threshold date... as if they were abandoned? 2) If a patch is being neglected due to inactivity but still needs to be reviewed, the author can always ping you on IRC. So ignoring inactive requests is not necessarily bad. The author cannot always ping you on IRC. Not everyone is always on IRC, and not everyone can match codereview names to IRC nicks. So this might work for Thiago, but not for the project as a whole. 3) You can remove yourself as a reviewer to get it off your list and stop getting emails Then the patch gets unabandoned and you don't notice. If you abandon a patch now, and resume work (unabandon) a patch in a months time, the reviewer *really* wants an email notification. 4) You can nag the author and ask that it either be abandoned or have you removed as a reviewer ossi just did this on behalf of all reviewers, it's more efficient ;) (removing as a reviewer is not an option). 5) Maybe we could add an easy nag button for that in gerrit We could see more comments of Work on it or mark as abandoned. But we still need to clarify the policy of what abandoned means, because if I add a comment to all those changes nagging you to abandon this, then you aren't going to because you disagree with me about the meaning of abandoned. Also, nagging is *never* the ideal solution. For anything. So I really would not
Re: [Development] abandoning stale changes on gerrit
On terça-feira, 29 de janeiro de 2013 19.47.11, Peter Kümmel wrote: On 29.01.2013 13:05, Oswald Buddenhagen wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. What about WIP changes? Could they stay open? It is obvious that they don't need a review. You can't tell apart a real work-in-progress (but not progressed in months) from an effectively abandoned WIP. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 08:10:45AM -0800, Thiago Macieira wrote: On terça-feira, 29 de janeiro de 2013 15.57.18, Poenitz Andre wrote: My dashboard still fits a screen, even with a few old items in it. If yours doesn't and you don't like that (I wouldn't...) unsubscribe yourself. Destroying other people's work is not an option. There's no destroying. All abandoned submissions can be un-abandoned by the author. I am happy with my dashboard as it is. Most items (19 of 21 on a quick survey) do not affect anyone who took part in this discussion so far. I don't think any kind of activity would help to clean up _their_ dashboards in those cases, and I don't think I owe any kind of activity to keep the status quo. I could unsubscribe from stuff that is stale. But it doesn't help me do my job as a maintainer, since I don't know what reviews are stuck and need a maintainer to make a decision. Unsubscribing seems to be indeed the best solution, with or without comment, depending on case. In case explicit maintainer interaction is needed to settle a dispute it should be clear from the discussion. In cases where it's just a kind of CC: maintainer, FYI kind of forced subscription some I trust you do to the right thing without me watching the case or even a silent unsubscription seems to be in order. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tue, Jan 29, 2013 at 08:43:33PM +0100, Oswald Buddenhagen wrote: On Tue, Jan 29, 2013 at 06:43:34PM +, Rutledge Shawn wrote: I do actually abandon stuff when it's quite clear that it's dead, but due to the review and CI processes, there's quite a large percentage of what I write that has hit some sort of obstacle and yet is still a good idea to somehow get done. before somebody gets stupid ideas: the cut-off for dead changes will be set at two months (or more - tbd) without any activity (which is not pinging). i don't see how any regular processes could lead to changes being stuck longer than that, and why keep-alive comments wouldn't be an acceptable effort to handle the exceptional cases. Most of my open issues are work in progress for things that are not completely mission-critical, essentially waiting for the equivalent of a Creative Christmas Vacation. And yes, this may mean yet another year. i don't yet know how to turn this into routine. but i think we should repeat this each time in the middle between two minor releases, which would make for a roughly half-yearly cycle. The problem seems to be that for a few people the dashboard gets oversized. That's not necessarily a problem of The System which mostly contains requests not related to those few people. I understand that having an oversized dashboard makes it unusable, but this problem is not solved by imposing yet another process on unrelated changes. Just unsubscribe from the not-so-interesting reviews. The world will not end. Even if you don't watch it. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On Tuesday 29. January 2013 13.05.52 Oswald Buddenhagen wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity for a long time a honest look. please explicitly mark the ones you still want to work on by adding a comment. everything which has no indication of (planned) activity in a few weeks will be abandoned by administrative action. if you are an ex-troll/-nokian, please also check the dashboard of your alter ego. if you are a maintainer, give identified drive-by contributors a ping. i'd also like to encourage everyone to adopt orphaned changes they have an interest in. regards ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, Please don't do it. My dashboard contains patches, that I'm interested in. It is a kind of knowledge storage, with already signed CLA. I understand that a big dashboard is not nice to maintain, but forcing everyone to clean it up is not the way to go. Answer is: use filters. https://codereview.qt-project.org/#q,reviewer:+oswald+-age:+2d+status:open,n,z for more you can look here: https://review.typo3.org/Documentation/user-search.html Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
