Re: [Development] Question about QCoreApplicationData::*_libpaths
On 22-1-2016 22:51, Kevin Kofler wrote:
I'd already be happy with those that were (are, actually) already
there. I'd rather have 10-20 common algorithms with a convenient API
than 80+ obscure ones that force me to use iterators (especially the
boilerplate .begin() and .end() iterators that will be used in 99+% of
the cases – copy programming sucks).
Please note that the algorithms in STD are by no means complete. You are
stimulated to add your own that you find useful, either as
specializations or combinations of what is already there, as
implementations of known algorithms in literature or even completely new
ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent).
Stephanov has seen his original design of STL been significantly
shortened to get it through the commission; the proposal included much
more than what is in STD even now after the more recent additions.
So, by all means, add what you deem useful.
I certainly agree that having to write begin/end pairs for all
algorithms is not nice. It is the most general way to specify them
however, so I understand why they are like this. And it even makes sense
for some of them (like find, where you can then call find again using
the return value of the last call to get the next match). Even for sort
there certainly are use cases for a pair of iterators instead of passing
the whole container. Still, it would make perfect sense to create
versions that take a whole container. I don't even think that that is
hard to do...
template < class Container, class Compare >
void sort ( Container container, Compare compare)
{
sort(begin(container), end(container), compare);
};
Something like that perhaps? Feel free to add as many as you think are
useful.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
On 23-1-2016 17:39, Milian Wolff wrote: On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote: Marc Mutz wrote: And this is where I stop taking you seriously, sorry. You can demand such nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ algorithms from the STL for Qt. Or play god deciding which are the ones "no- one will ever need" or "should never use" - IYHO. I'd already be happy with those that were (are, actually) already there. I'd rather have 10-20 common algorithms with a convenient API than 80+ obscure ones that force me to use iterators (especially the boilerplate .begin() and .end() iterators that will be used in 99+% of the cases – copy programming sucks). You should educate yourself by watching a few of Sean Parent's talks and it will become clear that most of these "obscure ones" are actually very applicable in many scenarios where you currently write handwritten loops which are probably not as efficient and well-tested as the STL implementations. The code also becomes more self-explaining by using algorithms. I can certainly agree with that one! Google for No Raw Loops for instance. Also, there are a lot of classes by Stephanov online that are quite educational (A9 published a couple of series on YouTube). There is even one where Sean Parent comes to talk to Stephanovs class there. It is an extended version of the No Raw Loops talk you'll find elsewhere. It pays off to familiarize yourself with these algorithms. You can use them more often than you think. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
On 21-1-2016 21:09, Milian Wolff wrote: On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: Op 21/01/2016 om 05:35 schreef Thiago Macieira: On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: Thiago Macieira wrote: The copy constructor is called once, then the move constructor. If value_type's move constructor is not noexcept, then it may throw after the container resized. Throwing an exception in a move constructor is really, really horrible. I can see why a copy constructor would throw (out of memory, failure to duplicate some other resource), but a move? Indeed. But the class in question may not have a move constructor. In the absence of one, the copy constructor gets called. I generally don't care. If I can't copy anymore due to running out of memory, I'm pretty much done anyway. No reliable way to recover from that. Might as well terminate the program. Right, _you_ don't care. But as a library one cannot usually make such claims. People may want to use it in conditions where they _do_ care, and for good reason. It would be a shame if C++ would not be applicable for such scenarios just because some people didn't care enough. So, please, enlighten me. What would be a realistic way to recover from such an exception? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On 27-7-2015 18:13, Thiago Macieira wrote: On Monday 27 July 2015 08:44:30 Knoll Lars wrote: I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. As I said in my email, the problem is that you will not turn this on for those 10% of the cases until you've already lost data, either visibly or really. I'm counting ambiguity and homographs as apparent data loss because it will send you down the wrong debugging path. In that case, I think your solution _causes_ data loss when debugging path-related issues in Windows. If paths get their separators doubled all of a sudden, then that is certainly going to send people down the wrong debugging track. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 27-7-2015 18:21, Thiago Macieira wrote: On Monday 27 July 2015 08:01:53 André Somers wrote: I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On 12-7-2015 19:56, Smith Martin wrote: If it doesn't, then why not choose QVector? My intent in getting the information from Marc is to change the documentation of QList to say that. But QList is easy to use. How is it easier to use than QVector? I will grand you two: QList is two characters less to type than QVector, so QList has the definite advantage there. Other than that, now that the API is basicaly synchronized, I don't see much benefit in QList over QVector. And 2) that Qt's own API often returns a QList and not a QVector... Perhaps QList needs to implicitly convert to a QVector so it become easier to make the transition in user code? Then, if Qt itself changes its API in Qt 6 to use QVector instead of QList, the users' code will just work :-) André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On 13-5-2015 2:44, Thiago Macieira wrote: On Wednesday 13 May 2015 02:34:28 Jan Kundrát wrote: Hi, this commit [1] added a new overload to QTextStream::readLine. As a result of that, calling stream.readLine(0) is now ambiguous: QString readLine(qint64 maxlen = 0); bool readLine(QString *line, qint64 maxlen = 0); While I can easily fix this in the caller (Konsole in this case), I'm wodnering whether this effect was understood at the time the change was merged. IMHO it's a bit more user-friendly to preserve source compatibility by removing the default value in the newly added overload. Should I send such a patch? Why write readLine(0) when it's the same as readLine() ? readLine(0) seems to me that it's asking for a line of at most zero bytes -- we should have had this argument default to -1 to indicate maximum length, not 0. Removing the default argument for the new overload will make it worse, by making people have to write the zero when they mean unlimited. I don't like that. The two options I will consider are: a) do nothing, accept and document the source incompatibility b) modify differently so that the new API isn't ambiguous but doesn't require people to write 0 either. In the spirit of option b), would it be an option to have the method take a QString instead of a QString*? That would resolve the ambiguity. It also makes it clear that it makes little sense to call the method without an actual QString to store the results in. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
On 8-5-2015 18:47, Hausmann Simon wrote: Hi, If the public API would allow you to implement what the folks at KDAB did at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ , would that help your use case? What they basicaly did was reimplement the Quick elements they were using, if I understood it right from an earlier time I read that blog, and then solve all kinds of issues with rendering that were already solved inside Qt itself... So, it comes down to implementing the elements of Quick 1 on your own again for the elements you need, or something close to it. It is what I called major work in my first reply. And indeed: I guess doing this requires heavy use of private API. So far, QML and Quick are not all that friendly for C++-side extensions... I read about an effort of a different rendering backend for Quick a while ago done by Digia at that time that sounded like it could work to solve the issue, but that was not freely available to take a look at so I don't know for sure it would fit the use case. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 15-4-2015 16:54, Keith Gardner wrote:
On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz marc.m...@kdab.com
mailto:marc.m...@kdab.com wrote:
Hi André,
On Wednesday 15 April 2015 11:49:56 André Somers wrote:
void MyClass::setFoo(QString value)
{
PropertyGuard guard(this, foo); //foo is the name of the
Q_PROPERTY
Q_UNUSED(guard);
m_foo = value;
}
This is an interesting idea, though I don't think I have
encountered the
problems with which you motivate PropertyGuard.
For use in a library, though, I fear the string-based mechanism is too
inefficient. For use within QtWidgets, say, I'd suggest a
mechanism that works
on the member data directly.
Thanks,
Marc
I have actually run into the same situation and made a template class
that owns the variable. Its constructor takes an initial value and a
std::functionvoid (const T) as a callback for when the value
changes. The callback can be a lambda or a std::bind to the expected
signal. I also added overloads to allow for the templated class to
behave just like the contained type so that it can be swapped in
easily. I figured the Qt project wouldn't like the submission of the
class due to its template nature and its use of std::function but i am
willing to share it if anyone is interested.
I'd certainly be interested to seeing how you solved this, yes. Thanks!
André
___
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] RFC: RAII for property changes
On 15-4-2015 17:08, Matthew Woehlke wrote:
On 2015-04-15 10:43, Marc Mutz wrote:
On Wednesday 15 April 2015 11:49:56 André Somers wrote:
void MyClass::setFoo(QString value)
{
PropertyGuard guard(this, foo); //foo is the name of the Q_PROPERTY
Q_UNUSED(guard);
m_foo = value;
}
This is an interesting idea, though I don't think I have encountered the
problems with which you motivate PropertyGuard.
For use in a library, though, I fear the string-based mechanism is too
inefficient. For use within QtWidgets, say, I'd suggest a mechanism that
works
on the member data directly.
FWIW I had the same thought; also, I'm not a fan of needing the
Q_UNUSED, or using a macro to 'hide' it.
What about something like this?
QPropertyGuard g{this};
g.addProperty(a); // use QObject::property
g.addProperty(b, m_b); // take value member by reference
g.addProperty(m_c, cChanged); // ...and also slot address
It's slightly redundant because declaring the guard and adding a
property are separate, but there is no unused object, and you can use
the same guard for multiple properties.
The implementation is trickier (probably you need a dynamically
allocated templated helper class with a virtual base to store the value
and check for changes), but avoids multiple string-based look-ups.
The slot could be a functor, like QObject::connect accepts, that could
be any of the actual slot, std::function, lambda, etc.
I'm not sure I understand your solution, or what it yields over what I
am using now. Of course what I do is not using multiple string lookups.
The property is looked up once on construction of the guard object. Then
the current value is copied as a QVariant, as it is made available
through the property system. The signal meta-method is also stored from
the constructor, so the destructor can use it. So, only one
string-lookup needed per property. The elegance is that it uses the
property system to get the value *and* the notification signal to
trigger, so it is really easy to use.
The need for a Q_UNUSED is inherent in any RAII class that you don't
explicitly use any more. It works without, but you get a warning about
an unused variable which is annoying. QMutexLocker suffers from the same
problem.
I also don't like using a macro much, but it does yield quite an elegant
way to say what you want I think. It also hides the explicit reference
to this. You can still use the explicit way too of course, especially if
you want to access the guard object afterwards (you can cancel it and
access the original value for instance).
I am currently not seeing a need to trigger anything else than the
notification signal, but I guess that could be added if there is a need
for that.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 15-4-2015 18:44, Matthew Woehlke wrote: The second form would thus save the value - QVariant comparison and not much else. The third form however eliminates the string look-up entirely by having the user provide both the backing member variable *and* what to do when a change should be emitted. (I'd expect this to be the change signal most of the time, but taking a functor adds the flexibility of allowing users to do other things if needed.) Right, of course. That may be useful indeed. Thank you for your feedback, it is apreciated! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 15-4-2015 21:05, Keith Gardner wrote:
QPropertyGuard g{this};
g.addProperty(a); // use QObject::property
g.addProperty(b, m_b); // take value member by reference
g.addProperty(m_c, cChanged); // ...and also slot address
There's type erasure going on, so it will allocate memory.
Allocating memory
in a setter that might just change an int is what I call inefficient.
Would something like this be better?
// constructor
// Provide an initial value and a std::function to notify about the change
Propertybool m_example = Propertybool(false, [](bool value){
emit exampleChanged(value);
});
// getter
bool *::example() const {
return m_example;
}
// setter
void *::setExample(bool value) {
m_example = value;
}
The working code for this example can be found
https://github.com/kreios4004/Property_Class.
Thank you for posting that.
I took a look at it, but I am not sure it actually solves much. It moves
the check if something changed to the wrapped variable, but it makes
using that value then more complicated. Instead of using the variable
directly, one now has to go through m_example.getValue() everywhere. Not
pretty, I think. The case of modifying more than one property in one go
is also not solved. On the one hand, dependent properties (such a
isValid property) are not updated unless you manually write that code
again, and on the other hand if you use this to set more than one
property in a method, you still are sending signals at the point the
class is in an inconsistent state.
One nice side effect of my implementation is that the notification is
actually only send once. Even if the property value is changed multiple
times in the meantime, you still get only one notification. That can be
very convenient, even if you don't use it much.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New company name for Qt part of Digia and unified web site
On 16-9-2014 20:50, Knoll Lars wrote: On 16/09/14 16:51, Mark Gaiser mark...@gmail.com wrote: On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars lars.kn...@digia.com wrote: Hi everybody, I’m happy to tell you that we’re making significant progress towards the new unified web page that I’ve first been talking about at the contributor summit. We just launched the first stage of it on http://qt.io. For now qt.digia.com is going to redirect to it. I hope you will like the new web page. Please have a look and give us your feedback. In addition, we also now have a new company name for the Qt part of Digia. It’s simply ‘The Qt Company’. For more details check out my blog at http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unif ie d-website-and-20e25-monthly-indie-mobile-package/ and of course http://qt.io Moving forward, we would like to slowly move some more pieces that are now on qt-project.org over to qt.io. We don’t have concrete plans yet on when and what will move, but would probably want to start with simple things such as the documentation. Any feedback on this is of course also more than welcome. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development I like the site! It looks clear and to the point imho. But i kinda fail to see the point in having - yet another - domain for Qt. I mean, we've had: - Trolltech - qt.nokia... - qt.digia... - qt-project and now we have qt.io. Yes, it's a nice short domain, but having domain changes every few years or so isn't very good for the search results. I can assure you that worse search results is the last thing we want to get. We can do all changes incrementally, and ensure that search engines can follow. What hurt us most in the past was that similar content was distributed over several sites (like the Qt docs that were still on nokia.com for a long time). Worse, we couldn't do anything about the content on some of the other sites. Our goal here is to make sure we get to one authoritative place where you can find all relevant information. We can then add relevant redirects and other hints to make sure search engines will be able to follow nicely. What was wrong with qt-project in that respect? And what is the status of that site (and project) now then? It sounds a bit like the xkcd standards comic [1]: adding a new domain to unite all the information from the existing ones... André [1] http://xkcd.com/927/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation)
On 4-9-2014 18:26, Thiago Macieira wrote:
On Thursday 04 September 2014 13:03:12 Saether Jan-Arve wrote:
Somebody already suggested to embed it as a resource, isn't that good
enough?
As long as we also load it by default. We cannot depend on users loading the
translation file from the resource system.
Fine. Load it by default.
Imagine an application that is only run in English (no L10n) and for
which the source code has proper, English messages. Will it occur to
the developers that they have to provide the en_US translation file
from Qt?
No, it won't. We need to get rid of that file.
If we get rid of it we have to provide an alternative way of providing those
plural forms, preferably in some language-agnostic API (since Qt does not
constrain you to write your source text in English). Unfortunately there
are up to 6 different plural forms in some languages, and the rules to
know which to pick differs greatly depending on the language.
I'm saying we need a convenience for us, so we don't have to ship a
translation file, and we write Qt source in English. This convenience could
also be used by most software, since they are also written in English.
If you write your language source in another language with different plural
rules, you'll need to use the existing overload and provide a translation from
your language back to your language again.
That sounds rather short-sighted to me.
It means that an inconsistency is introduced for no good reason at all.
If you want to have something that works for English only, it would be
rather trivial to write a free function like this:
QString singularOrPlural(QString singular, QString plural, int value) {
if (value == 0 || qAbs(value) 1) {
return plural;
}
return singular;
}
There you go, there's your special tr version. To me, it sounds rather
silly to abuse tr() to do something you explicitly say is meant for
those *not* using i10n or i18n. I really see no need to litter Qt this
way. Note that if you go ahead using the special tr function, you cannot
simply translate anyway any more. The string and its arguments may be
different than what you'd have if you wanted to take translation into
account from the start. As Qt itself will have to deal with translations
anyway, I also don't see a gain in Qt itself.
..or alternatively we need to be clarify our documentation to explicitly
mention that this plural-form-translation feature requires a translation to
be installed, even in English.
Which is what I don't want. This basically requires everyone to always load
the Qt translation, even if their apps aren't l10n'ed.
So? If they forget, they'll end up with 1 file(s) found instead of 1
file found or 2 files found. Big deal.
One only need to provide a translation file for the case you are describing
if the application developer uses the plural translation feature. If that
feature is not used, the translation file is not needed in your case. I
assume if an application developer uses that feature, he should also have
read its documentation. And if his plural translations doesn't work I would
expect him to read that part again. And if he still doesn't manage to
deploy the translation file after that, the user will still see Found 1
item(s) instead of Found 1 item, which is not the end of the world,
really.
Agreed.
But I'm assuming from your previous message that we use the feature in Qt's
own sources. Therefore, every single application uses the feature.
A quick search for %n in the Qt .ts files would reveal that. I don't
have them here, or I would take a peek.
But even so: Qt could pre-load the Qt .qm file by default from an
internal resource, and I guess that makes sense. There is no need for a
special tr() version to do that.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
Matthew Woehlke schreef op 11-3-2014 17:04: On 2014-03-11 05:01, Pasion Jerome wrote: Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 documentation to Qt 5 documentation. Subsequently, we will remove the 5.0 and 5.1 documentation from qt-project.org and we will place future Qt 5.x documentation in Qt 5 (http://qt-project.org/doc/qt-5/). How am I then supposed to find the 5.x documentation if I am developing an application against 5.x but the latest release is 5.y? It's common practice to keep old documentation available so that users can have a correct view of the state of the software /as of the version they are using/. If you don't do this, you *MUST* accurately document every *change* (not just additions) between versions and have that documentation clearly visible in the documentation of the affected classes/methods/etc. (Plus, I know from experience that \since is easily overlooked.) Indeed. It seems like a Bad Idea(TM) to me. People looking into the Qt 5 documentation will likely encounter the 5.0 version. Harmonizing the directories into one means that online viewers will always view the latest Qt 5 documentation. That can be solved easily by having /doc/qt-5/ symlinked on the server to the latest 5.x. I would also encourage doing like python.org and adding a widget to select the documentation version. You could also add a big noisy warning to the historic documentation pages. B)Multiple directories hinders the search results. A single directory for Qt 5 documentation increases traffic to the /doc/qt-5/ directory. Currently, the /doc/qt-5.1 and /doc/qt-5.0 directories are taking away viewers from the main Qt 5 content. So don't allow these to be indexed? I know there are ways to tell search engines to not index certain pages... That would suck too... As the on-site search for the docs is quite bad, I resort to using the Qt Doc Search extension for Chrome to search for documentation with the right version. That works quite well, but would break if either the old docs are removed they are not allowed to be indexed any more. I seriously don't see the benefit of this harmonization. When I look at the docs for a class, I often just look for method names that seem to do what I need. That usually works very with Qt. Now, I will need to go check for every method if it actually exists in the version of Qt I'm on, by looking for a since tag. How is that helping me to become more productive? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Need suggestion for a new API
Mandeep Sandhu schreef op 31-1-2014 13:47: Hi All, I needed a suggestion on an API I'm adding to QNetworkAccessManager and co. I'm adding a HTTP redirect feature to QNAM. It can be enabled at a global (QNAM) level, or can be enabled/disabled on a per request (QNetworkRequest) basis. The per-request setting, if set, overrides the global one otherwise uses whatever is set in the global setting. The default value of the global setting is false, i.e don't follow redirects. The QNAM setting can be a simple bool which defaults to 'false' if not explicitly set by the user. However, the request level setting needs 3 states - true (follow redirects), false (don't follow) and unset (use global setting). I was thinking I can have the request level setting as a 'pointer to a bool' which is uninitialized (NULL) if a user does NOT explicitly set the behaviour for the request or is initialized to whatever value is passed (true/false). But this would mean allocating space for a pointer etc, though I can manage it with a scoped pointer. Or else I could have an enum in the request class identifying these 3 states (I don't want to add an enum for such a simple thing). Any other suggestions on how this could be handled? I don't think that using a pointer to a bool would be good API. myRequest-setFollowRedirects(true); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(false); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(0); //what does this mean? vs. myRequest-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); //perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::AlwaysFollow); // perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::NeverFollow); //perfectly clear myQNam-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); // undefined, should fail I guess The enum way would be way clearer, and allows for extension later if needed. I would use the same enum at both levels, documenting that using the FollowGlobal value does not make sense at the QNAM level and perhaps using an assert on that one. Note that if you use an enum at the API surface, that does not mean you *have* to use the enum internally as well. Not that a pointer to a bool is smaller than an enum, but... The enum solution would allow for something like this to be added: myRequest-setFollowRedirects(QNetworkAccessManager::OnlyFollowWithinDomain); //if such a thing would make sense André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
Op 6-9-2013 19:56, Matt Broadstone schreef:
On Fri, Sep 6, 2013 at 1:52 PM, David Faure david.fa...@kdab.com
mailto:david.fa...@kdab.com wrote:
I would like to propose the inclusion of a QJob class in QtCore,
based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation
into a job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket
(like akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an
IDE, unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(),
calling pure
virtual methods doStart() and doKill(), and signals, most
importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually
prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on
jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing,
for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge
warning about not
using that in GUI apps (ideally only to be used in unittests or
separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows
generic GUIs
to be built on top, so that your app or your desktop can show the
progress of
multiple concurrent jobs, of different types (file download, CD
burning, mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support
sub-jobs.
The job implementation would choose when to create these subjobs
(all at once
initially, to have them run in parallel, or one after the other,
for sequence
of operations). KDE currently does that in a subclass
(KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have
it all in
one class instead.
We also have a standard interface for error handling so that all
jobs from a
given framework can have their error handled the same way, but
thinking about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to,
and to gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods
for getting
the value, even available as casting-to-the-value. If we imagine a
QFuture
that wraps a QJob, and the blocking method calling exec(), we'd
have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's
really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is
completely
different: a runnable is one sync method, while a qjob is all
signals/slots
based, with start() returning immediately. So one can't be used
like the
other, a given task implementation is either a blocking task for a
thread with
no event loop (QRunnable) or an async task that can actually be
used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob
subclass. So
instead, I propose to wrap QNetworkReply into a QNetworkJob or
something, in
order to offer the QJob interface for QNAM requests. On one hand
this doesn't
have to go in at the same time as QJob itself, but OTOH it could
be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
+1, or more if possible :)
Is this code up somewhere already for early review? This is very much
needed in Qt imho, I imagine it's
Re: [Development] New online installers available for testing
Op 31-5-2013 11:50, Heikkinen Jani schreef: Hi all! There is new online installers available in http://download.qt-project.org/online/qt5/online_installers/ http://download.qt-project.org/online/qt5/online_installers/ At the moment content is Qt5.0.2 but it will be updated to Qt5.1 RC1 when it is published (hopefully really soon). Please try those and give us feedback if those work or if you face some issues. Br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development MinGW on windows 7 seems to work. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 4-3-2013 21:21, Thiago Macieira schreef:
On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote:
QFutureT runFunction(QFunctionT then, QFunctionT main);
QFutureT runFunction(QFuntionvoid then, QFuntionT main);
QFutureT runFunction(QFunctionT main);
I think this is going too far. If you want to chain jobs, we need a more
complex job tracker. That's what ThreadWeaver is trying to do. But we need to
solve a simpler problem first.
And besides, you can always do:
QFutureWatcherT w = runFunction(...);
w.connect(QFutureWatcherT::finished, []() { other function goes here });
w.connect(QFutureWatcherT::finished, w, QObject::deleteLater);
The point is not to chain jobs. Indeed, that is what threadweaver is
doing. I am sorry if I did not make the point clear. The point is not to
create complex chains (or really: networks) of jobs. ThreadWeaver
already supports that use case. Still, I suppose you could do something
like that. The lines I wrote however were not meant as a chain, just as
different versions of the same method with a then method taking a
parameter of the type of the function, a then method without a parameter
and a call without any then argument.
The point is to get notification when a job is done in the simples way
possible. Nothing more, nothing less, without having to check the status
of the future. The way I understand QtConcurrent, the work is started
immediately and may finish at any moment. So, by the time I create the
QFutureWatcher and added the connect, the work may already be done.
Right? That means that you have to check for that as well, or you risk
missing the finished signal. See the discussion on the trampoline object
elsewhere in this thread. You'd avoid that by passing what you want
happening directly to the invocation to QtConcurrent.
The resulting code using a then argument would be much simpler than what
you post above. I don't quite get that code at all, by the way. You seem
to be creating a QFutureWatcher on the stack, and still connecting to
its deleteLater method? Also, which method directly returns a
QFutureWatcher? The QtConcurrent I'm familiar with returns a QFutureT,
which you can assign to a QFutureWatcher.
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code. It also doesn't create big constraints on the
type of object returned from these functions: there is no need for them
to be QObjects themselves.
If you want more control or need more information, you'd still create a
QFutureWatcher of course, as it provides more information than a simple
done.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 22-2-2013 11:57, Sze Howe Koh schreef:
Some more common use case would be (pseudo-code)
auto watcher = new QFutureWatcher;
QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
watcher-setFuture(QThrerad::run([]() { return computeStuff(); } ));
// who deletes the watcher?
If the caller creates the watcher, I think it's fine to let the caller
delete it too. It's an ordinary C++ practice.
Actually, how do you feel about adding an optional _then_ argument to
the list of arguments of the functions in QtConcurrent and whatever is
decided to replace the QtConcurrent::run feature? Such a _then_ argument
could be a slot signature, a function pointer or a lambda function
(basically, whatever you can use in the Qt 5 QObject::connect). That
would make it quite a bit easier to work with, I think. It would
eliminate the need to create (and delete) a QFutureWatcher for a lot of
cases. The method you passed into the _then_ argument would be called
when the future is ready. It would be very nice if the _then_ argument
could optionally have an argument of the return type of QFuture::result.
For this to work, QFuture would not need to be a QObject itself, and
because you pass in the _then_ argument with the call itself, you don't
have the race issues that you get if you need to connect in separate
calls after you have already fired off the thread: no need for
trampoline objects or the like.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Hebrew
Op 1-2-2013 17:41, Genghis Khan schreef: On Fri, 1 Feb 2013 09:26:24 + Knoll Lars lars.kn...@digia.com wrote: On Jan 31, 2013, at 4:13 PM, Genghis Khan genghisk...@gmx.ca wrote: Hello, I would like to initiate a new group http://qt-project.org/groups called Qt Hebrew for Hebrew speakers, where new and potential Hebrew speaking contributors to Qt and to Qt software will be able to join and to share their point of views on translations and report issues concerning to RTL (Right to left) alignment in software. Sure, local groups are always welcome. I disagree. At least where there are forums attached to the group. There should be a real need for a group with a dedicated forum to be created. That means that a community of some mass can be expected to make use of it. Also, there needs to be capacity to moderate the forum in question. I don't think we currently have a moderator in the team that speaks Hebrew. Due to a severe and deliberate depression of access for new Hebrew speaking contributors to Free Software projects, by certain entities and personalities, I find the need of such group very important. At least from the Qt Project perspective there is no such thing as trying to keep certain groups/nationalities away. We're a technical project and open to everybody who shares our interest in Qt and related technologies. Yes, of course. The purpose of another FOSS group is to be a safe heaven to newcomers or an opposition to current depressors at FOSS amongst Hebrew speakers. Come on, please. Don't make unfounded accusations into the wild like this. Either tell us what you mean (where do you see such opposition and depression?) or don't bring it up at all. Notably: do you see such problems inside the Qt community? I would like the administrator or on of the administrators to be Diego Iastrubni who is translating for KDE, who has a healthy approach with translations against daily communications and is welcoming. Have you talked to him about it? I know Diego since a long time, and he would certainly be a good person to lead the group. No, not yet. Once a group will be created I will ask Diego to join. Since Diego is a busy person, I did not want to bother him due to not knowing whether a group will or will not be created. Thank you. Sorry, but it doesn't work that way. You can apply for new groups through the proper channels, and you can't expect us to just add somebody that you have not even spoken to yet as a moderator for you. You can apply for a new group on qt-project.org as soon as you gain enough points. See the http://qt-project.org/ranks page for details. Decisions on what groups are created and who is to moderate them are not taken in this list. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
Op 30-1-2013 19:34, Robin Burchell schreef: On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada s...@sansano.inf.utfsm.cl wrote: How many changes do you need to close a jira task ? one, two, more, who knows ? The person submitting the change. The way I've seen this done various other places is to stop trying to overload all bugtracker metadata into a single keyword (Task-number) and instead split out the precise meanings (Fixes actually fixes it, Addresses works towards, but does not close - for instance). Yep, I have seen that work rather well, on Assembla for instance. The bugtracker gets a nice comment attached with a link to change automagically, and if the magic keyword is used together with the bug number, the status is modified automatically. I guess the trick for Qt would be though to make sure that the status is only changed (to fixed) if the fix is merged in a branch that will actually be released. Other commits with such a tag may get rejected through Gerrit, or fail to integrate somehow, and that should not lead to issues falsely reported as fixed in Jira of course. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
Op 30-1-2013 21:19, Shaw Andy schreef: Just to muddy the waters here, but would it be possible to make sure it only does this when the patch integrates? What happens if the bug is reopened because it turns out to be still be an issue? Andy That can always happen, even after releasing. I don't see the issue with that. The bug would be re-opened, and the next patch that gets integrated with the right magical text in the commit message adds another comment again and may again change the status. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Changes in QStyle subclasses
Op 24-11-2012 12:09, Nurmi J-P schreef: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Does this also mean that you will remove void QApplication::setStyle(QStyle* style)? This API seems useless if you can't create actual style instances any more because they are public. On the other hand, I think that that may cause issues for some applications... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFileSystemWatcher and Recursive Monitoring
Op 28-7-2012 11:04, d3fault schreef: I've been thinking about it some more, and I think it would be a good idea to add another optional bool to the opt-in custom interface constructor. Having (series of) bools in API's is usually a bad idea. See for instance this blog posting: http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html So it now would be: QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter *userCustomSnapshotComparisonCode, bool alwaysUseCustomFigureOuterEvenIfPlatformDoesntNeedIt = false, QObject *parent = 0); The reason for the additional bool is that we cannot predict what criteria a _user_ will use to determine a file changed. They may ignore certain changes that the native platform would emit, which will lead to inconsistencies in their application on platforms with native support vs. those without. The bool allows them to opt to take control of every platform so there aren't any inconsistencies. It defaults to false because most of the time the user will want to use the much more efficient native platform notifications when available. We need a pretty beefy class description explaining all this. That's exactly the problem. In my view, these things should not be needed in the constructor at all. Instead, make the whole thing property based. That is: make the user-class that you plug into the QFileSystemWatcher something that you can just get and set. There are other examples of this in the Qt API, for instance in working with delegates in itemviews. By default, there will be a delegate set on an item view, but you can set your own if you want. The same goes for QItemSelectionModel: an instance is created by default, but you can just set another one if you want. The benefit is that: 1) it is all very explicit in the code. It is easy to understand what happens 2) it does not get in the way of those not using it 3) it allows initializing in any order that makes sense to the user It would be nice if the system default object doing the work, if there is such a thing, would be available from the API and you could get it from the QFileSytemModel. That would make it possible to use the default implementation from the custom one. So, instead of complicated constructors, I'd suggest some normal API methods instead: //say, QAbstractFileSystemBuffer is the class (interface) that takes care of tracking the file system changes void setFileSystemBuffer(QAbstractFileSystemBuffer* buffer); // QFileSystemModel takes ownership QAbstractFileSystemBuffer* getFileSystemBuffer(); // simply returns a pointer to the object QAbstractFileSystemBuffer* takeFileSystemBuffer(); // releases ownership of the object That makes this possible: QFileSystemWatcher* watcher = new QFileSystemWatcher(this); // MyFileSystemBuffer can use the standard implementation to do much of the work... MyFileSystemBuffer* buffer = new MyFileSystemBuffer(watcher-takeFileSystemBuffer()); watcher-setFileSystemBuffer(buffer); //watcher takes ownership of the buffer André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Op 16-7-2012 23:52, Thiago Macieira schreef: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. That being the case, would it be possible to at least document these issues properly then? I think it is not all that clear from the documentation that QList is so inefficient for these cases. I don't think documentation changes are binary incompatible ;-) André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Op 27-6-2012 22:17, Иван Комиссаров schreef: Hm... What about adding new (maybe rather simple) widgets? QtCreator has QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my own modified copy). Browser example has ModelMenu and ModelToolBar classes (rather useful in some cases). Recently, I implemented Windows menu (popup menu with list of top-level windows and actions to minimize/maximize/change current window). I can add these classes to QtWidgets, if needed. IMHO, it's nice to have color button in Designer, for example. I'd like to suggest that additional widgets, unless they represent a very important addition so that Qt can support a now-common UI design pattern, are not added to QtWidgets but to an addon module. With the lack of a maintainer (let alone a set of them), I think it does not make sense to complicate the module even more. I think the widgets you mention may be useful in some applications, but it is not like they will be used all over the place. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Summit 2012 Registration is now open!
Op 14-4-2012 12:08, Sivan Greenberg schreef: On Fri, Apr 13, 2012 at 8:57 PM, Quim Gilquim@nokia.com wrote: Still a third party from a Qt Project point of view but I guess one that you are more used to trust. Sorry, it was the fastest and simplest way to save us from handling emails manually. Who is the third party in that case? Gitorious, I assume, as that is the hosting party of qt-project.org, right? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping the Q prefix from class names
Op 2-4-2012 1:02, joao.abeca...@nokia.com schreef: Hello again, To every-concerned-one-of-you, I hope you do realize that we share all of those same concerns. We do! :-) I really enjoyed this joke. Thanks! :-D André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] videoPlayer crashed
Hi Brian, 1) It is rude to hijack somebody elses thread. The thread you are replying in is about a request for a UI Helpers repository, not about Phonon. 2) You're in the wrong mailing list. This list deals with developing Qt *itself*, not with developing *with* Qt. You are looking for the inter...@qt-project.org mailing list or the Qt Developer Network (Qt DevNet) at http://developer.qt.nokia.com (for now). André Op 18-2-2012 6:30, Brian Li schreef: Dear all： I'm learning to use the Phonon in QT, followed up some examples in the help document to setup one VideoPlayer, but when running this programe, it always crashed, the example is so simple I don't known where is wrong. ___ 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
Re: [Development] Qt Contributors Summit: when and where
Op 3-1-2012 19:48, marius.storm-ol...@nokia.com schreef: On 03/01/2012 12:25, ext Jonas M. Gastal wrote: On Tuesday 03 January 2012 18:11:08 marius.storm-ol...@nokia.com wrote: On 03/01/2012 11:14, ext Quim Gil wrote: - When? There have been different opinions and the trend seems to be that it is better to do it after Qt 5 is released, otherwise people will be too stuck with bugfixing and pressure to release. But we can't do it in the middle of Summer holidays either. This would send us to late August - September. This is the critical point, all feedback is welcome. If we'd follow last year as a template, it would be Thursday June 14th - Saturday June 16th. I have my doubts if doing it then or after summer matters much time-wise. Everyone will always have plenty to do anyways. I think doing it after the release of Qt 5.0 could be good in the sense of giving the summit more focus, if we do it after we can use the summit as a forum to discuss the direction we want to take 5.1 in. If the summit happens before 5.0 the focus will be split. It would be well after the feature freeze anyways, so features discussed at the summit would have to be targeted 5.1 anyways. I think we need to get into a rhythm. The plan is to have Qt releases pretty regularly; every 6 months or so. So, with that in mind, I think we should aim to also keep the Contributor Summits also regular, and set a month when we would want it to happen. Personally, I think it would be good with releases before summer, not after. So then a before summer summit could (/should?) coincide with an actual release. I like having the summit before the summer, since it might give contributors not backed by a company the chance to work on fun and important things during the summer, if they'd want to. (Schools out, and they are looking fun projects!) It could also be an important meeting for Google Summer of Code candidates, for some face to face chat with the community before the summer starts. I agree with the timing for another reason: doing it after summer would put the event too close to the Qt DevDays. While that is a different type of event, it is another venue where you meet your fellow Qt developers. Last year, we also had contributor meetings during these events. It would be useful to keep them a bit apart, unless you actually put them back-to-back. I think that also makes it easier to get company funding for trips to visit these events. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Contributors Summit: when and where
Op 3-1-2012 21:14, Richard Moore schreef: - How many rooms, which capacity? No need to get into details but having a rough idea would be useful in order to book the right amount of space. For you this means what type of event do you want: was the event last year good or would you prefer a different distribution? For us booking the venue it has clear implications in the contract and the budget. Last year I got the impression that the number of rooms were fine, but the size of (some of) the rooms were not. Some sessions had people standing up against the wall, and sitting on the floor, and too little ventilation. Lets not do that again. Yes, I think we need a few bigger rooms than we had last year. We had lots of rooms that were good for small sessions, but the big ones were totally overfull which was no fun for anyone. Agreed. However, how you figure out what session to put in what room? Last year, the format was that of an unconference. How you choose what room to put your session in? It is hard to estimate the number of interested people for any session in such a setup. I, for one, was (pleasantly) surprised by the interest in the SQL one I put on the board last year. It was not one of those overcrowded ones (everyone had a chair!), but still more crowded than I expected. Anyway, I guess bigger rooms on average for the same number of people would take away much of the pressure already. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
Op 16-12-2011 1:07, Giuseppe D'Angelo schreef: fwiw, the usual elegant solution is having a value and a mask parameter. the mask could have two magic values meaning un-/set all asserted in vlaue to mean effectively what your bool means. the default argument would be the magic value for setting, so the standard syntax would set all flags named in the first argument. I'm not sure I understand this point completely -- isn't that what the method does? I.e. rx.setPatternOptions(CaseInsensitiveOption | DotMatchesEverythingOption) turns on those two options, and leaves the others unchanged. Really? Now to me _that_ is unexpected behaviour. I would have expected that this method call would set the options to exactly (CaseInsensitiveOption | DotMatchesEverythingOption), no matter what the previous value of the matchingOptions value was. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Json support for QtCore
Op 11-12-2011 15:55, lars.kn...@nokia.com schreef: The binary representation is optimized for fast reading. The binary format is relatively compact and stores the whole object in one blob. Is this a standard binary format of JSON, or something of your own devise? It's something I wrote. I wanted it to be something that you can simply mmap from a file and use without ever having to parse anything to make saving and restoring of json objects as cheap as possible. The problem with bson is that it's a streaming format that still requires parsing and as such was unsuitable for some of the use cases I have. I think I am missing something here. What is the use of this? I mean, if it is not JSON, then it is just some random binary format, right? How does that help with parsing and providing JSON when you are communicating with a webservice, for instance? I mean, it is cool to have a file format that is able to contain a lot of standard stuff and be quick about it, but I don't really see the connection with JSON, and calling it a binary format of JSON is confusing to me. However, like I said, I guess I am missing something here. Could you explain what the relationship is between this binary format and the JSON format, and how it helps parsing creating JSON? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
Op 9-12-2011 20:18, Stephen Kelly schreef: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. Aren't we all, in a way? ;-) Anyway, thanks. I think it is informative! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving itemmodels classes to QtCore
Op 23-11-2011 14:52, shane.kea...@accenture.com schreef: Hi, I think moving the item models back into QtGui would be better than QtCore. * QML and Widgets applications both depend on QtGui * The item models have no use outside of a GUI application. * QtGui was the location of these classes in Qt4. So, what do you suggest to do with the QSql*Model classes then? Should the SQL module depend on QtGui, or should these models also move to QtGui, making QtGui dependent on QtSQL? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
Op 16-11-2011 18:56, David Faure schreef: On Wednesday 16 November 2011 18:26:25 Andre Somers wrote: Op 16-11-2011 18:13, David Faure schreef: Hello, As previously discussed on qt5-feedback, I wrote QTemporaryDir and submitted it to gerrit at http://codereview.qt-project.org/#change,8297 After a few reviews from Thiago (and redoing the implementation on Windows) it's now ready for submission. Thiago suggested that I post the header file here, to see if anyone had feedback on the (rather short) API. Actually I'll post the .cpp file too, since the documentation of the API is there :) There is no need to assing copyright to nokia :-) I am being sponsored by Nokia for my work on KDE, and right now this involves putting into Qt 5 what KDE needs. So it kind of makes sense that Nokia owns the copyright for it. Ah, good point :-) Nokia (c) it is, then. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
Op 9-11-2011 19:35, Jeremy Lainé schreef: On 11/09/2011 07:21 PM, Peter Hartmann wrote: On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote: (...) A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString); pro: easy to connect to the QDnsReply's signal con: it's entirely up to the user to handle deletion. Judging by your comments above, I doubt you favor it? or B/ static QSharedPointerQDnsReply QDnsReply::lookup(QDnsReply::Type, QString); pro: memory ownership is explicit con: how used are our users to manipulating QSharedPointer with respect to signals and such? I rather favour option B (lessons learned from QNAM), because I think option A might lead to undeleted replies, which is what we experienced in the case of QNetworkReply *QNetworkAccessmanager::get(...). OK, there is always another option: C/ you make QDnsReply's constructor public, and let the user manage the lifetime of the object. This is what the Q3Dns API looks like. What I don't like about Q3Dns's API is that it's unclear when the request is actually made. You mean, like this? //user code QDnsReply* dnsReply = new QDnsReply(this); QDnsResolver::lookup(dnsQuery, dnsReply); Not a big fan... Lets stick to either A or B. *I* prefer B, but that much should be clear by now. I also suggest we ask somebody with more template fu than I can wield to look into if it would be feasable to let this work: QSharedPointerQDnsReply dnsReply = QDnsResolver::lookup(dnsQuery); connect(dnsReply, SIGNAL(finished()), this, SLOT(dnsFinished())); //directly connect, instead of: connect(dnsReply.data(), SIGNAL(finished()), this, SLOT(dnsFinished())); //currently needed connect statement André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
Op 4-11-2011 20:31, Jeremy Lainé schreef:
On 11/04/2011 10:15 AM, André Somers wrote:
The more I think about it, the more I think it is important to fix this: who
is
responsible for the lifetime of the QDnsReply object?
Why not have the same pattern as QNAM for consistency?
How about fixing QNAM to solve this issue there as well then?
This API does not make that clear. I like the pattern in itself (also in
QNAM), but I do
think it would be an improvement if we were to use a shared pointer to the
reply object.
That at least makes clear who has ownership of the object, and prevents
memory leaks
when people don't realize they are supposed to delete the object.
I'm not sure I understand how using a QSharedPointer would clarify the API,
it would lead
to code like this:
void someObject::someMethod()
{
QSharedPointerQDnsReply reply = someResolver-lookupService(X, Y, Z);
connect(reply.data(), SIGNAL(finished()),
this, SLOT(replyFinished()));
}
= surprise, the reply has been deleted!
Has it? Probably not, as the lookup service is still holding on to
another shared pointer to it in order to know where to put the results
of the lookup, right? Using a shared pointer, at least you are sure the
object is valid while either the receiver or the resolver is still
interested in having the object around, and as soon as that is no longer
the case, it will be properly deleted. Using raw pointers, you can not
be sure of either.
dreaming
Would be nice by the way if connect could directly deal with QObjects in
shared pointers...
/dreaming
Alternatively, perhaps a look at QFuture would help. QFuture is another way
results that
are not yet ready are handled in Qt, but this time it is returned as a value
instead of
as a pointer. It would be nice we could come up with a single approach for
these kinds
of things and use that all over the place...
I brought this up with Thiago on IRC, as I quite like the idea of using a
QFuture. However
apparently this is not an option as QtConcurrent is optional.
Me too. My point was, that we have slightly different patters for
basically the same sort of thing in different places in Qt. QFuture is
_currently_ coupled with QtConcurrent, but is there a strong reason why
is must be? I was not privy to that IRC chat, perhaps you could tell us
the reasoning why it would not be possible?
I think the Qt API would benefit from having the same kind of pattern
for waiting for asynchronous results, whether from calculation or from
the network or from some other resource. However, at all times, I think
it must be clear who owns what object, and who is responsible for
cleaning it up.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
