Re: [Development] Changes to Freenode's IRC

[Tobias Hunger]

On Thu, May 20, 2021, 21:03 André Pönitz  wrote:

> Works as designed. Freenode never endorsed public logging.
>
> Chat is for ephemeral contents, like normal speech.
>

I always chat as it it was logged, even in IRC: It is easy to log, so
people are logging. There may not be "official" logs, but there definitely
are logs.

Quassel e.g. has logging built in, to name just one IRC tool popular I  the
Qt crowd.

> If we choose to just move to another IRC service, then it's likely that
> I'll just
> > continue to ignore it as irrelevant like I do now with Freenode.
>
> Looks like the both of us won't have much of a chance to chat casually
> online.
>

That is true: Choosing a chat tool also implicitly select a target audience.

What is the target audience the Qt community wants to engage with?

Best Regards,
Tobias

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

Re: [Development] The sorry state of the Qt6 cross compile experience

[Tobias Hunger]

Hi BogDan,

On Tue, Feb 23, 2021, 12:30 BogDan Vatra via Development <
development@qt-project.org> wrote:

> - first and foremost, we need to waste time to **fully** build and install
> it
> for host platform (desktop). Yeah, I know that this was "decided" before
> TQC
> switched, overnight, to cmake, but let's face it, it's a BS needed to
> cover
> the fact that cmake can't build more than one platform at once.
>

We had the requirement to enable exactly that to stop wasting time in the
CI. This would have need to be met by any buildsystem used for Qt6.



No need to discuss implementation details ...

- IMHO the qmake build files were removed prematurely ... they should be
> removed **after** cmake matched qmake.
>

Making the old build system match the new one was never a goal.

Less maintenance effort was a goal, as was improving common use cases and
not making less important use cases impossible.

Having said that, I truly believe that cmake is a big step backwards.
> Am I the only one who's bother by all these things?
>

Some people always end up unhappy when you change things -- and when you do
not change things. Sorry that you ended up on the unhappy side!

We have a huge elephant in the room which nobody want to see it...
>

If that is your biggest concern about Qt right now: Lucky you.

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

[Development] Stepping down as maintainer of the CMake plugin of Qt Creator

[Tobias Hunger]

Hello everyone!

I would like to step down as the CMake plugin maintainer in Qt Creator on 1st 
of August as I will start a new job then and do not expect to have the time 
necessary to be a good maintainer in the Qt project. Thank you all for the the 
opportunity to work with so many passionate people and the trust to maintain a 
plugin!

It would be great to see somebody step up to the task of making CMake easy and 
convenient to use in Qt Creator! I will be around and am willing to help 
getting people to settle into the code base -- as I still think this is a very 
important area for Qt Creator going forward.

The last couple of weeks I spend on streamlining the code (killing two of the 
three completely different ways for creator to interact with CMake) and to 
generally simplify the interaction between Qt Creator and CMake. I think this 
was a major step forward for CMake support in Creator  -- and it removed a lot 
of code and made things conceptually simpler, so now is a good time to hand 
over the plugin.

Best Regards,
Tobias

PS: Please consider to test the upcoming Creator release and report issues you 
find so that I still have a chance to fix them myself:-)

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Tobias Hunger]

On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote:
> We currently have an "In Progress" state.  In practice when I work on an
> issue, I initially do the work, then put that up for review; the review
> phase takes up fragments of my time for a while, unlike the main work
> phase, which is closer to full-time.  I have more control over (and a
> better ability to estimate) how long the actual work takes, while review
> (and subsequent integration) depends on factors outside my control, that
> are harder to estimate.

If the review process does not ever result in a significant amount of work (==
no patch is ever rejected or significantly changed do to a review process), then
we should reevaluate the review process. If this is indeed the case, then Gerrit
has degenerated into a place to discuss formatting -- something we could have
clang-format take care of automatically!

If our review process is more than a formality then it might result in a
significant amount of work -- the patch can be rejected or you might end up
redoing significant parts of the code. In that case I do not see how you can
consider your original task done before the review is complete.

In both cases, IMHO having a separate state in JIRA provides very limited
benefit.

The code review process is meant to improve code quality. If this benefits is
outweighted by reduced productivity due to the review overhead, then we should
re-examine the topic of code review, not work around the issue in JIRA.

We did introduce the code review process we use today in Nokia when we were a
much different organization. Maybe we need to adjust our processes to the
environment we work in nowadays?

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

Re: [Development] Nomination of Build System Maintainer(s)

[Tobias Hunger]

On Wed, 2020-01-15 at 14:27 +, Kai Köhne wrote:
> Hi,
> 
> I'd like to nominate Jörg Bornemann and Alexandru Croitor as joint official
> maintainers of the Build System in qtbase, which is officially unmaintained
> [1].
> 
> Jörg has been doing a lot of work and reviews in qmake and the existing Qt 5
> build system after Ossi was leaving The Qt Company. 
> 
> Alexandru is currently organizing the work around the CMake port (Qt 6 build
> system), and also does a large fraction of the work himself. 
>   
> I believe that, together, they are the right ones to maintain the build system
> area in both Qt 5 and Qt 6.

+1 for Alexandru

+1 for Jörg

They both know a lot about build systems and I trust both to do a great job.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Cristian Adam as approver

[Tobias Hunger]

+1

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

Re: [Development] Assistant WebKit/WebEngine support

[Tobias Hunger]

Hi!

On Fri, Jun 21, 2019, 22:29 Volker Hilsheimer 
wrote:

> And I agree Simon that all those things don’t exclude each other. In fact,
> with a service that provides indexed searching and other high-level APIs to
> retrieve documentation content would make it a lot easier to develop some
> innovative interactions with the documentation, without having to worry
> about the “backend” stuff.


There are lots of help viewers out there, can we please pick one of those
over writing our own? Or at least have our documentation server support
some widely used formats instead of having our own?

Developers often need more than Qt itself and it is extremely convenient to
have all the documentation in one viewer. Getting more than just the Qt
docs I to assistant has always been possible, but also a big hassle since
it uses a format basically no other documentation comes in.

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Tobias Hunger]

On Fri, 2019-05-31 at 01:37 +0300, Konstantin Tokarev wrote:
> > I understand, but aside from qmake, I don't know of any build system that
> > allows for building both host and target in the same build. That means
> > whatever we use in Qt 6, we'll a separate build for host tools when cross-
> > compiling.

Lars asked to have the tools and the library builds separate from each other in
Qt 6. This is to reduce the load on the build machines: Currently we build lots
of different tools for the same host architecture -- one for each cross-compile
we do.

So this host/target combined build is on the way out for Qt 6 (independent of
build system used:-).

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Tobias Hunger]

Hi Thiago,

On Thu, May 30, 2019 at 8:18 PM Thiago Macieira
 wrote:
> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> wrote:
> > 2) should QRegExp stay in bootstrap? I have no idea of what's happening
> > regarding to that in Qt 6.
>
> Bootstrap needs to go away in Qt 6.

While the bootstrap libraries play a much reduced role in the cmake
branch, the bootstrap code is still needed: moc, rcc, qfloat16-tables
and tracegen link against it right now. I would love to see somebody
rewrite these tools in plain C++. It should not be that hard to do
so:-)

Qmake for the time being also links against a special build of QtCore,
but that is a separate issue. It needs some extra APIs on top of what
a normal Qt provides. So even with cmake we are currently building
parts of Qtbase 3 times:-/

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

Re: [Development] CMake branch

[Tobias Hunger]

On Fri, Mar 22, 2019 at 12:53 PM Joerg Bornemann  wrote:
> I believe that this means a reduced feature set for the CMake port.

That's not what I wanted to say:-)

All buildsystems all have things where they are nice to use and other
areas where they are less nice.

I want a build system for Qt that uses the things that work well in
cmake... one that does not do things for the only reason that we did
it exactly like that with qmake. Things that make sense and where
there is no obvious nicer way to get a similar effect in cmake should
of course stay.

> What kind of things do we expect to go away that we take for granted
> with the current build?

I do not plan to test any platform that I have no compiler for, so I
expect things to break there. I hope those platforms that are relevant
for Qt 6 will eventually get fixed by people that know them well.

Things will change, but not all of them due to cmake:

* We will also try to move most of the 3rd party code out of the Qt
repositories -- as much as we can get away with. CMake is good at
finding stuff, but we do this mostly since Thiago has been pushing for
that even before we started with cmake.
* We will also lose the ability to build qt tools for a host machine
and then continue to build for a target machine. You will need a host
installation to cross-compile. But again that is not due to cmake, but
because Lars asked for this to avoid building host tools dozens of
times on the CI.
* Setting features, etc. will be done differently (via the cmake UIs).
* How to enable sanitizers, etc. will change to how you do that in cmake.
* I hope the builds will also become a bit more robust -- but not as
robust as you would have managed with qbs!
* Builds should be faster as well -- we remove 3rd party code, so
there is less to build in the first place;-)

There are lots more things.

> And even if that is the case, why can't the qmake part be kept separate
> and left alone?

Currently the cmake and qmake parts are completely separate in the
wip/cmake branch. But once cmake is functional I plan to remove the
.pro/.pri/.qrc files and update some things then.

E.g. we no longer need to bootstrap qmake, so we can remove some
defines from Qt Base that enable that.

In fact qmake does not even need to stay in qtbase when we can build
everything with cmake. So I would like to separate that out so that we
have the option of moving it into a separate repository. Whether or
not we will move qmake is not my decision to make, but I do want to
provide the option.

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

Re: [Development] CMake branch

[Tobias Hunger]

Am Freitag, den 22.03.2019, 10:45 + schrieb Jedrzej Nowacki:
>   I'm supporting Mikhail' proposal and I'm probably a bit guilty of the
> thread 
> too. As some of you know I'm not enthusiastic about any build system. I
> really 
> think that there are too complex for the purpose. What I care about is 
> shortening my development cycle and I can see how the cycle could be reduced 
> with ninja. I could try to help with porting to cmake, but I have nothing to 
> do in the wip branch. At the point in which cmake port works in at least on 
> one platfrom with developer build I do not see reason to not have it in 
> dev(*). 

So you are one of the people I referred to as wanting to work on Qt using cmake.
IMHO we can not support you at this time. 

>   I'm also a bit afraid that we are making the same delivery mistake as with 
> qbs.

We do the same mistake as we did with Qbs: We have way too few people working on
it to make it in time.

>  Everything is hidden behind an outdated feature branch. It requires quite 
> a mental effort to actually look there. By looking there you need to be 
> determined on working on the feature (there is nothing else there). 

Yes, that is the state we are in: You need to want to work on cmake to find the
branch interesting.

>   In addition seems that we go with a big bang approach, which worries me a 
> bit. Could you explain me why the temporary goal is to have two parallel
> build 
> systems?

Mostly to be able to compare results from qmake and cmake. It is pretty
convenient at this time.

>  Why we can not port stuff one by one and allow qmake to call cmake and 
> cmake to call qmake? For example why we can not already (*) require cmake to 
> build tests, moc, plugins and others?

*sigh* The task is hard enough already, please do not complicate it by requiring
qmake and cmake to seamlessly interact with each other at arbitrary points in
the build process.

>   There was also argument that we should not have cmake stuff in qt5 LTS. I
> do 
> not understand it, to be honest. That is really an implementation detail of 
> Qt.

A build system is *NOT* an implementation detail that is invisible to anybody
but developers of Qt.

Switching build systems does introduce a real risk to break a certain compilers,
setups and use-cases for all users and customers of Qt 5. We will also
definitely breaking each and every packaging script for Qt 5 out there in
existing. We break each and every instruction on how to build Qt 5 that was ever
published. We will also break all a lot of instructions on how to build against
Qt (probably even those that are concerned with cmake:-).

We should IMHO not expose our users and customers to such a risk in a minor
release. The only option to switch to an *exclusive* CMake based build system
that we have is IMHO Qt 6 (or Qt 7 if we miss that one).

But from what I understand this is not the proposal we are talking about. This
is about introducing cmake as a *secondary build system for Qt 5*, in
preparation for making it exclusive in Qt 6. I am fine with that.

As a secondary build systems our hands are much more tied with the cmake port
with regards to deviating from what qmake did than before.

I am also not at all enthusiastic about having to push all my CMake changes
through CI. That will eat a lot of extra time! I really do not understand how
you Qt developers can work like that...

>  We can have some transition scripts so configure && make && make install 
> somehow workflow works, but that is all.

Transition scripts work great, except when they don't:-/

qmake and cmake do moc differently, they handle .ui files differently. They
handle shared code much differently. There are lots of subtle differences all
over the place. Some will bite users, even when you try to hide all of that
behind transition scripts.

> (*) With assumption that we agree that cmake is the chosen one. I do not
> think 
> that the port needs to be ready before accepting it. In my opinion it is 
> enough to commit to it based on the state of the wip/cmake branch.

Please try to fix a bug in Qt with the wip/cmake branch and tell me how that
worked out for you. I doubt that you will enjoy that experience at this time.

>  So are we 
> sure that cmake is the way to go?

I think it is the only option we have right now.

>  If yes then let's go to dev.

... once we updated the wip/cmake branch to qt5/dev. Currently it is way behind.
Any help in getting that done is greatly appreciated.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Tobias Hunger]

Am Donnerstag, den 21.03.2019, 15:26 + schrieb Mikhail Svetkin:
> > I do not understand this part.
> 
>  We can ask people to update CMakeFiles after updating pro files.

Creator has two build systems and that is a constant PITA.

If we decide to do this, then we need to have one CMake build as part of the
blocking CI. Otherwise we will not notice cmake breakage before it hits the
tree.

> > First it requires that we can not do *anything* that will break qmake while
> porting to CMake.
> 
> Why do we need to break qmake?

We do not want to port all the qmake-quirks over to cmake. We get enough quirks
for free straight from cmake:-)

> > So no moving of files, no removal of files, no renaming, no
> fixes to the source code, nothing. Considering that we generate most CMake
> files
> straight from the .pro-files, that is probably not too much of a problem, but
> it
> does take options of the table.
> 
> If you want to move files you can update pro files and qmake build. The same
> for another operations.

The point is that you need to keep cmake and qmake in sync, whether or not that
makes sense. E.g. the bootstrapping is not necessary in the same way with cmake
-- so restructuring src/tools would make sense. That is not applicable to qmake,
where the bootstrapping of qmake etc. is of course needed. 

We are not as free to change things for cmake in qt5/dev as we are with cmake in
wip/qt6 -- where we can just remove all the .pro-files once cmake is there. We
will not be able to do so in qt5/dev.

I am not ruling out either option, but I do want to have this noted before we
jump.

> > We need volunteers for this! I do not see the team currently trying to port
> Qtbase to CMake having the necessary resources.
> 
> I think people do not want to just play with CMake. They want to build Qt (in
> our case QtBase) with CMake and if they encounter issues some people more
> likely to fix the issues.

I expect more people will want to work on Qt than CMake, but I have no numbers
to back this up:-)

I *do* expect lots of developer will need to chip in to get the bulk of Qt
ported to CMake.

> Let's send a patch and see what happens.

Sure.

Any help getting wip/cmake updated to qt5/dev is appreciated!

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Tobias Hunger]

Hi all,

On Thu, 2019-03-21 at 12:51 +, Volker Hilsheimer wrote:
> The advantages are:
>  - It allows our contributors to play with CMake in dev branch
>  - Speed-up the build of QtBase

How so?

>  - Easy to find a lot of bugs in CMake port
>  - CI could have a nightly build with CMake and generate a report

I am sure CI can be configured to do the same for any branch.

>  - We can synchronize CMakeFiles and *.pro files

I do not understand this part.

> The disadvantages are:
>  - Any changes should be passed by CI

CI is a huge disadvantage! The last 3 patches I added to Qt took me 45 CI runs
to get in -- and I changed neither of these patches!


I see two more disadvantages:

First it requires that we can not do *anything* that will break qmake while
porting to CMake. So no moving of files, no removal of files, no renaming, no
fixes to the source code, nothing. Considering that we generate most CMake files
straight from the .pro-files, that is probably not too much of a problem, but it
does take options of the table.

Second will need to have CMake in a state where it will build qtbase at anytime
(or at least nearly so). So will need CMake to stay up-to-date with the qmake
build system at any time to keep things building. We have two options to achieve
this:

1) We can ask everybody to update CMake files whenever changing something in a
.pro/.pri file.

I do not think we should ask people to handle this extra annoyance for years to
come -- till the last Qt 5 LTS will go out of scope.

2) We have a dedicated person that fixes CMake ASAP.

We need volunteers for this! I do not see the team currently trying to port
Qtbase to CMake having the necessary resources.

If we fail with updates too often, then we will poison the well: People are
enthusiastic about the cmake port (those that are not never get here), the build
fails, they are less enthusiastic. Repeat every couple of weeks until all
enthusiasm is gone. At that point it is hard to get people to try again. I had
that happen to me with qbs in Qt Creator.

> I’m fully supporting this proposal.

My idea was to ask for merging wip/cmake after 
https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that point
the branch would be in a state where people can work on Qt (for certain
platforms) using cmake and do drive-by-contributions to cmake. Right now it is
more like working on CMake for Qt and doing drive-by-contributions to Qt:-)

> By doing the cmake work in a separate branch, we are keeping this hidden from
> everyone else. That was the right thing to do while we didn’t know if we want
> to go with it and what the structural implications of this change will be, but
> now we know, and it’s time to move this work into the mainline.

We have no decision from the Qt project yet. Submitting a patch for review and
getting that accepted would be such a decision:-) For this reason alone I would
very much welcome this proposal -- *if* we get volunteers to help with keeping
cmake up-to-date with qmake.


The wip/cmake branch is currently behind qt5/dev and we need to update it. So if
the Qt project decides to litter qtbase with CMakeLists.txt files ASAP, then we
will still need a while to send the actual patch for review.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Stepping down as maintainer of project management in Qt Creator

[Tobias Hunger]

Hello everybody,

not having lived up to the role of maintainer of the project management 
code in Qt Creator for a while now, I would like to formally step down. 
It has been an honor to work in this role in such a central area of the 
Creator codebase.

I want to propose Christian Kandeler to take over. He is a capable 
developer with a deep understanding of the code involved and I am sure 
he will do a terrific job going forward.

Best Regards,

Tobias


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

Re: [Development] wip/cmake status information

[Tobias Hunger]

On Mon, Oct 29, 2018 at 6:21 PM Sérgio Martins  wrote:
> I'm wondering if you have any performance numbers regarding
> incremental builds on Windows, and specially "nmake install", which
> currently takes *several* minutes for qtbase alone. Through ETW I
> noticed it's due to hundreds of qmake processes being created, so I
> guess the problem is gone now :)

Not yet. So far too much is missing to do a meaningful comparisons.

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

Re: [Development] About 3D desktop.

[Tobias Hunger]

On Tue, Aug 21, 2018 at 5:36 AM Stef Bon  wrote:
> Yes the 3D window manager looks a lot at the idea I want to work on.

Projecting "normal" 2D applications into 3D space is pretty useless
and full 3D applications do not really make sense for that many
use-cases.

I have used both 3dwm and fresco in a VR environment at the University
of Goteborg once. It was fun to be able to walk around your terminal
windows, but they were also pretty hard to use:-)

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

Re: [Development] About 3D desktop.

[Tobias Hunger]

Hi Stef,

in my misspent youth I played with Berlin (later Fresco), which went
into that direction. The website is long gone, but the internet
archive has a copy:
https://web.archive.org/web/20080223200807/http://issues.fresco.org:80/

The code is still also still around:
https://github.com/stefanseefeld/fresco


3DWM is something similar from back then:
https://www.researchgate.net/publication/239744067_3Dwm_A_Platform_for_Research_and_Development_of_Three-Dimensional_User_Interfaces

Looking Glass from Sun was already mentioned.

That's all I can think of.

Best Regards,
Tobias
On Mon, Aug 6, 2018 at 3:36 PM Stef Bon  wrote:
>
> Hi,
>
> There are various desktop effects which offer 3D effects (kube for example).
>
> I  want to know I anyone knows about any plan to create a 3D desktop,
> eg a desktop with not only the coordinates height and width, but also
> depth.
>
> I want to work on this, maybe start it. It would be awesome.
>
> Stef
> ___
> 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] Qt 6 buildsystem support requirements

[Tobias Hunger]

Hi Thiago,

On Sun, Jul 22, 2018, 17:35 Thiago Macieira 
wrote:

> >  A) works with IDE(s) -- preferably more than one
>
> Hello Tobias
>
> The fact that we have an IDE of ours means this one should be reasonably
> easy
> to address, as we can make that IDE work with the tool. So long as the
> tool is
> actually toolable, of course.


This is a matter of resources and what we want to spend those on.

Creator needs first class support for qmake for years to come. It also
needs first class support for CMake as that is what people out there
actually use. These two are set for the foreseeable future.

When we have a decision on what Qt will use going forward, then that will
be added to the mix.

"More than one" would be quite a challenge.


We can not expect people to drop their preferred set of tools to work on
Qt. That is a sure-fire way to reduce contributions from outside of our
core community.

>  B) Should be easy to hook in static and dynamic code analyzer tools
>
> Can you elaborate?
>

Most build tools offer to create a build_commands.json file so that some of
the clang tools can be used easily. I expect that from any build tool
nowadays.

Meson offers a "build with address sanitisation" option (and similar ones
for UBSAN, etc.) that can just turn on for your project. I would love that,
but at the very least compiler-based tools like ASAN and UBSAN should be
easy to enable with good documentation on how to do so.

A build tool with a track record of empowering developers by making new
tools easy to use on existing projects would be welcome.

Best regards,
Tobias

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

Re: [Development] Qt 6 buildsystem support requirements

[Tobias Hunger]

On Sun, Jul 22, 2018, 12:58 Иван Комиссаров  wrote:

> But only qmake works fine with new clang model, other build systems pass
> incorrect parameters to clang so it can’t compile my files (code model
> complains about missing std:: classes/functions, however the code compiles
> so project file is correct)
>

Please file but reports for those cases then. That *should* work and it
does work with all my test projects.

That’s true, but despite huge CMake community, Qt Creator’s CMake
> integration still is not in feature-parity with qmake.
>

CMake had never been a first class citizen in creator: Noboby inside the Qt
company used cmake in earnest, so nobody cared for CMake support -- once we
had rudimentary functionality in place.

When I spend some month improving CMake support in creator the feedback was
fantastic and there was and still is *lots* of it! There are *LOTS* of
people using qt creator and CMake out there!

But you are right: Some features are not possible with cmake. This includes
most operations that involve modifying CMakeLists.txt files directly,
including e.g. adding files to a target. One can hack something that will
probably work most of the time, but that is as good as it will get.

That is the same situation we also have with qbs by the way: Add some JS
into the wrong place and toolability is gone... Do stuff sensibly and all
is well.

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

Re: [Development] Qt 6 buildsystem support requirements

[Tobias Hunger]

On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> +1, I was flabbergasted when the big objection against CMake in Qt 6
> boiled down to "it does not supports all the architectures that Qt
> supports",
>

IIRC the bid showstopper was that CMake does not support building host
tools and the target libraries in one go.

That requirement was dropped since then in our side.

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

Re: [Development] Qt 6 buildsystem support requirements

[Tobias Hunger]

On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development <
development@qt-project.org> wrote:

> You really hate QBS don't you ? :)


Do you have so few arguments for qbs that you need to appeal to emotions? :)

Anyway IMHO is more important to have a clean, nice and easy to use syntax
> and
> to be tooling friendly than 1.b.
>

Sure you can write toolable build files with qbs, but there is nothing
stopping you writing an unparsable JS mess either.

For QML we needed to define a toolable subset of the language with the UI
files to have any chance at tooling it. For the qbs dialect of QML that has
not been done yet. So I do not consider qbs to be toolable at this point.

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

Re: [Development] Qt 6 buildsystem support requirements

[Tobias Hunger]

Hi Thiago,

On Sat, Jul 21, 2018, 04:36 Thiago Macieira 
wrote:

> [...] I'd like to add the following
> extra requirements to the buildsystem we choose to use. This is in
> addition to
> the functionality requirements.
>
> [...]
>

1) Ease of obtention


2) Track record
>
> 3) Community support
>

All these are very reasonable to ask for. I personally would like to add
the following point for consideration:

4) Toolable

 A) works with IDE(s) -- preferably more than one

 B) Should be easy to hook in static and dynamic code analyzer tools

Best Regards,
Tobias
___
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

[Tobias Hunger]

> [...] I propose Jaroslaw  Kobus as the new maintainer.

+1 from me for that.

Best Regards,
Tobisa

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

[Development] Orgad is now maintainer of Version Control plugins in Qt Creator

[Tobias Hunger]

Hello,

I am pleased to announce that Orgad Shaneh is now maintainer of the plugins 
related to version control systems in Qt Creator. He has done most work in this 
area for a long time nowe and I am sure he will continue to do a great job in 
his new role as well.

The maintainers page has been updated accordingly and the default assignee in 
JIRA has been changed.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

[Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator

[Tobias Hunger]

Hello,

I want to propose Orgad Shaneh as maintainer of the version control related 
modules in Qt Creator.

So far I have been handling that responsibility, but since I took over the 
project-related Qt Creator plugins, I had way too little time on my hands to 
take a lead in the version management related code.

Orgad has been working in those modules, he did a lion's share of the reviews 
involved and he added functionality during that time and he is willing to take 
on the responsibility involved. So I would like formally propose Orgad as 
maintainer of the version management code. I am sure he will take good care of 
the code, especially of the vcsbase and git plugins.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Tino,

On Fri, Feb 23, 2018 at 4:58 PM, Tino Pyssysalo  wrote:
> I’ll clarify little bit, as my earlier comment about “any backend” has been
> confusing. I requested a repo for a QtCreator analytics plugin, but we
> realized why not to use a similar solution in other tools as well. I want to
> concentrate on a Qt Creator plugin first to fully understand the problem
> domain. Once that is done we can discuss how to move forward with this
> project”. Our intention is usage data collection, but nothing else at this
> point. Obviously, we plan to use the collected data to improve Qt. As a
> concrete example, we have provided a lot of nice features in Qt Quick
> Designer in the recent Qt Creator releases, but we have no idea, if the use
> of Qt Quick Designer has changed in any way. This kind of data would be very
> valuable to us.

So this is a simple creator plugin to collect data about Qt Creator
users. That makes the scope clear to me, so I can step retract my -1
for undefined scope.

A repository in the qt-creator namespace makes sense to me for that
scope, but considering the experimental nature of this work, a
playground project might work out better. I am not deep enough in the
usual practices to have a firm opinion on that topic.

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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Pasi,

On Fri, Feb 23, 2018 at 10:33 AM, Pasi Keränen  wrote:

> I object to using “Spyware” term in this context. Spyware is SW that does
> things behind your back.

I noticed that my mail could be read in the way you read it pretty
much right after sending it. I need to apologize for expressing myself
so poorly!

What I meant to say that it is possible to write a spyware plugin
(following pretty much exactly what you lay out below) for creator or
any one Qt application that will collect basically everything about a
user and to feed that into a database on the internet somewhere in a
couple of weeks. On the other hand the task of writing a framework
that does anonymized data collection that follows all the relevant
data protection laws and standards and that pushes it to a server that
is easy to manage and set up is an entirely different scope. I wanted
to find out where our discussion is between these two poles.

I did not intend to imply that what we are discussing here is spyware.

> Siphons contact information, user account info etc.
> without telling you. We’re NOT talking about such use cases here! I don’t
> think anyone in The Qt Company wants to do such things. From what I hear the
> intention is to track certain things in an open, transparent manner,
> respecting the communitys clear wish to keep things in the open and for the
> benefit of our end users.

I am sorry for giving the impression that I thought anybody here is
considering spyware. That was not my intention and I want to apologize
to anybody that got that impression.



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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Pasi,

On Feb 23, 2018 08:05, "Pasi Keränen"  wrote:

Hi there,

+1 for having a generic telemetry plugin in Qt.


I planned to stay out of this, but

-1 since I am totally confused about the scope of this project at this
point.

So are we talking about a generic telemetry framework for Qt applications
or about watching Qt Creator users specifically?

Tino started by making the claim that this is a generic library and then
kept listing Qt Creator specific integrations. You focus entirely onto the
generic part, leaving out creator completely.

What exactly are we talking about here?

A Qt creator spyware plug-in (which does more than what we discuss here I
hope:-) would be a matter of a couple of weeks to do, putting a generic
framework into place with all the bits and pieces for that to be actually
useful in a wide list of possible contexts is a very different beast.

This is great initiative and very much the way today's app and application
industry works. UX studies performed by UX experts have been minimized and
targeted for specific (usually new/experimental) features or upcoming new
software (like we did with Qt 3D Studio back in last spring). And the mass
information on "how do our users use the SW? do they find the stuff we've
put in there? how often they hit a wall in doing sequence X? how many
crashes do they experience when doing Y?" is collected via automated
telemetry. It is great as it brings data from the actual user in their
actual work and you can then use that to concentrate on functionality that
really matters to your users. Making stuff they repeat hundred times a week
easier and faster, making them more productive.


I see value in this approach when you can do lots of small releases fast.
So you can do evaluate the effect of small changes by doing one change to
evaluate per release and measure how that effects usage.

We can not do more than two releases per year in Qt. Is this approach even
applicable to us?

I want to also point out that answering any of the questions you used as an
example require *way* more information than I am even remotely comfortable
to collect.

I see definite need for this in Qt 3D Studio so please don’t make this just
with Qt Creator in mind. Also, in my humble opinion, in order to be
relevant in today's UI development, Qt should also offer this kind of a
plug-in to our customers. A ready-to-go plug-in that automatically ensures
the data is collected in a way that fulfills data privacy acts and respects
the privacy of the user would be great. Especially for startups and smaller
companies, but also for bigger companies wanting to switch to the modern
way of doing UI development. It is not as easy to do as one might think at
glance.


I agree that having a general framework has value to some customers.

Such a framework would need to be integrated into big solutions like Google
analytics or something similar so the users can actually evaluate the
collected data and cross-reference that to other data they collect. Just
dumping data into some server somewhere does not help anybody.

Will the server-side code be part of this project by the way?

What about evaluation of the collected data? Is that in scope for this
project, too?

I would ask anyone who has not done work with usability and user experience
people in the past to give this way of working a chance. I've worked 7
years in application development while we grew usability knowledge in the
team over that time. The first time I got to observe a real world user
working with our software in actual real world situation was eye opening.
We had gotten so many important things wrong in our idealistic thinking and
forgotten to handle certain cases that occur on the field. Also you become
blind to your own creations faults as you just know how the software works.
It's just a fact of life.


Sure. We do way too little validation of what we do against the real world
usage.

Let us do some usability studies, let us talk to users, let us do surveys,
let's evaluate all the data users provide to us on the mailing list, the
bug tracker, the forums, stack overflow and in lots of other places. We do
have a very active and supportive community of users and customers, let us
use the feedback they provide already!

Collecting some semi-random data from a self-selected group of users and
dumping that onto a server somewhere is next to useless compared to all the
other options we have already. Even in an ideal situation (which we do not
have within Qt!), metrics are not comparable to a real user study where you
actually watch users doing their thing.

This is even more true when not leaving out any information that can be
used to identify individual users from the collected data, which we
obviously will do.

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

Re: [Development] Future of QBS

[Tobias Hunger]

On Tue, Oct 17, 2017 at 9:34 AM, Joerg Bornemann  wrote:
> On 10/17/2017 08:12 AM, André Somers wrote:
>
>> Well, in the case of QBS, would it not be reasonable to terminate the
>> evaluation of any property binding if it takes more than a 
>> amount of time? The language may be Turing-complete, but that does not
>> mean the code in control of executing it has to let it run indefinitely.
>
>
> 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Tobias Hunger]

Hi Jake,

take a breath, I was not even trying to attack qbs. These debates get way too 
emotional for my taste!

All I did was to ask to see qbs *sold* better and with more facts backing up 
our claims about it.

> > to use your version control picture: Are we trying to sell
> > subversion by showing how great that is compared to
> > CVS and RCS, while git is just getting introduced into
> > the market?

> Your analogy is stacked to support your (biased) argument.

Is my lack of enthusiasm for qbs making me biased towards cmake in your book? 
You got a strange friend-foe recognition algorithm at work there:-)

> In my (admittedly also biased) version, autotools, qmake,
> CMake, etc., are RCS, CVS, and Subversion. Qbs is git.

Linus did not compare git to CVS and RCS either, when he went to 'sell' git. He 
compared to monotone, and others VCSes that were state-of-the-art at the time 
instead.

So why don't we follow that example?

> Rhetoric like this is good for presentations and advertisements, but not very 
> good in logic-based debates.

I have not noticed you shying away from a bit of rhetorics yet:-)

> > I am still missing a comparison of qbs and *current* build
> > system options. All I see is qbs vs. qmake and qbs vs.
> > cmake 2.x. Neither qmake nor cmake is what qbs will
> > be competing with by the time it is ready to be used in earnest.

> Please give concrete examples of how CMake 3.x is so much
> more competitive now vs 2.x before continuing with this sort
> of argument.

It's a statement, not an argument.

Qbs is always compared to cmake 2.x or qmake (or at least I do not remember 
seeing it compared to something more recent). I went on to say that qbs will 
have to compete with newer tools than qmake and cmake by the time it is ready 
to be used. So I think it makes sense to show how qbs compares to newer tools.

Your presentation is just the latest example doing a qbs/cmake 2.x comparison. 
You left out development in cmake since 2014. You even went ahead and 
highlighted problems with recursive makefiles (which were never used in that 
form in cmake) and (as far as I recall) did not mention ninja. I doubt you will 
win over cmake users that way: Why would they perceive your statements are 
relevant to how they use cmake?

> I'm also not opposed to comparing against a wider range
> of build tools,

I had asked for a different set, not a wider range. Sorry if I did not make 
that clear.

> but keep in mind it's more useful to compare against what's
> actually relevant to our users in the market *now* (as in what
> people are already using), rather than options that do exist but
>  no one has actually considered or used yet in the context of Qt.

You repeatedly made the claim that qbs is targeting far further than Qt. Every 
tool I mentioned *is* used by developers right now.

> > So far we excluded most possible build systems on the grounds
> > that they do not support the mixed host/target builds we do.
> > That requirement is going away. So we have more options now.

I am surprised you left this part uncontested:-)

> > Just to name two: Bazel promises great scalability and reliability,
> > meson claims to be simple and fast. Even CMake made a lot of
> > progress since version 2.x.

> Qbs also promises scalability and reliability and also claims to be
> simple and fast.

When I read about bazel, I do find facts that (in my mind) support the 
statements about scalability (builds the entire google codebase) and 
reliability (e.g. only pre-declared inputs/outputs are available to all 
processes run by bazel). The same is true for Meson (very few commands, no 
functions or macros, so simple, and uses ninja, so fast compared to the 
make-baseline).

I would like to be able to do the same for qbs. E.g. as far as I can tell the 
only project currently building with qbs is creator, which is a comparatively 
small project. You just claimed that qbs is scalable. How do you substantiate 
that?

Without facts we are bound to have an emotional debate, so please provide 
more:-)

> Apparently, stating the tagline of a product somehow means
> that product is the best choice...?

I never made that claim.

> Meson is the same age as Qbs, so you can't reasonably put
> it into the conversation, because it did not exist at the time we
> invented Qbs.

I fail to see the logic here. Qbs was also not around when cmake was started 
either, yet you did compare the two in your presentation.

> Do you expect us to simply give up because competition
> *exists*?

No, I expressed hope that we watch the competition and that we are aware of the 
strength and weaknesses of our product compared to said competition.

> They have most certainly not magically leapfrogged over us in
> the same amount of time.

At QtCS you had not yet looked into meson, so how do you know?

> Same with Bazel - released in 2015. Again, some new software
> comes around and we just give up?

How did you get from "please compare qbs to something 

Re: [Development] Future of QBS

[Tobias Hunger]

Hi Jake,

to use your version control picture: Are we trying to sell subversion by 
showing how great that is compared to CVS and RCS, while git is just getting 
introduced into the market?

I am still missing a comparison of qbs and *current* build system options. All 
I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake is what 
qbs will be competing with by the time it is ready to be used in earnest.

So far we excluded most possible build systems on the grounds that they do not 
support the mixed host/target builds we do. That requirement is going away. So 
we have more options now. Just to name two: Bazel promises great scalability 
and reliability, meson claims to be simple and fast. Even CMake made a lot of 
progress since version 2.x.

I would also appreciate getting some numbers to back up the claims made about 
qbs.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Vikas Pachdha for Approver status

[Tobias Hunger]

+1 from my side. I have been reviewing Vikas patches since he started.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



From: Development <development-bounces+tobias.hunger=qt...@qt-project.org> on 
behalf of Eike Ziller <eike.zil...@qt.io>
Sent: Monday, May 15, 2017 10:43:57 AM
To: <development@qt-project.org>
Cc: qt-creator
Subject: [Development] Nominating Vikas Pachdha for Approver status

Hereby I nominate Vikas Pachdha for Approver status. He has been defacto 
maintaining iOS support in Qt Creator since a year.

https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z

Br,
--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
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] Use of std::function in Qt API

[Tobias Hunger]

On Thu, 2017-03-16 at 13:23 -0400, Matthew Woehlke wrote:
> On 2017-03-14 13:33, André Pönitz wrote:
> > In general, I am not overly sold on ABI compatibility promises. I personally
> > could live without and find SC of more practical value. The most important
> > "feature" of ABI compatibility guarantee for me is that it limits people
> > from
> > doing overly excessive source-incompatible changes.
> 
> Distros are likely to care; a Qt BC break requires a mass rebuild of
> everything that uses Qt (which translates into lots of users needing to
> update lots of packages when Qt changes). Distros may refuse to update
> Qt within a distro release as a result, which means users are stuck with
> older Qt for longer.

I think this is not a real issue:

A distribution will not update the standard c++ library within a distro release.
 Neither will a distribution upgrade Qt minor versions within a distro release.

I do not expect patch version upgrades of Qt to introduce BC issues with or
without it relying on std::functionality.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Tobias Hunger]

Hi Marc,

On Fri, Dec 2, 2016 at 8:22 AM, Marc Mutz  wrote:
> As you can see, I was not using it on QObject, as, indeed, the ownership there
> is messed up.

It just does not work with the concepts laid out in the GSL, but that
does not make it messed up.

> But we have tons of take*() and take()-like API, where even in auto-tests,
> which presumably were written by people that know the API well, the return
> value was ignored/leaked, making this kind of API a strong case for use of
> owner<>.

Sprinkling owner<> over our code-base will not magically improve any of this.

> If the Qt low-level smart pointer do not support gsl::owner, then we impair
> users that wish to use the GSL in their own code from using it, because Qt
> code will throw false positives.

Everybody is free to use the STL smart pointers and be done with it.
GSL users will be comfortable with those classes.

Considering that you will get a warning from each and every widget in
a dialog you are probably not going to use enforce GSL owner semantics
in a Qt application anyway.

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Tobias Hunger]

Hi Marc,

Am 28.11.2016 15:33 schrieb "Marc Mutz" :
> To see how simple gsl::owner markup is to incorporate into Qt, I sat
down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with
gsl::owner.
>
> https://codereview.qt-project.org/178107

Owner does not work with Qt's object tree, so this seems like a pointless
exercise to me. Having some owners but not being able to use them
consistently is not a big win and already possible with plain C++ smart
pointers.

I asked Bjarne Stroustrup at Meeting C++ about Owner and object trees and
he said that is a memory model that is not supported and that we are on our
own there.

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

Re: [Development] Neat feature in gerrit: drafts

[Tobias Hunger]

Hi Edward,

Am 10.11.2016 17:18 schrieb "Edward Welbourne" :
>
> A review puzzled several of us today by (apparently) starting at patch
> set 6.  Jesus had discovered a gerrit feature we hadn't heard of:
> drafts.  If you push to refs/drafts/blah instead of refs/for/blah, you
> get a review on gerrit with much of the effect we normally achieve using
> WIP but without the sanity-bot's complaint about WIP and without the
> buttons that would allow staging.  Folk can comment on it, they just
> can't actually accept it yet.  Later you can push to refs/for/blah as
> usual and the review turns into a real review.  Further pushes to
> refs/drafts/blah will be added as later patch sets without spamming
> those watching the review, while being visible to anyone actually
> looking at it; and you can delete drafts from the history once all they
> are is clutter.  There's probably more fun I've yet to learn.
>
> This seemed worth publicizing; so now you all know :-)

Qt Creator supports drafts, too.

You can also push a draft over an existing patch set in review. That draft
can then be discussed and "published" to become a "real" patch in the patch
set.

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

Re: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration

[Tobias Hunger]

On Fr, 2016-06-17 at 11:52 +, Eike Ziller wrote:
> I propose David Schulz for Maintainer status for Qt Creator text editors and
> CDB integration.
> 
> He has a long history in Qt Creator and factually maintained these areas for a
> long time now.
> 
> https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%
> 2540theqtcompany.com%253E%22,n,z

+1 from my side.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] Nominating Marco Benelli for Approver status

[Tobias Hunger]

Hello all,

please welcome Marco Benelli as the newest approver to the Qt project.

Best Regards,
Tobias

On Mi, 2016-04-13 at 08:06 +, Hunger Tobias wrote:
> Hello Qt Developers,
> 
> I hereby nominate Marco Benelli for Approver status. He has put in a lot of
> effort to maintain the QML code inside Qt Creator over the recent month and in
> fact is the default assignee for all bugs in that area of Qt Creator.
> 
> He did good work in his area and Qt Creator in general, so I think he has more
> than deserved Approver status by now.
> 
> Best Regards,
> Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Requesting New Repository - QtZeroConf

[Tobias Hunger]

Hi Thiago,

On Thu, Sep 10, 2015 at 5:47 PM, Thiago Macieira
 wrote:
> I don't know any project implementing LLMNR outside of Windows. It's clearly
> dead in terms of further adoption and mDNS has won. So I don't think we need
> to provide it for cross-platform interoperability. I'd say we provide mDNS for
> that. In addition, we may provide some other IoT protocols currently in
> development.

Systemd supports LLMNR and uses it to address containers it starts.

References:
http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
https://lwn.net/Articles/647634/

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

Re: [Development] Please update the maintainer table at http://wiki.qt.io/index.php?title=Maintainers

[Tobias Hunger]

On Mar 2, 2015 7:10 PM, Thiago Macieira thiago.macie...@intel.com wrote:
 BTW, any chance of getting mod_rewrite so the index.php?title= part gets
 hidden?

I did ask Tero the exact same question: Yes, it is planned, but getting the
contents across is the priority at this time.

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

Re: [Development] [Qt-creator] Nominating André Hartmann as approver

[Tobias Hunger]

+1 from my side.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

Email: tobias.hun...@theqtcompany.com | Phone: +49 30 63 92 3255 
www.qt.io | Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt

On Fr, Jan 30, 2015 at 9:53 , Orgad Shaneh org...@gmail.com wrote:
 Hi,
 
 I'd like to nominate André as approver.
 
 André has been actively reviewing changes for over 3 years, mostly 
 for Qt Creator, and contributed many high quality patches.
 
 His contributions
 His reviews
 
 - Orgad

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

Re: [Development] Qt 5.4 Mingw-4.9.1 offline package

[Tobias Hunger]

Hi Cristian,

In addition to Kais arguments I want to add that we want to encourage 
people to experiment with Qt, but we also want Creator to continue to 
function if those experiments fail.

So even if we used the same compiler for the shipped Qt version and Qt 
Creator we would need to ship an extra copy of Qt exclusively for 
Creator (and not listed in Creator's configuration).

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company

Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

Email: tobias.hun...@theqtcompany.com | Phone: +49 30 63 92 3255 
www.qt.io | Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt


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

Re: [Development] About the Guidance

[Tobias Hunger]

Hi Berkay,

On Jan 4, 2015 8:52 PM, Berkay Elbir berkayel...@gmail.com wrote:
 I have recently attended to developers for QT. I want to contribute it.
Also, I have downloaded qt 5 and builded it for OSX. But how can I find
issues to solve where should I begin? Of course, I know Jıra addresses,
read the Contributing guidance, I mean that  which one should I start from?
In addition, how can I open whole project if it is possible? Should I use
Qt creator or Xcode?

How to get started? Hard to say, it depends a lot on your background and
interests. Maybe start by fixing something that annoys you. Check the
bugtracker for low priority items, find one you care about and contact the
bug owner about it. Usually they are happy to provide hints on how to
attack the issue. IRC is great for that, so is private mail.

I personally use QtC and open the library I care about in that, but then I
an biased towards QtC, considering that I hack on that:-) Qt is cross
platform, so eventually you will need to test in other platforms and QtC
will be there, too.

Xcode should work, too, I'd you prefer that.

 Could you guide me to contribute you?

Not easy, as there is no one way to contribute.

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

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Tobias Hunger]

Hi Thiago,

Basically I agree with your statements, but I do not think we can rely
on journald
at this time.

The first problem is of course systemd itself: Ubuntu is one of the
biggest distros out
there and we can not reasonably assume that to be running systemd
before 14.04 is
at the end of its life-cycle. Considering that this is a long term
support release that
will be a while. But even when systemd is in use journald might be disabled or
misconfigured -- as you already said yourself. I hope gnome and KDE
starting to depend
on systemd user sessions will get that sorted out soon, but at this
time those changes are
not yet deployed in distributions.

So I think being able to rely on logging to journald is still a long
time off. So what is
the fallback? Stderr again?

Adding Journald into the picture will also make retrieving warnings
from remote machines
a lot more difficult. Currently we rely on SSH and/or gdbserver to
retrieve all application
output on Unix systems. I am not sure at this time how that would work
if the application
starts sending output to the journal. So having a way to force stderr
in favor of system logs
would be greatly appreciated.

Best Regards,
Tobias

PS: Creator not supporting getting logs from system logs on Unix systems
is not a bug, it is a feature nobody requested so far:-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build Hotspots in the Qt build process

[Tobias Hunger]

Hi Shane,

thanks again for the presentation at FOSDEM. I really enjoyed it:-)

The list of yours seems to be ordered alphabetically. I guess that is
not necessarily the order in which we should look at the files:-) This
list is rather long and slide 36 of your presentation shows that the
files listed trigger between 90s and more than 8000s of rebuild time!
That is two orders of magnitude difference, so if we look at this we
should start by looking at those in the 8000s range:-)

Could you generate a list of files sorted by hotness when you get
back to your lab? Maybe the distance of the file's datapoint from the
origin would be a good measure for that? That might need some
normalizing though.

I just went over your list and have not been overly surprised with
which files are causing long rebuild times: All of them are header
files that are widely used in Qt and by Qt applications. E.g. almost
the complete set of non-private headers in qtbase/src/corelib is
listed.

There actually is one .cpp file in the list, which is rather unexpected.

Seeing the same data for Qt webkit would also be cool. That is the
part of code that feels like it is taking the longest to build in all
of Qt:-)

Best Regards,
Tobias

On Mon, Feb 3, 2014 at 10:39 PM, Shane McIntosh mcint...@cs.queensu.ca wrote:
 Hi Qt developers!

 My name is Shane. I’m a PhD student at Queen’s University in Canada.

 I’ve been working on an approach for detecting build hotspots, i.e., files 
 that not only take a long time to rebuild, but also change often. We think 
 that these files are ideal candidates for refactoring that could shave time 
 off of incremental builds that are really impacting software teams.

 We came up with an approach that I presented last weekend at FOSDEM ( slides 
 are available here: 
 http://www.slideshare.net/shanemcintosh/identifying-hotspots-in-software-build-process
  ). One of the projects that we analyzed was Qt.

 I bumped into Tobias at FOSDEM and he suggested that I post the list of Qt 
 hotspots here. So, I’ve made the hotspot list available here: 
 http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt

 I’m happy to provide a more detailed Qt dataset when I return to my lab next 
 week.

 Kind regards,
 -Shane

 P.S.: We are conducting a survey on how build performance is impacting 
 developers ( http://is.gd/DbMRTr ). If you could spare 5 minutes to fill out 
 our survey, we’d really appreciate it!
 ___
 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] How long until clang memory model is ready?

[Tobias Hunger]

On Wed, Jan 22, 2014 at 7:14 PM, Chris L hackthegovernm...@hotmail.com wrote:
 Qt Creator could be, with a few fixed bugs the obvious #1 choice ( if it
 isn't already ) for general cross platform c++

Which bugs are those in your oppinion?

 but it seems like the devs ignore non Qt c++ development.

What makes you say that? Are there specific instances where we made
non-Qt C++ use-cases harder?

From my point of view we do not ignore the no-Qt use-case, but Qt is definitely
the focus. But then a good Qt IDE is also a good C++ IDE.

 I brought up the clang memory model because discussions on the irc channels
 and old blog entries indicate that there was a plan to use clangs memory
 model to support the stl's classes in Qt Creator ( unique_ptr, vector,
 ect... ), once clang's memory model was working correctly, and my question
 is about when to expect this to happen if ever?

Are you talking about the code model here and not the memory model?

Yes, template support is not as good as it should be. That does not
require us to
switch to the clang code model though (our existing one could be
improved as well).

The Clang plugin is part of the upcoming Qt Creator 3.1, but it is
still marked as
experimental there. So it will be disabled by default. It still is
significantly slower than
our current one though.

Any help to improve it is appreciated -- especially testing and the more unusual
the setup you test in the more valuable the results are.

PS: Please move this thread to the Qt Creator mailing list if possible...

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

Re: [Development] Nominating Michael Brüning as Approver

[Tobias Hunger]

+1

On Dec 13, 2013 12:40 PM, Jocelyn Turcotte jocelyn.turco...@digia.com
wrote:

 Hello,

 Michael has been working for Nokia since 2008 and joined the QtWebKit
team in 2011, which he then followed in Digia.
 He has since then been contributing many changes to QtWebKit and has
lately also been helping with QtWebEngine.

 here are his dashboard and his contributions to upstream WebKit:

 https://codereview.qt-project.org/#dashboard,1000263


https://codereview.qt-project.org/#q,owner:michael.bruning%2540digia.com+-status:abandoned,n,z

https://codereview.qt-project.org/#q,reviewer:michael.bruning%2540digia.com+label:CodeReview%252B1,n,z
 http://trac.webkit.org/search?changeset=onq=michael.bruning

 You can find him on IRC as mibrunin.
 I'm convinced that Michael will make a trustworthy approver.

 Best Regards,
 Jocelyn
 ___
 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] Qt SDK for Mac OS X (was: New Qt 5.2 snapshot build #172)

[Tobias Hunger]

On Nov 27, 2013 9:29 PM, Adam Strzelecki o...@java.pl wrote:
 Correct me if I am wrong but there’s single ~/.config/…/QtCreator file,
so even we have several QtCreators all of them gonna see some SDK
registered by the other.

Several users can share one installation of Qt creator. We also support one
user having different Qt Creator/Qt packages. Think Qt SDK and secret
new platform SDK. Qt SDK will want to see all Qt versions, except those
for the secret new platform, while the secret SDK will want to see only its
Qts. Both SDKs should not integer with any of the settings of the other.

That is why we have installation-wide and user settings -- in the two SDK
case we even have two completely separate sets of installation-wir and user
settings.

The SDK installer needs to work on the installation-wide settings and can
not even know all users of that installation. It can not touch user
settings in any way, but is limited to the installation wide settings.

The whole problem boils down to: How can Creator find all the relevant Qt
versions?

Currently we do that by having the installer register the Qt versions with
the one instance of Qt creator it did install along the Qt versions it set
up.

Maybe Qt Chooser is a way to go in the future, maybe we can register all Qt
Creators on a system and have Qt figure out which of those to register
with, maybe something else.

Good ideas are welcome.

 Of course triggering registration and copy Qt5.x.y-spec.qtsdk with Qt
Creator requires Qt Creator to be there. It may be explicitly written on
.dmg background image. We can even put link to Qt Creator download too for
convenience. I have ready bash scripts that do all the layout and dmg build.

You are aware that there are no .qtsdk files? So the rest of this mail is
mostly wishful thinking till somebody fleshed out what those files actually
are.

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

Re: [Development] Nominating Nikolai Kosjar for Maintainer

[Tobias Hunger]

On Nov 19, 2013 2:38 PM, Erik Verbruggen erik.verbrug...@digia.com
wrote:

 Hello everyone,

 I would like to nominate Nikolai Kosjar for Maintainer of the C/C++
 support in Qt Creator.

+1 Nikolai does keep the Cpp support rolling, so I am all for making that
official.

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

Re: [Development] Clang (trunk) no longer builds Qt applications

[Tobias Hunger]

On 22.10.2013 15:31, Nicolás Alvarez wrote:
 I don't think the standard is relevant here. The C++ standard doesn't
 and can't say anything about whether 'break' and 'continue' are allowed
 in a statement expression inside the 'for' header, because statement
 expressions don't exist in the standard to begin with; they are a gcc
 extension. Clang has to reverse engineer the exact semantics from gcc
 behavior.

So can we avoid relying on GCC extensions here?

I doubt that we can ask clang to be 100% compatible with GCC anyway and 
making that a requirement for Qt to function properly is not what we 
should aim for IMHO.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] GDB python pretty printers for common Qt classes

[Tobias Hunger]

There are pretty printers for most commonly used Qt types in Qt Creator.
Can those be used?

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

Re: [Development] [Qt-creator] Orgad Shaneh is maintainer of ClearCase plugin in Qt Creator now

[Tobias Hunger]

Hello everybody!

I proposed Orgad Shaneh for maintainer in November already, so everybody 
had enough time to speak up even with christmas holidays and the Qt 5 
release. I just asked Ossi to add him into the maintainers group on 
Gerrit as well as added him to the maintainers wiki page, so he is 
officially a maintainer now.

Congratulations to Orgad for his outstanding work!

He is now responsible for the ClearCase plugin to Qt Creator.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Nominating Orgad Shaneh for maintainer of ClearCase plugin in Qt Creator

[Tobias Hunger]

Hello!

I would like to nominate Orgad Shaneh for the role as maintainer of the 
ClearCase plugin in Qt Creator.

We merged a patch yesterday removing the experimental tag from the 
ClearCase plugin, so it is time to nominate a maintainer for it. Orgad 
has originally written this plugin and has been doing all the work of on 
it ever since it was accepted, so he is the ideal candidate.

Orgad has been contributing patches to Qt Creator for a long time now. 
He made cleanups, fixed bugs all over the codebase, has contributed new 
features and even a full plugin. He is an approver for a while now and 
fills that role well, being friendly, responsive and competent.

Here is a list of Orgad merged patches:
https://codereview.qt-project.org/#q,status:merged+owner:1000534,n,z

Best Regards,
Tobias
-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branching 5.0

[Tobias Hunger]

On 28.11.2012 20:47, Knoll Lars wrote:
 We will have the following policies on the branches:

 * master:

 Transitional only. Will be closed for new pushes once the branches get 
 created. Patches that are already in gerrit can still be staged for around a 
 week to allow everybody to stage their pending changes. Master will then get 
 merged to dev, and we will then completely close master.

 Changes that should go into stable will need to get pushed again to the newly 
 created stable branch and abandoned for master. After master is fully closed 
 all changes that are still pending will need to get pushed to dev or stable 
 again.

 Only binary compatible changes are allowed into this branch, as it'll be 
 merged to dev later on.

 * dev:

 Forms the basis of what will become 5.1. New features are ok to push there, 
 as long as they are complete, tested and documented.

 Please note that although the branch is called dev, larger new features (such 
 as the new ports) should not be developed in this branch. Please use a 
 special development branch for this and push the feature to dev once it's 
 done.

 Only binary compatible changes are allowed into this branch.

 * stable:

 Will become the RC, and we will then create the release branch out of it.

 Fully feature frozen.

This sounds a a lot like the model proposed by git-flow. How about 
adopting that approach formally so that we can (optionally:-) use the 
git-flow tool to help work with this model?

The branching model:
http://nvie.com/posts/a-successful-git-branching-model/

The tool to support this model:
https://github.com/nvie/gitflow

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt Creator 2.6 and Qt5 newer than beta2

[Tobias Hunger]

Hello!

The newly released Qt Creator 2.6 does not accept Qt 5 versions later 
than beta2, since it is failing to detect the ABIs used. This is due to 
Qt5 changing all the library names around after beta2 came out.

I put a fix into for this into Qt Creators 2.6 branch which Eike already 
merged into master. Please update if you want to work with Qt5 versions 
later than beta2.

If you do not want to build creator yourself you can always grab a 
nightly build from builds.qt-project.org (tomorrow, the builds from 
today do not have the patch yet;-).

Sorry for the inconvenience.

Best Regards,
Tobias
-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Tobias Hunger]

On 19.10.2012 19:26, Sune Vuorela wrote:
 no. it would be if you compiled Qt yourself or if you downloaded the
 built editions from digia, write qmake to build things. if you gotten
 from your linux distribution write probably
 qmake5,

Developers tend to be computer savvy people, they should be able to 
figure out a path to a binary on their system. Windows devs certainly 
can... I hope you are not implying Linux devs are more stupid than 
windows devs;-)

If a distribution feels that it needs to provide a default Qt for newbie 
developers to use, then it can always install a symlink to 
/usr/lib/ia64-linux-gnu/qt5/bin/qmake into /usr/bin and be done with 
that. Somebody just wanting to get his feet wet with Qt programming
will not care too deeply about the exact Qt version anyway (most likely 
not even whether it is Qt 4 or 5).

 but maybe the distro chose some other naming scheme so it could
 also be qmake-qt5 or /usr/lib/ia64-linux-gnu/qt5/bin/qmake

Distributions will always rename/move around/leave out binaries. That is 
a distribution's core competence;-) Seriously: Distros have widely 
differing setups that can influence packaging. Some support multiarch 
installations, some need to press their distro into a distribution 
medium of a certain size, others do not. Some have special licensing 
needs, some will use virtualization/containers to provide better 
security, etc. There is just no way upstream can not address all this.

So let's make sure Qt installs cleanly on Linux systems in an as 
self-contained way as possible. Ideally distro-provided Qts should feel 
similar to self-compiled Qts (or those from an SDK) and similar to Qts 
on other systems like windows and mac.

To me that seems to be to install the binaries into a place outside of 
$PATH. Maybe we could provide recommendations for symlinks to be put 
into $PATH, but that is all we should do IMHO.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development