On Wednesday November 11 2015 20:37:36 Petroules Jake wrote:
> What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so
> we could have a little more fine grained control. Maybe a user WANTS to write
> to locations in the local domain instead of the user domain (and in some
>
On Nov 11, 2015, at 12:21 PM, David Faure mailto:fa...@kde.org>>
wrote:
On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote:
Feel free to do whatever you like for test mode but do not change the existing
writable paths.
Jake, I would like to understand why you say that. As the QSP auth
On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote:
> Feel free to do whatever you like for test mode but do not change the
> existing writable paths.
Jake, I would like to understand why you say that. As the QSP author and
maintainer,
I am 100% sure that the value of writableLocation(x
On Wednesday 11 November 2015 19:07:17 David Faure wrote:
> On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote:
> > I mean the API returns a single value, not a list.
>
> Yes, and the value returned by writableLocation() is supposed to be
> user-specific (something under $HOME) rather tha
On Nov 11, 2015, at 8:20 AM, René J.V. Bertin
mailto:rjvber...@gmail.com>> wrote:
On Wednesday November 11 2015 16:03:31 Petroules Jake wrote:
I don't understand, what do you mean with "there is only one location"?
I mean the API returns a single value, not a list. However, READable locations
On Wednesday November 11 2015 19:07:17 David Faure wrote:
> Yes, and the value returned by writableLocation() is supposed to be
> user-specific
> (something under $HOME) rather than system-wide.
Agreed.
>
> So /Applications should be in QSP::standardLocations(ApplicationsLocation)
> but QSP::w
On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote:
> I mean the API returns a single value, not a list.
Yes, and the value returned by writableLocation() is supposed to be
user-specific
(something under $HOME) rather than system-wide.
So /Applications should be in QSP::standardLocatio
On Tue, Nov 10, 2015 at 11:39 PM, Friedemann Kleint <
friedemann.kle...@theqtcompany.com> wrote:
> Hi,
>
> >I don't see tickets in Jira for any of these.
>
> Please do not create unrelated, single tickets for each issue. Previously,
> we had https://bugreports.qt.io/browse/QTBUG-40277 "Adapt style
On Wednesday 11 November 2015 13:22:16 Massimo Callegari wrote:
> 2- the configure script in the main folder gives an error on Linux. I
> believe it has something to do with dos2unix carriage return. I had to copy
> the one from 5.5.1 to build.
.7z and .zip are meant for windows, so the text files
On Wednesday November 11 2015 16:03:31 Petroules Jake wrote:
>I don't understand, what do you mean with "there is only one location"?
>
>I mean the API returns a single value, not a list. However, READable locations
>will return a list containing both $HOME/Applications and /Applications
Ah. I h
On Nov 11, 2015, at 7:53 AM, René J.V. Bertin
mailto:rjvber...@gmail.com>> wrote:
On Wednesday November 11 2015 15:32:20 Petroules Jake wrote:
No, there is only one location so it must remain /Applications as expected by
anyone on the OS X platform.
I don't understand, what do you mean with "
On Wednesday November 11 2015 15:32:20 Petroules Jake wrote:
>No, there is only one location so it must remain /Applications as expected by
>anyone on the OS X platform.
I don't understand, what do you mean with "there is only one location"?
It is also expected that regular users do not have wr
On Nov 11, 2015, at 7:13 AM, René J.V. Bertin
mailto:rjvber...@gmail.com>> wrote:
On Wednesday November 11 2015 15:52:33 David Faure wrote:
Cross-posting on Qt's development ML because it seems more than relevant there.
To put things in context: this discussion on kde-frameworks-devel was star
On Wednesday November 11 2015 15:52:33 David Faure wrote:
Cross-posting on Qt's development ML because it seems more than relevant there.
To put things in context: this discussion on kde-frameworks-devel was started
because an autotest from KService deleted a good chunk from my /Applications
di
Hi Frederik,
... and everyone else maintaining the CI.
On Wednesday 11 November 2015 14:45:27 Frederik Gladhorn wrote:
[...]
> Long story short, we did a lot of fixing and hope to be back with full
> force. Just now we have the "dev" branch still locked down to make sure we
> are back to normal,
Hi all,
for those submitting patches to Qt the last few days were actually not very
rewarding since the continuous integration hasn't been working really.
I really hope that we're back on track, since Monday we had all kinds of
things coming together to hit us one after the other.
Since we want
And for us, distributions, we need at least splitted source codes.
We just CAN'T test our packages the way is deployed now.
On Wed, Nov 11, 2015 at 11:22 AM, Massimo Callegari <
massimocalleg...@yahoo.it> wrote:
> Hi, I think there something wrong with the sources package Nov 10th (I
> downloade
Hi, I think there something wrong with the sources package Nov 10th (I
downloaded the 7z one)
1- the folder name is 'releaseexporttools_src_work_win" instead of
"qt-everywhere-opensource-5.6.0"
2- the configure script in the main folder gives an error on Linux. I believe
it has something to do
> On 11 Nov 2015, at 01:40, Adam Light wrote:
>
> I built Qt 5.6 (latest from the 5.6 git branch as of this morning) and tested
> our application with the build on Windows 10. I'm calling
> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> before the QApplication is created.
>
> I do
On 11/11/15 00:41, "Development on behalf of Marc Mutz"
wrote:
>On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote:
>> Likewise, Marc is trying to use std::declval and type traits
>> in exception specification [https://codereview.qt-project.org/140132/]
>
>declval is in use for excepti
20 matches
Mail list logo
