Re: [Development] Nominating Johan Helsing for Approver status
Congratulations. The permission changes have been enacted. -- Alex From: Development on behalf of Giulio Camuffo Sent: Monday, 8 August 2016 9:14:55 AM To: Erik Larsson Cc: Qt development mailing list Subject: Re: [Development] Nominating Johan Helsing for Approver status +1 2016-08-06 8:31 GMT+02:00 Erik Larsson : > +1 > > 2016-08-04 12:22 GMT+02:00 Paul Tvete : >> >> Hi all, >> >> >> I'd like to nominate Johan Helsing for Approver status. He joined The Qt >> Company half a year ago, and has been working full time on Qt since. Johan >> has been actively involved in making the QtWaylandCompositor module ready >> for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in >> 5.6 and 5.7. >> >> Here is his gerrit dashboard: >> >> https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z >> >> Johan's list of reviews can be found at: >> >> >> https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d >> >> Cheers, >> >> - Paul >> >> >> ___ >> 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Would it make sense to make QObject moveable in Qt 6?
> On Aug 25, 2016, at 5:48 AM, Marc Mutz wrote: > > On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: >> `QObject` is already pretty much a handle to the underlying data due to >> pimpl. So that’s a good first step. > > I challenge the notion that QObject is a handle to date. > > QObject is first and foremost the base class of a polymorphic class hierarchy. > > If you wrap that in a parallel value-like-but-not-quite class hierarchy, you > end up with QDomNode. I don't like QDomNode. Do you like QDomNode? > > That said, the Copperspice guys argue that the implicit memory management of > QObject parent-child relationships is becoming alien for C++ developers. The > Qt community can of course deny every claim that comes from that direction, > but sometimes the look of an outsider is valuable, too. After all, the API > quality matters most for newbies, not decade-long Qt users. > > So IMO, it's certainly worth asking the question whether we should change > something there, e.g. by using shared_ptr/weak_ptr to manage lifetimes. > > That would cover your use-case: > > std::vector> > > is all you were asking for. This is fine and dandy except we’re holding shared pointers to pointers to data. That seems a bit wasteful when we know that internally it’s just Qt’s unique_ptr (QScopedPointer). I think that people would understand the fallout from QObject being movable if it was clearly documented, e.g. that if you hold any pointers to it, and then move it, the pointers aren’t valid. A QPointer that tracks the moves in principle is what anyone could use to track an object that has been moved, but it’d break its api a bit: after every move, the QPointer would return a different address. A QObject::Handle would be a cheaper version of a QPointer: it wouldn’t track destruction, but otherwise would work the same. Perhaps we could name it better? A movable QObject could be at the beginning just an implementation detail, and perhaps Qt shouldn't be moving any objects that are visible to the user. But internally it would track the moves all across the hierarchy. I’d need to see what the fallout of that would be, otherwise this will all be idle talk. I’ll see what an implementation would look like. Kuba ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] Qt Creator 4.1.0 released
We are happy to announce the release of Qt Creator 4.1.0 https://blog.qt.io/blog/2016/08/25/qt-creator-4-1-0-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Would it make sense to make QObject moveable in Qt 6?
On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: > `QObject` is already pretty much a handle to the underlying data due to > pimpl. So that’s a good first step. I challenge the notion that QObject is a handle to date. QObject is first and foremost the base class of a polymorphic class hierarchy. If you wrap that in a parallel value-like-but-not-quite class hierarchy, you end up with QDomNode. I don't like QDomNode. Do you like QDomNode? That said, the Copperspice guys argue that the implicit memory management of QObject parent-child relationships is becoming alien for C++ developers. The Qt community can of course deny every claim that comes from that direction, but sometimes the look of an outsider is valuable, too. After all, the API quality matters most for newbies, not decade-long Qt users. So IMO, it's certainly worth asking the question whether we should change something there, e.g. by using shared_ptr/weak_ptr to manage lifetimes. That would cover your use-case: std::vector> is all you were asking for. And wether you then use shared_ptr explicitly, or template using QObjectHandle = std::shared_ptr; is pretty much secondary. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Would it make sense to make QObject moveable in Qt 6?
On 2016-08-24, Thiago Macieira wrote:
> And its address is copyable, so if we replaced the pointer with something,
> we'd have to use something copyable and non-owning.
class QObjectHandle {
public:
QObjectHandle(QObject* obj) : m_obj(obj) { }
operator QObject* () const ( return m_obj.data() }
bool operator==(const QObjectHandle& other) const { return m_obj ==
other.m_obj;}
// default created rest of it is fine
private:
QPointer m_obj;
}
There. made it. Unsure what it gains us.
/Sune
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
