Yeah, if we go that direction on mac it would be fine for bundled Qt, but not for shared Qt. It would make all applications that use qt5-mac or qt5-kde or whatnot use linuxy paths or not. It's a runtime switch, so not very helpful if you've installed stuff to linuxy paths and then let the user choose to toggle it and fail to find all the resources needed. It sounds like a good solution for embedding a copy of Qt next to each application for windows use (and maybe for osx use too if resources don't make it completely unneccessary), but not for the macports shared Qt case.
On Thu, Oct 22, 2015 at 2:37 PM, René J.V. <rjvber...@gmail.com> wrote: > On Thursday October 22 2015 22:05:59 Marko Käning wrote: > >> > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971) >> > Because the proposal supports environment variables too, I guess this >> > would also cover the OS X needs (env XDG_CONFIG_DIRS). >> >> that actually slipped my attention back then! :-| >> >> OK, perhaps that is a way to go then also for MacPorts?! @René? > > I understood from Jeremy's reply at the time that it wasn't exactly what we'd > need. I'm not familiar with how qt.conf is to be used, but my 1st impression > is that neither a per-app-bundle qt.conf nor a central, shared one would be > the perfect solution. The per-application approach will be much more > maintenance-heavy, and a central, shared file would mean that all > applications depending on Qt5 use either the one or the other QSP "flavour". > > > R. > _______________________________________________ > Kde-frameworks-devel mailing list > kde-frameworks-de...@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
