Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-14 Thread Thiago Macieira 
Em sexta-feira, 14 de outubro de 2016, às 11:07:34 PDT, Thiago Macieira 
escreveu:
> What do you prefer?
> 
> 1) leak
> 2) crash and leak
> 
> Either way, the dlclose() call will not happen.
> 
> Note that this has nothing to do with freeing memory. Only the dlclose().

Actually, there's no distinction: both are leaks when the process exits.

The only difference is the cause of the exit: it's either a clean exit by 
returning from main, or a crash.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-14 Thread Thiago Macieira 
Em sexta-feira, 14 de outubro de 2016, às 16:08:27 PDT, Liang Jian escreveu:
> I don't care custom plugin, What I care is the plugins loaded by qt
> itself, such as qpa plugin, images format plugins ..., These plugins are
> needed for all qt programs, we can't avoid the leaks caused by not
> unloading these plugins if my understanding to this issue is right (Maybe
> you don't think that are leaks but they will confuse memory leak detector),
> that is why I hope to introduce a method to disable this feature at runtime.

What do you prefer?

1) leak
2) crash and leak

Either way, the dlclose() call will not happen.

Note that this has nothing to do with freeing memory. Only the dlclose().

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-14 Thread Thiago Macieira 
Em sexta-feira, 14 de outubro de 2016, às 07:10:00 PDT, Thiago Macieira 
escreveu:
> We are talking in this change about QFactoryLoader, which is a Qt API and
> which is ALWAYS used until program exit.
 
I meant internal Qt API.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt build without Virtual Keyboard

2016-10-14 Thread Mitch Curtis 
Qt Quick has always been mandatory for Qt Virtual Keyboard, as the keyboard 
itself is a Qt Quick Item.

I don’t know where or how you got the sources, but you can just remove the 
qtvirtualkeyboard directory to avoid it being built.

If you’re using Git, you can use –module-subset when initialising the 
repository to only clone the modules you’re interested in:

perl init-repository –module-subset=qtbase,qtblah

From: Development 
[mailto:development-bounces+mitch.curtis=qt...@qt-project.org] On Behalf Of 
Alexander Nassian
Sent: Friday, 14 October 2016 2:00 PM
To: development 
Subject: [Development] Qt build without Virtual Keyboard

Hi,

We are trying to build 5.7 on Linux without OpenGL support (so no QtQuick 
either) and are facing a build error in qtvirtualkeyboard „Module quick not 
found“.

Is QtQuick now mandatory, or is this a known bug? And why is the virtual 
keyboard building at all when choosing L-GPL? That’s not very nice.


Beste Grüße / Best regards,
Alexander Nassian, bitshift dynamics GmbH
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt build without Virtual Keyboard

2016-10-14 Thread Alexander Nassian 
Hi,

We are trying to build 5.7 on Linux without OpenGL support (so no QtQuick 
either) and are facing a build error in qtvirtualkeyboard „Module quick not 
found“.

Is QtQuick now mandatory, or is this a known bug? And why is the virtual 
keyboard building at all when choosing L-GPL? That’s not very nice.


Beste Grüße / Best regards,
Alexander Nassian, bitshift dynamics GmbH
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Multiple Qt branches on Coverity Scan

2016-10-14 Thread Oswald Buddenhagen 
On Thu, Oct 13, 2016 at 02:43:13PM +0100, Giuseppe D'Angelo wrote:
> On 13/10/16 14:35, Marc Mutz wrote:
> > Will the -lts version start out with its own CIDs or will identical issues
> > have the same CIDs in both projects? If they're different, we'll have a 
> > mess.
> 
> The idea was to share the database of CIDs so to keep them in sync. 
> That's why it's taking so long to set it up (?). I have no idea how the 
> matching between branches is going to work...
> 
probably not at all. but when you fix an issue in the lower branch, it
will also disappear in the higher branch, so there is no need to
explicitly mention it at all. just remember to use the issue number from
the correct source.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-14 Thread Liang Jian 
I don't care custom plugin, What I care is the plugins loaded by qt
itself, such as qpa plugin, images format plugins ..., These plugins are
needed for all qt programs, we can't avoid the leaks caused by not
unloading these plugins if my understanding to this issue is right (Maybe
you don't think that are leaks but they will confuse memory leak detector),
that is why I hope to introduce a method to disable this feature at runtime.

On Fri, Oct 14, 2016 at 1:10 PM, Thiago Macieira 
wrote:

> Em sexta-feira, 14 de outubro de 2016, às 09:11:48 CEST, Liang Jian
> escreveu:
> > It is a pity that qt develpers have made the dicision of not
> unloading
> > plugins and I have to accept the reality.
> > But I think we should at least  introduce a method to disable this
> > feature at runtime (such as through a enviroment variable) ?
>
> Use QLibrary for your own plugins.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> 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] QtBase WIP branch request

2016-10-14 Thread Morten Sorvig 

> On 12 Oct 2016, at 22:57, James Turner  wrote:
> 
> 
>> On 7 Oct 2016, at 02:32, Morten Sorvig  wrote:
>> 
>> 
>> What is actually in development? The scope is outlined in QTBUG-49827 and 
>> includes
>> - Improving expose event handling
>> - Improving support for Core Animation layer-backed QWindows
>> - Improving support for embedding QWindow in NSView hierarchies
>> - Driving QWindow::requestUpdate() animations via CVDisplayLink
> 
> Morten, I was doing some work, and have some patches (not yet available) in 
> this area, to do with embedding NSView hierarchies inside QWidgets. The 
> approximate changes are in the Cocoa QPA, to ensure that child QWindows are 
> inserted into the NSView heirarchy as subviews correctly, and re-ordered in 
> the subviews list (by removing and re-adding, as the AppKit docs suggest).
> 
> One of the bugs hopefully fixed by this is:
> 
>   https://bugreports.qt.io/browse/QTBUG-7140
> 
> I can provide the patches via email, but I wonder if they will be subsumed by 
> this work you’re about to start.

Hi, I don’t think I’ve made this change. Perhaps you can post the patch(es) on
codereview? We could then either merge them or move them into the WIP branch.

What I’ve seen is that compositing using layer-backed views is required to get
proper stacking of QWindows with OpenGL content. But that presumably requires
correctly ordered views first.

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development