[Development] Spelling of module names in documentation
Hi all, The documentation is currently using various spelling styles for module names, so I've worked with our technical writers and Kevin (the documentation maintainer) on this wiki article: http://developer.qt.nokia.com/wiki/Spelling_Module_Names_in_Qt_Documentatio n Comments? There are a couple of special cases that may need some further discussion: - Qt Publish Subscribe: should we drop the and to make the documentation and code consistent - Qt System Info instead of Qt System Information to make the documentation and code consistent - ActiveQt - Qt WebKit for WebKit 1 stuff - should that potential module be called Qt WebKit Widgets, similarly to Qt Multimedia Widgets? That could still cover Qt Quick 1 based stuff, because QDeclarativeView is a widget... Best regards, Henry ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespace macros for Qt Add-Ons
On 12/9/11 8:42 AM, Haverinen Henry (Nokia-MP-Qt/Tampere) henry.haveri...@nokia.com wrote: Hi Lars, We've previously recommended that add-on modules should wrap their public interface in C++ namespaces like QtBluetooth, QtOrganizer, QtJsonDb and so on. Should there be some guidance for the namespace macros? Especially the macros for using the namespace, which are used in application code. I assume they are introduced to prepare for the possibility of moving the module to Qt Essentials and removing the namespace. Or if the namespace should change for some other reason and you want to stay 100% source compatible. Now we have macros like: QTORGANIZER_USE_NAMESPACE QTBLUETOOTH_USE_NAMESPACE Q_USE_JSONDB_NAMESPACE So it's not consistent at the moment, which makes the macros non-guessable. What would be the right thing to do here? I'm not a too big fan of these macros. The main question is whether they are needed at all. It doesn't really save any effort in typing. 'using namespace QtAddOn::JsonDb' is not really harder to type than the macro. And if we change to a different namespace it's most likely for a reason, and we would likely do some API changes in the process breaking SC. In that case it might be just as ok if developers have to manually change the using statement. At least everybody understands then that something has changed. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespace macros for Qt Add-Ons
On 12/9/11 10:50 AM, Knoll Lars (Nokia-MP-Qt/Oslo) lars.kn...@nokia.com wrote: On 12/9/11 8:42 AM, Haverinen Henry (Nokia-MP-Qt/Tampere) henry.haveri...@nokia.com wrote: Now we have macros like: QTORGANIZER_USE_NAMESPACE QTBLUETOOTH_USE_NAMESPACE Q_USE_JSONDB_NAMESPACE So it's not consistent at the moment, which makes the macros non-guessable. What would be the right thing to do here? I'm not a too big fan of these macros. The main question is whether they are needed at all. It doesn't really save any effort in typing. 'using namespace QtAddOn::JsonDb' is not really harder to type than the macro. The current recommendation 'using namespace QtJsonDb' looks even better and easier to understand :) And if we change to a different namespace it's most likely for a reason, and we would likely do some API changes in the process breaking SC. In that case it might be just as ok if developers have to manually change the using statement. At least everybody understands then that something has changed. We should then make sure that the documentation and examples use normal C++ using statements rather than any macros. Best regards, Henry ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Hi Henry, https://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Choose a descriptive playground project name. The name should not include Qt. For example Extra Effects, Mime Types If a developer would like to move a project that is started as QtX, I should rename it to Y or something like that, and then back again to X ? Practical example: QtOpenaL (coming for instance from a KDE repository) - 3D Audio (Qt Playground) - QtOpenAL (Qt Final) I can probably guess the reasons, but it might just seem like an overhead for new contributors at first glance in the aforementioned example. I am not writing it is bad, but it would probably be reasonable to write a more detailed description of what the reason for this is. :) There are pros and cons for this decision, and if you mention why the decisions are made, it would make it clearer for contributors more explicitely why you stick by that. Graduating from the Playground Once your project becomes more mature, it can be moved out of the playground, and become a Qt module or tool. This decision is done on the qt-development mailing list and requires the approval of the Chief Maintainer. When your project is moved from the playground to the Qt project area, the playground name needs to be changed to a descriptive Qt module or tool name. Could you please document the review process more thoroughly ? II guess the whole history is not available in many cases. It would be nice, unless you already started the project in this playground repository. I am also interested in the review process in general about new modules and tools. It is somewhat different in the sense, they are not logical commit by commit reviews. More precisely, if I do not have a proper history, is it enough to put for review that way, or I need to refactor the project to get proper history first ? It might be a bit of a hard task in certain cases, but would bring more quality into the project. Thank you for sharing the wikipage. It is nice to see there is already some documentation. :) Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
Hi Liang, please send these to development@qt-project.org. On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com wrote: Hi, all, The original task is: http://bugreports.qt.nokia.com/browse/QTBUG-23071 And the change is: http://codereview.qt-project.org/10803 For the API name, we need a micro API review: Set 1: createUuidMd5() createUuidSha1() or createUuidMd5OrSha1() Set2: createUuidV3() createUuidV5() or createUuidV3OrV5() Any other suggestion is also welcome. These names look ugly. Why not simply QUuid::createUuid(const QUuid ns, const QByteArray baseData, Version v); ? Lars Regards, Liang ___ Qt5-feedback mailing list qt5-feedb...@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
Lars wrote:
On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com wrote:
The original task is:
http://bugreports.qt.nokia.com/browse/QTBUG-23071
And the change is:
http://codereview.qt-project.org/10803
For the API name, we need a micro API review:
Set 1:
createUuidMd5()
createUuidSha1()
or
createUuidMd5OrSha1()
Set2:
createUuidV3()
createUuidV5()
or
createUuidV3OrV5()
Any other suggestion is also welcome.
These names look ugly. Why not simply QUuid::createUuid(const QUuid ns,
const QByteArray baseData, Version v); ?
I don't like that one since the namespace and name version only makes sense for
v3(Md5) and v5(Sha1), making all other options useless. I would prefer one name
that makes explicit either the version (v3/v5), the approach (fromName) or the
hash function (Md5, Sha1).
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespace macros for Qt Add-Ons
On Friday, 9 de December de 2011 08.50.41, lars.kn...@nokia.com wrote: Now we have macros like: QTORGANIZER_USE_NAMESPACE QTBLUETOOTH_USE_NAMESPACE Q_USE_JSONDB_NAMESPACE So it's not consistent at the moment, which makes the macros non-guessable. What would be the right thing to do here? I'm not a too big fan of these macros. The main question is whether they are needed at all. They are probably a heritage of the Qt Mobility namespace, which existed in the first place because the modules there were meant to be moved into Qt and the namespace dropped, keeping source compatibility. -- 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] typo in docs
On Friday, 9 de December de 2011 11.57.21, Thomas Zander wrote:
hey,
just sending a quick email because I detected a typo in qpainter.cpp which
misspells an enum value. So copy paste gave me a compile error :)
It would be much appreciated if someone that actually has push rights
changes this and pushes it upstream, since creating a merge request is
kinda overkill.
Thanks!
hunk src/gui/painting/qpainter.cpp 2259
-\l {QImage::Format}{Format_ARGB32Premultiplied} or
+\l {QImage::Format}{Format_ARGB32_Premultiplied} or
The process to push the change is the same, regardless of who initiates it. So
if you do it or if I do it or anyone else, we'll both have the same workload.
--
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] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
On 12/9/11 1:27 PM, João Abecasis joao.abeca...@nokia.com wrote:
Lars wrote:
On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com
wrote:
The original task is:
http://bugreports.qt.nokia.com/browse/QTBUG-23071
And the change is:
http://codereview.qt-project.org/10803
For the API name, we need a micro API review:
Set 1:
createUuidMd5()
createUuidSha1()
or
createUuidMd5OrSha1()
Set2:
createUuidV3()
createUuidV5()
or
createUuidV3OrV5()
Any other suggestion is also welcome.
These names look ugly. Why not simply QUuid::createUuid(const QUuid ns,
const QByteArray baseData, Version v); ?
I don't like that one since the namespace and name version only makes
sense for v3(Md5) and v5(Sha1), making all other options useless. I would
prefer one name that makes explicit either the version (v3/v5), the
approach (fromName) or the hash function (Md5, Sha1).
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray
name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString
name)
{
return createFromName(ns, name.toUtf8());
}
A lot better.
The other option (if you want to avoid having two symbols is to only have
createFromName(Š, Version = Sha1), and document that anything that's not
Md5 will use to Sha1.
I don't have strong opinions on either option though.
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Removal of QWorkspace? (superseeded by QMdiArea since Qt 4.3)
Hi, I was wondering if the QWorkspace-widget should be removed in Qt 5. It has been out of maintenance for a long time. - http://codereview.qt-project.org/#change,10862 removes the Qt Designer support - https://codereview.qt-project.org/#change,10867 (ActiveQt) removes the last remaining occurrence of it outside qtbase. What do you think? Regards, Friedemann -- Friedemann Kleint Qt Open Source Team Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New QtonPi mailing list
Not sure, depends on each project. When the mailing list is the only and transparent channel of communication for developing the project itself you do generate traffic. Imagine for instance all http://mail.kde.org/pipermail/necessitas-devel/ landing in development@qt-project.org - not really useful. I personally prefer this modularized and focused on a topic. Meego had its own way for project communication, too. I have not seen too much Maemo and Harmattan discussion here either. They also had their own forums for this. On a side note for parallel examples, the linux kernel, KDE and gnome also have many separate mailing lists for a variety of development topics. :) I think boost also has project specific mailing lists. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of QWorkspace? (superseeded by QMdiArea since Qt 4.3)
On Fri, 9 Dec 2011, Friedemann Kleint wrote: I was wondering if the QWorkspace-widget should be removed in Qt 5. It has been out of maintenance for a long time. Still heavily in use in the real world however. Harri (representing several customer's interest). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
On 9. des. 2011, at 13.27, João Abecasis wrote:
Lars wrote:
On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com wrote:
The original task is:
http://bugreports.qt.nokia.com/browse/QTBUG-23071
And the change is:
http://codereview.qt-project.org/10803
For the API name, we need a micro API review:
Set 1:
createUuidMd5()
createUuidSha1()
or
createUuidMd5OrSha1()
Set2:
createUuidV3()
createUuidV5()
or
createUuidV3OrV5()
Any other suggestion is also welcome.
These names look ugly. Why not simply QUuid::createUuid(const QUuid ns,
const QByteArray baseData, Version v); ?
I don't like that one since the namespace and name version only makes sense
for v3(Md5) and v5(Sha1), making all other options useless. I would prefer
one name that makes explicit either the version (v3/v5), the approach
(fromName) or the hash function (Md5, Sha1).
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
Thinking over it some more, the two function names above could instead be
createUuidV3 and createUuidV5.
In that vein, we could introduce overloads for v1, v2 and v4 taking no
arguments. We currently have an implementation for v4, with
QUuid::createUuid(), making that trivial to implement:
static inline QUuid createUuidV4()
{
return QUuid::createUuid();
}
The other overloads,
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
would only be updated to call the right implementations, as appropriate.
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
On 9. des. 2011, at 17.10, ext Denis Dzyubenko wrote:
2011/12/9 João Abecasis joao.abeca...@nokia.com:
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray
name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
I like names createFromNameV3() ! I also think we should have api that
takes QString (i.e. operates on utf-16 data) and QByteArray (i.e. raw
data), and maybe even an overload that takes const char * and int size
- for passing raw data.
Above, I already suggest versions taking QByteArray and that operate on the
byte data, or did you mean something different?
And what's wrong with QByteArray::fromRawData(const char *data, int size)? (Can
we do something in QByteArray improve it, for instance? That would keep
everyone from having to add that one extra overload...)
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Hi Laszlo, If a developer would like to move a project that is started as QtX, I should rename it to Y or something like that, and then back again to X ? Practical example: QtOpenaL (coming for instance from a KDE repository) - 3D Audio (Qt Playground) - QtOpenAL (Qt Final) The instructions were written with brand new projects in mind, but I agree we need to consider existing projects that move to Qt Project. The contribution agreement needs some special consideration here, so I'll work with Cristy on making that addition. For a new project, you could pick a name like 3D Audio, and then if it is moved into an actual module it could be called Qt 3D Audio. OpenAL is a special case because it is a 3rd party technology name. Whether using it in the module name falls under fair use would have to be checked with Qt Project Legal. I can probably guess the reasons, but it might just seem like an overhead for new contributors at first glance in the aforementioned example. I am not writing it is bad, but it would probably be reasonable to write a more detailed description of what the reason for this is. :) There are pros and cons for this decision, and if you mention why the decisions are made, it would make it clearer for contributors more explicitely why you stick by that. In some cases we expect there to be several related playground projects, so it would not necessarily be fair to allocate a good name like Qt Physics Engine (just an example) for the first physics engine related playground activity. It needs to be given to the project that actually graduates into a real Qt module. Another reason for not using the Qt prefix is that we'd like to make sure the playground projects are not mistaken as actual Qt modules, because they don't have that status yet. Graduating from the Playground Once your project becomes more mature, it can be moved out of the playground, and become a Qt module or tool. This decision is done on the qt- development mailing list and requires the approval of the Chief Maintainer. When your project is moved from the playground to the Qt project area, the playground name needs to be changed to a descriptive Qt module or tool name. Could you please document the review process more thoroughly ? II guess the whole history is not available in many cases. It would be nice, unless you already started the project in this playground repository. I am also interested in the review process in general about new modules and tools. It is somewhat different in the sense, they are not logical commit by commit reviews. More precisely, if I do not have a proper history, is it enough to put for review that way, or I need to refactor the project to get proper history first ? It might be a bit of a hard task in certain cases, but would bring more quality into the project. The idea in this section of the wiki was to discuss the general spirit fit and technical fit of the project as a new Qt module on the mailing list, before including the module in Qt releases. I don't know how detailed technical review and API review would be done for a module that has a long history (or might lack a part of the history in the repository). Lars and others, do you have comments on this? Best regards, Henry ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Hi Robin, From: ro...@viroteck.net [mailto:ro...@viroteck.net] On Behalf Of ext Robin Burchell Agree with a Qt maintainer that s/he will approve your new playground project Can we agree that this approval should be done on development@? That way, the discussion around the suggestion is visible and (if needed) someone could raise concerns, point out areas of interest like past research, etc. I don't think that would end up too verbose, after alll, this shouldn't happen too often. Having these on a list also mirrors the structure for approval nomination. I think it'd be important to keep the barrier very low. It should be possible to start competing or crazy projects. So this approval from a Maintainer shouldn't usually require a lot of discussion, and it shouldn't be necessary for someone to object to creating playground projects. But I agree it'd be good to have an opportunity to see the initial discussion. How do others see this? Send your request for a new Playground project (including project name and description) to the Qt maintainer from whom you have pre-approval. CC to sergio.ahumada at nokia.com and Gerrit Expert Group (email address TBD). I think I'd prefer to see this on an infra@ type list, again, so people can keep informed (if they want), and there's no need to change CCs and get outdated information over time. There's also then an archive of this stuff happening, which is usually a good thing. The Gerrit Expert Group mailing list was intended to work as an archive. It doesn't exist yet. Sergio, I guess you'll be on that list anyway, so we could simplify this to just sending the emal to the list and to the approving maintainer? Cheers, Henry ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Hi, Send your request for a new Playground project (including project name and description) to the Qt maintainer from whom you have pre-approval. CC to sergio.ahumada at nokia.com and Gerrit Expert Group (email address TBD). I think I'd prefer to see this on an infra@ type list, again, so people can keep informed (if they want), and there's no need to change CCs and get outdated information over time. There's also then an archive of this stuff happening, which is usually a good thing. The Gerrit Expert Group mailing list was intended to work as an archive. It doesn't exist yet. Sergio, I guess you'll be on that list anyway, so we could simplify this to just sending the emal to the list and to the approving maintainer? Cheers, Henry Yes, I'll be in that list as well. people can keep informed (if they want) means that if I want to be informed I can subscribe to the Gerrit Expert Group ML ? I'd say that if this is going to be sent to development@ anyways (as Robin suggested) there is no need for yet another ML. Also I don't see the GEG ML as an archive for Playground requests but rather as a place to discuss about Gerrit itself. But maybe I misunderstood the idea. Cheers, -- Sergio Ahumada Mobile Phones Middleware - Quality Engineering http://wikis.in.nokia.com/QtQualityEngineering ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. Thanks, -- Stephen Kelly step...@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] This week in Qt 5 development (week 49)
Be that as it may, that is a /very/ useful email right there! :) 2011/12/9 Stephen Kelly stephen.ke...@kdab.com: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. Thanks, -- Stephen Kelly step...@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 ___ 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] How to create new Qt modules or tools
Hi Henry, Thank you for your quick reply. The instructions were written with brand new projects in mind, but I agree we need to consider existing projects that move to Qt Project. The contribution agreement needs some special consideration here, so I'll work with Cristy on making that addition. For a new project, you could pick a name like 3D Audio, and then if it is moved into an actual module it could be called Qt 3D Audio. OpenAL is a special case because it is a 3rd party technology name. Whether using it in the module name falls under fair use would have to be checked with Qt Project Legal. I was having the term idea according to the previous QtOpenGL. I have just tried to go to their mailing lists, but they do not seem to load here at the momment: http://kcat.strangesoft.net/openal.html#about Renaming to Qt3DAudio or something similar would not be a problem either. I have been so far the only one contributing to the codebase. I will patiently wait for Cristy's answer about it. :) In some cases we expect there to be several related playground projects, so it would not necessarily be fair to allocate a good name like Qt Physics Engine (just an example) for the first physics engine related playground activity. It needs to be given to the project that actually graduates into a real Qt module. Another reason for not using the Qt prefix is that we'd like to make sure the playground projects are not mistaken as actual Qt modules, because they don't have that status yet. Could you please document it on the relevant wikipage ? The idea in this section of the wiki was to discuss the general spirit fit and technical fit of the project as a new Qt module on the mailing list, before including the module in Qt releases. I don't know how detailed technical review and API review would be done for a module that has a long history (or might lack a part of the history in the repository). Lars and others, do you have comments on this? I will wait for Lars and others, then. :) I have further questions about the process in general: 1) Build and software testing service Is there a build and software testing service provided for projects in the Qt Playground repositories ? I have not seen any mentionings about that so far. and it is an important question in my case, for instance. I have been using CDash [1] for projects under the KDE umbrella. It is possible as long as I use cmake as a build system in my project. I think such a build and software testing service along with the publishing of the build results would increase the QA of those playground projects. I know there are such QA services for final modules. I was just curious if those tools, providing the relevant services, are available to Qt Playground projects or not. If not, are there some other options ? It would be really nice if playground projects could get such an attention. I am not willing to propose it for all the projects there because I do not know the capacity, but at least for projects and maintainers there who are interested in this matter. 2) Requirement about third-party dependencies In general, what is the requirement for third-party dependencies regarding the new modules and tools ? Let me give a practical example. QtOpenAL has been using a QALAbstractAudioDecoder interface at the momment and there are various implementations of that interface (e.g. backends like sndfile, libvorbisfile, flac, fluidsynth. Plans in the future, like modplug, dumb, ffmpeg and so forth). Could you please write something about third-party dependencies a bit more ? Are there limitations for those or just a sane consensus ? It might be that new modules or tools might try to bring new third-party dependencies in, if possible. 3) Becoming a maintainer on this road The playground project maintainer reaches the stage Graduating from the Playground. S/he would probably like to maintain this module either in Qt essentials or as an add-on in a normal case. It means that s/he would like become a maintainer. According to the Qt Governance model [2]: ...How to become a Maintainer An Approver who makes a high level of contribution to the Project, particularly to its strategic direction and long-term success, may be nominated as a Maintainer by an existing Maintainer... How about this workflow in this case ? I guess some of the Qt Playground project maintainers are not approver. Do they first need to get nominated for this role, or can they ask the graduating from playground directly without that process meanwhile becoming the maintainer of the freshly proposed module ? 4) Review process ...It's easy to kick off a new module or tool in the Qt project. With the approval of a Qt Maintainer, you can request a new project to be added to the Qt Playground area of codereview.qt-project.org... What does it mean precisely ? Does it mean that I have the same workflow in playground as in the final stage or can I push directly to my
Re: [Development] This week in Qt 5 development (week 49)
2011/12/9 Stephen Kelly stephen.ke...@kdab.com: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. I would love to see something like this on the Qt development list, even if accidentally distributed to a wider audience! Thanks, Marcus ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt platform and theme plugins
morten spaketh: Those of you that follow the commits on Gerrit closely may have noticed the new QPlatformTheme API and wondered what it is. In short, the QPlatformTheme API is there to support deeper platform integration, indepentently of QPlatformIntegration. snip, I am *very* interested in this effort -- IMHO we absolutely need to be able to establish the look-and-feel for applications in a centralized manner (color schemes, fonts, button styles, etc.) snip, QPlatformTheme currently has API for dialogs and system menus. Which APIs belong in QPlatformTheme is up for debate; we want to share as many platform abstractions as possible between QtWidgets and QtQuick, but at the same time some of the APIs might be to tied to the QWidget world. From the description, this appears to be an effort to establish a common API or approach for *both* Qt5Widgets and QML2+? That's what I'd be most excited about (one approach). Selfishly, I'm mostly focused on QML 2+ in Qt5+, even we'll have legacy widget styling needs at some level after migrating to Qt5, (we're currently using Qt stylesheets). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
On Fri, Dec 9, 2011 at 12:49 PM, Marcus D. Hanwell marcus.hanw...@kitware.com wrote: 2011/12/9 Stephen Kelly stephen.ke...@kdab.com: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. I would love to see something like this on the Qt development list, even if accidentally distributed to a wider audience! +1 --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
Op 9-12-2011 20:18, Stephen Kelly schreef: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. Aren't we all, in a way? ;-) Anyway, thanks. I think it is informative! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Linux event dispatcher work
Hi all, As I'm starting to get somewhere with some of my recent hackery, I thought I'd start discussing it a little more publically. tl;dr if all goes well and I manage to actually clean up all this code and get it reviewed, in the future, if you're on linux, hopefully the core event processing will be a lot snappier. Any input is welcome, I hope to start providing patches over this weekend. I've been working on a new event dispatcher[1] (QAbstractEventDispatcher subclass) in Qt's core. Specifically, I've been working on an event dispatcher to best make use of Linux-specific features (like eventfd, epoll, etc) and experimenting with that, with a fair degree of success: I've got a prototype that can run pretty quickly, faster than both QEventDispatcherUnix and QEventDispatcherGlib by quite a fair margin[2] - as it's at quite an early stage, I don't want to shout benchmarks from the top of the roof at this point, but my superficial eventbench testcase, which fires off QMetaObject::invokeMethod as fast as it can, is running at somewhere around 20-30% higher throughput than either of those. Anyway - now I've got this, I need to do something useful with it, right? I happened to have an accidental pseudo-meeting with Thiago about this just now, and as we're a cool open source project, that's the whole reason I'm writing this mail. The general conclusion is that we can try do it, but we do it in chunks, so here's my planned roadmap: - Split timer handling out of QUnixEventDispatcher for my saniy (done: http://codereview.qt-project.org/#change,10683) - Split QUnixEventDispatcher into two classes - a base containing things like timer handling and other parts that Linux can share with other unices, and an actual implementation containing the parts that can't be shared - especially intra-thread wakeup (more on that in a moment) - Introduce a QLinuxEventDispatcher class (mostly a copy of the Unix implementation class initially) - Introduce eventfd(2) handling to QLinuxEventDispatcher (this is much, much, much, orders of magnitude faster than the generic current thread pipe solution) - Introduce epoll (possibly optionally, possibly not, if I manage to browbeat Thiago enough ;), in some yet-to-be-decided form agreeable to all) - timerfd seems to be a useful solution to avoid doing timers in userspace/polling; I'm not sure on the practicality, needs more investigation. (Thiago, I forgot to mention this) In slightly more detail on some of points: eventfd === With my initial unix-based dispatcher, with just epoll implemented, I was somewhat surprised at the rather low call rates I was getting, so I did a bit of digging, and found out that thread waking was taking quite a long time. Since I was bored, I hacked eventfd support in (it wasn't all that hard), and suddenly, the number of QMetaObject::invoke()s I could do per second increased by a very large number - around 100,000. epoll = Epoll will allow Qt applications to scale to (much) larger numbers of FDs than the current unix event dispatcher - which is stuck at whatever FD_SETSIZE defaults to nowdays on Linux, something I don't personally know off the top of my head anymore. I highly hope (and partially suspect) it will _also_ reduce latency/etc (yes, even with the overhead of syscalls to disable writability notifications) for smaller numbers of sockets, but this is the part I need to prove somehow before I can make a strong case for making epoll the default. Thoughts on this welcome. [1]: For the uninitiated, an event dispatcher is the heart of a lot of things. It receives events from various sources (like sockets, timers, etc), and handles passing them off to Q(Core)Application, or wherever else they need to go. [2]: (usual disclaimer: code is work in progress/probably buggy/incomplete) Questions, comments, rocket propelled grenades? BR, -- Robin Burchell http://rburchell.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
