Re: [Development] Should QObject::event() be protected or public?

[Christian Kandeler via Development]

On 3/15/24 18:09, Marc Mutz via Development wrote:

I like simple rules. "Overrides should have the same access level as the
initial virtual function." is a simple rule.


But it makes no sense in general. The base class is the interface, and 
overrides should have the least possible visibility for their purpose.



Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How to document API only deprecated in future Qt versions

[Christian Kandeler via Development]

On 9/15/23 09:36, Kai Köhne via Development wrote:

The methods are formally marked as deprecated for Qt 6.10. But the methods are 
already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird 
in-between state.


Radical idea: Treat all deprecated functions as if they didn't exist, 
i.e. remove the documentation entirely. It seems counter-intuitive that 
legacy interfaces should take more documentation effort than current 
ones. Also, this way, fewer people will even be tempted to 
short-sightedly use them.



Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Do we need VS2019 for Qt 6.6?

[Christian Kandeler via Development]

On 2/2/23 16:38, Vladimir Minenko wrote:

In 2022 and 2023, around 24M builds ran on Windows in around 600K unique 
installations worldwide which had at least 10 builds in this period of time. 
Not even a single one used MSVC2022.


That's difficult to believe. I'm inclined to think the version was not 
detected correctly.



Christian

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt example development guideline and revamping examples

[Christian Kandeler via Development]

On 1/18/23 19:56, A. Pönitz wrote:


As a data point, even at it's height of .ui usage, Qt Creator (which is
a "namespace aware" code base, see https://wiki.qt.io/Qt_In_Namespace)
needed the QT_*_NAMESPACE for about 30 of its >200 .ui classes, and
that in the presence of ~680 places where it was needed for other
reasons.


That's probably because we went out of our way to explicitly add a 
namespace to the types in the ui file.



If it had been considered a problem at the time, we'd probably had
the uic flag for 13 years or so...


There are various bug reports along the lines of 
https://bugreports.qt.io/browse/QTCREATORBUG-19590, which we basically 
ignored.



Christian

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

Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

[Christian Kandeler via Development]

On 1/12/23 01:24, Thiago Macieira wrote:

On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote:

Will these be returning at some point?

No.


Out of curiosity: Who gains what by removing branches?


Christian

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

Re: [Development] Nominating Marcus Tillmanns as Approver

[Christian Kandeler via Development]

On 11/22/22 22:27, A. Pönitz wrote:

I'd like to nominate Marcus Tillmanns as an approver for the Qt project.

+1


Christian

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

Re: [Development] Using '#pragma once' instead of include guards?

[Christian Kandeler via Development]

On 10/10/22 17:13, Thiago Macieira wrote:
The biggest problem we used to have was installing builds that had 
include

paths pointing to both the source and installation directory. With
preprocessor guards, only one of the two would actually get included; with
#pragma once, the files are actually different so both would get included,
causing a build error.


Was this really verified or just a guess? Use of #pragma once is rather 
wide-spread, and so is implementing header precedence via include path 
order, so one would think lots of project would have problems if that 
combination didn't work.



Christian

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

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

[Christian Kandeler]

+1

On 1/18/22 15:10, Cristián Maureira-Fredes wrote:

Hello,

I would like to nominate Sona as maintainer [1]
for the qt5compat module, which at the moment doesn't
have one. Even if it's a special module we have around
only for Qt6, we need a responsible person in charge of it.

She has been working mainly in qtbase in the last years
and took care of many tasks when the module was created [2].

Due to her contributions in qtbase and other modules [3],
I firmly believe she will manage to maintain it.

Cheers


[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged
[3] 
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged



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

Re: [Development] Qbs development

[Christian Kandeler]

On 9/15/21 1:03 PM, Oswald Buddenhagen wrote:

in this case, you personally instructed the maintainer to do only
minimal maintenance work (which he does an excellent job at). he has
repeatedly made clear that he has exactly *zero* interest in the
strategic direction of qbs, and is letting "the community" duke it out
among itself, exactly as you wished. he provides no guidance whatsoever,
but reserves the right to cut short discussions he finds boring (or
something). the -2 is an override on that institutionalized
indifference.


I think our definition of "guidance" differs. For me, it does not 
involve going into infinite loops of obsessively arguing about points 
that only I care about. I do believe, however, that I am reasonably 
capable of telling a good patch from a bad one and constructive advice 
from self-serving bickering.



Christian

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

Re: [Development] Windows maintainer change

[Christian Kandeler]

+1

On 6/15/21 9:27 AM, Oliver Wolff wrote:

Hi all,

I would like to propose a change in Qt's Windows maintainership. I 
think that everybody knows, that Friedemann has been doing a great job 
maintaining the Windows platform specifics in Qt's code base. He wants 
to focus on Qt for Python now so we have been looking for an 
alternative way of maintenance.


I propose a shared maintenance between Andre de la Rocha and me for 
Windows. Andre has been involved in Qt's Windows development for 
almost 4 years now. He is responsible for our accessibility backend on 
Windows and rewrote mouse/touch/pen handling for that platform. He 
also wrote the "win32" bluetooth backend and fixed bugs in various 
areas of Qt.


I have been part of the winrt maintainership and wrote and maintain 
the "winrt" backend for Bluetooth (which is also used in Qt6 as the 
backend also works for "desktop" applications on Windows 10).


Thanks again to Friedemann for all the work he put into the 
maintenance of Qt. You have been doing a great job and I hope that we 
can ask for some guidance now and then ;)


Best regards,
Olli
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

Re: [Development] Qt6 repo

[Christian Kandeler]

On 1/13/21 11:46 PM, Thiago Macieira wrote:
Like I said above, the latest tip of the branch for every single 
module. This

recipe has worked for me for 10 years.


I don't believe you.


Christian

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

Re: [Development] Nominating Max Goldstein as an approver

[Christian Kandeler]

On 12/14/20 9:13 AM, Ulf Hermann wrote:

I would like to nominate Max Goldstein as an approver for the Qt Project.


+1


Christian

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

Re: [Development] qsizetype and classes working with QStrings or QList

[Christian Kandeler]

On Mon, 24 Aug 2020 14:45:19 +0300
Ville Voutilainen  wrote:

> On Mon, 24 Aug 2020 at 12:17, Mathias Hasselmann
>  wrote:
> > >> C++ also has a solution for that problem:  
> > >> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> > > That non-solution is terrible. The very reason for not using deduced
> > > types is to detect API breaks loudly.
> > > The warning does that in dulcet tones, not as loudly as some might
> > > wish because the conversion is implicit.
> > > Buying the AAA snake oil can move the problem elsewhere for a while,
> > > but it's not helpful; it's partially
> > > hiding an API break, and it's unlikely that you want that to continue;
> > > the manifestations of the API break
> > > are going to appear further away from the spots where they could be
> > > first detected.
> >
> > Do you have examples showing verifiable evidence, or do you share a feeling?
> 
> I don't have verifiable evidence examples, but the gist of it is this:
> 
> ConcreteType x = foo(); // this detects API breaks right here, right now
> ...
> ...
> ...
> some_use_of(x);
> 
> With AAA, this might become
> 
> auto x = foo(); // this always compiles
> ...
> ...
> ...
> some_use_of(x); // you may detect an API break here, or somewhere deep
> inside some_use_of
> 
> I wonder where the verifiable evidence is that AAA works at scale.

What about:

some_use_of(foo());

Are you suggesting that this is an anti-pattern?


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

Re: [Development] QProperty and library coding guide

[Christian Kandeler]

On Thu, 16 Jul 2020 10:32:08 +
Edward Welbourne  wrote:

> > [...] let me first give an introduction here, and answer some of your 
> > question.
> 
> I have turned a large chunk of that into
> https://wiki.qt.io/QProcess

Are you sure about the URL?


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

[Development] Nominating Ivan Komissarov as approver

[Christian Kandeler]

Hello,

I'd like to nominate Ivan Komissarov as an approver.
Ivan has been doing valuable work in the qbs project for a while now, both as a 
contributor and a reviewer.
I trust him to use his approver rights responsibly.

His commits can be found here:
https://codereview.qt-project.org/q/owner:ABBAPOH%2540gmail.com


Best regards,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Stepping down as moc maintainer.

[Christian Kandeler]

On Tue, 5 May 2020 07:43:27 +
Lars Knoll  wrote:

> I’m happy to say that I have a great candidate who’d be willing to take over 
> the maintainership. Fabian Kosmale would be interested in taking over from 
> Olivier. He has been working on a couple of features for the moc over the 
> last month, continuing work that Olivier started. 

+1


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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Christian Kandeler]

On Fri, 21 Feb 2020 15:00:53 +0200
Ville Voutilainen  wrote:

> On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  wrote:
> > > Why do I need to know that it's a signal being emitted? How is that
> > > "vital information"? I could just as well
> > > invoke any other callback, but I find myself not exactly yearning for
> > > being able to write
> > > callback somethingHappened();
> >
> >
> > Signals have different semantics than regular functions.
> 
> In what way?

They typically call back into "upper layers", which is worth considering on the 
calling side, e.g. due to the danger of inconsistent state getting accessed if 
you don't emit the signal at the end of a function, to name just one tyical 
pitfall.
I, for one, definitely want to see whether I am emitting a signal or not.


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

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Christian Kandeler]

On Tue, 18 Feb 2020 11:17:38 +
Edward Welbourne  wrote:

> > - of the 6 times I can find of QProcess being derived from in Qt & Qt
> >   Creator, 5 are to override setupChildProcess anyway and the last one
> >   is in tst_QProcess
> 
> Does anyone have sources from outside Qt project that are currently
> forced to derive from QProcess for the sake of this ?  If so, please try
> to work out how Thiago's change would affect you and give the rest of us
> a summary.

In qbs, we use it to call setpgid() with the id of the newly created process.
But I don't understand why that should matter at all: Whether we inject the 
code via an overriden virtual or a std::function is purely a question of 
implementation technique, is it not? How can there possibly be a functional 
difference?


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

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Christian Kandeler]

On Tue, 18 Feb 2020 19:35:53 +0800
Sze Howe Koh  wrote:

> See 
> https://forum.qt.io/topic/111473/maintenance-tool-error-cannot-open-file-for-writing-no-error/

Probably the same as https://bugreports.qt.io/browse/QTBUG-77375.

> Is this worth a post on the Qt Blog? I foresee many frustrated and
> confused Ryzen users out there who would benefit from a reminder to
> update their BIOS.

I suppose it won't hurt, but I wonder how such a system is usable at all...


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

Re: [Development] Changes to Qt offering

[Christian Kandeler]

On Mon, 27 Jan 2020 19:09:43 +0100
Giuseppe D'Angelo via Development  wrote:

> Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
> > *We do hope that this eases your concerns, and that we can continue 
> > with your trust*.
> >
> > https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
> 
> That blog post is now removed. The URL is correct, as it's cross 
> referenced from other blog posts.

The link works for me (at the time of writing). Let's assume there just was a 
technical mishap.


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

Re: [Development] Stepping down as Qt for macOS maintainer (but don't worry)

[Christian Kandeler]

On Mon, 9 Dec 2019 11:33:16 +
Morten Sørvig  wrote:

> I’d like to formally step down as Qt for macOS maintainer, and suggest that 
> Tor Arne Vestbø takes over in my place. He’s already maintaining Qt for iOS 
> (and QPA), and has done a lot of good work on macOS over the past couple of 
> years.

Is it required for this job to have an ø in your name?


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

Re: [Development] Assistant WebKit/WebEngine support

[Christian Kandeler]

On Thu, 27 Jun 2019 08:47:07 +0300
Alberto Mardegan  wrote:

> On 27/06/19 04:47, Lars Knoll wrote:
> > 
> > Yes, Webengine uses some memory. But is that really a problem on developer 
> > machines?
> 
> Yes. The more RAM you use for surfing documentation, the less RAM you
> have for building. I have 16 GB of RAM, and sometimes I have to close
> Chromium away (yes, I know, my fault, I should use a more lightweight
> browser!). Doing the same with QtCreator (which I only use for browsing
> documentation, not for actual development) would be quite troublesome.

Speaking of more light-weight applications: You probably should be using 
assistant instead.


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

Re: [Development] Assistant WebKit/WebEngine support

[Christian Kandeler]

On Wed, 26 Jun 2019 11:24:30 +
Riitta-Leena Miettinen  wrote:

>   3.  Should the same style be used online and offline?
>
> For 3), we always answered „yes“, because we felt that the use cases for 
> reading documentation on the web or using it within Qt Creator next to the 
> Code editor were different. 

Just for clarification: I assume you meant "no" here?


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

Re: [Development] Views

[Christian Kandeler]

On Thu, 06 Jun 2019 13:46:12 +0200
"Mutz, Marc via Development"  wrote:

> On 2019-06-06 12:24, Ola Røer Thorsen wrote:
> > tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
> > :
> > 
> >> Qt is GUI framework. Not only, yes, but this is the main purpose.
> >> +/-
> >> 10MB is almost nothing for GUI apps. Slightly faster
> >> lookup/insertions,
> >> cache line, proper alignment... Well, nice to have, but when an app
> >> spends most of the time on rendering something, it doesn't matter.
> >> Highly unlikely will it be a bottle neck.
> > 
> > I'm still supporting Qt Quick-applications running on devices with a
> > total of only 128 MB RAM, so I disagree that +/- 10MB is irrelevant
> > for Qt. The performance could definitely be better too.
> 
> 
> I'm sorry. I tried. But you'll have to upgrade your hardware, because 
> the people that develop the product you base your work on are unable to 
> read code that uses std::lower_bound.
> 

Could you please stop trolling? It's getting quite annoying.


Thanks,
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecation/removal model going into Qt 6

[Christian Kandeler]

On Sat, 1 Jun 2019 14:36:12 +0200
André Pönitz  wrote:

> On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry
> > poorly designed architecture or APIs around with us throughout the Qt
> > 6 series, and as long as we care about binary and source compatibility
> > within a major series, doing what we can for Qt 6.0 (and doing it
> > right) is the only option we have.
> 
> The problem is that we as a whole do not agree what "poorly designed
> architecture or APIs" means in detail anymore, sometimes even on a very
> fundamental level.
> 
> E.g. the previous consent on Qt providing consistency and convenience
> is challenged regularly by some.

I don't think there is an actual controversy there; the term "some" already 
seems to be an overstatement.


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

Re: [Development] unique_ptr and Qt, Take 2

[Christian Kandeler]

On Sat, 04 May 2019 09:06:39 +0200
Allan Sandfeld Jensen  wrote:

> On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote:
> > On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote:
> > > Which should be considered bad practice and banned on an API level
> > 
> > No way.
> > 
> > Are you going to forbid creation of QFile on the stack?
> 
> Perhaps QFile shouldn't be the same kind of base object type as QWidgets? Or 
> not use the same smart pointer.
> 
> Though even making QWidgets not allowed on the stack, while sensible, would 
> break a many of our tests, where we "abuse" that it is technically possible 
> in 
> simple cases.

Doesn't almost every project create its main widget on the stack? 


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

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Christian Kandeler]

On Tue, 2 Apr 2019 15:14:38 +
Mitch Curtis  wrote:

> As described in https://bugreports.qt.io/browse/QTBUG-66320, currently Qt 
> users are on their own if they want to call helper functions that can fail a 
> test. The reason is documented:
> 
> Note: This macro can only be used in a test function that is invoked by 
> the test framework.
> 
> A common workaround for this is to make the helper function return a bool 
> indicating success or failure, and pass in a QString reference which is set 
> to the failure message (if any).
> 
> I don't know how many people reading this have written comprehensive auto 
> tests for an application, but not having helper functions is just not an 
> option if you want maintainable code.
> 
> I looked into this briefly during the last hackathon we had, and from what I 
> found, throwing an exception was the best approach:
> 
> https://codereview.qt-project.org/#/c/248490/

+2 for the general idea. It would solve a problem that comes up again and again 
and always requires awful workarounds.


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

Re: [Development] On deprecating functions

[Christian Kandeler]

On Mon, 4 Mar 2019 22:27:42 +0100
André Pönitz  wrote:

> (5) Use #if (QT_VERSION / QT_VERSION_CHECK. To "fix" perfectly
> valid code *for cosmetical reasons*? DUH!

Example: https://codereview.qt-project.org/#/c/252715/1 was necessary because 
of the immediate deprecation of an existing function when a nicer looking 
replacement was introduced.


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

Re: [Development] CMake Workshop Summary

[Christian Kandeler]

On Mon, 25 Feb 2019 08:13:29 +
Jedrzej Nowacki  wrote:

> On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote:
> > But do note that our parallelism isn't that bad right now.
> 
> It is not bad, but it is not great either :-). For example one needs to 
> _link_ 
> QtCore before compilation on other things can be started, it is quite visible 
> on an under-powered machines, where linking takes time. Similar, redundant 
> synchronization point is on the module level.

Also, the examples could have per-app granularity and just start building as 
soon as the respective module is ready,


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

Re: [Development] New API design for file system operations

[Christian Kandeler]

On Thu, 7 Feb 2019 16:03:30 +
Volker Hilsheimer  wrote:

> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
> good API are welcome here in this email thread before moving to a dedicated 
> JIRA ticket. 

My personal pet peeve: Please, let's never again use the term "file name" when 
we actually mean a file path.


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

Re: [Development] New linguist maintainer nomination

[Christian Kandeler]

On Mon, 7 Jan 2019 12:51:25 +
Alex Blasche  wrote:

> After Ossi stepping down as maintainer for Linguist and related tools 
> (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a 
> long history working on Qt and even more specifically with Qt's translation 
> tools. 

+1

(Full disclosure: He's in charge of approving my vacation days.)


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

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Christian Kandeler]

On Thu, 13 Dec 2018 12:47:08 +0100
Kevin Kofler  wrote:

> Christian Gagneraud wrote:
> > On Thu, 13 Dec 2018 at 12:27, Kevin Kofler wrote:  
> >> (so, unlike QBS, it does not depend on Qt, which would mean a circular
> >> dependency when building Qt),  
> > 
> > qmake has this problem, yet it's been packaged for 10+ years without a
> > problem.  
> 
> Bootstrapping QMake has always been the least pleasant part of the Qt build
> process. It requires building parts of Qt (QMake and the classes it depends
> on) with a custom script, making it harder than necessary to get it to use
> the proper build flags (optimization, security hardening, etc.). The script
> is also a completely unnecessary maintenance burden for Qt.
> 
> I am looking forward to this bootstrapping hack going away by just using
> CMake.
> 
> And it would be much worse for QBS, which requires much more from Qt than
> QMake. It requires QML, JavaScript, etc.

It does not require QML.


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

Re: [Development] automated bulk change closing old issues in the "Need more info" state

[Christian Kandeler]

On Mon, 19 Nov 2018 16:01:32 +
Kai Koehne  wrote:

> > -Original Message-
> > From: Development  > project.org> On Behalf Of Uwe Rathmann  
> > Sent: Monday, November 19, 2018 4:10 PM
> > To: development@qt-project.org
> > Subject: [Development] automated bulk change closing old issues in the "Need
> > more info" state
> > 
> > Hi all,
> > 
> > I just received 2 messages about: automated bulk change closing old issues 
> > in
> > the "Need more info" state.
> > 
> > - https://bugreports.qt.io/browse/QTBUG-68874
> > - https://bugreports.qt.io/browse/QTBUG-66264
> > 
> > I have no idea why they have been set to "Need more info" - actually one of
> > them has been explicitly answered, but the developer does not follow up.  
> 
> Then it's good that the bot pointed the wrong state out. Please move the bugs
> back to open state (as you apparently did already). Next time you answer,
> consider clicking "Provide missing info", instead of just commenting [1].

The fact that this is not done ~90% of the time indicates a UI/workflow 
problem, does it not?


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

Re: [Development] Build system for Qt 6

[Christian Kandeler]

On Wed, 31 Oct 2018 10:44:43 +1300
Christian Gagneraud  wrote:

> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  
> wrote:
> > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > The only thing I'm criticising is that its proper chance involves Qt being 
> > the
> > guinea pig. Find someone else instead and grow your community. Get track
> > record for building, cross-compiling, working with weird set ups,
> > containerised build environments, build farms, etc. Don't ask Qt to switch 
> > to
> > it until you've done that work.  
> 
> !?!
> What make you think qbs cannot be used in such environments?That all
> very basic stuff to me.
> - cross-compiling: Qbs support *out of the box* all "standard" OS
> *and* "standard" toolchains.
> - working with weird set ups: what does that even mean? That a very
> vague statement.
> - containerised build: any build system can run in a container, that's
> orthogonal.
> - build farms: Against what is the problem with build farm, i don't get it.
> - etc: again, can you elaborate? that's very vague.
> 
> I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all
> producing platform specific installers.
> It was a breeze.
> I've used it to build a 1.5 million SLOC SW, with complex build
> matrix. The only reason we dropped it, was because of lack of
> integration:
> QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing
> long time ago, Qbs won't take off without XCode, Visual Stidio, Visual
> Code, Eclipse, ... integration.
> And, so far, we failed at switching to CMake, the build matrix is too complex.

So what *are* you using now? Just curious.


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

Re: [Development] QUIP 12: Code of Conduct

[Christian Kandeler]

On Thu, 25 Oct 2018 19:39:45 +0200
André Pönitz  wrote:

> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
> > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't 
> > led to abuse of power, suppression of free speech, racism against white 
> > people 
> > or whatever other nonsense people seem to attribute to CoCs nowadays.  
> 
> The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic",
> "support". It doesn't push someone's personal political agenda.  

I agree. It reads as if it was written with the intention of creating a 
constructive environment, lacks the inquisition-y vibe and is free of jargon 
and weirdly over-specific lists.


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

Re: [Development] QtScxml module maintainer change

[Christian Kandeler]

On Tue, 4 Sep 2018 11:48:24 +
Erik Verbruggen  wrote:

> I'd like to propose Ulf Hermann as the new maintainer of the QtScxml module.

+1


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

Re: [Development] QAbstractItemModel::setItemData behaviour

[Christian Kandeler]

On Mon, 3 Sep 2018 09:03:06 +
Luca Beldi  wrote:

> Gentle ping as I got no answers before.
> 
> 
> Hi everyone,
> While trying to submit a patch to fix QStringListModel::setItemData 
> https://codereview.qt-project.org/235730 we opened a much larger discussion 
> on QAbstractItemModel, that expanded on the forum 
> https://forum.qt.io/topic/93207/qabstractitemmodel-setitemdata-partial-success
>   but that I ultimately would like your opinion on:
> 
> At the moment, QAbstractItemModel::setItemData calls setData for each role 
> until the first failure and returns false if that happens.
> This opens up 2 issues:
> 
> * QAbstractItemModel::setItemData returns false even when some but 
> not all data was actually set without rolling back the changes
> 
> * QAbstractItemModel::setItemData depends on the ordering of the roles
> 
> For the second point, an example that illustrates the problem is 
> (QStringListModel::setItemData just uses the base class implementation):
> QStringListModel::setItemData({{Qt::DisplayRole,QVariant("test")},{ 
> Qt::DecorationRole,QVariant(QIcon())}) will return false but actually set the 
> string to "test"
> QStringListModel::setItemData({{Qt::EditRole,QVariant("test")},{ 
> Qt::DecorationRole,QVariant(QIcon())}) will return false and do nothing on 
> the model
> 
> My proposal is:
> 
> * Remove the ordering-dependency  QAbstractItemModel::setItemData 
> (i.e. sets all the roles it can and returns false if any of them failed)
> 
> * Make setItemData in subclasses of QAbstractItemModel behave 
> transaction-like (i.e. try to set all the roles, if any fails rollback the 
> other changes and return false)
> 
> This however is technically a change of behaviour so I would like people way 
> smarter than me to agree on the way forward.

To me, both suggestions sound better than what is done currently. And 
technically, the potential behavior change does not break any contracts, since 
the details are not specified in the documentation.


Christian
___
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] Qt 6 buildsystem support requirements

[Christian Kandeler]

On Thu, 2 Aug 2018 10:23:12 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
> [snip] 
> > > > As for java in the loop - this is a a build system, how much does it
> > > > matter with what it is written in if the implementation is good?  
> > > 
> > > ...because Java is an *enormous* added dependency  
> > 
> > the actual toolchain and external dependencies play in the same league.
> > ... which is still dwarfed by the size of a single qt debug build.  
> 
> But would be problematic when building for other archs not that powerful as 
> "the normal ones".

You mean *on* other archs? Because the (cross-)compiler does not care how 
powerful the target architecture is.


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

Re: [Development] Changing maintainer-ship for Qt Assistant, Qt Help and Qt Creator’s help Integration

[Christian Kandeler]

On Mon, 28 May 2018 10:19:28 +
Karsten Heimrich  wrote:

> officially I'm still  the maintainer of Qt Assistant & Qt Help and Qt 
> Creator’s help Integration. Since I actually no longer working on this code, 
> I propose Jaroslaw  Kobus as the new maintainer. Jarek has done a lot of good 
> work on these  modules recently and has been a very long time with Qt in 
> general.

+1

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

Re: [Development] Naming convention for (scoped) enums

[Christian Kandeler]

On Thu, 17 May 2018 08:14:15 +
Alex Blasche  wrote:

> The naming conventions for enums state that each enum value name must repeat 
> a part of the enum Type name (for details see 
> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
> 
> In case of scoped enums this becomes a superfluous rule as the type has to be 
> mentioned anyway. Does anybody object to modifying the above definition by 
> adding an exception for scoped enums where you do not have to repeat a part 
> of the enum type name?

I would not have even assumed that the rule applies to scoped enums, but it 
can't hurt to write it down explicitly. Perhaps the section should be rewritten 
so that the unscoped enums are the special case rather than the other way 
around.


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

Re: [Development] Goodbye

[Christian Kandeler]

On Fri, 9 Feb 2018 21:14:22 +0100
Jake Petroules  wrote:

> Steve Jobs once said:
> 
> > “I have looked in the mirror every morning and asked myself: "If today were 
> > the last day of my life, would I want to do what I am about to do today?" 
> > And whenever the answer has been "No" for too many days in a row, I know I 
> > need to change something.”  

Yeah, but he also said "Let's treat this cancer with some random herbs instead 
of actual medicine", so I'm not sure you should just blindly follow his advice.
Just sayin'.

> After 8 years of Qt, it's time to say goodbye. Both from my employment in The 
> Qt Company and my roles in the Qt Project. I'd like to thank those of you in 
> the company and in the Qt Project who have supported me over the years in 
> various ways. It's been a great adventure. Friday, February 23rd will be my 
> last day.
> 
> I hereby relinquish my role as Maintainer of Apple build system support 
> across all projects under the Qt Project umbrella (nominating Oswald 
> Buddenhagen as my replacement), and my role as Maintainer of the Apple 
> watchOS platform (nominating Tor Arne Vestbø as my replacement).

I'm missing the part where you provide the qbs project with a new macOS freak, 
so I'm afraid I can't accept this resignation.


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

Re: [Development] Nominating Kari Oikarinen for Approver Status

[Christian Kandeler]

On Fri, 9 Feb 2018 14:18:56 +0100
Rainer Keller  wrote:

> I'd like to nominate Kari Oikarinen for approver status in the Qt Project.

+1


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

Re: [Development] Getting build flags for platforms without pkg-config

[Christian Kandeler]

On Mon, 30 Oct 2017 09:00:46 +0100
Jeandet Alexis  wrote:

> Le dimanche 29 octobre 2017 à 15:57 -0700, Thiago Macieira a écrit :
> > On domingo, 29 de outubro de 2017 14:57:44 PDT Jeandet Alexis wrote:  
> > > Hello,
> > > 
> > > Previously I asked about getting some defines from pkg-config, I
> > > pushed
> > > some code on gerrit to fix that.
> > > 
> > > Now I would like to care about platforms where we don't use pkg-
> > > config,
> > > at first I thought that we could get compile flags from qmake but
> > > it
> > > seems that no.  
> > 
> > You can get them from either qmake or cmake. The flags are saved
> > there.
> > 
> > You should also reconsider and install pkg-config on those platforms.
> >   
> > > Did I miss something?
> > > Would there be a way to get compile flags for a build system like
> > > meson?  
> > 
> > Either write a .pro file that prints or saves the flags, or read the 
> > $$[QT_INSTALL_ARCHDATA]/mkspecs/modules/qt_lib_*.pri files.
> > 
> > Reading the files directly is officially looking into private API and
> > we cannot 
> > promise you that it will continue working. But I don't see how to do
> > it 
> > officially with qmake either.  
> I was affraid I would get this answer. How do you solve this issue with
> QBS? Does qmake generate files for QBS on each Qt version or do you
> hardcode stuff in QBS? 

Neither. At the moment, qbs simply parses the module .pri files. The proper 
solution would be to provide qbs module files with Qt.


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

Re: [Development] Future of QBS

[Christian Kandeler]

On Wed, 18 Oct 2017 08:46:34 +0200
Jeandet Alexis  wrote:

> Le mardi 17 octobre 2017 à 17:45 +0200, Giuseppe D'Angelo a écrit :
> > (Small story: when I presented Qt Creator at CppCon last year,
> > people's 
> > reactions were always these two:
> > 
> > 1) "Oh, wait, it's a general purpose IDE? It's not just for building
> > Qt 
> > applications?"  
> You are right, but what is misleading I think is that some visible
> features are for Qt(designer, QML...), then I'm not sure that it is
> possible to build anything without qmake(-> without any kit). The fact
> that non Qt users have to deal with Qt kits is really painfull.

While there might have been a time where setting a Qt in the kit was required, 
it certainly isn't these days. 
The actual problem in that area is that some plugins are not agnostic to the 
build tool being used, i.e. they only work with qmake projects. This is due to 
the history of Qt Creator.


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

Re: [Development] Future of QBS

[Christian Kandeler]

On Tue, 17 Oct 2017 17:23:17 +0200
Ulf Hermann  wrote:

> >> Exactly. The halting problem can be worked around pragmatically.  
> > 
> > ... at the price of getting different build results based on CPU speed ...
> > 
> > Your fast desktop CPU crunches through the JS and you get a working
> > built, while my sucky laptop CPU does not and the build fails for me.  
> 
> A simple timeout may be a bit too pragmatic, but you could count the JS 
> instructions executed.

Whatever happened to pressing "Cancel"?


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

Re: [Development] Future of QBS

[Christian Kandeler]

On Mon, 16 Oct 2017 01:23:51 +0800
Ben Lau  wrote:

> I am still new to QBS, but I think it is better than CMake too. However, I
> think it has missed a critical feature - A simple way to run custom script.
> 
> For example, run a script to call external command (not a product by your
> application) to deploy your application to App Store or simply upload to a
> server.
> 
> Currently it is quite difficult to do it via qbs, so it will still need a
> platform depended script system.

Really? It appears to me that this is easily done using a rule in a dedicated 
product (builtByDefault would probably set to false). We can follow this up on 
the qbs mailing list if you like.


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

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Christian Kandeler]

On Fri, 13 Oct 2017 15:13:16 +0200
Viktor Engelmann  wrote:

> >>  4. I don't think we need to be as paranoid towards contributions
> >> from > our own employees as we need to be towards external
> >> contributions.  
> > Anyone with approver rights should be aware of his powers and use them
> > carefully, no matter if he is employed at The Qt Company or an
> > external contributor.  
> 
> Sure - but let's think about this in a different context: imagine
> someone applies at your company. You invite them to a job interview and
> have one of your engineers do a technical interview with them.
> 
> Do you afterwards go to the applicant and ask them if they thought your
> engineer was competent and fire your engineer if the applicant says "no"?

This is an incredibly arrogant stance to take. No contributor is above others 
because of their employer.


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

Re: [Development] QLowEnergyController and obsolete ctor

[Christian Kandeler]

On Tue, 29 Aug 2017 11:18:02 +
Alex Blasche  wrote:

> Hi Martin,
> 
> > -Original Message-
> > From: Development [mailto:development-
> > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Martin Koller  
> 
> > In Qt 5.9 I find that the following ctor is marked as obsolete:
> > 
> > explicit QLowEnergyController(const QBluetoothAddress ,
> >   const QBluetoothAddress ,
> >   QObject *parent = Q_NULLPTR); // TODO Qt 
> > 6 remove ctor
> > 
> > but there is no other way to create a QLowEnergyController which does not 
> > use
> > the local default adapter.
> > 
> > How is this supposed to work ?  
> 
> The ctor still exists and works. You can use it for Bluetooth Central use 
> cases. Having two local adapters is a very rare use case and only supported 
> when using Bluez. That's why it has moved to obsolete. The fix would be to 
> overload QLEController::createCentral(). Could you file a bug for it and 
> assign it to me?

Real-world example use case: My laptop has a built-in Bluetooth controller that 
is not LE-capable. When I plug in a USB-based LE controller, it appears to be 
non-deterministic which of the two devices becomes the default one. So in order 
to do BLE stuff on that machine, I need to use that constructor.


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

Re: [Development] ChangeLog entries and reverted commits

[Christian Kandeler]

On Mon, 31 Jul 2017 11:11:41 +0200
Friedemann Kleint  wrote:

> have a look at https://codereview.qt-project.org/#/c/201164/ for the 
> Perl script.

Are the two scripts competing or do they complement each other in some way?


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

Re: [Development] Introductions?

[Christian Kandeler]

On 04/28/2017 04:05 PM, Edward Welbourne wrote:
> On 25 April 2017 at 10:09 I wrote (inter alia):
>> [...] the same is relevant for any approver or maintainer: perhaps we
>> should tweak our process for introducing candidates for those stations
>> within the community; ask that each introduce self in the course of it
>> - possibly *after* we've made our decision, so we won't be prejudiced
>> by their weird hobbies.  ISTR Lars, when proposing me, just linked to
>> my review history in gerrit; that probably should suffice for the
>> decision on whether to accept a candidate - but it might be worth,
>> once the decision is made, as a matter of course, having the new
>> approver or maintainer introduce self, or link to web pages that do
>> so.
> 
> Just to clarify, as one off-list discussion raised concerns about
> pressuring folk to share more than might feel comfortable: I do, of
> course, intend no more than that we invite the newly-chosen to say as
> much about themselves as they feel comfortable saying.  If they wish to
> keep their public exposure to what's visible already on gerrit, they are
> of course free to do so.
> 
> [...]
>> What do folk think ?
> 
> We've heard one +1 and no other public response.

I see one +1 and one -2.


Christian




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

Re: [Development] QProcess fork() failure and overcommit

[Christian Kandeler]

On 03/07/2017 10:05 PM, Thiago Macieira wrote:
> Em terça-feira, 7 de março de 2017, às 17:53:41 CET, René J.V. Bertin 
> escreveu:
>> One tends to forget (I do at least) that spawning a little helper process
>> can be quite expensive, sometimes prohibitively so. Makes you wonder what
>> kind of cross-platform alternatives there are!
> 
> It shouldn't be.
> 
> fork() does need to copy the page tables and mark the pages as shared. It 
> also 
> means COW of certain pages. But the overhead shouldn't be that big.
> 
> If anyone is seeing this, can you run your application with strace to get the 
> timings? 
> 
>   strace -T -e clone

I use the default settings for overcommit (0/heuristic). My application
starts QProcesses in a loop. If the application has not allocated
additional memory, strace -T for clone() gives:

<0.79>
<0.91>
<0.000205>
<0.90>
<0.000119>
<0.000112>
<0.000231>
<0.96>
<0.000114>
<0.000112>

Here's the same application using 1GB of additional memory:

<0.012753>
<0.016715>
<0.015152>
<0.014449>
<0.012960>
<0.016914>
<0.013560>
<0.013337>
<0.012911>
<0.013019>

So, factors around 100?
(Also, I get lots of ERESTARTNOINTR in the latter case).


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

Re: [Development] QProcess fork() failure and overcommit

[Christian Kandeler]

On 03/07/2017 02:54 PM, René J. V. Bertin wrote:
>> This kind of stuff seems to happen when the parent process has allocated
>> a lot of memory. I haven't debugged into it, but one idea might be that
> 
> What is a lot here? Typical usage for one of the KDevelop sessions that tends 
> to 
> be affected is around 70Mb total according to KSysGuard. Hardly a value that 
> shocks me...

More than that. Let's say a Gig, as in my example.

>> Note also that starting a QProcess becomes enormously slow in such
>> applications; for instance, on my machine here, I can only start about
>> 20 processes per second from an application that has 1 GB of memory
>> allocated.
> 
> As opposed to how many from a leaner application?

Hundreds.


Christian

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

Re: [Development] QProcess fork() failure and overcommit

[Christian Kandeler]

On 03/07/2017 02:04 PM, René J.V. Bertin wrote:
> I have a bit of an intriguing issue I hope someone here could help me 
> understand. If not, sorry for the noise.
> 
> I'm seeing occasional QProcess failures where QProcess:waitForStarted() fails 
> and gives rise to errors like
> 
> kdevplatform.vcs: "DVCSJob::start: git ls-files -- kclock.cpp failed to 
> start: Resource error (fork failure): Cannot allocate memory"
> 
> Those come and go in episodes; restarting the affected application always 
> helped too (for a while).
> 
> Last time this happened htop reported I had 6955Mb used of 7899Mb, and not 
> even 10% swap used (1151Mb of 16Gb) but despite that the issue went away when 
> I turned overcommit back on (I usually run with overcommit_memory=2 and 
> overcommit_ratio=80).
> 
> This only happened to me with KDevelop5 until now, i.e. a Qt5/KF5 based 
> application, running on a KDE4 (= Qt4-based) desktop.
> If memory contention were really the cause here I would expect to see traces 
> of similar failures elsewhere too because KDevelop isn't exactly the only KDE 
> application that makes generous use of QProcess.
> 
> Is there anything in QProces (Qt5) vs. the Qt4 version that could explain 
> fork() failing, or else can it be the way QProcess is being used which causes 
> this in KDevelop but not other applications?

This kind of stuff seems to happen when the parent process has allocated
a lot of memory. I haven't debugged into it, but one idea might be that
the page tables themselves get to a non-trivial size and thus copying
them causes allocation problems.
Note also that starting a QProcess becomes enormously slow in such
applications; for instance, on my machine here, I can only start about
20 processes per second from an application that has 1 GB of memory
allocated.


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

Re: [Development] Naming of path/directory-related environment variables in Qt

[Christian Kandeler]

On 11/11/2016 04:13 PM, Mitch Curtis wrote:
> I'd like to establish some kind of convention for naming 
> path/directory-related environment variables in Qt, with the hope that it 
> could be set in stone with e.g. one of these newfangled QUIPs.
> 
> Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, 
> where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER environment 
> variable:
> 
> https://codereview.qt-project.org/#/c/174616/
> 
> I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it 
> seemed we had a few other environment variables using this naming scheme.
> 
> JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt Quick 
> Controls 2:
> 
> https://codereview.qt-project.org/#/c/176512/
> 
> He found more examples of where we've used "PATH" than where we used "DIR", 
> so it seems like a good time to continue with that trend so that we don't 
> have any more inconsistencies.
> 
> My hope is that enough approvers see this email (or QUIP) and its conclusion 
> (whatever it may be) and -1 patches that go against the convention.
> 
> So, can we all agree on using "PATH" when naming environment variables that 
> refer to paths?

But note that "path" is more generic than "dir": A "file path" is not
(necessarily) a directory. So the latter name conveys more information
to me as a user.


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

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

[Christian Kandeler]

On 11/04/2016 09:10 AM, Jędrzej Nowacki wrote:
> In your email you wrote that blacklisted is just a burden for CI. In 
> general it is true, but mark that currently they are compiling and they are 
> _not_ crashing. So they do contribute to the quality of Qt. On the other hand 
> they artificially increase test coverage level hiding untested code paths and 
> they may affect other tests.
> 
> Partial conclusion: delete them, but watch code coverage and add new ones 
> where needed.

If there's still value in having them compiled, can't you just remove
the "testcase" value from CONFIG?


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

Stephen Kelly wrote:

> My previous guess about Qbs being able to generate unknown files in a 
> particular location and then determine them by an 'ls' equivalent, moc 
> them and compile everything is not something Qbs would be able to do.

I'm having trouble parsing this, but if you mean that your previous guess was 
wrong, then I can tell you it was not; that's exactly what we do for "blackbox 
tools".

> I'm still interested in a Qbs solution to the code/repo I posted before. 
> A full and preferably working Qbs solution, instead of a snippet, would 
> be good for comparison.

That's more than I'm willing to invest during my vacation, but I might come 
back to you later there.


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

Stephen Kelly wrote:

>> There is no input file. There is only an input number. The task is from
>> Bo, who gave it as a simplified example.
> Oops, I'm wrong here. Bo said to read the number from a file.
> I don't think that changes anything though regarding dynamic build graph 
> being an advantage.

Sure? What about the (lack of) need for two rules to agree in advance about the 
location of a generated file? Also, there could be several layers of 
indirection, with the second set of generated files also containing meta data 
etc.


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

[Sorry about the formatting, using outlook]

Stephen Kelly wrote:
> Here's the CMake version:

[ ... ]

>  execute_process(
>   COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
>   OUTPUT_VARIABLE fileList
> )

How do you know where the input file is located?

> However, it is cheating in the same way that the QBS version from
> Christian is cheating - it assumes '--list' exists:

Yes, I was assuming a cooperating tool.

> Christian, can you create a version which does not require --list?

There are two possibilities:
a) The inner workings of the tool are known and "simple enough". That's the 
case in Bo's example, so there we could just open the input file and derive the 
output artifacts from the number we find there.
b) Otherwise, our outputArtifacts script has to run the tool in "real mode" 
(using the "--generate" option). The actual command would be a no-op then. This 
is icky, both conceptually and for practical reasons, because commands of 
non-competing rules are run in parallel, whereas the outputArtifacts scripts 
are not. I think so far we only use this approach for the infamous qdoc tool.


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

On 09/08/2016 02:03 PM, Bo Thorsen wrote:
> Ok, go try it. Create a simple python or perl script that reads a file.
> The file just has a single number N inside it. And based on N the script
> outputs those files:
> 
> server.h
> method1.h
> method2.h
> ...
> methodN.h
> 
> Inside method1.h you write this:
> 
> #include 
> 
> class Method1 : public QObject {
>   Q_OBJECT
> };
> 
> server.h has this:
> 
> #include "method1.h"
> ...
> #include "methodN.h"
> 
> class Server {
> public:
>   Method1* call1() { return new Method1; }
>   ...
>   MethodN* callN() { return new MethodN; }
> };
> 
> In main.cpp you instantiate Server.
> 
> The only problem is that you have to run moc on each of the .h files.
> 
> Solution to the problem is only accepted if you can press build one
> single time inside both Visual Studio and Qt Creator and it builds this
> even when you modify the input file and the main.cpp.

In qbs:

Rule {
inputs: ["metadata"]
fileTags: ["hpp"]
outputArtifacts: {
var p = new Process();
try {
p.exec("path_to_script", ["--list", input.filePath]);
var files = p.readStdout.split("\n");
var artifacts = [];
for (var i in files)
artifacts.push({ filePath: files[i],
 fileTags: ["hpp"]});
return artifacts:
} finally {
p.close();
}
prepare: {
var cmd = new Command("path_to_script",
  ["--generate", input.filePath]);
cmd.description = "creating headers";
return [cmd];
}
}

(This is a somewhat more advanced example in that it is not assumed that
we have a priori knowledge about how the content of the input file
relates to the outputs.)


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

Re: [Development] Use of Standard Library containers in Qt source code

[Christian Kandeler]

On 07/01/2016 08:36 PM, Thiago Macieira wrote:

For some time now, we've had a flurry of changes to Qt source code that uses
the Standard Library's containers and algorithms, in the name of performance
and often code size gains.

I'm not disputing that there is a gain. But I am wondering about the trade-off
we're making with regards to readability. For example, I was just reviewing
this code:

if (d->currentReadChannel >= d->readHeaders.size()
|| d->readHeaders[d->currentReadChannel].empty()) {
Q_ASSERT(d->buffer.isEmpty());

The use of the Standard Library member "empty" is highly confusing at first
sight because it does not follow the Qt naming guidelines. It's even more
confusing because the next line has "isEmpty". When I read this code, I had to
wonder if that "empty" was a verb in the imperative, meaning the author was
trying to remove all elements from the container.


I must admit I don't see a problem here. We are not talking about some 
random third-party library that people are pulling in gratuitously, but 
about the Standard Library, an integral part of C++ that every developer 
should be at least generally familiar with.
Having said that, I personally follow the "use Qt types by default" 
approach, but should we really regard STL containers as dangerous 
intruders that need to be kept out if at all possible?



Christian

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

Re: [Development] commas in ctor-init-lists

[Christian Kandeler]

On 06/03/2016 02:52 PM, Thiago Macieira wrote:

I've seen a lot of code do:

#ifdef FOO
if (foo) {
// something
} else
#endif
if (bar) {
// something else
} else {
// default
}


This kind of thing is an abomination that should never ever be allowed, 
regardless of other coding style considerations. You can hardly even 
tell whether the code is syntactically correct in both cases, let alone 
semantics.
Factor out ifdefs into dedicated functions whenever possible. You'll be 
glad you did, and even more so the people who have to read your code later.



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

Re: [Development] RFC: lambda or lambda return from lambda?

[Christian Kandeler]

On 02/01/2016 03:10 PM, Marc Mutz wrote:

The point of giving names to things (variable, functions, classes) in
programming is so you don't need to look at the implementation all the time to
see what it's doing. You only need to look when you want to see _how_ it's
doing what it does.

So if you think that this is not a problem, then it's not a problem for you,
either, if local variables are named only a, b, c, ...


Depending on the context, yes. For instance, I have never written this:
for (int thisIsACounterThatIsUsedForIteration = 0; 
thisIsACounterThatIsUsedForIteration < arrayLen; 
++thisIsACounterThatIsUsedForIteration) { ... }


Instead, I simply use the name "i". Inacceptable?


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

Re: [Development] RFC: lambda or lambda return from lambda?

[Christian Kandeler]

On 02/01/2016 11:08 AM, Marc Mutz wrote:

We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about the
result.

E.g. (not picking on Anton here, I have done the same before):

  auto firstEqualsName = [](const QPair )
  {
   return qstricmp(name.constData(), header.first) == 0;
  };
  fields.erase(std::remove_if(fields.begin(), fields.end(),
  firstEqualsName),
   fields.end());

This is one way to write a unary predicate. But it hides the fact that the
predicate depends on the parameter 'name' (an argument to the function this
lambda is defined in).

With classical function objects, one would have written - at the call site:

  fields.erase(std::remove_if(fields.begin(), fields.end(),
  FirstEquals(name)),
   fields.end());

See the difference?


Yes, but it is offset by another difference: As opposed to the function 
object, the lambda is defined right above the call site (or at least 
very close to it), so you can easily see that it captures an additional 
variable.

I therefore think that this is not a problem.


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

Re: [Development] Suggestion for change on how blockers are marked in Jira

[Christian Kandeler]

On 11/27/2015 11:46 AM, Eskil A. Blomfeldt wrote:

We've had a few informal discussions locally about the current process
of manually adding bugs to a meta-task in order for them to be
considered blockers for a particular release.

Wouldn't it be more practical if this was baked into the information you
register on the bug itself, so that it can easily be added to filters
and so that you don't have to search for the task to let the release
team know about it?

Our suggestion is: Instead of the meta-task, we use the "Fix version"
field. The combination of "Status: Closed" and "Fix version" is
currently used to indicate the first version containing a particular
fix. "Status: Open" and "Fix version", however, has a very loose
definition at best. Since we're doing time-based releases, it gives a
promise it might not be able to keep, so the preference has been to
leave the field unset until the report is closed.

So we could define it like this: If a bug report is open and has "Fix
version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The
release team will maintain this the same way they maintain the
meta-task, and will override it if they disagree that it should be a
blocker.


Sounds sensible, but what about all the existing bugs that have a "Fix 
version" assigned? Won't they all become blockers now? Or can a script 
wipe this field before the new semantics are announced?



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

Re: [Development] Avoid overloading of 'error'

[Christian Kandeler]

On 06/10/2015 06:42 PM, Thiago Macieira wrote:
 On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
 Hi,

 I think renaming the getter to lastError is nice! I however do like error as
 signal name and it looks good in qml as onError:...

 onError screams of Basic to me...
   ON ERROR GO SUB foo
 or worse
   ON ERROR RESUME

 I don't mind the getter still being named error because it's a noun and we
 name our properties (and thus the getters) after nouns.

 The problem is the signal: the coding style is that signals are named after
 verbs in the past, indicating that something happened. error has no verb in
 the past. Even errored would be better, though that's unusual.

 I think error + verb in the past is best, so here are my suggestions, in no
 particular order:

   errorHappened
   errorCaught
   errorEncountered
   errorOccurred   (people will get the double r wrong)
   https://en.wiktionary.org/wiki/occured
   errorFound
   errorDetected
   errorDiscovered
   errorNoticed
   errorSeen
   errorObserved

 alternatively, with the verb in the active:

   caughtError
   foundError
   detectedError
   discoveredError
   noticedError
   sawError
   observedError

 If I break out the thesaurus, then we also have

   errorBefell

I would +2 this one immediately, even if it's the last thing I do before 
losing my approver rights.


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

Re: [Development] Q_OBJECT and override

[Christian Kandeler]

On 06/04/2015 04:52 PM, Konstantin Ritt wrote:
 #define  Q_OBJECT  \

 public:  \

  Q_OBJECT_CHECK  \

  QT_WARNING_PUSH  \

  Q_OBJECT_NO_OVERRIDE_WARNING  \

  static  const  QMetaObject  staticMetaObject;  \

  virtual  const  QMetaObject  *metaObject()  const;  \

  virtual  void  *qt_metacast(const  char  *);  \

  virtual  int  qt_metacall(QMetaObject::Call,  int,  void  **);  \

  QT_WARNING_POP  \

Oh, this is already in 5.5... I overlooked it somehow. Well, that makes 
this thread kinda pointless. Sorry about the noise (if the construct 
above indeed works).


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

[Development] Q_OBJECT and override

[Christian Kandeler]

Hi,

as anyone who uses clang has probably already noticed, this compiler has 
recently added -Winconsistent-missing-override to the collection of 
flags enabled via -Wall. As a result, you now get literally thousands 
of warnings when building any non-trivial Qt project. This is because 
the expansion of the Q_OBJECT macro contains virtual overrides that are 
not marked with the override keyword, so all QObject-derived classes 
using Q_OBJECT and making use of the override keyword will trigger 
this warning. Adding the keyword in the Q_OBJECT definition does not 
help in itself, as now all derived classes *not* using override would 
trigger the warning.
So how to deal with this?
1) Add override (or rather Q_DECL_OVERRIDE) to the definition of 
Q_OBJECT *and* all QObject-derived classes in Qt.
Pros: Is the correct solution.
Cons: Tedious work, will introduce some noise into the git history.
2) Remove override from all QObject-derived classes in Qt.
Pros: Less work than 1)
Cons: Entirely wrong. Discourages developers from using override in 
their code, for a start.
3) Explicitly disable the warning in the clang mkspecs.
Pros: Easy to do.
Cons: Users might want to enable the warning, but they can't, as they 
will then drown in warnings from our headers.
4) Let users deal with the problem by making them turn the warning off.
Pros: Even easier to do.
Cons: See 3). Also seems very lazy.

Opinions?


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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Christian Kandeler]

On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote:
 On Sun, May 17, 2015 at 9:55 PM, Smith Martin
 martin.sm...@theqtcompany.com wrote:
 How do you get bitten by an out-reference?

 As usual, because at call site I didn't realize the argument was
 actually being modified. Compare

 doSomething(param1, param2, param3);
 doSomething(param1, param2, param3);

 which one is likely to be modifying arguments?

Both are equally likely to, unless you are a C programmer.


Christian

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

Re: [Development] RFC: RAII for property changes

[Christian Kandeler]

On 04/15/2015 05:12 PM, Matthew Woehlke wrote:
 [Valid points about the inconsistent state of the object elided.]

 On 2015-04-15 10:58, André Somers wrote:
 What if that slot [connected to the instance property changed
 signal] triggers something that ends up deleting the instance?

 Then the slot is broken. What if the sender needs to do something after
 it delivers the signal? What if other slots are connected? Deleting a
 signal sender from a slot connected to the signal is inherently
 dangerous. Don't do it.

While delete is probably the most extreme case, all other operations on 
the sender have the same conceptual problem. I'd even argue that the 
delete case is relatively benign, because it very likely fails loudly, 
rather than in some subtle way.


Christian

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

Re: [Development] [RFC] more gerrit codereview scores?

[Christian Kandeler]

On 03/06/2015 05:42 PM, Oswald Buddenhagen wrote:
 1) i'd like to propose the introduction of the code review score -3.

 rationale: it's quite common that a particular patchset is so broken
 that it must not be merged. this is typically done by giving a -2 score,
 in particular when it's needed to counterweight a pre-existing +2 score
 (yes, people tend to overlook -1 given after approval).
 however, -2 scores are sticky - even a new patchset stays -2. the
 reason for that is the double meaning of -2: it represents this is
 inherently broken as well. i'd like to decouple this, resulting in the
 following negative scores:

 -1: I would prefer this is not merged as is, advisory, non-sticky
 -2: This shall not be merged as is, blocking, non-sticky
 -3: This shall not be merged [at all], blocking, sticky

This makes sense under the assumption that there are patches of which 
you can be almost 100% sure that they are completely unfixable by 
whatever the author could come up with in the new patch set (including 
considerable changes to the concept).
Is that something that happens reasonably often?


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

Re: [Development] QtCore missing check for memory allocation

[Christian Kandeler]

On 02/25/2015 04:30 PM, Giuseppe D'Angelo wrote:
 Il 25/02/2015 13:35, Ulf Hermann ha scritto:
 I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
 QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
 succeeded (e.g. QVector::reallocateData).

 Until 9d44645eae144fcfefa0de2455d41f04d29c40d4 (September 2014) most
 of QVector's allocations weren't checked at all and surprisingly no
 one had complained about that before I did. The common theme is If
 you need so much space you better design your own data structure. I
 find that argument lacking because memory allocation can fail for a
 number of reasons, not only because you have requested a too large
 single chunk of memory. Furthermore people keep saying What can we do
 if we detect a failed memory allocation? Qt is in an invalid state
 then and we have to crash anyway. I somewhat agree to that, but we
 should really crash reliably without writing or reading random user
 memory before.

 We should thus do Q_CHECK_PTR on every memory allocation in Qt and we
 should fix Q_CHECK_PTR so that it works under all circumstances.

 That's a much bigger commitment than changing QVector, though. All of
 Qt's codebase assumes infinite memory, so that allocations never fail.
 In other words, only a handful of places currently check for such OOM
 conditions, and it's unclear what should happen in case a OOM is
 detected (apart from crashing).

Also, you are not even guaranteed to get a null pointer/bad_alloc due to 
things like Linux overcommitting.


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

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Christian Kandeler]

On 02/10/2015 05:33 PM, Olivier Goffart wrote:
 Note that some STL implementation (most notably the GNU one) use implicit
 sharing for std::string

I thought that was prohibited in C++11?


Christian

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

Re: [Development] Compiler warnings

[Christian Kandeler]

On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
 As we are developing for aerospace, avionics, defence and healthcare, we are 
 confronted on a daily basis with a lot of very stringent rules that we have 
 to comply with (irrespective if some people might find these rules outdated, 
 stupid, ridiculous or not). That's why we always compile with as much 
 compiler warnings as possible. Our code must be audited by an external office 
 anyways, so we better make sure we can avoid a bad report as soon as possible.
 Some examples of 'stupid' rules (which after second consideration aren't that 
 stupid after all):
 - a switch statement must always have a default statement (also all cases 
 must be handled)

Doesn't this actually make the code *worse* when using enums? Adding a 
default statement when you handle all possible values will inhibit 
genuine compiler warnings when you forget to add a case for a newly 
added enum value. In fact, this is almost guaranteed to happen in a 
non-trivial project, so this rule seems almost absurdly wrong to me.


Christian

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

Re: [Development] Compiler warnings

[Christian Kandeler]

On 10/17/2014 01:06 PM, Milian Wolff wrote:
 I think you are missing something:

 enum Foo {
 Bar = 1, Baz = 2
 };

 Foo foo = static_castFoo(3);

If you start to guard against this kind of stuff, where does it end?

void f(void *p);

f(reinterpret_castvoid *(5));

Is f supposed to catch that?


Christian

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

Re: [Development] Building Creator's qbsprojectmanager and qbsplugin with external qbs

[Christian Kandeler]

On 10/04/2014 08:36 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
 Hi! A fellow maintainer in Debian has packaged qbs as a separate source. So we
 though of building qtcreator's qbsprojectmanager and qbs plugin with it.

 This seems not supported right now out of the box

Hm, what do you mean by that? The project files are supposed to prefer 
an external qbs over the one coming from the submodule. Admittedly, this 
is not well-tested at the moment, as you have found out.

(but could easily be done
 with config.test stuff [0]), so I disabled building the embedded qbs source
 (to avoid wasting build time) and then I setted up QBS_INSTALL_DIR so the
 build system can find it.

The latter should be all that's required.

 Then I got to the point in where the qbsprojectmanager needs hostosinfo.h
 which is not provided by qbs by default nor as a private header/lib.

That's a bug. Creator must not include this private header. I will 
provide a fix.

 Adding
 the header is clearly not enough as the symbols it references are still not
 present with a normal qbs installation.

 So, is there any plan to make this possible? Is it desirable?

It's the intended use case for distributions, in fact.

 What needs to be done?

In theory, nothing. In practice... well, I guess we'll see.


Christian

 (yes, we might provide patches for this if we can get a clear view of
 what's needed).


 [0] Yes, if we get to be able to build the stuff using the external qbs I will
 propose a patch for this.

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

Re: [Development] clang-analyzer and qbs projects

[Christian Kandeler]

On 09/29/2014 09:29 AM, gorthaue...@yandex.ru wrote:
 Is there any way to analyze qbs projects with clang-analyzer?

A cursory glance at how clang-analyzer works suggests it should be 
enough to set cpp.compilerPath to the location of the c++-analyzer 
tool (for C++ projects) and make sure the right compiler is found via PATH.


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

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Christian Kandeler]

On 04/28/2014 10:51 PM, André Pönitz wrote:
 I am tempted to suggest to reload http://www.classnamer.com/ until it
 contains Q, M, and L.

Don't waste your time. I've checked the source code and found that the 
first word will never start with a 'Q'. Maybe we should fork it?


Christian

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

Re: [Development] Nominating Jake Petroules as approver

[Christian Kandeler]

On 04/15/2014 07:13 PM, Thiago Macieira wrote:
 I'd like to nominate Jake Petroules as approver.

+1


Christian

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

Re: [Development] Qt5 does not build with Python 3.3 anymore

[Christian Kandeler]

On 01/29/2013 12:34 PM, Дмитрий Волосных wrote:
 It happens somewhere while building WebKit, when build script starts
 to use tools from gnuwin32\bin.

The failure I saw on my machine was due to some deprecated use of a 
print format string. I took the easy route and directed the build 
process to use python 2.7...


Christian

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

Re: [Development] QtCreator Generic Linux Device plugin questions

[Christian Kandeler]

On 01/12/2013 05:11 PM, a.gra...@gmail.com wrote:
 I'm trying to understand how the Generic Linux Device plugin of
 QtCreator works and I've some questions to ask, to understand if it
 already does what I need or if I need to fork it and customize for my
 needs.

Note that this question should really go to the Creator mailing list; 
see http://lists.qt-project.org/mailman/listinfo/qt-creator. Staying on 
this one for now.

 1) I'm trying to use the Generic Linux Device feature of QtCreator 2.6
 to connect to another Linux machine and try to deploy and execute a Qt
 application on it.

 The machine where I'm trying to deploy is a normal Xubuntu 12.10 with
 SSH server installed.

From my working machine to that machine, I can SSH without any
 problem, but from the Generic Linux Device panel I cannot connect
 and I get this error during the configuration testing:

 Connecting to host...
 SSH connection failure: Timeout waiting for reply from server.
 Device test failed.

This means the authentication was not completed within the timeout you 
set in the device configuration. Usually, it's due to one of these reasons:
 a) The server is slow to answer and the default timeout of 10 
seconds is not enough.
 b) The server's identification string is non-compliant, leading us 
to never progress to the actual authentication.

In the case of a), simply increase the timeout.
I have only really seen b) with some ancient OpenSSH versions, so it 
seems unlikely that this happens on Ubuntu 12.10. Plus, Creator = 2.6 
tries to handle this in a better way, telling you explicitly about the 
problem.

 I tried to give a look to auth.log in the remote machine and this is what I 
 see:

 Dec 16 16:41:01 andrea-1215P sshd[2317]: pam_ecryptfs:
 pam_sm_authenticate: /home/andrea is already mounted
 Dec 16 16:41:01 andrea-1215P sshd[2317]: Accepted password for andrea
 from 192.168.0.6 port 54187 ssh2
 Dec 16 16:41:01 andrea-1215P sshd[2317]: pam_unix(sshd:session):
 session opened for user andrea by (uid=0)
 Dec 16 16:41:01 andrea-1215P sshd[2428]: Received disconnect from
 192.168.0.6: 11:
 Dec 16 16:41:01 andrea-1215P sshd[2317]: pam_unix(sshd:session):
 session closed for user andrea

Hm, the disconnect happens right after the authentication succeeded. Is 
this by any chance exactly 10 seconds after the initial contact to the 
server?

 Do you have any idea about how to make this work?
 How the remote machine should be configured to accept connections from
 this plugin?

There is no magic involved. An SSH server needs to be running, that's all.

 2) If I had to execute the previous task manually, without using a
 plugin, I would use scp to copy the compiled binary to the remote
 device: is this a task that the plugin is expected to do or I need to
 customize it someway? If I need to customize it: how?

There is a pre-configured upload step in the plugin, which uses SFTP. 
See the deployment part of your project for the details. This currently 
works only for qmake-based projects. The files to deploy are specified 
via the .pro file's INSTALLS variable.

 3) The second step I expect after building and deploying a binary is
 to remotely execute the application: normally I would ssh into the
 device/machine and I would run the app displaying it in the running
 graphic server. Is it something that the plugin already does? How I
 could do it manually?

See the run configuration of your project.

 4) where can I find the source code of these plugins? I can clone the
 source code of Qt5 where QtCreator is, but what is the folder where I
 can find just the plugins?

The sources are here: http://qt.gitorious.org/qt-creator.


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

Re: [Development] QtCreator Generic Linux Device plugin questions

[Christian Kandeler]

On 01/14/2013 01:51 PM, a.gra...@gmail.com wrote:
 There is a pre-configured upload step in the plugin, which uses SFTP.
 See the deployment part of your project for the details. This currently
 works only for qmake-based projects. The files to deploy are specified
 via the .pro file's INSTALLS variable.

 can I also specify the destination in my .pro?

Yes, via the target.path variable.

 I explain my problem. The default behaviour is to deploy
 MyTestProject in /opt/MyTestProject/ on the remote device.

No, there is no default path, at least not in the source code. If your 
project is deployed to /opt, then that's set in the project file. 
Presumably you used Creator's Qt Quick app wizard, which writes such a 
project file,

 I fixed the problem just giving chmod 777 to the /opt but this is
 just a workaround. I could deploy my app to the /home/user folder or
 just give user RW permissions for /opt
 Which method do you think it would be better?

Whatever fits your use case. Using the /home directory seems much less 
intrusive.


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

Re: [Development] Is QtConcurrent's code generator still in use?

[Christian Kandeler]

On 11/14/2012 12:17 PM, Sorvig Morten wrote:
 QtConcurrent is done. The implementation is not good enough to be used as a 
 base for further development.

Can you be a bit more specific? What are the general problems and why 
can't they be easily solved?


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

Re: [Development] Issues with qmake and subdirs template

[Christian Kandeler]

On 10/17/12 17:27, Wehmer, Matthias wrote:
 I'm currently trying to organize my project with qmake. The compiling itself 
 works pretty smooth so far, but somehow I have problems with make install.
 To be more concrete: I have organized everything with the subdirs template 
 and in one directory on a lower level I'm using a .pro file, also using the 
 subdirs template, which should move some files via INSTALLS. This does not 
 work when I call the qmake on the top level. Funnily it works fine though, 
 when calling qmake  nmake install on the level of the problematic .pro 
 file. I used google and got some results that tell something about problems 
 with the subdirs template and INSTALLS. But I didn't find a solution. Do you 
 know of this problem and what is going wrong? Have you any suggestions?

You should provide a link to (a paste of) the actual project (or, even 
better, the most reduced version of it that still exhibits the problem). 
Otherwise people can only guess what's going wrong.


Christian

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

Re: [Development] Qt Playground - Command Line Parser experiment

[Christian Kandeler]

On 03/09/2012 12:36 AM, ext Laszlo Papp wrote:
 I would like to experiment with a command line parser in Qt
 Playground. The topic and the use case were more or less discussed
 previously on the qt5-feedback mailing list around last October.

 It is not a separate module, but class(es). The name for this
 experiment, in playground, would be something like Command Line
 Parser. According to the regulation: if nobody objects to this
 addition from the beginning, I need to get the support of one existing
 module maintainer in order to be able to experiment with this feature
 in playground.

 Either way, please let me know your thoughts. Thank you in advance!

After having written three project-specific command line parsers in as 
many months, I am enthusiastically in favor of having a general one in 
Qt. Definitely a good idea.


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