Re: [Development] A QtCore class for event-driven jobs
Full agreement with Konstantin. It's two weeks before the feature freeze and we haven't seen any more then a draft. I am against any new classes going into Qt essential modules that do not have direct and proven use cases. Develop it in a playground project, show why it makes sense and once you have a stable API let's discuss into which module it should go. Cheers, Lars From: Konstantin Ritt ritt...@gmail.commailto:ritt...@gmail.com Date: tirsdag 10. september 2013 00:40 To: development@qt-project.orgmailto:development@qt-project.org development@qt-project.orgmailto:development@qt-project.org Subject: Re: [Development] A QtCore class for event-driven jobs 2013/9/9 Sune Vuorela nos...@vuorela.dkmailto:nos...@vuorela.dk The api has been stabilized and well tested since like forever. Let's get a QAbstractJob heavily inspired by KJob in now. A nice side effect of getting it in now is that the myriad of nice frameworks KDE is preparing for ship could be built on QAbstractJob and KDE could skip shipping KJob and move everything over to QAbstractJob now and not after we in KDE has made our first release where we promise to keep ABI and API stability. That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can use it by only linking to QtCore. Once released, it's API become frozen up until 6.0...and you don't really care about all others who may disagree with it's design or simply can not use it due to it's limited API and so on. All I've seen so far (following by David's links) is a piece of KIO where some API is still hardcoded to be used by KIO. I'd say this is not a 5.2 material at all. Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or usable drafts at very least. Until then, I'm all in doubts about how useful would that be to the user. In example, David said job's doStart() enqueues the runnable in the thread pool; now looking at the code - it seems like we could have then started() signal emitted, say, 5 seconds earlier than the runnable gets dequeued and executed. So `for (int i = 0; i 100; ++i) (job = someoperation(params))-start();` gives us 100 started jobs where only few of them got dequeued and really started; and thus all other jobs can not report their actual execution state change because they were started and become started, once dequeued by worker thread...weird, isn't it? First of all, put the initial implementation to Qt-project as a module. Let's then gather such a use-cases and see where the current API is not sufficient, then polish the API to make QJob usable in all those cases; let's write some QJob-s based demonstration framework and polish the API once again, if needed... and only then we'll see if it is good enough for QtCore. Kind regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars On 06.09.13 15:52, Sorvig Morten morten.sor...@digia.com wrote: I agree, QtWin::foo looks much better. We can rename the QtMacExtras namespace as well. What about the module name itself? Would we still say import QtWinExtras and #include QtWinExtras/QWinFunctions? Morten On Sep 6, 2013, at 11:49 AM, Nurmi J-P jpnu...@digia.com wrote: I also very much like the idea of sticking the conversion functions right into the respective classes in QtCore and QtGui. At least QtWinExtras still has lots of helper methods that do not fall into this category, though. All that Windows specific window blurring, peeking, colorization etc. stuff will remain in QtWinExtras, and I'd still prefer QtWin as the namespace for those methods. So my original question still remains valid - can we rename the QtPlatformExtras namespaces to QtPlatform? Friedemann already prepared the first step for QtWinExtras: https://codereview.qt-project.org/#change,64803. -- J-P Nurmi On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: Yes yes a thousand times yes! On 9/3/13 14:41 , Sorvig Morten wrote: I think the advantages of having these functions available in QtCore/Gui outweighs the risk of customers accidentally using platform-dependent code. Maintenance will be easier since there is less code duplication. Morten On Sep 2, 2013, at 11:38 PM, Joseph Crowell joseph.w.crow...@gmail.com wrote: Most of the functionality was already in Qt 4 and was moved out for Qt 5 because of maintenance issues and different code for different platforms exposed to the customer. On 02/09/2013 10:35 PM, Sorvig Morten wrote: I agree the Extra looks superfluous. In fact I'd like to go a bit further and suggest we don't have platform extras at all and instead integrate the functionality into Qt: - Conversion functions for types in QtCore to QtCore - Conversion functions for types in QtGui to QtGui - Widgets to QtWidgets - Non-trivial implementation to the platform plugin - etc. I've prepared a set of patches showing how (for parts of QtMacExtras): https://codereview.qt-project.org/64342 https://codereview.qt-project.org/64343 https://codereview.qt-project.org/64344 https://codereview.qt-project.org/64345 https://codereview.qt-project.org/64346 Notes: - The platform extras will continue to exist as research playgrounds. - This approach works for platforms that has an Q_OS #define - The function header is named qmacfunctions.h, the namespace is QMac - We can now use the public NSString conversion functions in QtCore when implementing rest of Qt. - Conversion functions in QtCore And Gui can be used without bringing in QtMacExtras and its widgets dependency One case is still unsolved: classes that wrap native UI elements but are neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar for example). A possible solution could be to add the implementation to the platform plugin and add public API in QtWidgets and Qt Quick Controls. QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are basically API wrappers around the implementation in QCococaWindow. Morten On Aug 30, 2013, at 3:27 PM, Jake Petroules jake.petrou...@petroules.com wrote: +1 from me for doing it everywhere, including in the library names. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@digia.com wrote: Hi all, While we still have a chance to tweak things before releasing 5.2, I'd like to re-open the discussion about platform extras naming. Short version: Could we rename the QtMacExtras QtWinExtras namespaces to just QtMac QtWin? (QtX11Extras namespace doesn't exist, at least yet) Long version: The current status: - Classes: QPlatformFoo - QX11Info (*) - QMacNativeWidget, ... - QWinTaskbarButton, ... (*) The only thing in QtX11Extras - already released in Qt 5.1. - Stand-alone function namespaces: QtPlatformExtras::toType() - QtWinExtras::toHBITMAP(), ... - QtMacExtras::toCGImageRef(), ... I'm not entirely happy with how the current stand-alone function namespaces look in application code. I would find it prettier if we dropped the Extras part from the namespace names. IMHO that would still remain distinctive enough, just making it look more professional and... convenient to type. :) if (QtWinExtras::isCompositionEnabled()) // ... vs. if (QtWin::isCompositionEnabled()) // ... Open questions: - What about the headers? - Could #include QtMacExtras/qmacfoo.h also become QtMac/qmacfoo.h? - QX11Extras/QX11Info was already released - so it would have to remain as a compatibility header if we chose the latter - What about the lib names? Should we keep
Re: [Development] A QtCore class for event-driven jobs
On Mon, Sep 9, 2013 at 11:40 PM, Konstantin Ritt ritt...@gmail.com wrote: 2013/9/9 Sune Vuorela nos...@vuorela.dk The api has been stabilized and well tested since like forever. Let's get a QAbstractJob heavily inspired by KJob in now. A nice side effect of getting it in now is that the myriad of nice frameworks KDE is preparing for ship could be built on QAbstractJob and KDE could skip shipping KJob and move everything over to QAbstractJob now and not after we in KDE has made our first release where we promise to keep ABI and API stability. That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can use it by only linking to QtCore. Once released, it's API become frozen up until 6.0...and you don't really care about all others who may disagree with it's design or simply can not use it due to it's limited API and so on. +1 -- Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] WebView for Android on track for Qt 5.2?
Thanks for the additional information. I'm not an export on OpenGL but if I give it a try I'll report my findings here. Cheers, Conny On Mon, 2013-09-09 at 05:52 +, Abrahamsen-Blomfeldt Eskil wrote: Hi, So far there hasn't been much research on this, but the idea was to render it into a texture and use this in the QML scene graph, yes. Any experience you collect on this will probably be very helpful. I think the path forward may be to make an Android-specific API for this that can easily be adapted to a cross-platform API later. That gives us a bit more flexibility as we do not have to commit to a cross-platform API right away. I can't give any promises as for the Qt version this will be targeted at yet, but I do understand that it's a very important feature, so I definitely want to have it as soon as at all possible. Here's a blog which might be helpful if you're going to be looking at this: http://anuraagsridhar.wordpress.com/2013/03/13/rendering-an-android-webview-or-for-that-matter-any-android-view-directly-to-opengl/ -- Eskil -Opprinnelig melding- Fra: Cornelius Hald [mailto:h...@icandy.de] Sendt: 6. september 2013 16:15 Til: Abrahamsen-Blomfeldt Eskil Kopi: development@qt-project.org Emne: Re: [Development] WebView for Android on track for Qt 5.2? On Fri, 2013-09-06 at 10:41 +0200, Eskil Abrahamsen Blomfeldt wrote: On 09/05/2013 06:18 PM, Cornelius Hald wrote: Hi guys, what is the state of WebView (QQ2) for Android? Is it still planed for Qt 5.2? Is there a branch to track somewhere? The bug report suggests that instead of using QtWebKit a wrapper around the Android-WebView is now planned. https://bugreports.qt-project.org/browse/QTBUG-32093 Anything I could help you with? Hi, I've talked to the team working on the web engine in Qt in Digia, and right now there are no resources to do work on this in Digia unfortunately. It might be possible to do something specifically for Android, but it would be a lot nicer to have a cross-platform solution like the web engine guys initially planned, and I think this is needed for iOS as well. I'll talk to the iOS team here, but I don't think it sounds feasible that this will be done in the one and a half weeks we have left before the Qt 5.2 feature freeze. Sorry :( -- Eskil Hi Eskil, thank you for your fast reply. Of course that wasn't the answer I was hoping for but at least I can be sure now. I have two projects running on Windows and Linux. Both I should port to Android as soon as possible. Are there any known workarounds? Like using the Android WebView and rendering it into a GL texture that could be used with QQ2? I only need output. No input or interaction. I will research my options but would be very grateful for any hints and tips. Also it would be great to know for what Qt version it is planned to have a working WebView on Android. Thanks! Conny ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Bug] git fetch is failed
Hello guys, At attempt to do fetch, git failed, e.g.: ... User@Host /e/git/ng/789/qtserialport (stable) $ git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/27/64927/1 git checkout FETCH_HEAD efrror: RPC failed; result=22, HTTP code = 503 atal: The remote end hung up unexpectedly ... What it an error? Best regards, Denis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Bug] git fetch is failed
Hello, You can try the SSH command instead of the Anonymous HTTP command. (Don't know why it isn't working) Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] p#229; vegne av Denis Shienkov [scap...@yandex.ru] Sendt: 10. september 2013 15:34 To: development@qt-project.org Emne: [Development] [Bug] git fetch is failed Hello guys, At attempt to do fetch, git failed, e.g.: ... User@Host /e/git/ng/789/qtserialport (stable) $ git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/27/64927/1 git checkout FETCH_HEAD efrror: RPC failed; result=22, HTTP code = 503 atal: The remote end hung up unexpectedly ... What it an error? Best regards, Denis ___ 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] [Bug] git fetch is failed
On 09/10/2013 03:34 PM, Denis Shienkov wrote: Hello guys, At attempt to do fetch, git failed, e.g.: ... User@Host /e/git/ng/789/qtserialport (stable) $ git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/27/64927/1 git checkout FETCH_HEAD efrror: RPC failed; result=22, HTTP code = 503 atal: The remote end hung up unexpectedly ... What it an error? Best regards, Denis Hi, I got this error as well (it doesn't happen with all changes) I will request Gerrit to be restarted, that should fix the problem. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Bug] git fetch is failed
Guys, thanks in any case. I was logged in, but for the unknown reason was active the Anonymous HTTP button instead of SSH. After switching to SSH - all works. Thanks. Best regards, Denis 10.09.2013, 17:58, Sergio Ahumada sergio.ahum...@digia.com: On 09/10/2013 03:34 PM, Denis Shienkov wrote: Hello guys, At attempt to do fetch, git failed, e.g.: ... User@Host /e/git/ng/789/qtserialport (stable) $ git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/27/64927/1 git checkout FETCH_HEAD efrror: RPC failed; result=22, HTTP code = 503 atal: The remote end hung up unexpectedly ... What it an error? Best regards, Denis Hi, I got this error as well (it doesn't happen with all changes) I will request Gerrit to be restarted, that should fix the problem. Cheers, -- 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] Qt Platform Extras
On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? Comparison with other namespaces: http://qt-project.org/wiki/Qt_5_Structure Earlier discussion on this topic: http://thread.gmane.org/gmane.comp.lib.qt.devel/7464/focus=7634 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
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) 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 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. Have a nice day, Stefan Merettig ___ 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,
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.
(Sidenote: In this case, multiple INFO's should be allowed to appear)
key - value mapping, not two values for a.
Why?
Because that's my definition of having multiple values for a single
key,
something which the ML was against. The current preview on gerrit
supports
that already and has everything on-board which is needed for a addition
like allowing multiple values per key. Letting the user who uses the
meta
information in the end try to figure out if there are more than one
values for a single key sounds tedious and bogus. We could as well do
it in
QMetaInfo then without introducing any complexity. (Proposal:
class QMetaInfo {
const char *name() const;
const char *value(int index = 0) const;
int valueCount() const;
};
)
other hand it's redundant, as Q_INFO doesn't have any benefits
over
Q_CLASSINFO anymore.
I prefer Q_CLASSINFO.
Alright, I'm fine with that as long the features of Q_INFO and
Q_CLASSINFO are
the same basically. If Q_INFO supports multiple values per key though
I'd like
to see both.
How do you associate the method ID or property ID with an info?
That's simple actually. I take my preview code as example. As we know
which
object types can be annotated, I have a hard-coded sequence which is:
Class, signals, slots, Q_INVOKABLEs, c'tors, Q_PROPERTYs, enums
Each category has as much entries as the meta system knows about them,
so
if we have 5 slots, there are 5 entries for this category. The 'Class'
category
has a constant item count of one. This creates a table, where each
object
stores 'start index' and 'count'. 'start index' points to the first
entry
which stores the Q_INFO data, and count shows how many Q_INFO
annotations this
object has. Now, at this 'start index', we have another table in the
form:
name, flags, argc, values ...
'name' is the annotation name, 'flags' is unused (always zero) and
'argc' tells
the reader how many values this annotation has - Thus 'values' is of
dynamic
length. This introduces a minor performance penality while reading
annotations
of the same object, but nothing else.
This sounds complicated at first, but first API tests with Q_INFO
access
integrated into QMetaObject show that it's actually nice to work with.
For visualization, see this moc'd example:
Header file: http://pastebin.com/wYihYjPt (Note: Still the old syntax)
meta data table: http://pastebin.com/i1AHpzFa
I paid greater attention to not break anything else. The change in the
header
is no big deal in this case as the parser will simply skip it. The
whole
Q_INFO meta data is only stored if it's used anywhere at least once. If
it's
not used, then both fields in the header are zero.
If only a single value per key is allowed we could of course simplify
the
payload table. Though this doesn't come with any real benefits. The
only
difference between allowing:
Q_INFO(foo, bar) Q_INFO(foo, baz) void myFunc();
and
Q_INFO(foo ARGS bar, baz) void myFunc();
is that the first one is more verbose and offers a opportunity for a
typo.
That's my two cents on that discussion.
___
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 terça-feira, 10 de setembro de 2013 19:27:48, Stefan Merettig wrote:
Hi,
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.
(Sidenote: In this case, multiple INFO's should be allowed to appear)
Sure.
I think INFO in the Q_PROPERTY is easier to read, but that's my opinion.
key - value mapping, not two values for a.
Why?
Because that's my definition of having multiple values for a single
key,
something which the ML was against. The current preview on gerrit
supports
that already and has everything on-board which is needed for a addition
like allowing multiple values per key. Letting the user who uses the
meta
information in the end try to figure out if there are more than one
values for a single key sounds tedious and bogus. We could as well do
it in
QMetaInfo then without introducing any complexity. (Proposal:
class QMetaInfo {
const char *name() const;
const char *value(int index = 0) const;
int valueCount() const;
};
)
Oh, sorry, I don't think I was clear.
I meant that you should allow this:
Q_INFO(a, b) Q_INFO(a, c)
void foo();
That means QMetaInfo is exactly like QMetaClassInfo:
const char *name() const;
const char *value() const;
QMetaMethod, QMetaProperty and QMetaEnum have an indexOfInfo() that returns
any of the QMetInfo whose name() matches the search key. If there are more
than one, it is undefined which one it returns.
How do you associate the method ID or property ID with an info?
That's simple actually. I take my preview code as example. As we know
which
object types can be annotated, I have a hard-coded sequence which is:
Class, signals, slots, Q_INVOKABLEs, c'tors, Q_PROPERTYs, enums
Each category has as much entries as the meta system knows about them,
so
if we have 5 slots, there are 5 entries for this category. The 'Class'
category
has a constant item count of one. This creates a table, where each
object
stores 'start index' and 'count'. 'start index' points to the first
entry
which stores the Q_INFO data, and count shows how many Q_INFO
annotations this
object has. Now, at this 'start index', we have another table in the
form:
name, flags, argc, values ...
'name' is the annotation name, 'flags' is unused (always zero) and
'argc' tells
the reader how many values this annotation has - Thus 'values' is of
dynamic
length. This introduces a minor performance penality while reading
annotations
of the same object, but nothing else.
This sounds complicated at first, but first API tests with Q_INFO
access
integrated into QMetaObject show that it's actually nice to work with.
Ok, understood. That makes sense. Except for argc.
For visualization, see this moc'd example:
Header file: http://pastebin.com/wYihYjPt (Note: Still the old syntax)
meta data table: http://pastebin.com/i1AHpzFa
See above: I don't think we want argc.
If only a single value per key is allowed we could of course simplify
the
payload table. Though this doesn't come with any real benefits. The
only
difference between allowing:
Q_INFO(foo, bar) Q_INFO(foo, baz) void myFunc();
and
Q_INFO(foo ARGS bar, baz) void myFunc();
is that the first one is more verbose and offers a opportunity for a
typo.
--
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] Making QScopedPointer scoped (again)
On 05.09.2013 12:10, Daniel Teske wrote: QScopedPointer has never been a scoped pointer. It has always had a .reset() method. That should never have been part of QScopedPointer. I wonder if this would happen again with the current review process. daniel# ___ 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 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. Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Peter ___ 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 10.09.2013 20:28, schrieb Thiago Macieira: 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. (Sidenote: In this case, multiple INFO's should be allowed to appear) Sure. Agreed. Oh, sorry, I don't think I was clear. I meant that you should allow this: Q_INFO(a, b) Q_INFO(a, c) void foo(); That means QMetaInfo is exactly like QMetaClassInfo: const char *name() const; const char *value() const; Ah, sorry for that. I'm fine with that for now, the only little behaviour I want to add to this is the guarantee, that values appear sorted by their key in the same sequence they appear in in the code. So it behaves like a QMultiMap. Ok, understood. That makes sense. Except for argc. argc is overrated - Noted. I think we figured out everything now. I'll start implementing everything in moc first and then do the needed changes in the Qt API, except for the meta object builder classes for now. Will see when I can get to this, but I'll do it before Sunday. ___ 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 10.09.2013 08:16, Knoll Lars wrote: Develop it in a playground project, show why it makes sense and once you have a stable API let's discuss into which module it should go. An idea I already had when I saw the QUniquePoiner implementation: Couldn't we add a new branch to dev/stable/release, which is open for very experimental code? Creating a playground project just for one class is too complicated, and most people would not give them a try, but only switching a branch lowers the barrier a lot. We could base the branch on stable, so it is a good starting point for experiments, and it would be easy to try out these new features without the hassle of checking out (multiple) other repositories, or by cherry-picking stuff. Peter Cheers, Lars From: Konstantin Ritt ritt...@gmail.com mailto:ritt...@gmail.com Date: tirsdag 10. september 2013 00:40 To: development@qt-project.org mailto:development@qt-project.org development@qt-project.org mailto:development@qt-project.org Subject: Re: [Development] A QtCore class for event-driven jobs 2013/9/9 Sune Vuorela nos...@vuorela.dk mailto:nos...@vuorela.dk The api has been stabilized and well tested since like forever. Let's get a QAbstractJob heavily inspired by KJob in now. A nice side effect of getting it in now is that the myriad of nice frameworks KDE is preparing for ship could be built on QAbstractJob and KDE could skip shipping KJob and move everything over to QAbstractJob now and not after we in KDE has made our first release where we promise to keep ABI and API stability. That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can use it by only linking to QtCore. Once released, it's API become frozen up until 6.0...and you don't really care about all others who may disagree with it's design or simply can not use it due to it's limited API and so on. All I've seen so far (following by David's links) is a piece of KIO where some API is still hardcoded to be used by KIO. I'd say this is not a 5.2 material at all. Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or usable drafts at very least. Until then, I'm all in doubts about how useful would that be to the user. In example, David said job's doStart() enqueues the runnable in the thread pool; now looking at the code - it seems like we could have then started() signal emitted, say, 5 seconds earlier than the runnable gets dequeued and executed. So `for (int i = 0; i 100; ++i) (job = someoperation(params))-start();` gives us 100 started jobs where only few of them got dequeued and really started; and thus all other jobs can not report their actual execution state change because they were started and become started, once dequeued by worker thread...weird, isn't it? First of all, put the initial implementation to Qt-project as a module. Let's then gather such a use-cases and see where the current API is not sufficient, then polish the API to make QJob usable in all those cases; let's write some QJob-s based demonstration framework and polish the API once again, if needed... and only then we'll see if it is good enough for QtCore. Kind regards, Konstantin ___ 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
On terça-feira, 10 de setembro de 2013 21:03:24, Stefan Merettig wrote: Ah, sorry for that. I'm fine with that for now, the only little behaviour I want to add to this is the guarantee, that values appear sorted by their key in the same sequence they appear in in the code. So it behaves like a QMultiMap. I'd rather you didn't do that. Just let it be undefined which order they appear in and which one indexOf finds. I'd even go so far as to say there's no guarantee that they are sequential. Starting from there, we choose which behaviours we need to define so that the feature is useful and usable. Also note that you're contradicting yourself. If you have code: Q_INFO(a, b) Q_INFO(foo, bar) Q_INFO(a, c) void func(); Then QMultiMap will move the middle element away. That is, it does not keep insertion order of elements with different keys. So you'll probably have to define that behaviour and choose between one of: a) all items are kept in declaration order b) all items with same key appear sequentially What does Q_CLASSINFO do? Ok, understood. That makes sense. Except for argc. argc is overrated - Noted. I think we figured out everything now. I'll start implementing everything in moc first and then do the needed changes in the Qt API, except for the meta object builder classes for now. Will see when I can get to this, but I'll do it before Sunday. -- 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 terça-feira, 10 de setembro de 2013 21:01:51, Peter Kümmel wrote: On 10.09.2013 08:16, Knoll Lars wrote: Develop it in a playground project, show why it makes sense and once you have a stable API let's discuss into which module it should go. An idea I already had when I saw the QUniquePoiner implementation: Couldn't we add a new branch to dev/stable/release, which is open for very experimental code? Creating a playground project just for one class is too complicated, and most people would not give them a try, but only switching a branch lowers the barrier a lot. We're using Git, you can create your clone and publish it anywhere you'd like. See all my experimental code: http://qt.gitorious.org/qt/thiago-intels-qtbase/ Everything is in the master branch. This branch rebases often. If you want to publish your own class for QtCore, do that as well. People can fetch and merge/cherry-pick your change in their trees. I don't like the idea of a shared, experimental branch. How often will it get nuked and cleaned, or rebased? Who approves stuff there? It also gives the impression that the code will someday make into the release, which is not a given. -- 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
Am 10.09.2013 22:26, schrieb Thiago Macieira: What does Q_CLASSINFO do? From looking at the code, it maintains the order of entries. The documentation of QMetaClassInfo doesn't say anything on this. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira thiago.macie...@intel.comwrote: On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. I believe he is aware of that... I think, Sze please correct me if I am wrong, he just wanted to make sure because there was several emails last year about QFoo or QtFoo for the namespace, and it seemed that the suboptimal naming was chosen for other reasons. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
