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
Em quinta-feira, 13 de outubro de 2016, às 20:46:46 CEST, André Pönitz
escreveu:
> It's not about most that don't, but those that do, or that would like to.
>
> At a certain level of complexity one doesn't only want to load plugins
> on demand, but also unload them when not needed use anymore, or
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) ?
On Thu, Oct 13, 2016 at 11:16 PM, Thiago Macieira
On Thu, Oct 13, 2016 at 08:16:50PM +0200, Thiago Macieira wrote:
> Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz
> escreveu:
> > I am not concerned about toy applications that gets started and closed
> > by the minute.
>
> Right. Most applications don't unload their plugi
Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz
escreveu:
> I am not concerned about toy applications that gets started and closed
> by the minute.
Right. Most applications don't unload their plugins, except at program exit.
--
Thiago Macieira - thiago.macieira (AT) intel
13.10.2016, 20:39, "André Pönitz" :
> On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote:
>> > I still consider the approach of not unloading plugins fundamentally
>> > wrong. It only deepens the trench between Qt and valid approaches at
>> > software architectures.
>>
>> I th
On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote:
> > I still consider the approach of not unloading plugins fundamentally
> > wrong. It only deepens the trench between Qt and valid approaches at
> > software architectures.
>
> I think not unloading plugins is fundamentally right
13.10.2016, 19:39, "André Pönitz" :
> On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote:
>> On 2016-10-12 20:59, Thiago Macieira wrote:
>> >Hello
>> >
>> >We've got a number of issues that got fixed in 5.7 by the change that made
>> >QFactoryLoader stop unloading plugins (notabl
On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote:
> On 2016-10-12 20:59, Thiago Macieira wrote:
> >Hello
> >
> >We've got a number of issues that got fixed in 5.7 by the change that made
> >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer
> >plugin). Given th
Just got a segmentation fault on OS X 10.9 machine, while compiling, which
doesn't seem related to moc.
http://testresults.qt.io/logs/qt/qtbase/9859c09bddaf87f49e73c1e8734decab497730ec/OSXOSX_10_08x86_64OSXOSX_10_08x86_64Clangqtci-osx-10.8-x86_64Release_NoFramework/85d6b000f945a84bc84a4f01f53ac65
Em quinta-feira, 13 de outubro de 2016, às 22:00:35 CEST, Liang Jian escreveu:
> Not unloading plugin is really a bad idea.
> That will make any memory leak detector report tons of leaks even run a
> simplest qt widgets program. Find and fix 'real' memory leak will be much
> harder than bef
On 12/10/16 20:59, Thiago Macieira wrote:
We've got a number of issues that got fixed in 5.7 by the change that made
QFactoryLoader stop unloading plugins
It's actually 5.8, isn't it? 494376f980e96339b6f1eff7c41336ca4d853065 is
in 5.8 (and has a documentation bug as it states 5.7!).
Which op
On 2016-10-12 20:59, Thiago Macieira wrote:
Hello
We've got a number of issues that got fixed in 5.7 by the change that
made
QFactoryLoader stop unloading plugins (notably, the Network Manager
bearer
plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of
new
issues have croppe
Not unloading plugin is really a bad idea.
That will make any memory leak detector report tons of leaks even run a
simplest qt widgets program. Find and fix 'real' memory leak will be much
harder than before.
On Thursday, October 13, 2016, Thiago Macieira
wrote:
> Em quarta-feira, 12 de
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
On Thursday 13 October 2016 15:11:18 Giuseppe D'Angelo wrote:
> Heads up:
>
> On 03/10/16 22:46, Giuseppe D'Angelo wrote:
> > I'm going with "lts" and "dev" anyhow, thanks!
>
> To avoid losing history, we're sticking with the current "qt-project" to
> represent "dev", as apparently it's not possi
Heads up:
On 03/10/16 22:46, Giuseppe D'Angelo wrote:
I'm going with "lts" and "dev" anyhow, thanks!
To avoid losing history, we're sticking with the current "qt-project" to
represent "dev", as apparently it's not possible to rename projects.
"qt-project-lts" is going to be 5.6. The new bran
17 matches
Mail list logo
