Re: [Development] qt summit 2012 schedule structure
Hi, I think using the tracks is a good idea. Some 'keynotes' in the beginning for everyone, and after that the tracks. These help in finding the most interesting topics. It would be good to plan a bit more ahead than last time (and have some of the sessions announced prior to the event), but I think it is still important to allow sessions to come during the event. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.com or qt.digia.com On 11.4.2012 21.14, Sivan Greenberg si...@omniqueue.com wrote: Hi All, Doing more organization thought and work, we'd like to get the discussion going about how to best organize the the schedule for the summit. My personal experience from last year was such that it was a bit hard to decide which sessions to attend, some I missed due to room locating (perhaps that's just me ;)) but it extremely easy to actually schedule my session and gather participants for it through the sticky note system. Now, although this might be more related to the content rather than structure but the latter could benefit- what about having top level tracks that we can pre-decide on like for instance Qt Outreach (with subjects: Docs, Qt marketing, community and commercial visibility) , Qt Core (-beta efforts, bug fixing, features, users itches, new contributors etc.) Qt Platforms=(PI, android, iOS, etc.) Qt Extras (projects surrounding Qt that demand and contribute to its development) and then - each track takes place in room blocks such that moving is easy within the track between the rooms. Also, when checking the sticky board it might be easier to decide to go to a session when it has the 'track' tag. Also, if hacking sessions are scheduled just like any other session it might enable more people to attend as opposed to background ones, as it can be pinned in one's schedule. From my personal experience, having at least 15 minutes break after each session would be great to catch breath, drink something and then go to the next one. If our day is around 10 hours of day conf, and we have an hour lunch break, that means we can schedule no more than 9 sessions of 45 minutes each day. Thoughts, suggestions corrections (this is mostly my 2c from last year's experience, the track names are solely for demonstration) ? -Sivan ___ 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] Qt5 missing features
On 4/12/12 6:05 AM, ext Alex Wilson alex.wil...@nokia.com wrote: On Wednesday, April 11, 2012 07:25:41 pm ext BogDan wrote: the problem with QML desktop components is that not all controls are touch friendly (e.g. lists, editbox, etc.), even they have Android look the feel is not the right one. As I said, I believe is a waste of time to have 3 completely different ways to draw QML components (desktop, symbian and meego) + one for classic widges. =snip= so you'll end up with two QML components implementation, one for pointer devices (desktop, N900, etc.) and one for touch devices (N9, etc.) I really like this idea -- PointerComponents and TouchComponents, and when you import them, you get the appropriate look and feel for the runtime platform, without having separate QML files for each one -- just one QML file for your touch UI (mobile), and one for pointer UI (desktop). Just that this doesn't take into account how things are evolving on the HW front. I believe you'll start seeing touch screens on 'desktop' platforms appear rather soon now, and if you look at Apple and Microsoft, you can see that they are preparing their OSes for that. So we might need components that can deal with both in some way and maybe detect pointer vs touch at runtime. Cheers, Lars But currently the different QML components implementations for each platform have completely different paradigms and ways of organising things... it's more than just a simple oh there are some widgets different -- the entire API is differently designed. So harmonising all the touch platforms and all the pointer platforms into those two groups under a standard banner for each would be difficult, but necessary, I think, if we want QML components to be a serious cross-platform UI offering to compete with our own QWidgets. It could also be the case that some platforms really have unique and specialised aspects (like e.g. some menubar stuff on OSX maybe), and these should get special treatment, maybe in their own import just for apps that don't mind writing some more platform-specific code. Of course this discussion would be much simpler if QML had some equivalent to #ifdef that doesn't involve massive multi-file code duplication... -Alex ___ 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
[Development] Nominating Steffen Hahn and Johann Specht for Approver status
Hi, I would like to Nominate Steffen Hahn and Johann Specht for Approver status. Steffen and Johann have been contributing to qtsystems module for quite some time now. Give a look at their dashboards if you want to know what they have been doing: Steffen : http://codereview.qt-project.org/#dashboard,1000219 Johann : http://codereview.qt-project.org/#dashboard,1000233 Best Regards, Kranthi. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] System Locale Update broken
As this is a regression from 4.8 I assume it must be fixed for 5.0, rather than just hacking the test to make it pass? I also assume I need to open a separate bug report for it? As much as possible we would like to fix any regressions that we find in 5.0 compared to 4.8, so that migration of existing applications to 5.0 is is easy as possible. I don't see a need for the overhead of a second bug report. Better to just make the title of the existing report reflect the real problem and not just the first symptom that was noticed. Bug reports often start out as a description of symptoms and there's nothing wrong with adjusting that description when we gain a better understanding of the root cause. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for an upgrade (Thu 12th - 09:00 - 09:20 CEST)
On 04/11/2012 02:11 PM, Sergio Ahumada wrote: Hi, Gerrit https://codereview.qt-project.org/ will go down at 09:00 CEST tomorrow Thu 12th 2012, for deployment of fixes. Fixes are: https://bugreports.qt-project.org/browse/QTQAINFRA-190 https://bugreports.qt-project.org/browse/QTQAINFRA-195 https://bugreports.qt-project.org/browse/QTQAINFRA-340 https://bugreports.qt-project.org/browse/QTQAINFRA-357 https://bugreports.qt-project.org/browse/QTQAINFRA-366 https://bugreports.qt-project.org/browse/QTQAINFRA-367 https://bugreports.qt-project.org/browse/QTQAINFRA-456 We expect Gerrit to be down for about 15 - 20 minutes. I'll will send out a follow-up once the service is back up. Cheers, Hi, Deployment was successful, thanks you for your patience. If you find any problems, please let me know as soon as possible ! The new version is called: V2.2.1-NQT-007. This should be put in the Environment field if you want to report bugs in JIRA. Cheers, -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 missing features
From: Alan Alpert alan.alp...@nokia.com To: development@qt-project.org Cc: Sent: Thursday, April 12, 2012 6:20 AM Subject: Re: [Development] Qt5 missing features On Thu, 12 Apr 2012 11:28:43 ext Lincoln Ramsay wrote: On 04/12/2012 11:00 AM, ext Alan Alpert wrote: One thing I don't understand in this discussion is this theme manager concept (like QStyle). ... Why exactly do we need this level of indirection Because of this: import Widgets 1.0 As opposed to this: //import MeeGoWidgets 1.0 //import SymbianWidgets 1.0 import DesktopWidgets 1.0 If there was a standard API defined for a components and each platform provided something that was source-compatible with this API then that would work too (without indirection) but I haven't seen anyone suggesting that a platform's components should adhere to some standard API. I suggest it :) . It's a de-facto standard already if you can simply comment in the appropriate import. People are coming at this from a one source, multiple targets viewpoint, which clashes with QML's one source, one target design. I suspect that people do not want to maintain otherwise virtually-identical .qml files for each target platform just because the components have a different import, or a different name for an element. This doesn't require a theme manager abstraction. It could be handled with a Widgets import that resolves to MeeGoWidget,SymbianWidgets or DesktopWidgets based on runtime platform. (this approach does also require the 'standard API' you mention, but that's still not a theme manager - it requires quite different actions to make it a reality) A theme manager will make the things much more simpler and clear for the user and when it comes to add support for other platforms. Let me try explain more: From user perspective: * AFAIK currently there is no easy way to create a custom theme for QML controls, so if I want to completely change the look of my controls I don't want to rewrite them :) I want to specify simple attributes to the theme manager and it should do the magic for me, something similar with Qt Style Sheets, of course now you'll say that it was too complex and almost nobody use it, I agree that it was complex but something simple must take its place, because I believe that something is better than nothing :) ! From developer perspective who wants to add support for another platform: * I want to do the style job once for both QML and classic widgets, without a theme manager I don't see how it can be done ! * Some platforms have too complex controls to be draw using an existing QML implementation, the live example is Android platform where almost nothing can be used from existing style implementations, not even BorderImage [1] I can't use it because Android has another (IMHO smarter) approach [2], the image contains all the informations you need to draw it properly, it contains padding informations and informations about the margins, even the name says it has 9 patches, is not true, it can contain more than 9 check [3], which is great, because you can draw much more complex controls with it. Probably again you'll complain that it doesn't follow the standard you followed[4]:). Cheers, BogDan. [1] http://doc-snapshot.qt-project.org/4.8/qdrawutil-h.html#qDrawBorderPixmap [2] http://developer.android.com/guide/developing/tools/draw9patch.html [3] http://androidxref.com/source/xref/frameworks/base/include/utils/ResourceTypes.h [4] http://www.w3.org/TR/css3-background/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Steffen Hahn and Johann Specht for Approver status
+1 from my side. Steffen and Johann have significantly contributed to SystemInfo and PS, and I am sure our community will benefit from their skills and their knowledge. I definitely second them to come aboard the Approvers ship :) Br, -Cristiano Cristiano di Flora, PhD SW Architect / Technical lead, Nokia MP - Qt Software development Visiokatu 3 33720, Tampere (FINLAND) On 4/12/12 10:11 AM, ext Kumar-Kuntala Kranthi (Nokia-MS/Tampere) kranthi.kumar-kunt...@nokia.com wrote: Hi, I would like to Nominate Steffen Hahn and Johann Specht for Approver status. Steffen and Johann have been contributing to qtsystems module for quite some time now. Give a look at their dashboards if you want to know what they have been doing: Steffen : http://codereview.qt-project.org/#dashboard,1000219 Johann : http://codereview.qt-project.org/#dashboard,1000233 Best Regards, Kranthi. ___ 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] Qt5 missing features
On Thu, 12 Apr 2012 17:46:21 ext BogDan wrote:
From: Alan Alpert alan.alp...@nokia.com
To: development@qt-project.org
Cc:
Sent: Thursday, April 12, 2012 6:20 AM
Subject: Re: [Development] Qt5 missing features
On Thu, 12 Apr 2012 11:28:43 ext Lincoln Ramsay wrote:
On 04/12/2012 11:00 AM, ext Alan Alpert wrote:
One thing I don't understand in this discussion is this theme
manager
concept (like QStyle).
...
Why exactly do we need this level of indirection
Because of this:
import Widgets 1.0
As opposed to this:
//import MeeGoWidgets 1.0
//import SymbianWidgets 1.0
import DesktopWidgets 1.0
If there was a standard API defined for a
components and each
platform provided something that was source-compatible with this API
then that would work too (without indirection) but I haven't seen
anyone
suggesting that a platform's components should adhere to
some
standard API.
I suggest it :) . It's a de-facto standard already if you can simply
comment
in the appropriate import.
People are coming at this from a one source, multiple targets
viewpoint, which clashes with QML's one source, one target
design. I
suspect that people do not want to maintain otherwise
virtually-identical .qml files for each target platform just because
the components have a different import, or a different name for an
element.
This doesn't require a theme manager abstraction. It could be handled
with a
Widgets import that resolves to MeeGoWidget,SymbianWidgets or
DesktopWidgets based on runtime platform. (this approach does also
require the 'standard API'
you mention, but that's still not a theme manager - it requires quite
different actions to make it a reality)
A theme manager will make the things much more simpler and clear for the
user and when it comes to add support for other platforms.
Let me try explain more:
From user perspective:
* AFAIK currently there is no easy way to create a custom theme for QML
controls, so if I want to completely change the look of my controls I
don't want to rewrite them :) I want to specify simple attributes to the
theme manager and it should do the magic for me, something similar with Qt
Style Sheets, of course now you'll say that it was too complex and almost
nobody use it, I agree that it was complex but something simple must take
its place, because I believe that something is better than nothing :) !
The theory is that, since QML is a UI specification language, rewriting them
in QML is the exact same as specifying simple attributes. It's certainly has
similarities to Qt Style Sheets (but simpler ;) ). Perhaps the 'theme engine'
would be like the custom components in the components labs project, and
platform implementations would look like:
Button {
anchors.margins: 5000
backgroundColor: fuchsia
}
From developer perspective who wants to add support for another platform:
* I want to do the style job once for both QML and classic widgets,
without a theme manager I don't see how it can be done !
I didn't think of this one - good point! I don't see an easy way around this
either :(
* Some platforms have too complex controls to be draw using an existing
QML implementation, the live example is Android platform where almost
nothing can be used from existing style implementations, not even
BorderImage [1] I can't use it because Android has another (IMHO smarter)
approach [2], the image contains all the informations you need to draw it
properly, it contains padding informations and informations about the
margins, even the name says it has 9 patches, is not true, it can contain
more than 9 check [3], which is great, because you can draw much more
complex controls with it.
Probably again you'll complain that it doesn't follow the standard you
followed[4]:).
What's this 'existing QML implementation' thing? The approach to creating a
custom 'button' in QML can be the same as a custom 'button' with QWidget. It's
as easy to subclass QQuickPaintedItem and draw something as it is to subclass
QWidget and draw something.
Keep in mind - that's a custom widget not just re-theming the button. It might
be more involved that the theme manager approach, but it might also be less if
you have to go to C++ to instantiate a native control anyways.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
To help with this I would like to nominate Casper Vandonderen as the maintainer for our documentation. I've already talked to him and he's interested and willing to take the job. This doesn't mean he is responsible for writing or reviewing all the documentation we have, but his role would be to set the direction and quality standards that we should strive for. I'd like to second this nomination, and to re-iterate that we as developers are responsible for the content of our class and module documentation. The doc team's role is primarily to provide us with tools for processing docs, guidelines on good doc practices and style, and pulling together the more global docs such as the overview and what's new pages. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Towards a Qt 5 beta: Documentation
Hi everybody, TL;DR: We need to change the way Qt does documentation. A lot of things will change and we need help from everybody. As mentioned by Lars: We should make sure the quality of the documentation for Qt 5.0 is as high as possible. To get and keep our documentation in shape for Qt 5.0 and beyond I think we will need to tackle the following problems: 1. The documentation is not modularized. 2. The documentation build system is hard to explain to people. (consequence of 1) 3. The different Qt modules have a completely different style of documenting. 4. The QDoc commands and functionality are not known well enough by people, which causes QDoc errors. 5. There is no real review process for documentation contributions. Modularizing the documentation is a process that will move a lot of files around and make some things impossible. The biggest consequence will be that we will have the same dependency chain as when compiling the modules. E.g. not allow circular dependencies in the documentation. Therefore there can be no links from the QtGui documentation to any class in QtWidgets, from QtWidgets to QtGui will work, since Widgets depends on Gui. This will also automatically break Inherited by: between classes in separate modules in the documentation. I have written down a possible method for modularizing the documentation at the end of this email. That should make the whole process more transparent. Issue 3 just needs people to clean up the documentation, writing guidelines to get this standard will be published on the Qt Project Wiki. For issue 4 I would like to point people to http://doc-snapshot.qt-project.org/qdoc/ this is the URL of the qdoc manual. If everybody follows what is written there and reports bugs about inconsistencies in the manual we should have a minimal influx of new qdoc errors. There are problems in qdoc (like not understanding C++ templates/macros and C++11 syntax for documenting QObject::connect), but we should not start putting Doxygen documentation commands in QDoc when there is a QDoc equivalent. I am also aware that we still need to change a lot of old documentation, like replacing all \gui commands with \uicontrol, which is quite a simple search/replace. Issue 5 needs thought and help from everybody. We will keep the normal reviewing process for documentation and we cannot enforce all documentation patches to be reviewed by native English speakers/technical writers. But when documentation changes we should all pay special attention to making it understandable to someone who is new to Qt. This has always been the focus of the Qt documentation and I think we should try to keep the same standard of documentation going forward. -- Modularized documentation proposal Let's use qtbase as an example, since that needs the global content such as CSS and default qdocconfs. - Source code stays where it is now under /src. - Global documentation (such as CSS Files and default qdocconf templates) goes into /doc/global. This will be copied to QT_INSTALL_DOCS/global to be used by the other repositories. modules inside qtbase will use relative links to the /doc/global folder. - Individual modules have their documentation in /src/[conveniencename]/doc. For example: /src/corelib/doc. Documentation .qdoc files will stay under src in that folder, snippets will stay under snippets, etc. - Images will go in /src/[conveniencename]/doc/images, cross-module images will not be allowed (unless you copy them into multiple folders). - The [modulename].qdocconf will be in the top-level directory for the module. For QtCore this means that the qdocconf file will be qtbase/src/corelib/doc/qtcore.qdocconf. - Documentation output will be put in /doc/html/[modulename]. The whole /doc/html/[modulename] folder will be copied to QT_INSTALL_DOCS/[modulename] - For cross-linking we need to do a few things (None of this is implemented yet): 1. We need to add a depends qdocconf variable, where you list the modules you depend on. The easiest thing would be to use the full modulename, so qtcore instead of just core. This means that you put depends += qtcore in the qtgui.qdocconf 2. We could then implement an -indexdir CLI option/variable which points to the directory containing all documentation and let qdoc look for /[modulename]/[modulename].index under that folder, 3. Then we will have to set-up the .pri files to let indexdir point to qtbase/doc/html for the modules in qtbase and QT_INSTALL_DIR/doc for the other modules. So when building qtgui qdoc will be called with qdoc -indexdir doc/html doc/gui/qtgui.qdocconf. This should make it find /doc/html/qtcore/qtcore.index when you put depends += qtcore in the qtgui.qdocconf. 4. A problem will occur when you have other repositories that contain multiple modules. (such as qtpim and qtdeclarative) So there we need to specify 2 -indexdir options, QDoc should check the timestamp when there are 2 conflicting index files and use the newest one. - In
Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString
On quinta-feira, 12 de abril de 2012 08.17.37, kai.koe...@nokia.com wrote: Hi, I'd like to get https://codereview.qt-project.org/#change,22151,patchset=5 into 5.0/api_changes branch. It's one more change to the logging framework, specifically to the signature of QMessageHandler (new in 5.0, old QtMsgHandler is unchanged): void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const char *); becomes void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const QString ); Maybe QChar *begin, int len? Or QChar *begin, guaranteed to be NUL-terminated? The reason is to avoid unnecessary string conversions, especially on Windows. E.g. qDebug() Hello World; will right now result in const char * - QString conversion in QDebug::operator(const char *) (QString::fromAscii(), shouldn't this be QString::fromLatin1() btw?) fromAscii() was correct in the sense of from whatever the user used in developing source code. QString - const char * conversion in QDebug::~QDebug() (QString::toLocal8Bit()) const char *- QByteArray conversion in qMessageFormatString() for the default message handler a QByteArray - QString conversion in qWinMessageHandler() (QString::fromLocal8Bit) So we're converting from latin1 to utf16 to local8bit to utf16 :) The patch mitigates this somewhat by passing const QString as argument to the message handler, instead of const char *. I support this. The message handler is new API and this change is not changing compatibility with Qt 4. I assume you will do a final UTF16-to-local8bit if the user installed a legacy 8-bit message handler. Note that QtDeclarative right now installs a message handler with the const char * signature. That means if the patch is accepted, we'd need to synchronize the qtbase with a qtdeclarative update. You can keep a temporary compatibility code in QtCore for the time being, with both signatures, and apply the conversion. Once qtdeclarative moves over, you can remove the old one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Towards a Qt 5 beta: Documentation
Op 12-4-2012 15:12, casper.vandonde...@nokia.com schreef: Modularizing the documentation is a process that will move a lot of files around and make some things impossible. The biggest consequence will be that we will have the same dependency chain as when compiling the modules. E.g. not allow circular dependencies in the documentation. Therefore there can be no links from the QtGui documentation to any class in QtWidgets, from QtWidgets to QtGui will work, since Widgets depends on Gui. This will also automatically break Inherited by: between classes in separate modules in the documentation. While I understand the reasoning, I am not sure the limitations above are acceptable. At least, if I understand you correctly. I think that loosing all the cross links and all the inherited-by links that span modules is unaceptable. For instance, you would no longer be able to see relations between some major classes, like QObject - QWidget. You'd only be able to see QWidget - QObject. These kinds of links are not something that does not happen. The QObject docs are a good example of that, as they actually reference QWidget. Personally, I also regulary use the Inherited by list. I would hate to see that go. I don't have a solution ready though. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On Thursday 12 April 2012 15:35:45 André Somers wrote: Op 12-4-2012 15:12, casper.vandonde...@nokia.com schreef: Modularizing the documentation is a process that will move a lot of files around and make some things impossible. The biggest consequence will be that we will have the same dependency chain as when compiling the modules. E.g. not allow circular dependencies in the documentation. Therefore there can be no links from the QtGui documentation to any class in QtWidgets, from QtWidgets to QtGui will work, since Widgets depends on Gui. This will also automatically break Inherited by: between classes in separate modules in the documentation. While I understand the reasoning, I am not sure the limitations above are acceptable. At least, if I understand you correctly. I think that loosing all the cross links and all the inherited-by links that span modules is unaceptable. For instance, you would no longer be able to see relations between some major classes, like QObject - QWidget. You'd only be able to see QWidget - QObject. These kinds of links are not something that does not happen. The QObject docs are a good example of that, as they actually reference QWidget. Personally, I also regulary use the Inherited by list. I would hate to see that go. I don't have a solution ready though. I also don't like it. What is the benefit of doing that? what went wrong with make docs? Also, you seem to use the Module terminology to refer to library (QtCore, QtGui, ...) within qtbase. But some other people may refer to Module for the repositoies (qtbase, qtdeclarative, qtscript, ...). This is a bit confusing, please clarify. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
On Wednesday, April 11, 2012 23:03:51 Robin Burchell wrote: On Wed, Apr 11, 2012 at 2:49 PM, lars.kn...@nokia.com wrote: We are now done with new feature development and changes to our API. I will merge the api_changes branch that contains the remaining changes to our api back to master by the end of this week, and close the branch after that. I wonder: you imply that breaking binary compatibility in a controlled way (by controlling when we stage) is fine - but then why not keep the branch open for exactly that, and have those controlled merges 1-2 times a week, and not impede staging? People who need compile stability can use master (and rebuild once a week), people who don't mind rebuilding every pull can stick with api_changes, I mean. I was actually initially a bit sceptical, but I don't think it's worked all that badly as a model, aside from the extended period without a merge due to the alpha... I think it didn't work well. I'd like to see another model attempted next time, like all commits going to master, and a 'stable' branch which gets fast forwarded once a week - no chance of CI failures, no question of which branch to commit to, and when an alpha needs to be created, a alpha branch can be created, instead of attempting to create it from a still fast-moving master (sort of) with more CI breakage. I'm sure that model won't work 100% for every case either, but if we don't try it, we'll never know for sure. Just for your consideration. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] Proposed API change: Change signature of QMessageHandler to use QString
-Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Thiago Macieira Sent: Thursday, April 12, 2012 3:14 PM To: development@qt-project.org Subject: Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString On quinta-feira, 12 de abril de 2012 08.17.37, kai.koe...@nokia.com wrote: Hi, I'd like to get https://codereview.qt-project.org/#change,22151,patchset=5 into 5.0/api_changes branch. It's one more change to the logging framework, specifically to the signature of QMessageHandler (new in 5.0, old QtMsgHandler is unchanged): void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const char *); becomes void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const QString ); Maybe QChar *begin, int len? Or QChar *begin, guaranteed to be NUL-terminated? What's the advantage of having a QChar * in contrast to a QString? The reason is to avoid unnecessary string conversions, especially on Windows. E.g. qDebug() Hello World; will right now result in const char * - QString conversion in QDebug::operator(const char *) (QString::fromAscii(), shouldn't this be QString::fromLatin1() btw?) fromAscii() was correct in the sense of from whatever the user used in developing source code. Just realized that nowadays fromAscii==fromLatin1. So it's really just a matter of taste. QString - const char * conversion in QDebug::~QDebug() (QString::toLocal8Bit()) const char *- QByteArray conversion in qMessageFormatString() for the default message handler a QByteArray - QString conversion in qWinMessageHandler() (QString::fromLocal8Bit) So we're converting from latin1 to utf16 to local8bit to utf16 :) The patch mitigates this somewhat by passing const QString as argument to the message handler, instead of const char *. I support this. The message handler is new API and this change is not changing compatibility with Qt 4. I assume you will do a final UTF16-to-local8bit if the user installed a legacy 8- bit message handler. Yes, that's already part of the patch. [...] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.0 alpha released
Hi, just wanted to share some download stats with you guys: 10668 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.7z 1 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.7z?51580699043405175974186249732156 93 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.7z 2436 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.bz2 1616 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.gz 796 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.xz 6084 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.zip Since the first two and the last in this list indicate Windows downloads (due to the CRLF EOL, unless people use 'unzip -a'), we get a guesstimate of 16753 Windows downloads 4941 Linux/OSX downloads ~3.4x more Windows downloads than Linux and Mac OSX combined. Not hard facts, but still interesting. -- .marius From: development-bounces+marius.storm-olsen=nokia@qt-project.org [mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Tuesday, April 03, 2012 10:01 AM To: annou...@qt-project.org Cc: development@qt-project.org; releas...@qt-project.org; inter...@qt-project.org Subject: [Development] Qt 5.0 alpha released Hi, We are happy to announce the Qt 5.0 alpha release. This is the first major Qt release since the Qt Project went live, and a large amount of work and features have gone into this release. Blog post: http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/ Download page: http://qt-project.org/wiki/Qt-5-Alpha Thanks a lot for all the contributions and feedback, and thanks to all the people who made this happen! The Qt Project -- Marius Storm-Olsen Head of Qt OSS Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
On Thu, Apr 12, 2012 at 04:26:12PM +0200, ext Stephen Kelly wrote: I'd like to see another model attempted next time, like all commits going to master, and a 'stable' branch which gets fast forwarded once a week that's besides the point. people must work on the bleeding edge. bic/sic changes just don't fare well with downstream (whichever definition of that you apply), so they are diverted into a separate branch. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 missing features
snip, theme GUI interfaces for QML A theme manager will make the things much more simpler and clear for the user and when it comes to add support for other platforms. snip, Let me try explain more: From user perspective: snip, want to re-use controls with different themes From developer perspective who wants to add support for another platform snip, re-using controls on new platforms I want to specify simple attributes to the theme manager and it should do the magic for me, something similar with Qt Style Sheets, of course now you'll say that it was too complex and almost nobody use it, I agree that it was complex but something simple must take its place, because I believe that something is better than nothing :) ! _This_. We have the same code on touch-interfaces and desktop. We need this. We're using Qt Style Sheets, and they work ok. (Could be more elegant, but is good enough, and it *works*.) IMHO, it seems like this theming and styling thing should be so much *easier* with QML. But, I'm not seeing approaches (yet) on these lists that will work for us. This is not a complaint: The QML declarative paradigm is new, and we must think about these theme-issues in a new paradigm. (This is a very positive thing, IMHO.) But, my point: We need *ANY* theme/style-convention that *WORKS*. I explored many designs in the way-way-way past, and they all worked to varying degrees of success (so we have lots of options): http://lists.qt.nokia.com/pipermail/qt-qml/2010-November/001772.html Summary: We (internally) are pursuing theming-and-styling through centralized convention with our QML components. Because we must enforce these types of conventions ourselves, things like the QML desktop widgets don't exactly work for us, because they don't follow our theme-conventions. (Recall that *by-definition*, themes/styles work *only* because components follow a convention.) And, we've not fully established what *should* be these conventions (they are in flux), but we *know* we *need* these conventions. So, for us, if it can't be themed, we won't/can't use it. Period. YMMV, I'm not-at-all disagreeing with other approaches, and understand why graphic designers are writing custom QML components for their own purposes, without centralized options for themes/styles. That's not us, though: Even for our highly-custom applications, we *demand* a single location to maintain the default-font-color for the application. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
While I understand the reasoning, I am not sure the limitations above are acceptable. At least, if I understand you correctly. I think that loosing all the cross links and all the inherited-by links that span modules is unaceptable. For instance, you would no longer be able to see relations between some major classes, like QObject - QWidget. You'd only be able to see QWidget - QObject. These kinds of links are not something that does not happen. The QObject docs are a good example of that, as they actually reference QWidget. Personally, I also regulary use the Inherited by list. I would hate to see that go. I don't have a solution ready though. I also don't like it. What is the benefit of doing that? what went wrong with make docs? There are 2 main problems with the current system: 1. Nobody was running make docs on their local machines (and verifying the output). There are qdoc errors that were put in by developers last December. Having the documentation modularized will at some point (hopefully soon) allow us to put documentation generation in the CI system. This would allow us to catch patches causing qdoc errors. 2. It was/is completely unclear how the system works, there hasn't been any QML documentation at http://doc-snapshot.qt-project.org/5.0/ for multiple weeks now (I believe 4, maybe more). Also, you seem to use the Module terminology to refer to library (QtCore, QtGui, ...) within qtbase. But some other people may refer to Module for the repositoies (qtbase, qtdeclarative, qtscript, ...). This is a bit confusing, please clarify. The term module in documentation equals library. There is no concept of repositories for the documentation. I went for what we use in qdoc (\module and \qmlmodule), sorry if that was unclear. Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On Thursday 12 April 2012 16:30:39 casper.vandonde...@nokia.com wrote: While I understand the reasoning, I am not sure the limitations above are acceptable. At least, if I understand you correctly. I think that loosing all the cross links and all the inherited-by links that span modules is unaceptable. For instance, you would no longer be able to see relations between some major classes, like QObject - QWidget. You'd only be able to see QWidget - QObject. These kinds of links are not something that does not happen. The QObject docs are a good example of that, as they actually reference QWidget. Personally, I also regulary use the Inherited by list. I would hate to see that go. I don't have a solution ready though. I also don't like it. What is the benefit of doing that? what went wrong with make docs? There are 2 main problems with the current system: 1. Nobody was running make docs on their local machines (and verifying the output). There are qdoc errors that were put in by developers last December. Having the documentation modularized will at some point (hopefully soon) allow us to put documentation generation in the CI system. This would allow us to catch patches causing qdoc errors. 2. It was/is completely unclear how the system works, there hasn't been any QML documentation at http://doc-snapshot.qt-project.org/5.0/ for multiple weeks now (I believe 4, maybe more). But none of those problem will be fixed by modularizing the docs by libraries. Or am i missing something? (putting make docs in the CI is a good idea) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
There are 2 main problems with the current system: 1. Nobody was running make docs on their local machines (and verifying the output). There are qdoc errors that were put in by developers last December. Having the documentation modularized will at some point (hopefully soon) allow us to put documentation generation in the CI system. This would allow us to catch patches causing qdoc errors. 2. It was/is completely unclear how the system works, there hasn't been any QML documentation at http://doc-snapshot.qt-project.org/5.0/ for multiple weeks now (I believe 4, maybe more). But none of those problem will be fixed by modularizing the docs by libraries. Or am i missing something? (putting make docs in the CI is a good idea) The CI system the documentation will be built per repository, that is true, but there might be users who only want to build a specific set of libraries with documentation and the extra step of granularity will not make a difference (in my opinion), since the only difference would be a few extra qdocconf files and make targets. I also think that adding the documentation build closer to the source build (we could add the make corelib-docs target to corelib.pro) will make the whole system more transparent and (psychologically) easier to use. Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString
2012/4/12 Thiago Macieira thiago.macie...@intel.com: Not for long. I still need to change fromAscii to be fromUtf8. Provided it doesn't break too much. I'm happy to help fix test failures (of which I am sure there will be a fair few) once there's something to work with. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On 04/12/2012 06:12 AM, ext casper.vandonde...@nokia.com wrote: To get and keep our documentation in shape for Qt 5.0 and beyond I think we will need to tackle the following problems: 1. The documentation is not modularized. 2. The documentation build system is hard to explain to people. (consequence of 1) 3. The different Qt modules have a completely different style of documenting. 4. The QDoc commands and functionality are not known well enough by people, which causes QDoc errors. 5. There is no real review process for documentation contributions. There are other tasks that seems to be missing. - What is documentation? Are we talking only about the API docs or also about code examples, tutorials, demo videos? - Who are the contributors working specifically in the deliverables described above, and who is the overall responsible? Now it feels that a lot of responsibilities fall between the cracks. That was ok-ish for the pre-alpha phase but now we need more organization. - What are the deliverables for the beta release? Documentation wasn't a showstopper for an alpha release but certain documentation criteria need to be met for the beta. What are those criteria? -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
On 4/12/12 3:39 PM, ext Girish Ramakrishnan gir...@forwardbias.in wrote: Hi Lars, On Wed, Apr 11, 2012 at 5:49 AM, lars.kn...@nokia.com wrote: Hi everybody, hope many of you had the chance to take some time off over easter. I certainly did. Now that the alpha is out, there's work we need to do to get things in shape for a beta. We are now done with new feature development and changes to our API. I will merge the api_changes branch that contains the remaining changes to our api back to master by the end of this week, and close the branch after that. Are you ok with minor API edits? Because of our massive move to QPA, I keep finding left over code which has seeped into public API. Is it ok to fix them? For example, https://codereview.qt-project.org/#change,22695 https://codereview.qt-project.org/#change,22978 https://codereview.qt-project.org/#change,22977 Absolutely, these are still fine. I can take up the role of just double checking all our new public apis, if you like. Please do. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On 4/12/12 7:27 PM, ext casper.vandonde...@nokia.com casper.vandonde...@nokia.com wrote: There are 2 main problems with the current system: 1. Nobody was running make docs on their local machines (and verifying the output). There are qdoc errors that were put in by developers last December. Having the documentation modularized will at some point (hopefully soon) allow us to put documentation generation in the CI system. This would allow us to catch patches causing qdoc errors. 2. It was/is completely unclear how the system works, there hasn't been any QML documentation at http://doc-snapshot.qt-project.org/5.0/ for multiple weeks now (I believe 4, maybe more). But none of those problem will be fixed by modularizing the docs by libraries. Or am i missing something? (putting make docs in the CI is a good idea) The CI system the documentation will be built per repository, that is true, but there might be users who only want to build a specific set of libraries with documentation and the extra step of granularity will not make a difference (in my opinion), since the only difference would be a few extra qdocconf files and make targets. In addition, this is a good practice. We might later on split out certain parts from the qtbase repo, and I want this to be possible. The second side is that users should *not* be exposed to our repo structure. If we have uplinks one place people expect them to work everywhere. But that's completely incompatible with a modular structure, where one can add and remove libraries from the SDK (something we need to aim for in the longer term). I can't see a way how you could possibly have a complete list of classes inheriting e.g. QObject in such a modular world. And I don't think it's desirable neither. I also think that adding the documentation build closer to the source build (we could add the make corelib-docs target to corelib.pro) will make the whole system more transparent and (psychologically) easier to use. Or simple 'cd src/corelib; make docs' ;-) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
2012/4/12 Stephen Kelly stephen.ke...@kdab.com: I think it didn't work well. While I'm not you, and you didn't really extrapolate on why you think that, I do agree that it certainly wasn't perfect - but the times when it wasn't perfect it was mostly things that either don't apply anymore or can be improved on without fundamental changes to the model - human error (submitting to master when it should not be there, even if pre-approved, I'm guilty here *ahem*) causing breakages - actual api changes (shouldn't be as big an issue anymore) causing breakages/delays in merging back - vast delays in merge due to release (this is a very valid problem, but we should _not_ have been trying to release off master when it is moving so fast, *that* should have been branched off of master, fixes pushed to the release branch, and then have it merged back to master once the release is made - if we avoid trying to release off master again, then we have no reason to not have frequent merges (within reason), and there is no problem here anymore ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
On 04/11/2012 05:49 AM, ext lars.kn...@nokia.com wrote: To help with this I would like to nominate Casper Vandonderen as the maintainer for our documentation. Great! Jason has been leading Qt (and Qtopia) releases a couple of times in the past within both Trolltech and Nokia. He will be helping us to get the release out with a focus esp. on quality. Super! I would like to coordinate better with both of you in order to have a great beta release. I have already asked in the Documentation thread about the deliverables expected for the beta. Getting a quality assessment on the release materials themselves would be useful too. The initial idea on the beta release notes is to branch http://qt-project.org/wiki/Qt-5-Alpha , improve the current text and highlight the novelties between alpha and beta in the first paragraphs and a promoted What's New section. I also think that most of the brain and flesh put in Lars' blog should go the release materials themselves, becoming the center point and reference URL for everybody. In the alpha there was a lot of overlap between Lars' post and the release notes, and actually Lars' blog had more details. The problem is, a blog post fades over time. A side problem was that such blog post was hosted at labs.qt.nokia.com got us many reviews starting with Nokia's Qt Labs has released Qt 5.0 Alpha... -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Summit 2012 Registration is now open!
On 04/11/2012 02:23 PM, ext André Pönitz wrote: On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote: Just to be clear: Nokia employees follow the same registration process, like anybody else. Organizers too. Lars too. Me too. Everybody. If you say so... http://qt-project.org/groups/qt-contributors-summit-2012/wiki There will be at least one person who is not even remotely amused about the prospect to have to enter personal data into some random document hosted at some third party site. Interesting. Can I ask what is your concern? Every time someone registers to some third party event s/he uses some third party site. This is no exception. Last year a 3rd party service was used as well afair. The alternative would have been to use something within http://qt-project.org - but what? We didn't want to bring more work to Marius co installing services and we actually are reusing as much as Qt DevNet as possible, The personal data requested is mostly public anyway? Also, if you send it to me via email guess what I will do: store it in the same online spreadsheet since that is the space used by the organizers and all badges are printed from there. And the random document has been defined from scratch and reviewed extensively at the Qt Project [Marketing] mailing list. -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt summit 2012 schedule structure
On 04/11/2012 11:14 AM, ext Sivan Greenberg wrote: Thoughts, suggestions corrections (this is mostly my 2c from last year's experience, the track names are solely for demonstration) ? One aspect to consider: we will have video recording in the main room but not in the rest of the rooms. Perhaps we want to have curated sessions there, and leave all the rest for unconference setup. -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString
Before I would do such a change I would check if there are other projects in QT they install their own messaghandler. I think they all need to change their code as well. Maybe we should keep it as it is. Cheers, WB -Original Message- From: development-bounces+wolfgang.beck=nokia@qt-project.org [mailto:development-bounces+wolfgang.beck=nokia@qt-project.org] On Behalf Of Koehne Kai (Nokia-MP/Berlin) Sent: Friday, April 13, 2012 12:41 AM To: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Thiago Macieira Sent: Thursday, April 12, 2012 3:14 PM To: development@qt-project.org Subject: Re: [Development] Proposed API change: Change signature of QMessageHandler to use QString On quinta-feira, 12 de abril de 2012 08.17.37, kai.koe...@nokia.com wrote: Hi, I'd like to get https://codereview.qt-project.org/#change,22151,patchset=5 into 5.0/api_changes branch. It's one more change to the logging framework, specifically to the signature of QMessageHandler (new in 5.0, old QtMsgHandler is unchanged): void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const char *); becomes void (*QMessageHandler)(QtMsgType, const QMessageLogContext , const QString ); Maybe QChar *begin, int len? Or QChar *begin, guaranteed to be NUL-terminated? What's the advantage of having a QChar * in contrast to a QString? The reason is to avoid unnecessary string conversions, especially on Windows. E.g. qDebug() Hello World; will right now result in const char * - QString conversion in QDebug::operator(const char *) (QString::fromAscii(), shouldn't this be QString::fromLatin1() btw?) fromAscii() was correct in the sense of from whatever the user used in developing source code. Just realized that nowadays fromAscii==fromLatin1. So it's really just a matter of taste. QString - const char * conversion in QDebug::~QDebug() (QString::toLocal8Bit()) const char *- QByteArray conversion in qMessageFormatString() for the default message handler a QByteArray - QString conversion in qWinMessageHandler() (QString::fromLocal8Bit) So we're converting from latin1 to utf16 to local8bit to utf16 :) The patch mitigates this somewhat by passing const QString as argument to the message handler, instead of const char *. I support this. The message handler is new API and this change is not changing compatibility with Qt 4. I assume you will do a final UTF16-to-local8bit if the user installed a legacy 8- bit message handler. Yes, that's already part of the patch. [...] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ 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] Qt Summit 2012 Registration is now open!
On Thu, Apr 12, 2012 at 02:44:36PM -0700, Quim Gil wrote: On 04/11/2012 02:23 PM, ext André Pönitz wrote: On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote: Just to be clear: Nokia employees follow the same registration process, like anybody else. Organizers too. Lars too. Me too. Everybody. If you say so... http://qt-project.org/groups/qt-contributors-summit-2012/wiki There will be at least one person who is not even remotely amused about the prospect to have to enter personal data into some random document hosted at some third party site. Interesting. Can I ask what is your concern? Every time someone registers to some third party event s/he uses some third party site. There seems to be a misunderstanding concerning the term third party here. In that what I consider a usual registration process _two_ parties are involved: A person who wants to attend an event, and the host of the event. The host typically promises to use the attendee's personal data only for the purpose of the event, to not pass it on to third parties etc, and the attendee typically trusts the host of the event to stick to the promise. The registration setup you choose for the summit involves a third party as man in the middle which neither the host nor the attendee has any business with, let alone controls in any way. On the contrary, by using the services of said third party one agrees to their terms and conditions, put into writing in several pages of legalese, not all of it harmless to the uninitiated on first sight. This is no exception. Last year a 3rd party service was used as well afair. I don't really remember filling in a form hosted at google. But I admit that doesn't mean much. The alternative would have been to use something within http://qt-project.org - but what? We didn't want to bring more work to Marius co installing services and we actually are reusing as much as Qt DevNet as possible, The alternatives range from a hand crafted web page on qt-project.org to using plain email and manual transfer into a database. Total effort for a 200 person event in both cases less than a day. And I'd rather volunteer to key in the data personally instead of spending the time discussing basic privacy concerns. The personal data requested is mostly public anyway? [mostly perhaps. But even if so, it would not matter in this particular context. Availability does not imply the right to use it without consent, at least not over here.] Also, if you send it to me via email guess what I will do: store it in the same online spreadsheet [...] I would feel more comfortable if you could at least try to pretend that a Qt Project community manager acknowledges the existence of the concept of privacy, and does not feed personal data of members of the community into _anything_ outside the reach of the Qt Project without the consent of the person concerned. [...] since that is the space used by the organizers and all badges are printed from there. I can take care of a badge. No worries ;-) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Summit 2012 Registration is now open!
Quim, I agree with André on this one. Google's terms and policies are quite complicated, and it's not right for the Qt Project to force anyone to abide by their terms. We need to stop using their spreadsheet and find other ways to organize the information you need to keep tabs on the Contributor Summit. A simple highlight of one of the terms for Google Docs (underline, bolding and eliding by me) from http://www.google.com/intl/en/policies/terms/ @ 2012-04-12 20:30: When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (...), communicate, publish, publicly perform, publicly display and distribute such content. -- .marius -Original Message- From: development-bounces+marius.storm-olsen=nokia.com@qt- project.org [mailto:development-bounces+marius.storm- olsen=nokia@qt-project.org] On Behalf Of ext André Pönitz Sent: Thursday, April 12, 2012 7:34 PM To: Gil Quim (Nokia-DXM/SiliconValley) Cc: development@qt-project.org Subject: Re: [Development] Qt Summit 2012 Registration is now open! On Thu, Apr 12, 2012 at 02:44:36PM -0700, Quim Gil wrote: On 04/11/2012 02:23 PM, ext André Pönitz wrote: On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote: Just to be clear: Nokia employees follow the same registration process, like anybody else. Organizers too. Lars too. Me too. Everybody. If you say so... http://qt-project.org/groups/qt-contributors-summit-2012/wiki There will be at least one person who is not even remotely amused about the prospect to have to enter personal data into some random document hosted at some third party site. Interesting. Can I ask what is your concern? Every time someone registers to some third party event s/he uses some third party site. There seems to be a misunderstanding concerning the term third party here. In that what I consider a usual registration process _two_ parties are involved: A person who wants to attend an event, and the host of the event. The host typically promises to use the attendee's personal data only for the purpose of the event, to not pass it on to third parties etc, and the attendee typically trusts the host of the event to stick to the promise. The registration setup you choose for the summit involves a third party as man in the middle which neither the host nor the attendee has any business with, let alone controls in any way. On the contrary, by using the services of said third party one agrees to their terms and conditions, put into writing in several pages of legalese, not all of it harmless to the uninitiated on first sight. This is no exception. Last year a 3rd party service was used as well afair. I don't really remember filling in a form hosted at google. But I admit that doesn't mean much. The alternative would have been to use something within http://qt-project.org - but what? We didn't want to bring more work to Marius co installing services and we actually are reusing as much as Qt DevNet as possible, The alternatives range from a hand crafted web page on qt-project.org to using plain email and manual transfer into a database. Total effort for a 200 person event in both cases less than a day. And I'd rather volunteer to key in the data personally instead of spending the time discussing basic privacy concerns. The personal data requested is mostly public anyway? [mostly perhaps. But even if so, it would not matter in this particular context. Availability does not imply the right to use it without consent, at least not over here.] Also, if you send it to me via email guess what I will do: store it in the same online spreadsheet [...] I would feel more comfortable if you could at least try to pretend that a Qt Project community manager acknowledges the existence of the concept of privacy, and does not feed personal data of members of the community into _anything_ outside the reach of the Qt Project without the consent of the person concerned. [...] since that is the space used by the organizers and all badges are printed from there. I can take care of a badge. No worries ;-) Andre' ___ Development mailing list Development@qt-project.orgmailto: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] Qt Summit 2012 Registration is now open!
Ok. The system we have now was discussed and agreed in the [Marketing] list in a thread that lasted several days followed by a wait of more days until the Alpha was released. It's a system that works, takes little time to manage and is allowing us to get mew participants registered as we speaks. Who can work on a better system? Please, go ahead and we will adopt it. In the meantime I will handle manually and locally those participants not willing to submit their data. In the meantime I'm for keeping the current registration open. I understand the theoretical concern but for this case and for the low sensitiveness of the data being gathered (mostly public) I don't see the point of stopping the registration process before having a replacement. Is that ok? -- Quim On 4/12/12 6:39 PM Storm-Olsen Marius (Nokia-MP/Austin) wrote: Quim, I agree with André on this one. Google's terms and policies are quite complicated, and it's not right for the Qt Project to force anyone to abide by their terms. We need to stop using their spreadsheet and find other ways to organize the information you need to keep tabs on the Contributor Summit. A simple highlight of one of the terms for Google Docs (underline, bolding and eliding by me) from http://www.google.com/intl/en/policies/terms/ @ 2012-04-12 20:30: “When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (…), communicate, publish, publicly perform, publicly display and distribute such content.” -- .marius -Original Message- From: development-bounces+marius.storm-olsen=nokia.com@qt- project.org [mailto:development-bounces+marius.storm- olsen=nokia@qt-project.org] On Behalf Of ext André Pönitz Sent: Thursday, April 12, 2012 7:34 PM To: Gil Quim (Nokia-DXM/SiliconValley) Cc: development@qt-project.org Subject: Re: [Development] Qt Summit 2012 Registration is now open! On Thu, Apr 12, 2012 at 02:44:36PM -0700, Quim Gil wrote: On 04/11/2012 02:23 PM, ext André Pönitz wrote: On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote: Just to be clear: Nokia employees follow the same registration process, like anybody else. Organizers too. Lars too. Me too. Everybody. If you say so... http://qt-project.org/groups/qt-contributors-summit-2012/wiki There will be at least one person who is not even remotely amused about the prospect to have to enter personal data into some random document hosted at some third party site. Interesting. Can I ask what is your concern? Every time someone registers to some third party event s/he uses some third party site. There seems to be a misunderstanding concerning the term third party here. In that what I consider a usual registration process _two_ parties are involved: A person who wants to attend an event, and the host of the event. The host typically promises to use the attendee's personal data only for the purpose of the event, to not pass it on to third parties etc, and the attendee typically trusts the host of the event to stick to the promise. The registration setup you choose for the summit involves a third party as man in the middle which neither the host nor the attendee has any business with, let alone controls in any way. On the contrary, by using the services of said third party one agrees to their terms and conditions, put into writing in several pages of legalese, not all of it harmless to the uninitiated on first sight. This is no exception. Last year a 3rd party service was used as well afair. I don't really remember filling in a form hosted at google. But I admit that doesn't mean much. The alternative would have been to use something within http://qt-project.org - but what? We didn't want to bring more work to Marius co installing services and we actually are reusing as much as Qt DevNet as possible, The alternatives range from a hand crafted web page on qt-project.org to using plain email and manual transfer into a database. Total effort for a 200 person event in both cases less than a day. And I'd rather volunteer to key in the data personally instead of spending the time discussing basic privacy concerns. The personal data requested is mostly public anyway? [mostly perhaps. But even if so, it would not matter in this particular context. Availability does not imply the right to use it without consent, at least not over here.] Also, if you send it to me via email guess what I will do: store it in the same online spreadsheet [...] I would feel more comfortable if you could at least try to pretend that a Qt Project community manager acknowledges the existence of the concept of privacy, and does not feed personal data of members of the community into _anything_ outside the
Re: [Development] Qt Summit 2012 Registration is now open!
Alright, forget all this. Let me arrive at home and change the wiki page. I will start by asking people to send me an email with those fields. Any improvement from that lowest point is welcome. Quim On 4/12/12 6:50 PM Gil Quim (Nokia-DXM/SiliconValley) wrote: Ok. The system we have now was discussed and agreed in the [Marketing] list in a thread that lasted several days followed by a wait of more days until the Alpha was released. It's a system that works, takes little time to manage and is allowing us to get mew participants registered as we speaks. Who can work on a better system? Please, go ahead and we will adopt it. In the meantime I will handle manually and locally those participants not willing to submit their data. In the meantime I'm for keeping the current registration open. I understand the theoretical concern but for this case and for the low sensitiveness of the data being gathered (mostly public) I don't see the point of stopping the registration process before having a replacement. Is that ok? -- Quim On 4/12/12 6:39 PM Storm-Olsen Marius (Nokia-MP/Austin) wrote: Quim, I agree with André on this one. Google's terms and policies are quite complicated, and it's not right for the Qt Project to force anyone to abide by their terms. We need to stop using their spreadsheet and find other ways to organize the information you need to keep tabs on the Contributor Summit. A simple highlight of one of the terms for Google Docs (underline, bolding and eliding by me) from http://www.google.com/intl/en/policies/terms/ @ 2012-04-12 20:30: “When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (…), communicate, publish, publicly perform, publicly display and distribute such content.” -- .marius -Original Message- From: development-bounces+marius.storm-olsen=nokia.com@qt- project.org [mailto:development-bounces+marius.storm- olsen=nokia@qt-project.org] On Behalf Of ext André Pönitz Sent: Thursday, April 12, 2012 7:34 PM To: Gil Quim (Nokia-DXM/SiliconValley) Cc: development@qt-project.org Subject: Re: [Development] Qt Summit 2012 Registration is now open! On Thu, Apr 12, 2012 at 02:44:36PM -0700, Quim Gil wrote: On 04/11/2012 02:23 PM, ext André Pönitz wrote: On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote: Just to be clear: Nokia employees follow the same registration process, like anybody else. Organizers too. Lars too. Me too. Everybody. If you say so... http://qt-project.org/groups/qt-contributors-summit-2012/wiki There will be at least one person who is not even remotely amused about the prospect to have to enter personal data into some random document hosted at some third party site. Interesting. Can I ask what is your concern? Every time someone registers to some third party event s/he uses some third party site. There seems to be a misunderstanding concerning the term third party here. In that what I consider a usual registration process _two_ parties are involved: A person who wants to attend an event, and the host of the event. The host typically promises to use the attendee's personal data only for the purpose of the event, to not pass it on to third parties etc, and the attendee typically trusts the host of the event to stick to the promise. The registration setup you choose for the summit involves a third party as man in the middle which neither the host nor the attendee has any business with, let alone controls in any way. On the contrary, by using the services of said third party one agrees to their terms and conditions, put into writing in several pages of legalese, not all of it harmless to the uninitiated on first sight. This is no exception. Last year a 3rd party service was used as well afair. I don't really remember filling in a form hosted at google. But I admit that doesn't mean much. The alternative would have been to use something within http://qt-project.org - but what? We didn't want to bring more work to Marius co installing services and we actually are reusing as much as Qt DevNet as possible, The alternatives range from a hand crafted web page on qt-project.org to using plain email and manual transfer into a database. Total effort for a 200 person event in both cases less than a day. And I'd rather volunteer to key in the data personally instead of spending the time discussing basic privacy concerns. The personal data requested is mostly public anyway? [mostly perhaps. But even if so, it would not matter in this particular context. Availability does not imply the right to use it without consent, at least not over here.] Also, if you send it to me via email guess what I will do: store it in the same online
Re: [Development] Towards a Qt 5 beta: Documentation
Hi. In general I applaud this effort. I'm going to talk about some of the doc things Qtopia had. Most of this came from our (infamous for being unmaintainable) mkdocs script. Given the reputation that script had I'm not about to suggest we implement things similarly in Qt but perhaps the ideas are worth something. In an effort to stop people from ignoring doc errors (by not building docs), we developed a system that automatically built the docs for a given directory when running make there. It was very quick (compared to building all docs) though its output wasn't very useful but we only cared about the errors anyway. QtSensors (and I guess other Qt modules) already have a similar-ish system in place where they can build their docs separately from the rest of Qt. Again, the result isn't very useful compared to a full doc build but it's very fast and great for reviewing doc changes as they're happening (though it's not automatic). We had cross-module links in both directions. We achieved this by running qdoc twice per module. Once to get the .index (used for resolving links) and again to build with the other modules' .index files. The only way to avoid doing things twice would be to have more intermediate steps in the doc building process (ie. generate indexes, etc for everything then bring those together into a final product and resolve all the links then). - For cross-linking we need to do a few things (None of this is implemented yet): 1. We need to add a depends qdocconf variable, where you list the modules you depend on. Why?! We already have our dependencies stated in the sync.profile and module .pro files. Duplicating this information just causes a maintenance burden. Allowing explicit dependencies on docs (where there is no dependency between modules) may make sense but dependencies derived from the build should be extracted from the build. -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
Hi, We had cross-module links in both directions. We achieved this by running qdoc twice per module. Once to get the .index (used for resolving links) and again to build with the other modules' .index files. The only way to avoid doing things twice would be to have more intermediate steps in the doc building process (ie. generate indexes, etc for everything then bring those together into a final product and resolve all the links then). I have been thinking about this problem for some time, and while it is technically possible from a qdoc side to implement the whole system like this: I don't see the CI system handling anything like this, what we could do is have a previous run of all the index files somewhere for the CI system to find, but that would theoretically open up the possibilty that I remove a documentation \class from QtCore, but it will still be found in the index. The missing file will only show up when you run qhelpgenerator to generate the QCH files. And I haven't even talked about the qhelpgenerator/QCH process yet, because that thing is still in qttools and can therefore not be run in the CI for qtbase. - For cross-linking we need to do a few things (None of this is implemented yet): 1. We need to add a depends qdocconf variable, where you list the modules you depend on. Why?! We already have our dependencies stated in the sync.profile and module .pro files. Duplicating this information just causes a maintenance burden. Allowing explicit dependencies on docs (where there is no dependency between modules) may make sense but dependencies derived from the build should be extracted from the build. Adding this information extra in the qdocconf file will not be that harmful I think because we don't change the dependency tree that often anymore. But I would be grateful if you would make a plan on how to turn qdoc into a mini-qmake so that qdoc can parse the .pro/sync.profile, so that we don't need the depends. Because that would probably also mean that you have to run qdoc [module.pro] [module.qdocconf], or do you see that differently? Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta: Documentation
On 04/13/2012 03:19 PM, Vandonderen Casper (Nokia-MP/Oslo) wrote: But I would be grateful if you would make a plan on how to turn qdoc into a mini-qmake so that qdoc can parse the .pro/sync.profile, so that we don't need the depends. Because that would probably also mean that you have to run qdoc [module.pro] [module.qdocconf], or do you see that differently? Doesn't qmake run over doc.pri to generate a Makefile rule make docs that you run? Or are we moving away from make docs and towards running qdoc explicitly? -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
