This is a known issue (as in, Ossi and I know about it) but I don't know if
there's an open QTBUG for it (there should be).
Did you first notice this in 5.9.2 or an earlier release?
> On Oct 22, 2017, at 3:34 PM, Thiago Macieira
> wrote:
>
> On Sunday, 22 October 2017 14:11:39 PDT Nuno Santos
On Sunday, 22 October 2017 14:11:39 PDT Nuno Santos wrote:
> I have noticed a new behaviour I wasn’t having on Qt 5.7.1. When I run or
> simply build a Qt iOS app, qmake command is called. This is actually taking
> quite long (around 15s to complete).
>
> My project contains a lot of files but I h
Hi,
I have just tried Qt 5.9.2 as I have been still working with Qt 5.7.1
I have noticed a new behaviour I wasn’t having on Qt 5.7.1. When I run or
simply build a Qt iOS app, qmake command is called. This is actually taking
quite long (around 15s to complete).
My project contains a lot of fil
On Sunday, 22 October 2017 10:17:50 PDT Christian Ehrlicher wrote:
> Am 22.10.2017 um 18:38 schrieb Thiago Macieira:
> > There's no function to decode this in QString or QByteArray for that
> > matter. This has nothing to do with fromUtf8().
> >
> > The decoding has to be done manually.
>
> Thx f
> On 22. Oct 2017, at 15:42, Sze Howe Koh wrote:
>
> On 22 October 2017 at 20:21, Jeffrey Brendecke
> wrote:
>>
>> On 21. Oct 2017, at 15:56, Jeffrey Brendecke
>> wrote:
>>
>> Is it possible to access the latest development branches for Qt versions
>> after 5.10?
>>
>> If so, where do I get
Hi Guiseppe,
If that line was left out the dialog would return just "text" (i.e.
without the suffix).
Thanks,
Dan.
On 22/10/17 19:25, Giuseppe D'Angelo wrote:
Hi,
Il 21/10/2017 20:39, Dan Allen ha scritto:
fileDialog.setDefaultSuffix("txt");
Just wondering, what happens without thi
Hi,
Il 21/10/2017 20:39, Dan Allen ha scritto:
fileDialog.setDefaultSuffix("txt");
Just wondering, what happens without this line?
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt,
Il 22/10/2017 14:21, Jeffrey Brendecke ha scritto:
Do I need to be registered anywhere as a user in order to get access? I
just want read-only access at this time.
$ git clone https://github.com/qtproject/qt5.git --branch dev
By the way, why are you cloning from github, and not the official
Am 22.10.2017 um 18:38 schrieb Thiago Macieira:
There's no function to decode this in QString or QByteArray for that matter.
This has nothing to do with fromUtf8().
The decoding has to be done manually.
Thx for the information, decoding should be easy. I just did not want to
reinvent the wheel
On Sunday, 22 October 2017 03:48:12 PDT Christian Ehrlicher wrote:
> Hi,
>
> Is there a Qt-way to decode hex escaped values in a QString? In bug
> 61420 the udev filename in /dev/disk/by-label/ is encoded with
> ID_FS_LABEL_ENC which means all non-latin1 characters are hex-escaped.
> But since QFi
On 22 October 2017 at 20:21, Jeffrey Brendecke
wrote:
>
> On 21. Oct 2017, at 15:56, Jeffrey Brendecke
> wrote:
>
> Is it possible to access the latest development branches for Qt versions
> after 5.10?
>
> If so, where do I get the source and are there compilation/installation
> instructions bey
> On 21. Oct 2017, at 15:56, Jeffrey Brendecke
> wrote:
>
> Is it possible to access the latest development branches for Qt versions
> after 5.10?
>
> If so, where do I get the source and are there compilation/installation
> instructions beyond what is found here:
>
> https://wiki.qt.io/Bui
Hi,
Is there a Qt-way to decode hex escaped values in a QString? In bug
61420 the udev filename in /dev/disk/by-label/ is encoded with
ID_FS_LABEL_ENC which means all non-latin1 characters are hex-escaped.
But since QFileInfo::fileName() already returns a QString I can't use
QString::fromUtf8
With that version of Mint it was 100% reproducable and there was a long
list of people on the BOINC forum victimized by it. The problem was
never fixed in Mint 17 64-bit. Most of us ended up identifying one
64-bit distribution where a certain combination of things could get it
to work and jumpi
>From a cursory overview, it seems that the issue was assumed to not be
>reproducible anymore, and no one reported to the contrary.
What more do you want?
> On Oct 22, 2017, at 11:35 AM, Roland Hughes
> wrote:
>
> Nothing to do with Qt but given our previous given out previous conversation
>
Nothing to do with Qt but given our previous given out previous
conversation on how OpenSource bugs are left to rot then mass
exterminated, this one just showed up in my inbox this morning. It's
noteworthy because, yet again, to avoid working on something the
maintainer flagged the report "Inco
16 matches
Mail list logo
