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

2016-11-20 Thread Giuseppe D'Angelo 
On Sun, Nov 20, 2016 at 9:13 PM, Marco Bubke  wrote:
> Do you think about a wiki where you can comment? I think you want something 
> with the capability to describe, comment,  argument and poll with a version 
> history. Like you described email is a terrible tool for it.

If a wiki allows for all of this, then sure, let's use a wiki. Does
MediaWiki support these features? I've got the impression that
discussion pages are totally independent from the "main" page. The
threading must be somehow manually managed and I don't think there's a
way to mark some argumentative point as "this requires a resolution".

(Maybe the right tool does not exist, but we'll need to settle for
using an existing one "in the right way")

Cheers,

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

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

2016-11-20 Thread Philippe 
On Sun, 20 Nov 2016 19:49:09 +0100
Marc Mutz  wrote:

> I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but 
> failed to take advantage of the STL containers,

...good that STL containers were not used... Look at _this month_ Visual
Studio 2017 announcement:


std::vector has been overhauled for correctness and performance: aliasing 
during insertion/emplacement is now correctly handled as required by the 
Standard, the strong exception guarantee is now provided when required by the 
Standard via move_if_noexcept() and other logic, and insertion/emplacement 
perform fewer element operations.
(https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)


Being the "standard library" does not mean "bug free and equal on all
platforms". Dependencies with other libraries must be careful checked.

Philippe

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

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

2016-11-20 Thread Marco Bubke 
On November 20, 2016 20:39:08 Giuseppe D'Angelo  wrote:

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

Do you think about a wiki where you can comment? I think you want something 
with the capability to describe, comment,  argument and poll with a version 
history. Like you described email is a terrible tool for it. 


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

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

2016-11-20 Thread Giuseppe D'Angelo 
On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen
 wrote:
> the repository has been created.

I would also like to point out that, despite we have a repository, we
still don't have a tool for properly discussing the actual content of
QUIPs.

* Gerrit does not work because comments cannot be threaded, they don't
stick to multiple reviews, and they can be ignored
* Email does not work (it may work for the overall direction, but not
for the in depth discussion) because a single message may cover
multiple discussion points, disrupting the threading, and discussion
points can get ignored (*)

Any idea to how to actually make this work? Try reviewboard maybe?

My 2 cents,
-- 
Giuseppe D'Angelo


(*) This still happens all the time. User A proposes something; user B
replies with "I don't think it works in scenarios X, Y, Z"; user A
counter-replies "but Z is not a scenario we consider" and the
discussion derails about Z. Noone talks about X and Y, which instead
*must* be talked about, for the proposal to be accepted. We need
something that makes it impossible to ignore the comment about X and
Y.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-11-20 Thread Giuseppe D'Angelo 
On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira
 wrote:
>
> Can you remember the list of C++11 features we're allowed to use? We had a
> discussion on the mailing list.

Going back to this particular point: so should this list go into the
QUIPs repository, or in qtbase? (The idea of putting it in qtbase was
to re-use the same branching scheme, so for a given branch you can
know which features you are allowed to use).

Thanks,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-11-20 Thread Thiago Macieira 
Em domingo, 20 de novembro de 2016, às 19:49:09 PST, Marc Mutz escreveu:
> which Qt3D freely uses,
> now, in something called "assimp"

You mean the worst offender of warnings and code quality issues inside Qt? 
Sorry, that's not a good example and doesn't support your cause.

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

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

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

2016-11-20 Thread Marc Mutz 
On Sunday 20 November 2016 12:53:11 André Pönitz wrote:
> So: If you want to argue that using GSL, and std::exception
> would be beneficial for Qt, you might want to start with 
> making a point about the value of the current BC promise.

Right. I wasn't going to attack the BC promise on such a fundamental level, 
but I agree that its value is limited in a world where not even the compiler 
vendors can agree on a platform's C++ ABI.

I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but 
failed to take advantage of the STL containers, with 5.2, when Q_STRINGTABLE 
missed to be merged because it dared to use Boost (which Qt3D freely uses, 
now, in something called "assimp"), and now with the GSL, which promises much 
stronger statig type-checking because the new vocabulary types can be used to 
decalre intend much better, ... With each of these, and probably more, the 
pendulum swings more into the direction of more harm than good for Qt as a 
project. As a consequence, I'm advocating at least reverting the BC guarantees 
to their old meaning of "two versions of Qt are BC if, for a given platform, 
compiler, and set of dependencies, one Qt compiled against these can be 
replaced by the other without breaking code compiled against the former".

There are so many knobs to turn that make two C++ compilates binary 
incompatible, from ms-compatible bitfields, fortran-compatible double 
alignment, to compiler and standard library versions, that for any library to 
try to draw through that messy jungle a line labelled "this is where Qt BC 
begins" is just a logically nonsensical endeavour.

Sometimes, it's just better to compile separate library versions.

Thanks,
Marc

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

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

2016-11-20 Thread Thiago Macieira 
Em domingo, 20 de novembro de 2016, às 08:33:23 PST, Marc Mutz escreveu:
> > Those parts of KDE don't keep BC guarantees. Distros have to rebuild
> > everything when their dependencies change.
> 
> I wonder why we used d-pointers and virtual_hook in, say, libkdepim if it
> doesn't guarantee BC...

There's a difference between breaking BC when Boost is upgraded and in every 
single patch release and even applied bugfix patch.

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

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

Re: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review

2016-11-20 Thread Allan Sandfeld Jensen 
On Sunday 20 November 2016, Nikolaus Waxweiler wrote:
> > Anyway, on the API front. Forcing to autohinter is probably not
> > acceptable. So we could enable stem darkening where native available,
> > but then we need to know if what engine a face is using, or better yet
> > specifically if the engine used right now on this face did stem
> > darkening.
> 
> I was just thinking. Can Qt mix font rendering modes on a face-by-face
> basis? Even without FT_Face_Option(), you can query the font driver  for
> a face and the autohinter for stem darkening as described in [1]. If
> FT_Property_Get returns an error for the property, the driver has no
> means of darkening stems at all. Note that this is a font
> driver/autohinter wide setting, affecting all faces that pass through them.
> 
> So, how about something like this: for each face that should be
> rendered, first query the driver (or the autohinter if it's to be used)
> if it supports stem darkening. If so, turn it on while rendering the
> face and use linear alpha blending and gamma correction (maybe with a
> factor of 1.8 like Adobe recommends). If there is no stem darkening
> support, blend naively. 

Qt can't do that right now, right now it can only be controlled all or nothing 
by QPA platform or font-engine, but controlling it on a face-by-face basis was 
exactly the possible solution I was considering, but it requires exposing the 
data from the face-specific QFontEngine class to the drawing back-end. At 
least for the rasterizing engine. The whole thing first needs some cleanup in 
5.9 though, it has been adjusted a bit too much for separate platforms to 
match native text rendering, and is not very consistent or elegant at the 
moment.

`Allan

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

Re: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review

2016-11-20 Thread Nikolaus Waxweiler 
> Anyway, on the API front. Forcing to autohinter is probably not acceptable. 
> So 
> we could enable stem darkening where native available, but then we need to 
> know if what engine a face is using, or better yet specifically if the engine 
> used right now on this face did stem darkening.

I was just thinking. Can Qt mix font rendering modes on a face-by-face
basis? Even without FT_Face_Option(), you can query the font driver  for
a face and the autohinter for stem darkening as described in [1]. If
FT_Property_Get returns an error for the property, the driver has no
means of darkening stems at all. Note that this is a font
driver/autohinter wide setting, affecting all faces that pass through them.

So, how about something like this: for each face that should be
rendered, first query the driver (or the autohinter if it's to be used)
if it supports stem darkening. If so, turn it on while rendering the
face and use linear alpha blending and gamma correction (maybe with a
factor of 1.8 like Adobe recommends). If there is no stem darkening
support, blend naively. Or: also blend correctly, but use a lower gamma
correction factor (e.g. 1.4 like GDI uses iirc).

As it stands, this would only enable correct rendering for .otf and if
the autohinter is involved. Support for more font drivers could then be
done from within FreeType without source modifications in Qt.

[1]:
https://www.freetype.org/freetype2/docs/reference/ft2-cff_driver.html#no-stem-darkening(cff)
-- Use FT_Property_Get instead, obviously.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-11-20 Thread André Pönitz 
On Sat, Nov 19, 2016 at 10:44:19PM +0100, Giuseppe D'Angelo wrote:
> On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke  wrote:
> I'm terribly sad that this thread has been derailed in an unrelated
> discussion.

Asking about Creator and BC on @dev was a perfect attempt at trolling
as far as I can tell.
 
> Please, could we all *stop* doing that and let's discuss that (*extremely
> important*) matter on another thread.
> 
> Staying on track: I would love to see (again) Creator as a playground for
> how well the GSL can be integrated into a Qt project.

For me it still is one of the main reasons to have Qt Creator at all,
and I still think it serves this purpose well in practice.

For the concrete matter of owner I *personally* see not much a reason
to have it, as for some reason I seemingly rarely ever run into those
unclear ownerships of naked T* and consequently don't understand where
all this hatred comes from. But then, owner is as non-intrusive as
it gets, and since I have a couple of '// owned' or '// not owned'
comments in my code it looks like having that compiler-checkable would
actually make sense. So I would not oppose using owner in Creator
code.

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

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

2016-11-20 Thread André Pönitz 
On Fri, Nov 18, 2016 at 08:37:26PM +0100, Marc Mutz wrote:
> There's no reason for Qt to extend its BC guarantees to other libraries. STL, 
> GSL, Boost, std::exception, you name it. They are outside of Qt's realm and 
> therefore do not fall under the Qt BC rules. As with every other C++ library: 
> if a user wants BC, it's his job to pin libs without BC guarantees to a fixed 
> version. Not Qts.

If Qt *requires* a dependency that does not care about BC and
leaks it into its interface, this effectively voids the value
of Qt's current BC promise for the user, as, as you correctly
stated, the burden of taking care of dependencies is now shifted
to the sholders of a user caring for BC.

Now we can discuss how much of a total loss of value of Qt that
would be. My personal guess on a first approximation is "zero,
because nobody is really affected". Typical users of Qt are:
- people using Qt in a restricted environment that ship their
  application themselves, bundled with everything they use 
  (read "Windows", or "certified environment", or "devices") 
  They are not affected by BC breakages. If they need to update
  stuff they go from one blob to another blob, the only 
  difference Qt BC in that scenario might be is the size of
  the delta blob.
- people using Qt in applications distributed by packaging
  systems (read "Linux distributions"). They are not affected
  by BC breakages.
- people providing packaging systems. They *are* affected. But
  since they already take care of a lot of other dependencies
  not caring for BC, Qt being on one side of the fence or the
  other does not make a fundamental difference.

So: If you want to argue that using GSL, and std::exception
would be beneficial for Qt, you might want to start with 
making a point about the value of the current BC promise.

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