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
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
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 conten
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 thre
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
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 -
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 fun
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...
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 engi
> 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 wa
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.
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:
12 matches
Mail list logo
