We need to get qt5.git integrated to be able to produce mingw binaries.
Unfortunately there are some issues open which are preventing it at the moment
but let’s hope we could solve those really soon & so on be able to produce all
packages as soon as possible
Br,
Jani
From: development-bounces+
On Tuesday 07 October 2014 23:31:11 Christoph Feck wrote:
> On Tuesday 07 October 2014 23:19:23 Tony Van Eerd wrote:
> > > The problem is serious enough, indeed, that Python 3 has resorted
> > > to a hack where they use a private Unicode range to encode the
> > > bytes between 128 and 255 in string
On Tuesday 07 October 2014 23:19:23 Tony Van Eerd wrote:
> > The problem is serious enough, indeed, that Python 3 has resorted
> > to a hack where they use a private Unicode range to encode the
> > bytes between 128 and 255 in strings that fail normal decoding.
> > I think that putting this hack in
>
> The problem is serious enough, indeed, that Python 3 has resorted to a hack
> where they use a private Unicode range to encode the bytes between 128
> and 255 in strings that fail normal decoding. I think that putting this hack
> into
> QString is unthinkable, and the concept of a platform st
Hi everyone,
any chance to get a hold on a MinGW snapshot of the 5.4.0 beta ?
I personally hate to use Micro$oft stuff and I much prefer the good old shell :)
The snapshot would allow me to decide if I need to open a bug about buttons
background palette on Windows. The code works fine on Linux.
On 07-Oct-14 18:21, Oleg Shparber wrote:
> I cannot get my changes [1] through CI for qtdeclarative/5.4. Originally
> it failed with qquickwindow tests, but now it does not compile on
> Windows CE platform.
>
> Can anyone take a look at the situation?
>
> 1. https://codereview.qt-project.org/96314
Hi,
I cannot get my changes [1] through CI for qtdeclarative/5.4. Originally it
failed with qquickwindow tests, but now it does not compile on Windows CE
platform.
Can anyone take a look at the situation?
1. https://codereview.qt-project.org/96314
Best,
Oleg
On Tuesday 07 October 2014 10:38:47 Kuba Ober wrote:
> Just to be very clear: it is currently impossible to make a truly portable
> file management utility with Qt’s core APIs. Why? Because it will simply
> ignore all file names that it can’t decode when iterating the directory,
> and it won’t be a
El Tuesday 07 October 2014, Tomasz Siekierda escribió:
> For file paths, I feel QString is really enough.
> Changing it to something else because of a few corner cases seems like
> an overkill to me.
Just for the sake of documenting the issue and pointing to this thread if
future questions arise:
On Oct 7, 2014, at 8:30 AM, Julien Blanc wrote:
> On 07/10/2014 12:11, Tomasz Siekierda wrote:
>> For file paths, I feel QString is really enough.
>> Changing it to something else because of a few corner cases seems like
>> an overkill to me. We already have a lot of classes that are connected
>
On Oct 7, 2014, at 6:11 AM, Tomasz Siekierda wrote:
> On 7 October 2014 11:16, Marc Mutz wrote:
>>> Ugh, that begins to sound like Java. Let's have a wrapper for a
>>> wrapper... please don't go that way.
>
>> We have QSize and QPoint and they're used ubiquitously in Qt. But, by your
>> ration
On 07/10/2014 12:11, Tomasz Siekierda wrote:
> For file paths, I feel QString is really enough.
> Changing it to something else because of a few corner cases seems like
> an overkill to me. We already have a lot of classes that are connected
> with paths and the file system (QFile, QFileInfo, QDir,
moin,
to prevent wasting a whole integration cycle on each change in 5.3, i
now locked down staging. please add me as a reviewer when your change
gets approved, and i'll do integration batches every few days (depending
on demand).
you still should fix sufficiently severe issues in 5.3, and the br
On 7 October 2014 11:16, Marc Mutz wrote:
>> Ugh, that begins to sound like Java. Let's have a wrapper for a
>> wrapper... please don't go that way.
> We have QSize and QPoint and they're used ubiquitously in Qt. But, by your
> rationale, everyone should be using two ints instead, so let's remove
Hi all,
There seems to be real issue with qt5.git integration in 'dev' branch.
Someone, please check and fix this.
Br,
Jani
-Original Message-
From: Qt Continuous Integration System (Code Review)
[mailto:gerrit-nore...@qt-project.org]
Sent: 7. lokakuuta 2014 11:08
To: Qt Submodule Upd
Hi Kuba,
Your criticisms are completely valid, and the conclusions you draw from them
are, too. The problems Thiago lists make this a daunting task, but mostly not
because of complexity, but of sheer volume of code that needs to be modified.
I believe it's worth it, but most of us here lack the
On Tuesday 07 October 2014 09:47:19 Tomasz Siekierda wrote:
> >> I’d think that the solution could be to use a dedicated class for file
> >> names, perhaps with a base class for uninterpreted platform strings.
>
> Ugh, that begins to sound like Java. Let's have a wrapper for a
> wrapper... please
On Tue, Oct 7, 2014 at 9:13 AM, Anttila Janne
wrote:
> Hi,
>
> Thanks for your feedback related to qt.io opensource downloads page:
> http://www.qt.io/download-open-source/
>
> The page is now updated based on your comments - the major changes are:
> 1. Automatic download is now completely removed
>>> This was discussed to exhaustion in Qt 5's development process. The
>>> conclusion
>>> is to remain at status quo since there is no good, technical solution.
>>
>> I’d think that the solution could be to use a dedicated class for file
>> names, perhaps with a base class for uninterpreted plat
Hi,
Thanks for your feedback related to qt.io opensource downloads page:
http://www.qt.io/download-open-source/
The page is now updated based on your comments - the major changes are:
1. Automatic download is now completely removed
* Recommended download is still highlighted and you can start dow
20 matches
Mail list logo