Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
Hi, Great to see we are making progress. On Tuesday 10 September 2013 18:26:09 Stefan Merettig wrote: Alright guys, let's try to complete the feature. As I heard from sides now that you want a key-value store, I'll do it that way. Feature list: 1. Q_INFO is a new macro (which expands to nothing): #define Q_INFO(key, value) Since we have Q_CLASSINFO for classes. maybe we should call it Q_METHODINFO and apply it only for method. Then, for Q_PROPERTY, use a INFO as a keyword within the Q_PROPERTY syntax. I think it is easier to read. Let us compare again: Q_INFO(foo, bar) Q_PROPERTY(int bar READ bar) Q_INFO(foo, baz) Q_PROPERTY(int baz READ baz) Q_PROPERTY(int bar READ bar INFO foo = bar) Q_PROPERTY(int baz READ baz INFO foo = baz) You see the property name (more important) before the info. and everything is together. Then for enums, we can have Q_ENUMS(MyEnum MyOtherEnum INFO foo = bar) That would only be a problem if there is an enum called INFO, but i think we are safe, it is not the Qt style. Then we have everything, with nice syntax. 2. Q_INFO can be prepended to: - Classes - Signals, slots and Q_INVOKABLE methods (This includes c'tors) - Q_PROPERTY - Q_ENUM'd enums - So everything that is accessible through the meta system 3. Multiple Q_INFO annotations for a single object are possible 4. Each object has a unique key - value mapping. This means, that something like: Q_INFO(a, b) Q_INFO(a, c) void myFunc(); results in a single key - value mapping, not two values for a. 5. API Design: Pretty much a copy of QMetaClassInfo from the user standpoint, the class will be called QMetaInfo. Questions: 1. If Q_INFO can be applied to classes, then it's redundant to Q_CLASSINFO. On the one hand it's nice to have a unified API for annotations, on the other hand it's redundant, as Q_INFO doesn't have any benefits over Q_CLASSINFO anymore. 2. How should we store this? My current approach still stems from when Q_INFO supported multiple arguments. Technically possible, but not liked. As Thiago pointed out: JSON is out of the question. I'd like to stick to something like my current implementation. It boils down to having a table in the meta_data I beleive that Thiago meant that JSON was out of question for describing the properties in the actual source. But i would not necessarily rule it out for storing the data. moc already export some data using Qt's binary JSON, so this is still a valid option. That said, I think that having the info stored in the meta_data table, like Q_CLASSINFO is, is just fine. array with two columns for each object: start index, count At 'start index' there's a list of two integers for each Q_INFO record, the first pointing to the name, the second to the value. I'd like to use a third column there to store a currently unused flag. In my initial implementation which is also on gerrit I have a fourth field to store the value count, but with only a single one this can obviously be dropped if we don't plan to ever support this feature. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On quarta-feira, 11 de setembro de 2013 08:33:35, Olivier Goffart wrote: I beleive that Thiago meant that JSON was out of question for describing the properties in the actual source. But i would not necessarily rule it out for storing the data. moc already export some data using Qt's binary JSON, so this is still a valid option. I would. I don't want qmetaobject.cpp to depend on JSON decoding. I already think it's a mistake that it depends on QByteArrayData, to the point that I run a binary-incompatible version of the meta object that has that removed. It's fine for JSON-encoded data to be stored in the meta-object, provided that it's completely transparent for QMetaObject family. If you do that, you'll need to get the char* from QMetaObject family, then pass it to QJsonDocument yourself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
-Original Message- Other people have suggested adding the info to the Q_PROPERTY expansion. This would avoid a sequence of Q_INFO / Q_PROPERTY pairs in the class that might be difficult to read: Q_INFO(foo, bar) Q_PROPERTY(int bar READ bar) Q_INFO(foo, baz) Q_PROPERTY(int baz READ baz) Right. I'd be fine with supporting something like Q_PROPERTY( ... INFO foo = bar) Though IMO that's way less easy to read. Would be fine as alternative syntax. I think foo = bar is easier to read. Why not use the same syntax for the regular Q_INFO annotations too: Q_INFO(foo = bar) I also think that the name Q_INFO is way too generic (everything in a source file is information, so it's just redundant). I would therefore prefer to just use Q_ANNOTATE. My last suggestion is to remove the quotes around the key. Having the key without quotes makes it fit in better with the rest of the information in the Q_PROPERTY macro. So summarizing my three suggestions we'd get: Q_ANNOTATE(foo = bar) and Q_PROPERTY( ... ANNOTATE foo = bar) In my mind, this is more readable. Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt installer - user register access
Hi Richard,
at the moment this usecase is not implemented and a shortcut to get the list
via the installer.value functions sounds wrong to me. So please create a
feature request for that at jira.
As a workaround you can use the execute feature:
registryCallOutput = installer.execute(reg, new Array(QUERY,
HKLM\\Software\\Microsoft\\Office))[0]
registryElements = registryCallOutput.split(\n)
for( var i = 0; i registryElements.length - 1; i++)
{
print(registryElements[i]);
}
Von: development-bounces+tim.jenssen=digia@qt-project.org
[development-bounces+tim.jenssen=digia@qt-project.org] im Auftrag von
Richard Gerd Kuesters [rich...@humantech.com.br]
Gesendet: Donnerstag, 5. September 2013 19:05
An: development@qt-project.org
Betreff: Re: [Development] qt installer - user register access
Thank you Jenssen!
I got all the way through this, but my problem is a little more specific. Well,
let's see if I can explain myself a little better.
We develop Autodesk plugins for our clients, mostly for their AutoCAD suite.
So, we need to detect if there's a installation present in the machine and it's
version, since we provide the facility to install for more then one instance of
the program (let's say, versions 2011, 2012, 2013, etc).
So, my routine is quite simple: I search for
HKEY_CURRENT_USER\Software\Autodesk\AutoCAD in the registry tree and need to
get its children directories, as a list or something, like R18.1, R19.0,
etc.
I'm sending a screenshot attached. I hope there's a way to retrieve that
information :)
Best regards,
Richard.
On 09/04/2013 12:20 PM, Jenssen Tim wrote:
See GlobalConfig at the operation documentation
http://doc-snapshot.qt-project.org/qtifw-master/operations.html
function Component() {}
Component.prototype.createOperations = function()
{
// call the base create operations function
component.createOperations();component.addOperation(GlobalConfig,
your_registry_path_on_windows_or_filename_on_*x, key, value)
}
This creates an operation which saves the old value (for unregistration) and
set the new value.
If you only want to check some variable to have some different behaviour in the
installer use:
installer.value(your_registry_path + / + your_key, your_default_value)
Hopefully this helps.
Cheers Tim
Von:
development-bounces+tim.jenssen=digia@qt-project.orgmailto:development-bounces+tim.jenssen=digia@qt-project.org
[development-bounces+tim.jenssen=digia@qt-project.orgmailto:development-bounces+tim.jenssen=digia@qt-project.org]
im Auftrag von Richard Gerd Kuesters
[rich...@humantech.com.brmailto:rich...@humantech.com.br]
Gesendet: Mittwoch, 4. September 2013 15:05
An: development@qt-project.orgmailto:development@qt-project.org
Betreff: [Development] qt installer - user register access
Hi all!
I've been working on top of Qt installer framework in the last week, so I could
drop the usage of NSIS. But, to do that, I need to access, in Windows, the user
registry (ex. HKEY_FOOBAR).
Is there a way to do this? I've search all over the place, and didn't find any
kind of example or code that can help me with that. Or maybe I didn't dig
enough :)
If someone can give me a hint, I'll be much obliged.
Kind regards,
Richard.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: [Interest] QAbstractEventDispatcher
Good morning,
I am attempting to use a Glib based library with Qt, it works
perfectly on Linux but on windows the application locks up.
I have gotten as far as realising that I need to use the
QAbstractEventDispatcher, that the qeventdispatcher_glib.cpp and
qeventdispatcher_win.cpp provide good examples.
It seems to me however that I need most of qeventdispatcher_glib.cpp
and just to insert the calls required for my library to interact with
the system. Is that a fair statement or would that be overkill for
reimplementing my own QEventDispatcher?
Regards
Phil Hannent
-- Forwarded message --
From: Thiago Macieira thiago.macie...@intel.com
Date: 5 September 2013 16:30
Subject: Re: [Interest] QAbstractEventDispatcher
To: inter...@qt-project.org
On quinta-feira, 5 de setembro de 2013 10:43:31, Phil Hannent wrote:
Good morning,
I am trying to implement my own event loop. I am trying to use
libpurple which uses glib with a Qt application I am developing [1].
On Linux the application runs fine. On windows the application is
unstable and will freeze. Working on the assumption that the Windows
version of Qt is not using the glib eventloop I set about
re-implementing the event loop using the QAbstractEventDispatcher.
Your assumption is correct. We don't use glib on Windows. We don't even search
for it.
2, There is a lack of good examples regarding Qt and 3rd party glib
implementations for which I believe the class was designed for.
There are less than 10 people in the world that need to implement event
dispatchers, including the people who wrote the ones in Qt. That's why it's
not very documented: too much effort for too little gain.
It's best just to read the code for the existing glib and Windows dispatchers
and ask questions here and in dev@. We'll do what we can to help.
I was ploughing ahead with it anyway on the basis that it would be a
good exercise, however I am getting lost. Such as the registerTimer
function [2], where is the timerId value from? I am using my own Id's
so could I clash?
[2]
http://harmattan-dev.nokia.com/docs/library/html/qt4/qabstracteventdispatch
er.html#registerTimer-2
Updated links:
http://qt-project.org/doc/qt-5.1/qtcore/qabstracteventdispatcher.html#registerTimer-4
http://qt-project.org/doc/qt-4.8/qabstracteventdispatcher.html#registerTimer-2
The ID is allocated by the non-virtual overload, which then calls the virtual
one. That is, QObject::startTimer calls this function:
int QAbstractEventDispatcher::registerTimer(int interval, Qt::TimerType
timerType, QObject *object)
{
int id = QAbstractEventDispatcherPrivate::allocateTimerId();
registerTimer(id, interval, timerType, object);
return id;
}
[Qt 5 code; in Qt 4, there's no timer type]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Interest mailing list
inter...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
signature.asc
Description: PGP signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable'
Hi, We are starting the preparations for the Qt 5.2.0 release, which means that: - We plan to merge 'dev' into 'stable' branch on September 23rd. - After Sept 23rd any changes that are required for 5.2.0 need to be pushed to the 'stable' branch. So if your changes are not in by that day, please wait until the merge is done and re-target it to the 'stable' branch. The repositories that will be part of the Qt 5.2.0 merge are: - qtactiveqt - qtbase - qtconnectivity [*] - qtdeclarative - qtdoc - qtgraphicaleffects - qtimageformats - qtlocation [1][*] - qtmacextras [2][*] - qtmultimedia - qtquick1 - qtquickcontrols - qtscript - qtsensors - qtserialport - qtsvg - qttools - qttranslations - qtwebkit - qtwebkit-examples - qtwinextras [*] - qtxmlpatterns - qtx11extras Cheers, [1]: pending status, see https://codereview.qt-project.org/65075 [2]: pending status, see https://codereview.qt-project.org/64435 [*]: since there is no 'stable' branch, we will create it out of 'dev' instead of doing a merge -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable'
Hi, Prior to this merge, will you merge stable into dev? It hasn't happened at least for qt5.git so far. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of Sergio Ahumada [sergio.ahum...@digia.com] Sent: Wednesday, September 11, 2013 12:42 To: development@qt-project.org Cc: releas...@qt-project.org Subject: [Development] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable' Hi, We are starting the preparations for the Qt 5.2.0 release, which means that: - We plan to merge 'dev' into 'stable' branch on September 23rd. - After Sept 23rd any changes that are required for 5.2.0 need to be pushed to the 'stable' branch. So if your changes are not in by that day, please wait until the merge is done and re-target it to the 'stable' branch. The repositories that will be part of the Qt 5.2.0 merge are: - qtactiveqt - qtbase - qtconnectivity [*] - qtdeclarative - qtdoc - qtgraphicaleffects - qtimageformats - qtlocation [1][*] - qtmacextras [2][*] - qtmultimedia - qtquick1 - qtquickcontrols - qtscript - qtsensors - qtserialport - qtsvg - qttools - qttranslations - qtwebkit - qtwebkit-examples - qtwinextras [*] - qtxmlpatterns - qtx11extras Cheers, [1]: pending status, see https://codereview.qt-project.org/65075 [2]: pending status, see https://codereview.qt-project.org/64435 [*]: since there is no 'stable' branch, we will create it out of 'dev' instead of doing a merge -- Sergio Ahumada Release Engineer - Digia, Qt ___ 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] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable'
On 09/11/2013 01:14 PM, Blasche Alexander wrote: Hi, Prior to this merge, will you merge stable into dev? It hasn't happened at least for qt5.git so far. -- Alex Hi, I merged stable-dev last Friday for most of the modules https://codereview.qt-project.org/64848 is the only one missing and I am planning to do a new merge this Friday. For qt5.git here you go https://codereview.qt-project.org/65191 Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: [Interest] QAbstractEventDispatcher
On quarta-feira, 11 de setembro de 2013 11:19:29, Phil Hannent wrote: Good morning, I am attempting to use a Glib based library with Qt, it works perfectly on Linux but on windows the application locks up. I have gotten as far as realising that I need to use the QAbstractEventDispatcher, that the qeventdispatcher_glib.cpp and qeventdispatcher_win.cpp provide good examples. It seems to me however that I need most of qeventdispatcher_glib.cpp and just to insert the calls required for my library to interact with the system. Is that a fair statement or would that be overkill for reimplementing my own QEventDispatcher? You need to write a qeventdispatcher_glib_win.cpp. The one that exists is a Unix-only dispatcher. In particular, you need to provide registering of Windows events (see QWinEventNotifier). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable'
On quarta-feira, 11 de setembro de 2013 12:42:50, Sergio Ahumada wrote: - After Sept 23rd any changes that are required for 5.2.0 need to be pushed to the 'stable' branch. So if your changes are not in by that day, please wait until the merge is done and re-target it to the 'stable' branch. Please note that the stable rules still apply after the merge: no new features can go into stable, be careful about large changes, etc. You may still change binary compatibility of new symbols and classes added since 5.1 until the final 5.2.0 release. Note the part about new features. If your feature isn't fully-implemented, documented, tested, with examples, and integrated by the branch, your feature will be left behind for Qt 5.3. If your feature is ready but only fighting CI for unrelated reasons, post an email. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
On Tuesday 10 September 2013 21:09:55 Peter Kümmel wrote: On 06.09.2013 19:52, David Faure wrote: connect(job, SIGNAL(result(QJob*)), this, SLOT(handleResult(QJob*))); This looks so old-school like in times of futures and monads. I'm an old-timer, clearly ;-) Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Can we forget about threads for a second? The main point of event-driven jobs is to have them use the event loop, NOT threads. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] Qt5::lrelease path issues (QTBUG-32570)
Using qttools-5.1.1... In short, Qt5LinguistToolsConfig.cmake ends up defining Qt5::lrelease to point to /usr/lib64/cmake/Qt5LinguistTools/bin/lrelease instead of /usr/lib64/qt5/bin/lrelease It would appear this was supposed to be fixed in 5.1.1, https://bugreports.qt-project.org/browse/QTBUG-32570 but apparently not? -- Rex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On Wed, Sep 11, 2013 at 2:33 AM, Olivier Goffart oliv...@woboq.com wrote: Hi, Great to see we are making progress. On Tuesday 10 September 2013 18:26:09 Stefan Merettig wrote: Alright guys, let's try to complete the feature. As I heard from sides now that you want a key-value store, I'll do it that way. Feature list: 1. Q_INFO is a new macro (which expands to nothing): #define Q_INFO(key, value) Since we have Q_CLASSINFO for classes. maybe we should call it Q_METHODINFO and apply it only for method. Then, for Q_PROPERTY, use a INFO as a keyword within the Q_PROPERTY syntax. I think it is easier to read. Let us compare again: Q_INFO(foo, bar) Q_PROPERTY(int bar READ bar) Q_INFO(foo, baz) Q_PROPERTY(int baz READ baz) Q_PROPERTY(int bar READ bar INFO foo = bar) Q_PROPERTY(int baz READ baz INFO foo = baz) I think this is too verbose. If we're already headed towards java-style annotations why not just have an annotate that can align with a Q_PROPERTY: Q_PROPERTY(int bar READ bar WRITE setBar) (this gives us a good, clear definition of the property) Q_ANNOTATE(bar, foo = baz, abc = cde) (this annotates the aforementioned property, and is a specialization of the normal Q_ANNOTATE, and can appear anywhere in the class definition) Matt You see the property name (more important) before the info. and everything is together. Then for enums, we can have Q_ENUMS(MyEnum MyOtherEnum INFO foo = bar) That would only be a problem if there is an enum called INFO, but i think we are safe, it is not the Qt style. Then we have everything, with nice syntax. 2. Q_INFO can be prepended to: - Classes - Signals, slots and Q_INVOKABLE methods (This includes c'tors) - Q_PROPERTY - Q_ENUM'd enums - So everything that is accessible through the meta system 3. Multiple Q_INFO annotations for a single object are possible 4. Each object has a unique key - value mapping. This means, that something like: Q_INFO(a, b) Q_INFO(a, c) void myFunc(); results in a single key - value mapping, not two values for a. 5. API Design: Pretty much a copy of QMetaClassInfo from the user standpoint, the class will be called QMetaInfo. Questions: 1. If Q_INFO can be applied to classes, then it's redundant to Q_CLASSINFO. On the one hand it's nice to have a unified API for annotations, on the other hand it's redundant, as Q_INFO doesn't have any benefits over Q_CLASSINFO anymore. 2. How should we store this? My current approach still stems from when Q_INFO supported multiple arguments. Technically possible, but not liked. As Thiago pointed out: JSON is out of the question. I'd like to stick to something like my current implementation. It boils down to having a table in the meta_data I beleive that Thiago meant that JSON was out of question for describing the properties in the actual source. But i would not necessarily rule it out for storing the data. moc already export some data using Qt's binary JSON, so this is still a valid option. That said, I think that having the info stored in the meta_data table, like Q_CLASSINFO is, is just fine. array with two columns for each object: start index, count At 'start index' there's a list of two integers for each Q_INFO record, the first pointing to the name, the second to the value. I'd like to use a third column there to store a currently unused flag. In my initial implementation which is also on gerrit I have a fourth field to store the value count, but with only a single one this can obviously be dropped if we don't plan to ever support this feature. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ 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] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
Hi,
From the whole discussion, this is what I believe it should look like:
class Foo {
/* For class annotations, we keep the Q_CLASSINFO as it is */
Q_CLASSINFO(foo, bar)
/* For properties, we put the annotation in the property macro */
Q_PROPERTY(int foo READ foo ANNOTATE foo = bar)
public slots:
/* Q_ANNOTATE macro in front of methods. */
Q_ANNOTATE(foo = bar) void mySlot();
};
No annotations for enums.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
Am 11.09.2013 21:49, schrieb Thiago Macieira:
On quarta-feira, 11 de setembro de 2013 12:03:52, Matt Broadstone
wrote:
Q_ANNOTATE(bar, foo = baz, abc = cde)
(this annotates the aforementioned property, and is a specialization
of the
normal Q_ANNOTATE, and can appear anywhere in the class definition)
Something like this is simply unparsable. Consider this example:
class Foo {
Q_ANNOTATE(bar = baz)
void foo();
}
This would be ambiguous to the reader. That's why I always stressed
that the
macro is *prepended* to whatever it applies to:
Q_ANNOTATE(foo = bar) class MyClass { ...
Sorry, I'm setting my foot down now: do not use Q_INFO / Q_ANNOTATE /
whatchamacallit for properties. Place the annotation inside the
Q_PROPERTY.
Compare the two proposals above:
Olivier used Q_INFO before Q_PROPERTY. Matt used Q_PROPERTY before
Q_INFO.
It's beyond me why we would like to set the name explicitly in the
macro.
Just think of overloaded methods .. Sounds like fun. I just want a
uniform
API for this, both in the Qt API and in the header file. While placing
the
annotation data in the Q_PROPERTY is a violation of this thought, I can
live
with it as long it's the only exception. Though I want to point out
that it's
confusing that Q_PROPERTY 'appends' this information while everything
else
has it prepended. Appending the annotation data to everything is too
hard to
read (Think of classes, would you ever look at the end to find a
annotation?)
and sometimes even dangerous:
void myFunc () Q_INFO(...) { .. }
void myFunc () { .. } Q_INFO(...)
Just think of future fun moments in #Qt because people put their
annotations
at the wrong position. A 'always prepend' rule is pretty simple to
communicate on the other hand, even with a exception for Q_PROPERTY.
class Q_INFO(Foo = bar) Q_DECL_EXPORT Q_DECL_ALIGN(16) Foo :
public Bar
{ };
See above.
I'm not sure which of those are valid syntax and which ones aren't;
which ones
apply to which, etc. Also, apparently there's a disagreement between
the GCC
syntax and the C++11 syntax.
Maybe I'm the only one with that problem, but the positions of C++11
attributes
and their implications confuses me all the time. That's why I
explicitly stated
that Q_INFO/Q_ANNOTATE is always prepended, that is, it's in front of
the
declaration itself. Nowhere else, simply because IMO it's the only
readable
version.
Something like:
void Q_INFO(...) myFunc();
void myFunc () Q_INFO(...);
void myFunc Q_INFO(...) ();
is barely readable.
Note: I used Q_INFO and Q_ANNOTATE here as I pleased. I'm fine with
both.
Also, do we agree that the current syntax is: Q_ANNOTATE(key =
value) ?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] constexpr and qMetaTypeId()
Hello,
I'd like to use qMetaTypeId() in a constexpr expression. I have my own
custom type declared as such:
class MyCustomClass : public QObject
{
Q_OBJECT
// ...
};
Q_DECLARE_METATYPE(MyCustomClass*)
I then try the following:
constexpr qint32 metaTypeId = qMetaTypeIdMyCustomClass*();
static_assert(metaTypeId != 0, boo, qMetaTypeId failed);
and I get the following compiler errors:
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:640: error:
'static constexpr int QMetaTypeId2T::qt_metatype_id() [with T =
MyCustomClass*]' called in a constant expression
return QMetaTypeId2T::qt_metatype_id();
^
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:532: 'static
constexpr int QMetaTypeId2T::qt_metatype_id() [with T =
MyCustomClass*]' is not usable as a constexpr function because:
static inline Q_DECL_CONSTEXPR int qt_metatype_id() { return
QMetaTypeIdT::qt_metatype_id(); }
^
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:532: error: call
to non-constexpr function 'static int
QMetaTypeIdMyCustomClass*::qt_metatype_id()'
static inline Q_DECL_CONSTEXPR int qt_metatype_id() { return
QMetaTypeIdT::qt_metatype_id(); }
^
Looking at the definitions for these functions in qmetatype.h, many of
these have the Q_DECL_CONSTEXPR macro, so I'm assuming this should work,
but it looks like QMetaTypeIdT::qt_metatype_id() is not marked
constexpr even though all the other functions that rely on it in this
case are.
Question: is this a bug? Is a Q_DECL_CONSTEXPR missing somewhere? I was
unable to find the definition of QMetaTypeIdT::qt_metatype_id() to
verify whether or not it is marked as constexpr. Given the prevalence of
Q_DECL_CONSTEXPR for many of these functions, I'm assuming the intent is
to be able to write something like the code I have written above, but
clearly, something isn't quite right.
Any help is greatly appreciated.
Thanks,
Alfonso
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
2013/9/11 Olivier Goffart oliv...@woboq.com: Alright guys, let's try to complete the feature. As I heard from sides now that you want a key-value store, I'll do it that way. Feature list: 1. Q_INFO is a new macro (which expands to nothing): #define Q_INFO(key, value) Since we have Q_CLASSINFO for classes. maybe we should call it Q_METHODINFO and apply it only for method. For the sake of clarity, I think the number of keyword/terms should be kept to a minimum. Q_INFO(key, value) could be, for classes, a drop-in replacement for Q_CLASSINFO(Key, value) Q_CLASSINFO, could be somehow deprecated in a distant future and new code advised to use Q_INFO instead. methods would then also use Q_INFO OR, Q_ANNOTATE, which sounds indeed better. class, methods, enums and properties can have annotations. That sounds simpler than having a specific mechanism for each object type moc supports. QMetaObject, QMetaProperty and QMetaMethods would have the following new methods: annotation() annotationCount(); annotationOffset(); indexOfAnnotation() QMetaObject would keep these methods as alias for compatibility purposes: classInfo() classInfoCount(), classInfoOffset(), indexOfClassInfo() QMetaAnnotation could be an alias of QMetaClassInfo until 6.x QMetaMethod::tag() could be dropped in 6.x, tags being irrelevant when having annotations, and the #define stuff was too hacky. Then, for Q_PROPERTY, use a INFO as a keyword within the Q_PROPERTY syntax. I think it is easier to read. Let us compare again: Q_INFO(foo, bar) Q_PROPERTY(int bar READ bar) Q_INFO(foo, baz) Q_PROPERTY(int baz READ baz) Q_PROPERTY(int bar READ bar INFO foo = bar) Q_PROPERTY(int baz READ baz INFO foo = baz) You see the property name (more important) before the info. and everything is together. It gets complicated if you want several annotations, and, it's not unified. Again, an universal syntax for annotation is simpler than having a syntax for class, one for methods, and one for properties/enums The it's too verbose argument makes little sense to me, I'd prefer something a bit more verbose but less confusing. Then for enums, we can have Q_ENUMS(MyEnum MyOtherEnum INFO foo = bar) annotations for enums sounds overkill. Q_ANNOTATE(foo, bar) Q_ENUMS(MyEnum) In both case, it's sounds insane to allow annotation in a Q_ENUMS / Q_FLAGS containing several items Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] New SceneGraph related issue
Hi, I have strange issue running most recent Qt sources on Tizen emulator (qemu i586). Also I know that there are issues with supporting HW acceleration. For example I need to export QML_BAD_GUI_RENDER_LOOP=1 because multithreaded OpenGl is a little broken there. Anyway: When I run simple Qml App (ApplicationWindow with rectangle) I get: QtHelloWorld: client_gl.c:1585: glGetBufferSubDataARB: Assertion `offset + size = buffer-size' failed. Aborted (core dumped) after setting (noopaque is significant because it prevents app from crash) QSG_RENDERER_DEBUG=render,build,change,upload,rootfs,dump,noalpha,noopaque,noclip I get: Batch thresholds: nodes: 64 vertices: 1024 Using buffer strategy: static dirty: Added RootNode 0x9ba3a58 dirty= 0 ) dirty: Matrix TransformNode( 0x9ba3a90 identity dirty= 0 ) dirty: Added Node( 0x9bc79b0 dirty= 0 flags= 1 ) dirty: Added TransformNode( 0x9bc73e0 identity dirty= 0 ) Updater::updateStates() - nodes have been added - transforms have changed RootNode 0x9ba3a58 dirty= 0 ) TransformNode( 0x9ba3a90 identity dirty= 0 ) Node( 0x9bc79b0 dirty= 0 flags= 1 ) TransformNode( 0x9bc73e0 identity dirty= 0 ) Node( 0x9bc72d8 dirty= 0 flags= 1 ) TransformNode( 0x9bc7498 identity dirty= 0 ) Node( 0x9bc76c0 dirty= 0 flags= 1 ) TransformNode( 0x9bc76f0 identity dirty= 0 ) Node( 0x9bc7808 dirty= 0 flags= 1 ) GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 TransformNode( 0x9bc7550 identity dirty= 0 ) Node( 0x9bc77a8 dirty= 0 flags= 1 ) TransformNode( 0x9bc7608 translate 0 600 0 dirty= 0 ) Node( 0x9bc77d8 dirty= 0 flags= 1 ) Renderer::render() QSGRenderer(0x9bc6528) rebuild: full Opaque render lists (complete) : - element: 0x9bc79e0 batch: 0x0 node: GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 order: 1 Alpha render list: (complete) : Opaque Batches: - Batch 0 0x9bc7ff8 upload root: 0x0 - element: 0x9bc79e0 node: GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 1 Alpha Batches: Uploading Opaque Batches: - batch 0x9bc7ff8 first: 0x9bc79e0 root: 0x0 merged: 1 positionAttribute 0 vbo: 0 : 76 - uploading element: 0x9bc79e0 GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 0x9bc7e78 48 64 -- Vertex Data, count: 4 - 12 bytes/vertex --- 0: 0:(2,float * 100 0 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 1: 0:(2,float * 0 0 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 2: 0:(2,float * 100 100 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 3: 0:(2,float * 0 100 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) -- Index Data, count: 6 --- 0 0 1 2 3 3 -- DrawSet: indexCount: 6 vertices: 0 z: 48 indices: 64 --- vertex/index buffers unmapped, batch upload completed... Uploading Alpha Batches: Rendering: - Opaque: 1 nodes in 1 batches... - Alpha: 0 nodes in 0 batches... - Breakdown of render time: preprocess=0, updates=0, binding=0, render=10, total=11 - Breakdown of frame time; sync: 0 ms render: 11 ms swap: 33 ms total: 46 ms time since last frame: 1 ms dirty: Matrix TransformNode( 0x9bc7498 identity dirty= 0 ) dirty: Matrix TransformNode( 0x9bc7608 translate 0 1280 0 dirty= 0 ) dirty: Matrix TransformNode( 0x9bc73e0 identity dirty= 0 ) dirty: Matrix TransformNode( 0x9ba3a90 identity dirty= 0 ) Updater::updateStates() - transforms have changed RootNode 0x9ba3a58 dirty= 0 ) TransformNode( 0x9ba3a90 identity dirty= 0 ) Node( 0x9bc79b0 dirty= 0 flags= 1 ) TransformNode( 0x9bc73e0 identity dirty= 0 ) Node( 0x9bc72d8 dirty= 0 flags= 1 ) TransformNode( 0x9bc7498 identity dirty= 0 ) Node( 0x9bc76c0 dirty= 0 flags= 1 ) TransformNode( 0x9bc76f0 identity dirty= 0 ) Node( 0x9bc7808 dirty= 0 flags= 1 ) GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 TransformNode( 0x9bc7550 identity dirty= 0 ) Node( 0x9bc77a8 dirty= 0 flags= 1 ) TransformNode( 0x9bc7608 translate 0 1280 0 dirty= 0 ) Node( 0x9bc77d8 dirty= 0 flags= 1 ) Renderer::render() QSGRenderer(0x9bc6528) rebuild: none Uploading Opaque Batches: - batch 0x9bc7ff8 first: 0x9bc79e0 root: 0x0 merged: 1 positionAttribute 0 vbo: 1 : 76 - uploading element: 0x9bc79e0 GeometryNode( 0x9bc7838 strip #V: 4 #I: 4 x1= 0 y1= 0 x2= 100 y2= 100 materialtype= 0xb77093e4 ) dirty= 0 0x9bc7e78 48 64 -- Vertex Data, count: 4 - 12 bytes/vertex --- 0: 0:(2,float * 100 0 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 1: 0:(2,float * 0 0 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 2: 0:(2,float * 100 100 ) 1:(4,ubyte 255 0 0 255 ) Z:(0) --- 3: 0:(2,float * 0
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On Wednesday 11 September 2013 07:41:03 Saether Jan-Arve wrote: I think foo = bar is easier to read. Why not use the same syntax for the regular Q_INFO annotations too: Q_INFO(foo = bar) I also think that the name Q_INFO is way too generic (everything in a source file is information, so it's just redundant). I would therefore prefer to just use Q_ANNOTATE. My last suggestion is to remove the quotes around the key. Having the key without quotes makes it fit in better with the rest of the information in the Q_PROPERTY macro. So summarizing my three suggestions we'd get: Q_ANNOTATE(foo = bar) and Q_PROPERTY( ... ANNOTATE foo = bar) In my mind, this is more readable. I actually like the ANNOTATE name much better than Q_INFO -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On quarta-feira, 11 de setembro de 2013 12:03:52, Matt Broadstone wrote:
On Wed, Sep 11, 2013 at 2:33 AM, Olivier Goffart oliv...@woboq.com wrote:
Q_INFO(foo, bar)
Q_PROPERTY(int bar READ bar)
Q_INFO(foo, baz)
Q_PROPERTY(int baz READ baz)
Q_PROPERTY(int bar READ bar INFO foo = bar)
Q_PROPERTY(int baz READ baz INFO foo = baz)
I think this is too verbose. If we're already headed towards java-style
annotations why not just have an annotate that can align with a Q_PROPERTY:
Q_PROPERTY(int bar READ bar WRITE setBar)
(this gives us a good, clear definition of the property)
Q_ANNOTATE(bar, foo = baz, abc = cde)
(this annotates the aforementioned property, and is a specialization of the
normal Q_ANNOTATE, and can appear anywhere in the class definition)
Sorry, I'm setting my foot down now: do not use Q_INFO / Q_ANNOTATE /
whatchamacallit for properties. Place the annotation inside the Q_PROPERTY.
Compare the two proposals above:
Olivier used Q_INFO before Q_PROPERTY. Matt used Q_PROPERTY before Q_INFO.
I call that mightily confusing. So Q_INFO applying to a Q_PROPERTY is out of
the question.
For the same reason, Q_INFO applying to the whole class while *inside* the
class body is also out of the question. It could be placed outside of the
class:
class Q_INFO(Foo = bar) Q_DECL_EXPORT Q_DECL_ALIGN(16) Foo : public Bar
{ };
Whoever wants to implement that, please study the C++11 attributes and GCC
attributes[1]. Note the differences below:
Q_INFO(x, y)
class Q_INFO(t, w) Foo : public QObject
{
Q_OBJECT
public slots:
Q_INFO(foo = bar)
void Q_INFO(a = b) slot1(),
Q_INFO(c = d) slot2();
} Q_INFO(blah, blubb)
obj Q_INFO(trailing, trailing);
I'm not sure which of those are valid syntax and which ones aren't; which ones
apply to which, etc. Also, apparently there's a disagreement between the GCC
syntax and the C++11 syntax.
[1] http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Attribute-Syntax.html
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On quarta-feira, 11 de setembro de 2013 22:19:33, Stefan Merettig wrote:
This would be ambiguous to the reader. That's why I always stressed
that the
macro is *prepended* to whatever it applies to:
Q_ANNOTATE(foo = bar) class MyClass { ...
I'm fine with that, provided it matches a place where the C++11 attributes can
be placed in a class declaration.
So:
$ clang -xc++ -std=c++11 -fsyntax-only - '[[foo]] class X {};'
stdin:1:1: error: an attribute list cannot appear here
[[foo]] class X {};
^~~
1 error generated.
$ gcc -xc++ -std=c++11 -fsyntax-only - '[[foo]] class X {};'
stdin:1:15: warning: attribute ignored in declaration of ‘class X’ [-
Wattributes]
stdin:1:15: note: attribute for ‘class X’ must follow the ‘class’ keyword
There we go, the matter is settled: the annotation must appear after the class
keyword, before the class name. An attribute placed before the class keyword
applies to a variable of that class type:
[[foo]] class X {} x, y; // [[foo]] applies to x and y
Let me see if I can decrypt for you N2761 (attributes rev6), plus the
amendments in N3067 which moved a few positions around:
[[foo]] class X {} x, y; // [[foo]] applies to x and y
class [[foo]] X {} x, y; // applies to type X
class X [[foo]] {} x, y; // ill-formed
class X {} [[foo]]; // ?? #1
class X {} [[foo]] x, y; // ?? #2
class X {} x [[foo]], y; // applies to variable x, but not y
class X {} x, y [[foo]]; // applies to variable y, but not x
[[foo]] void f(), g(); // applies to both functions f() and g()
void [[foo]] f(), g(); // ?? #3
void f [[foo]] (), g(); // applies to function f(), but not g()
void f() [[foo]], g(); // ?? #4
void f(), g [[foo]] (); // applies to function g(), but not f()
void f(), g() [[foo]]; // ?? #4
struct S {
[[foo]] S();// applies to the constructor S
[[foo]] ~S(); // applies to the destructor S
}
It seems that ?? cases 1 and 2 apply to class X, but not to type X. GCC
prints this warning:
warning: attribute ignored in declaration of ‘class X’
Cases 3 and 4 seem to be allowed and they apply to a type specifier. In all
four cases, I have no clue what they're used for.
It's beyond me why we would like to set the name explicitly in the
macro.
Just think of overloaded methods .. Sounds like fun. I just want a
uniform
API for this, both in the Qt API and in the header file. While placing
the
annotation data in the Q_PROPERTY is a violation of this thought, I can
live
with it as long it's the only exception.
Unfortunately, the problem is that there's no semi-colon or braces separating
Q_PROPERTYs from one another and from other declarations. So there's no way to
cleanly separate declaration from one another except for the parentheses
themselves.
Therefore, the annotation must come inside the Q_PROPERTY.
Though I want to point out that it's
confusing that Q_PROPERTY 'appends' this information while everything
else
has it prepended. Appending the annotation data to everything is too
hard to
read (Think of classes, would you ever look at the end to find a
annotation?)
and sometimes even dangerous:
void myFunc () Q_INFO(...) { .. }
void myFunc () { .. } Q_INFO(...)
The second one is a clear-case: the ending brace ended the declaration. So
that Q_INFO is applying to the *next* thing that appears:
void myFunc() { } Q_INFO(a = b)
void myOtherFunc() { }
The annotation belongs to myOtherFunc.
As for the first case, see above.
Just think of future fun moments in #Qt because people put their
annotations
at the wrong position. A 'always prepend' rule is pretty simple to
communicate on the other hand, even with a exception for Q_PROPERTY.
Understood, but since C++11 set the rule, people need to deal with it. I'd
much rather we explain once for both types of annotations than explain how
it's different.
Maybe I'm the only one with that problem, but the positions of C++11
attributes
and their implications confuses me all the time. That's why I
explicitly stated
that Q_INFO/Q_ANNOTATE is always prepended, that is, it's in front of
the
declaration itself. Nowhere else, simply because IMO it's the only
readable
version.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] constexpr and qMetaTypeId()
On quarta-feira, 11 de setembro de 2013 14:29:44, achart...@fastmail.fm wrote: Hello, I'd like to use qMetaTypeId() in a constexpr expression. You can't. The types are registered at runtime. Any help is greatly appreciated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable'
Hi, Could you please let me know if Qt3d repository to be part of Qt5.2? Thanks and Regards, Ramakanth -Original Message- From: releasing-bounces+ramakanthreddy_kesireddy=mahindrasatyam@qt-project.org [mailto:releasing-bounces+ramakanthreddy_kesireddy=mahindrasatyam@qt-project.org] On Behalf Of Sergio Ahumada Sent: 11 September 2013 16:13 To: development@qt-project.org Cc: releas...@qt-project.org Subject: [Releasing] HEADS UP: Starting preparations for Qt 5.2.0 - merge 'dev' into 'stable' Hi, We are starting the preparations for the Qt 5.2.0 release, which means that: - We plan to merge 'dev' into 'stable' branch on September 23rd. - After Sept 23rd any changes that are required for 5.2.0 need to be pushed to the 'stable' branch. So if your changes are not in by that day, please wait until the merge is done and re-target it to the 'stable' branch. The repositories that will be part of the Qt 5.2.0 merge are: - qtactiveqt - qtbase - qtconnectivity [*] - qtdeclarative - qtdoc - qtgraphicaleffects - qtimageformats - qtlocation [1][*] - qtmacextras [2][*] - qtmultimedia - qtquick1 - qtquickcontrols - qtscript - qtsensors - qtserialport - qtsvg - qttools - qttranslations - qtwebkit - qtwebkit-examples - qtwinextras [*] - qtxmlpatterns - qtx11extras Cheers, [1]: pending status, see https://codereview.qt-project.org/65075 [2]: pending status, see https://codereview.qt-project.org/64435 [*]: since there is no 'stable' branch, we will create it out of 'dev' instead of doing a merge -- Sergio Ahumada Release Engineer - Digia, Qt ___ Releasing mailing list releas...@qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
