Re: [Development] Qt 4.8.7 release candidate available
Sure, with the removal I only meant the xsm implementation :) Simon Original Message From: Samuel Gaist Sent: Thursday, April 30, 2015 23:36 To: Hausmann Simon Cc: Matthew Woehlke; development@qt-project.org; releas...@qt-project.org Subject: Re: [Development] Qt 4.8.7 release candidate available Hi, It's back since 5.2 with an implementation for OS X waiting for Qt 5 (also for Qt 4 but since it's considered a new feature it won't get in) Samuel On 30 avr. 2015, at 19:37, Hausmann Simon wrote: > IMO this isn't a Qt bug, I commented on Jira. > > I suspect another app isn't implementing the protocol directly, but if we > really want to protect ourselves then we should probably ditch the entire > session management code from Qt 4 (it's gone in Qt 5, too :) > > Simon > > Original Message > From: Matthew Woehlke > Sent: Thursday, April 30, 2015 16:49 > To: development@qt-project.org > Cc: releas...@qt-project.org > Subject: Re: [Development] Qt 4.8.7 release candidate available > > > On 2015-04-30 09:17, Salovaara Akseli wrote: >> If blocker issues for Qt 4.8.7 release (i.e. new regression) are found >> please report those to bugreports.qt.io and raise issue also (with bug id) >> on releasing mailing list. > > Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 > fixed? This is a really nasty bug that cripples all (newly launched) Qt > applications when it happens. It's listed as P1 and has been reproduced, > but I don't know enough about the bowels of QSessionManager to suggest a > solution. > > KDE4 is likely to be around for a while yet (e.g. LTS distros) and it > would be good if this can be fixed. > > -- > Matthew > > ___ > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] RFC: QtQuick. Custom keys support proposal.
There are some cases when non-standard keys should be handled. Remote control units with custom key codes are the primary example. Existing Keys QML type provides a handy means of processing specific key events only for a small subset of Qt::Key enum, and that is true only for presses, not release events. Here I suggest patch that allows to extend the default set of key codes. It heavily depends on newly added Q_ENUM macro which allows to completely drop then need to keep internal table sigMap up to date. Unfortunately, there seems to be no way to generate signal so that all the keys are provided with specific handlers. So, we will still have to add them manually. Getting the full list of signals should be a matter of playing with regular expressions, though. Another plus is that now implementations of keyPressed/Released handlers of QQuickKeysAttached are merged into one auxiliary private function. Adding new set of supported keys is a matter of inheriting QQuickKeysAttached with Q_ENUM of custom keys declared which should be registered with a protected member function provided for this purpose. Next, a set of wanted specific signal should be listed under 'signals' section of the class. As for drawbacks, in order to let users inherit from QQuickKeysAttached we need to mark it with Q_QUICK_PRIVATE_EXPORT -- this will break ABI as far as I understand. QQuickKeyNavigationAttached is marked this way, already. So there seems to be no contradiction. And, of course, it is required to list private modules as your project dependencies. Unfortunately, should have user chosen to use custom key handlers there is no way to disable default Keys QML type. Even that it is discouraged to mix both classes, this should not be a big problem which could be addressed via documentation on this topic. Since newly registered set of keys is searched for key in question prior to the default keys from Qt namespace we can override default signals in QQuickKeysAttached class thus effectively renaming a key. This feature may come handy in some cases when RCU has domain specific buttons. Diff of the patch and example of CustomKeys QML attached type may be viewed here: https://gist.github.com/dvolosnykh/65819bca1693b0e82058 In case this change is welcomed, what branch should I target? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.7 release candidate available
Hi, It's back since 5.2 with an implementation for OS X waiting for Qt 5 (also for Qt 4 but since it's considered a new feature it won't get in) Samuel On 30 avr. 2015, at 19:37, Hausmann Simon wrote: > IMO this isn't a Qt bug, I commented on Jira. > > I suspect another app isn't implementing the protocol directly, but if we > really want to protect ourselves then we should probably ditch the entire > session management code from Qt 4 (it's gone in Qt 5, too :) > > Simon > > Original Message > From: Matthew Woehlke > Sent: Thursday, April 30, 2015 16:49 > To: development@qt-project.org > Cc: releas...@qt-project.org > Subject: Re: [Development] Qt 4.8.7 release candidate available > > > On 2015-04-30 09:17, Salovaara Akseli wrote: >> If blocker issues for Qt 4.8.7 release (i.e. new regression) are found >> please report those to bugreports.qt.io and raise issue also (with bug id) >> on releasing mailing list. > > Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 > fixed? This is a really nasty bug that cripples all (newly launched) Qt > applications when it happens. It's listed as P1 and has been reproduced, > but I don't know enough about the bowels of QSessionManager to suggest a > solution. > > KDE4 is likely to be around for a while yet (e.g. LTS distros) and it > would be good if this can be fixed. > > -- > Matthew > > ___ > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I *finally* got permission to share this. Sorry it took so long.
The attached code, excluding the copyright notices, is hereby placed
into the Public Domain. Permission is also granted to use the attached
code under either the BSD license, as stated in the files themselves, or
pursuant to Kitware's CLA with Qt.
It is my hope that this is useful to other people. (Also that the first
one finds its way into STL eventually :-), though that's a bit OT for here.)
These are both C++11 code. At minimum, they'll need brace-initialization
changed to parentheses-initialization in order to build in C++03 mode.
However, qtIndexRange also uses trailing return type specification, and
I'm not sure it's possible to avoid that without losing type deduction,
which sort-of defeats the purpose. There are also lots of elided type
specifiers, though those are easy enough to add.
Personally, I wouldn't consider it a terrible loss if these were only
available in C++11-or-later mode, since they're intended to be used with
range-based for.
> Note that this should also work for foreach:
>
> foreach (const auto i, qtEnumerate(map))
I'm not sure if it will or not; it was designed to work in range-based
for, i.e. it supplies begin() and end(). I'm not sure if that's enough
to automagically work in Q_FOREACH.
Thiago, do you want me to take another look at integrating these into Qt
proper, or do you have it in hand?
--
Matthew
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither name of Kitware, Inc. nor the names of any contributors may be used
to endorse or promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Based on code written by Matthew Woehlke and used by permission.
*/
#ifndef __qtEnumerate_h
#define __qtEnumerate_h
//-
template class qtEnumerator
{
public:
class iterator;
qtEnumerator(Container const& container) : c(container) {}
iterator begin() const { return {c.begin()}; }
iterator end() const { return {c.end()}; }
protected:
Container const& c;
};
//-
template class qtEnumerator::iterator
{
public:
using Iterator = typename Container::const_iterator;
Iterator operator*() const { return i; }
iterator& operator++() { ++i; return *this; }
bool operator==(iterator const& other) const
{ return i == other.i; }
bool operator!=(iterator const& other) const
{ return i != other.i; }
protected:
friend class qtEnumerator;
iterator(Iterator const& iter) : i{iter} {}
Iterator i;
};
//-
template
qtEnumerator qtEnumerate(Container const& container)
{
return {container};
}
#endif
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither name of Kitware, Inc. nor the names of any contributors may be used
to
Re: [Development] Qt 4.8.7 release candidate available
IMO this isn't a Qt bug, I commented on Jira. I suspect another app isn't implementing the protocol directly, but if we really want to protect ourselves then we should probably ditch the entire session management code from Qt 4 (it's gone in Qt 5, too :) Simon Original Message From: Matthew Woehlke Sent: Thursday, April 30, 2015 16:49 To: development@qt-project.org Cc: releas...@qt-project.org Subject: Re: [Development] Qt 4.8.7 release candidate available On 2015-04-30 09:17, Salovaara Akseli wrote: > If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please > report those to bugreports.qt.io and raise issue also (with bug id) on > releasing mailing list. Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 fixed? This is a really nasty bug that cripples all (newly launched) Qt applications when it happens. It's listed as P1 and has been reproduced, but I don't know enough about the bowels of QSessionManager to suggest a solution. KDE4 is likely to be around for a while yet (e.g. LTS distros) and it would be good if this can be fixed. -- Matthew ___ 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 4.8.7 release candidate available
On 2015-04-30 09:17, Salovaara Akseli wrote: > If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please > report those to bugreports.qt.io and raise issue also (with bug id) on > releasing mailing list. Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 fixed? This is a really nasty bug that cripples all (newly launched) Qt applications when it happens. It's listed as P1 and has been reproduced, but I don't know enough about the bowels of QSessionManager to suggest a solution. KDE4 is likely to be around for a while yet (e.g. LTS distros) and it would be good if this can be fixed. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 4.8.7 release candidate available
Hi, Qt 4.8.7 release candidate packages are available at http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/ and SHA-1 is now frozen so please test these packages accordingly. These packages are built against SHA-1: fa81aa6d027049e855b76f5408586a288f160575 * QNAM: Fix upload corruptions when server closes connection (current HEAD). Preliminary version of changes-4.8.7 file is available at http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/changes-4.8.7-rc1.txt and full git log http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/4.8.7-rc1-changes-git-log.txt (mirroring in progress - if changes files are not available please try again a bit later). If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please report those to bugreports.qt.io and raise issue also (with bug id) on releasing mailing list. Br, Akseli -- Akseli Salovaara The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Creator uses "_qt_autotest_force_engine_poller"?
Makes sense, thanks. R On 29 Apr 2015, at 12:35, Ziller Eike wrote: > >> On Apr 21, 2015, at 11:46 AM, René J.V. Bertin wrote: >> >> Hi, >> >> I know I should ask this on the QC ML (but I'd prefer not to sign up for >> just an occasional question like this): >> >> Is there a (good) reason why DocumentManagerPrivate::linkWatcher() forces >> the use of a polling watcher? > > The reason is https://bugreports.qt.io/browse/QTBUG-15522 > > Br, Eike > >> >> Mainly asking because I just noticed that this approach can lead to >> significant CPU use when the IDE is otherwise idle, which is ... >> unfortunate. >> >> R. >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller, Senior Software Engineer - The Qt Company GmbH > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modifying and accessing environment variables in Qt
On Thursday, April 30, 2015 10:50:59 AM Marc Mutz wrote: > > > 2. what business does a program have, anyway, of modifying the > > > > > >environment after threads may have started? Such code should be > > >fixed. > > >Making the Qt wrappers "save" could lead to more code doing nonsense > > >instead of being fixed. > > This is my main point. That is a valid point, for sure. Inherently valid due to the nature of the way the C runtime implements this and is accessible to everyone. > > > 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. > > > > > >You may be able to patch 3rd-party code, but you cannot patch libc. > > > > Right, there are more "unsafe" functions in libc that we cannot change. > > But isn't that an orthogonal topic to the issue of our tests crashing? > > You want to fix races between environment accesses. I'm saying that libc > functions are implicitly accessing the environment, too, and you cannot > insert you Qt mutex there. So this is isn't really orthogonal. I think you may be misunderstanding me. I don't want to fix all races, I want to fix the common cases in Qt, in particular the ones that affect our everyday work of trying to integrate changes by passing tests. I'm looking for a pragmatic improvement, not a perfect solution. I see however that you agree to the proposed change being acceptable as a stop-gap - so thank you :) > > > Callers of putenv()/setenv() should be fixed to not do so after initial > > > initialisation, ie. when threads may have started. This is how most > > > initialisation in libraries is required to be handled, see e.g. > > > > > > https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check > > > . > > > > > >htm > > > > > > l and I don't see why Qt should do something different from every other > > > C/C++ library on the planet, at least not for such a common problem as > > > library initialisation. > > > > How can we do this in Qt and in our tests? > > Tests are presumably easy. If everything else fails, QtTest could execute > itself anew for each test. Can you elaborate on that? I don't think I fully understand what you mean. The only portable solution that I can think of is to replace each use of an environment variable with an autotest-only exported variable in Qt, that is used instead. That may be a path forward and I'd be happy to help review changes towards that. > After a quick scan, the only thing I'm worried > about in QtBase is qglxconvenience.cpp, which temporarily modifies the > environment. > > It would all have to be done before the application constructor, because > > already our platform plugins start threads. This is in contrast to > > individual test functions in Qt calling putenv(). > > Platform plugins are creating threads before the Q*Application ctor runs? > How is that possible if the Q*Application ctor is the first Qt code that > gets called from the application? If they do, it means that the threads are > already running when control enters main(). And that's unacceptable, > because it deprives application authors of the window of control where > there's only one thread of execution. Guaranteed. So you cannot, say, use > gpgme with a Qt program. No, I do not claim that threads are created before the Q*Application constructor runs. Please re-read what I wrote. I said that the platform plugins start threads, and they are loaded in the Q*Application constructor. So environment variables have to be set before there, if they affect the platform plugins. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modifying and accessing environment variables in Qt
On Wednesday 29 April 2015 11:15:21 Simon Hausmann wrote: > > 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant. In > > > >any case, it's almost trivial to fix this in libc (using CAS, as Ossi > >suggested in a comment on v1 of the patch), but impossible outside. > > Does reentrancy here refer to the supplied arguments of putenv? Can you > explain how this helps with concurrent getenv invocations? > > (Sorry, I must be missing something - I don't see how this relates to the > crashes) See my other mail. It prevents putenv/putenv races, but not putenv/getenv, indeed. > > 2. what business does a program have, anyway, of modifying the > >environment after threads may have started? Such code should be fixed. > >Making the Qt wrappers "save" could lead to more code doing nonsense > >instead of being fixed. This is my main point. > > 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. > >You may be able to patch 3rd-party code, but you cannot patch libc. > > Right, there are more "unsafe" functions in libc that we cannot change. > But isn't that an orthogonal topic to the issue of our tests crashing? You want to fix races between environment accesses. I'm saying that libc functions are implicitly accessing the environment, too, and you cannot insert you Qt mutex there. So this is isn't really orthogonal. > > Callers of putenv()/setenv() should be fixed to not do so after initial > > initialisation, ie. when threads may have started. This is how most > > initialisation in libraries is required to be handled, see e.g. > > > > https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check. > >htm > > > > l and I don't see why Qt should do something different from every other > > C/C++ library on the planet, at least not for such a common problem as > > library initialisation. > > How can we do this in Qt and in our tests? Tests are presumably easy. If everything else fails, QtTest could execute itself anew for each test. After a quick scan, the only thing I'm worried about in QtBase is qglxconvenience.cpp, which temporarily modifies the environment. > It would all have to be done before the application constructor, because > already our platform plugins start threads. This is in contrast to > individual test functions in Qt calling putenv(). Platform plugins are creating threads before the Q*Application ctor runs? How is that possible if the Q*Application ctor is the first Qt code that gets called from the application? If they do, it means that the threads are already running when control enters main(). And that's unacceptable, because it deprives application authors of the window of control where there's only one thread of execution. Guaranteed. So you cannot, say, use gpgme with a Qt program. Qt can't make the rules. It has to abide by them. As an aside: That so much code in Qt checks the environment for some more-or-less obscure options indicates the need for explicit management of these options. I'll give this some more thought. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
