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

[Mario Fux]

Am Sonntag, 04. Januar 2015, 22.22:09 schrieb René J.V. Bertin:

Morning René

> On Sunday January 04 2015 21:09:18 David Faure wrote:
> > This isn't 1998 anymore. There is no "K Desktop Environment", but I'll
> > translate what you meant by assuming you said "Plasma Workspace". And
> > then I can disagree on more fundamental grounds than naming. The goal of
> > KF5 is to let Qt-based apps use additional libraries WITHOUT this having
> > any relation to the OS and desktop/workspace where the application runs.
> 
> Erm, KF5 stands for KDE Frameworks, no? And KDE?

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.

> > Using a KF5 library DOES NOT make an app "part of the desktop
> > environment". Anything that goes into that direction, undermines the
> > whole idea of KF5.
> 
> I still don't think I agree:

Sorry, but I think we're here really just at a point where it's not about 
agreeing (as what David perfectly explained is just a fact that was worked on 
for years now) but understanding.

> a Desktop Environment isn't made by 1
> application, but by a set of applications sharing similar design and
> building on shared, base functionality etc. Whether you want to call it a
> Desktop or Plasma or a User Experience Framework is just semantics,
> though.

I think I know what you mean. But a Qt app using the linguistic framework 
Sonnet or the threading framework Threadweaver or the KArchive framework or 
all of them does make them connected to KDE Workspace Plasma (nor to the 
Windows or Mac Desktop).
All "frameworks" above are KDE Frameworks and the complete list of KDE 
Frameworks is here:
https://projects.kde.org/projects/frameworks

> And let's be clear: use OS X users were never interested in the KDE Desktop
> per se, as we already have our environment that we cannot dish.

So you make the separation of KDE Desktop (aka Plasma) and other KDE Apps 
yourself?!?

> > this has evolved into: the KDE community provides three independent
> > products, a set of libraries (the "frameworks"), a desktop (or
> > "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.

> > produced by the KDE community, but technically the goal of KF5 is to
> > provide the same features to apps produced by other people too, as long
> > as they link to KF5 libraries.
> 
> 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 
recent years. And either one accepts the new meaning and the numberous 
explanations or one doesn't accept and understand it and then it doesn't make 
any sense to explain in further. But then you'll have problems to discuss 
these matters with other KDE people as you don't talk about the same things 
and that's a fundamental requirements for successful discussion.

> > You're still describing the kde3/kde4 situation. I certainly hope that
> > with KF5, the apps don't need this dual compilation system, with or
> > without kdelibs for kde integration. Marble's Qt Only and Calligra's Qt
> > Only builds can
> 
> I doubt that, unless the KF5 frameworks shrink to something of no interest
> outside of for instance Plasma environments or in any case without
> interest for the application in question. As long as they (KF5) do, the
> reason their (apps) dual versions exist is to allow them (apps) to be
> installed without imposing additional frameworks a user might not want, or
> that might not exist for his system.

I don't really get it and seems to be based on the same wrong assumptions as 
above.

> > hopefully go away now, because 1) we added a lot of things into Qt itself
> > (so e.g. you no longer need kdelibs to get mimetype support, etc.).
> 
> ...
> 
> > whole bunch of running daemons, for many things), with KF5 that should be
> > "no problem, go ahead", not "ah, you need a patched Qt, or a special
> > build flag for Qt, or a special file somewhere to make things work".
> 
> Yes, and this is something where we're quite likely to run into other
> issues, I'm afraid. With KDE4 we've been able to patch many things in
> descendants of Qt classes, which makes it possible to do things that could
> interfere with pure Qt apps. That will no longer be possible were the KDE
> classes in question were integrated into Qt, which AFAIK was done without
> feedback from KDE-Mac users (most of the few of whom were probably unaware
> of what was going on) and possibly even before we got KDE4/Mac to the
> point where it currently is.

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.

> > > However, Ian might mean that it should be possible for
> > > Qt to know that an application is going to use KDE features, presumably
> > > so that KDE4 functionality that wasn't kept in KF5 could be introduced
> > > in the Qt equivalents. That's like patching a KF5-specific Qt5 build,
> > > but with runtime activation of those KF5 bits.
> > 
> > I have no idea what this really means, please elaborate.
> 
> I hope my remarks directly above and a bit below make this a bit clearer..
> 
> An example: KDE4 menu titles. IIRC they're called menu sections in Qt5, and
> they are supposed to work through a texted separator. While that will work
> in floating and widget-attached menus, it doesn't in the toplevel menubar:
> the text is not rendered because the OS has no support for this. In KDE4,
> the extra rendering often crashed the application when it was done in the
> menubar, until I patched KMenu. Fixing the Qt5 menu section issue will
> require fixing Qt5. That's an example where your argument "there are no
> more KDE apps" applies, because adding menu sections is no longer a KDE
> privilege, so if it still doesn't work in Qt5.4 there's a good reason to
> fix it without need for a "KF5-on-Mac specific patch". Menu item placement
> is another thing, though. I continue to think that Qt has a design bug by
> using text-based heuristics to decide which actions become the About,
> Preferences, Quit, etc. menu items, a number of which end up in a
> different menu than the one where the application thinks it's putting
> them. It seems however to work fine for the majority of (commercial?) Qt
> apps, or Digia would have changed their approach already. Not so for KDE
> apps (sorry...), some of which end up with a completely unrelated action
> under (and called!) the Preferences menu item. The only ways to address
> this is either to change all KDE apps to set an explicit menuRole for each
> action they create, or to patch Qt.

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?

Btw I still think that some of the communication problems come from the (not) 
distinction of kdelibs4 based and KF5/Qt5 based apps. You're afaik working a 
lot on the former but not (yet) on the second?.

> > Patching Qt5 doesn't sound like a good solution to me, in any case.
> 
> See above. I've accumulated a number of other general patches over time for
> things that appear to be issues only for KDE apps (e.g. the file watcher
> class printing out a warning that it couldn't add another file, which is
> triggered mostly and a lot by KDevelop). Ian already mentioned raster
> rendering mode: this mode could be forced in kdelibs4 to prevent rendering
> issues that don't occur with pure Qt apps. Maybe such a patch is no longer
> required with Qt5, but maybe we'll have to find a place to force a
> specific rendering mode, and if that cannot be done in KF5 it'll have to
> be in Qt5 (or in each individual KF5 client app). And that would be a case
> where Qt (= functions in the Qt API) should know if the application they
> serve will also use KF5 features, so that things can be set up
> appropriately.

I think it will never happen that Qt knows if the application it's running 
currently used KF5 libs as well.

[snip]

And thanks for mentioning that we should be cautious to use the term 
"frameworks" in the Mac/Apple context.

Best regards
Mario