Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

[Marco Bubke via Development]

On 21.02.24 19:56, Edward Welbourne via Development wrote:

Andre' Poenitz  (21 February 2024 19:21) wrote:

1. 'static' is attached to individual functions, not a scope of
uncertain extend. When working on unfamiliar code it helps to
understand the context. With 'static' the locality is obvious in the
immediate context of the function and not set by some 'namespace {'
potentiall a dozen functions and hundreds of lines of code away.


In particular this means that if someone picks up the function and moves
it elsewhere in the file, cut and paste, it's very easy to fail to
notice that they've moved it out of a nameless namespace and thereby
suddenly made it visible to the linker.  They'd have taken that little
word "static" on the front of the declaration with it, if it'd been
there, because it's not so easy to miss.

(Incidentally, the ways I can think of to say "has no name" tend to
suffer from some degree of precedent as "has a name but it has not been
disclosed" - the anonymous author of a pamphlet, the unnamed person who
reported a problem.  I'm currently unable to think of such a precedent
for "nameless", but I suspect that's only that I can't currently think
of it.  Then again, if a namespace with no name actually does have a
secret name, I guess that just matches the linguistic baggage.)



There is a warning for a missing 
prototype/declarations(-Wmissing-prototypes and -Wmissing-declarations). 
The clang code model in QtCreator is warning me reliable about it. You 
can even enforce it by -Werror if you like. ;-)


Anonymous namespace have an other advantage. They work with other 
construct like classes, enumerations etc. too. People tend to copy code 
and then you end with a slightly different class. We already had ODR 
problems because it. And this bugs are hard to find. If you put 
everything in an anonymous namespace you are simply fine. It is a very 
easy rule. Yes, that should be not happen but it does.

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

Re: [Development] API style guide: scoped enum or not?

[Marco Bubke via Development]

Hi Thiago

This is introducing dependencies on code which makes dependency breaking much 
harder. I very often need an enumeration in an interface but not the class 
itself. There are ways to get around that but it makes TDD harder if Qt is 
involved.


From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, May 4, 2023 0:17
To: development@qt-project.org 
Subject: Re: [Development] API style guide: scoped enum or not?

On Wednesday, 3 May 2023 10:51:18 PDT Jaroslaw Kobus via Development wrote:
> "enum class" has one advantage over "enum" inside a "class" : you may
> forward declare the "enum class", while the other not. That's quite often
> case that your header must include the other header just because you use
> the "enum" in "class" in your API and nothing more.

Hello Jarek

That's fair, but that requires a separate scope from the class itself. That
alone may be a reason not to do so, and instead just declare the enum inside
the class, as our current practice dictates, with the choice of plain enum or
enum class.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Knud Dollereder as approver

[Marco Bubke]

+1

From: Development  On Behalf Of Thomas 
Hartmann
Sent: Monday, June 14, 2021 12:21 PM
To: development@qt-project.org
Subject: [Development] Nominating Knud Dollereder as approver

Hi all,

I'd like to nominate Knud Dollereder as an approver for the Qt Project.

Mahmoud has been working on Qt 3D Studio Design Studi and has regularly 
contributed to Qt Design Studio and Qt Creator.
He helped with implementing the timeline and implemented the curve editor.

Qt Commits:
   https://codereview.qt-project.org/q/owner:knud.dollereder%2540qt.io

Currently, Knud is working on Qt 6 support and helps with macOS issues.
Mandatory disclaimer: We work in the same team.

I trust him to be a good reviewer.

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

Re: [Development] Nominating Henning Gründl as approver

[Marco Bubke]

+1

From: Development  On Behalf Of Thomas 
Hartmann
Sent: Monday, June 14, 2021 12:30 PM
To: development@qt-project.org
Subject: [Development] Nominating Henning Gründl as approver

Hi all,

I'd like to nominate Henning Gründl as an approver for the Qt Project.

Henning has been working on Qt Studio Design Studio and has regularly 
contributed to Qt Design Studio and Qt Creator.
He helped to integrate the advanced dock widget framework and did a lot of work 
on the property editor.

Qt Commits:
   https://codereview.qt-project.org/q/owner:henning.gruendl%2540qt.io

Currently, Henning is further improving the property editor.
Mandatory disclaimer: We work in the same team.

I trust him to be a good reviewer.

Best regards,
Thomas Hartmann

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

Re: [Development] Nominating Aleksei German as aproover

[Marco Bubke]

+1

From: Development  On Behalf Of Thomas 
Hartmann
Sent: Monday, June 14, 2021 12:27 PM
To: development@qt-project.org
Subject: [Development] Nominating Aleksei German as aproover

Hi all,

I'd like to nominate Aleksei German as an approver for the Qt Project.

Aleksei has been working on Qt Studio Design Studio and has regularly 
contributed to Qt Design Studio and Qt Creator.
He implemented annotation support and improved the property editor and form 
editor. Aleksei is also taking care of the MCU support.

Qt Commits:
   https://codereview.qt-project.org/q/owner:aleksei.german%2540qt.io

Currently, Aleksei is working on a few last features for annotations and will 
continue with MCU support.
Mandatory disclaimer: We work in the same team.

I trust him to be a good reviewer.

Best regards,
Thomas Hartmann

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

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

[Marco Bubke]

A new Document API where you could memory map the file and save the changes as 
a log on top would be nice. For lines you have to read the file but you don't 
have to hold it completely in memory. An other advantage would be that your 
document would be a binary reflection of the file. But I think this would be 
not a replacement of QDocument.

-Original Message-
From: Development  On Behalf Of Lars Knoll
Sent: Wednesday, August 26, 2020 9:23 AM
To: Ville Voutilainen 
Cc: Qt development mailing list 
Subject: Re: [Development] qsizetype and classes working with QStrings or QList


> On 26 Aug 2020, at 09:07, Ville Voutilainen  
> wrote:
> 
> On Wed, 26 Aug 2020 at 09:39, Lars Knoll  wrote:
>>> QtGui:
>>> * QTextCursor
>>> * QTextDocument (find offset, character{At,Count})
>>> * QTextLayout
>>> * QValidator and subclasses (validate offset)
>> 
>> These here are questionable. Editing a text file with more than 2G 
>> characters? Sounds unlikely.
> 
> Thou Shalt Not Write Debug Log Viewers Or Hex Editors With Qt. :)

Porting that API might not be too much of a problem, I don’t think we have 
virtual methods in there taking offsets.

But QTextDocument is probably not the right data structure for a hex editor or 
a log viewer anyway (why would you store a hex in clear text instead of 
decoding on the fly???).

Cheers,
Lars

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

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

[Marco Bubke]

auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed

AFAIK you can say that a rvalue should not return a reference by using 
ref-qualified member functions.

View getView() const & { return v;}
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Marco Bubke]

On June 13, 2019 17:25:15 Matthew Woehlke  wrote:

> On 13/06/2019 03.03, Marco Bubke wrote:
>> On June 12, 2019 23:13:14 Matthew Woehlke  wrote:
>>>> me here. I think Daniel is on to something and we really should explore
>>>> having smart pointers in Qt 6, but at this point I'm not convinced
>>>> std::unique_ptr alone is it. I'd like to see what we could achieve with a
>>>> QObject-specific smart pointer that understood ownership-taking functions
>>>> (setParent, addWidget, etc.) and observing-only API (like connect()).
>>>
>>> Idea: make this hypothetical pointer be a QObject that initially "owns"
>>> the object to which it points. If the object is reparented, the pointer
>>> will stop "owning" it but will still have the reference.
>>
>> Can you implement it so that it fits owner? One of the purposes is that 
>> the static analysis can be sure about the ownership.
>
> I don't think so; at least, not without a lot of associated work. Part
> of the above idea is that I believe it is notionally implementable *now*
> (or even as far back as Qt4 at least). You can safely pass the raw
> pointer to methods that may or may not reparent the object, and
> everything will continue to work, but currently it isn't obvious what
> methods will or won't take ownership, and in some cases the answer to
> that question depends on additional (run-time) information. (Note in
> particular the QLayout example as mentioned elsewhere in this thread.)
But then the static analysis tool gives you many false positives. So the tool 
gets less useful. Tools get more and more important, so we want to send the 
message that "real" Qt developers don't need that tools? ;-)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Marco Bubke]

On June 12, 2019 23:13:14 Matthew Woehlke  wrote:
>> me here. I think Daniel is on to something and we really should explore
>> having smart pointers in Qt 6, but at this point I'm not convinced
>> std::unique_ptr alone is it. I'd like to see what we could achieve with a
>> QObject-specific smart pointer that understood ownership-taking functions
>> (setParent, addWidget, etc.) and observing-only API (like connect()).
>
> Idea: make this hypothetical pointer be a QObject that initially "owns"
> the object to which it points. If the object is reparented, the pointer
> will stop "owning" it but will still have the reference.
Can you implement it so that it fits owner? One of the purposes is that the 
static analysis can be sure about the ownership.

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

Re: [Development] QList for Qt 6

[Marco Bubke]

Maybe flatpak is the way to go? There could be two runtimes. Personally I use 
more and more flatpaks because I get up-to-date packages provided by the 
developers.

On May 24, 2019 19:59:52 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> Hi!
>
> On Mon, 20 May 2019 at 10:53, Lars Knoll  wrote:
> [snip]
>> I’m not proposing to make QList inherit QVector. Actually, I’m making it an 
>> alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 
>> .
>>
>>
>> With that, one option could be to make the alias dependent on a compile time 
>> setting for the application code (ie. have a simple define whether we do
>>
>>
>> using QList = QVector
>>
>>
>> Or
>>
>>
>> using QList = Qt5Support::QList
>
> That would actually be painful for distros. Once we take either route
> we can't go back without breaking ABI. And we will possibly be
> choosing different things in each distro, which makes it even worst.
> Example: qreal in Qt5.
>
> I really think Marc Mutz's approach would be more sensible in this case.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Views

[Marco Bubke]

On 20/05/2019 23:11, André Pönitz wrote:
> On Mon, May 20, 2019 at 08:44:47PM +0000, Marco Bubke wrote:
>> On May 20, 2019 22:16:11 André Pönitz  wrote:
>>
>>> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
>>>> [...] There is no readability difference between the use of a Qt container 
>>>> and
>>>> that of an STL container.
>>>
>>> Exhibit A:
>>>
>>>  foo().contains(x)
>>>
>>>
>>> Exhibit B:
>>>
>>>  {
>>>  ... container = foo();
>>>  std::find(container.begin(), container.end(), x) != 
>>> container.end();
>>>  }
>>
>> AFAIK contains is now part of the STL.
> 
> Define "now"...
> 
>> But to show a pattern I see often with Qt container is the use of contains 
>> and
>> then access the element with a key again. I that case the STL with iterators
>> leads you to better performing code. Ranges hopefully make much of this code
>> even more readable and performant.
> 
> Performance is always a combination of "raw run-time performance" and "time to
> market".

Yes, it is an economic decision too but there is not only "time to 
market" but "stay in the market" too. So you have be careful with your 
investments but if you do not invest enough you will loose too.

> There's no point in saving 30 processor cycles a day, even for a million 
> users,
> if that takes one hour of developer time to implement in a desktop 
> application.
> 
> People who disagree wouldn't ever touch Java or JS or any interpreted 
> language.
> Or std::ostream for that matter.
> 
> You know as well as I do that e.g. QList is heavily used in e.g. the Qt 
> Creator
> code base, and that this is absolutely *no* performance problem. Sure, it's 
> not
> used in *really* time-critical parts, but for the 100%-\epsilon 
> non-exceptional
> stuff it's just "good enough".
> 

I would agree that we have not much performance problems because most 
containers use only few entries but I ran in some. What I want to say is 
that there are solutions to that problem. For example with ranges you 
get readability and performance in many cases but if you are not 
familiar with that patter it looks strange. Very often the first 
reaction is to reject something because it looks unfamiliar as 
unreadable. Yes it is as you encounter it the first time but maybe it 
will be more readable in the long run.

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

Re: [Development] Views

[Marco Bubke]

On May 20, 2019 22:16:11 André Pönitz  wrote:

> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
>> [...] There is no readability difference between the use of a Qt container 
>> and
>> that of an STL container.
>
> Exhibit A:
>
> foo().contains(x)
>
>
> Exhibit B:
>
> {
> ... container = foo();
> std::find(container.begin(), container.end(), x) != container.end();
> }

AFAIK contains is now part of the STL. But to show a pattern I see often with 
Qt container is the use of contains and then access the element with a key 
again. I that case the STL with iterators leads you to better performing code. 
Ranges hopefully make much of this code even more readable and performant.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Views

[Marco Bubke]

Thiago, you partially implying that BC is still needed but with technologies 
like flatpak or snappy this will maybe not common use case anymore. They 
provide even behaviour compatibility if you stay with the same runtime. 
Something which is not provided by binary compability. I personally think if 
the behaviour is changed it should not even compile anymore so you can fix it 
easily.

On May 17, 2019 17:08:28 Thiago Macieira  wrote:

> On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
>> > When you first design the class, sure. But 5 years later, you may have
>> > the
>> > data internally kept in a QMap or QHash, mapped to some other
>> > information. So
>> > your function that used to "return d->member;" now does
>> > "return d->member.keys();"
>>
>> Can you point out a Qt class where this was the case in the past?
>
> I'll have to look it up, but it has happened in the past and if not in Qt,
> then in one of the KDE libraries. The Library API Design Policy includes this
> particular point (don't return references) for a reason.
>
>> > Another case would be where you're keeping extra data in the internal
>> > structure and you need to filter that out before returning. Or the
>> > dual:
>> > augment with some implied data. The latter could be quite common if the
>> > class
>> > is not storing anything in the regular case, but synthesising it on
>> > demand for
>> > the benefit of the old API.
>>
>> This one is simple: Array of struct -> struct of arrays. Well-known
>> optimisation in the games industry.
>
> Sure, but if you returned a view of structs, how would you later make that
> view of structs work with your internally-stored struct of arrays?
>
>> > But only so long as each of those containers store lay the data out the
>> > same
>> > way in memory, which is not the case for my QMap example.
>>
>> You basically have a dichotomy: Either you have contiguous storage, in
>> which case you return pointers, or you have non-contiguous storage, in
>> which case you need some form of runtime-dispatch Iterator Pattern.
>
> Or you have a well-known storage pattern, in which case you don't return an
> array of pointers (which would need to be allocated anyway), but you return a
> means of finding those elements. That's what the containers do for you.
>
> So I don't have a problem returning a type that is cheap when you're designing
> the API, so long as you don't lock yourself into it if you later want to
> change. I don't see anything but actual containers here.
>
>> I don't think you'd ever come into a situation where you'd need to
>> switch from one to the other. If you think so, please provide an example
>> where this was necessary in the past.
>
> I'll look it up. Note that in hindsight all of those will look like bad
> design, but the point is that we didn't know any better when the design was
> first done.
>
>> > Two of your examples [QRegion, QGradient] basically return an internal
>> > structure, so I'm not seeing
>> > how they are relevant.
>>
>> How are they not relevant? Because the class basically _is_ a container?
>> Well, then see QAIM::roleNames(). Apart from the questionable design to
>> return a node-based associative container for the O(10) elements in
>> there, instead of a (view to a) sorted array of structs[1], it is a
>> prime example of how the API requires a particular implementation. I
>> don't remember whether it returns a QMap or a QHash, but either way, one
>> might want to return the other, down the road - or even depending on the
>> number of elements in the container, like QRegion does.
>
> I meant they are not good examples because they always return something that
> currently is stored in the d pointer. So there's no problem in changing them
> to return a view to that storage, since that storage does not go out of scope
> at function exit.
>
>> For an example of where roleNames() goes horribly wrong, see
>> QQmlListModel. Is has the data stored elsewhere and re-constructs a
>> QHash each time it's called. With a runtime iterator, it could probably
>> produce the values on the fly, and with a sorted array of {role, name}
>> it would allocate one block of memory per call, not O(n).
>
> I don't understand what you meant here. Are you advocating that the return
> type should have been different? What type would have helped?
>
> Or are you saying that if we had different tools internally, the
> implementation of QQmlListModel::roleNames could have been better?
>
> Either way, this is a very good example for why the return type mustn't be a
> reference or a non-owning container: the two sources for the function are not
> compatible with the return type.
>
>> > How would you implement this one with a view-based return?
>>
>> Glad you asked:
>>
>>  static constexpr QGradientStop defaultStops[] = {{0,
>> QColorLiterals::black}, {1, QColorLiterals::white}};
>>  return SomeView{std::begin(defaultStops), std::end(defaultStops)};
>>
>> Instead of the simple 

Re: [Development] A deployment tool for Linux

[Marco Bubke]

Sounds you want flatpak. ;-)

On April 10, 2019 21:43:31 Richard Weickelt  wrote:

>>> I, as a person, think that a "deployment tool for Linux" is
>>> something that spits out packages in half a dozen "native"
>>> distribution package formats.
>>
>> Nope, that tool is called "package maintainer" :)
>
> Blessed be those who have a "package maintainer". I don'ẗ think it's that
> easy. If I would want to bring my software product into the official
> distribution repositories, maybe and of course every open source project
> should aim for it. But that's quite some effort and sometimes even
> impossible. I would be interested to know how easy it is to release a
> Qt-based application with a bleeding edge Qt version (or with a patched one)
> to the official Debian repositories.
>
> And if I had a proprietary product and want to make updating as convenient
> as possible for my customers?
>
> Nothing stops me from publishing a self-containing .deb, .rpm, .whatever on
> my website. If there was a one stop shop tool that produces a collection
> like this with very little effort: https://speedcrunch.org/download.html I
> would be sold. Maybe even in combination with setting up my own package
> repos. But with very little manpower that can be cumbersome.
>
>>> Collecting "resources that the application uses (like [...]
>>> graphics, [...]" *and dependencies* would be a (important)
>>> step, but not all that it takes.
>>
>> By this logic windeployqt should produce .msi packages
>
> Wouldn't be the worst feature though, would it. That doesn't make Andre's
> comment less valid.
>
> Richard
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Looking for Feedback QDeferred

[Marco Bubke]

And don't let forget excutors: 
http://www.vollmann.ch/en/presentations/executors2018.pdf

They will be end in C++ and it would be nice to be fit in.

From: Development  on behalf of Denis 
Kormalev 
Sent: Monday, March 4, 2019 1:05 AM
To: Juan Gonzalez Burgos
Cc: development@qt-project.org
Subject: Re: [Development] Looking for Feedback QDeferred

Hi,

Sorry for the kinda late response, but you probably would also like to check 
https://github.com/dkormalev/asynqro for ideas about API improvements.

--
Regards,
Denis Kormalev

On Feb 12, 2019, at 1:38 AM, Juan Gonzalez Burgos 
mailto:juangbur...@gmail.com>> wrote:

Hi,

Looking at it with the “Qt Creator” hat on, i.e. with the mindset of “could we 
replace what we do in Qt Creator with our extension of QtConcurrent".
(http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/runextensions.h
 adds the convenience and actual runnable based around QFuture and 
QFutureInterface.)
I suppose this is a very UI-interaction focused, and high-level view on things 
;) but it is something that the QFuture/QFutureInterface/QFutureWatcher API 
supports.

Wow, first of all thanks for taking the time for this awesome feedback.
I guess the QFuture/QFutureWatcher design was driven by Qt's needs as I 
developed QDeferred for my very own needs. I suppose one just have to use the 
tool that best fits the problem.

1) I think the chaining/promises style is an improvement to the need to always 
use QFutureWatcher. We more often need to carry a QFutureWatcher member around 
than I like (even with a helper function Utils::onResultReady, the moment you 
need to handle various signals you’ll want to stick to a single QFutureWatcher)

Agree. There are use cases where QFutureWatcher is better.

2) We use QFuture/QFutureInterface for a generic progress UI. Basically you 
tell a central progress UI manager about your QFuture, and that shows a 
progress bar for it, including a cancel button.

What about multiple “subscribers” to a task? The progress UI needs to act on 
progress info, and finished / success status changes. On a glance I didn’t see 
if that is possible with your API.

Yes is possible to have multiple subscribers, thank you for pointing at it, I 
forgot to mention it explicitly in the readme. It is done as follows:

QDeferred defer = myMethod()
.done([](int val) {
})
.fail([](int val) {

});

// we can pass "defer" around since is a explicitly shared object
// ...

// subscribe elsewhere
defer
.done([](int val) {

})
.fail([](int val) {

});

And if the QDeferred was already resolved/rejected when a new subscription is 
done, then the callback is called inmediatly (depending on the connection-type, 
more on this later). I will add this to the document.

I didn’t see cancel functionality in your work, do you have thoughts on this?

I didn't think of this, haven't had the need but it is a great idea! I think it 
should not be too hard to implement. Maybe an API method called "cancel" and a 
callback called "cancelled" so we know when the process has actually been 
cancelled,

The implementation for progress seems to be a bit awkward in comparison to 
QFutureInterface, and doesn’t seem to be separate from the result type? 
Progress can be pretty separate from actual result producing, i.e. a file 
system search will be able to provide very fine grained progress information, 
but might only report a handful of results.

Yes and no, actually this was a hard decision for me. One main differentator 
with QDeferred is that there are N result types, so we could get around the 
issue as follows:

QDeferred defer = myMethod()
.progress([](QByteArray result, int progress, QString message) {
Q_UNUSED(result);
qDebug() << "Progress" << progress << "% , details :" << message;
})
.done([](QByteArray result, int progress, QString message) {
Q_UNUSED(progress, message);
// do something with the QByteArray results
});

The fact that you have N result types does not mean you have to use all of them 
in every callback. You could use some of them for progress info and some others 
for results. I know this might come as "akward", but what actually constitute a 
"progress"? At some point I though of adding a specialized  or  
API for the progress but decided not to because it would be limiting. E.g. one 
of my use cases was to bring large chunks of historic data from a server, and 
the "progress" for that use case was partial data blocks which I could 
inmediatly display in a chart as they arrived, so one of my return types was a 
reference to that partial data block which I only used in the progress 
callback. Maybe there is a better way to achieve this, but I couldn't find one 
that met all my needs.

Another thing that QtConcurrent handles for us, it to guard against “too much 
progress reporting”. I.e. if a loop from 1 to 100 reports every single step 
as progress, this would block the UI/main thread with progress updating. 
QtConcurrent makes 

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

[Marco Bubke]

+2

On February 8, 2019 11:12:25 Christian Kandeler  
wrote:

> On Thu, 7 Feb 2019 16:03:30 +
> Volker Hilsheimer  wrote:
>
>> Thoughts, ideas, and pointers to other frameworks that you believe provide a 
>> good API are welcome here in this email thread before moving to a dedicated 
>> JIRA ticket.
>
> My personal pet peeve: Please, let's never again use the term "file name" 
> when we actually mean a file path.
>
>
> Christian
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Marco Bubke]

I am not sure it would be a good idea because a glyph can be still composed of 
more than one code points which is language dependent. Some time you want 
characters, sometimes code points and sometimes glyphs etc.. Would it be not 
better to use a simple container and then functions on top which use a view, so 
we could use them with any container. So we would avoid any allocations for 
transforming characters from one to the other container. But anyway I think 
there are many usages for strings that one class to tackle all this problems is 
not enough.


From: Development  on behalf of Edward 
Welbourne 
Sent: Wednesday, January 23, 2019 2:53:00 PM
To: Arnaud Clère; Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString

All of this discussion ignores a major elephant: QString's indexing is
by 16-bit UTF-16 tokens, not by Unicode characters.  We've had Unicode
for a couple of decades now.

We *should* have a string type (I don't care what you call it) that acts
on strings indexed by Unicode characters, not in terms of a
representation.  Whether that string type internally uses UTF-16 or
UTF-8 should be invisible to its user.  Ideally it would be capable of
carrying its data internally in either form (so as to avoid needless
conversion when both producer and consumer use the same form) and of
converting between the two (e.g. so as to append efficiently) as needed.

Meanwhile, buffers of data (whether 8-bit, 16-bit or of other sizes) are
types we do need in diverse places - but they should be described
differently from the sting type (call it a "text" type, if hysterical
reasons oblige us to use "string" for its encoding).  They can be
interpreted as strings, hence can serve as backing-store for a string,
provided they respect the relevant rules of a relevant encoding.

If blob[index] always returns a Unicode *character*, then blob is a
string; if it can sometimes return one half of a UTF-16 surrogate pair
(as is the case with QString today) or one byte of a multi-byte UTF-8
chunk, then blob is not really a string, it's just the storage for an
encoding of a string.

What are our chances of getting this right in Qt 6 ?
It's the 21st century - way past time we did this,

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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Marco Bubke]

You can use std::string which as small string optimization instead of 
QByteArray too. In many cases where you would use const String  you can use 
std::string_view, so you are more flexible.


From: Development  on behalf of Allan 
Sandfeld Jensen 
Sent: Tuesday, January 15, 2019 10:44:45 PM
To: development@qt-project.org
Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString

On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote:
> Hi,
>
> With every Qt release we see how the new release improved over previous
> releases in terms of speed, memory consumption, etc.
>
> Any chance of having UTF-8 storage support for QString?
>
Use QByteArray when you can.

Regards
'Allan


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

Re: [Development] QUIP 12: Code of Conduct

[Marco Bubke]

Hallo Jason


> It was purely about lines of code. It was elegant and beautiful, and brutally 
> simple.


This is aesthetics and if you would reflect about it with other you could find 
out that is very context sensitive.


My experience in this area is that their are many people who prefer interaction 
with computer to interaction with different people.  Many people use a 
platonic language all the time without any reflection about the problems of 
that language. And this is creating friction, much friction, and not the kind 
of productive friction. Is it not nice to understand if other people have a 
different aesthetic view of how code should look?


It's my experience which is shaping my context. And I believe it's the same for 
you. So I think that our context is different. So if we work together should we 
not respect different contexts and try to understand them. Use that difference 
to create something better. Is that not better than connect our work with our 
self and let discussion easily get highly emotional? What do you think is the 
outcome of this culture? I don't believe that this highly emotional, sometimes 
rude, culture is creating the best source code! I think it is driving many 
talented people away.


Best, Marco


From: Development  on 
behalf of Jason H 
Sent: Wednesday, October 24, 2018 5:09:58 PM
To: Ulf Hermann
Cc: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone 
following the shit-show that is the Linux kernel code of conduct fiasco, I also 
think would be against the code of conduct as well.

Immediately after imposing the Code of Conduct, past tweets by contributors and 
the accusations started flying and it devolved from there. In addition to 
several authorities on Open Source weighed in that yes, contributors can revoke 
the copyright of their prior contributions, which was threatened by those 
accused. Which would leave any software in a lurch. Now, it looks like those 
contributors might go to BSD...

Having been interested in software from a very young age, and later 
specifically Open Source, one thing that appealed to me was that it was a 
meritocracy. The best code survives, your code contributions are limited only 
by your code being the best. Now we're saying it's not just your code, but also 
your behavior. We had an ideal, we had THE ideal - a place where only our ideas 
mattered. A place where nothing else mattered - not your gentatilia, your 
sexual identity, not your partner preference, not your political party - none 
of it. It was purely about lines of code. It was elegant and beautiful, and 
brutally simple. And now the social justice warriors are contaminating that 
perfection with code+conduct. So it goes from "this is the best code that could 
be written" to "this is the best code that could be written from an individual 
whose political ideals match our own".

If we adopt this, does that mean there is a  [git commit hook| gerrit review] 
installed that evaluates the contributor's social media to find controversial 
posts?
If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation 
(She's racist against white people, but the New York Times says that's "ok")?
- How do assure that white people are adequately protected against reverse 
racism?
-- Do we even agree that reverse racism [is possible to] exist(s)
If we adopt this, what exactly are the political ideas a Qt contributor must 
espouse?
- Are stances against illegal immigration "racist"?
- Is "Sceintific racism" actual racism or just statistics?
-- In a matter closer to home, where are we on James Damore situation? Would he 
be banned from this community?

NONE of those questions should need to be contemplated by an Open Source 
software project. Open Source is about the Source. Not the source of the Source.

In case it needs to be said-
I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. 
But I am also against people judging other people's code for factors that have 
nothing to do with the code itself. I find that adding a value judgement of 
conduct to code to be intolerant. We had the ideal.
I am FOR inclusion. I want everyone to feel welcome here. Everyone.

We might identify as a "community" as we are people, but really we're an open 
source project, and at the end of the day what matters the most is what is in 
git.

I oppose any Code of Conduct. And demand the answers be provided to the above 
questions PRIOR to passage (if it happens).

I really want to know where we are with James Damore because I thought his 
paper was well-researched with a scientific basis?



> Sent: Wednesday, October 24, 2018 at 3:17 AM
> From: "Ulf Hermann" 
> To: "development@qt-project.org" 
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well 

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

[Marco Bubke]

Enumerations inside of classes makes dependency breaking harder. We don't use 
that in Qt but users of our interface may do. It's still possible but much more 
complex because you generally get much more dependencies. A simple header file 
for enumerations instead can simply be included without any additional 
dependencies.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2018: Third-party and security policy

[EXT Marco Bubke]

On June 9, 2018 04:10:58 Thiago Macieira  wrote:

> There's a session scheduled for Monday (unless it gets moved). Here's what I
> will propose.
>
> 0) Where not really necessary, delete the third-party code and force the use
> of a system library (see assimp discussion, can be applied to qtimageformats
> too).
>
> 1) Third-party bundled should be opt-in, not opt-out. That is, the system
> library always takes precedence, if found.

This is really problematic in the Sqlite case as an embedded library. An 
embedded library is meant to be customized to an application. Actually this 
whole process looks like it is customized to an server based world and much 
less to an embedded world.

So what about some embedded scenario. What is a system library in that sense. 
If people ship their own binary it's not part of Qt anymore. So it's their 
problem but for the user it's still a problem and by a high probability you 
introduced an out dated library. Would it not be better to ship it as part of 
Qt in that context to make the life of the embedded developer easier?

> 2) Qt Project sources always ship the latest third-party sources available one
> week before the Qt release. The grace period is just so that we can release
> the RC that passed QA. Every feature release receives updates to the latest
> and greatest upstream; every patch release receives updates in the same patch-
> series by upstream, if such exists. Release Management will put this as a P1
> requirement for the release, like the changelog, header check, BC check, etc.
>
> 3) Qt Project sources receive a patch for a security fix in a library that
> cannot be built as a system library. That's the case of the bundled FreeBSD
> sources or TinyCBOR or right now with Qt Creator's sqlite. We do this within
> one week of the fix, even if it is high Summer in Finland. All releases after
> this point will contain the patched version.

That is a security fix? If there is an securifix for Sqlite but this not 
applicable for Qt Creator, should any action be taken? Actually it is hard to 
imagine any security related problem in this context. We should follow here a 
reasonable instead of a fundamental approach. In that sense we should 
distinguish between different Qt Project software packages.

>
> 4) No patches are necessarily issued for fixes to libraries that can be used
> as system libraries. But all releases from that point on will be patched.
>
> 5) Qt Project binaries containing third-party code are re-released every time
> the code has a fix for a CVE that isn't in what we're shipping. We do this
> within one week of the fix, same conditions. Note this applies to the
> "gnuwin32" dir in qt5.git too.
>
> 6) Each third-party bundled library must have an official maintainer and one
> deputy who know how to update it and are tracking that library's security
> advisories. They'll both be added to the Qt Security Team. They have to inform
> the Security Team if they are going to be completely unavailable for more than
> a week. If both are going to be unavailable, they need to ensure there's
> someone who is tracking the library.
> Corollary: existing code that cannot meet this requirement will be
> deleted from the Qt Project sources.
>
> I know this is harsh, but I think it's necessary. Let's discuss on Monday to
> see if there's any solution I've missed.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Marco Bubke]

The Sqlite module is not a plugin but a library. It is linked to a plugin but 
this plugin is not build in release and normally disabled.
Like I said, it can be simply not build for release. Please stick to KISS.

On June 8, 2018 16:30:19 Edward Welbourne  wrote:

> Marco Bubke (7 June 2018 19:37) wrote:
>> AFAIK the refactoring plugin is disabled for release. Just do the same for 
>> the Sqlite library.
>
> Probably better to do as Thiago said:
>
> On June 7, 2018 23:54:43 Thiago Macieira  wrote:
>>> So we just need a conditional to disable the building if the refactoring
>>> plugin isn't enabled either.
>
> or, perhaps more to the point, only enable building of the sqlite plugin
> if (it's explicitly wanted or) something that needs it is enabled,
>
> Eddy.

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

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Marco Bubke]

AFAIK the refactoring plugin is disabled for release. Just do the same for the 
Sqlite library.

On June 7, 2018 23:54:43 Thiago Macieira  wrote:

> On Thursday, 7 June 2018 06:56:11 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> El jueves, 7 de junio de 2018 07:17:10 -03 Marco Bubke escribió:
>> > It is used buy the Clang refactoring plugin, which is not build by
>> > default.
>>
>> But we are still building sqlite3.c by default.
>
> So we just need a conditional to disable the building if the refactoring
> plugin isn't enabled either.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Marco Bubke]

It is used buy the Clang refactoring plugin, which is not build by default. So 
I see no urgency in it except it will break it. Let's discuss it if I am back.

On June 7, 2018 15:06:57 Thiago Macieira  wrote:

> On Wednesday, 6 June 2018 23:52:35 PDT Marco Bubke wrote:
>> Hi
>>
>> I am on vacation till end of July, I am looking forward to discuss it in
>> August.
>
> Sure. Meanwhile, can we apply Lisandro's patch?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

[Marco Bubke]

Hi

I am on vacation till end of July, I am looking forward to discuss it in August.

Best regards, Marco

On June 7, 2018 11:13:24 Thiago Macieira  wrote:

> On Wednesday, 6 June 2018 19:57:55 PDT Thiago Macieira wrote:
>> On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer
>>
>> wrote:
>> >  - Is it worth the trade off considering it makes finding security bugs
>> >  more
>> >
>> > complicated?
>>
>> We're not supposed to find or fix sqlite security issues. We get them from
>> upstream and upstream supports the single-file build style.
>
> Actually, this is a very important subject, so I just added a session to the
> QtCS program next week to discuss it.
>
> As you may be aware, Intel is taking security VERY seriously and I cannot
> accept a project I contribute to having any worse policies. Our open source
> security team also evaluates each project's security policies and they have
> blacklisted quite a few open source projects from being used in Intel
> products, so I'd like to make sure Qt continues to comply with the stricter
> guidelines.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
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

[Marco Bubke]

I was ask to provide more info about the crash dump server. It is called 
Socorro:

https://github.com/mozilla-services/socorro


<https://github.com/mozilla-services/socorro>

Like you can see it was developed originally for Firefox:

https://crash-stats.mozilla.com/topcrashers/?product=Firefox=58.0.2
<https://github.com/mozilla-services/socorro>


There are many statistics about crashes and the stack trace which is very 
helpful

for the developer to prioritize bug reports and fix crashes. We already have 
client support for

that in Qt Creator but we need a server instance where we can send the crash 
dumps.



From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on 
behalf of Marco Bubke <marco.bu...@qt.io>
Sent: Monday, February 26, 2018 6:29:22 PM
To: Edward Welbourne; Robert Loehning; André Pönitz
Cc: development@qt-project.org; Ryein Goddard; qt-crea...@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator

Edward Welbourne:

> When you look into the feature that no-one uses much, you may find that most 
> users
> that do use it have a crash report following close on the heels of their
> use of it; you can make an educated guess at why they don't use it after that.


We have already a crash reporter, which would provide us with that information.

I am pushing this since some time but we need a server installation. Sorry, 
with my

current experience I don't think that we need something much more complicated 
and

fuzzy if we don't get something simple like a crash handler working. And I only

speak about a customization of an already existing server and setting up the VM.

I have that done very long ago but nobody stepped in to productise it.


So I don't believe that we can fly to the stars if we cannot fly to the moon,

but it is much easier to dream about the stars than to go to the moon. 


From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on 
behalf of Edward Welbourne <edward.welbou...@qt.io>
Sent: Monday, February 26, 2018 6:06:08 PM
To: Robert Loehning; André Pönitz
Cc: development@qt-project.org; qt-crea...@qt-project.org; Ryein Goddard
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator

Am 23.02.2018 um 11:54 schrieb Edward Welbourne:
>> The proposed system provides anonymised and presumably aggregated
>> data; so you won't be given, much less asked to evaluate, information
>> about a specific user A doing things at a specific time B; your
>> objection is a straw man.  You'd be getting data on what proportion
>> of users spend what proportions of their time doing which things.  In
>> particular, knowing which bugs bite most users most often might not
>> be entirely useless when it comes to prioritising which bug to fix
>> first.

Robert Loehning (23 February 2018 15:59)
> If many users spend much time doing a "thing", does that mean that
> this is most important to them? Or that it is most fun to do? Or does
> it just mean that the design is so bad that they lose lots of time
> there and can't use it efficiently?

You don't necessarily know - but you do at least know it sees a lot of
use, as distinct from the things that no-one uses.  That, in turn, might
be because the thing doesn't work, or is too confusing; or it might mean
it does a thing no-one feels any need to do.  However, you have now
separated two classes of feature from one another: you won't waste time
asking users why they never use the heavily-used feature; and you won't
assume that users know how to use the feature you know none of them use.

You'll have more information along with just "what proportion use which
features what proportions of the time"; some of this may help you to
distinguish between the various possible explanations.  When you look
into the feature that no-one uses much, you may find that most users
that do use it have a crash report following close on the heels of their
use of it; you can make an educated guess at why they don't use it after
that.  For another feature, users may methodically work their way
through the steps your tutoral for the feature outlined and never touch
it again; it's probagly useless.

You won't be throwing away your other ways of getting information from
users; you can ask them, in all the usual ways, what they like best and
what ticks them off about each feature.  That's quite likely to
distinguish, among the ones that are commonly used, the ones that are
fun from the ones that are time-consuming pain points.

Data on how your users use your product can contribute to your
understanding of what questions to ask your users and what work to
prioritise.  Like all data, of course, you have to use it intelligently
to get actionable inform

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

[Marco Bubke]

Edward Welbourne:

> When you look into the feature that no-one uses much, you may find that most 
> users
> that do use it have a crash report following close on the heels of their
> use of it; you can make an educated guess at why they don't use it after that.


We have already a crash reporter, which would provide us with that information.

I am pushing this since some time but we need a server installation. Sorry, 
with my

current experience I don't think that we need something much more complicated 
and

fuzzy if we don't get something simple like a crash handler working. And I only

speak about a customization of an already existing server and setting up the VM.

I have that done very long ago but nobody stepped in to productise it.


So I don't believe that we can fly to the stars if we cannot fly to the moon,

but it is much easier to dream about the stars than to go to the moon. 


From: Development  on 
behalf of Edward Welbourne 
Sent: Monday, February 26, 2018 6:06:08 PM
To: Robert Loehning; André Pönitz
Cc: development@qt-project.org; qt-crea...@qt-project.org; Ryein Goddard
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator

Am 23.02.2018 um 11:54 schrieb Edward Welbourne:
>> The proposed system provides anonymised and presumably aggregated
>> data; so you won't be given, much less asked to evaluate, information
>> about a specific user A doing things at a specific time B; your
>> objection is a straw man.  You'd be getting data on what proportion
>> of users spend what proportions of their time doing which things.  In
>> particular, knowing which bugs bite most users most often might not
>> be entirely useless when it comes to prioritising which bug to fix
>> first.

Robert Loehning (23 February 2018 15:59)
> If many users spend much time doing a "thing", does that mean that
> this is most important to them? Or that it is most fun to do? Or does
> it just mean that the design is so bad that they lose lots of time
> there and can't use it efficiently?

You don't necessarily know - but you do at least know it sees a lot of
use, as distinct from the things that no-one uses.  That, in turn, might
be because the thing doesn't work, or is too confusing; or it might mean
it does a thing no-one feels any need to do.  However, you have now
separated two classes of feature from one another: you won't waste time
asking users why they never use the heavily-used feature; and you won't
assume that users know how to use the feature you know none of them use.

You'll have more information along with just "what proportion use which
features what proportions of the time"; some of this may help you to
distinguish between the various possible explanations.  When you look
into the feature that no-one uses much, you may find that most users
that do use it have a crash report following close on the heels of their
use of it; you can make an educated guess at why they don't use it after
that.  For another feature, users may methodically work their way
through the steps your tutoral for the feature outlined and never touch
it again; it's probagly useless.

You won't be throwing away your other ways of getting information from
users; you can ask them, in all the usual ways, what they like best and
what ticks them off about each feature.  That's quite likely to
distinguish, among the ones that are commonly used, the ones that are
fun from the ones that are time-consuming pain points.

Data on how your users use your product can contribute to your
understanding of what questions to ask your users and what work to
prioritise.  Like all data, of course, you have to use it intelligently
to get actionable information out of it; the possibility that you might
misunderstand it doesn't mean it's worthless; it *supplements* the other
sources of insight into how best to use your time, it doesn't replace
them.

All of which, of course, does depend on taking care that the process of
collecting the data does not, in itself, cause greater harm than the
benefits that you can glean from using the information, once collected,

Eddy.
___
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-creator] Requesting repository for telemetry plugin in Qt Creator

[Marco Bubke]

It would be nice if you can explain what data you want to collect and how it 
will be help the creator development. In my view it is quite hard to collect 
data about not implemented features, so you could only provide information 
about what feature is used. So the data could be used to see what should be 
polished. But could this not lead to false impression because people don't use 
a 'very useful' features because the implementation is 'suboptimal'. Would in 
that case not JIRA a much better source of information?


From: Qt-creator  on 
behalf of Tino Pyssysalo 
Sent: Thursday, February 22, 2018 2:58:55 PM
To: Simon Hausmann; Tuukka Turunen; qt-crea...@qt-project.org; 
development@qt-project.org
Subject: Re: [Qt-creator] [Development] Requesting repository for telemetry 
plugin in Qt Creator


Hi,



The idea is to develop a generic library/plugin, which anyone could use for 
analytics. The backend can be any storage and The Qt Company does not provide 
that.



We plan to use the same backend, which we already use in online installers to 
collect statistics about installations. At least in case of Qt Creator, the 
plan is to make some analysis results available for the community. Obviously, 
we do not do that for our commercial tooling.



Analytics is opt-in and disabled by default in Qt Creator. We plan to ask user 
in the installer, if the user wish to participate in Qt UX improvement. If the 
answers is no, the analytics plugin is never installed.  When the creator is 
started for the first time, it will show a dialog, consisting a list of 
collected data items and an option to enable/disable the plugin. There will be 
a new output pane, which shows collected data, conversions methods, if any 
used, and transmitted data to the user.

--

Tino





On 22/02/2018, 15.26, "Simon Hausmann" 
> wrote:



Hi,



Can you provide a bit more information about how this plugin / frontend fits 
into the Qt project? Where is the collected data sent to and how is it 
accessible to the community?



(-1 from me, as I think this needs to be clarified)



Simon



From: Development  on 
behalf of Tuukka Turunen 
Sent: Thursday, February 22, 2018 2:14:14 PM
To: Tino Pyssysalo; qt-crea...@qt-project.org; development@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator





Hi,



+1 for creating the repo, but what about qt/qtanalytics as a name? This item 
could be useful also for other applications.



Yours,



 Tuukka



From: Qt-creator  on 
behalf of Tino Pyssysalo 
Date: Thursday, 22 February 2018 at 13.04
To: "qt-crea...@qt-project.org" 
Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator



Description:



Telemetry plugin (frontend) to collect usage data from Qt Creator to help 
improving Qt, Qt features, and Qt tools.

Non-personal data items, such as duration the user spent in design mode, will 
be collected in a way, which is completely transparent to the user.



Responsible: Tino Pyssysalo



Repository: qt-creator/plugin-telemetry





---

Tino Pyssysalo

Senior Manager



The Qt Company

Hämeenkatu 14 C 25

33100 Tampere, Finland

tino.pyssys...@qt.io

+358 40 8615475

http://qt.io



The future is Written with Qt

---




___
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

[Marco Bubke]

> Well, there are things that are hard to report via survey, e.g. rate of 
> crashes or memory leaking in clangbackend


We have a crash handler in the works, which is much more useful than this. And 
memory leaks can simply be investigated simply by debugging. I don't see how 
this plugin could help here. Anyway, we disabled the crash recovery already, so 
most memory leaks should be gone.


From: Development  on 
behalf of Konstantin Tokarev 
Sent: Thursday, February 22, 2018 2:42:55 PM
To: Ryein Goddard; Simon Hausmann
Cc: development@qt-project.org; qt-crea...@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator



22.02.2018, 16:39, "Ryein Goddard" :
> This might be nice to make pretty charts to show to managers, but to be 
> completely honest I think it is 100% useless.  If you don't know what people 
> are using your software for, or how then you aren't communicating with them.  
> You know once upon a time companies just talked with people to figure out 
> what they wanted and what they were having difficulties with.  Why not just 
> take a few surveys a year?

Well, there are things that are hard to report via survey, e.g. rate of crashes 
or memory leaking in clangbackend

>
> On 02/22/2018 08:26 AM, Simon Hausmann wrote:
>> Hi,
>>
>> Can you provide a bit more information about how this plugin / frontend fits 
>> into the Qt project? Where is the collected data sent to and how is it 
>> accessible to the community?
>>
>> (-1 from me, as I think this needs to be clarified)
>>
>> Simon
>> 
>> From: Development  
>> on behalf of Tuukka Turunen 
>> Sent: Thursday, February 22, 2018 2:14:14 PM
>> To: Tino Pyssysalo; qt-crea...@qt-project.org; development@qt-project.org
>> Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
>> plugin in Qt Creator
>>
>> Hi,
>>
>> +1 for creating the repo, but what about qt/qtanalytics as a name? This item 
>> could be useful also for other applications.
>>
>> Yours,
>>
>>  Tuukka
>>
>> From: Qt-creator  on 
>> behalf of Tino Pyssysalo 
>> Date: Thursday, 22 February 2018 at 13.04
>> To: "qt-crea...@qt-project.org" 
>> Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt 
>> Creator
>>
>> Description:
>>
>> Telemetry plugin (frontend) to collect usage data from Qt Creator to help 
>> improving Qt, Qt features, and Qt tools.
>>
>> Non-personal data items, such as duration the user spent in design mode, 
>> will be collected in a way, which is completely transparent to the user.
>>
>> Responsible: Tino Pyssysalo
>>
>> Repository: qt-creator/plugin-telemetry
>>
>> ---
>>
>> Tino Pyssysalo
>>
>> Senior Manager
>>
>> The Qt Company
>>
>> Hämeenkatu 14 C 25
>>
>> 33100 Tampere, Finland
>>
>> tino.pyssys...@qt.io
>>
>> +358 40 8615475
>>
>> http://qt.io
>>
>> The future is Written with Qt
>>
>> ---
>>
>> ___ Qt-creator mailing list 
>> qt-crea...@qt-project.org 
>> http://lists.qt-project.org/mailman/listinfo/qt-creator
> ,
>
> ___
> Qt-creator mailing list
> qt-crea...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator


--
Regards,
Konstantin
___
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] Setters: Clarifying the ownership

[Marco Bubke]

Using a standard from the Cpp Core Guidelines will have the advantage of better 
tooling support. And please don't use the preprocessor, it will down slow the 
refactoring or makes it impossible.


From: Development  on 
behalf of Eric Lemanisser 
Sent: Saturday, January 20, 2018 9:17:43 AM
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] Setters: Clarifying the ownership

Please use an already existing solution to this problem : 
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-raw
Errors will be caught by the compiler in case of std::unique_ptr, and by static 
analysers (like clang-tidy) for gsl::owner, without run-time cost.
There was already an attempt to use gsl::owner 
https://codereview.qt-project.org/#/c/178107/ but it did not go forward, 
because of lack of time ?

Le ven. 19 janv. 2018 à 19:33, Thiago Macieira 
> a écrit :
On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote:
> Jaroslaw Kobus (19 January 2018 17:09)
>
> > "give" may be confused with "get", which is usually an accessor. I may
> > also think "Am I giving (to QCoreApplication)" or "The
> > QCoreApplication is giving (me)". Maybe it is just a matter of the
> > other verb? Absorb, hand over, hand on, suck in, swallow...
>
> However, we have plenty of take functions, where the caller takes
> ownership from the object on which the method is called; so it makes
> sense that a give function would be the caller giving ownership to the
> object on wich the method is called.
>
> Thus we'd keep child.setParent(newParent), since the child doesn't take
> ownership of the parent; but QMainWindow's setCentralWidget() would
> become giveCentralWidget(), matching its takeCentralWidget().  This
> would save the search for its doc, to find that it does indeed take
> ownership.
>
> The signature is, in any case, always sufficient to make clear that a
> give()r isn't a get()ter.

Let's stop the discussion about method *naming* right here. We're not going to
change hundreds of getters and setters now or even in Qt 6.

Let's instead find a solution that either uses macros or uses simple binary-
compatible pointer wrappers like GST.

And be careful with template functions. Changing from T to Something may
change what gets deduced.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

[Development] Nominating Ivan Donchevskii for approver

[Marco Bubke]

I'd like to nominate Ivan Donchevskii for Approver.


He is working since spring at the C++ support of Qt Creator. Since then

his changes made a strong impact to the C++ support. He worked on the Clang

integration for Qt Creator, Clang itself, improved the static analyses,  
polished

the Windows experience of the C++ support and integrated Clazy and Clang Tidy.


These are his contributions:

https://codereview.qt-project.org/#/q/owner:%22Ivan+Donchevskii%22,n,z
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

[Marco Bubke]

I think many users see a beta as something you better not touch, but a release 
candidates can be trusted much more. I know it's not intended that way but 
people learned by experiences. [?]


Maybe "pre release" or "preview" could be a name to show the final status?




From: Development  on 
behalf of Thiago Macieira 
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process

Em ter?a-feira, 20 de dezembro de 2016, ?s 13:34:39 BRST, Tuukka Turunen
escreveu:
> If desired, we could use some other name than "Release Candidate 1" for the
> release that begins the last phase of the release. It could be called "Beta
> 2" or "Technology preview", if so desired. Personally, I would call it
> "Release Candidate 1".
>
> The difference to our current process is quite small. In essence it would be
> about considering the "RC1" the beginning of the final releasing phase (.0
> branch), not something we do almost at the end of it. I believe that
> lowering the quality criterial for "RC1" helps us in being more efficient
> as it has been in practice impossible to really fulfill the current process
> goal and have already the first RC as good as the final.

I like the process, but I would also rename the release like you proposed. We
can't have something called "release candidate" when we *know* it's not a
candidate. Let's call it beta 2, beta 3, etc. until we can make it a release.

Release candidates are really the snapshots that the release team creates when
we're testing for sanity right before the actual release.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
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?

[Marco Bubke]

So you are writing a style for the QPaintEngine. What if you have a OpenGL back 
end or some other back ends where your descriptions does not fit that well any 
more? I have seen much more complicated things written in an abstract way, so 
it should be possible. And I haven't said that you should use CSS. Some custom  
DSL would quite handy. Actually I don't care about that fancy styles, they 
looks too baroque to me but I want something like Flatpak so I don't have work 
with outdated packages! But that are my priorities. [?]


From: Matthew Woehlke <mwoehlke.fl...@gmail.com>
Sent: Thursday, November 24, 2016 5:36:04 PM
To: development@qt-project.org
Cc: Marco Bubke
Subject: Re: Basing Qt Creator Coding Style on C++ Core Guidelines?

On 2016-11-22 06:25, Marco Bubke wrote:
> On November 22, 2016 08:17:57 Thiago Macieira wrote:
>> Theming and styling is a complex operation. It's not just "propagating
>> values". Reading config files will at best get you the right font, correct 
>> icon
>> set, and somewhat correct colours. But gradients, shapes, complex dialogs 
>> will
>> not work.
>
> I don't see the problem to describe it in text, like CSS is doing.

Clearly you have never actually written a QStyle. Something like Oxygen
involves *multiple* gradients just for the window background. Don't
forget inline SVG's for elements like the tree expanders and the 'icons'
on scroll bar buttons, combo boxes, spin boxes... and that's not even
the *hard* stuff.

Try specifying a tab bar in CSS. You have text margins, margins between
the tabs, possible complex shapes of the tabs themselves (all of which
need complicated gradients for shading)... The current version of the
Oxygen style (well, the KDE4 version anyway) represents *years* of work,
and even then I would not say it is perfect.

Take a look at
http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif and
explain to me how to replicate that in CSS. Start with the scroll bar
handle. *Then* I will believe you when you say there is no problem
describing widget style in CSS.

That said, there *is* a textual language that can be used to adequately
describe a style. That language is commonly known as "C++".

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

[Development] Summary ABI compabilty

[Marco Bubke]

Hi


I try to gather all arguments so they don't get lost:


Short Term ABI compability(1-2 years):


* better bug fixing

* faster development

* faster adoption of standards

  - con: we don't want to adapt them because our solution is better


Long Term ABI compability(5-10 years):


* easier life of Linux packager

  - con: you can use Flatpack in many case (disputed)


I think I miss some but feel free to extend the list

___
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?

[Marco Bubke]

On November 22, 2016 08:17:57 Thiago Macieira <thiago.macie...@intel.com> wrote:

> On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote:
>> So you say it it does not work because of themeing support? Isn't Qt
>> Controls 2 not anymore providing them too. And is there no technical
>> solutions for that? Like propagating the values to the Flatpack themeing
>> engine. This could be improve the interoperability between different
>> desktop libraries too. The implementation which is based on GTK or Qt is
>> suboptimal anyway. It shows visually why Linux Desktop was never widely
>> adopted. I mean the lack of cooperation and the hesitancy to try to
>> understand the context of the other. I use Linux all the day, but honestly
>> many things are broken, especially where Unix wasn't copied.
>
> So you're saying we need to develop another GUI toolkit for Linux desktops so 
> that we can share some common things between the existing toolkits?
>
> This comes to mind: https://xkcd.com/927/
>
> Theming and styling is a complex operation. It's not just "propagating 
> values". Reading config files will at best get you the right font, correct 
> icon 
> set, and somewhat correct colours. But gradients, shapes, complex dialogs 
> will 
> not work.

I don't see the problem to describe it in text, like CSS is doing. Actually it 
has the advantage to be independent of drawing systems. If you code it in C++ 
it is hard to translate that to OpenGL etc. 

> And I don't see anyone volunteering for a major overhaul of QtWidget's 
> styling 
> system. I don't even think a volunteer would be *accepted* by the Qt Project. 

Why do you can not write a QStyle whicj is bridging it? 

> So, no, there is no solution. Qt applications in a flatpak or similar will 
> not 
> look or feel native, therefore it is not an acceptable solution for an 
> application of regular use.

Come on,  it is mostly broken for me already today. If you mix different 
toolkits it is not working that well. Mix High DPI in it and it gets worse. 
Linux Desktop is already in a ugly shape,  I don't see how it get worse with 
it. 

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
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?

[Marco Bubke]

On November 22, 2016 00:47:26 Thiago Macieira <thiago.macie...@intel.com> wrote:

> On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote:
>> I strongly agree with Andre'. And is a BC break in the time of flat pack
>> that bad? As an user I really looking forward to flat pack,  so I can
>> update my heavily used Applications and being not dependent on
>> distribution. This package could be much better optimize with LTO and
>> profile guided optimization. Maybe sharing everything is not that smart
>> anymore.
>
> FlatPaks don't work for Qt.
>
> Reasons:
>
> /usr/lib64/qt5/plugins/styles/breeze.so
> /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
>
> If you include Qt in your flatpak or equivalent, then your Qt application 
> will 
> not load the system plugins and will thus not have native look and feel in a 
> Plasma desktop or in LXQt.

So you say it it does not work because of themeing support? Isn't Qt Controls 2 
not anymore providing them too. And is there no technical solutions for that? 
Like propagating the values to the Flatpack themeing engine. This could be 
improve the interoperability between different desktop libraries too. The 
implementation which is based on GTK or Qt is suboptimal anyway. It shows 
visually why Linux Desktop was never widely adopted. I mean the lack of 
cooperation and the hesitancy to try to understand the context of the other. I 
use Linux all the day, but honestly many things are broken, especially where 
Unix wasn't copied.


> If you don't include Qt or if the included Qt loads plugins, then BC is 
> required.
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
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?

[Marco Bubke]

On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer 
<perezme...@gmail.com> wrote:

> On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
> [snip] 
>> And how many applications are Qt only and use no standard lib anyway? Are
>> there any numbers?
>
> Good question, I wonder if there is a way to dig that.
>
>> Yes, sometimes they are inlined but sometimes they are
>> not. Is it really a so big burden for you? 
>
> Yes, as I described in a previous mail. Thiago got a nice word there: 
> bottleneck. It's a heck of a bottle neck.
>
>> And what are you doing about
>> GTK? To my knowledge their BC is quite limit.
>
> I guess GTK maintainers suffer, specially with the last changes they 
> announced 
> some time ago about breaking API/ABI (sorry, I don't remember exactly which 
> one) in some minor releases. Incindentally the first thing we Qt maintainers 
> though about those changes is how lucky we are to have such a string-minded 
> upstream that guarantess ABI during the life of a major version.

So GTK maintainers can do it. There are much more applications on my Linux 
Desktop so it is possible. And like Linus Torvalds has said,  it is 
questionable to provide a package for every application on Earth. Flatpack is a 
much more reasonable choise for the developer and the user. 


> -- 
> Bebe a bordo (pero con moderación)
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
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?

[Marco Bubke]

On November 22, 2016 02:10:50 Thiago Macieira  wrote:

> On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor 
> Pérez Meyer wrote:
>> I guess GTK maintainers suffer, specially with the last changes they
>> announced some time ago about breaking API/ABI (sorry, I don't remember
>> exactly which one) in some minor releases. Incindentally the first thing we
>> Qt maintainers though about those changes is how lucky we are to have such
>> a string-minded upstream that guarantess ABI during the life of a major
>> version.
>
> GTK 2 and GTK 3 do keep their ABI just fine.

To my understanding GTK 3 gives no guarantees at all.

>
> Lisandro is talking about the GTK 4 plans. See 
> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
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?

[Marco Bubke]

On November 21, 2016 23:57:07 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
>> [snip]
>> > - people using Qt in applications distributed by packaging
>> >   systems (read "Linux distributions"). They are not affected
>> >   by BC breakages.
>> 
>> Users might not notice if we maintainers have to deal with this nightmare.
>
> That's what I said.
>
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

And how many applications are Qt only and use no standard lib anyway? Are there 
any numbers? Yes, sometimes they are inlined but sometimes they are not. Is it 
really a so big burden for you? And what are you doing about GTK? To my 
knowledge their BC is quite limit. 

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
>
> I understand that.
>
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
>
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

You can capture behavior changes by unit and integration tests but there is 
always the possibility that you break something because the complexity is not 
reasonable testable. It's always a tradeoff. 

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
>
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?
>
> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.
>
> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I strongly agree with Andre'. And is a BC break in the time of flat pack that 
bad? As an user I really looking forward to flat pack,  so I can update my 
heavily used Applications and being not dependent on distribution. This package 
could be much better optimize with LTO and profile guided optimization. Maybe 
sharing everything is not that smart anymore. 

> Andre'
> ___
> 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] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 20:02:54 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote:
>> Giuseppe D'Angelo:
>> >> I would also like to point out that, despite we have a repository, we
>> >> still don't have a tool for properly discussing the actual content of
>> >> QUIPs.
>> >>
>> >> * Gerrit does not work because comments cannot be threaded, they
>> >>   don't stick to multiple reviews, and they can be ignored
>> >> * Email does not work (it may work for the overall direction, but not
>> >>   for the in depth discussion) because a single message may cover
>> >>   multiple discussion points, disrupting the threading, and
>> >>   discussion points can get ignored (*)
>> 
>> All of which plays into my desire to introduce you all to Critic [0]
>
> Guys,
>
> the idea of QUIPs was to *fix* a problem, namely the current inability
> to pinpoint results of mailing list discussion. This *is* a problem for
> the Project, as lazy consensus on the mailing list is *the* official
> decision making process in the Qt Governance model, but it works in
> practice rather accidentally, if at all.
>
> Discussions are observed to deteriorate, develop into completely
> unrelated discussions, and even if something appears like consensus or
> the discussion dies, it typically turns out that different people think
> differently about what the consensus actually was, and the discussion
> re-starts half a year later.
>
> You both nicely demonstrate that this problem exist, thank you for that,
> but beyond that this particular sub-discussion misses the point.
> QUIPs were not meant to require new or different tooling, and I still
> believe such will be needed.
>
> The rough idea is that a topic is presented as usual on the mailing
> list, and when someone, usually the original proponent, gets the feeling
> that the usual rounds of bike-shedding, trolling and name-calling is
> over, and the occasional sensible arguments all have been heard, writes
> up what appears like a potential consensus and puts that on Gerrit,
> where some review process commences.
>
> The only difference to a normal review process I'd like to see would be
> a *much* higher bar for approval, to ensure that QUIPs are really close
> to consensus and to ensure some consistency within the set of QUIPs.
>
> None of this requires new tools, certainly not the bootstrapping of
> the first QUIP. There's also nothing changing processes, so everybody
> will be free to continue to present his views on his favourite tools
> in the future, but for now I'd really like to get this here done.
>
> IMNSHO it boils down to the question: Does anybody have any fundamental
> problem with main idea of having documents summarizing the lazy consensus
> of certain mailing list discussions? If not I'd call that a lazy
> consensus and would ask to proceed with reviewing the final wording
> on Gerrit.
>

I think it's modeled after Python PEP and RFCs? Do we have a first QUIP who is 
describing the process? 

I think we should copy a successful model like 
https://www.python.org/dev/peps/pep-0001/ and don't try to be smarter.

And yes, I don't think document a random email conversation is the answer. 

> Andre' 
>
> ___
> 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] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

So how often do you had a BC break in stdlibc++? 


On November 21, 2016 19:50:23 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> [snip]
>> - people using Qt in applications distributed by packaging
>>   systems (read "Linux distributions"). They are not affected
>>   by BC breakages.
>
> Users might not notice if we maintainers have to deal with this nightmare.
>
> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib 
> break 
> ABI we need to get Qt rebuilt and *everything* building against it. That's 
> the 
> worth nightmare we distro maintainers can dream on. And yes, we would need to 
> adjust Qt's SONAME on each change.
>
> -- 
> Yo quiero conocer el pensamiento de Dios, el resto son detalles.
>  Albert Einstein
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 14:29:10 Shawn Rutledge  wrote:

>
>> On 21 Nov 2016, at 12:06, Edward Welbourne  wrote:
>> 
>> Giuseppe D'Angelo:
 I would also like to point out that, despite we have a repository, we
 still don't have a tool for properly discussing the actual content of
 QUIPs.
 
 * Gerrit does not work because comments cannot be threaded, they
  don't stick to multiple reviews, and they can be ignored
>> 
>> [0] https://github.com/jensl/critic
>> 
>> I would dearly love to replace Gerrit with it - I realise that's hoping
>> for too much - but, for a new repository on which Gerrit isn't adequate,
>> maybe we could consider it …
>
> Maybe it’s worth a try.  But someone has to install it on a server so that we 
> can try it, right?  Is that easy enough?

Yes, some server for evaluation would be nice. 

> ___
> 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] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 13:51:10 Oswald Buddenhagen <oswald.buddenha...@qt.io> 
wrote:

> On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
>> On November 21, 2016 12:58:59 Oswald Buddenhagen <oswald.buddenha...@qt.io> 
>> wrote:
>> > how about taking the existing processes seriously and exercising social
>> > pressure on those who think they are above them?
>> 
>> Sorry, not everybody likes to use social pressure (mobbing).
>>
> the thing is that there there is no tooling which is absolutely
> foolproof. people will always come up with creative ways to
> circumvent it, and the only way to deal with that is showing them that
> doing so is not acceptable. it's a bit of a stretch to call that
> mobbing, and i gladly laugh it off when it happens.

But you see that a tool who makes it easy to snippet on some argument is maybe 
more suboptimal than other. It's not about using the perfect tool but using one 
which is better. Ones that sets 'loud'  people at a disadvantage. And it's not 
only the tool,  it's the culture too. A culture which is appreciating new 
arguments and not loves to repeat arguments again and again, especially to hide 
some private agenda. If an argumentation is more about individual agendas and 
less about the common good it is doomed.  Especially if people try to sell the 
first as last. The tool should help to make that transparent but it is only one 
building stone. 

> ___
> 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] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 12:58:59 Oswald Buddenhagen  
wrote:

> On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote:
>> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen 
>>  wrote:
>> > the repository has been created.
>> 
>> I would also like to point out that, despite we have a repository, we
>> still don't have a tool for properly discussing the actual content of
>> QUIPs.
>> 
>> * Gerrit does not work because comments cannot be threaded,
>>
> when you use inline comments, the locality is good enough to
> make threading generally unnecessary.
>
>> they don't stick to multiple reviews,
>>
> this is true, but becomes a real problem only if the change owner
> doesn't bother handling all comments before pushing new changesets.
>
>> and they can be ignored
>>
> that's correct, and having real issue tracking would be advantageous
> (which gerrit upstream knows very well).
> otoh, it's the responsibility of the reviewers and the submitter (a role
> we have intentionally restricted in this repo, mind you) to verify that
> all comments have been (actually) acted upon.
>
>> Any idea to how to actually make this work?
>> 
> how about taking the existing processes seriously and exercising social
> pressure on those who think they are above them?

Sorry, not everybody likes to use social pressure (mobbing). And could it be 
that the outcome of the argumentation is be quite different of what we would 
describe as good in the long run. My impression is generally that many smart 
people don't like too spend their time for that games. But people who thinks 
that their arguments are smarter think that they deserve to be chosen. 

Or let our describe it that way,  the rationality of people is quite limited 
and you need a good framework to get a better outcome. You can easily derail 
cooperation with a dysfunctional framework. Is shown in many experiments and 
believe me, we are not different. Actually people who working in IT have more 
trouble because they often describe the world  not as contingent but as based 
on a all-time, universal fundament (truth). So it's hard to compromise because 
that would be deviate from truth. If the discussion is based on experience it 
is actually quite positive to compromise because all arguments together give a 
bigger picture, based on much more experience. 

So the truth based world description leds to few 'specialists' discuss that 
matter but the latter is a cooperation of all people with experience about that 
matter. Neither is guaranteed to succeed but if you get the last in a 
cooperative mode you have a good chance. 

> ___
> 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] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 20, 2016 20:39:08 Giuseppe D'Angelo  wrote:

> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen
>  wrote:
>> the repository has been created.
>
> I would also like to point out that, despite we have a repository, we
> still don't have a tool for properly discussing the actual content of
> QUIPs.
>
> * Gerrit does not work because comments cannot be threaded, they don't
> stick to multiple reviews, and they can be ignored
> * Email does not work (it may work for the overall direction, but not
> for the in depth discussion) because a single message may cover
> multiple discussion points, disrupting the threading, and discussion
> points can get ignored (*)
>
> Any idea to how to actually make this work? Try reviewboard maybe?
>
> My 2 cents,
> -- 
> Giuseppe D'Angelo
>
>
> (*) This still happens all the time. User A proposes something; user B
> replies with "I don't think it works in scenarios X, Y, Z"; user A
> counter-replies "but Z is not a scenario we consider" and the
> discussion derails about Z. Noone talks about X and Y, which instead
> *must* be talked about, for the proposal to be accepted. We need
> something that makes it impossible to ignore the comment about X and
> Y.

Do you think about a wiki where you can comment? I think you want something 
with the capability to describe, comment,  argument and poll with a version 
history. Like you described email is a terrible tool for 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] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 18, 2016 22:13:03 Thiago Macieira  wrote:

> Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu:
>> There's no reason for Qt to extend its BC guarantees to other libraries.
>> STL, GSL, Boost, std::exception, you name it. They are outside of Qt's
>> realm and therefore do not fall under the Qt BC rules.
>
> Which is the reason we can't accept them in our ABI. The rules are 
> incompatible.

Actually GSL owner is simply definded as as alias to *T,  so you can add it 
without breaking any ABI or  API.

And I want to remind you it is about QtCreator, which has no guarantees. So it 
would be nice if you get in context. 

Actually it looks like you cannot agree on your assumptions, so it's maybe time 
to find arguments to provide some agreeable fundamentals. Otherwise I don't see 
how this discussion can be reach any cooperative level at all. 

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
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?

[Marco Bubke]

I want to remind you this is about Qt Creator, not Qt. Please use a different 
thread for it. [?]


From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on 
behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Thursday, November 17, 2016 11:35:54 AM
To: development@qt-project.org
Subject: Re: [Development] Basing Qt Creator Coding Style on C++ Core 
Guidelines?

On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote:
> On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
> >> Like you maybe have learned there are C++ Core Guidelines. They are
> >> already very comprehensive. What about basing the Qt Creator Code
> >> Style on it?
> >>
> >> I see advantages like new developer can easier grasp out rules
> >> because they are already familiar with it.
> >>
> >> We may have to exclude some rules too because they don't fit to us.
>
> Thiago Macieira replied:
> > "very comprehensive" is an understatement. Can you point out examples
> > of rules you're more interested in? Maybe we should start with a
> > whitelist of rules we do want and progressively expand from there.
>
> The guidelines' introduction does, after all, countenance gradual
> adoption - especially for existing code-bases - and a general opt-in
> approach.  Presumably QtC's style is also used for new projects; it may
> be worth using a larger subset of the guidelines for new projects as
> compared to old; and it probably makes sense to make it easy for users
> to configure which of the guidelines they opt in to, for each project.

If we do nothing else, we should at least use owner whereever possible. We
can add it to QtGlobal, since we require now enough C++11 to support it:

  namespace gsl {
  template  using owner = T;
  }

There, done. It doesn't even interfere with client code including a more
comprehensive GSL library, because they will define it the same way, and it's
just a type alias.


One problem is that in Qt, who is the owner is often not clear. But that
should not prevent us from using it everywhere else.

Than again, no compiler actually checks for this atm, not even MSVC, afaik, so
if we get it wrong, there's no-one but reviewers to call the mistake...


The bigger problem is that while owner does not affect the ABI, all other
GSL types do, and we're back to our ?$%&!? rule that we can't accept other
libs' types in our ABI, preventing anything other than owner from being
added to Qt.

My personal opinion is that we're way, WAY, past the tipping point where this
policy started to hurt Qt more than the convenience of interchanging libc++
and libstdc++ on OS X gives to the 5 people in the world that use this
feature. And I'm not at all happy that QtCS chickened out on a decision this
year. I don't think we can afford to wait for next year's QtCS to maybe-maybe-
not get rid of that nonsensical rule.

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

Hi


This is a Qt Creator topic only so sorry to disturb every body else.


Like you maybe have learned there are C++ Core Guidelines. They are already 
very comprehensive. What about basing the Qt Creator Code Style on it?


I see advantages like new developer can easier grasp out rules because they are 
already familiar with it.

We may have to exclude some rules too because they don't fit to us.


We can enable Qt Creator partially with the ownership flag so the static 
analyser can do a much better job. In the long run we had to add that to Qt too 
but that is a different story. We would then a testbed for better support of 
static analyses for Qt too. Something which are our users would maybe value 
quite high.



https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

[https://avatars1.githubusercontent.com/u/13841574?v=3=400]

CppCoreGuidelines/CppCoreGuidelines.md at master · isocpp 
...
github.com
CppCoreGuidelines - The C++ Core Guidelines are a set of tried-and-true 
guidelines, rules, and best practices about coding in C++


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

Re: [Development] Branch for adding Q_DECL_OVERRIDEs

[Marco Bubke]

Final can be used by the compiler by optimazing the virtual call away but it 
has the drawback that you cannot overload it in testing code to mock or fake a 
class. 


On October 27, 2016 18:36:01 Giuseppe D'Angelo  
wrote:

> Hi,
>
> please keep the discussion on the mailing list, so others can chime in.
>
> Il 27/10/2016 17:47, Александр Волков ha scritto:
>> 27.10.2016 18:19, Giuseppe D'Angelo пишет:
>>> Don't worry too much. To minimize merge conflicts I'm quite sure we'll
>>> keep using Q_DECL_OVERRIDE as long as 5.6 will be open. So use that :)
>>> We'll do a cleanup pass in the future.
>> 
>> BTW, should 'override' be added in the following case:
>> struct A {
>>virtual void f();
>> };
>> struct B : A {
>>void f() final; // override also?
>> };
>> ?
>> 
>> Unfortunately gcc reports a warning for f() 
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010)
>> There some such places in Qt, for example in 
>> corelib/kernel/qeventdispatcher_glib_p.h,
>> where Q_DECL_OVERRIDE should be added to make it compilable with gcc 
>> [-Werror, -Wsuggest-override].
>> The question is whether to follow a reasonable style
>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override
>> or a style forced by gcc?
>
> To be honest I don't know if we have a consensus on this. (How many
> cases of "final" in our classes do we have anyhow?)
>
> Cheers,
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clangbackend qtcreator 4.2 memory hogging

[Marco Bubke]

If c++ modules becomes supported it could go down but actually you should 
request that in the clang mailling list. We open a translation unit for every 
file and they are that big. We research precompiled header to improve speed and 
maybe they provide advantages in memory usage too.


From: Development  on 
behalf of kang joni 
Sent: Wednesday, October 26, 2016 11:57:55 AM
To: development@qt-project.org
Subject: [Development] clangbackend qtcreator 4.2 memory hogging

I have small project in which contains 2k SLOC with heavy v8 js
template included in source file.
For small opening 3-4 sources file this take almost 870mb in memory
with no precompiled header being checked plus qtcreator eats 280mb
with 2gb Intel celeron and this is definitely not desirable for me. I
have feature request  whether is this possible to put heavy c++ symbol
data in sqlite file with multithread concurrent access mechanism
instead to keep clangbackend memory usage being low?
___
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 Standard Library containers in Qt source code

[Marco Bubke]

> Why would we want UTF-8? There's no native type for it, unlike UTF-16's
> char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
> ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
> guaranteed to be UTF-32).


UTF-8 is used by many libraries and converting between UTF-16 and UTF-8 makes 
things not faster or better. If you work with text which is annotated with 
ASCII, which is quite common today, the advantages of Utf8 looks quite 
compelling.


But without changing QString to UTF-8 our UTF-8 support could be much better . 
For example we convert mostly to a QByteArray which has to be copied again 
because we have move the ownership of that string to API which is not 
supporting QByteArray. In that case it would be already nice that you would 
have something like QByteArray::takeData(). And this is only one case. Lets 
face it, the world is much bigger than Qt, and I think there is much to gain if 
we integrate better with alien libraries. Actually as I used Qt in the nineties 
it was my impression that Qt had that mindset but than it changed gradually.


From: Development  on 
behalf of Thiago Macieira 
Sent: Tuesday, July 12, 2016 7:33:16 AM
To: development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code

On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
>  y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:

Criticism:
* Qt's dependency on qmake: that's only for building Qt itself, not for your
application. Otherwise, we could always criticise any library for choosing to
use buildsystem X instead of Y.

* Remove moc: why? Moc has a very important use besides signals, that being of
reflection of C++. Until at least C++ 2020, but most likely WAY further,
there's no replacement for that. Therefore, removing moc is removing important
functionality. Let's see CS implement QtScript, QtDBus and QtQml without
moc...

* Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't
implement it properly.

* Signal / slot delivery as a separate library: interesting, I'll give CS
that, but not sure what the value of this is.

* Containers: leveraging STL only makes sense if we drop implicit sharing.
There are many arguments in favour and against doing that, which I will not
get into. What I will say: doing implicit-sharing with STL is the worst of
both worlds.

* Use C++ native pointers: granted, that's also the reason why we're not
reimplementing std::unique_ptr or extending QScopedPointer to have move
semantics.

* Refactor QString: huh?

> What would QString refactor would bring? UTF-8? QStringView?

Why would we want UTF-8? There's no native type for it, unlike UTF-16's
char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
guaranteed to be UTF-32).

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

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

[Marco Bubke]

I think it simply a question of time to get used to the STL. You get used to 
many things.


I think we should mind about the new features of C++ which are coming, which 
cannot integrated very well with Qt because we use a different idiom.


I really think we should make it easier for the developer but if we provide no 
way to go the fast path do we really make it easier?


If the context is changing over time, is it not smart to reevaluate decision 
again and maybe go a different route? I don't mean to do it all the time but 
maybe there is a middle path between different "fundamentalisms". []


From: Development  on 
behalf of Martin Smith 
Sent: Thursday, July 7, 2016 9:25:18 AM
To: André Somers; development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the ease 
of use of the Qt collections with the efficiency of STL algorithms.


martin


From: Development  on 
behalf of André Somers 
Sent: Thursday, July 7, 2016 9:20:10 AM
To: development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most 
> efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André
___
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] Changing qreal to a float

[Marco Bubke]

Hi

QMatrix4x4 is still qreal, which is still target depend? Is there any 
intention to change that?

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