> On Nov 9, 2016, at 3:40 PM, Aleix Pol wrote:
>>> we plan to keep it
>>> multiplatform and with no external dependency other than Qt modules (that's
>>> what KDE framework tier 1 means). A big reason is actually that it would be
>>> quite easier to contribute to it.
>>
>> And when we do the wor
On mercoledì 9 novembre 2016 23:25:41 CET, Allan Sandfeld Jensen wrote:
GTK has only just recently implemented HiDPI, much much later than Qt.
What makes you think it is "working well for them"?
I think it's working well just because I didn't hear as many complaints as
QT's, but may be as well
On Wed, Nov 9, 2016 at 6:49 PM, Jake Petroules wrote:
>
>> On Nov 9, 2016, at 7:30 AM, Marco Martin wrote:
>>
>> On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote:
I was planning to keep it a KDE project, probably as a tier 1 framework.
>>>
>>> That seems like a bad idea. Let's submi
On quarta-feira, 9 de novembro de 2016 19:40:14 CST Niccolò Belli wrote:
> > We have plenty of environment variables already. I personally set
> > QT_SCREEN_SCALE_FACTORS to 2 on my 13" 3200x1800 display (font DPI is
> > 216).
> AFAIK QT_SCREEN_SCALE_FACTORS doesn't scale fonts, so you will still
On Wednesday 09 November 2016, Niccolò Belli wrote:
> On martedì 8 novembre 2016 23:02:04 CET, Thiago Macieira wrote:
> > Agreed we need to adjust the formula. I'm not sure a full round
> > down (i.e., an
> > integer division) is what we want. Another option is
> >
> > qRound(dpi / 96.0 - 0.75
Probably file path is too long.
MS improved situation since win10.1607 (up to 32k symbols) but almost
every program today (even from MS) is not able to handle such paths.
They require special handling.
See
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
for more inf
Hi,
I'm having problems compiling 5.8.0 beta from source. It fails when making
qtwebengine.
D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe
-C
D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64
ninja: Entering directory
`D:/qt-everywh
> Agree with meta/quips
+1,
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote:
We have a two factor scaling system. We also scale by DPI.
144/2 == 72 for instance, which happens to be the standard on
Macs. Therefore 144DPI become a normal 2x scaling of standard
72 Mac DPI.
And having 2x with smaller t
On martedì 8 novembre 2016 23:02:04 CET, Thiago Macieira wrote:
Agreed we need to adjust the formula. I'm not sure a full round
down (i.e., an
integer division) is what we want. Another option is
qRound(dpi / 96.0 - 0.75);
That would make:
DPI < 1681x
DPI < 264
Agree with meta/quips
> On Nov 9, 2016, at 10:11 AM, Louai Al-Khanji wrote:
>
> As far as I am concerned meta/quips will do just fine. It’s not worth a
> bikeshed.
>
> Cheers,
> Louai
>
> On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne"
> kai.koe...@qt.io> wrote:
>
>
>
>> -
(resend for the mailing list)
On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote:
On Tuesday 08 November 2016, Niccolò Belli wrote:
1) Always round down. With your current formula a 145ppi
screen gets scaled
by a 2x factor, while every other toolkit (GTK3 for example[3]) star
As far as I am concerned meta/quips will do just fine. It’s not worth a
bikeshed.
Cheers,
Louai
On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne"
wrote:
> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.o
> On Nov 9, 2016, at 7:30 AM, Marco Martin wrote:
>
> On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote:
>>> I was planning to keep it a KDE project, probably as a tier 1 framework.
>>
>> That seems like a bad idea. Let's submit it to Qt so that everyone can
>> benefit and it can be kep
On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote:
> > I was planning to keep it a KDE project, probably as a tier 1 framework.
>
> That seems like a bad idea. Let's submit it to Qt so that everyone can
> benefit and it can be kept better maintained alongside Qt and for all
> platforms.
B
> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, November 09, 2016 4:01 PM
> To: development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
>
> On
On 11/09/16 16:01, Oswald Buddenhagen wrote:
>
> i can offer meta/ as an alternative.
+1
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
> +1 for qt/quips, I don't think of it as a web site thing either.
>
well, i don't want it in qt/ - this is not a generic namespace for stuff
that doesn't fit elsewhere. everything in there *should* be aggregated
by qt5.git (with an
Hi.
I wasn't involved with Charts at its inception, so I don't really know the
original motivations. I suspect the aim was to provide easy to use module for
simple charting use cases without needing 3rd party libraries, but not be the
be-all-end-all charting solution for all users. That's how I
> Now: what should it do ?
Compile the test with additional debugging flags.
On Linux it would be looking like that:
for 10 min (minimum 3000 runs):
Run the test
Run the test with valgrind
Use taskset to reduce CPU affinity to one CPU
Put external load on the CPU to re-arrange thr
On torsdag 3. november 2016 13.50.51 CET Morten Sorvig wrote:
> > On 1 Nov 2016, at 09:41, Robert Iakobashvili wrote:
> >
> > Dear Qt-Management and Developers,
> >
> > People cannot dictate to Qt-software at Mac as filed:
> >
> > https://bugreports.qt.io/browse/QTBUG-56811
>
>
> Hi,
>
> I
Jedrzej Nowacki said:
> As you wrote, in the first iteration of the functionality I would go
> for an easy solution and I would detect just all modifications to
> tests/auto/*
> On the other hand I do not want to have the definition of stress
> testing in Coin code. Every one should be able to run
On Wed, 09 Nov 2016 09:04:23 +, Miikka Heikkinen wrote:
Hi Mikka,
> I’m Qt Charts maintainer. It is true that Charts have been on back
> burner for a good while now, as I’ve been assigned to other tasks, but
> it’s not abandoned by any means.
Maybe you could shed some light on the future of
Hi.
I’m Qt Charts maintainer. It is true that Charts have been on back burner for a
good while now, as I’ve been assigned to other tasks, but it’s not abandoned by
any means. We do welcome third party contributions and I’m certainly willing to
discuss the design and review any contributions.
O
As you wrote, in the first iteration of the functionality I would go for an
easy solution and I would detect just all modifications to tests/auto/* On the
other hand I do not want to have the definition of stress testing in Coin code.
Every one should be able to run it therefore it should be a m
25 matches
Mail list logo