On Wednesday 17 June 2015 08:33:50 Giuseppe D'Angelo wrote:
> On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
>
> wrote:
> > Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for
> > longer. So we're targetting that *Qt 5.6* will be the first LTS release.
>
> Mind to elabor
Ok, given these extra votes, I've just submitted the removal right now and for
5.5.0:
https://codereview.qt-project.org/114503
On Wednesday 17 June 2015 05:33:34 Knoll Lars wrote:
> Yes, let's remove them. The font files shouldn't be part of qtbase for sure.
> We might still decide to package up
Thiago Macieira schreef op 16-6-2015 om 22:49:
> Last year's notes[1]
>
> Qt 5.5 will be the last release to support:
> * GCC 4.6
> * OS X 10.7
> * Windows Vista
> * WIndows Embedded Compact 7
> * QNX 6.5
> * Qt WebKit, Qt Script, Qt Quick 1
Ok, I understan
On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
wrote:
>
> Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for
> longer. So we're targetting that *Qt 5.6* will be the first LTS release.
Mind to elaborate? Why is the "old Qt CI" a requirement or a blocker
for a LTS release?
Yes, let's remove them. The font files shouldn't be part of qtbase for sure. We
might still decide to package up certain fonts in the Qt for device creation
product, but that's totally separate and has nothing to do with our
repositories.
Cheers,
Lars
On 17/06/15 06:35,
"development-bounc
Make that two votes :)
Simon
Original Message
From: Thiago Macieira
Sent: Tuesday, June 16, 2015 22:40
To: development@qt-project.org
Subject: Re: [Development] Fwd: (QTBUG-46655) qt5base: font license files
missing
On Tuesday 16 June 2015 12:28:51 Paul Olav Tvete wrote:
> There is st
On 16/06/2015 6:49 pm, Koehne Kai wrote:
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=theqtcompany.com@qt-
>> [...]
>> If you ask my opinion, 'errorOccurred' sounds like a sensible name.
>
> I concur that errorOccurred() is the most sensible choice.
+1
--
Lorn 'ljp
On Tuesday 16 June 2015 23:32:28 Olivier Goffart wrote:
> On Tuesday 16. June 2015 13:31:51 Thiago Macieira wrote:
> > Please don't use the CI for the test. Compile with MSVC first and only
> > submit your code if it compiled.
> >
> > If you don't have access to MSVC, either get someone to test fo
On Tuesday 16. June 2015 13:31:51 Thiago Macieira wrote:
> Please don't use the CI for the test. Compile with MSVC first and only
> submit your code if it compiled.
>
> If you don't have access to MSVC, either get someone to test for you or
> don't submit.
Isn't the new CI allowing to easily test
Stephen Kelly wrote:
>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>> please don't take that as me trying to shut the discussion down. :)
>
> Cool. Let's wait and see.
This thread has gone way off-topic now, but we gathered a week of opinions
and reasons, and I think
On Tuesday 16 June 2015 13:35:55 Thiago Macieira wrote:
> On Tuesday 16 June 2015 10:27:15 Matthew Woehlke wrote:
> > Ignoring whether or not to use 'auto', there actually *is* a reason to
> > use the static_cast... it communicates that, yes, you really want back
> > an 'int', even if that means a
Last year's notes[1]
Qt 5.5 will be the last release to support:
* GCC 4.6
* OS X 10.7
* Windows Vista
* WIndows Embedded Compact 7
* QNX 6.5
* Qt WebKit, Qt Script, Qt Quick 1
Therefore, we'd like to have a long-term support release that allows people
who can
> On Jun 16, 2015, at 16:52, Matthew Woehlke
> wrote:
>
> On 2015-06-12 17:45, Thiago Macieira wrote:
>> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
On Friday 12 June 2015 08:08:51 André Somers wrote:
> Not available for use are:
> * = default,
> * = deleted,
>>>
>>
On Tuesday 16 June 2015 21:57:53 Giuseppe D'Angelo wrote:
> > * Qt 5.6 will deprecate: QNX 6.5 (QNX 6.6 OK)
> > * Qt 5.6 will deprecate WEC 7, 2013 only.
>
> Deprecate or drop them? From the C++11 thread I understood they will
> be completely dropped due to lack of compilers.
The changelog says "
On Tuesday 16 June 2015 21:50:29 Robin Burchell wrote:
> * Qt 5.6 will deprecate: QNX 6.5 (QNX 6.6 OK)
> * Qt 5.6 will deprecate WEC 7, 2013 only.
> * Qt 5.6: Vista is on life support - patches welcome, it won’t be tested
> * Qt 5.6: OS X 10.8+ (previous 4 releases)
> * Qt 5.6: RHEL 6.6 with devpac
On Tuesday 16 June 2015 17:44:06 Nurmi J-P wrote:
> Given that QGtkStyle is no longer part of the public API in Qt 5, how about
> making it a QStylePlugin and moving it out of QtWidgets?
Sounds like a good idea.
Meanwhile, Debian and the other distros can compile with -no-gtkstyle.
--
Thiago Mac
On Tuesday 16 June 2015 12:28:51 Paul Olav Tvete wrote:
> There is still code in Qt that reads and adds QPF files if they are
> installed, but I do not believe this is commonly used. In any case, if
> someone needs QPF fonts they can get them from other sources than the Qt
> packages. It sounds
On Tuesday 16 June 2015 10:52:16 Matthew Woehlke wrote:
> On 2015-06-12 17:45, Thiago Macieira wrote:
> > On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
> >>> On Friday 12 June 2015 08:08:51 André Somers wrote:
> Not available for use are:
> * = default,
> * = deleted,
> >>
On Tuesday 16 June 2015 10:27:15 Matthew Woehlke wrote:
> Ignoring whether or not to use 'auto', there actually *is* a reason to
> use the static_cast... it communicates that, yes, you really want back
> an 'int', even if that means a conversion loss e.g. because your input
> is a 'double'. (See e.
On Friday 12 June 2015 08:08:51 André Somers wrote:
> Available for use then:
> * Auto
> * decltype
> * nullptr
> * r-value ref
> * lambda
> * class enum
> * explicit overrides
>
> Not available for use are:
> * uniform initialization and constexpr (is broken in VS2013.)
> * Explicit conversions,
On Tue, Jun 16, 2015 at 9:50 PM, Robin Burchell wrote:
> * Deprecation is hard: lots of use of “old"RHEL 6 still going on. At the
> same time, why is there a desire to use the newest Qt on these “old”
> platforms?
Because these platforms constitute big "standards" for development of
a complex sys
Notes I took on the deprecation session follow. If I missed anything, or
misrepresented it in the notes, please chime in -- I was pretty tired
when I was writing this :)
(P.S. Did someone take notes on the QtQuick Performance discussion?)
==
Introduction
* Qt 5 is now a few years old, a lot
On Tue, Jun 16, 2015 at 4:50 AM, Sze Howe Koh wrote:
>
> On 16 June 2015 at 19:28, Kurt Pattyn wrote:
> > Well,
> >
> > you can also think of “on” + , like in: onWindowClosed,
> > onMouseClicked, onBytesReceived, …
> > In the same analogy, you could have onErrorOccurred.
> >
> > Seems very intui
> On 16 Jun 2015, at 16:32, Dmitry Shachnev wrote:
>
> Hi all,
>
> In Debian, we have recently removed the gtk2 platform theme from default
> Qt 5 installation [1], and now I start getting reports about missing icons
> in my Qt 5 application on Debian (currently Qt 5 supports themed icons
> onl
On 2015-06-12 17:45, Thiago Macieira wrote:
> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
>>> On Friday 12 June 2015 08:08:51 André Somers wrote:
Not available for use are:
* = default,
* = deleted,
>>
>> Where are these not supported? I have code that (AFAIK) has been usi
Hi all,
In Debian, we have recently removed the gtk2 platform theme from default
Qt 5 installation [1], and now I start getting reports about missing icons
in my Qt 5 application on Debian (currently Qt 5 supports themed icons
only on KDE and when using the gtk2 platform theme).
>From the discuss
On 2015-06-16 09:33, André Somers wrote:
> Marc Mutz schreef op 16-6-2015 om 15:41:
>> For type conversions, you're supposed to use static_cast on the rhs:
>>
>> auto integer = static_cast(someLongLong);
>
> Sorry, but that just looks silly to me. Why obfusticate the type of the
> variable -
On 2015-06-15 04:18, Marc Mutz wrote:
> On Monday 15 June 2015 08:24:22 Simon Hausmann wrote:
>> A namespace for functions only, no public classes within.
>
> _That_ argument again... :)
>
> Could you explain to me why you think that classes are different from
> functions, pleaae?
With a small
On Tuesday 16 Jun 2015 15:33:00 André Somers wrote:
> Marc Mutz schreef op 16-6-2015 om 15:41:
> > On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
> >>> Note that in a world of auto variables, class names are no longer _that_
> >>> important. Functions are important, they are still visible. But
Hi,
A huge +1 on this, BT support on Windows is long overdue.
While there is certainly more inertia in the windows desktop version
than probably any other Qt supported platform, Microsoft itself is
trying to nudge people into quicker upgrade cycles, and while Win8 has
certainly gotten a pushba
Marc Mutz schreef op 16-6-2015 om 15:41:
> On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
>>> Note that in a world of auto variables, class names are no longer _that_
>>> important. Functions are important, they are still visible. But other
>>> than at initial creation, class names fade to be
Hi everyone,
It might sound weird that while we're trying to get 5.5.0 out I am starting a
discussion about Qt 5.6, but if you look at the release schedule there is not
much time for the feature freeze
https://wiki.qt.io/Qt-5.6-release
One of the items the Windows / WinRT team would really lik
On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
> > Note that in a world of auto variables, class names are no longer _that_
> > important. Functions are important, they are still visible. But other
> > than at initial creation, class names fade to be background.
> >
> > And now you tell me ho
On 16 June 2015 at 19:28, Kurt Pattyn wrote:
> Well,
>
> you can also think of “on” + , like in: onWindowClosed,
> onMouseClicked, onBytesReceived, …
> In the same analogy, you could have onErrorOccurred.
>
> Seems very intuitive to me.
>
> It depends if you want to react to a state or to the eve
Well,
you can also think of “on” + , like in: onWindowClosed, onMouseClicked,
onBytesReceived, …
In the same analogy, you could have onErrorOccurred.
Seems very intuitive to me.
It depends if you want to react to a state or to the event causing that state.
Cheers,
Kurt
> On 11 Jun 2015, at 2
On Sunday 14. June 2015 23.18.18 Thiago Macieira wrote:
> The file qtbase-opensource-src-5.4.2/lib/fonts/README
> states:
> 'Copyright statements and the source of the qpf fonts are located in
> ../../src/3rdparty/fonts'
>
> The directory src/3rdparty/fonts does not exist in qtbase-opensource-
> s
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [..]
> Depends whether or not we make the choice to break the "no stl in abi" rule.
As I am looking at the advantages versus the the disadvantages in using the
standard library I opting for using it. For ex
> Note that in a world of auto variables, class names are no longer _that_
> important. Functions are important, they are still visible. But other than at
> initial creation, class names fade to be background.
>
> And now you tell me how using lots of auto is bad for readability,
> because you neve
On Tuesday 16 June 2015 08:59:11 Knoll Lars wrote:
> >Marc Mutz schreef op 15-6-2015 om 22:26:
> >> On Monday 15 June 2015 21:01:54 André Pönitz wrote:
> >>> if so:
> >>> Please explain how that avoids name clashes.
> >>>
> >> You only need to add the prefix when the compiler tells you. E.g. i
On Mon, Jun 15, 2015 at 08:52:52AM +0200, Simon Hausmann wrote:
> We also do have at this point a duplication of repository dependencies
> in qt.pro as well as in the repository sync.profile. I do believe that
> we can eliminate this dependency without any downside, based on your
> idea of placing
On Friday, June 12, 2015 10:52:35 PM André Pönitz wrote:
> On Fri, Jun 12, 2015 at 12:58:42AM +0200, Marc Mutz wrote:
> > On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> > > That's exactly the kind of situation I was referring to in my previous
> > > mail: This is intentionally introducing
On Monday, June 15, 2015 07:40:07 PM Sergio Ahumada wrote:
> On 15.06.2015 08:52, Simon Hausmann wrote:
> > Perhaps there is a misunderstanding here, so let me confirm also what
> > Joerg
> > said: At this point we're interested in discussion repository
> > dependencies. I understand that are somew
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [...]
> If you ask my opinion, 'errorOccurred' sounds like a sensible name.
I concur that errorOccurred() is the most sensible choice. It also matches the
wording in the existing documentation ('error occ
43 matches
Mail list logo
