Hi,
I think our two views of this topic are too contrary to come to
some consense, therefore I just want to answer your technical questions
and leave the rest as is.
Others that care about getting their applications to Mac can still tell their
opinion,
this is as said anyways only mine, therefor
On Thursday October 15 2015 09:14:42 Christoph Cullmann wrote:
>> KDE and its Frameworks and KF5 successors EMBRACE file-sharing between
>> applications, utilities and libraries.
>Actually, I here already disagree.
Hmmm?
>At least some KDE application developers like me or the Krita team want is
Hi,
> Hi Christoph, René and Samuel,
>
> First of all, gentlemen, let's not argue and get hot under the collar. The
> only
> way we are going to get anywhere is by working together, helping each other
> and exchanging information.
Sure, please, nobody should feel insulted, I just stated my opin
On Wednesday October 14 2015 23:46:14 Christoph Cullmann wrote:
> you are aware that with this we introduce just a extra platform we will get
> bugs
> for? We then not have just Mac/Qt but also Mac/Qt-X11 which is not even
> officially
> supported by Qt itself?
But what gave you the idea that a
On Wednesday October 14 2015 22:12:31 Christoph Cullmann wrote:
> isn't this really all going in the completely wrong direction?
No. Pragmatism may not be the best but is never the wrong direction.
Skip back and note how I accepted the idea of local patching of toplevel CMake
files to build KF5
Hi,
>> I am already quiet annoyed to see we actually can turn on X11 on Mac, Qt's
>> own
>> X11 backend is not available
>> per default anyway, which sense makes that?
>
> Qt's X11 backend builds just fine except for a few details that should be easy
> enough to address.
>
> Choice is good but
Hi,
> FYI: with a bit of help from a friendly Qt developer, I've now been able to
> come
> up with a QSP patch that includes the necessary "logic" to flip the switch at
> link time using either
>
> QT += qsp_xdg
> (qmake)
> https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/file
FYI: with a bit of help from a friendly Qt developer, I've now been able to
come up with a QSP patch that includes the necessary "logic" to flip the switch
at link time using either
QT += qsp_xdg
(qmake)
or
find_package(Qt5QspXDG)
target_link_libraries(... Qt5::QspXDG ...)
(cmake)
and hopefu
Jeremy Whiting wrote:
> That does sound like a bit more interesting question. Browsing through
Bump ...
I think I'll try a simpler approach, where I'd have to patch each toplevel
CMake
file (including of the frameworks themselves, to be exhaustive) to add a module
in the
find_package(Qt5 ${R
On Tuesday September 29 2015 09:45:02 David Faure wrote:
>> > One thing I like about this, as a side effect, is that my unittests which
>> > need to
>> > have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS
>> > but I have to skip such unittests on OSX/Windows) could then be
On Tuesday September 29 2015 09:45:02 David Faure wrote:
Hi,
I appreciate your continued interest (and not having to send a 'bump' message
:))
>You don't *really* need XDG on OSX. You need files to be found, it's just
>easier to do that by coying what we do on Linux/BSD ;)
Sure. But if it was
On Friday 25 September 2015 14:09:14 René J.V. Bertin wrote:
> Also, it strikes me as bit of a gamble not to have implemented a framework
> for dealing with what one might call Freedesktop or XDG compliance, but to
> have left that to QStandardPaths, basically. It must have been clear from the
>
On Thursday September 24 2015 22:56:37 David Faure wrote:
> Maybe this needs to be per-method-call then :
> * if libA installs stuff into XDG paths, then it would find it using
> QSP::locate(type, filename, XDG)
> * the alternative would be QSP::locate(type, filename, Native), which would
>
On Friday September 25 2015 14:09:14 René J.V. Bertin wrote:
> This could work though, and to avoid that perl script it could be handled
> purely in the QSP headerfile with a default mode option that is defined at
> build time; MacPorts or Fink devs could add an appropriate -DQT_USES_XDG_QSP
>
On Thursday September 24 2015 22:56:37 David Faure wrote:
> [warning: long, and I change my mind mid-way; I left it all so you can follow
> my reasoning]
Seems like a gradual change of mind :)
> If you're really only thinking of apps made by the KDE community, I would be
> surprised to see any o
And another "one more thing":
Back when we attempted a first Qt code review, the proposed change was rejected
in large part because some Qt devs were against implementing a patch that was
only for the benefit of KF5 apps and something that was presented too much as a
KF5 issue. IIRC, the message
[warning: long, and I change my mind mid-way; I left it all so you can follow
my reasoning]
On Thursday 24 September 2015 05:44:18 Jeremy Whiting wrote:
> That does sound like a bit more interesting question. Browsing through
> http://lxr.kde.org/ident?_i=QStandardPaths&_remember=1 (quite a long
That does sound like a bit more interesting question. Browsing through
http://lxr.kde.org/ident?_i=QStandardPaths&_remember=1 (quite a long
list...) a couple of things come to mind. First anything that's using
QStandardPaths isn't necessarily using any frameworks at all. Looking
at http://agateau.c
In fact, let me ask a different question: is there a KF5 framework that is
guaranteed to be linked to by all KF5 applications that have reason (or are
likely) to query QStandardPaths for locations?
That would probably provide the cleanest and easiest solution to my quest: that
framework could b
On Wednesday September 23 2015 14:34:25 Jeremy Whiting wrote:
>Back to your original question I don't think there is such a place,
>besides patching QtCore itself. Many of the frameworks and
>applications use KI18n, but some don't I don't think there's a common
>location that every application lin
Rene,
Back to your original question I don't think there is such a place,
besides patching QtCore itself. Many of the frameworks and
applications use KI18n, but some don't I don't think there's a common
location that every application linking against KF5 libraries uses.
BR,
Jeremy
On Wed, Sep 2
21 matches
Mail list logo
