[Development] QMetaTypeId and QMetaTypeId2
Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? QMetaTypeId2 delegates all operations to QMetaTypeId by default and qMetaTypeId() function is calling QMetaTypeId2. To make it more complex Q_DECLARE_METATYPE is specializing QMetaTypeId but Q_DECLARE_BUILTIN_METATYPE is specializing QMetTypeId2. From an user perspective it is not visible, but it makes implementation complex. Can I merge QMetaTypeId and QMetaTypeId2? Cheers, Jędrek ps. Stats: metatype usage count: 12 which is about 2,4 per sentence. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMetaTypeId and QMetaTypeId2
On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote: Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? Because the original QMetaTypeId that existed in Qt 4.0 lacked one important feature, which Harald fixed in 4.2 or 4.3. Before harryF's changes, the Q_DECLARE_METATYPE macro did not save the name, so you had to include the type's name in the registration function: qRegisterMetaTypeMyType(MyType); This was necessary because the type's name cannot be easily gleaned from the template parameter (I have a patch for that though, see https://codereview.qt- project.org/#change,670 ). QMetaTypeId2 delegates all operations to QMetaTypeId by default and qMetaTypeId() function is calling QMetaTypeId2. To make it more complex Q_DECLARE_METATYPE is specializing QMetaTypeId but Q_DECLARE_BUILTIN_METATYPE is specializing QMetTypeId2. From an user perspective it is not visible, but it makes implementation complex. Can I merge QMetaTypeId and QMetaTypeId2? Yes. Those are not public classes. There was some Harmattan code that specialised them and broke when we made some changes in 4.7, but touching those classes is internal API. -- 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] Changes to the Jira roles and workflow
On Thursday, 9 de February de 2012 10.20.47, bradley.hug...@nokia.com wrote: There is call for discussion around default assignee – is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? Unassigned should be the default. When someone picks up the task, they should assign it to themselves. Anything else is misleading. Agreed. As a Maintainer, I really don't want tons of tasks assigned to me and in idle state. It would make my life difficult because I can't find the tasks I want to work on. And it would get people screaming at me for not looking at their tasks. -- 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] Changes to the Jira roles and workflow
Default Assignee There is call for discussion around default assignee – is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? Unassigned should be the default. When someone picks up the task, they should assign it to themselves. Anything else is misleading. I don't think the Creator team wants to change away from the current default assignee system for bugs in Creator, as that works pretty well for us. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
On 09/02/2012 04:33, ext Thiago Macieira wrote: On Thursday, 9 de February de 2012 10.20.47, bradley.hug...@nokia.com wrote: There is call for discussion around default assignee – is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? Unassigned should be the default. When someone picks up the task, they should assign it to themselves. Anything else is misleading. Agreed. As a Maintainer, I really don't want tons of tasks assigned to me and in idle state. It would make my life difficult because I can't find the tasks I want to work on. And it would get people screaming at me for not looking at their tasks. I think the argument against that is that Maintainers should know what goes on in their modules. Assigning new tasks unassigned will not notify the maintainer about issues in the modules that have come up, and the maintainer will not by notified when someone takes a task and starts working on it. (/me has no strong feelings either way, just highlighting the different view points) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMetaTypeId and QMetaTypeId2
On Thursday, February 09, 2012 10:07:16 Jedrzej Nowacki wrote: Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? QMetaTypeId2 delegates all operations to QMetaTypeId by default and qMetaTypeId() function is calling QMetaTypeId2. To make it more complex Q_DECLARE_METATYPE is specializing QMetaTypeId but Q_DECLARE_BUILTIN_METATYPE is specializing QMetTypeId2. From an user perspective it is not visible, but it makes implementation complex. Can I merge QMetaTypeId and QMetaTypeId2? I always thought they were split so that Qt could add new built-in metatypes without breaking user code. Eg, if you merge them, any user code doing: Q_DECLARE_METATYPE(QModelIndex) will no longer compile until that line is removed (It is a built-in metatype now). 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] JIRA bug management: users can't close their 'assigned' bugs.
On 06/02/2012 03:04, ext Rick Stockton wrote: Hi everyone, I have a number of stale bugs which need to be closed. When bugs are Assigned, even to Earth Domain, the original reporter is unable to close them. SO, for the purpose of removing bad data from our DB, I'm requesting help with the following bugs. I'm the reporter/creator of in all cases: https://bugreports.qt-project.org/browse/QTBUG-19793 (some work on mouse buttons in 4.x, which we put into 5.0 instead. Change to CLOSED/REJECTED) Done by Shane on 06. https://bugreports.qt-project.org/browse/QTBUG-22642 (Qt5 mouse buttons in XLIB and XCB, Resolved. Fixed in Qt 5.0.0) This is currently in Verified state, which will changed to Closed once released. (See https://bugreports.qt-project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=Qt%20Bug%20TrackingstepId=7width=fullheight=full for workflow visualization) https://bugreports.qt-project.org/browse/QTBUG-22642 (bad idea, should be CLOSED/REJECTED. Note: Current assignee is Oliver Goffart, but the bad idea was mine ;) The QTBUG number on this one is the same as above. https://bugreports.qt-project.org/browse/QTBUG-22338 (change to CLOSED/REJECTED). Done by Shane on 06. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
Howdy, Assigning new tasks unassigned will not notify the maintainer about issues in the modules that have come up, and the maintainer will not by notified when someone takes a task and starts working on it. Surely this is something that JIRA could support? Watching a component or similar? (also can Gerrit do this too?) Cheers, MichaelG ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote: Assigning new tasks unassigned will not notify the maintainer about issues in the modules that have come up, and the maintainer will not by notified when someone takes a task and starts working on it. Surely this is something that JIRA could support? Watching a component or similar? (also can Gerrit do this too?) Not by default. But there is a 3rdparty pluging to allow adding Watcher on components: https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Watcher+Plugin -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
It's easy to make a report on your personal dashboard to show issues reported on a given (set of) component(s). It means polling rather than email notification, but the email notifications have poor signal:noise ratio. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of marius.storm-ol...@nokia.com Sent: Thursday, February 09, 2012 11:47 To: michael.godd...@nokia.com Cc: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Changes to the Jira roles and workflow On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote: Assigning new tasks unassigned will not notify the maintainer about issues in the modules that have come up, and the maintainer will not by notified when someone takes a task and starts working on it. Surely this is something that JIRA could support? Watching a component or similar? (also can Gerrit do this too?) Not by default. But there is a 3rdparty pluging to allow adding Watcher on components: https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Wa tcher+Plugin -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMetaTypeId and QMetaTypeId2
On Thursday 09 February 2012 10:42:07 Thiago Macieira wrote: On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote: Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? Because the original QMetaTypeId that existed in Qt 4.0 lacked one important feature, which Harald fixed in 4.2 or 4.3. Before harryF's changes, the Q_DECLARE_METATYPE macro did not save the name, so you had to include the type's name in the registration function: qRegisterMetaTypeMyType(MyType); This was necessary because the type's name cannot be easily gleaned from the template parameter (I have a patch for that though, see https://codereview.qt- project.org/#change,670 ). It was before my time, but I think it is totallty unrelated to that, since Q_DECLARE_METATYPE already registered the name in Qt 4.0 and that QMetaTypeId2 is only used for builtin types. I beleive it has been added so adding builting type do not conflicts with Q_DECLARE_METATYPE of the same type. Indeed, in Qt 4.1, the list of supported metatype was quite small http://doc.qt.nokia.com/4.1/qmetatype.html#Type-enum But in Qt 4.2, where QMetaTypeId2 was added, that list has gained a lot of types. Without QMetaTypeId2, customer code that would have done Q_DECLARE_METATYPE(QStringList) yould break QMetaTypeId2 delegates all operations to QMetaTypeId by default and qMetaTypeId() function is calling QMetaTypeId2. To make it more complex Q_DECLARE_METATYPE is specializing QMetaTypeId but Q_DECLARE_BUILTIN_METATYPE is specializing QMetTypeId2. From an user perspective it is not visible, but it makes implementation complex. Can I merge QMetaTypeId and QMetaTypeId2? Yes. Those are not public classes. There was some Harmattan code that specialised them and broke when we made some changes in 4.7, but touching those classes is internal API. In Qt5.0 they sure can be merged. Maybe we will need to re-add it if we decide to add buitlins metatype that were not builtins before. But it is less likely now that in Qt 4.1, or maybe we find another trick to keep it working. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] RFC: The Future of QDoc
Hello, I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
Implement a new C++ parser Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST, but it seems like Qt Creator will be moving away from its own implementation in the future, so I think that might be something to consider. Also, since the necessary work on Clang is being done for Qt Creator anyway (I'm thinking of things like signals/slots) it might be worth to keep qdoc in mind when working on Clang for Qt Creator. Any thoughts? Keno ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On 2/9/12 3:15 PM, ext Keno Fischer ke...@stanford.edu wrote: Implement a new C++ parser Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST, but it seems like Qt Creator will be moving away from its own implementation in the future, so I think that might be something to consider. Also, since the necessary work on Clang is being done for Qt Creator anyway (I'm thinking of things like signals/slots) it might be worth to keep qdoc in mind when working on Clang for Qt Creator. Any thoughts? I think that QDoc will indeed use the parser from Creator (whatever that will be, the last answer from Andre Poenitz was to use a hybrid), unless someone comes up with other great ideas. The problem stays that QDoc is not fully modularized (QDoc will depend on Creator/an independent module containing the parser). But maybe that is something we cannot circumvent (unless we let QtBase depend on Clang and have our own parser, but that will not work on every platform I assume). Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On 9 February 2012 14:15, Keno Fischer ke...@stanford.edu wrote: Implement a new C++ parser Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST, but it seems like Qt Creator will be moving away from its own implementation in the future, so I think that might be something to consider. Also, since the necessary work on Clang is being done for Qt Creator anyway (I'm thinking of things like signals/slots) it might be worth to keep qdoc in mind when working on Clang for Qt Creator. Any thoughts? There's also the KDevelop C++ parser. It already supports many C++11 features and run very fast. As far as I'm aware it doesn't depends on any KDE libraries (Qt only) and already has the ability to extract Doxygen-style comments. I don't know if there are any KDevelop people on this list who can comment further? -- Matt Williams http://milliams.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMetaTypeId and QMetaTypeId2
On Thursday, 9 de February de 2012 14.11.17, André Somers wrote: Not hindered by any knowledge of the internals of these classes: Would it be possible to make such a statement a no-op then if the type is already registered? If you can find a way to do that, great. The problem is we haven't found a way. -- 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] QMetaTypeId and QMetaTypeId2
On Thursday, 9 de February de 2012 12.39.54, Stephen Kelly wrote: I always thought they were split so that Qt could add new built-in metatypes without breaking user code. That's not why it was added. Eg, if you merge them, any user code doing: Q_DECLARE_METATYPE(QModelIndex) Most types are not built-ins. They may be added by another library, like QtDBus (that Q_DECLARE_METATYPEs a lot of types) and then there's no protection. -- 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] QMetaTypeId and QMetaTypeId2
From: Olivier Goffart oliv...@woboq.com On Thursday 09 February 2012 10:42:07 Thiago Macieira wrote: On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote: Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? Because the original QMetaTypeId that existed in Qt 4.0 lacked one important feature, which Harald fixed in 4.2 or 4.3. Before harryF's changes, the Q_DECLARE_METATYPE macro did not save the name, so you had to include the type's name in the registration function: qRegisterMetaTypeMyType(MyType); This was necessary because the type's name cannot be easily gleaned from the template parameter (I have a patch for that though, see https://codereview.qt- project.org/#change,670 ). It was before my time, but I think it is totallty unrelated to that, since Q_DECLARE_METATYPE already registered the name in Qt 4.0 and that QMetaTypeId2 is only used for builtin types. I beleive it has been added so adding builting type do not conflicts with Q_DECLARE_METATYPE of the same type. Indeed, in Qt 4.1, the list of supported metatype was quite small http://doc.qt.nokia.com/4.1/qmetatype.html#Type-enum But in Qt 4.2, where QMetaTypeId2 was added, that list has gained a lot of types. Without QMetaTypeId2, customer code that would have done Q_DECLARE_METATYPE(QStringList) yould break I think this should be handled such that it won't break such that: 1. It logs that it has already been registered, and preferably where the extraneous registrations are coming from. 2. Any extraneous registrations are dropped (not processed aside from #1). #1 is to help people track down registrations they don't need - or at least block them out so that they only occur with Qt versions that still need them (if they need the interoperability). From: André Somers an...@familiesomers.nl Op 9-2-2012 12:39, Stephen Kelly schreef: Can I merge QMetaTypeId and QMetaTypeId2? I always thought they were split so that Qt could add new built-in metatypes without breaking user code. Eg, if you merge them, any user code doing: Q_DECLARE_METATYPE(QModelIndex) will no longer compile until that line is removed (It is a built-in metatype now). Not hindered by any knowledge of the internals of these classes: Would it be possible to make such a statement a no-op then if the type is already registered? The effect should be a no-op with the possible addition of a log message (e.g. qDebug()) if it is already there so that people can track down the extraneous cases. That said, I'd like to see at least QAbstractSocket::SocketError registered as well. As it is, I typically have to register it before I can throw it through signals across thread boundaries. I'd suggest that any type - especially enums and standard types - that is in a signal/slot in the Qt API should be registered by Qt so that a signal can be used with it across thread boundaries. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Removal of Trolltech usages inside Qt
One of the blockers of [1] (Larger changes for Qt 5) is the clean up of Trolltech strings/namespaces/etc. inside Qt, which is actually tracked by several bug reports [2]. That's fine, but was any consensus reached about what to change those strings to? qt-project.org? Should any logic for fallbacks (for settings, etc.) be present in Qt code? I'd like especially to hear advice from the Chief Maintainer and the legal team. Cheers, -- Giuseppe D'Angelo [1] https://bugreports.qt-project.org/browse/QTBUG-20885 [2] https://bugreports.qt-project.org/secure/IssueNavigator.jspa?reset=truejqlQuery=summary+~+%22Stop+using+Trolltech%22 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of Trolltech usages inside Qt
On 2/9/12 4:56 PM, ext Giuseppe D'Angelo dange...@gmail.com wrote: One of the blockers of [1] (Larger changes for Qt 5) is the clean up of Trolltech strings/namespaces/etc. inside Qt, which is actually tracked by several bug reports [2]. Btw, same thing is true for 'nokia' strings and namespaces. That's fine, but was any consensus reached about what to change those strings to? qt-project.org? Should any logic for fallbacks (for settings, etc.) be present in Qt code? I'd like especially to hear advice from the Chief Maintainer and the legal team. We should change things to qt-project.org. I've done that for IIDs to some extent already. In most cases we will not need any fallbacks. I'm uncertain about some identifiers in e.g. the qtdbus module, as I don't know how this will affect interoperability between Qt 4 and Qt 5. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of Trolltech usages inside Qt
On Thursday, 9 de February de 2012 16.04.07, lars.kn...@nokia.com wrote: I'm uncertain about some identifiers in e.g. the qtdbus module, as I don't know how this will affect interoperability between Qt 4 and Qt 5. I'd say we're ok to change, as the default names will change already due to QWidget - QWindow. -- 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] RFC: The Future of QDoc
On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Have you thought about using doxygen or any similar tool? Or at least make QDoc be able to parse doxygen-style comments (which also means it should not ignore headers, as documenting public API in a header file is much more common at least outside Qt than doing that in the implementation file...) I'd be happy to see Qt use or at least support more standard solutions over homegrown ones. Since that failed for localization, maybe we can at least get it for documentation :) BR, ~ Sput -- Manuel Sput Nickschas | mailto: manuel.nicksc...@nokia.com | .-. Senior SW Engineer, Middlelayer | callto: +49 (0) 174 16 53 993 | oo| Nokia GmbH, MP Development | sendto: Lise-Meitner-Str. 14 | /`'\ Product Creation Center Ulm | 89081 Ulm, Germany | (\_;/)___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On 09/02/2012 10:16, ext Hugo Parente Lima wrote: On Thursday 09 February 2012 14:30:20 Matt Williams wrote: On 9 February 2012 14:15, Keno Fischerke...@stanford.edu wrote: Implement a new C++ parser Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST, but it seems like Qt Creator will be moving away from its own implementation in the future, so I think that might be something to consider. Also, since the necessary work on Clang is being done for Qt Creator anyway (I'm thinking of things like signals/slots) it might be worth to keep qdoc in mind when working on Clang for Qt Creator. Any thoughts? There's also the KDevelop C++ parser. It already supports many C++11 features and run very fast. As far as I'm aware it doesn't depends on any KDE libraries (Qt only) and already has the ability to extract Doxygen-style comments. I don't know if there are any KDevelop people on this list who can comment further? The KDevelop parser is based on a version of Roberto's parser, last time I checked the sources it used few KDE utility classes like some smart pointers, but I see no difference in using the KDevelop or QtCreator parser as both are more or less the same. QtCreators parser is a much later version of Roberto's parser, and I expect that it parses much faster than the KDevelop one. I'm sure QtCreators parser can be upgraded to also handle those new C++11 features, and since we need to maintain it in Creator anyways, I don't see why it should use another parser than a one we already have intimate knowledge about? I nice ability QDoc would have is to support other output formats like XML or JSON, the old QDoc had this feature but it was deprecated and not documented at all. The PySide documentation is generated using the XML output of qdoc3, but the current version of qdoc3 doesn't support XML output anymore. Oops. Casper, Martin any details about this, and why XML output was dropped? Hugo, any reason why PySide cannot use the normal output? Integration with other help tools? -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On Thursday 09 February 2012 17:56:12 marius.storm-ol...@nokia.com wrote: On 09/02/2012 10:16, ext Hugo Parente Lima wrote: On Thursday 09 February 2012 14:30:20 Matt Williams wrote: On 9 February 2012 14:15, Keno Fischerke...@stanford.edu wrote: Implement a new C++ parser Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST, but it seems like Qt Creator will be moving away from its own implementation in the future, so I think that might be something to consider. Also, since the necessary work on Clang is being done for Qt Creator anyway (I'm thinking of things like signals/slots) it might be worth to keep qdoc in mind when working on Clang for Qt Creator. Any thoughts? There's also the KDevelop C++ parser. It already supports many C++11 features and run very fast. As far as I'm aware it doesn't depends on any KDE libraries (Qt only) and already has the ability to extract Doxygen-style comments. I don't know if there are any KDevelop people on this list who can comment further? The KDevelop parser is based on a version of Roberto's parser, last time I checked the sources it used few KDE utility classes like some smart pointers, but I see no difference in using the KDevelop or QtCreator parser as both are more or less the same. QtCreators parser is a much later version of Roberto's parser, and I expect that it parses much faster than the KDevelop one. I'm sure QtCreators parser can be upgraded to also handle those new C++11 features, and since we need to maintain it in Creator anyways, I don't see why it should use another parser than a one we already have intimate knowledge about? I nice ability QDoc would have is to support other output formats like XML or JSON, the old QDoc had this feature but it was deprecated and not documented at all. The PySide documentation is generated using the XML output of qdoc3, but the current version of qdoc3 doesn't support XML output anymore. Oops. Casper, Martin any details about this, and why XML output was dropped? Hugo, any reason why PySide cannot use the normal output? Integration with other help tools? XML output was dropped because it wasn't maintained and was never made public, it always was a private experimental thing from qdoc3. We couldn't use the normal output because we need to modify the Qt documentation without touch the Qt sources, so the qdoc3 outputs XML files generated from Qt sources, we apply some XSLT's to change small things, then we transform those XML's into rst files and send them to sphinx to create the docs formatted in a python friendly way. -- Hugo Parente Lima 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] RFC: The Future of QDoc
On 09/02/2012 10:33, ext Manuel Nickschas wrote: On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Have you thought about using doxygen or any similar tool? Or at least make QDoc be able to parse doxygen-style comments (which also means it should not ignore headers, as documenting public API in a header file is much more common at least outside Qt than doing that in the implementation file...) Qt puts the documentation in the sources since it's closer to the actual code, and thus more likely to be maintained at the same time as the code is changed. If the documentation is in another location, it's far more likely to be forgotten when updates/changes to behavior is done in the source code. I'd be happy to see Qt use or at least support more standard solutions over homegrown ones. Since that failed for localization, maybe we can at least get it for documentation :) I think there are a few issues here: 1) Only Dimitri touches Doxygen code, and it doesn't look like contributions go in (at least not under the authors name). This means that the functionality to support Qt's extensive documentation needs to be implemented by Dimitri alone. Thus, Nokia's team cannot be working on enhancing Doxygen to get it up to par with the current output from qdoc. 2) From what I've seen of attempts to set up Doxygen, none of them have proven to create output quality on par with what qdoc produces. This is obviously due to qdoc only having 1 mission, to produce the documentation output that the Qt documentation team think is optimal, while Doxygen is a tool for a multitude of outputs. However, is does leave a quality gap between the documentation we want verses the documentation we can get out of the tool. A gap the documentation team would want to close, which again points to 1). 3) Transforming the documentation in Qt sources to only use current Doxygen syntax is VERY unlikely, at least in the Qt 5.0 time-frame. All of the above is my personal opinion of course, and *NOT* representative of the Qt Documentation team, qdoc team or any other team in Nokia. I like Doxygen, and have used it on several occasions for my own personal projects; but I still feel that the output of qdoc looks better. (And no, I *don't* use the inheritance charts. I think they are pointless, and not nice to look at. If you need them, something is obviously too complex in your design.) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
Hi, I nice ability QDoc would have is to support other output formats like XML or JSON, the old QDoc had this feature but it was deprecated and not documented at all. The PySide documentation is generated using the XML output of qdoc3, but the current version of qdoc3 doesn't support XML output anymore. Oops. Casper, Martin any details about this, and why XML output was dropped? Hugo, any reason why PySide cannot use the normal output? Integration with other help tools? XML output was dropped because it wasn't maintained and was never made public, it always was a private experimental thing from qdoc3. We couldn't use the normal output because we need to modify the Qt documentation without touch the Qt sources, so the qdoc3 outputs XML files generated from Qt sources, we apply some XSLT's to change small things, then we transform those XML's into rst files and send them to sphinx to create the docs formatted in a python friendly way. Have you looked at the DITA XML output we generate now? It is pretty stable now, we tried to use it for the 4.8 DevNet release, but the output was not fully up to spec at that point. It is now. You can find more information about DITA XML at http://docs.oasis-open.org/dita/v1.2/spec/DITA1.2-spec.html The version of DITA Open Toolkit we are using to apply XSLTs can be found at https://projects.developer.nokia.com/doxygen_dita/files Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On 09/02/2012 10:33, ext Manuel Nickschas wrote: On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Have you thought about using doxygen or any similar tool? Or at least make QDoc be able to parse doxygen-style comments (which also means it should not ignore headers, as documenting public API in a header file is much more common at least outside Qt than doing that in the implementation file...) Qt puts the documentation in the sources since it's closer to the actual code, and thus more likely to be maintained at the same time as the code is changed. If the documentation is in another location, it's far more likely to be forgotten when updates/changes to behavior is done in the source code. I'd be happy to see Qt use or at least support more standard solutions over homegrown ones. Since that failed for localization, maybe we can at least get it for documentation :) Just to add what I think to Marius' comments: 1. Doxygen would need some extra features, the major one being QML, but also being able to use index files to easily link for instance the Creator docs to the Qt docs. 2. Even if we would use Doxygen we would still need a fork before a release, I do not think we can line up releases of Doxygen with releases of Qt. And having a Doxygen version number like 1.7.6.2-qt-SHA1 also doesn't look too great. I would personally not mind using Doxygen, but I do agree with the points about Dimitri only changing the code and the quality of Doxygen output (which you can of course change) Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On 09/02/2012 12:13, ext marius.storm-ol...@nokia.com wrote: On 09/02/2012 10:33, ext Manuel Nickschas wrote: I'd be happy to see Qt use or at least support more standard solutions over homegrown ones. Since that failed for localization, maybe we can at least get it for documentation :) I think there are a few issues here: 1) Only Dimitri touches Doxygen code, and it doesn't look like contributions go in (at least not under the authors name). This means that the functionality to support Qt's extensive documentation needs to be implemented by Dimitri alone. Thus, Nokia's team cannot be working on enhancing Doxygen to get it up to par with the current output from qdoc. Btw, all purely based on http://doxygen.svn.sourceforge.net/viewvc/doxygen/trunk/ and committers I can see in the revision logs. I have not been in contact with Dimitri on the matter, but I do see a call to action in http://old.nabble.com/Doxygen-support-for-QML---td32658060.html. So perhaps a wrong assumption on my part. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it offloads much of the resource requirements from the Qt-Project infrastructure. What then will be a public repo address on Gitorious for get/clone other people a code libraries? It's up to you really. If you don't want to mirror it to Gitorious on a regular basis, you can just use the Gerrit repo as the primary location, though I think people will need a Jira/Gerrit account to do so? Sergio, can you please confirm or deny that? My recommendation: Keep your Gitorious repo as the primary source, and push the 2.0 branch from Gerrit to Gitorious whenever you feel it's stable enough. Then add a notice on the Gitorious project that all development is done at codereview.qt-project.org, and that Merge Requests in Gitorious is therefore disabled. For Qt Essentials, the init-repository script in qt5.git makes the Gitorious repos the 'origin', while Gerrit is the 'gerrit' remotes. -- .marius 08.02.2012, 21:37, marius.storm-ol...@nokia.com: You may now disable/stop using the Gitorious repo, and clone from Gerrit, and start pushing to refs/for/2.0 to the Gerrit repo. Then those will show up as review tasks for the 2.0 branch in Gerrit, and you can review it there. Basically, you may now use the Gerrit version as the
Re: [Development] Feature freeze and Alpha
On Sunday 05 Feb 2012 14:12:48 lars.kn...@nokia.com wrote: Is there anything that I have now forgotten that really *must* be in 5.0 (i.e. it really can't be done in a BC/SC way for Qt 5.1)? If you have such an item, please speak up, otherwise I'll consider the above exception list as final. Hi Lars, Apologies for the late reply, snowed under at work this week. I need to bring up the plan for the QLocale backend switch to ICU switch and whether you still want to complete that for 5.0 or not. There are 4 must-do changes to the API to prepare for ICU/CLDR regardless of whether the backend switch happens in 5.0 or 5.1: 1) Change QLocale date/time format API to match ICU/CLDR features. This is by necessity a source-incompatible change. 2) Change the date/time format codes to match ICU/CLDR codes. This is by necessity a source and behaviour incompatible change. 3) Add a QCalendarSystem API. While not 100% necessary for 5.0, it sets up the API usage pattern for when ICU is introduced. 4) Change the QLocale number settings API like decimalPoint() from returning QChar to QString. This is by necessity a source-incompatible change. I have patches for most of that just about ready to go that I'll get finished at the KDE PIM sprint this weekend, and will post separate review emails for these. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
From: casper.vandonde...@nokia.com casper.vandonde...@nokia.com Just to add what I think to Marius' comments: 1. Doxygen would need some extra features, the major one being QML, but also being able to use index files to easily link for instance the Creator docs to the Qt docs. Why would Doxygen need QML itself? Or do you mean it would need to be able to process the QML/JavaScript files to get additional documentation? 2. Even if we would use Doxygen we would still need a fork before a release, I do not think we can line up releases of Doxygen with releases of Qt. And having a Doxygen version number like 1.7.6.2-qt-SHA1 also doesn't look too great. I can understand bundling a version of Doxygen with Qt in the release - like many projects do for their dependencies in case those things are not on the platform people are building on. E.g. Subversion bundles libneon. However, I see no issue with saying that Doxygen version x.y.z is required to support documentation. So why would we need to _fork_ it as opposed to simply bundling a version that is known to work? Just curious, Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Look and feel
On Fri, 10 Feb 2012 03:37:44 ext Thiago Lacerda wrote: Hi, Is there a way, on Qt5, to get the platform look and feel, without the dependency of QtWidgets using QStyle? Or this is a feature that needs to be discussed about or done (for 5.1 maybe?)? The plan I'm aware of for getting platform look and feel with QML is to have QtQuick components for every platform. Theoretically, you could dynamically pick the appropriate plugin at run-time and run fine as long as you stick to the shared sub-set of API. But I say theoretically because I'm not aware of any plans to actually implement this. It's a feature that needs to be discussed about how it gets done (and 5.1 at the earliest it's looking like). The closest we have now is that the Desktop components (a labs project) tries to get hints out of QStyle to look native across desktop platforms. -- 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] Changes to the Jira roles and workflow
On Thu, 9 Feb 2012 12:58:40 ext marius.storm-ol...@nokia.com wrote: Hi, ... There is some discussion over if we should burden maintainers with Release Management work. There is a suggestion of a new workflow Nokia Engineer - no privileges in Gerrit only in Jira. That role might be useful, but please don't call it Nokia Engineer. Even if we don't expect anyone to ever volunteer to do task management roles, Qt as an open project could grow to other companies. Calling it Task Manager or Issue Secretary (or something along those lines that's not a joke ;) ) will mitigate the risk of having to change the name again later. ... Default Assignee There is call for discussion around default assignee - is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? The theory I was taught was that you don't use your 'tasks assigned to me' list as your list of your in-progress bugs. You use your 'tasks assigned to me and listed as in-progress' for that list. So assignment merely means If someone's going to look at this bug, it'll probably be this guy first. If you're working on a bug and don't want people to take it away, you mark it as in-progress. Then the tasks which are up for grabs are the ones assigned to the maintainer (or anyone, actually) which are not marked as 'in-progress'. On the 'unassigned' suggestion, I think that could only work if there's an easy way to find the correct maintainer for a component. Currently the table in qt-project contains some data, which is nice, but it's just not convenient enough or obvious enough to work with JIRA. Default assignee has basically been the way people find maintainers for bug reporting (at least), if you take that away then something else is needed. -- 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] Feature freeze and Alpha
Dear Lars,
On Thursday 09 February 2012, 21:00:40 John Layt wrote:
On Sunday 05 Feb 2012 14:12:48 lars.kn...@nokia.com wrote:
Is there anything that I have now forgotten that really *must* be
in 5.0 (i.e. it really can't be done in a BC/SC way for Qt 5.1)? If
you have such an item, please speak up, otherwise I'll consider the
above exception list as final.
sorry for chiming in that late, but my past attempts to direct some
perception of the audience on a long time flaw of Qt seem to have
failed so far. Please allow me to quote myself with a historical Qt bug
report and a post to qt5-feedback:
http://bugreports.qt.nokia.com/browse/QTBUG-277
It's about QDateEdit, QTimeEdit and QDateTimeEdit allowing to keep
invalid dates, times and datetimes invalid (with databases, a NULL
value of such a field usually has a special meaning (think death-day
of still living people). Current behavior since Qt3 is: if the user
just tabs over such a field in a (database) form, the widgets force a
valid date/time value: leading to a value of 2000-01-01 00:00:00 for a
QDateTimeEdit. Needless to say, that this behavior isn't desired almost
all the time. At least, the auto completion should be controllable in
some way. Some dates might only be valid as past or as future dates.
While the bug says, that QDateTime needs modifications, but didn't
describe, which, I beg to differ. QDate and QTime _do_ allow invalid
values. What it takes is keep invalid QDates and QTimes as long as the
user doesn't change one value (at least) and allow the user to
invalidate the values.
Here's some food for implementation thoughts: how about adding some
global boolean flag (application wide), that allows enabling invalid
Q{Date,Time,DateTime} in their respective edit widgets. If that flag is
enabled, change the widget behavior in a way, that
* tabbing over it will keep an invalid date{time},
* allow to explicitely set an invalid date{time} programatically,
* disable auto completion,
* set an invalid date{time}, if the user presses delete, or removes all
values with backspace,
* and finally add a widget property to control this behavior..
This should be possible without violating source code compatibility of
these widgets. Sorry for not providing a patch, but being a PyQt hacker
myself, my C++ skills are pretty rusty at best.
Anyway, I would love to see Qt5 appearing without this very flaw, and I
bet, that a considerable amout of Qt developers will be very grateful
for such an improvement.
Thanks in advance,
Pete
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze and Alpha
On quinta-feira, 9 de fevereiro de 2012 20.00.40, John Layt wrote: 1) Change QLocale date/time format API to match ICU/CLDR features. This is by necessity a source-incompatible change. 2) Change the date/time format codes to match ICU/CLDR codes. This is by necessity a source and behaviour incompatible change. Hi John Can you explain in more detail what those source-incompatible changes would be? How much would they affect user code? Should we consider a compatibility API? If we do that, then you're free to introduce the CLDR-compatible codes later in new functions without breaking the old ones. 3) Add a QCalendarSystem API. While not 100% necessary for 5.0, it sets up the API usage pattern for when ICU is introduced. I think we're past the time for this to go in 5.0. It can wait for 5.1, provided the necessary adaptations for it to work are in place. 4) Change the QLocale number settings API like decimalPoint() from returning QChar to QString. This is by necessity a source-incompatible change. This one seems like a simple enough change with restricted damage. I'd recommend doing it immediately, regardless of ICU or CLDR, provided Lars approves it. -- 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] QLog ( Work on qDebug and friends)
On 02/10/2012 01:16 AM, ext BRM wrote: That said, there may be a place for having a compile time option to entirely disable it too - e.g. for distributions and commercial (Digia) binary releases to be able to completely disable it on release builds. Removing the logging statement entirely is achieved by expanding the macro to: if (1) /*NOP*/; else qDebug() Technically, you'd have to wrap the logging statement in a #ifdef/#endif pair to ensure it's completely removed but I think compilers can correctly determine that the else is never hit (due to the constant in the if) and so omit that code from the binary. Certainly, that code will never be run when the macro expands this way. -- 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] QLog ( Work on qDebug and friends)
Hi Kai,
The controlling of the category will be done using a configuration file.
QLog contains a private class that creates a file watcher for the configuration
file.
So not only if you start the application but during runtime as well the
category filtering can be changed dynamically by changing the config file.
No recompiling needed with this solution.
Cheers,
WB
-Original Message-
From: Koehne Kai (Nokia-MP/Berlin)
Sent: Thursday, February 09, 2012 7:05 PM
To: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org
Subject: RE: QLog ( Work on qDebug and friends)
-Original Message-
From: Beck Wolfgang (Nokia-MP/Brisbane)
Sent: Thursday, February 09, 2012 8:11 AM
To: Koehne Kai (Nokia-MP/Berlin); development@qt-project.org
Subject: RE: QLog ( Work on qDebug and friends)
Hi Kai,
Hi Wolfgang,
I think this was a very good idea so I've tried it but I've run into
one important problem.
If I use this trick I have to call the overloaded function in QMessageLogger:
e.g.
1. void debug(QMessageCategory category, const char *format, ...); and 2.
QDebug debug(QMessageCategory category);
The first function is ok but the 2. one needs to return a QDebug object.
In this case I have to do a lots of overhead e.g. function call and
creating object after I can check if the category should be logged or not.
So better having a other named macro which I can do
#define qLog(category) \
If(!logging_enable);\
Else QMessageCategory().debug()
I see. You'll indeed need something like that if you want to define which
category to log or not with the help of the macro expander.
You might still get half-way there performance wise though by giving QDebug a
boolean active, and check for it in the various operator, e.g.
inline QDebug operator(qint64 t){ if (!active) return *this;
stream-ts QString::number(t); return maybeSpace(); }
If everything is inlined, and the various overloads of operator that people
can implement do the check too, this should mostly come down to just in a
couple of if (false) ... being executed.
Anyhow, a more basic question I have is whether we want the filtering by
category be done at runtime (e.g. in a central message handler), or at compile
time (like your solution seems to be based on). Maybe there's place for both,
but I thought the idea for the Qt libraries was to avoid the need for
recompiles ...
Regards
Kai Koehne
Cheers,
WB
-Original Message-
From: Koehne Kai (Nokia-MP/Berlin)
Sent: Tuesday, February 07, 2012 5:27 PM
To: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org
Subject: RE: QLog ( Work on qDebug and friends)
Hi Wolfgang,
how about making the category a distinct type instead?
struct QMessageCategory {
explicit QMessageCategory(const char *name); };
class QMessageLogger {
void debug(const char *format, ...);
void debug(QMessageCategory category, const char *format, ...); }
...
QDebugCategory debugCategory(MyApp); // You'll typically do this in
one place ...
qDebug(debugCategory, hi there);
Anyhow, you probably don't want to set the category explicitly for
every call in e.g. QtCore, so you can also pass it implicitly via a DEFINE:
class QMessageLogger {
QMessageLogger(const char *file, int line, const char *function,
const char
*defaultCategory) {
}
}
#define Q_DEBUG_CATEGORY // empty default #define qDebug
QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO,
Q_DEBUG_CATEGORY).debug
And QtCore is then compiled with
DEFINES+=Q_DEBUG_CATEGORY=QtCore. IMO both approaches are
complementary, passing an explicit category would overwrite the
Q_DEBUG_CATEGORY define.
Regards
Kai
From: development-bounces+kai.koehne=nokia@qt-project.org
[development-bounces+kai.koehne=nokia@qt-project.org] on behalf of
Beck Wolfgang (Nokia-MP/Brisbane)
Sent: Tuesday, February 07, 2012 7:54 AM
To: development@qt-project.org
Subject: [Development] QLog ( Work on qDebug and friends)
I'm working to integrade category log with QMessageLogger Co and
unfortunatelly we can not use
qDebg(category) my message because there is already a
debug(const char *msg, ...) function combining with the macro #define
qDebug QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug.
So I use a new function and macro:
QDebug debug();
QDebug debugCategory(const char *msg);
QDebug warning();
QDebug warningCategory(const char *msg);
QDebug critical();
QDebug criticalCategory(const char *msg);
QDebug fatalCategory(const char *msg);
#define qDebugCat(category) QMessageLogger(__FILE__, __LINE__,
Q_FUNC_INFO).debugCategory(#category)
#define qWarningCat(category) QMessageLogger(__FILE__, __LINE__,
Q_FUNC_INFO).warningCategory(#category)
#define qCriticalCat(category) QMessageLogger(__FILE__, __LINE__,
Q_FUNC_INFO).criticalCategory(#category)
[Development] Proposing Sergey Dubitskiy for Approver Status
Hi, I hereby propose Sergey Dubitskiy for the role of approver. Sergey has previously worked for some months on the Multimedia Framework and has now turned his attention to Qt3D. Br, Martin. Sarah Smith Team Lead Qt3D Email: sarah.j.sm...@nokia.commailto:sarah.j.sm...@nokia.com Ph: +61448283476 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
Op 9-2-2012 19:13, marius.storm-ol...@nokia.com schreef: On 09/02/2012 10:33, ext Manuel Nickschas wrote: On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Have you thought about using doxygen or any similar tool? Or at least make QDoc be able to parse doxygen-style comments (which also means it should not ignore headers, as documenting public API in a header file is much more common at least outside Qt than doing that in the implementation file...) Qt puts the documentation in the sources since it's closer to the actual code, and thus more likely to be maintained at the same time as the code is changed. If the documentation is in another location, it's far more likely to be forgotten when updates/changes to behavior is done in the source code. That only goes for code that is actually *in* the cpp files. It does not hold for enums, flags, inline functions and typedefs, nor does it hold for the many cases where the code is actually in a private class and the implementation contains little more than a d-doSomething(). I'm not saying that putting all documentation in the header file is better, but it would IMHO be better if we were able to put the documentation at a place were we do not need to repeat ourselves. As you say: that makes it less likely to be properly updated. That results in being able to parse both the headers *and* the sources. For the rest, you make excellent points. If doxygen really is that closed, and it is currently not up to par with what Qt needs, then we need to stick with qdoc. However, the general idea to use what is out there instead of trying to maintain every part of the toolchain ourselves does appeal to me in general. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
Op 10-2-2012 8:07, Andre Somers schreef: Op 9-2-2012 19:13, marius.storm-ol...@nokia.com schreef: On 09/02/2012 10:33, ext Manuel Nickschas wrote: On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote: I am working on QDoc part-time and we have been discussing some changes that we would like to implement to make qdoc more future proof. I have created a short list of the things we would like to do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc It comes down to: Implement a new C++ parser, make qdoc more modular and be able to handle the Qt modules better with qdoc. I am wondering if anybody has any ideas about what he/she would like qdoc to do, or how qdoc should evolve? Have you thought about using doxygen or any similar tool? Or at least make QDoc be able to parse doxygen-style comments (which also means it should not ignore headers, as documenting public API in a header file is much more common at least outside Qt than doing that in the implementation file...) Qt puts the documentation in the sources since it's closer to the actual code, and thus more likely to be maintained at the same time as the code is changed. If the documentation is in another location, it's far more likely to be forgotten when updates/changes to behavior is done in the source code. That only goes for code that is actually *in* the cpp files. It does not hold for enums, flags, inline functions and typedefs, nor does it hold for the many cases where the code is actually in a private class and the implementation contains little more than a d-doSomething(). Oh, and that is not mentioning templates either... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
