Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 to 
>have self contained installers/bundles,
>as that is the normal way to go there.

Not *the* normal way, *a* normal way, for applications where this makes sense. 
Bigger and more complex *suites* of applications more often than not use some 
kind of installer to put the various things in their respective places.
Xcode itself came that way, until Apple in their infinite loopdom decided to 
ship it via the App Store. The result is a humongous bundle that contains 
everything the dev community as a whole might ever nee (until "that time of 
year" when 10.n+1 rears its increasingly ugly head). Have a look at its size 
and also note the true size (a priori the thing is compressed with HFS+ 
compression).

Shipping something like the Calligra suite as a self-contained app bundle (a la 
OpenOffice ... which still used an installer last time I bothered) may be 
possible, and would most likely solve any sandboxing issues in IPC that are 
bound to arise when following App Store rules. It will be very complex to get 
right (for a probably brittle result) if none of shared locations are to be 
specified in relative terms so that the app bundle can be moved around freely. 
(BTW Ian, that is probably why QSP doesn't return locations pointing into an 
app bundle's resources directory!)

BTW, Ian and I come at this with the goal of being productive *using* KDE, not 
*on* KDE (exclusively). That's included in what I meant with pragmatism in a 
previous message.
In addition, I have always considered it a self-evidence that you start out a 
porting effort by keeping everything the same as much as possible (shared 
locations, in this case) and focus on what has to be changed ("native" instead 
of X11/xcb APIs). That would have allowed to publish KF5 applications via 
MacPorts and family, driving community interest, and possibly attracting 
experienced OS X developers to help out making things "more native" (that's how 
I got hooked: I rewrote the OS X Keychain "backend" for KWallet almost 
entirely). Progress might have been slower, but surely surer, and less 
disruptive for users.
As to that last bit: I'd have approached the whole KDE4->KF5 evolution as 
KDE4->KDE5->KF5 (i.e. port kdelibs and family to Qt5, and only then start 
thinking of blowing things into individual bits and pieces) but that's a topic 
for another thread.


>I understand that for KDE 4 it was necessary to treat Mac just like a other 
>kind of
>BSD, but I think for frameworks we shall aim to make them usable for people 
>wanting to

OS X *is* just another (and very weird) kind of BSD...

>http://kate-editor.org/2015/10/14/kate-on-mac-hidpi/

Quoting Ari: "Sorry, Kate"

>You need nothing to work on Kate beside XCode, Qt + CMake (and yeah, gettext).

Kate is cute and all, but as a standalone editor I don't see anything it has 
over, say, TextWrangler or its commercial big brother BBEdit.
Except for the fact it can work as a "kpart", providing the editor component 
for a.o. KDevelop. But can it, in its "nativised" KF5/Mac version? I still have 
seen no answer to that question.

>Nothing else above what is shipped with a normal Mac.

As opposed to a senile Mac? Please weigh your words a bit more..

>and that I need to install the icons in the right locations.

Define right?

>And yes, without any black magic

What, no more C++? Now that would be a commendable goal! O:-)

>We wanted to make them attractive for non-KDE applications & developers.
>For Windows & Mac that means for me, they must be usable with stock Qt and 
>without any
>non-os native requirements ;=)

I've never said that couldn't be an ultimate goal, just that it shouldn't be 
the 1st goal to pursue on those platforms. Pursue too many goals at once, and 
you can just as well start rewriting something new from scrap (like Apple did 
with AVFoundation, abandoning manyears worth of dependent software).

Using Qt is already a non-native requirement no matter how you want to turn it. 
It contains iffy  mechanism like "oh, this QAction has a translated title that 
contains the word configure, let's make it the Preferences menu item in the 
Application menu" (did KStandardActions survive, btw?). Qt4 never managed 
completely to prevent conflicts between C++ and ObjC object management (leading 
to events being delivered to deleted objects, for some reason only in KDE 
applications) and I'm not aware anything has changed in that aspect (mechanism 
like ARC might even acerbate the phenomenon).
Qt is admirable at what it accomplishes (not so much on 10.11 though), but if 
you really want to do things natively you'll want to embrace the ObjC/Cocoa 
APIs and SDKs. 
So yeah, set a goal to make KDE native and I 

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Christoph Cullmann]

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, therefore I am not that sure why your mail 
seems to be so upset.

But I can misread that. In any case: I don't want to upset you.

>>You need nothing to work on Kate beside XCode, Qt + CMake (and yeah, gettext).
> 
> Kate is cute and all, but as a standalone editor I don't see anything it has
> over, say, TextWrangler or its commercial big brother BBEdit.
> Except for the fact it can work as a "kpart", providing the editor component 
> for
> a.o. KDevelop. But can it, in its "nativised" KF5/Mac version? I still have
> seen no answer to that question.
Kate uses KF5TextEditor, which provides the "part", and yes, KF5TextEditor is 
after
my last patches just a single self-contained library, Kate uses it via linking
without any global strings attached (beside what frameworks like KIO do at the 
moment)
and KDevelop will just work as fine with that "native" version, if the bundle 
the KF5TextEditor
dynlib in the application bundle, without any extra files.

And you loose nothing, users still have all the features like having own syntax 
xml files in the local data
dirs, own scripting files, config,  But all stuff that is needed by the 
editor itself
is in resources compiled in on ALL operating systems. Its even faster that way, 
as
we no longer stat around 200-300 files on each opening of the application using 
KF5TextEditor.

For me, this is technically the goal for all KF5 frameworks, to be usable by 
just having the library
and potential needed minimal other things bundled (yes, that might imply asset 
files and even helper executables/plugins
like for KIO/Sonnet/...).

> 
>>Nothing else above what is shipped with a normal Mac.
> 
> As opposed to a senile Mac? Please weigh your words a bit more..
Technical answer: "Normal Mac" == "What I buy from Apple without any stuff 
additionally installed"
Perhaps I should have said "plain", "stock", "bare" or "end user".

> 
>>and that I need to install the icons in the right locations.
> 
> Define right?

Right as of now: to get it working at the moment to not have such laughable 
screenshots and be able to try out what
is still crashing/not working without guessing the buttons.

Right as of later: inside the application bundle either in the "Resources" dir 
or as Qt resources, like Krita does
it.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Christoph Cullmann]

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 opinion.

> 
> On 15/10/2015, at 9:46 AM, René J.V. Bertin wrote:
>> 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?
> 
> The KDE Community can provide bug support for whatever platforms it chooses.
> 
> In point of fact, its support for KDE 4 on OS X has not been at all strong in
> the last
> 5 or 6 years.  Partly this was because none of the following worked properly 
> on
> OS X --- KCrash, DrKonqi and Help->Report a bug.  I know, I spent large parts 
> of
> last year fixing them.
> 
> Marko Käning, Mario Fux and I revived this list as a place to discuss the
> issues.
> Thanks for being subscribed, Christoph and Samuel.
> 
> What we are trying to do here is to make support for Frameworks and KF5 
> better,
> this time around, that is if we ever get to implement them on Apple OS X and 
> if
> we
> have not already lost any user base that KDE products have on Apple OS X.
> 
> We are also spending some time on KDE 4 problems.
> 
> Regarding the topic at hand.  I think René has made an important breakthrough
> on the QStandardPaths issue and we should be thinking about how best to take
> advantage of that.
> 
> A few hours ago, Christoph wrote:
>> Isn't this really all going in the completely wrong direction?
>> I thought we want to have frameworks that work as native on the different
>> operating systems as qt.
> 
> The KDE and Apple OS X environments have quite different design approaches
> with regards to applications.  A simple mapping of XDG directories onto 
> "native"
> Apple OS X directories is not going to cut it in the long run.  Why not?
> 
> KDE and its Frameworks and KF5 successors EMBRACE file-sharing between
> applications, utilities and libraries.  Any GUI app I write for KDE has to 
> have
> a ui.rc
> file and a .desktop file.  These have to be installed, not in an Apple OS X
> bundle,
> but in locations where libraries and utilities written by KDE core developers
> can
> find them, easily and _quickly_.
Actually, I here already disagree.
At least some KDE application developers like me or the Krita team want is to 
have self contained installers/bundles,
as that is the normal way to go there.

And it is not true, that all frameworks require globally installed files. I 
patched
KXMLGui to not require any UI file installed, itself it needs no longer any 
global files either.
The plugin mechanism of KDE was rewritten to not require .desktop files either, 
but
just have the plugins dir in the right place.

KConfig will have that fallback soon, too, to even allow preshipped default 
configs like in kate
without global stuff:

https://git.reviewboard.kde.org/r/125598/

KIO is still a challenge, that is true.

I understand that for KDE 4 it was necessary to treat Mac just like a other 
kind of
BSD, but I think for frameworks we shall aim to make them usable for people 
wanting to
create bundles and not going the MacPorts route.

Please read:

https://mail.kde.org/pipermail/kde-frameworks-devel/2015-October/027673.html

And yes, without any black magic and any Qt patches, you can have working 
applications:

http://kate-editor.org/2015/10/14/kate-on-mac-hidpi/

You need nothing to work on Kate beside XCode, Qt + CMake (and yeah, gettext).
All other stuff is just the ECM + frameworks.
Nothing else above what is shipped with a normal Mac.

The only real problem with that ATM is broken KIO without dbus, patch here:

https://git.reviewboard.kde.org/r/125638/

and that I need to install the icons in the right locations.

And yeah, I think a lot more stuff is broken for sure and still we would need 
some
"deploy-qt" like tool to bundle all the libs inside the application bundle.

And no, I don't want to make life for MacPorts/Fink/Homebrew/... harder,
I am happy that people fix stuff for that things, too, but I don't see that as 
the goal
we had for the Frameworks 5 initiative.

We wanted to make them attractive for non-KDE applications & developers.
For Windows & Mac that means for me, they must be usable with stock Qt and 
without any
non-os native requirements ;=)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 hopefully 

find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core QspXDG)

in KF5 toplevel CMake files.

Without those qsp_xdg/QspXDG tokens, QSP has stock behaviour (except for 
FontsLocation, which is wrong in stock Qt):

Standard paths [*...* denote writable entry]:
  DesktopLocation: "Desktop" */Users/bertin/Desktop*
  DocumentsLocation: "Documents" */Users/bertin/Documents*
  FontsLocation: "Fonts" */Users/bertin/Library/Fonts* /Library/Fonts 
/System/Library/Fonts
  ApplicationsLocation: "Applications" */Applications*
  MusicLocation: "Music" */Users/bertin/Music*
  MoviesLocation: "Movies" */Users/bertin/Movies*
  PicturesLocation: "Pictures" */Users/bertin/Pictures*
  TempLocation: "TemporaryItems" *${TMPDIR}*
  HomeLocation: "Home" */Users/bertin*
  AppLocalDataLocation: "Application Support" 
*/Users/bertin/Library/Application Support/QtProject/qtdiag* 
/Library/Application Support/QtProject/qtdiag 
/Volumes/Debian/Users/bertin/work/src/new/Qt/qtdiag/qtdiag.app/
  CacheLocation: "Caches" */Users/bertin/Library/Caches/QtProject/qtdiag* 
/Library/Caches/QtProject/qtdiag
  GenericDataLocation: "Application Support" */Users/bertin/Library/Application 
Support* /Library/Application Support
  RuntimeLocation: "Application Support" */Users/bertin/Library/Application 
Support*
  ConfigLocation: "Preferences" */Users/bertin/Library/Preferences*
  DownloadLocation: "Desktop" */Users/bertin/Downloads*
  GenericCacheLocation: "Caches" */Users/bertin/Library/Caches* /Library/Caches
  GenericConfigLocation: "Preferences" */Users/bertin/Library/Preferences*
  AppDataLocation: "Application Support" */Users/bertin/Library/Application 
Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag 
/Volumes/Debian/Users/bertin/work/src/new/Qt/qtdiag/qtdiag.app/
  AppConfigLocation: "Preferences" 
*/Users/bertin/Library/Preferences/QtProject/qtdiag*


 with the token; it returns locations that conform to XDG conventions (enough, 
hopefully). Find the differences: :)

Standard paths [*...* denote writable entry]:
  DesktopLocation: "Desktop" */Users/bertin/Desktop*
  DocumentsLocation: "Documents" */Users/bertin/Documents*
  FontsLocation: "Fonts" */Users/bertin/Library/Fonts* /Library/Fonts 
/System/Library/Fonts
  ApplicationsLocation: "Applications" */Applications*
  MusicLocation: "Music" */Users/bertin/Music*
  MoviesLocation: "Movies" */Users/bertin/Movies*
  PicturesLocation: "Pictures" */Users/bertin/Pictures*
  TempLocation: "TemporaryItems" *${TMPDIR}*
  HomeLocation: "Home" */Users/bertin*
  AppLocalDataLocation: "Application Support" 
*/Users/bertin/.local/share/QtProject/qtdiag* /Library/Application 
Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag 
/Volumes/Debian/Users/bertin/work/src/new/Qt/qtdiag/build/
  CacheLocation: "Caches" */Users/bertin/.cache/QtProject/qtdiag* 
/Users/bertin/.cache /Library/Caches/QtProject/qtdiag
  GenericDataLocation: "Application Support" */Users/bertin/.local/share* 
/opt/local/share /Library/Application Support
  RuntimeLocation: "Application Support" */Users/bertin/Library/Application 
Support*
  ConfigLocation: "Preferences" */Users/bertin/.config* /opt/local/etc/xdg
  DownloadLocation: "Desktop" */Users/bertin/Downloads*
  GenericCacheLocation: "Caches" */Users/bertin/.cache* /Users/bertin/.cache 
/Library/Caches
  GenericConfigLocation: "Preferences" */Users/bertin/.config* 
/opt/local/etc/xdg
  AppDataLocation: "Application Support" 
*/Users/bertin/.local/share/QtProject/qtdiag* /Library/Application 
Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag 
/Volumes/Debian/Users/bertin/work/src/new/Qt/qtdiag/build/
  AppConfigLocation: "Preferences" 
*/Users/bertin/Library/Preferences/QtProject/qtdiag*

https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/fix-qstandardpaths3.patch
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/fix-qstandardpaths-headerspri.patch
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/fix-qsp_fontlocations.patch

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Christoph Cullmann]

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/files/fix-qstandardpaths3.patch
> https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/fix-qstandardpaths-headerspri.patch
> https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/fix-qsp_fontlocations.patch

isn't this really all going in the completely wrong direction?

I thought we want to have frameworks that work as native on the different 
operating systems as qt.

That means for Mac we need to make them usable for application bundles. And we 
need then to decide
which KDE applications make sense on Mac (like Krita, Kate, KDevelop, Dolphin, 
...) and make these
applications workable with the frameworks.

For Kate, I already got all up to speed, guess the only thing missing in the 
Kate application itself are
the plugins which still not find their UI files.

For frameworks, I think KIO and Co. has still a way to go to make them work 
with bundles.

But now, we start to even patch Qt to make it behave like on Linux/BSD on Mac? 
Really?
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?

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 software in what one should probably call QSP compatibility 
mode.

> I thought we want to have frameworks that work as native on the different 
> operating systems as qt.
(to take this literally, that's exactly what will be the case, with or without 
my patch.)

Define we?

I'm not going to get into this discussion with you again, AFAIC we just have to 
agree to disagree (for now) and ensure everyone gets what they want.

There is nothing in the OS X specifications that says where shared resources 
*must* be (such strict rules apply only to items to be submitted to the App 
Store). Applications will however almost always be built like app bundles, but 
those are not obligatory standalone affairs. 

If we had gotten a QSP patch like this working *months* ago (possibly even 
included into Qt) we might now have been in a situation with working 
applications ready to convert/adapt to native locations.

> And we need then to decide which KDE applications make sense on Mac

I think "we" Mac users are perfectly capable to decide that for ourselves, and 
don't need people to do it for us who not so long ago (gave the impression 
they) couldn't care less about the cross-platform aspect KDE inherited by 
choosing Qt.
It's fine with me if some sort of official KDE workgroup decides which 
applications are going to be made available as shiny clickable items in the App 
Store or via dmgs on some official server. As long as it doesn't interfere with 
the approach currently used to provide KDE4 via MacPorts and that allows me to 
exchange KDE settings between Mac and Linux desktops.

> 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 if it annoys you, just look the other way (and do it 
quietly, as you already suggested by accident :P). I do the same with dogma.
(Or get yourself a Winbox, it's a bit harder to "turn on X11" there...)

OS X is a Unix with what used to be a great desktop environment. The presence 
of which doesn't mean people shouldn't be able to use it as a more common Unix 
workstation, or avoid wasting disk space by using shared libraries and 
resources the way they're intended to, if that's what they want. That's 
probably also the chief and major audience for MacPorts, Fink and family.

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Christoph Cullmann]

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 if it annoys you, just look the other way (and do it 
> quietly,
> as you already suggested by accident :P). I do the same with dogma.
> (Or get yourself a Winbox, it's a bit harder to "turn on X11" there...)
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?

To tell me to look the other way is nice, but won't stop the bugs from coming
to our bugtracker.

In the dependency thread the concern was raised for bugs that will come in
if we make more stuff optional, but X11 on Mac is just a complete different 
level
of potential support problems.

Btw., if you like to have a second opinion read Boudewijn mail from that thead:

https://mail.kde.org/pipermail/kde-frameworks-devel/2015-October/027673.html

I fully agree with him.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 anyone is aiming to build KF5 for X11 on OS X? 
Did you deduce that from my argument that users might run KF5 applications in a 
context where they're expected to interact (and share resources) with non-Qt 
applications, based on GTk/Gnome? That can work perfectly well with the KDE 
applications using native displaying APIs.

It's what I am doing right now; in fact, my GTk2 theme is set to QtCurve using 
the exact same settings as the QtCurve theme I use for KDE.

There might have been an interest to that if Qt5 was more suitable for 
displaying on a remote X11 display, but it isn't (and XQuartz lacks support for 
remote GLX). Without that, there is just too little interest in using the xcb 
plugin to make it a supported configuration. If a given Qt5-based application 
still works "as is" when you launch it with -platform xcb, that's a bonus, 
nothing more, nothing else (less).

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core [...])

line. Seems like it'd be the best compromise acceptable to most (if not all...)

I'd still have to patch Qt to provide such a module, and publish it in a way 
that it can be requested via the above syntax.

The existing entries that can be used there all seem to have names that give a 
s*load of hits when searching for them in the source, so I don't really have 
any 
ideas where to start, currently.
Is there anyone here who could give me some pointers or guidance with that? 
David?

Thanks,
René
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[David Faure]

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 
> onset that QSP complies with Freedesktop/XDG conventions only in standard 
> Unix/Linux Qt builds (OS X being a "deviant" Unix configuration).

Yes that was clear and on purpose.
The intent was not to use XDG-like directories on all platforms, but rather to 
"do what the platform recommends/forces us to do" - which is QSP.

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 ;)

> I guess that outlines another possible solution: create a framework that can 
> provide the required glue on platforms where this might be required or 
> desired, with build switches to control optional behaviour *and* ensure that 
> all applications still end up using the same conventions.

That is KStandardDirs, and I certainly do NOT want to bring that back. It would 
go exactly against "all apps use the same conventions"
because apps using QSP and apps using KStandardDirs would do things 
differently. And because it assumed XDG layout everywhere,
which looks strange on OSX, looks a lot stranger on Windows, and is just not 
allowed on Android or iOS.
 
> > So OK, kcoreaddons could switch QSP behavior on Mac, provided that
> > it's documented with a huge warning, and that it can be turned off. It 
> > breaks
> > the principle of least surprise ("ever since my app started using one tiny
> > unrelated class out of KF5, my users lost all their previous 
> > configuration!").
> 
> This shouldn't happen when things are done correctly. The choice what 
> locations are to be used should be made at a global level and apply for the 
> whole installed KF5 environment. That's why I went with a link-time switch 
> that gets set immutably when an application is loaded. It's not intended to 
> provide things like runtime switchable configuration profiles.

I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from 
KF5, say KTextEdit, and my users lost
all of their previous configuration because this brought in kcoreaddons, which 
toggled a global switch in QSP!!! You guys suck!!!" :-)

> > The advantage of this solution compared to your initial question: no build 
> > system hackery
> > (which would break the principle of least surprise even more, I would say).
> 
> What I like about a build system modification (esp. at the level of Qt 
> component selection) is that it's done in places that aren't likely to evolve 
> frequently. And where, if they do, people will be careful. My experience with 
> modifying source code (e.g. to make X11 calls conditional) is that not 
> everyone is very careful to leave such modifications in place, let alone 
> ensure that an upstream change doesn't break them. I won't call it lack of 
> respect, but sometimes it feels like that ;)

Hidden magic is good because it's hidden so people won't break it? I can't 
agree to this line of argumentation.
Hidden magic is *usually* bad because it fools expectations. And on top of 
that, it can still be broken - unknowingly - because it's so hidden.
Anyway, meta discussions won't help, let's dive into specifics again ;)

> > 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 enabled on 
> > OSX.
> 
> You should also be able to do that with a build system modification that 
> leaves a choice, no?

Sure, unittests are easy (self contained), whichever solution we end up with.

> >  which means the suggested solution here would break third-party libs 
> > which
> > install stuff into default QSP paths, and then we toggle the mode to XDG, 
> > and they
> > can't find their stuff anymore...
> 
> It'd be the responsibility of packagers to ensure that those 3rd party 
> libraries are patched too, or built with the same switch setting...

Hmm. You envision a world where a single packaging system controls all the Qt 
based libs.
I suppose this is the case for Macports (and its alternatives like Fink, 
assuming people can't
mix-n-match between the two)? Or can an app in Macports link to a lib from the 
"real" OSX
(I guess I mean for instance /Library)?


If indeed this is about a self-contained world where all libs and apps should 
use the same paths,
then we're back to the easiest solution: a Qt patch for Macports.
Or the equivalent, an upstream Qt change which is enabled when configuring Qt 
for Macports.

If however this is about a mix-and-match world where some libs install files 
into XDG-like paths
and some other libs install files into OSX-like paths, and some apps link to 
both of these libs,
then 

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 wasn't clear: for use in frameworks (sic..) like those provided 
by MacPorts those files have to be found in locations where non-Qt code will 
also find them. Which probably leaves little choice ...
BTW, was that an intentional slip-up, coy instead of copy? ;) Question is, what 
would be the real MacCoy? :)

>That is KStandardDirs, and I certainly do NOT want to bring that back. It 
>would go exactly against "all apps use the same conventions"

I would say that it helps impose that "all apps use the same conventions", at 
least that's how I'd implement it.
>because apps using QSP and apps using KStandardDirs would do things 
>differently.

I'm not suggesting to bring back KSD, much as having a patchable proxy class 
would make things easy as they were with KDE4. I'm really only thinking of 
something that provides a hook to modify QSP behaviour in a controlled fashion 
for *all* applications that belong to the class where the native QSP behaviour 
is not appropriate.

>And because it assumed XDG layout everywhere,
>which looks strange on OSX, looks a lot stranger on Windows, and is just not 
>allowed on Android or iOS.

FWIW, I don't see why KSD could not have been rewritten to behave more 
appropriately?

>I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from 
>KF5, say KTextEdit, and my users lost
>all of their previous configuration because this brought in kcoreaddons, which 
>toggled a global switch in QSP!!! You guys suck!!!" :-)

To which you could reply "but you asked for it by configuring your KF5 build to 
modify Qt's behaviour". Not changing stock behaviour by default has clearly 
always been a requirement for me.

>Hidden magic is good because it's hidden so people won't break it? I can't 
>agree to this line of argumentation.

Didn't say it's good, and also didn't intend to hide through obfuscation. 
Rather, hide in plain sight, with a good ample description that would be a bit 
cumbersome in "user source code".
But,
>Anyway, meta discussions won't help, let's dive into specifics again ;)

>Hmm. You envision a world where a single packaging system controls all the Qt 
>based libs.

Indeed, but I don't envision that as the only or even the centre of the 
universe. It just happens to be the world I live on ;)

>I suppose this is the case for Macports (and its alternatives like Fink, 
>assuming people can't
>mix-n-match between the two)? Or can an app in Macports link to a lib from the 
>"real" OSX
>(I guess I mean for instance /Library)?

MacPorts, HomeBrew and (AFAIK) Fink are comparable to things like Gentoo Prefix 
in that they attempt to be as self-contained as possible. It's not even their 
goal to provide libraries and middleware for use in whatever personal or 
professional projects users might have. They exist with the goal to make it 
easy to install (free) software, and strive for reproducible builds (which 
explains the goal of being self-contained). The only outside/system libraries 
that apps in MacPorts are supposed to link to are the system SDKs and a select 
few other libraries which would otherwise lead to circular dependencies. You 
can have MacPorts and Fink installed alongside each other (for users who know 
what they're doing); HomeBrew installs stuff into /usr/local and is thus more 
or less incompatible with anything else.
MacPorts also has the guideline to force applications and libraries to build 
against MacPorts dependencies instead of against any "embedded" copies of those 
libraries that might be shipped with the code. I'm even tempted to say that Qt 
is provided only so that Qt applications can all be built against the same, 
controlled version. Or at least that that argument is at least as important as 
the reduction of the disk footprint.
And yes, MacPorts uses a build and packaging system written in Tcl (running in 
a special tclsh); Fink uses Debian's packaging system and HomeBrew uses 
"recipes" written in Ruby . So all have ways to distribute specific patches 
(like my QSP patch, currently) and perform all kinds of magic .

Which also means that it's perfectly possible to implement some or all of the 
changes we're discussing here in the appropriate MacPorts ports.
That doesn't take away the fact that I need some guidance on how best to 
implement those changes ... and there is a MacPorts guideline that they 
shouldn't be the repository for upstream patches.

>If indeed this is about a self-contained world where all libs and apps should 
>use the same paths,
>then we're back to the easiest solution: a Qt patch for Macports.
>Or the equivalent, an upstream Qt change which is enabled when configuring Qt 
>for Macports.

Yes and no.
Yes, the 

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 enabled on 
>> > OSX.

>I would just like to take one step back and make sure this is going into a 
>direction that makes sense.
>Let's assume you can toggle QSP behavior to XDG somehow (per call or globally 
>or whatever).
>What then? Macports users will have to set XDG_* env vars for the apps to 
>work? I thought
>setting env vars wasn't an option?

Just so everyone has a clear view of what locations we're talking about:

>>> stock QStandardPaths from Qt 5.5.0 on OS X (from qtdiag from my 
>>> port:qt5-kde; these only have a fix applied to the FontsLocation)
Standard paths [*...* denote writable entry]:
  DesktopLocation: "Desktop" */Users/bertin/Desktop*
  DocumentsLocation: "Documents" */Users/bertin/Documents*
  FontsLocation: "Fonts" */Users/bertin/Library/Fonts* /Library/Fonts 
/System/Library/Fonts
  ApplicationsLocation: "Applications" */Applications*
  MusicLocation: "Music" */Users/bertin/Music*
  MoviesLocation: "Movies" */Users/bertin/Movies*
  PicturesLocation: "Pictures" */Users/bertin/Pictures*
  TempLocation: "TemporaryItems" */var/folders/j1/blabla/T*
  HomeLocation: "Home" */Users/bertin*
  AppLocalDataLocation: "Application Support" 
*/Users/bertin/Library/Application Support/QtProject/qtdiag* 
/Library/Application Support/QtProject/qtdiag /opt/local/libexec/qt5/bin/
  CacheLocation: "Caches" */Users/bertin/Library/Caches/QtProject/qtdiag* 
/Library/Caches/QtProject/qtdiag
  GenericDataLocation: "Application Support" */Users/bertin/Library/Application 
Support* /Library/Application Support
  RuntimeLocation: "Application Support" */Users/bertin/Library/Application 
Support*
  ConfigLocation: "Preferences" */Users/bertin/Library/Preferences*
  DownloadLocation: "Desktop" */Users/bertin/Downloads*
  GenericCacheLocation: "Caches" */Users/bertin/Library/Caches* /Library/Caches
  GenericConfigLocation: "Preferences" */Users/bertin/Library/Preferences*
  AppDataLocation: "Application Support" */Users/bertin/Library/Application 
Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag 
/opt/local/libexec/qt5/bin/
  AppConfigLocation: "Preferences" 
*/Users/bertin/Library/Preferences/QtProject/qtdiag*

>>> stock QStandardPaths from Qt 5.5.0 on Linux; also note the xdg-kde-plasma 
>>> directories that don't show up in the OS X locations:
Standard paths [*...* denote writable entry]:
  DesktopLocation: "Desktop" */home/bertin/Desktop*
  DocumentsLocation: "Documents" */home/bertin/Documents*
  FontsLocation: "Fonts" */home/bertin/.fonts*
  ApplicationsLocation: "Applications" */home/bertin/.local/share/applications* 
/usr/share/applications /usr/share/kde-plasma/applications 
/usr/local/share/applications
  MusicLocation: "Music" */home/bertin/Music*
  MoviesLocation: "Movies" */home/bertin/Videos*
  PicturesLocation: "Pictures" */home/bertin/Pictures*
  TempLocation: "Temporary Directory" */tmp*
  HomeLocation: "Home" */home/bertin*
  AppLocalDataLocation: "Application Data" 
*/home/bertin/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag 
/usr/share/kde-plasma/QtProject/qtdiag /usr/local/share/QtProject/qtdiag
  CacheLocation: "Cache" */home/bertin/.cache/QtProject/qtdiag*
  GenericDataLocation: "Shared Data" */home/bertin/.local/share* /usr/share 
/usr/share/kde-plasma /usr/local/share
  RuntimeLocation: "Runtime" */run/user/UID*
  ConfigLocation: "Configuration" */home/bertin/.config* 
/etc/xdg/xdg-kde-plasma /usr/share/upstart/xdg /etc/xdg
  DownloadLocation: "Download" */home/bertin/Desktop/Downloads*
  GenericCacheLocation: "Shared Cache" */home/bertin/.cache*
  GenericConfigLocation: "Shared Configuration" */home/bertin/.config* 
/etc/xdg/xdg-kde-plasma /usr/share/upstart/xdg /etc/xdg
  AppDataLocation: "Application Data" 
*/home/bertin/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag 
/usr/share/kde-plasma/QtProject/qtdiag /usr/local/share/QtProject/qtdiag
  AppConfigLocation: "Application Configuration" 
*/home/bertin/.config/QtProject/qtdiag* 
/etc/xdg/xdg-kde-plasma/QtProject/qtdiag 
/usr/share/upstart/xdg/QtProject/qtdiag /etc/xdg/QtProject/qtdiag

On a related note: those Linux locations come from qtdiag of a Qt installed 
into /opt/local, actually a Linux build of the aforementioned qt5-kde port 
(MacPorts package).
I'm surprised that I'm not seeing /opt/local show up anywhere in there. What 
would be the consensus to modify in these locations, for a Qt installed into 
/opt/local where KF5 could also be installed? Replace everything pointing to 
/usr/local with /opt/local, or also replace /usr with /opt/local?

R.
___
Kde-frameworks-devel mailing list

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 one of them not linking to kcoreaddons.

Point is I don't know ... but it will probably be the case. Apps that link with 
more than just 1 or an eclectic selection of KF5 frameworks, and that (indeed) 
are supposed to interact with each other. That latter is the crucial bit of 
course: without interaction (direct IPC or indirectly via shared resources even 
if as trivial as icons) there is no real point in imposing specific locations 
that all those interacting apps agree upon. We can probably even be more 
selective: resources that are not part of some Freedesktop specification but 
are by definition/design shared *only* among KF5 applications can probably be 
anywhere (under a common root that can be configured, preferably) as long as 
it's indeed a shared location. We'll probably be excluding KDE4 applications 
here; if I understand correctly they can continue to work as they do currently 
on OS X/MacPorts since their's no Plasma desktop to comply with; as long as the 
KDE4 libraries and KF5 frameworks and respective other shared stuff don't enter 
into conflict.
(FWIW, with GUI applications being built as app bundles anyway, it ought even 
be possible to have, say, Kate4 and Kate5 installed in parallel.)

> I want to stay on record saying that this goes against the modularity 
> principle
> of KF5 for other applications, of course. If someone wants to only use 
> KItemModels,

The modularity principle for *other* applications? Does that mean that there's 
official leeway for, erm, non-other applications to require a common subset? 
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 onset 
that QSP complies with Freedesktop/XDG conventions only in standard Unix/Linux 
Qt builds (OS X being a "deviant" Unix configuration).

I guess that outlines another possible solution: create a framework that can 
provide the required glue on platforms where this might be required or desired, 
with build switches to control optional behaviour *and* ensure that all 
applications still end up using the same conventions.

> So OK, kcoreaddons could switch QSP behavior on Mac, provided that
> it's documented with a huge warning, and that it can be turned off. It breaks
> the principle of least surprise ("ever since my app started using one tiny
> unrelated class out of KF5, my users lost all their previous configuration!").

This shouldn't happen when things are done correctly. The choice what locations 
are to be used should be made at a global level and apply for the whole 
installed KF5 environment. That's why I went with a link-time switch that gets 
set immutably when an application is loaded. It's not intended to provide 
things like runtime switchable configuration profiles.

> In addition to that, we should still make sure that KF5 frameworks work with
> the default Apple-conformant QSP (either because they don't link to 
> KCoreAddons,

You yourself came up with quite a few good arguments why this would be 
undesirable if not impossible, but those may have been made with a coherent set 
of "KDE Desktop" applications in mind.

> or because someone turned off the QSP-switching), but I totally understand if 
> you want to
> leave that to somebody else (to each man his own battle).

I might actually be tempted to participate, but only after everything works to 
satisfaction in my own use case scenario whatever :) I'd probably want to have 
an uptodate KDevelop to do that kind of work, for instance, and installed via 
MacPorts or Fink ;)

> Now, if a global object in kcoreaddons switches QSP behavior, how can someone
> turn that off? 

I'd argue that that shouldn't be possible, that the way the switch is flipped 
should be set when applications are linked, in the build system. Or in a shared 
header file, that'd be fine too AFAIC. Though in that case there should be a 
way to override the header's setting, of course. It should be fine to link an 
application with an explicit choice for the QSP behaviour, that seems evident.

> In details, my idea would be:
> KCoreAddons has in a cpp file: Q_CONSTRUCTOR_FUNCTION(func1) where func1 
> switches QSP to XDG mode.
> If an app doesn't want that: Q_CONSTRUCTOR_FUNCTION(func2) where func2 
> switches QSP path to OSX mode.
> If it's guaranteed that the ctor func in the app runs last we're fine. 
> Otherwise we need a tristate logic
> (default, forcedToXDG, forcedToOSX) where kcoreaddons would say "switch to 
> xdg unless forced to OSX").
> Any OSX linker experts around? :)

Do you have specific Linux-linker 

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 was "fix it on your own end".

This might actually argue for a (standalone!) "Freedesktop compliance" KF5 
framework that provides the logic to flip a switch built into Qt O:-)

More to the point, it means we'll have to be a bit careful that whatever 
solution we come up with isn't too exclusive to KF5, if we want to hope that 
the required QSP patch will go into Qt at some point.
Which probably shouldn't be too much of an issue because there must be enough 
pure Qt (or LXQt?) applications that don't use KF5 but still want to rely on 
Freedesktop conventions through QSP. Or so I presume?

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Jeremy Whiting]

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.com/2013/kf5-diagrams/kf5.png (which admittedly may
not be up to date either) it seems KCoreAddons is a very commonly used
framework. Also depended on by many other frameworks and used by many
applications. It contains KAboutData which is used by pretty much any
GUI application that we release, I'm not sure if it matters if it
needs to be used by command-line tools also or not. I'm not sure how
many if any command line tools or system daemons etc. are using
QStandardPaths. Maybe try with KCoreAddons and see if that's a
suitable enough place?

BR,
Jeremy

On Thu, Sep 24, 2015 at 3:34 AM, René J.V.  wrote:
> 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 be patched (on OS X or for MacPorts/Fink/...) to 
> activate the QSP mode switch. (And that could be either using an instance of 
> the dedicated class I described, or using an OS X framework initialisation 
> routine.)
>
> R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 be patched (on OS X or for MacPorts/Fink/...) to activate the 
QSP mode switch. (And that could be either using an instance of the dedicated 
class I described, or using an OS X framework initialisation routine.)

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J . V . Bertin]

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 linking against KF5 libraries uses.
>
>BR,
>Jeremy

Ahhh, thanks Jeremy!

So there's nothing in the ECM that could be set?

It would certainly make sense to add this to the part where the required Qt 
components are declared.
Correct me if I'm wrong (I haven't yet found the doc for the find_package call 
in question):
I understand that's done with a macro provided by Qt which receives the 
required minimum version and the required components, so anything I want to 
change in there would require changing this expression in all CMake files, or 
else changing the Qt macro itself?

The CMake documentation for find_package is mute about the CONFIG argument I 
see being used: where does it come from?

Now this may be a moot point, but if that understanding is true, it seems a bit 
surprising that the eventuality hasn't been taken into account that that list 
of components might not be the same on all platforms (i.e. that some might 
require an additional component systematically)? Wouldn't it have been more 
future-proof to use a wrapper to that find_package macro (which would also have 
been perfect for my needs)?

Patching a Qt CMake file is no problem (I'm already patching the source...).

Supposing there is indeed no choice but to patch all toplevel KF5 CMake files, 
is there at least a distinctive pattern that all those files have *before* the 
"find Qt5" logic, so that I can write a generic patchfile or script that takes 
care of that change?

BR,
René
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[David Faure]

[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
> 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.com/2013/kf5-diagrams/kf5.png (which admittedly may
> not be up to date either) it seems KCoreAddons is a very commonly used
> framework. Also depended on by many other frameworks and used by many
> applications. It contains KAboutData which is used by pretty much any
> GUI application that we release, I'm not sure if it matters if it
> needs to be used by command-line tools also or not. I'm not sure how
> many if any command line tools or system daemons etc. are using
> QStandardPaths. Maybe try with KCoreAddons and see if that's a
> suitable enough place?

Right, I was going to suggest that too.

If you're really only thinking of apps made by the KDE community, I would be
surprised to see any one of them not linking to kcoreaddons.

I want to stay on record saying that this goes against the modularity principle
of KF5 for other applications, of course. If someone wants to only use 
KItemModels,
they should be able to do just that. But in this context that's fine, this 
would likely
not be an app from the KDE community (which is expected to integrate with 
others)
but more likely an external, more standalone app.

So OK, kcoreaddons could switch QSP behavior on Mac, provided that
it's documented with a huge warning, and that it can be turned off. It breaks
the principle of least surprise ("ever since my app started using one tiny
unrelated class out of KF5, my users lost all their previous configuration!").

In addition to that, we should still make sure that KF5 frameworks work with
the default Apple-conformant QSP (either because they don't link to KCoreAddons,
or because someone turned off the QSP-switching), but I totally understand if 
you want to
leave that to somebody else (to each man his own battle).

Now, if a global object in kcoreaddons switches QSP behavior, how can someone
turn that off? It's a bit tricky because another global object in the app could 
be constructed
before or after the one in kcoreaddons (unless there's a spec that ensures it 
happens
in libs before apps? I'm no expert on this, I only know order of construction 
is undefined
within a given library at least).

In details, my idea would be:
KCoreAddons has in a cpp file: Q_CONSTRUCTOR_FUNCTION(func1) where func1 
switches QSP to XDG mode.
If an app doesn't want that: Q_CONSTRUCTOR_FUNCTION(func2) where func2 switches 
QSP path to OSX mode.
If it's guaranteed that the ctor func in the app runs last we're fine. 
Otherwise we need a tristate logic
(default, forcedToXDG, forcedToOSX) where kcoreaddons would say "switch to xdg 
unless forced to OSX").
Any OSX linker experts around? :)

The advantage of this solution compared to your initial question: no build 
system hackery
(which would break the principle of least surprise even more, I would say).

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 enabled on OSX.
But of course I would also solve that by adding setters to QSP cross-platform...
I just always wanted to stay away from that because it only makes sense in 
tests.
Libs and apps would fight over it, if this was misused (one lib could make 
other libs
not able to find their stuff anymore, or apps would break libs, etc.). Which is 
kind
of the issue here with the global QSP mode, but at least it's a single setting 
to
fight over ;-)

 which means the suggested solution here would break third-party libs which
installed stuff into default QSP paths, and then we toggle the mode to XDG, and 
they
can't find their stuff anymore...

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 be 
the default.
This seems more correct to me after all, no? Porting the KDE code would be just 
running
one perl script, don't worry about that part.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Jeremy Whiting]

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 23, 2015 at 3:15 AM, René J.V.  wrote:
> Let me just add what me me come to KDE.
> That was mostly out of unhappiness with changes in OS X applications and 
> development, and to find replacements for mail and IDE applications (and 
> because I'd seen on Linux that KDE4 was about ripe to be an alternative to 
> the OS X GUI, I was both blissfully and sadly unaware of KF5).
> I also use digiKam and KDEnlive but my main applications are Kontact and 
> KDevelop. I could see myself use Karbon at some point when my PPC copy of 
> Illustrator really no longer cuts it, but for the rest I find myself reaching 
> for my older copy of Pages (and Numbers & Keynote) from back when Apple still 
> hadn't ripped out the interesting functionality, and to image processing 
> applications built purely on native APIs.
>
> Maybe this helps put my priorities in perspective ... and now, back to the 
> original question please!
>
> R.
> ___
> kde-...@kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel