On Saturday 19 November 2016 22:30:51 Thiago Macieira wrote:
> Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu:
> > You see, this is a perfect example of why we _don't_.
> >
> >
> >
> > (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or
> > even 3). It has
On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke wrote:
> Hi
>
>
> This is a Qt Creator topic only so sorry to disturb every body else.
>
>
> Like you maybe have learned there are C++ Core Guidelines. They are
> already very comprehensive. What about basing the Qt Creator Code Style on
> it?
>
>
> I
Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu:
> You see, this is a perfect example of why we _don't_.
>
> (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or even
> 3). It hasn't been a problem for KDE to keep BC guarantees comparable to
> what Qt does.
19.11.2016, 09:46, "Marc Mutz" :
> On Saturday 19 November 2016 02:17:27 Konstantin Tokarev wrote:
>> > If we do nothing else, we should at least use owner whereever
>> > possible.
>>
>> Wouldn't it be a better idea to use standard language feature to indicate
>> ownership, i.e. std::unique_p
On Sat, 19 Nov 2016 21:08 +0100
Kevin Kofler wrote:
> Alexander Nassian wrote:
>> In my personal opinion I don't care much about BC but I'm happy that it
>> blocks
> > STL usage because its brutally unnatural and I stumbled so often over
> > different behaviors of it on different platforms and
Alexander Nassian wrote:
> Will there be now 10 BC discussions every year? At least it feels like.
> Why can't it be decided and then accepted by everyone as is? In my
> personal opinion I don't care much about BC but I'm happy that it blocks
> STL usage because its brutally unnatural and I stumble
On Saturday 19 November 2016 14:18:20 Иван Комиссаров wrote:
> Still, we need those guarantees not to rebuild whole KDE packages in linux
> distros each time new Qt version (or new stdlib version if we’ll support
> std:: in API) is released (also, users should reinstall those packages
> too)
You s
Em sábado, 19 de novembro de 2016, às 13:07:04 PST, Marc Mutz escreveu:
> As soon as someone explains to me what the material difference is between a)
> supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting
> mixing release and debug runtimes on Windows,
libc++ and libstdc++ a
Em sábado, 19 de novembro de 2016, às 13:00:58 PST, Marc Mutz escreveu:
> That's how this came up: it prevents the use of the GSL in Qt
And as Marco points out, this thread is NOT about GSL in Qt. It's about
(maybe) GSL in Qt Creator.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Softwa
Em sábado, 19 de novembro de 2016, às 10:34:36 PST, Alexander Nassian
escreveu:
> Will there be now 10 BC discussions every year?
No, that's why we need a QUIP for it so that we don't rediscuss it every year,
unless the circumstances change.
--
Thiago Macieira - thiago.macieira (AT) intel.com
> I am just curious from a philosophical point of view how come stem
> darkening is even needed. Gamma-corrected blending might end up
> paler, but it should be a more correct result, so it just odd that it
> looks wrong and that a compensation is needed. Somewhere we must have
> done something t
On Saturday 19 November 2016, Nikolaus Waxweiler wrote:
> >> Correct font rendering with linear alpha blending and gamma correction
> >> can make text look pale like reported in
> >> https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math
> >> behind it works out. Stem darkening compens
IMO, we can mix libc++/libstd because we have some BC guarantees, not we have
BC guarantees because we *need* to mix them. There’s no real difference between
debug/release and libc++/libstd.
Still, we need those guarantees not to rebuild whole KDE packages in linux
distros each time new Qt versi
On Saturday 19 November 2016 10:22:18 Иван Комиссаров wrote:
> Maybe we should start another thread about BC?
> I'm not convinced that MacOS is the only system when mixing libc++/stdlib
> makes sence. On linux you can do the same.
As soon as someone explains to me what the material difference is b
On Saturday 19 November 2016 10:34:36 Alexander Nassian wrote:
> Will there be now 10 BC discussions every year?
No, just one for each time Qt suffers more from this policy. :)
That's how this came up: it prevents the use of the GSL in Qt. The STL was
really just for simile. This is about the GS
>> If the new FT_Face_Option() is present, FT can do stem darkening on
>> (almost entirely) all outline fonts :) The toolkit just has to invoke
>> the function on all FT_Faces to be rendered.
>
> But will stem darkening work with the bytecode interpreter?
It won't until I implement it in the True
On Saturday 19 November 2016, Nikolaus Waxweiler wrote:
> > Anyway from an API point of view, the easiest implementation would be if Qt
> > could read on initialization if freetype can do stem darkening on all
> > outline
> > fonts. Since it can't do that currently, an alternative would be to be
The problem is that Qt stuck at some point.
We can’t use STL in our API, so we forced to have QVector, …, QSharedPointer,
On the other hand, we doesn’t develop those classes, because stl already have
them. So, we’re missing QUniquePtr, qMakeShared, append(T&&) (yeah, COW, i
know) and so on.
Will there be now 10 BC discussions every year? At least it feels like. Why
can't it be decided and then accepted by everyone as is? In my personal opinion
I don't care much about BC but I'm happy that it blocks STL usage because its
brutally unnatural and I stumbled so often over different beha
Maybe we should start another thread about BC?
I'm not convinced that MacOS is the only system when mixing libc++/stdlib
makes sence. On linux you can do the same. If we will use stl, the Qt
version installed from packages can't be used for development, you should
use libc++/stdlib Qt version from
20 matches
Mail list logo
