[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[Mario Fux]

Am Montag, 05. Januar 2015, 12.37:22 schrieb René J.V. Bertin:
> On Monday January 05 2015 11:18:23 Mario Fux wrote:
> > Am Sonntag, 04. Januar 2015, 22.22:09 schrieb René J.V. Bertin:
> Hi Mario,

Morning René

Sorry to CC you, you should be subscribed here ;-). Not sure about David.

> > KF5 stands for "KDE Frameworks 5". "KDE" stands for "KDE". Back in the
> > days it stood for "K Desktop Environment" but that's long gone. "KDE" is
> > the community we're all part of. The people. A community that produces a
> > lot of great software.
> > So you make the separation of KDE Desktop (aka Plasma) and other KDE Apps
> > yourself?!?

Small (but IMHO important detail). The above quote of me confused me. There 
was quite some other stuff between the first part and the last sentence. At 
least something like "[...]" would have indicated that.

> Well, yes. But I consider that even without Plasma, KDE apps (some of which
> are from kde4-workspace) form an ensemble that one could think of as the
> KDE Desktop for <some OS>. If you want to call that simply "the KDE apps",
> well, I guess I can live with that.

Sorry, I don't understand this even after reading it three times. Let's try it 
a last time ;-) ... Some "KDE apps form an ensemble one could think of as the 
KDE Desktop for <some OS>". I don't think so. Plasma is (currently the only 
but that might change) the KDE Desktop. But Plasma is even more...

> > > > "workspace"), and a set of applications. And you can use either of
> > > > these independently from the others, that's the whole point of the
> > > > separation.
> > > 
> > > Really? You can run any among those applications without the
> > > "frameworks" being present? O:-)
> > 
> > No. That's not what David explained. He meant the you don't need the
> > desktop aka KDE Workspace aka Plasma present.
> 
> Well, it is what he said, but I understood what he meant ;)
> 
> About Workspace: there are a number of things we use on OS X from
> kde4-workspace, and from what I understand, other things (like DrKonqi)
> have been moved into KF5 Workspace which apparently depends intimately on

What's this kde4-workspace? A Macports module? Don't find it e.g on 
projects.kde.org:
https://projects.kde.org/search?projects=1&q=kde4-workspace

Oh and there is no "KF5 Workspace". You might mean Plasma 5. Which is based on 
KF5, but it's based on Qt5 as well and not called "Qt5 Desktop" because there 
are other "Qt5 Desktop" IIRC like lxqt or hawaii or so. And they might even 
use KF5, at least some of them.

> Plasma.

KF5 Workspace depends on Plasma??? DrKonqi is afaik in Plasma and that might 
need to be changed. But that's probably for another thread. And we (KDE) 
should probably check other bug-report-tools or crash-tool. But other thread, 
sorry.

> This may have to be re-evaluated. We'll want systemsettings on OS
> X, and of course DrKonqi (esp. after all the effort Ian put into that),
> and also styles/themes.

Makes sense to me too.

> > > Like it or not, I think many people (including me) will continue to
> > > think of KF5 as KDE 5. If not only KDE just sounds better than KF5...
> > 
> > Then keep doing so but it's wrong. It's simply wrong. It's not about
> > having an opinion here. The meaning of "KDE" and the KDE Community
> > changed a lot in the
> 
> If KDE no longer refers to Desktop Environment, than what's wrong with
> calling KF5 KDE 5?

"KDE" refers to the KDE community, the people and thus "KDE 5" would be a 
"version 5 of the people"???

> The fact that so many Linux distribs already have
> kde5libs etc. packages?

I just know Debian and there "kdelibs5" packages:
https://packages.debian.org/search?keywords=kdelibs5

But that's different and has nothing to do with KF5 or Qt5. It's actually 
"kdelibs4" and thus Qt4 based. Do you know anything else? Could you send some 
links? Seriously I'd be interested.

> > I don't really get it and seems to be based on the same wrong assumptions
> > as above.
> 
> We do appear to be on parallel channels. My assumption is simple: if KF5
> libraries provide additional features, Qt5 applications may decide to use
> those, or make them optional, for whatever reason.

I think (but might be wrong) what's missing here is the fact that you can (and 
should) use only some of the frameworks in KF5. That's an important point of 
the modularization of kdelibs to KF5. So you don't either use KF5 or not but 
you might use (to take David's example) Sonnet in Scribus (and thus use KF5) 
or in Dolphin you might use quite some more KDE frameworks (KArchive, Kio, 
KConfig, etc.) but not Sonnet. (Just examples, I did not check the actual 
dependencies of these apps).

> In the latter case,
> they'll be supporting different configurations. It may be that it's less
> of a dual situation, but in the end it remains a choice of the application
> developers.

In the end all should be "just" Qt apps. Some of them use Qt and some other 
libraries, some use just Qt and some use Qt and some libraries from KF5. 
Everything should work as good as possible for our user on Mac and Co ;-).

> > We tried hard to invite KDE people from all platforms to participate in
> > what is KF5 now and if there is or was no feedback it was really hard to
> > integrate it. But that's not to blame you. But in the same way it's not
> > to blame the KF5 people that they didn't listen or search for guidance
> > and feedback from other platforms if there was none.
> 
> I'm not saying there was no such invitation even less that KDE/Mac was
> excluded deliberately.

Sorry then, your "...which AFAIK was done without feedback from KDE-Mac users 
(most of the few of whom were probably unaware of what was going on)..." 
sounded to me like that.

> Depending on how long ago this all happened the KDE
> Mac community was maybe so small and inactive that they simply missed the
> invite, or thought they had too little to contribute.

Fortunately this changed meanwhile :-).

> But in the end there
> was little or no feedback, and I think very few "core KDE devs" looked
> into OS X adaptations that were floating around to get their own idea of
> the platforms idiosyncrasies.

Indeed. That might have happened. There might have been other missings but we 
managed to get a KF5 out and more releases and we're working on getting it 
better on Windows and Mac (and more) and so let's fixed it here and now and 
work into the future rather than bringing it up and again what we've done 
wrong back then. It's honestly a bit tiring to always repeat this.

> > Just to be clear and that I understand it correctly. KDE apps based on
> > kdelibs4 didn't work correctly and you patched it, right? Do the
> > Qt5/KF5based apps have the same problem? And do just Qt4-based apps
> > (without deps to kdelibs4) have the problem too?
> 
> Certain issues like the menu placement are likely to pop up in pure Qt
> applications too if for instance they define multiple Configure or
> Settings or Preferences menu actions, without taking care the right one
> gets created first. Apparently this doesn't happen very often. OTOH, pure
> Qt applications that are tested on OS X by their devs or whose devs take
> feedback from OS X users in account are likely to have been patched
> themselves.

So if I get this correctly there is really something wrong with Mac menus in 
Qt apps and it should be fixed (rather the patched). Please do it (ok, you're 
already on it so thanks). 

> This is also the case with certain KDE apps, but IMHO it
> shouldn't be necessary. At the moment we can say very little about Qt5/KF5
> in this aspect. Apart from the fact that the menu placement heuristic is
> in fact expanded with more guesses (now including cut,copy,paste), so that
> particular issue will continue to exist.

So we really need to get KF5based apps running on Mac. But therefore we need 
the QSP patch upstream which is being worked on. Great. We'll be there 
eventually.

> > I think it will never happen that Qt knows if the application it's
> > running currently used KF5 libs as well.
> 
> We'll see to what extent that may turn out to be the only solution to
> yet-to-be-identified issues on OS X ...
> 
> Cheers,
> R.

Thanks
Mario