> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Alexander
> Blasche
> I don't think we can drop all 32bit support. I do believe MSVC 2017 should be
> part of the deal though. That's a good suggestion. Keeping t
23.11.2016, 05:32, "Thiago Macieira" :
> On quarta-feira, 23 de novembro de 2016 02:06:14 PST Jake Petroules wrote:
>> > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can
>> > drop
>> > the 32-bit binary build in time for 5.9.
>> >
>> > Otherwise, if we have to wait for
> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also
> be prepared to have it available for 5.9, so I propose:
>
>
On quarta-feira, 23 de novembro de 2016 02:06:14 PST Jake Petroules wrote:
> > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can
> > drop
> > the 32-bit binary build in time for 5.9.
> >
> > Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't
> > drop 32
> On Nov 22, 2016, at 5:58 PM, Thiago Macieira
> wrote:
>
> On terça-feira, 22 de novembro de 2016 16:07:25 PST Thiago Macieira wrote:
>> On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote:
- For MinGW I propose to start delivering 64 bit binary packages instead
On terça-feira, 22 de novembro de 2016 16:07:25 PST Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote:
> > > - For MinGW I propose to start delivering 64 bit binary packages instead
> > > of 32 bit one & start using MinGW 6.x (6.2?)
> >
> > Does this
On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote:
> > - For MinGW I propose to start delivering 64 bit binary packages instead
> > of 32 bit one & start using MinGW 6.x (6.2?)
> Does this make sense when we're still delivering 32-bit MSVC packages? I'd
> opt to keep 32-bit o
On quarta-feira, 23 de novembro de 2016 00:07:35 PST Allan Sandfeld Jensen
wrote:
> Can't we statically link to it, so that it doesn't matter which version the
> application is using?
No, same problem, which is exactly what the Linux distros are doing wrong.
C++ requires certain symbols to be sh
> On Nov 22, 2016, at 3:42 AM, Jani Heikkinen wrote:
>
> Hi all,
> We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet
> :) There are some things to be agreed already now:
>
> - Qt 5.9.0 Feature Freeze
> - Changes in supported platforms/configurations
>
> So first of a
On Tuesday 22 November 2016, Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 19:21:40 PST Giuseppe D'Angelo wrote:
> > * pros:
> > ** You can use Qt compiled against either libc++ or libstdc++, with
> > "the other one", without recompiling Qt.
> >
> > * subjective cons:
> > ** apar
On terça-feira, 22 de novembro de 2016 19:21:40 PST Giuseppe D'Angelo wrote:
> * pros:
> ** You can use Qt compiled against either libc++ or libstdc++, with
> "the other one", without recompiling Qt.
> * subjective cons:
> ** apart from Qt, noone does that, why should Qt be special in that regard?
On Tue, Nov 22, 2016 at 12:33 PM, Marco Bubke wrote:
> I think I miss some but feel free to extend the list
Does Qt need to keep BC across incompatible standard C++ library
implementations? (Independently from the long term/short term ABI
breaks)
This does not mean "is Qt affected by a BC break
On martes, 22 de noviembre de 2016 11:33:55 ART Marco Bubke wrote:
[snip]
> Long Term ABI compability(5-10 years):
>
>
> * easier life of Linux packager
>
> - con: you can use Flatpack in many case (disputed)
The amount of flatpacks needed would easily become also a problem (see my mail
with
On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
[snip]
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack, so I can
> update my heavily used Applications and being not dependent on
> distribution
On lunes, 21 de noviembre de 2016 17:20:09 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > Now I have a question: how will the Qt community take that a distro
> > changes
> > the SONAME of a lib from, let's say, 5
On terça-feira, 22 de novembro de 2016 11:25:45 PST Marco Bubke wrote:
> I don't see the problem to describe it in text, like CSS is doing. Actually
> it has the advantage to be independent of drawing systems. If you code it
> in C++ it is hard to translate that to OpenGL etc.
For 20 years we have
On terça-feira, 22 de novembro de 2016 11:33:55 PST Marco Bubke wrote:
> Short Term ABI compability(1-2 years):
>
>
> * better bug fixing
By a very small margin. We've got 20 years of experience fixing bugs without
breaking ABI.
> * faster development
Unproven.
> * faster adoption of standar
Hi,
(resending here instead of qt-creator@, as hinted to by Eike)
two questions to anyone working on/with QCH files:
Q1: what would be a good system path pattern (on *nixoid systems) for Qt-based
libraries to install their QCH files to?
Q2: And would/could there be some way to have 3rd-party Q
> -Original Message-
> From: Lars Knoll
> I added him to the gerrit Approver group. Alex can do any adjustments to Jira
> that are required.
Done.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/ma
As long as we're still merging from 5.6 to 5.8, this is probably a good way to
handle things. But since we're now having this on the table, I still believe
that we need to consider when to stop doing merges from 5.6 to newer versions.
This has been discussed in length at the contributor summit,
On Tue, Nov 22, 2016 at 01:40:44PM +0100, Liang Qi wrote:
> Then there will be batches of merges 5.6->5.7->5.8 before the final down
> merge 5.8->5.8.0. If your changes are after those merges, it will miss the
> 5.8.0 release normally.
> (cherry-pick only for the critical things after the final do
> On 16 Nov 2016, at 17:22, Niccolò Belli wrote:
>
> Hi Morten,
> I'm sorry, I missed your reply.
>
>> RoundPreferFloor Round up for .75 and higher
>> RoundPreferFloor is the new default. Do you think this is sufficient?
>
> qFloor would help for my monitor, of course.
>
> Unfortunately the
Hi again
The CI seemed to suffer from the same problem as our personal instances of the
CI did: hardware was not allocated per request, nor did cleaning up of VMs
work. So my best bet is that something went bad on vSphere's side. What
exactly, we don't know, but a restart of the CI seemed to do
Then there will be batches of merges 5.6->5.7->5.8 before the final down
merge 5.8->5.8.0. If your changes are after those merges, it will miss the
5.8.0 release normally. (cherry-pick only for the critical things after the
final down merge.)
And I plan to do the merges during weekends, if CI/COIN
Hi,
I added him to the gerrit Approver group. Alex can do any adjustments to Jira
that are required.
Congratulations, James!
Cheers,
Lars
On 22/11/16 13:08, "Rafael Roquetto" wrote:
Hello,
Since there were no objections, could we please grant the appropriate rights
to James?
Hello,
Since there were no objections, could we please grant the appropriate rights
to James?
Thanks,
Rafael
On Tue, Nov 01, 2016 at 08:14:19AM +, Lars Knoll wrote:
> +1 from my side. Another hand on QNX will be very welcome :)
>
> Cheers,
> Lars
>
>
>
>
> On 01/11/16 00:01, "Developmen
+1 to this. First and foremost we're looking for a way to summarize and
document the outcome of discussions and decisions made. That's what QUIPs are
for.
Arguing about whether gerrit is the perfect tool for reviewing QUIPs is besides
the point. It is a tool that'll work better than email discu
Hi all,
We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :)
There are some things to be agreed already now:
- Qt 5.9.0 Feature Freeze
- Changes in supported platforms/configurations
So first of all let's agree the feature freeze date: I propose to have the FF
1.2.2017
Hi
I try to gather all arguments so they don't get lost:
Short Term ABI compability(1-2 years):
* better bug fixing
* faster development
* faster adoption of standards
- con: we don't want to adapt them because our solution is better
Long Term ABI compability(5-10 years):
* easier li
On November 22, 2016 08:17:57 Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote:
>> So you say it it does not work because of themeing support? Isn't Qt
>> Controls 2 not anymore providing them too. And is there no technical
>> solutions for that? Like
> On 21 Nov 2016, at 21:11, André Pönitz wrote:
>
> QUIPs were not meant to require new or different tooling, and I still
> believe such will be needed.
Me too.
See? we have consensus. ;-)
___
Development mailing list
Development@qt-project.org
h
31 matches
Mail list logo
