Re: [Development] Automatic signal-slot statistics

[Olivier Goffart]

On 2018-08-08 06:53, Taras Kushnir wrote:

Hello

I’ve been refactoring giant pieces (like 50-60%) of one project's codebase and 
I’m concerned about validity/quality of the result. Except different kinds of 
tests I’m thinking about statistical metrics one of which would be to get a 
feel how Qt-specific parts of the project have changes.

Is there any way to produce statistics which signals got fired and how many 
times (+ the same for slots) automatically during any application runtime?
(“any" way except of patching and recompiling Qt framework itself)



There is a way:
There is some exported private API from qobject_p.h that you can trivially 
re-declare in your project:



struct QSignalSpyCallbackSet
{
typedef void (*BeginCallback)(QObject *caller, int signal_or_method_index, 
void **argv);

typedef void (*EndCallback)(QObject *caller, int signal_or_method_index);
BeginCallback signal_begin_callback,
slot_begin_callback;
EndCallback signal_end_callback,
slot_end_callback;
};
void Q_CORE_EXPORT qt_register_signal_spy_callbacks(const QSignalSpyCallbackSet 
_set);


extern QSignalSpyCallbackSet Q_CORE_EXPORT qt_signal_spy_callback_set;

https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject_p.h.html#73


All you need to do is to call qt_register_signal_spy_callbacks to register the 
signal_begin_callback, and this will be called everytime a signal is emited. So 
you can gather some statistics from that.



--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] How to create a Qt5 offline installer myself

[Roland Winklmeier]

Dear Qt Devs,

I think I asked this question in the past, but I never got a reasonable
answer. The question is actually quite simple:

How can I create a Qt5 offline installer for example for 5.11.1 MinGW 5.3.0
32 bit?

I'm aware of the qt/qtsdk repository and its scripts. There is also some
high level description in the READMEs. But following the coin builds, those
are using GO scripts which are as far as I can see not public.So that
means, Qt build servers have been using those python scripts in the past,
but now they don't and that renders them in fact untested and unmaintained.
I don't mind doing more steps manual (even if automating it fully would be
super great), but I cannot even find a easy way of doing it manually.

It was often mentioned in this mailing list, that users/developers can
build their own version of Qt and the official binaries are just a subset.
That's fair enough and I can and do regularly build Qt on my own. But my
own build doesn't help me much, if I cannot bundle it into a proper
installer and make it available to other people and/or build servers.To me,
this is still a very important step which should be properly documented and
as easy reproducable as the regular Qt5 build.

So if anyone has a good and easy to follow guide, how to produce my own
offline installer, please share it with me. Ideally we come up with a wiki
page similar to https://wiki.qt.io/Building_Qt_5_from_Git.
The reason why I'm asking is, that I would like to try and get some changes
into the binaries (release build with debug symbols for crash dumps, MSVC
2017 32 and 64 bit builds etc).

Looking forward to any help.

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

Re: [Development] Closing issues automatically with new keyword

[Oswald Buddenhagen]

On Tue, Aug 07, 2018 at 04:06:38PM +0200, Frederik Gladhorn wrote:
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> > did your investigation reveal that it's unsalvagably bad?
> 
> I guess it could work, it can close issues,
>
well, obviously. that's the preferred approach, because the gerrit-based
trigger is easier to get reliable than an external script.

> but it doesn't have any idea about versions. I just looked at the code
> now.
> 
your script should be integrated then.

> > https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
> 
> I'd really like to get the fix version set, so that we can generate change 
> logs more easily when it comes to fixed issues for each release.
> 
yes, me as well. if that feature is missing in the plugin, let's
contribute it - this really looks like something everyone would want.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Question about qml compiler?

[Young Moon Jung]

Hi All of qt members.

I have a question about qml compiler.
I want to develop application which is based on QML with Qt 5.6.0. ( open
source license )

When I checked below link, I saw that qml compiler is commercial license.



*https://www.embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/
*
My Question is that Should I use qml compiler for developing QML
application?
I think I can develop QML application only use qmake like below.
( qmake /Users/josh/untitled7/untitled7.pro -spec macx-clang CONFIG+=debug
CONFIG+=x86_64 CONFIG+=qml_debug && /usr/bin/make qmake_all )



Thanks & Regards,
Josh.


-- 
*Jung Young Moon   DrimAES Inc.*

*Address*  *#803, Ace Twin Tower 2-cha, 273, Digital-ro, Guro-gu, Seoul,
Korea
*
*Mobile* *+82 (0)10 - 4907 - 2117*
*Mail* j...@drimaes.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] About 3D desktop.

[Stef Bon]

Thanks a lot for the time.
I'm kind of busy now, but soon (2/3 days) I will come with a response.

We'll build an awesome 3D desktop!

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

Re: [Development] Closing issues automatically with new keyword

[Thiago Macieira]

On Tuesday, 7 August 2018 04:59:02 PDT Jani Heikkinen wrote:
> I see at least one problem there: If bug is affecting to several branches it
> will be closed when fix for first branch is done even in that case it
> shouldn't be closed until every branch has a fix...

I usually close the bug when the first branch gets the fix. When the other 
branches get it, I just update the bug report with an extra Fix For and SHA-1.

This is a nice way for the script to do the same.

-- 
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] Closing issues automatically with new keyword

[Tor Arne Vestbø]

> On 7 Aug 2018, at 16:06, Frederik Gladhorn  wrote:
> 
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
>> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
>>> I've spend a bit of time writing a script that monitors gerrit and the git
>>> repositories to update JIRA statuses. It's not quite done yet, but getting
>>> there.
>> 
>> so why exactly are you doing this after i implied in
>> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
>> look at
>> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
>> did your investigation reveal that it's unsalvagably bad?
> 
> I guess it could work, it can close issues, but it doesn't have any idea 
> about 
> versions. I just looked at the code now.
> 
>> 
>> after the elusive gerrit upgrade (hey, we finally have someone assigned
>> to that now (!)), either script based solution will be obsoleted by
>> deploying
>> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
>> anyway.
> 
> I was not aware of/forgot that comment. I am also unsure if I want to wait 
> for 
> that gerrit update to manifest.

Agreed, let’s decouple these two tasks for now. If it turns out the script will 
be obsoleted, so be it 

Tor Arne 


> I'd really like to get the fix version set, so that we can generate change 
> logs more easily when it comes to fixed issues for each release.


> 
> Cheers,
> Frederik
> 
>> 
>> ___
>> 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] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
> 
> so why exactly are you doing this after i implied in
> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
> look at
> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> did your investigation reveal that it's unsalvagably bad?

I guess it could work, it can close issues, but it doesn't have any idea about 
versions. I just looked at the code now.

> 
> after the elusive gerrit upgrade (hey, we finally have someone assigned
> to that now (!)), either script based solution will be obsoleted by
> deploying
> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
> anyway.

I was not aware of/forgot that comment. I am also unsure if I want to wait for 
that gerrit update to manifest.
I'd really like to get the fix version set, so that we can generate change 
logs more easily when it comes to fixed issues for each release.

Cheers,
Frederik

> 
> ___
> 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] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 15.23.52 CEST Robert Löhning wrote:
> Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
> > Hi all,
> > 
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
> > Basically it should be able to set the fixed version and close tasks
> > automatically.
> > 
> > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the
> > keyword to trigger this.
> > 
> > The plan is to update the fix versions and close the task as done when a
> > line in the commit message starts with "Fixes:".
> > If the issue is already closed (e.g. cherry-pick) it can add an additional
> > fix version (e.g. 5.9.7).
> > 
> > Note: Task-number will be used as before as "this is related to the issue
> > in some way".
> > 
> > Cheers,
> > Frederik
> 
> Hi,
> 
> would that work for all project in JIRA immediately or only in QTBUG?

It should work for all.

Frederik

> 
> Cheers,
> Robert
> ___
> 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] Closing issues automatically with new keyword

[Robert Löhning]

Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:

Hi all,

I've spend a bit of time writing a script that monitors gerrit and the git
repositories to update JIRA statuses. It's not quite done yet, but getting
there.
Basically it should be able to set the fixed version and close tasks
automatically.

Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
to trigger this.

The plan is to update the fix versions and close the task as done when a line
in the commit message starts with "Fixes:".
If the issue is already closed (e.g. cherry-pick) it can add an additional fix
version (e.g. 5.9.7).

Note: Task-number will be used as before as "this is related to the issue in
some way".

Cheers,
Frederik


Hi,

would that work for all project in JIRA immediately or only in QTBUG?

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

Re: [Development] Closing issues automatically with new keyword

[Oswald Buddenhagen]

On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> I've spend a bit of time writing a script that monitors gerrit and the git 
> repositories to update JIRA statuses. It's not quite done yet, but getting 
> there.
>
so why exactly are you doing this after i implied in 
https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
look at
https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
did your investigation reveal that it's unsalvagably bad?

after the elusive gerrit upgrade (hey, we finally have someone assigned
to that now (!)), either script based solution will be obsoleted by
deploying
https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
anyway.

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

Re: [Development] Closing issues automatically with new keyword

[Alex Blasche]

> -Original Message-
> From: Development  project.org> On Behalf Of Jani Heikkinen

> >The plan is to update the fix versions and close the task as done when
> >a line in the commit message starts with "Fixes:".
> >If the issue is already closed (e.g. cherry-pick) it can add an
> >additional fix version (e.g. 5.9.7).

The devil is in the detail. We don't want FixVersion to be set to 5.11 but set 
to 5.11.x.  When you look at a bug 6 month down the road you don't want to know 
that it was fixed in 5.11 but you want to know the exact patch level release. 
Especially the LTS releases tend to have many patch lvl number.

This implies that the script needs to know when 5.11.x was branched off and 
that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1 may 
never be released is irrelevant though as that's a simple bulk change when the 
decision to not have x+1 comes through. Is this what you intend to do?

> I see at least one problem there: If bug is affecting to several branches it 
> will be
> closed when fix for first branch is done even in that case it shouldn't be 
> closed
> until every branch has a fix...

That's the developer's decision as much as it is today already. If you know 
that the fix should go to multiple branches you should probably not use the 
"Fixes" keyword for the first commit but the existing "Task-number" keyword.

> Another concern or question is that in which phase we should close the bug; 
> is it
> done immediately when fix is in or should it be done when fix is in the 
> packages
> and someone can verify that fix is there and really fixes the problem...

It can only ever be when it is in the code line. That's correct for 90% of all 
cases. We cannot optimize for the case when releasing becomes creative and 
starts shifting around SHA's or decides to create the package. I am sure 
releasing does not want to be responsible for setting the fix version across 
all tasks. It does not scale. In other words the status quo applies.

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

Re: [Development] Closing issues automatically with new keyword

[Jani Heikkinen]

>
>From: Development  on 
>behalf of Frederik Gladhorn 
>Sent: Tuesday, August 7, 2018 12:46 PM
>To: development@qt-project.org
>Subject: [Development] Closing issues automatically with new keyword
>
>Hi all,
>
>I've spend a bit of time writing a script that monitors gerrit and the git
>repositories to update JIRA statuses. It's not quite done yet, but getting
>there.
>Basically it should be able to set the fixed version and close tasks
>automatically.
>
>Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
>to trigger this.
>
>The plan is to update the fix versions and close the task as done when a line
>in the commit message starts with "Fixes:".
>If the issue is already closed (e.g. cherry-pick) it can add an additional fix
>version (e.g. 5.9.7).
>
>Note: Task-number will be used as before as "this is related to the issue in
>some way".
>
>Cheers,
>Frederik

Hi,

I see at least one problem there: If bug is affecting to several branches it 
will be closed when fix for first branch is done even in that case it shouldn't 
be closed until every branch has a fix...

Another concern or question is that in which phase we should close the bug; is 
it done immediately when fix is in or should it be done when fix is in the 
packages and someone can verify that fix is there and really fixes the 
problem... 

br,
Jani


___
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] Closing issues automatically with new keyword

[Christian Kandeler]

On Tue, 7 Aug 2018 11:46:12 +0200
Frederik Gladhorn  wrote:

> I've spend a bit of time writing a script that monitors gerrit and the git 
> repositories to update JIRA statuses. It's not quite done yet, but getting 
> there.
> Basically it should be able to set the fixed version and close tasks 
> automatically.
> 
> Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the 
> keyword 
> to trigger this.

Sounds like an excellent plan. Thanks.


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

Re: [Development] Closing issues automatically with new keyword

[Tor Arne Vestbø]

On 7 Aug 2018, at 11:46, Frederik Gladhorn  wrote:
> 
> Hi all,
> 
> I've spend a bit of time writing a script that monitors gerrit and the git 
> repositories to update JIRA statuses. It's not quite done yet, but getting 
> there.
> Basically it should be able to set the fixed version and close tasks 
> automatically.
> 

Excellent!

> Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the 
> keyword 
> to trigger this.

Sounds good! Perhaps the commit message template should include this field at 
the bottom too?

> 
> The plan is to update the fix versions and close the task as done when a line 
> in the commit message starts with "Fixes:".
> If the issue is already closed (e.g. cherry-pick) it can add an additional 
> fix 
> version (e.g. 5.9.7).
> 
> Note: Task-number will be used as before as "this is related to the issue in 
> some way”.

Good :)

Tor Arne 

> 
> Cheers,
> Frederik
> 
> 
> 
> ___
> 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] Closing issues automatically with new keyword

[Frederik Gladhorn]

Hi all,

I've spend a bit of time writing a script that monitors gerrit and the git 
repositories to update JIRA statuses. It's not quite done yet, but getting 
there.
Basically it should be able to set the fixed version and close tasks 
automatically.

Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword 
to trigger this.

The plan is to update the fix versions and close the task as done when a line 
in the commit message starts with "Fixes:".
If the issue is already closed (e.g. cherry-pick) it can add an additional fix 
version (e.g. 5.9.7).

Note: Task-number will be used as before as "this is related to the issue in 
some way".

Cheers,
Frederik



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

Re: [Development] Programmable delegate selection for QML views

[Paolo Angelelli]

On Mon, 6 Aug 2018 15:34:00 +0200
Pierre-Yves Siret  wrote:

> > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself  
> Loader can wrap QObject too. This works : Instantiator { Loader { QtObject
> {} } }
> http://doc.qt.io/qt-5/qml-qtquick-loader.html#sourceComponent-prop : "Since
> QtQuick 2.0, Loader is able to load any type of object; it is not
> restricted to Item types."

True, but that example is a bit artificial.

How about nesting some other QObject * subclass that should be the delegate in 
a view?
And, also, loaded elements are childItems of the Loader itself, if QQuickItems.
If it's a QObject only, there's the "QObject *item" property instead.
But then views should then handle the Loader case specifically to extract the 
QObject.

If the view uses a delegate model, instead, at least with options 2. and 3., it 
would
require no special handling. If the view is supposed to have QObject delegates 
and
does not support (in principle) a Loader, no special handling would be required.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programmable delegate selection for QML views

[Svenn-Arne Dragly]

On 08/06/2018 05:03 PM, Mitch Curtis wrote:

-Original Message-
From: gr3...@gmail.com  On Behalf Of Pierre-Yves


A default delegate looks like the sensible way to go indeed.
But should we REQUIRE one ? Why can't we just not instantiate something
when no fitting delegate is found ? That's what I believe #1 is actually doing.

It's an interesting question. :D Personally I don't see the point. The behaviour for 
views has always been that there will always be a delegate available when it is needed. 
How would "missing" delegates work? I would imagine that would mess up 
something, somewhere internally in Qt Quick view classes.

Or to ask it a different way: why do you have data in your model if it 
shouldn't be displayed?
Sounds like it would be useful to filter data in a view. For instance, 
if you have multiple views of the same data, but want only certain data 
categories in each view. This could also be used to create dynamic 
filters with a custom delegate chooser.


That being said, we already have existing and powerful mechanisms to 
filter data in Qt, and I'm not sure if adding yet another mechanism to 
choose from is a good idea.


However, I see many users setting the "visible" property of their 
delegates based on some logic as a hacky filter implementation today 
(just search for "how to filter data in QML"). This is typically because 
subclassing QSortFilterProxyModel is too much hassle for a simple list, 
for instance if all you need is a ListModel with 50 items and a search 
box. I don't have a complete overview of models/views in QML, so please 
correct me if there are other simple, yet more elegant ways of filtering 
in these simple cases. Otherwise, this might be worth keeping in mind in 
this discussion.


Svenn-Arne

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