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

[Konstantin Shegunov]

On Sat, Mar 16, 2024 at 4:01 PM Marc Mutz via Development <
development@qt-project.org> wrote:

> Function != variable ;-)
>

Granted, they're different and using declarations are intended for and work
for _both_ functions and variables.
I was simply providing some context where this syntax is actually quite
useful, hence the usage of "You can ALSO use this for [...]".

That aside, is the principal discussion theoretical as it seem to have
strayed quite a lot?
I get your argument(s) and I mostly agree, in principle that is. Yet, to
give you a counter example: if you `protected` inherited some class you
might want to hide some of its (virtual) methods for derived classes and
make them private. This a valid use case I believe, and is probably why the
language allows you to do so, rightfully - I imagine some (edge) cases
where you may want to do this sort of thing.

So to summarize my opinion:
Should `QObject::event` be made `protected` - likely, yes - but you would
need to collect the use cases for the public method and provide a migration
path, to play nice with the users.
Should this be discouraged if possible - likely, yes.
Should this guideline be made a rule, a.k.a. chisel it in stone - hell no.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development <
development@qt-project.org> wrote:

> The member variable thing sounds very wrong. I'd be surprised if it
> compiled.


Then you'd be surprised.


> If it does, it's probably something new in C++23 or 26 whereby
> you can use `using` for more general renaming [...]


If I'm not mistaken it's a C++17 feature. You can also use this to 'pull'
specific methods out of specific bases (e.g. if there's a name
clash/ambiguity), not only for changing access scope.
E.g.

struct A
{
   int foo(int);
};
struct B
{
   double foo(double);
};
struct C : A, B
{
using A::foo;
using B::foo;
};

Which allows C to have `foo()` properly overloaded.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Konstantin Shegunov]

Hi,
I imagine you're using a russian IP address, so this[1] should shed some
light on the matter.

Kind regards,
Konstantin.

[1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Importing a module build in creator

[Konstantin Shegunov]

This thread has been utterly useful, and thanks all for the input. May I
suggest, however, these tips get documented somehow (e.g. in the wiki)?
As it happens, what Eddy and Thiago wrote was truly a life saver for my
current poking into qtbase. Rebuilding the bootstrap lib invalidates
basically everything and it takes forever to build for no useful reason (in
my case), so it'd be really nice to have had this documented to begin with,
even if it is a 'workaround' of sorts.

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

Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

[Konstantin Shegunov]

On Mon, Jan 24, 2022 at 8:50 PM Thiago Macieira 
wrote:

> If you're talking about code in Qt, simply use std::fma and it'll do the
> right
> thing. It becomes my problem to optimise it so we get the shortest code
> emission, not yours.
>

So as it is now in that case. If it's not my problem but yours, then this
works for me wondrously. :)

The compilers also convert *some* instances of plain multiplication
> followed
> by addition into FMA. That depends on compiler flags, often enough,
> because of
> differences in rounding.
>

I will check if I'm not talking nonsense (as I had a few iterations over
that one), but I can't rely on that to happen magically - so I simply
enforce it at this point with std::fma.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

[Konstantin Shegunov]

On Mon, Jan 24, 2022 at 7:32 PM Thiago Macieira 
wrote:

> Today, only in the two files with "_avx2" in the name, unless you raise
> the
> CPU architecture yourself while configuring Qt. My proposal is to get that
> on
> Linux by default with the v3 extra build.
>

Yes, this I got from the discussion. However the code in question isn't in
*_avx2. In any case I don't have an objection or an opinion even (about the
original discussion), that default should work for my case, though.

For *your* code, you need to explicitly enable FMA yourself. The changes
> proposed in this thread do not affect user code.
>

*My* code, is supposed to fix Qt code at some point, so that's why I'm
asking. I know I have to do it myself for user code, that's not an issue.


> Both glibc, macOS libSystem, and Windows' ucrtbase have implementations
> using
> the FMA instruction and will detect at runtime which one to use (this was
> the
> *only* place in ucrtbase I found AVX2/FMA code). You're out of luck if
> you're
> using MinGW, though.
>

I suppose that could work, but I'd rather avoid doing the call if I can
help it.


> All compilers tested will use the FMA instruction if you enabled the CPU
> feature, otherwise they'll make a call to the math lbrary's fma() function.


Compare: https://gcc.godbolt.org/z/c5385d5GY (no FMA)
> to: https://gcc.godbolt.org/z/jf3zhsjPf (with FMA)
>

Yes, I already looked at the assembly, which is exactly why I'm asking
about it.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Implicit VFMADD support (Was: Updating x86 SIMD support in Qt)

[Konstantin Shegunov]

Related, but somewhat offtopic for the original thread.
Do we get `-mfma` (or equivalent) added, whenever supported, while we build
Qt. Is it part of the feature detection? Because I want `std::fma` to emit
the instruction(s), but I've noticed that in the code I test a bugfix with
I must force the issue by passing the flag explicitly; even with -O2 I get
a function call otherwise.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Importing a module build in creator

[Konstantin Shegunov]

Thank you all for the insights!

On Sun, Jan 9, 2022 at 5:02 PM Arno Rehn  wrote:

> I don't think that this is possible with CMake.
>
> I've been working around that by (re-)building only the module I'm
> working on with qtbase/bin/qt-configure-module in a seperate directory.
> That single-module build can then be imported just fine.
>

Thanks for that tip, I will try that out.

I've found that importing the full Qt6 build tree isn't so bad, either.
> Incremental builds with ninja are very fast.
>

Yeah, insofar as you don't touch the cmake files.

On Mon, Jan 10, 2022 at 10:10 AM Eike Ziller  wrote:

> Build your module separately from the rest of Qt, and open that in Qt
> Creator. Building a module separate from qtbase is actually pretty easy
> with CMake. Build qtbase and other modules that you depend on via qt5, and
> then just run "/qtbase/bin/qt-cmake-private -S  -B
> ” and build. Since you ran CMake separately from Qt
> on your module, you’ll have a separate project that you can open in Qt
> Creator.
>

With the provision that I haven't looked inside qt-cmake-private what would
be the difference from the qt-configure-module, which Arno suggested?

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

[Development] Importing a module build in creator

[Konstantin Shegunov]

Hello,
In the Qt5 times with qmake I was able to run the makefile generator on the
top of the Qt tree and then import build in Creator for some specific
module I'd wanted to work on. Is something like this still possible for Qt6
and cmake (I'm currently using the default ninja generator)?

The whole idea of this approach is that once I build the whole of Qt I
wouldn't change/rebuild or even check unrelated modules, but simply focus
on what I'm hacking at. I saw that currently I can import the (cmake)
configuration from the toplevel project, and that works fine, but I haven't
figured out if and how to do it for a subtree/module, or if it is possible
at all.

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

Re: [Development] Removing the global static QObject from QPixmapCache

[Konstantin Shegunov]

On Sun, May 30, 2021 at 6:14 PM Giuseppe D'Angelo 
wrote:

> > That should work, but it'd be one of them "exceptions", wouldn't it ...?
> ;)
>
> Sorry, exceptions to what?
>

I was simply teasing. I was referring to this thread about QTBUG-71545[1],
where I wanted the application to destroy its children explicitly so they
see it as QCA, but I wasn't convincing enough. Whereas QWidget(s) are doing
it in their destructors for their children for exactly the same reason,
which was the "exception(s)" I was referring to.

[1]:
https://lists.qt-project.org/pipermail/development/2018-November/034311.html
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removing the global static QObject from QPixmapCache

[Konstantin Shegunov]

On Sun, May 30, 2021 at 2:05 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> I'd tend to agree with idea, but not with the specific solution. You may
> want
>
> 1) to keep the cache alive across multiple QGA::exec() invocations,
> 2) to destroy it only when QGA gets destroyed,
> 3) to recreate it if QGA itself gets recreated.
>

Fair enough. If the object doesn't expect QGA to be alive while cleaning
up, then we could probably simply attach a destruction callback
(qAddPostRoutine)?


> A very simple solution is to make the cache a member of QGA(P), create
> it lazily if needed (like Q_G_S does; but I've got the funny feeling
> that the pixmap cache is used in 100% Qt apps, so maybe that's not even
> needed), and kill it in ~QGA.
>

That should work, but it'd be one of them "exceptions", wouldn't it ...? ;)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Konstantin Shegunov]

On Fri, May 28, 2021 at 2:13 PM Volker Hilsheimer 
wrote:

> Hey Widget fans,
>

Hola,


> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>
> The UX resulting from our (strange) choice to trigger selection changes on
> mouse press rather than mouse release is indeed quite horrible, as
> explained in the ticket.
>
> The options to fix that seem to be:
>
> 1) change the default behavior - always change selection on mouse release
> 2) change the default behavior if drag (as per dragDropMode)
> 3) make the "selection trigger" a property
>

Personally, I'd go for 1). This is rather usual from the user point of
view. That's how buttons and other UI elements typically operate - by
handling the behaviour whenever the release occurred over the element of
interest.

Also this thread[1] may be of interest to you. Implementing 1) is also
probably going to make the hack to change the selection back moot.

[1]
https://forum.qt.io/topic/126692/reordering-rows-of-qtableview-with-drag-and-drop

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

Re: [Development] Svar: Changes to Freenode's IRC

[Konstantin Shegunov]

On Thu, May 20, 2021 at 11:23 AM Volker Hilsheimer 
wrote:

> But the other question is who operates the service. It doesn’t matter if
> the service is Open Source if the community doesn't trust the operating
> entity.
>

Obviously, but Jason has a point. I can even give you an example:

When was it decided that your company should start sending unsolicited
advertisement emails?
I get these weird things for some time now, which I didn't use to get a few
years ago, mind you. And they end with:
You received this email because you are subscribed to Newsletters from The
Qt Company.

... which I can assure you I never explicitly did.
So this doesn't really inspire much confidence in the way TQtC handles this
user information.
*Note*, I'm not saying it's illegal, nor that I can't explicitly
unsubscribe, but then again I wonder (I don't really know) if people
registering just to post on forum.qt.io simply to get some user help also
get added (semi)automatically to these lists.
Do they?


> I personally would very much like to see certain aspects of the community
> at large to be less entangled with The Qt Company. The qt-project.org
> page is a good start. But that requires that someone actually steps up and
> says “I’ll do it”. Funding can always be discussed.
>

Funding does come with strings.
Example 2:
We were happily chugging along in the forum without much interaction with
the QtC, or with the other community channels really. One day a button
appeared that went to the marketplace you'd just started. Now, I don't mind
it much, simply because I realize and am grateful for the provided infra to
run the forum, but there wasn't a discussion or anything. It just appeared.
Again, neither illegal, nor "bad" in itself, just saying that it doesn't
inspire much confidence that the "community"'s opinion is regarded in a
significant way.

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

Re: [Development] Qt 6 docs: noexcept and constexpr

[Konstantin Shegunov]

On Tue, May 4, 2021 at 3:04 PM Giuseppe D'Angelo 
wrote:

> No. I'd say a qdoc bug/feature request is in order.
>

Right, I opened an issue on JIRA[1] about it, thanks.

On Tue, May 4, 2021 at 6:34 PM Topi Reiniö  wrote:

> QDoc uses libclang to parse the C++ sources, and there are cases where C++
> attributes/specifiers are not exposed in the AST  provided by libclang.
> It's possible to create workarounds for these limitations, but these are
> yet to be implemented.
>

Strange. Anyway I tried to attach the bugreport[1] to the 'Qt6
Documentation' epic but JIRA didn't allow me. I assume it's about
permissions and such, so if you want to move it there, you're going to need
to do it yourself.

[1]: https://bugreports.qt.io/browse/QTBUG-93439
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 6 docs: noexcept and constexpr

[Konstantin Shegunov]

Hi,

Is qdoc supposed to mark the mentioned declarations?

I just checked the Qt 6 docs for the QFlags and it doesn't seem to indicate
either, although they are declared as such in code. Am I missing something
here?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's up with inter...@qt-project.org ?

[Konstantin Shegunov]

I got incoming on the 3rd (snip of the headers follow), however I did
notice it being silent shortly after that. I may've received it directly
because I was the primary recipient.

Received: by 2002:ab0:1521:0:0:0:0:0 with SMTP id o30csp1949336uae;
Sat, 3 Apr 2021 02:35:47 -0700 (PDT)
X-Google-Smtp-Source:
ABdhPJyy5488+rwp6QTJrVNfcSedvCtkpB2ImSSZVagD6JN5bbHBNlrPSuIifeyFpNo+RDkDMSBc
X-Received: by 2002:a05:600c:ad3:: with SMTP id
c19mr1000142wmr.125.1617442547454;
Sat, 03 Apr 2021 02:35:47 -0700 (PDT)
Subject: Re: [Interest] QtQuick over Qt3D (Qt 5.15)
To: Konstantin Shegunov 
Cc: Interests Qt 

PS.
However, I just saw a mail came through the interest, so the problem may be
intermittent, or the mail server is laggy or something ...

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

Re: [Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6

[Konstantin Shegunov]

On Wed, Apr 7, 2021 at 4:51 PM Giuseppe D'Angelo 
wrote:

> Uhm... didn't they decide exactly against this? I might have missed the
> memo.
>

Well, apparently I did.

On Wed, Apr 7, 2021 at 5:05 PM Volker Hilsheimer 
wrote:

> You didn’t miss any memo. Konstantin, I wonder (genuinely to see what we
> can do better to have a discussion about this kind of thing without ending
> up with FUD spreading) how you got that impression?
>

It wasn't a loaded question, I must simply have remembered incorrectly; I
do recall it being discussed.
On a personal note, I do like the BC promise, and find it rather
distasteful to make such a promise, but then brake it a year or so in, even
if there may be good reasons to.

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

Re: [Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6

[Konstantin Shegunov]

On Wed, Apr 7, 2021 at 4:20 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> Il 07/04/21 14:56, Sze Howe Koh ha scritto:
> > Is it acceptable to remove them during Qt 6's lifetime? Or should we
> > wait till Qt 7?
>
> It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility
> promise. And not marking things _in code_ but only in docs isn't good
> enough.
>

Didn't the powers that be decide that an ABI break is going to happen in
6.2? If so, doesn't this mean, this could be sneaked in then?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Fri, Feb 21, 2020 at 10:25 AM Kai Köhne  wrote:

> Hi,
>
> Another alternative is to actually use C++ attributes for this:
>
>   [[qt::emit]] somethingChanged();
>

Nice idea, +1.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Konstantin Shegunov]

On Tue, Feb 4, 2020 at 8:55 PM Daniel Teske  wrote:

> A QObject with a parent on the stack/unique_ptr is double owned and thus a
> problem. The severity of that problem is arguably worse with a unique_ptr.
>
Which is rather typical in well structured and valid threaded code, where
the children are stack allocated and are moved to the correct thread
whenever the parent is moved. There's more to memory management than
half-blindly throwing smart pointers at it, is my point. Say you substitute
all the private objects' allocations with std::unique_ptr, the question
would be what do you gain by that?

> Where my patch improves this situation is that the object ctors taking a
> parent ptr are all marked with a optional deprecation, thus if you opt into
> that, you'll get a warning for the second case even for the stack
> allocation.
>
I've looked at your patch the first time you posted it on the dev list, it
looked (and still does) fine to me.

> And yes this contrary to very crafty code that allocates objects in the
> right order on the stack, but that has never been the recommend way to use
> Qt.
>
The right order in the stack is given if the parent already contains the
children. And C++ is stack-based to begin with, otherwise people wouldn't
have invented stack objects managing heap-allocated data blocks (a.k.a
"smart pointers"). Even the idea of having free floating shared pointers
gives me shivers. I've run on more than one occasion into easy to miss
ownership pitfalls where I have had a slot executed on a QObject where the
object had already been deleted by a shared pointer. My current stance is
(in regards to the current state of affairs, that is) - don't use QObject
with shared pointers unless you like pain often and in copious amounts.
(nested event loops and/or queued events are what usually does it)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Konstantin Shegunov]

On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov 
wrote:

> I think, if we decide to re-implement parent-child model using smart
> pointers, we would not use unique pointers at all. Even in a methods
> like QObject::makeChild (because ownership is already defined). Shared +
> weak pointers make perfect sense here.


You have to be really crafty. Allocating on the stack is a thing, you know,
even for parent-child trees, so how do you intend to handle that? Are we
again in "forget the stack and new everything" land?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Konstantin Shegunov]

On Thu, Jan 30, 2020 at 12:22 AM Matthew Woehlke 
wrote:

> Aside from issues with Patreon's reputation


I was not aware of such, but I'm going to take your word for it.


> Besides, I was thinking more along the lines of something that could
> integrate with other OSS tools (e.g. GitHub).
>

Fair enough.


> I want a "proud sponsors" page. I want to be able to offer bounties for
> specific bugs or feature requests.


I believe everybody would welcome that.
On that note, just a wild idea, paying per module (i.e. 50$ / year for
QtCore + 50$ / year for GUI, etc.) could be more flexible scheme to
license. Not sure how that aligns with QtC's sales people, but seems more
fair to me to pay for what you use (and by extension support its
development).

On Thu, Jan 30, 2020 at 12:26 AM NIkolai Marchenko 
wrote:

> I personally want a goal oriented fundraiser model. Like "revamp
> qtwidgets", "do a round of serious bugfixes in qml" etc
>

That also seems fine to me.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Konstantin Shegunov]

On Wed, Jan 29, 2020 at 11:55 PM Matthew Woehlke 
wrote:

> We need more open-source-meets-kickstarter...
>

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

Re: [Development] Changes to Qt offering

[Konstantin Shegunov]

On Mon, Jan 27, 2020 at 4:36 PM Lars Knoll  wrote:

> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>

This all sounds like a spanking for the LGPL users, and it really is.
Leaves a really bad aftertaste, especially for those that actively try to
give something back (even if it's a small something) as a "compensation"
for using the LGPL license. I don't think anyone would be against bigger
businesses pitching in more into development (moneywise), but as a
one-man-show the feel is that I've been penalized for not paying the rather
insane license fee.

The third change is that The Qt Company will in the future also offer a
> lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
>

I see a couple of issues here. Firstly, 100k/year *turnover* isn't a small
business, that's a nano-company (i.e. 1-2 devs max) and if they're
providing a device alongside the software that 100k is going to be eaten in
no time. Notice we are not talking profit here, but raw revenue. Whoever
from sales came up with that number, really did a botched up job with it.
On that note, even if we accept that it's applicable, the straightforward
math shows you want to bill 0.5% - 2.5% of the total turnover, so while
this sounds good initially it really isn't that shiny when you crunch the
numbers. That offering is stillborn from my point of view.

Additional question (and a note) here: Is this targeted at embedded/device
developers? Because I don't see how Qt for Device Creation is something
desktop devs need. What we actually would love to see is (more) bugfixing
in the widgets module, but that hasn't been happening that much, nor am I
expecting it to happen; it does seem the major push is to put new features
in, even at the expense of a significant feature creep. (not complaining,
just noting, I get you need to make money and money is where new shiny
things are)
But then that begs the question: What'd be my incentive to pay the license
fee as a desktop dev (any of them, and the standard one is real steep) when
I get very little out of it in return?

The second change is that a Qt Account will be in the future required for
> binary packages. Source code will continue to be available as currently.
> This will simplify distribution and integration with the Marketplace. In
> addition, we want open source users to contribute to Qt or the Qt
> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
> review and the forums all require a Qt Account).


That's not that big of a deal most of the time, even if somewhat
inconveniencing. The justification though, it's totally bogus. You want
people to register, fine, but don't invent the reasoning for it to sound
better. Also having an account does not lead to contributing, it's simply a
non sequitur. We have tons of people that register to the forums to post
questions, but that doesn't mean they do or want to contribute to the
source. Also the whole spirit of the new offering feels as "we want *to
make* opensource users to contribute". The whole tone and impression is not
"we want to encourage you", but rather "we want to force you", and I have
to say that approach has never ever really worked well, historically.
There's a reason the anecdote goes as: "Putting a 10 foot wall just opens
the market for 12 foot ladders".


> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
>

That's not really true. Neither in the technical sense, nor otherwise.
There are technical problems, as for example pointed out by Peppe, that
need to be addressed, and then there's the argument that changing the
pattern of usage is always going to change the pattern of development. You
can't artificially separate the two and make that claim lightheartedly.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving math3d classes from GUI to CORE

[Konstantin Shegunov]

On Fri, Jan 24, 2020 at 12:17 PM Laszlo Agocs  wrote:

>
> > So it looks like there is a need to have something like Eigen in Qt, at
> least for Qt 3D purposes (faster, better optimized classes, more complete
> API).
>
> Not sure how that conclusion was drawn.


Yeah, me neither. In my view the original problem was reinventing the wheel
on a day-to-day basis. So why would you want to step on that shovel yet
again?
I agree with Laszlo, given that eigen/blas or w/e isn't going in - "just
stick to what is available" seems like a very good advice. On that note
it's probably worth considering "backporting" Qt3D's QTransform and friends
into the gui module, as they're reported to be better optimized, but I
wouldn't go further than that.

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

Re: [Development] Moving math3d classes from GUI to CORE

[Konstantin Shegunov]

Hi.

On Thu, Jan 23, 2020 at 10:56 AM Jaroslaw Kobus 
wrote:

> one of the tasks planned for Qt 6 is to move the math3D classes from QtGui
> to QtCore (https://bugreports.qt.io/browse/QTBUG-46653).
>

Why? My personal experience leads me to believe that the transformations
and such aren't really suited for general-purpose work (i.e. gui
unrelated), so I really don't see the point of going through the motions.
This is what we also advise people in the forums - if you want to do math
on vectors (unrelated to the painting), do it manually/pull a dep or w/e.

These may be interesting for you to take a look at:
https://bugreports.qt.io/browse/QTBUG-75146, which triggered:
https://bugreports.qt.io/browse/QTBUG-75879
leading to:
https://codereview.qt-project.org/c/qt/qtbase/+/261770 and
https://codereview.qt-project.org/c/qt/qtbase/+/261715
none of which seem to be possible, or wanted.


> 1. QMatrix4x4 class (to be moved into Core) uses QTransform class (which
> is currently a part of Gui lib, inside paining dir):

2. Old QMatrix class, which is to be ultimately deprecated in Qt 5.15, is a
> field member of:


I'll pass here, I don't have an opinion on that.


> 3. QMatrix inside QVariant / QMetaType. If we are going to remove QMatrix
> type in Qt 6, we need to remove it from QMetaType::Type enum (current value
> = 79). Then we create a gap at position 79. We may adjust the values for
> other types (like instead of 80 for QTransform we move it to 79, and so
> on). However, I wonder whether it is going to work in cases like data
> streaming (e.g. someone stored the variant using Qt 5.15 and now he want to
> read it in Qt 6). Or should we just leave the gap at 79?
>

I'd say leave the gap, seems more prudent. My concern you spelled
explicitly already - if indeed someone uses a stream that comes from Qt 5.x
but is read in Qt 6.x then reordering the types means breaking the stream
for no obvious reason.


> 4. Where to place math3d classes? Currently they are in gui/math3d. Should
> they go to corelib/math3d, or should they be added into some already
> existing dir, like corelib/tools?
>

I think it's best to leave them in the gui module.


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

Re: [Development] The age-old T* foo vs. T *foo

[Konstantin Shegunov]

On Fri, Oct 18, 2019 at 6:40 PM Thiago Macieira
 wrote:
> Third option:
>
> char * const key;

Which is my style in my own projects - detaching the asterisk(s) with
whitespaces both sides. And in c++ there are types composed from
multiple tokens already, so it isn't anything original either way. The
discussion boils down to that - a style preference, which means it's
best decided by majority vote, which we don't have, nor do we employ,
thus from my point of view that makes it rather impractical bordering
irrelevant.

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

Re: [Development] Views

[Konstantin Shegunov]

On Tue, Jun 11, 2019 at 4:04 PM Giuseppe D'Angelo 
wrote:

> Well, one difference is that we don't _already_ have an implementation
> of flat (unordered) maps to be replaced by a 3rd party library, and we
> are finding lots of cases where this would be useful...
>

Fair point. We don't already have an implementation that solves systems,
but I leave that to rest, it's not that important for this thread. But to
play devil's advocate for a second - taking the stance that QVector, QList
and friends should go away, isn't it better to *ask* that such a container
goes into the STL and use that instead of boost? Or even just wait for it
to materialize in the STL (eventually), i.e. basically do nothing?

On Tue, Jun 11, 2019 at 10:02 PM André Pönitz  wrote:

> I don't think that (non-)COW is a problem in the scenario under discussion.
>

It may, if eventually it's to be exposed as public class, that's why I
brought it up. Otherwise I personally don't have any objection to (or
argument against) a non-shared container.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Tue, Jun 11, 2019 at 12:03 PM Ulf Hermann  wrote:

> 3) Also sort the data on copying. Then you can still share the result.
>

You mean at the point of the shallow-copy (i.e. ref-count increment)? If
so, yes, that could work too, I think.

On Tue, Jun 11, 2019 at 12:46 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> It's fun to write containers and everything, but this stuff already
>
exists, and it's ready to be used (under liberal licenses):
> boost::container::flat_map, absl::flat_hash_map, and so on. Maybe the
> only thing missing is a flat unordered container that doesn't use
> hashing at all (just a vector of elements compared with op== for
> detecting duplicates, for very small workloads).
>
> Anyhow, given all of this isn't meant for public APIs, let's just use
> them and move on?
>

I find that unlikely to happen. Otherwise it'd raise a question in my mind
why this[1] couldn't go in.

[1]: https://codereview.qt-project.org/c/qt/qtbase/+/261715
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Tue, Jun 11, 2019 at 11:31 AM Ulf Hermann  wrote:

> I imagine that a vector which automatically sorts itself on the first
> lookup after any changes if it's larger than X items could be a drop-in
> replacement for most of the places where I misuse QHash or QMap. X could
> be a template parameter or found by some heuristic.
>

I though about this as well. There's one caveat though. It can't be
(easily) made COW (if we require it). If your lookup is non-mutable (i.e.
`constFind` or w/e it's named), it'd mean that you have to mutate the data
in a const method. This implies doing it (thread-)safely is going to get
rather clumsy as there are 2 possibilities I see:
1) Detach in the `const` lookup if the data's dirty (i.e. not sorted) and
then sort it, and then do the lookup.
2) Lock the data block, sort it and then do the lookup.

Do I miss something?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Wed, Jun 5, 2019 at 9:44 PM André Pönitz  wrote:

> On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote:
> > 2. Delete all uses of the deprecated API from Qt itself
>
> ... and that *before* the deprecation happens.
>
> Lately the deprecations left Qt in a state that was still using deprecated
> API all over the place, with the people driving the deprecation generally
> leaving "fixing" Qt itself and other Qt Project to others.
>
> To put it bluntly: I consider this anti-social behaviour that is absolutely
> *not* in line with the spirit of the Qt Project.
>

I'd have to agree on that. In general that is, because there are some cases
where it's not possible; e.g. when the deprecated class/function is
exported for the user and due to our compatibility promises we can't remove
it immediately. Before we require the user to clean up their house it'd be
really in line for us to do the same. Not to mention that leaving usage of
deprecated APis inside the library unnecessarily creates technical debt,
which is going to bite sooner or later; if we are lucky, sooner rather than
later.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Wed, Jun 5, 2019 at 12:57 AM Kevin Kofler  wrote:

> IMHO, major versions with source compatibility need to actually
> live
> much LONGER, not shorter. At least 20-30 years, with the time at least
> doubling with every new major release. Or just stop doing compatibility
> breaks entirely.
>

This isn't possible by any practical measure. Unless the API design was so
good that it encompassed every possible case and it was designed in such a
way that nothing changes, then it could live forever (and yes 20 years is
forever). Since the API need to get fixed, polished, refactored and
improved, compatibility needs to break from time to time. Keeping
compatibility is simply not maintainable and honestly a chimera. Can we
drop that topic branch now?

Shorter binary-incompatibility cycles, no matter whether you call them
> major
> versions or start breaking binary compatibility in minor versions (ewww!)
> are going to make Qt entirely unmanageable for distributions.


Somewhat harder. Entirely unmanageable is an unjustified exaggeration.


> We already
> have to maintain Qt 3, 4, 5, and soon 6.
>

Actually we have to maintain 5, we should've moved away from 4 (and I
personally know that can be a pain for some codebases), and honestly if
you're using (and requiring) Qt3 then you really need to rethink your
approach.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

What about shortening the major version release time, instead of changing
the whole model?
Say we keep the current model, but instead of doing a major release once in
6-7 years, we fix that to 3 years with two LTS releases - one 1.5 years in,
and then the last minor version before the major release. That'd allow to
make the cleanup sooner and at the same time keep the promise of
compatibility for a reasonably long time. It'd also compress the amount of
breakage going in, just due to the time constraint, so should alleviate
some of the porting issues (I think).

On Tue, Jun 4, 2019 at 8:09 PM Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> Hi!
>
> On Tue, 4 Jun 2019 at 13:46, Mutz, Marc via Development
>  wrote:
> >
> > Hi,
> >
> > This is not meant to be a summary of the thread so far, but the
> > definition of a possible solution space:
> >
> > = The meaning of deprecation
> >
> > I think of deprecation as a means to tell users that the designers of
> > the deprecated API think that there is some deep flaw in the API that
> > makes it harder to use correctly or easier to use incorrectly. Or
> > lacking in any other desirable software quality realm, and yes that
> > includes performance.
> >
> > One important aspect of deprecation, IMO, is that the deprecated API
> > will be less likely to be properly maintained. So, e.g. by deprecating
> > QLinkedList, we tell the users that we do _not_ intend to make it
> > feature-compatible with std::list, e.g. by adding splice(). Users may
> > continue to use the class, but they will not enjoy the same progress
> > that other Qt classes or std::list will exhibit.
> >
> > I don't think, that, apart from the usual nay-sayers who don't want
> > anything to change, but also don't contribute, there's much disagreement
> > over how and what to _deprecate_.
>
> Agreed.
>
> > = The deprecation life-cycle:
> >
> > The question really is: if an API is deprecated, then what? We have, so
> > far, removed deprecated APIs from the library, or moved it to a
> > QtXSupport library, which later got removed, too. I think the most Angst
> > comes from the removal part here.
> >
> > Let me try to define the deprecated API lifecycle as follows (dare I
> > call it 4D? :)
> >
> > 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many
> > simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops;
> > sometimes, Qt will realise that it's not able to support some API any
> > longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer)
> >
> > 2. Delete all uses of the deprecated API from Qt itself
> >
> > 3. Disentangle the deprecated API from Qt. With this I mean that we take
> > the steps necessary, at a point in time when we can, to make a Qt built
> > sans deprecated APIs as BiC as possible with one that isn't stripped of
> > deprecated APIs. The usual way to do this is to move the implementation
> > inline into the header file and make it wrap the new API. The point in
> > time traditionally was v(X+1).0, but see below.
> >
> > 4. Decommission the deprecated API. With this I mean either remove it,
> > or spin it off into a library which is no longer maintained by the Qt
> > Project. The hope being, that someone (TQC, KDAB, Kevin Kofler) picks up
> > maintenance of said library. This can be done at the same time as (3),
> > or later.
>
> Sounds good.
>
> > = Deprecation and BiC
> >
> > All the above, except, possibly, the decommissioning stage, are SC.
> > Disentanglement is, however, BiC. We have traditionally used new major
> > versions as a flag day to do disentanglement, and it seems to some, and
> > this is why Peppe started this thread, that the plan is for it to also
> > be the flag day for decommissioning.
> >
> > I think we could make the experience for our users a lot less painful if
> > we allowed ourselves the liberty to break BC by disentangling deprecated
> > API within major release cycles. I don't think anyone actually needs BC
> > from 5.0 to 5.13, and for all intents and purposes, 5.13 is not BC with
> > 5.0, because, as attested in this thread, there are behaviour changes
> > which make it unlikely that an application compiled against 5.0 runs
> > without modifications against 5.13.
> >
> > It seems to me to be a good compromise to disentangle deprecated API
> > right after an LTS. Whether to keep BC-for-DPF (binary compatibility for
> > deprecation-free programs, with apologies to Hans Boehm) across two or
> > three LTS releases is another question. I'm tending towards three. But
> > this would be BiC in the current process.
>
> The part of doing BiC in major versions is (also?) due to SONAME as
> it's (currently) only limited to major versions:
>
> $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME
>  SONAME   libQt5Core.so.5
>
> SONAME *must* be changed with each release that breaks binary
> incompatibility. Possible solution? Maybe using SONAMEs like major.lts
> could work. In 

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

[Konstantin Shegunov]

On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler  wrote:

> Why should software be different?


It shouldn't, as already pointed out. That's why well behaved libraries try
to keep compatibility in some reasonable margins.
To throw one more stone here - are you willing to backport patches from
latter minor versions to former ones? When the API and ABI breaks often
that isn't very trivial, is it?

On Mon, Jun 3, 2019 at 2:47 AM Manuel Bergler  wrote:

> a) Qt can never remove superseded APIs and classes (which is what
> you suggested previously) and will eventually collapse under its own
> weight, or
>

It can under the current model where API and ABI breaking may happen
between major versions, which I find rather reasonable.


> b) Distributors have to deal with the fact that some software
> doesn't port and have to ship every version of qt side-by-side, or
>

Like they do with boost? Which they don't, obviously.
It simply ain't going to happen they're not an infinite well of computer
and human time.

Also are you suggesting that all applications sync up theirs to your
release cycle? Or are the distros to do that?
If porting the application between minor versions takes more time than the
time to introduce a breaking change, then you're never going to port
anything as this is all you're going to do ultimately.

c) The software that doesn't port has to deal with the fact that it
> will be dropped by distributions. But any software with sufficiently
> many users to warrant packaging by the distributors should be able to
> find a maintainer that at least can keep it compiling.
>

Keeping something compiling is different from keeping something working;
not to mention that API breaks are non-trivial to port. Also this is not a
distributions' problem exclusively. Clients of Qt expect, and rightfully
so, binary compatibility which was promised. It wouldn't be surprising to
me to find an ebb of usage if we start breaking the ABI every 6 months just
because we decided we can. I don't even want to venture into the rabbit
hole that is 6-month lifetime of APIs.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Thu, May 23, 2019 at 12:15 PM Shawn Rutledge 
wrote:

> > On 23 May 2019, at 07:51, Konstantin Shegunov 
> wrote:
> > Yes, exactly like, though it'd need to regrow automatically; and on
> regrow it may need to normalize the order of elements (hence the
> "amortized”).
>
> When should it regrow?  It’s part of the definition that it overwrites the
> oldest elements when you try to insert too much data.
>

Yes, I meant specifically for the QQueue, we'd want it to grow so we can
accommodate the data. The most obvious thing that comes to mind for the
regrowth is when you need an element and the begin iterator (i.e. pointer)
is end iterator + 1. It does waste one element, but on the other hand
allows to easily distinguish between an empty buffer and a full one.


> I’m a big fan of the concept, have actually need one of these several
> times, and would like to see it moved to qtbase and made public


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

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> On 2019-05-22 22:38, Konstantin Shegunov wrote:
> > What about a rather smart (in terms of storage) circular buffer; a
> > vector. Then the push, pop, enqueue and dequeue would be amortized
> > O(1)?
>
> You mean like QCircularBuffer?
>

Yes, exactly like, though it'd need to regrow automatically; and on regrow
it may need to normalize the order of elements (hence the "amortized").
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Wed, May 22, 2019 at 11:30 PM Thiago Macieira 
wrote:

> More important than the prepend (unshift) optimisation, QQueue benefits
> from
> the takeFirst (shift) optimisation. That can be added to QVector by making
> by
> moving the begin pointer.
>

What about a rather smart (in terms of storage) circular buffer; a vector.
Then the push, pop, enqueue and dequeue would be amortized O(1)?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Konstantin Shegunov]

On Tue, May 21, 2019 at 11:26 AM Elvis Stansvik  wrote:

> They will not show up in the web search (I think).
>
> They are however available in the debian-debug archive, see
> https://wiki.debian.org/AutomaticDebugPackages


Oh! You got me there. I was not aware of that. Thanks for pointing it out!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Tue, May 21, 2019 at 11:04 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> which ones of the following guarantee
> integrity of references, i.e., _heap allocate every single element?
>

That's a hard one. Especially since very few could keep in their brain a
list of the sizes of each and every one class from Qt. It also differs
depending on architecture.
For example:
QList may (does on x86, doesn't on x64),
while
QList for sure does.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Tue, May 21, 2019 at 9:34 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> [...]
> This does not make the API simple to use.


Actually it does. Simple, as "easily understood or done" and
self-explanatory, which isn't the case for the Q3Slider's constructor. Yes,
familiarity plays a role in that, but doesn't conflict with simplicity.


> It introduces two different ways to do essentially the
> same thing


So? The standard does that too. Before the lambda from c++11 we implemented
that idiom as a function object. We had the tools to do it and it worked
just as well. It can still be done instead of using the shorthand syntax.
I, personally, have found it rather curious that each new revision of the
language claims more expressiveness and simplicity, while the STL on the
other hand is restricted to the box of "universality"; in the end there's
nothing more universal than a naked C-style array.


> advocating the ways that only works in a particular
> corner-case and refusing to show the universal way
>

To paraphrase: You're confusing universality with simplicity.


> Had the Qt API and the docs not lied to them by
> permanently showing contains() without mentioning that it's but a
> short-cut for a corner-case, but shown them std::find or std::remove
> instead, the developer would have been empowered.


I object to the "corner-case" description, otherwise I'm with you
(partially). There should be some promotion in the docs of the iterators,
for example with regards to find-and-erase vs. remove() (e.g. QHash, QMap).
Especially whenever you actually need to get the value before removing.


> As-is, Container::contains() dumbs the novice down by telling him a
> fairy-tale
> that isn't applicable to actual professional work.
>

Actually it doesn't. I continue to claim that contains() is a convenient
shorthand when you are only interested whether something has something,
which if I had to pull a number off thin air probably constitutes ~5% up to
~10% of the cases where you search. This doesn't qualify for an edge-case,
and most certainly doesn't exclude professional work.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Konstantin Shegunov]

On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Oh, a nullptr deref is pretty clear in a backtrace.


Indeed, but my point is that it's relatively useless for the user (or for
the developer for that matter). As you pointed out the dev sees the nullptr
dereferencing instantly, the user just gets a crash. The assert is just
superfluous is what I'm saying.


> Even in a release
> build, if you installed the debug symbol package that does with the
> distribution's version of Qt.
>

Humor me, will you? [1]


> Please, you debug against a release build, and complain that you don't
> get debug checks?
>

To take your previous example.

QPen pen1 = ~~~;
QPen pen2 = std::move(pen1);

// ... Some code

pen1.color(); // Ooops

You're missing out on 4000 other checks that way, too!
>

Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If
not, I get segfault. And as it happens I have enough builds, so even if
that happens and I can't switch kits and step into Qt, not every one user
does have that at their fingertips, however.
Having documentation that spells such behaviour clearly, would be
satisfactory to me, that's why I was inquiring on *how* the problem, which
is a real one, can be mitigated.


> That said, I'm pretty sure that a static analyzer can find uses of
> objects in partially-formed state with local analysis.
>

QPen pen;
QColor color = pen.color();

If the analyzer can see the above as dangerous, i.e. touching an object
with an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied.

[1]:
https://packages.debian.org/search?suite=testing=all=any=names=libqt5core
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Konstantin Shegunov]

On Tue, May 21, 2019 at 12:27 AM André Pönitz  wrote:

> > Somehow  *suggest* to the user that [s]he's supposed to build in
> > debug mode otherwise they're on their own?
>
> Nobody forces you to use Q_ASSERT.
>

Now you lost me. I don't, it was suggested as a means to prevent at-library
site accessing a partially formed state - i.e. for prevention of touching a
moved-from object that had its d-ptr nulled. I don't have access to the
d-ptr from the outside.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <
development@qt-project.org> wrote:

> All I'm saying is that there are tons of examples (QGradient) where the
> use of an owning container in the API is just a very bad idea and limits
> the implementor's freedom and/or performance. E.g. QGradient could have
> inline storage for two or three stops to avoid allocating memory for the
> most-common cases. I mean, QPainter is full of (QPoint *, int nPoints)
> APIs that surely were added just for performance. Ditto for QString,
> btw. Nowadays, with views, we can have the same API, but have it accept
> many owning containers transparently. I'm not saying that there must be
> no owning containers in the API. But there is a lot of low-hanging fruit
> out there.
>

Okay, I can live with that, and I do see why it'd make sense in some cases
to iterate the data directly. But then as a container can have many
different iterables, it seems reasonable to consider adding a couple of
methods that return views and take it from there. Why the push to remove
the owning container(s) API? In time it may prove you're right, so then we
can migrate the getters to the view API and eventually deprecate these
methods. Or they could coexist, or w/e. The point is why reach for the top
if there's low-hanging fruit?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Konstantin Shegunov]

On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen 
wrote:

> On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > state. The difference is whether member functions other then destruction
> > and assignment check for a nullptr d. I'd propose that on classes under
> > the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the
> > best balance between safety and speed.
>
> I agree. I would consider anything other than deleting or reassigning  a
> moved
> object undefined behavior, so asserting on it seems like a good help to
> users
> of our APIs.
>

I agree as well, although I have a minor nitpick. Q_ASSERT works only if it
was not stripped while building Qt. Meaning that I'm often working, as I'm
sure other users, on Linux especially, with the default (i.e. release)
version of Qt from the repo. Granted it may be my own fault, but in this
case the assert isn't tripped and this code simply segfaults for reasons
that aren't so obvious. Any suggestions how to mitigate that? Somehow
*suggest* to the user that [s]he's supposed to build in debug mode
otherwise they're on their own?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Fri, May 17, 2019 at 8:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Qt is a C++ library. If you don't like C++, either stay in QML or use
> Java. No-one uses C++ unless they need the extra performance.
>

I may or may not like where C++ is going, but that's really beside the
point. I don't, and I believe sensibly, optimize every single line in what
I write. I don't shy away from doing it where it matters, but certainly I
appreciate convenience where it hardly matters. Primarily I work without UI
so I don't see why QML or Java would be at all relevant.


> It is not Qt's job to change the decisions made by the C++ standards
> committee.


I never said it's the case. Are we talking about their decisions or the Qt
project's?


> If you want to change the STL, submit a paper to WG21, not
> rant on a Qt mailing-list.
>

There was no rant. Just how I saw the case from the user side, granted
written with some bitterness. Not everything that doesn't profess the STL
as the greatest thing since the sliced bread can or should automatically be
classified as a rant. I had written 3 more paragraphs in that particular
email.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Fri, May 17, 2019 at 12:56 AM Konstantin Tokarev 
wrote:

> In C++ there is a convention that ugly things should look ugly in code.


Have a reference for that convention?


> Removing element from the middle or beginning of contiguous container is
> ugly thing. If you need such operation in your code, you should consider
> using linked list instead, which allows to remove element with one method
> call (std::list::remove or std::list::remove_if)
>

Yes, because I may need to do it from time to time, so my code has to be
ugly. Makes sense ...
std::list is for linked lists, not for vectors. My use case may not involve
random insertions or removals in the vector, an occasional one - maybe,
that in no way means the library should treat me like an idiot who doesn't
know what he's doing. I can read the docs, I don't need to fight against
the API to do something rather simple.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

>
> On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.
>

Assuming that the data structure is simple enough and can be kept
contiguous in memory, and the view can be simply constructed cheaply by
means of contiguous blocks. The moment you need a couple of semantically
different layouts on top of that "struct of arrays" you're already treading
on thin ice. Not every problem can be simmered down to a vector and a
struct, sorry, otherwise people, much smarter than me, wouldn't have
invented trees and hashes. Yes, the user should *actually* think before
just using either arbitrarily, but this doesn't mean their implementation
complexity should be used as hindrance.


> 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.
>

Yes, and you can have infinitely many types of contiguous or non-contiguous
presentations based on either one these two storage kinds. Are we having a
different view class for each case where we may need to present the
internal data in a different way?


> Sure, but you'd have to change the public API to return that view
> instead of the contiguous-storage one.


Indeed, that's true. However changing the internal data layout nontrivially
almost certainly leads to changing the implementation of the view. Binary
compatibility ties your hands here if the view's implementation isn't
private. Making its implementation private in turn can eat much of the
benefit you claim.


> 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.


User story:
The API is always going to rule supreme over any implementation detail or
efficiency. The API is what you present to the user, not the
implementation. The moment you start sacrificing good API, one that's
fleshed out and convenient to the user, for a simpler implementation you
end up where the STL is - so convoluted it's hardly worth making anything
with it. Take the glorified std::vector - appending a vector to another
takes 3 arguments, and removing an element from it, or accessing its value
through an iterator for that matter, involves rather poorly hidden pointer
arithmetic.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] FP calculations and stability in Qt

[Konstantin Shegunov]

On Mon, May 13, 2019 at 12:42 PM Konstantin Ritt  wrote:

> Writing and proposing a patch would take less time than discussing pros
> and cons here.
>

Which I had in a minute fraction done, as a pass-by in the comments. I'm
not, however, willing to take huge technical debt on the issue by investing
copious amounts of time writing a specialized decomposition for this
particular case, in this particular class, for this particular set of
values. I'm not going to do it better than already done, is one, and
secondly it's a huge time sink. Combine both to get: "dubious result for a
big investment".
What I'd really, really want, ideally, is to have a well tested tool(set)
that I can rely on to do the job, whence my initial question: "can we talk
about how feasible it is to pull something (or parts of it) in Qt, even if
only internally, to facilitate stable fp calculation"
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] FP calculations and stability in Qt

[Konstantin Shegunov]

On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud 
wrote:

> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov 
> wrote:
> > Doesn't this imply it should be dropped as an API that we can rely on?
>
> No i don't think so, this is just an edge case. I solved it by
> changing the base unit of my graphics view, so that it doesn't have to
> manipulate tiny FP values.
> I remember reporting that, and AFAIR, an example was an arc in a
> QGraphicsPathItem rendered as as a polyline.
>

Okay, I'll bite. Let's take as an example the bugreport I mentioned, how
would such a transformation of units look like? It's not a loaded question,
I'm genuinely interested if I missed something because really I don't see
it. My point is that the actual calculation is done internally, so
restructuring the units isn't at all trivial, nor perhaps possible, on the
part of the user. If we can accept that we don't want to go through the
motions to make transformations at least correct in all cases, I'm fine
with that too, but we should then warn the user not to expect it from the
library.

I then turned on specialised library, Qt is a GUI toolkit, and is
> optimised for painting. Qt takes all opportunities to be fast and
> efficient in that context, and that includes being "mathematically"
> imprecised, painting is all about pixels at the end of the day.
>

Look, I'm not arguing we should aim for 1 epsilon precision, but there's
"imprecise" and then there's "blatantly wrong".

A pixel is a surface, everything is correct as long as the surface
> covered by the pixel contains the point.
>

Which it may not, is my argument. Numerical instability is the
disproportionate grow of the relative error. If you don't keep that error
in check then you (can) just get nonsense. I can, and will, accept that we
don't want the most precise algorithm out there, but at least we should
strive for one that's correct, shouldn't we?

What i was trying to say, is that all geometry operations performed by
> components coupled to QPainter are good enough (and very efficient)
> for painting, by are not usable for "scientific" calculation.
>

Define "good enough" please. Is "good enough" errors bound by the errors in
the input, is "good enough" errors that explode with some inputs, or
something else?

OT: By the way, as far as I can tell a LU with pivoting (O(n^3) complexity)
is approximately as efficient as the algorithm currently employed in the
mentioned bugreport. It has two major advantages in my view, however. One
is that it's rank-revealing, thus you can tell if there's linear dependency
with zero cost. Secondly, it's not reinventing a square wheel.


> QPainterPath is not called QPath, expecting to do precise geometry
> boolean set operations with it is a mistake.
>

To extend my argument from the previous paragraph(s):
How do you take the algebra out of the geometry? I get that the algebra can
go its merry way on its own (e.g. in science), but the geometry just
depends on the algebra. So if the algebra's wrong, the geometry can be all
over the place by simple logical implication, you can't tell if it's
correct or not.

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

Re: [Development] FP calculations and stability in Qt

[Konstantin Shegunov]

Thanks for chiming in, I do appreciate the thoughts.

On Sun, May 12, 2019 at 1:49 PM Christian Gagneraud 
wrote:

> I use to think that Qt could do a better job about FP
> precision/stability, but i had to realise that i was using Qt in a way
> that it was not designed for.
> For example, I tried to use QPainterPath, QLineF, QRectF, ... to do
> geometry processing. And i can tell you that QPainterPath is all but
> stable when it comes to small values. Highly zoomed-in QGraphicsView
> based geometry object yields crazy artifacts.
>

Doesn't this imply it should be dropped as an API that we can rely on?


> I then turned on specialised library, Qt is a GUI toolkit, and is
> optimised for painting. Qt takes all opportunities to be fast and
> efficient in that context, and that includes being "mathematically"
> imprecised, painting is all about pixels at the end of the day.
>

True, arriving at those pixels is the problem, at least as far as I can
tell.

Who cares where exactly a line intersect a polygon, if all you need to
> know is if you need to paint a pixel black or red.
>

Intersecting at the wrong point, means you paint the wrong pixel, right?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] FP calculations and stability in Qt

[Konstantin Shegunov]

Hi,
I'd want to clear the context out of the way, so this is the bug[1] that
got me thinking.
I appreciate that we want to keep external dependencies to a minimum, and
for a good reason, but can we talk about how feasible it is to pull
something (or parts of it) in Qt, even if only internally, to facilitate
stable fp calculation.

I've seen some complaints (on the forums mostly) about the stability of the
transformations Qt supplies, generally unfounded, however it'd be nice if
we can solve this with generality. I realize Qt is no math library and
support the idea to drop most of the global functions that dealt with math,
in the end they're already in the STL. However, as it is, we have some
linear algebra done (internally mostly), so I think it'd be nice to have
that done "correctly" for the user.

I'd appreciate feelings and opinions on the matter, as I'm but one person
and my view is rather limited.

[1]: https://bugreports.qt.io/browse/QTBUG-75146
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Konstantin Shegunov]

On Mon, May 6, 2019 at 10:42 AM Lars Knoll  wrote:

> Not sure whether it’s most projects, but there certainly are users doing
> it. And we’ve been using the pattern in our examples in some cases as well.
> But I can relate to Allan that creating widgets on the stack is bad style
> (as it conflicts with the way we memory manage them), and if I’d have a
> choice today, I would probably prefer to enforce them to be created on the
> heap by some means.
>

Fine, there seems to be somewhat of an argument in that regard. I'd raise
the question then, what should be done for QObject derived classes, and I
don't mean the ones that come from Qt (i.e. QFile, which Thiago mentioned),
but the ones the user defines. In the end QObject is for us to derive from
- get signals and slots and all those goodies. But then if one restricts
QObject to be on the heap how do we treat the user classes? What I mean is
- you can control how allocations happen in the library, say you provide
custom new/delete for QObject and/or QWidget and restrict the stack
(presumably through some trickery that disables the constructor), does this
mean we are to force the user to write their own allocation operators for
their classes? This doesn't really sound practical to say the least.
Moreover there's really little reason (from the user's point of view) to
have something in the heap if it can go on the stack. What do we do with
QCoreApplicaiton, force the heap on it?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Konstantin Shegunov]

On Fri, May 3, 2019 at 11:02 PM Иван Комиссаров  wrote:

> Which should be considered bad practice and banned on an API level
>

On Fri, May 3, 2019 at 11:30 PM Иван Комиссаров  wrote:

> By forcing usage of smart pointers, of course.
>

That's a joke, right? Smart pointers aren't pointers, they are *stack*-based
(auto-storage) objects that manage pointers. I draw the line to pay one
heap allocation for binary compatibility not two, one of them being the
size of void * mind you, wherever I can help it.
C++ is a stack-based language, are you intending to reinvent it?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecating the static QProcess::startDetached() overloads

[Konstantin Shegunov]

On Wed, Feb 27, 2019 at 12:24 PM Joerg Bornemann 
wrote:

> I'm not sure, I'm following. The non-static startDetached supports
> everything the static startDetached allowed. No functionality is going
> away, even if the static method is completely removed.
>

Right, sorry. I didn't realize that a non-static was introduced in 5.10 and
apparently I completely misread Thiago's question.
In light of this, I haven't any objection.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecating the static QProcess::startDetached() overloads

[Konstantin Shegunov]

On Wed, Feb 27, 2019 at 9:00 AM J-P Nurmi  wrote:

> Is it technically possible to start() and then detach()?
> [...]
>

This is quite important for me. I have a module that implements a
daemon/service[1] (due to QtService being old and not integrating with
windows' service manager) and I use the static `QProcess::startDetached` to
start the daemon and detach from the controlling terminal (on Linux). I
need *AN* API to do this, otherwise I'd have to (re)implement
double-forking myself. If there are changes I'm going to comply with them,
but please, deprecate only if you allow for detaching (later) through the
non-static methods.

[1]: https://bitbucket.org/nye/qtdaemon
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Coding style for lambdas with empty parameter list

[Konstantin Shegunov]

On Wed, Jan 9, 2019 at 8:44 PM "André Hartmann"  wrote:

> My request to syncronize both [3] lead to the conclusion, to change the
> rule,
> so that empty parameter lists should be written as
>
>  [] { // lambda content }
>

If I were to vote, which I won't, I'd vote instead to make the expression
as explicit as possible, thus requiring even the return type to be
specified. Which is also in line with my view on the auto keyword. C++ is
implicit enough to pile yet more "if this is not specified, then it means
something else" on top. And I personally believe that the whole syntax
shouldn't have been put in the standard allowing for any choice to begin
with. If you look before C99 the following kind of definitions were a real
blast:

functionX(parameter1, parameter2)
  int parameter1;
  float parameter2;
{
return 200;
}

Beautiful, right? The best part is, there's no need to specify the return
type as well ...
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Missing documentation in Qt 5.12

[Konstantin Shegunov]

On Tue, Dec 18, 2018 at 9:39 AM Martin Smith  wrote:

> I'll argue with you about it being a p1. If the problem is confined to the
> all-members list, it's not a p1 problem because the information is still
> there via the inherits links, which are more useful for seeing what is
> inherited anyway.


You can argue with the people that handled it through the tracker, I don't
prioritize bugs. From my point of view, however, it falls strictly into the
P1 category - it's a regression from the last version, not an edge-case
data loss, and it's pretty embarrassing.

My own opinion is that the all-members list should be removed.
>

I think no, unless there's another way to search for a method in the
hierarchy. Allowing for a somewhat contrived example:
Say I'm working with `QTemporaryFile` I know there exists something for
checking about it being readable but I don't know exactly from where it
comes from, then the all-members page is really useful. That use-case gets
even more prominent for classes that implement interfaces and/or that have
multiply inherited (e.g. QLabel's indirect inheritance from QPaintDevice).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Missing documentation in Qt 5.12

[Konstantin Shegunov]

Not only are members missing, but links lead noplace. For example in the
mentioned page metaObject() goes to
http://doc.qt.io/qt-5.12/qwidget.html#metaObject which naturally doesn't
exist. From what I can tell nothing that is inherited, beside the things
explicitly overriden, appear in the list. Although I wouldn't presume to
place fault, for me the bad impression was left not by the bug itself,
which is pretty embarrassing, as so much as bouncing it around on the
tracker for 10 days until ultimately a ping on the list prompted action ...
I mean, we get it, there's not enough people and hours to handle all the
bugs, but I *hope* it is not going to be necessary to bring P1s to the list
so at least they get attention ...

Disclaimer: I had conversed with Sze-Howe about this bugreport before he
started this thread.

Nitpick: Between 5.10 and 5.11 we magically got qt_metacall and qt_metacast
(expanded out of Q_OBJECT) into the members list and of course the links
are broken, but this listing of private(-use) members is long-standing
(from Qt 4); although I'm pretty sure these are not intended to be employed
by the users and they're never going to get a proper documentation page.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Opinions on QTBUG-71545

[Konstantin Shegunov]

On Tue, Nov 6, 2018 at 1:07 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> Note however that those children are deleted explicitly (via manual
> calls to delete), and NOT via the parent/child relation.
>

Noted. When I started that thread I didn't intend it to become one of those
lengthy arguments really. More like a simple "poll" whether the thing's
allowed, and if not how to handle it. As I wrote in the bug report -
"disallowing" the application to be parent is acceptable as an answer to
me, but then I think it should be noted in the documentation otherwise it's
rather misleading from the user's point of view.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Opinions on QTBUG-71545

[Konstantin Shegunov]

On Mon, Nov 5, 2018 at 11:02 PM Elvis Stansvik  wrote:

> But seems to me it would be a slippery slope to accept more
> exceptions.


You say exception, but I say expected behavior, which is actually the crux
of the disagreement.


> What's next, will I have to implement the destruction
> myself in my own widgets? :)
>

Yes, in the general case you actually have to if your dependent objects are
attached to a QObject holding an application-global state. Which is exactly
what Q*Application is - a QObject that has/is a global state.

On Mon, Nov 5, 2018 at 11:50 PM Uwe Rathmann 
wrote:

> The title of the bug report is about QCoreApplication, while the demo
> code is a QApplication - so I'm not 100% sure if I completely understood
> the discussion.
>

I'm at fault for not attaching the stack trace, but I'll try to explain.
Indeed the example code is for QApplication, the problem however manifests
whenever the destruction of said application object goes through. The
segfault happens because QCoreApplication sets its static member - the
global instance of the application object - to null before the children are
cleaned up by the QObject destructor. This means that objects parented to
the application are destroyed after there's Q*Application object no more.

But at least for QApplication I would consider having children being
> common practice and actually Qt does this too:

[snippet]
>

Interesting point, I haven't thought about it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Opinions on QTBUG-71545

[Konstantin Shegunov]

Hello,
Since we couldn't agree, I'd love to see some more opinions about this
one.[1]

Specifically:
1) Is parenting to the application object a thing?
1.a) ... and should it be allowed (i.e. accepting the proposed change)?
1.b) .. if not allowed, should we put a warning in the documentation that
it is wrong and shouldn't be done at all, or at least that it's discouraged.

[1] https://bugreports.qt.io/browse/QTBUG-71545
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt6 source changes

[Konstantin Shegunov]

I've seen that kind of argument before, so that's why I want put a comment
in here.

On Thu, Nov 1, 2018 at 12:58 PM Sascha Cunz  wrote:

> I've seen lots of commercial code bases in the past where QObject
> inheriting classes are combined with QExplicitlySharedDataPointer -
> while at the same time relying on having a parent in those QObjects.
>

QExplicitlySharedDataPointer? That would be rather odd. Do you mean
QSharedPointer?

Semantically:
> - They are strongly owned by some other QObject based entity
>

Then that's their parent.

- A lot of code stores a reference to them (In terms of a QESDP), where
> either:

   - the reference _should_ be invalidated during destruction
>

QPointer or connect directly to `QObject::destroyed`.

   - the existence of such reference (to a child) _should_ stop the
> parent from destroying that child.
>

Then they're not strongly owned by the parent!

- The overhead of QPointer is not desirable
>

Other smart pointers are cheap?

I know these requirements are kind of a paradox. But both variants of
> this are a pattern, I find relatively often in customer's code bases.
>

Sounds more like antipattern.


> I would really like to have an easy way to give such customers a "sane"
> way forward.
>

That'd be to define the ownership clearly, not try to weasel out of it with
some "smart" pointer.
Self-owning QObject instances can still be hold in `QSharedPointer` if
needed, however,
then they're not owned by the parent, so you shouldn't give them a parent.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Konstantin Shegunov]

On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use qbs
>
> That's not going to happen any more than our breaking source compatibility
> in
> a major way.
>

Fair enough. As a consequence qbs gets rather limited exposure, thus it's
not a priority for development.
To make matters worse smaller user base means smaller amount of
bugreports/fixes. Less fixes in turn leads to buggier/quirkier system
leading to fewer people using it. And the circle is complete - unfortunate,
but somewhat expected.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Konstantin Shegunov]

On Tue, Oct 30, 2018 at 6:41 PM Oswald Buddenhagen 
wrote:

> On Mon, Oct 29, 2018 at 12:17:04PM +, Lars Knoll wrote:
> > and investment in promoting it towards the larger C++ ecosystem as a
> > new build tool.
> >
> nonsense.
> all the promotion qbs would need is being used to build qt.
>

Context:
I don't really have a stake in this argument - I'm a qmake user that
doesn't *much* care about the build system, but I'll throw my 2 cents in.
For me cmake is good because many projects are already using it, meaning
that there's not a new technology to learn for many developers. Also it's
powerful, even to the point of being dangerous (I've seen quite the
abominations). On the minus side - it's rather complicated and the syntax
is abysmal.

Argument:
>From my point of view qbs is doomed as long as qmake's alive. Either kill
qmake and force the developers using Qt (or developing Qt) to use qbs, with
all its quirks, or live with the fact that people don't want to spend the
time learning a new technology if they don't have to. That's leaving the
pure enthusiasm about something cool aside. Not forcing the issue, in my
opinion, is the reason for the inevitable demise of qbs. And that's exactly
in line with the situation about makefiles: everybody's still using them
underneath the build tools, and pretty much everybody is hating them, but
at the end of day they work and there's little incentive to switch; known
is *safe* but ultimately hinders change.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sun, Oct 28, 2018 at 9:51 PM Thiago Macieira 
wrote:

> I'm pretty sure their company HR would want to have a chat anyway.
>

Well, I'm not as sure as you, but I am hopeful.


> That's also a good reason to choose the KDE CoC, as both TQtC and KDAB
> recruit
> heavily from the KDE community and its CoC is basically a statement of
> shared
> values.
>

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

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sun, Oct 28, 2018 at 2:08 PM Martin Smith  wrote:

> No, it isn't a resolution. Not reacting to a complaint is no resolution.


Given the (current) structure of the community I take that as the offence
not carrying merit.

But even if "the community" does react to the alleged offense, how is that
> different from mob rule?
>

It is not. Note that having a committee doesn't exclude mob rule either. In
all fairness, though, it makes it less likely, as I can easily imagine the
people voted in are going to be of significant integrity.

>Not only can I, I pretty much have to.
>
> No. You don't. You used the word "heinous." It has a meaning. You used it
> deliberately to draw attention away from the problems the CoC is meant to
> resolve.
>

I did no such thing, and I resent the accusation.

I'm not defending the CoC text and premise. I'm defending the goal of
> establishing a CoC.
>

Then I have no idea why we are arguing. I was just responding in good faith
to a question that was put forth. From the very beginning of this thread I
have operated under the assumption that a CoC is going to be adopted in
some form or another.

My turn to bite. What is a heinous act that is not a criminal act?
>

 Personal attacks, baseless accusations, mean-spirited comments, a
combination thereof. Anything that's beyond distasteful, but still doesn't
constitute a crime.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sun, Oct 28, 2018 at 10:43 AM Martin Smith  wrote:

> >Oh, it is going to end in A resolution, it may not end the way the
> offended party
> >may feel just, but that's true also for the proposed text.
>
> HA! You are not Konstantin Shegunov! A software engineer would imediately
> see that your 3 step CoC might not terminate. You are an imposter!
>

That's actually amusing, but I'll bite. Formally speaking, I'm not a
software engineer, never had any formal training in the field. I'm a
physicist who moonlights as a programmer. In any case, the current status
quo, which is what I described, ends in either the community reacting or
not reacting to the alleged offence (i.e. isolating the offensive party for
example). That is A resolution, be it a good one or bad.

>imagine that the abusive party is an employee of the QtC and has committed
> >heinous acts against a community member.
>
> You can't immediately jump to the worst case scenario to discredit the
> code of conduct. In fact, the CoC can deal with "heinous acts" by stating
> that such acts will be referred to the appropriate legal authority.
>

Not only can I, I pretty much have to. Minor infringements can already be
handled internally without the need for CoC, major ones is where it would
actually matter if we have one and which one we chose. Also it's a
perfectly valid logic to push an argument to the extreme to see if holds,
we do it on every day basis. In math you can assume something, operate on
the presumption and see if contradicts itself when pushed (reductio ad
impossibilem). If I were to design a safety net for a nuclear power plant
am I to just ignore the extreme or unlikely case? Surely not. You compared
the CoC to a "local law" of sorts, but does the local law forgo the
unlikely case that from the whole population one person would be a
murderer? I shouldn't think so.
You can't defend the CoC's text and premise on the basis that my argument
is unlikely, or extreme. It has to able to withstand exactly those extremes!

In fact, the CoC can deal with "heinous acts" by stating that such acts
> will be referred to the appropriate legal authority.


Not if they don't elevate to a criminal act.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira 
wrote:

> The answer to all of those questions needs to be "yes". Anything short of
> that
> means the CoC is powerless and just for show.
>

Which was my point exactly.


> Whether there's a termination of employment or not is out of scope, since
> the
> CoC does not rule TQtC employment and what other work there is inside that
> company.


> Note also it applies to any company. If you're not welcome anymore in the
> community where your employer is asking you to do work, that is going to
> affect your employment.
>

I agree. However my argument was that the QtC being a major contributor to
the codebase is going to have to abide by the ruling of the proposed
committee, which is a significant commitment (and a major nitpick I admit).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  wrote:

> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>

Oh, it is going to end in A resolution, it may not end the way the offended
party may feel just, but that's true also for the proposed text.


> But that isn't the implication.
>

Then I apologize, this is how I interpreted it.

The implication is that a mistreated person can take the actions you have
> specified, and the result can be that the mistreatment, real or not, is not
> resolved.


The proposed text can't guarantee resolution either (see below for a
reductio ad absurdum).

Active contributors who abuse others should be treated the same as inactive
> contributors who abuse others. What would be done would of course depend on
> what the abuser did. I suppose the abuser (active contributor or not) would
> be informed as to what he/she did wrong and would be told to stop doing it.


Say we adopt the CC (basically the proposed text) and imagine that the
abusive party is an employee of the QtC and has committed heinous acts
against a community member. As far as I can tell this is very unlikely, but
humor me for a second. As QtC employees' main work is on the Qt project,
i.e. writing patches, committing features, writing docs and such, how would
is this proposed committee to enforce the CoC? Are they going to plead that
the person is taken out of the project, and wouldn't that mean that,
basically, he/she can't be an employee for the QtC anymore? And to drive it
home, say the head troll had a mental breakdown or something what is the
committee to do? Take over the QtC?

Just as I said before, I'm not against a CoC in principle. I'm against the
CC's text which is quite invasive and badly written. To me KDE's CoC is
much more practical in the case of the Qt project.

Exactly. Without a CoC, we have no laws, so the implication is we don't
> consider any behavior an offense.


Laws are bit more complicated than a statement of how people *should*
behave. There's also separation of power, mandates, enforcement and laws
that control how laws are made. Also there's hierarchy between the laws
themselves in case they are in conflict. I suggest we don't venture into
that. It's not what binds us to this community to begin with.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 4:09 PM Martin Smith  wrote:

> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>

1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor) who is known to
the alleged victim and who can act as mediator to try an resolve it.
3) If 1) and 2) don't work he/she may also bring it to the attention of the
community (e.g. the mailing list). The community is then free to react or
not to react.

The implication that currently, if you're feeling mistreated, it's
impossible to act (respectfully) against harassment seems rather
far-fetched to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

+1 for the KDE CoC from me as well.
Better written, clearer and to the point.

On Thu, Oct 25, 2018 at 8:40 PM André Pönitz  wrote:

> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development
> wrote:
> > We do have a Code of Conduct at KDE for about 10 years now, and this
> hasn't
> > led to abuse of power, suppression of free speech, racism against white
> people
> > or whatever other nonsense people seem to attribute to CoCs nowadays.
>
> The KDE CoC is *friendly*. It contains words like "considerate",
> "pragmatic",
> "support". It doesn't push someone's personal political agenda.  This is a
> completely different beast than the Contributor Covenant that's about
> "enforcing", "reporting", "banning".
>
> I think we'd see much less heat in the discussion if the proposed Qt CoC
> had
> been based on the KDE CoC.
>
> 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] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Thu, Oct 25, 2018 at 1:01 PM Lorn Potter  wrote:

> Those do not mean the same as 'empathy', which is the "ability to
> understand and share the feelings of another", or "put yourself in the
> other persons shoes"
>
> I think empathy is a fine word for this, there is nothing vague about it.
>

Okay, let me rephrase then. Is empathy required or needed? If it's neither
required nor needed, then I see no point in even mentioning it. It'd be one
of those pointless redundancies and empty platitudes people seem to be so
fond of these days. More to the point, is me feeling like crap, because
you're feeling under the blues improve your code, or your perception of the
community? I'd have hard time believing it. I'd much rather see people do
right (and you can codify that) by other people than to mess with
the psychobabble.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

I  think you're over-engineering the whole thing and you don't drive the
point of such a document home. My best suggestion is to simplify (heavily)
the process and the phrasing.

Firstly and most importantly drop the heavy and redundant wording, e.g. "
... pledge to making participation in our project and our community a
harassment-free experience for everyone, regardless of age, body size, ..."
"everyone" is already all those things. Unless your point was to write a
constitution, just state what you mean simply, plainly and succinctly.
Helps in reading, understanding and proceeding to implement. On that note
hardly will I be convinced that a new (or seasoned) contributor waste the
time to read through something that's longer than half a page instead of
diving into the heart of the matter, which is to write code, improve docs
or w/e.

Addendum: There's too much vague phrasing. When I was reading through the
text I read things of the sort:
"Showing empathy towards other community members"
and
"Other conduct which could reasonably be considered inappropriate in a
professional setting"
and what I thought was "What's that nonsense?! empathy?!". What is wrong
with stating it directly - "Don't be mean, respect others."?
Here's what Tero wrote on the boards (shortened the tips about language,
which shrunk it by about 5%-10%) as a guideline for moderators:

*The short moderation and banning guideline for the Qt Forum*
> First, the Qt Community is in general a friendly place. When you applied
> or were called to be a moderator, several other moderators read a good
> section of your posts, and agreed that you are very friendly towards to
> community in addition to being knowledgeable in Qt. Thank you, and keep up
> the friendly attitude!



Always assume that the person asking has a real valid problem. Trolls and
> ranters are very rare here, so it's best to assume that a person sounding
> aggressive is just having a bad day, or that english is their third or
> second language. The language barrier may cause the question to sound
> strange.

 [...]

In general the following types of posts will be deleted
> obvious spam
> 'support' phone numbers
> obviously non-Qt services and sites
> backlink spam (spam with links to a completely non-Qt site, with the
> intention of raising search engine rankings)
> swearing
> completely off topic posting
> posting the same question in multiple subforums (remember to post a note
> on the one you leave up)
> Banning is in place when:
> The user posts harmful spam
> Abusive behaviour, swearing and being offensive
>

It's reasonable, short enough, easy to comprehend and apply.

Secondly, that whole committee thing is somewhat of a stretch in my mind.
It's going to be much more practical to have one contact person to "shuffle
the paper" and consider complaints/issues, answering questions about and
for the community, helping newer persons to get on with the program and so
on. Election can be by majority voting ran for a reasonable time period
(say 1 week) from a pool of proposed candidates. Alternatively, as the
community is somewhat dispersed over different media - forums, mailing
lists, IRC and so on a person for each of the channels mentioned can be
elected. On that note the proposed CoC doesn't take into account that
specific, for one we mostly police ourselves in the forum, and I imagine
people have an operator on IRC, but it's not clear how the committee is
supposed to operate on the different channels, are they to be omnipresent?

Thirdly, and I'll stop with my ramblings, there will always be grating
between people that work on something together for extended periods, no
matter if it's a huge C++ library or some triviality. If you try to stop
all of it, what my feeling of the proposed document is, brace yourselves,
you're going to fail miserably. I'd rather suggest handling the extreme
cases only and leave people blow off steam once in a while. Disruptions to
good order are more often than not correctable by a simple private notice.
Or to quote Sze-Howe Koh:

There are 2 ways to ensure that things don't get done in an open project:
>
>1. Spend so much time molly-coddling everyone such that there is
>little time left to do actual work
>2. Drive so many (potential) contributors away such that there are few
>people left to do actual work
>
> Somewhere in the middle of these two extremes is the sweet spot where
> people are neither molly-coddled nor driven away, and maximal work gets
> done. That is the spot a project wants to reach.


PS
I don't know why that (half-)political argument about women, hiring,
google, and whatnot, spun off but I see no relevance to the document, nor
did I read anything remotely related to it in the text. So let's drop it,
shall we?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Gerrit "no matching cipher found"

[Konstantin Shegunov]

On Wed, Oct 10, 2018 at 8:43 PM Tomasz Siekierda  wrote:

> Hi,
> I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is
> correct. And I've used init-repository script to get going.
>

Hi,
Ran into this a few months ago. Force the cipher through the ssh config and
you should get it going.
Sample follows:
Host codereview.qt-project.org
   Port 29418
   User 
   Ciphers aes256-cbc
   PreferredAuthentications publickey
   IdentityFile 

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

Re: [Development] Configure Qt gerrit git ssh access via Tor on Linux

[Konstantin Shegunov]

Hi Denis,

On Sun, Sep 2, 2018 at 9:34 AM, Denis Shienkov 
wrote:
>
> Could someone help me please?
>

I've run into problems on Debian testing recently and it appears to have
been the same problem as you're having. Perhaps you could try something
like this:

GIT_SSH_COMMAND="ssh -c aes256-cbc" 

It's been a month or so, but as far as I can remember this solved it for me.

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

Re: [Development] Symbol clashes with static Qt libraries

[Konstantin Shegunov]

On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne  wrote:

> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user
> code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g. https://codereview.qt-project.
> org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase.
>

Isn't introducing a private namespace for that purpose an option?
I think it'd fare better than renaming the symbols, and in the end that's
the whole reason for having them in the language, right?
Granted there should be an using clause at the top of the sources that use
those private methods and explicit scoping for public headers (if any), but
that should solve the problem I believe. Also patching it up should be
relatively straightforward.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development