On Saturday August 20 2016 10:16:41 David Faure wrote: > OK, you're probably right about OSX, but on Windows the shared data dir > allows > to do this, without the need for a XDG mode on Windows.
Possibly, I must admit that I haven't looked at exactly what MSYS2's needs are here. It does seem likely that they don't need a configuration in which a single Qt build can cater to both needs. It wasn't my idea, initially, to combine our efforts, but since there is an evident overlap it does seem a good idea to pursue a single fits-all solution. I've been simplifying my patch, moving away from the XDG terminology towards the concept of an ALTernative mode, which is something that I hope is more acceptable and requires less platform-specific code. > So I would suggest to leave Windows out of the discussion: separate issues, > separate solutions. Probably, though I see some practical advantages to come up with a patch that addresses the as yet unanswered needs, at least before we start to think of launching the review process(es). > Although I'm curious about what's in the commit I'm replying to, where is it? Sorry, it didn't survive my pruning: https://github.com/Alexpux/MINGW-packages/pull/1623#issuecomment-241074130 > > I resent calling the Ext class a hack. > > I'm just telling you, the Qt developers will never accept a class called > QExtStandardPaths. The name itself reeks of bad API. The name isn't set in stone, I just couldn't come up with a better name more in line with whatever guidelines Qt might have for this. I suppose you agree that a descendant class that overloads the QSP methods is the easiest way to introduce an extra argument without having to patch each and every QSP invocation and if you don't want to add the mode switch to the QSP API itself. > Well, the mode arg in each call is still a possible option, I don't see why > it > leads to a "why bother" conclusion. Not the mode argument, but the idea of specifying a set of paths in each call. > More work adapting KDE, but a cleaner API, possibly. Not just KDE, if adaptation is required for instance because of an obligatory new argument to class methods. Probably not impossible to propose, but it seems it would defeat the purpose of a number of C++ features to do this for an argument with a clearly defined default value. I agree the API would be cleaner if the mode argument would simply always be there, everywhere, and there would only be the question of how you set the default value for that argument. The reason I've introduced the overloading QExt class to avoid changing the "official" API is that there are apparently concerns with Apple's App Store admission rules. I have no idea exactly how Apple go about checking whether QSP returns acceptable paths. If they just look at compiled application behaviour there shouldn't be any problem with introducing a mode argument with a default value in the current QSP API. Not as long as it doesn't change the default behaviour. > I have trouble thinking about all this 10 minutes at a time every > two weeks, it would be more efficient to sit together somewhere and dig into > the I agree, for me too. > issue, possibly with other OSX people. Will you be at QtCon/Akademy in two > weeks? Sadly, no, I don't think so. Is that the event in Berlin (IIRC)? Maybe it would be possible to find a convenient moment to get together over some kind of video-conferencing during the Akademy? > Well, and I keep wondering if things wouldn't be much simpler without this > requirement. I.e. Qt from MacPorts would be needed by MacPorts apps, > and that Qt can be told at compile time look into MacPorts-like paths, easy > patch, end of story. Yep. Of course. And MacPorts could also have 2 different Qt installs (and hope you can load a plugin using the one into a host application using the other Qt as long as their versions match). :) On a more serious note: just how likely would it be to get such an easier patch accepted? It would have to be something that is under control of Qt's configure mechanism, and I have the strong impression that there's a lot of reluctance to make that mechanism any more complex than it already is. On the other hand, if we're talking about an easy patch that won't be upstreamed then I don't see why I would give up on the idea of a mode switch... For those who don't know (or forget ;)): the reason why I'm pursuing a solution in which a single Qt build can provide both "native" and alternative (XDG-compliant) QSP locations is that MacPorts aims to provide applications that behave as much as possible as they're expected to. This applies especially to applications that have been designed or specifically adapted to OS X (as opposed to simply being built on OS X and bundled into an app bundle). Those apps are to behave like they behave when you get them from another source, notably the official build. Example: VirtualBox is in MacPorts too; it's supposed to behave like the version provided by Oracle, and that also means both versions have to get their configuration files from the same locations (which means that a future Qt5-based version will need to use QStandardPaths in native mode). KF5 applications are in a different reality: they'd be expected to behave (and thus interact which each other) like they do on other Unix platforms, and that also includes the interaction with other applications designed around Freedesktop/XDG guidelines that are not based on Qt5. R _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
