Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Oswald Buddenhagen]

On Wed, May 15, 2019 at 07:50:42PM +0200, André Pönitz wrote:
> On Wed, May 15, 2019 at 11:38:25AM +0200, Oswald Buddenhagen wrote:
> > [...]
> > jake had started that "qt-free qbs" project (he got as far as
> > eliminating (most) use of qt containers), but it was snuffed out because
> > it was unrealistic and counterproductive at that time. even now, no
> > patches in that direction will be accepted
> 
> Won't they?
> 
not unless the benefit is immediate.

> > unless a coherent final picture and a credible committment to
> > further maintenance is presented.
> 
> Getting rid of implicitly shared containers should be a rather obvious
> move when "performance" is part of any "final picture", coherent or
> not.
> 
this blanket statement is just wrong if you account for the entire
context, which is that qbs both uses and provides qt-like apis which are
centered around shared containers, and converting between the two adds
significant overhead.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[André Pönitz]

On Thu, May 16, 2019 at 10:00:33AM +1200, Christian Gagneraud wrote:
> On Thu, 16 May 2019 at 09:32, Иван Комиссаров  wrote:
> > > 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
> > >
> > > Getting rid of implicitly shared containers should be a rather obvious 
> > > move
> > > when "performance" is part of any "final picture", coherent or not.
> >
> > +1 from me, hidden detaches are evil =)
> 
> How do you avoid copy then? Without cluttering an API.

API-wise, returning some kind of iterator/span/range is often sufficent,
and even more flexible than a full copy.

I am also not sure how relevant API here is. The only "external" consumer
of QBS API I am aware of is Qt Creator.

Implicit sharing is convenient, and it's even a solution when performance is not
crucial, e.g. classical GUI code. But I wouldn't attach that label to build
systems. Quite a few containers are never copied, yet with implicit sharing one
pays for each access "just in case" the container is copied massively, 
unmodified.

Andre'
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Epting, Thomas]

> I didn’t do any measurements, but quick search for QList in Qbs
> source code shows a lot of places  where it’s used incorrectly –
 > it stores «big» structures, std::shared_pointers, even all
 > QSharedDataPointer classes are not marked as Q_MOVABLE_TYPE
 > and thus result in extra allocations in QLists…
>
 > My point is - current usage of Qt containers in Qbs should be
> carefully revisited, switching to more suitable containers
> (QVector or std::vector/std::deque).

I think we should know the performance hot spots first, before going to spend 
effort on doing broad code changes where it’s not affecting performance at all 
(which is typically true for 95% of the code). We should use tools like VTune 
to identify these hot spots and possibly segregate them, then focus on 
optimizing the sensible parts only.

Thomas

Von: Qbs  Im Auftrag von  ??
Gesendet: Donnerstag, 16. Mai 2019 01:25
An: Christian Gagneraud 
Cc: qbs 
Betreff: Re: [Qbs] Donation to QBS developers/maintainers/contributes

In many cases, you don’t need to copy them. For trivial getters, you can return 
const-ref/span to the internal vector instead of a copy because in many places 
all we do is iterate over that vector.

The only argument for copies is that it’s impossible to change the 
implementation from returning a member to some «transformed member» without 
breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t think 
it’s relevant.

This will save us from creating a temp variables or usages of qAsCont to avoid 
detaching in range-for loops (see this commit 
https://codereview.qt-project.org/#/c/253792/ to estimate the amount of 
incorrect usages of Qt containers). Note, that those clutter API as well, 
especially the need of a temp variable.

I didn’t do any measurements, but quick search for QList in Qbs source code 
shows a lot of places  where it’s used incorrectly - it stores «big» 
structures, std::shared_pointers, even all QSharedDataPointer classes are not 
marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists…

My point is - current usage of Qt containers in Qbs should be carefully 
revisited, switching to more suitable containers (QVector or 
std::vector/std::deque).



16 мая 2019 г., в 0:00, Christian Gagneraud 
mailto:chg...@gmail.com>> написал(а):

On Thu, 16 May 2019 at 09:32, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:

15 мая 2019 г., в 19:50, André Pönitz 
mailto:apoen...@t-online.de>> написал(а):

Getting rid of implicitly shared containers should be a rather obvious move
when "performance" is part of any "final picture", coherent or not.

+1 from me, hidden detaches are evil =)

How do you avoid copy then? Without cluttering an API.

Chris

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Thu, 16 May 2019 at 11:24, Иван Комиссаров  wrote:
>
> In many cases, you don’t need to copy them. For trivial getters, you can 
> return const-ref/span to the internal vector instead of a copy because in 
> many places all we do is iterate over that vector.
>
> The only argument for copies is that it’s impossible to change the 
> implementation from returning a member to some «transformed member» without 
> breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t 
> think it’s relevant.
>
> This will save us from creating a temp variables or usages of qAsCont to 
> avoid detaching in range-for loops (see this commit 
> https://codereview.qt-project.org/#/c/253792/ to estimate the amount of 
> incorrect usages of Qt containers). Note, that those clutter API as well, 
> especially the need of a temp variable.
>
> I didn’t do any measurements, but quick search for QList in Qbs source code 
> shows a lot of places  where it’s used incorrectly - it stores «big» 
> structures, std::shared_pointers, even all QSharedDataPointer classes are not 
> marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists…

can QList -> QVector be automated? Or does it has to be done on a case by case?
I have a python script to do "mass but targeted" clang/clazy auto-fixit.

There is 
https://github.com/KDE/clazy/blob/master/docs/checks/README-inefficient-qlist.md
But it doesn't offer a fixit :(

Concerning the QSharedDataPointer classes are not marked as
Q_MOVABLE_TYPE, could clazy detect/fix these as well?

> My point is - current usage of Qt containers in Qbs should be carefully 
> revisited, switching to more suitable containers (QVector or 
> std::vector/std::deque).

Moving to QVector seems easier, at least as a first test. But we would
need performace regression testing to see if it really speed up
things.

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

In many cases, you don’t need to copy them. For trivial getters, you can return 
const-ref/span to the internal vector instead of a copy because in many places 
all we do is iterate over that vector.

The only argument for copies is that it’s impossible to change the 
implementation from returning a member to some «transformed member» without 
breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t think 
it’s relevant.

This will save us from creating a temp variables or usages of qAsCont to avoid 
detaching in range-for loops (see this commit 
https://codereview.qt-project.org/#/c/253792/ 
 to estimate the amount of 
incorrect usages of Qt containers). Note, that those clutter API as well, 
especially the need of a temp variable.

I didn’t do any measurements, but quick search for QList in Qbs source code 
shows a lot of places  where it’s used incorrectly - it stores «big» 
structures, std::shared_pointers, even all QSharedDataPointer classes are not 
marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists…

My point is - current usage of Qt containers in Qbs should be carefully 
revisited, switching to more suitable containers (QVector or 
std::vector/std::deque).


> 16 мая 2019 г., в 0:00, Christian Gagneraud  написал(а):
> 
> On Thu, 16 May 2019 at 09:32, Иван Комиссаров  wrote:
>>> 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
>>> 
>>> Getting rid of implicitly shared containers should be a rather obvious move
>>> when "performance" is part of any "final picture", coherent or not.
>> 
>> +1 from me, hidden detaches are evil =)
> 
> How do you avoid copy then? Without cluttering an API.
> 
> Chris

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Thu, 16 May 2019 at 09:32, Иван Комиссаров  wrote:
> > 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
> >
> > Getting rid of implicitly shared containers should be a rather obvious move
> > when "performance" is part of any "final picture", coherent or not.
>
> +1 from me, hidden detaches are evil =)

How do you avoid copy then? Without cluttering an API.

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

+1 from me, hidden detaches are evil =)

> 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
> 
> Getting rid of implicitly shared containers should be a rather obvious move
> when "performance" is part of any "final picture", coherent or not.
> 
> Andre'
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[André Pönitz]

On Wed, May 15, 2019 at 11:38:25AM +0200, Oswald Buddenhagen wrote:
> [...]
> jake had started that "qt-free qbs" project (he got as far as
> eliminating (most) use of qt containers), but it was snuffed out because
> it was unrealistic and counterproductive at that time. even now, no
> patches in that direction will be accepted

Won't they?

> unless a coherent final
> picture and a credible committment to further maintenance is presented.

Getting rid of implicitly shared containers should be a rather obvious move
when "performance" is part of any "final picture", coherent or not.

Andre'
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Oswald Buddenhagen]

On Tue, May 14, 2019 at 04:17:41PM +0200, Иван Комиссаров wrote:
> Qbs itself has a huge dependency on a QtCore, but some stuff is
> present in standard library and can be easily changed to that (we
> still have enourmous amount of places where qlist is used instead of a
> qvector/std::vector and used inefficient);
>
yes, getting rid of qt containers is easy. only the qtcreator plugin
would still need them (and it's a good question where to draw the lines
to not introduce unnecessary conversion inefficiencies).

qstring is a lot harder ... 

> others are trickier but can be bootstrapped (like qfile) if needed.
>
bootstrapping qt classes is counterproductive (you notice latest when
you link libqbs into qtcreator) and laborious (you notice latest when
you get to qprocess or another class that *needs* full qobject/moc and
the qt event loop to operate sensibly).

as of now, there is no reasonable alternative to pulling in random
external dependencies, possibly boost (fwiw, the relevant c++ stdlib
projects are apparently dormant).

> But what about QtScript's dependency on the QtCore/other libs? My
> point was that it may depend on the qtlibs more than Qbs does and the
> biggest job is there, not in Qbs core.
> 
for the js engine, a bare JSC was considered.
hmm, come to think of it, the js engine might not be the only part from
webkit (or webengine) that makes sense to build upon ...

jake had started that "qt-free qbs" project (he got as far as
eliminating (most) use of qt containers), but it was snuffed out because
it was unrealistic and counterproductive at that time. even now, no
patches in that direction will be accepted unless a coherent final
picture and a credible committment to further maintenance is presented.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

Good information, thanks.
Qbs itself has a huge dependency on a QtCore, but some stuff is present in 
standard library and can be easily changed to that (we still have enourmous 
amount of places where qlist is used instead of a qvector/std::vector and used 
inefficient); others are trickier but can be bootstrapped (like qfile) if 
needed.
But what about QtScript's dependency on the QtCore/other libs? My point was 
that it may depend on the qtlibs more than Qbs does and the biggest job is 
there, not in Qbs core.

Иван Комиссаров

> 14 мая 2019 г., в 14:08, Christian Gagneraud  написал(а):
> 
>> On Tue, 14 May 2019 at 23:35, Christian Gagneraud  wrote:
>> 
>>> On Tue, 14 May 2019 at 23:11, Christian Gagneraud  wrote:
>>> 
 On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
 
 I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
 qtdeclarative originally used v8 JavaScript engine which got replaced with 
 Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible 
 to go the opposite direction and remove Qt dependency in the first place?
 Except for GUI and script module, I don't think there's a lot of Qt stuff.
>>> 
>>> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
>>> '*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
>>> | sort | uniq -c | sort -nr
>>>   673 QtCore
>>> 76 QtScript
>>>  7 QtGui
>>>  6 QtWidgets
>>>  5 QtNetwork
>>>  1 QtXml
>> 
>> The above is the number of #include in all cpp and h files, per Qt
>> module. As you can see dependency on QtCore is quite heavy.
>> 
>> And here is the number of cpp/h files using QtScript, per directory:
>> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
>> QtScript src/ | egrep '.(cpp|h)' | xargs dirname | sort | uniq -c |
>> sort -nr
>> 17 src/lib/corelib/buildgraph
>> 14 src/lib/corelib/jsextensions
>> 12 src/lib/corelib/language
>>  3 src/lib/corelib/tools
>> 
>> Ideally you would like to see only jsextensions and language
> 
> Just in case someone follows my monologue... :)
> 
> QtSCript dependency of buildgraph:
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -h
> QtScript src/lib/corelib/buildgraph/ | sed -ne 's,^ *# *include
> *]*\)>.*$,\1,gp' | sort | uniq -c | sort -nr
>10 qscriptvalue.h
>  3 qscriptengine.h
>  3 qscriptcontext.h
>  2 qscriptvalueiterator.h
>  2 qscriptclass.h
>  1 qscriptstring.h
>  1 qscriptprogram.h
>  1 qscriptclasspropertyiterator.h
> 
> I'm no expert at QtScript and Javascript, but this looks mostly like
> "core" classes (value, engine, context, program).
> 
> And here are the "offenders"
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
> QtScript src/lib/corelib/buildgraph/
> src/lib/corelib/buildgraph/artifactsscriptvalue.cpp
> src/lib/corelib/buildgraph/artifactsscriptvalue.h
> src/lib/corelib/buildgraph/buildgraph.cpp
> src/lib/corelib/buildgraph/buildgraph.h
> src/lib/corelib/buildgraph/dependencyparametersscriptvalue.h
> src/lib/corelib/buildgraph/depscanner.cpp
> src/lib/corelib/buildgraph/depscanner.h
> src/lib/corelib/buildgraph/processcommandexecutor.cpp
> src/lib/corelib/buildgraph/projectbuilddata.h
> src/lib/corelib/buildgraph/qtmocscanner.cpp
> src/lib/corelib/buildgraph/qtmocscanner.h
> src/lib/corelib/buildgraph/rulecommands.cpp
> src/lib/corelib/buildgraph/rulecommands.h
> src/lib/corelib/buildgraph/rulesapplicator.cpp
> src/lib/corelib/buildgraph/rulesapplicator.h
> src/lib/corelib/buildgraph/rulesevaluationcontext.h
> src/lib/corelib/buildgraph/scriptclasspropertyiterator.h
> 
> But this is without looking at leaks from langugage itself:
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
> QtScript src/lib/corelib/language/*.h
> src/lib/corelib/language/evaluationdata.h
> src/lib/corelib/language/evaluator.h
> src/lib/corelib/language/evaluatorscriptclass.h
> src/lib/corelib/language/language.h
> src/lib/corelib/language/scriptengine.h
> src/lib/corelib/language/scriptimporter.h
> 
> Is it worth the effort to remove QtScript from buildgraph and make
> language hermetic to QtScript?
> Versus: forking, maintaining (and improving?) QtScript.
> 
> Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Tue, 14 May 2019 at 23:11, Christian Gagneraud  wrote:
>
> On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
> >
> > I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
> > qtdeclarative originally used v8 JavaScript engine which got replaced with 
> > Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible 
> > to go the opposite direction and remove Qt dependency in the first place?
> > Except for GUI and script module, I don't think there's a lot of Qt stuff.
>
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
> '*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
> | sort | uniq -c | sort -nr
>673 QtCore
>  76 QtScript
>   7 QtGui
>   6 QtWidgets
>   5 QtNetwork
>   1 QtXml

The above is the number of #include in all cpp and h files, per Qt
module. As you can see dependency on QtCore is quite heavy.

And here is the number of cpp/h files using QtScript, per directory:
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
QtScript src/ | egrep '.(cpp|h)' | xargs dirname | sort | uniq -c |
sort -nr
 17 src/lib/corelib/buildgraph
 14 src/lib/corelib/jsextensions
 12 src/lib/corelib/language
  3 src/lib/corelib/tools

Ideally you would like to see only jsextensions and language

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
>
> I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
> qtdeclarative originally used v8 JavaScript engine which got replaced with 
> Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible to 
> go the opposite direction and remove Qt dependency in the first place?
> Except for GUI and script module, I don't think there's a lot of Qt stuff.

chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
| sort | uniq -c | sort -nr
   673 QtCore
 76 QtScript
  7 QtGui
  6 QtWidgets
  5 QtNetwork
  1 QtXml
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^>]*\)>.*$,\1,gp' |
sort | uniq -c | sort -nr
 70 QtCore/qstring.h
 67 QtCore/qstringlist.h
 54 QtCore/qdir.h
 40 QtCore/qfileinfo.h
 39 QtCore/qvariant.h
 37 QtCore/qhash.h
 30 QtCore/qprocess.h
 28 QtCore/qshareddata.h
 28 QtCore/qobject.h
 26 QtScript/qscriptvalue.h
 25 QtCore/qlist.h
 25 QtCore/qcoreapplication.h
 24 QtCore/qfile.h
 20 QtScript/qscriptengine.h
 20 QtCore/qglobal.h
 18 QtCore/qmap.h
 17 QtCore/qdebug.h
 14 QtCore/qbytearray.h
 13 QtCore/qtimer.h
 12 QtCore/qtextstream.h
 11 QtCore/qregexp.h
 11 QtCore/qdiriterator.h
 10 QtScript/qscriptable.h
  8 QtCore/qt_windows.h
  7 QtCore/quuid.h
  7 QtCore/qdatastream.h
  6 QtCore/qsettings.h
  5 QtScript/qscriptvalueiterator.h
  5 QtScript/qscriptclass.h
  5 QtCore/qtemporaryfile.h
  4 QtScript/qscriptcontext.h
  4 QtCore/qthread.h
  4 QtCore/qloggingcategory.h
  4 QtCore/qcryptographichash.h
  3 QtCore/qmetatype.h
  3 QtCore/qjsonobject.h
  3 QtCore/qjsondocument.h
  3 QtCore/qflags.h
  3 QtCore/qdatetime.h
  2 QtScript/qscriptstring.h
  2 QtScript/qscriptprogram.h
  2 QtScript/qscriptclasspropertyiterator.h
  2 QtNetwork/qlocalsocket.h
  2 QtGui/qtextcursor.h
  2 QtCore/qxmlstream.h
  2 QtCore/qvarlengtharray.h
  2 QtCore/qlibrary.h
  2 QtCore/qjsonarray.h
  2 QtCore/qeventloop.h
  2 QtCore/qelapsedtimer.h
  2 QtCore/qabstractitemmodel.h
  1 QtXml/qdom.h
  1 QtWidgets/qmessagebox.h
  1 QtWidgets/qmenu.h
  1 QtWidgets/qmenubar.h
  1 QtWidgets/qmainwindow.h
  1 QtWidgets/qapplication.h
  1 QtWidgets/qaction.h
  1 QtNetwork/qsslcertificate.h
  1 QtNetwork/qsslcertificateextension.h
  1 QtNetwork/qlocalserver.h
  1 QtGui/qtextobject.h
  1 QtGui/qtextdocument.h
  1 QtGui/qkeysequence.h
  1 QtGui/qevent.h
  1 QtGui/qbrush.h
  1 QtCore/qvector.h
  1 QtCore/qurl.h
  1 QtCore/qtextcodec.h
  1 QtCore/qtemporarydir.h
  1 QtCore/qregularexpression.h
  1 QtCore/qpoint.h
  1 QtCore/qpair.h
  1 QtCore/qnumeric.h
  1 QtCore/qlockfile.h
  1 QtCore/qiodevice.h
  1 QtCore/qendian.h
  1 QtCore/qcommandlineparser.h
  1 QtCore/qcommandlineoption.h
  1 QtCore/qbytearraymatcher.h
  1 QtCore/qbytearraylist.h
  1 QtCore/private/qcore_mac_p.h
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | wc -l
482

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
qtdeclarative originally used v8 JavaScript engine which got replaced with 
Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible to go 
the opposite direction and remove Qt dependency in the first place?
Except for GUI and script module, I don't think there's a lot of Qt stuff. 

Иван Комиссаров

> 14 мая 2019 г., в 12:33, Richard Weickelt  написал(а):
> 
> 
>>> However, will this help to get new developers? Right now, there are not that
>>> many contributors.
>> 
>> I agree, how much money do you want to raise? And what for?
>> For now Qbs can use Qt (company/project) infra, so there's no need to
>> manage an infra.
> 
> The Qt Company pays for qt.io. We can ask them to sponsor the domain also in 
> the future, but we cannot expect it.
> 
> If we had fee-lancing contributors, then it might make sense to set up a 
> bounty system. I also find models like this https://www.patreon.com/bjorn 
> interesting. I guess that spare-time contributors have a different motivation 
> though.
> 
> What is IMO more important is, to turn qbs.io into an attractive landing 
> page. It should become more clear, that Qbs is no longer a The Qt Company 
> project. Might be worth to pay a web designer to come up with a professional 
> looking.  Any volunteers? https://bugreports.qt.io/browse/QBS-1341
> 
> Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Richard Weickelt]

>> However, will this help to get new developers? Right now, there are not that
>> many contributors.
> 
> I agree, how much money do you want to raise? And what for?
> For now Qbs can use Qt (company/project) infra, so there's no need to
> manage an infra.

The Qt Company pays for qt.io. We can ask them to sponsor the domain also in 
the future, but we cannot expect it.

If we had fee-lancing contributors, then it might make sense to set up a bounty 
system. I also find models like this https://www.patreon.com/bjorn interesting. 
I guess that spare-time contributors have a different motivation though.

What is IMO more important is, to turn qbs.io into an attractive landing page. 
It should become more clear, that Qbs is no longer a The Qt Company project. 
Might be worth to pay a web designer to come up with a professional looking.  
Any volunteers? https://bugreports.qt.io/browse/QBS-1341

Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Richard Weickelt]

> If I am right, one urgent task is to remove the dependency of Qt Script.

I don't think it's urgent. It might not even be necessary given that Qbs won't 
be Qt's next build system and won't have to be bootstrapped. But if you have 
good ideas, feel free to discuss in https://bugreports.qt.io/browse/QBS-913

Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Vincent Hui]

If I am right, one urgent task is to remove the dependency of Qt Script.

Vincent


On Tue, 14 May 2019 at 17:51, Christian Gagneraud  wrote:

> On Tue, 14 May 2019 at 21:46, Иван Комиссаров  wrote:
> >
> > +1
> >
> > However, will this help to get new developers? Right now, there are not
> that many contributors.
>
> I agree, how much money do you want to raise? And what for?
> For now Qbs can use Qt (company/project) infra, so there's no need to
> manage an infra.
>
> Chris
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Tue, 14 May 2019 at 21:46, Иван Комиссаров  wrote:
>
> +1
>
> However, will this help to get new developers? Right now, there are not that 
> many contributors.

I agree, how much money do you want to raise? And what for?
For now Qbs can use Qt (company/project) infra, so there's no need to
manage an infra.

Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

+1

However, will this help to get new developers? Right now, there are not that 
many contributors.

Иван Комиссаров

> 14 мая 2019 г., в 11:18, Карелин Павел  написал(а):
> 
> +1
> 
> 14.05.2019 11:54, Алексей Скородумов пишет:
>> Hi,
>> 
>> Is it hard to make "donate" button on "QBS site" as a part of "transition to 
>> community"?
>> I can't contribute time right now, but would like to support the project.
>> 
>> --
>> Best regards,
>> Aleksei Skorodumov
>> 
>> 
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Карелин Павел]

+1

14.05.2019 11:54, Алексей Скородумов пишет:

Hi,

Is it hard to make "donate" button on "QBS site" as a part of 
"transition to community"?

I can't contribute time right now, but would like to support the project.

--
Best regards,
Aleksei Skorodumov

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs