I want to point this out:
On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
It's still March 31st.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology
On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
> The requirement for
> Windows 10 should not be a problem, since the upgrade is free anyway.
Oh, yes, it is. The problem is not the cost. The problem is the permission to
use it. Many companies' IT departments are slow to
I totally applaud the initiative. Should we go a step further, and make
Windows 10 a requirement for building Qt for any platform? The OS ships on
most new PCs, and cross-compilers and sysroots for other platform targets
are pretty much ubiquitous nowadays. I realize there may be a slight
As you may know, Lars is leading an effort to modularize the build
system. One of the big headaches we have is that Windows uses a completely
separate configure.exe, leading to a lot of duplicated effort.
With the latest announcement from Microsoft, everything changes. Now that
bash is natively
[image: Mic Drop]
No suggestions at all? :(
I am stuck here and without Webkit, I cannot build digikam.
On Thu, Mar 31, 2016 at 2:25 PM, Partha Bagchi wrote:
> I seem to have hit another snag. Hoping someone can point to a solution.
> In my build process, I am getting the
Thiago Macieira wrote:
> git diff misses the parent commit ID and the commit message. The output from
> git format-patch has the commit message, but still misses the parent commit
> ID.
So? A system that accepts patches rather than commits will evidently need and
provide a mechanism to enter at
On quinta-feira, 31 de março de 2016 08:01:54 PDT Knoll Lars wrote:
> >Why would they need to deal with 5.6.0 specifically?
> >As you said in another mail, 5.6 is LTS, not 5.6.0
>
> I’m with Olivier here. We will not support 5.6.0 in three years anymore.
> What we will support is 5.6.x (x being
I seem to have hit another snag. Hoping someone can point to a solution. In
my build process, I am getting the following error:
mingw32-make[2]: Entering directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
( test -e Makefile.WebCore.DerivedSources ||
Z:/src/kde/qt5/qtbase/bin/qmake.exe
On Wednesday, 30 March 2016 18:14:38 CEST, Konstantin Tokarev wrote:
New UI is not required to use these features
Inline editting is only available in 2.11, and the old change screen is
gone in 2.11, too.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
On Wednesday, March 30, 2016 09:34:40 AM Sean Harmer wrote:
> Hi All,
>
> I'd like to nominate Volker Krause for approver status. Volker is one of the
> main authors of GammaRay, is very active in the Qt Automotive sphere where
> he leads up KDAB's contributions, and has touched many parts all
+1
On 30 mars 2016, at 10:34, Sean Harmer wrote:
> Hi All,
>
> I'd like to nominate Volker Krause for approver status. Volker is one of the
> main authors of GammaRay, is very active in the Qt Automotive sphere where he
> leads up KDAB's contributions, and has touched many
On Wednesday, March 30, 2016 10:23:35 PM CEST Konstantin Tokarev wrote:
> Hello,
>
> Are there any plans to reimplement QThreadStorage via thread_local for
> compilers which support it?
Why not use thread_local _instead of_ QThreadStorage in user code, where
applicable?
--
Milian Wolff |
On Wednesday, March 30, 2016 09:34:40 AM Sean Harmer wrote:
> Hi All,
>
> I'd like to nominate Volker Krause for approver status. Volker is one of the
> main authors of GammaRay, is very active in the Qt Automotive sphere where
> he leads up KDAB's contributions, and has touched many parts all
Am Mittwoch, 30. März 2016, 22:23:35 CEST schrieb Konstantin Tokarev:
> Hello,
>
> Are there any plans to reimplement QThreadStorage via thread_local for
> compilers which support it?
QThreadStorage is already implemented with __thread which is a bit like
thread_local before it existed.
On 31/03/16 08:38, "Development on behalf of Olivier Goffart"
wrote:
>Am Mittwoch, 30. März 2016, 21:04:50 CEST schrieb Thiago Macieira:
>> On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier
On quarta-feira, 30 de março de 2016 22:23:35 PDT Konstantin Tokarev wrote:
>> Hello,
>>
>> Are there any plans to reimplement QThreadStorage via thread_local for
>> compilers which support it?
Thiago Macieira replied:
> I haven't investigated whether it's possible. Probably not.
Konstantin: try
On 03/31/2016 12:10 AM, Olivier Goffart wrote:
The question is rather, the Qt creator that will be release in 2 years will
maybe want to use these macros to auto complete signals/slots and properties.
I would assume some people would still have a LTS version of Qt which would
then be, say Qt
Am Mittwoch, 30. März 2016, 21:04:50 CEST schrieb Thiago Macieira:
> On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote:
> > The question is rather, the Qt creator that will be release in 2 years
> > will
> > maybe want to use these macros to auto complete signals/slots and
>
I had previously posted some issues I found with the new QChart system.
I haven't heard back from anyone.. Is there a better place to post usage issues?
Scott
___
Development mailing list
Development@qt-project.org
19 matches
Mail list logo