And here's the business part of the latest version of my QSP patch, by popular
request (or not) :)
I've followed your (David's) remark that the actual QExtStandardPaths payload
could be part of QStandardPaths; QExtStandardPaths is now purely header based -
in qstandardpaths.h to be exact.
The
On Sunday January 31 2016 12:10:05 David Faure wrote:
> On Sunday 31 January 2016 11:18:34 René J.V. Bertin wrote:
> > +case QPlatformTheme::IconThemeSearchPaths:
> > +if (QStandardPaths::isXDGLocationsEnabled()) {
> > +return xdgIconThemePaths();
> > +}
>
> I don'
On Sunday 31 January 2016 11:18:34 René J.V. Bertin wrote:
> +case QPlatformTheme::IconThemeSearchPaths:
> +if (QStandardPaths::isXDGLocationsEnabled()) {
> +return xdgIconThemePaths();
> +}
I don't think this requires an if() at all.
It's not like Mac OSX has freed
Hi,
I was just reminded of a related issue. The native Mac platform theme has a
very limited icon theme search path. You can add the XDG-compliant icon
repository to that path, but then almost all buttons will start to show icons:
the platform theme apparently doesn't even check the DialogButto
On Monday 18 January 2016 12:48:34 René J.V. Bertin wrote:
> David,
>
> In your idea of a QSP::addStandardLocation() approach, would that always add
> to a "global" list (= affect all subsequent calls to standardLocations()), or
> would you also consider a variant that only affects the next call
David,
In your idea of a QSP::addStandardLocation() approach, would that always add to
a "global" list (= affect all subsequent calls to standardLocations()), or
would you also consider a variant that only affects the next call?
Also, if you think we should avoid thinking of this as "providing
On Monday January 11 2016 18:58:08 David Faure wrote:
Sorry for the silence, I'm trying to force myself to devote my attention to
other things that should have priority right now.
> We can get cohesion without subclassing QApplication, that's for sure.
The question is how. I'm not saying it's i
On Sunday 10 January 2016 21:52:13 René J.V. Bertin wrote:
> You meant inter-INdependent I suppose?
Yes, of course.
> Sadly I had completely forgotten I'd ever heard about KDE, 4 years ago (and
> wasn't where I was ATM, development wise). If I'd have known what I know now
> I'd have defended K
On Sunday January 10 2016 18:43:25 David Faure wrote:
> Otherwise where do you draw the line? You say "One or two", does that mean
> that when you get to three frameworks
> you suddenly switch to case 2? Of course not ;)
Indeed, but see below.
> In the qt5/kf5 world, there is only ONE kind of a
On Sunday 10 January 2016 17:04:14 René J.V. Bertin wrote:
> On Saturday December 12 2015 19:32:34 David Faure wrote:
> > I didn't mean switching at runtime. I mean using KF5 in Qt apps.
> > I'm pretty sure we had this discussion already but here we go again:
> > If a pure Qt app (say Scribus) has
On Saturday December 12 2015 19:32:34 David Faure wrote:
Somehow I never got around to answering this. Also directing this back to the
lists.
> I didn't mean switching at runtime. I mean using KF5 in Qt apps.
> I'm pretty sure we had this discussion already but here we go again:
> If a pure Qt
Alex Merry wrote:
> I'm not sure what you mean by "incremental", though. All CMake variables
> overwrite their previous values when you set them, so you have to
> explicitly include the old value when you set them, and you can't really
> do this from the command line.
That's what I was getting at
On 2015-11-28 21:53, René J. V. Bertin wrote:
BTW, not that it's already being used, but is
CMAKE_EXE_LINKER_FLAGS_INIT
incremental or does one have to accumulate all elements first and use a
single -
DCMAKE_EXE_LINKER_FLAGS_INIT=XX argument?
CMAKE_EXE_LINKER_FLAGS_INIT is a bit special. You
Alex Merry wrote:
> I'd be fine with adding something to KDECompilerSettings as long you had
> to explicitly ask for it to be enabled when running CMake. But if you're
> doing that, why not set CMAKE_EXE_LINKER_FLAGS_INIT directly on the
> CMake command line, or use the LDFLAGS env var? I assume
On 2015-11-28 19:25, René J.V. Bertin wrote:
On Saturday November 28 2015 15:29:00 David Faure wrote:
Otherwise, the next best idea is to get ECM to add your activator to
all link lines
automatically, e.g. by adding it to CMAKE_EXE_LINKER_FLAGS or
whatever.
This for sure beats editing every lin
On Saturday November 28 2015 15:29:00 David Faure wrote:
>I still have to see proof that a "pure Qt application" installed with MacPorts
>really cares about where QSP points to - apart from the obvious migration issue
>if this ever changes.
The question is not whether individual applications care
On Saturday 21 November 2015 17:17:49 René J.V. Bertin wrote:
> That would mean having 2 different Qt5 installs in MacPorts; one for pure Qt
> applications that are expected to behave "natively"
I still have to see proof that a "pure Qt application" installed with MacPorts
really cares about wher
On Saturday November 21 2015 12:59:40 David Faure wrote:
>I still don't see why you can't just patch Qt on macports (given that you're
>already patching it anyway) rather than having to add something to each and
>every link line in KF5,
That would mean having 2 different Qt5 installs in MacPort
18 matches
Mail list logo
