I like this idea very much and think we should look into it further. There is a long way we can go with integrating Qt into Apple platforms better at every level and this would be a great start. -- Jake Petroules Chief Technology Officer Petroules Corporation ยท www.petroules.com Email: [email protected]
On Jun 18, 2013, at 3:31 PM, Adam Strzelecki <[email protected]> wrote: >> That might work for when QtCore is bundled with the executable, but it >> doesn't >> if QtCore is still installed system-wide and the executable (your >> application) >> is somewhere else completely. How will it find the plugins? > > I am perfectly aware than on some platforms it isn't possible to get path for > the executable, requires messing with /proc or it may not even exists. That's > why I all stuff below applies to OSX, and maybe can be brought to Windows. > > As a full-time Mac developer I may be biased towards way of OSX, but I think > there's something wrong conceptually with Qt Mac frameworks architecture. > > Basically Qt Mac SDK looks like a mixture of contradictory OSX and UNIX > concepts, where UNIX libraries use compile time "prefix" (/usr /usr/local > /opt /sw), Mac frameworks never expect their location to be some particular > path. > > So if libqcocoa.dylib is QtWidgets.framework plugin which is a Mac framework, > it may be better idea to keep it as > QtWidgets.framework/Version/5/PlugIns/Cocoa.bundle/Contents/MacOS/Cocoa. IMHO > Some.app/Contents/PlugIns is reserved for application plugins not for their > frameworks. > > This also applies to Qt built-in translations that should be in framework > Resources etc. etc. > > So all frameworks know where to look for their plugins translations, etc. > etc. because they're carried with them. > > Finally Qt SDK would be just a bunch of frameworks you can (selectively) link > to, move around, copy to your app bundle, w/o any extra path tweaking. SDK > could be just dmg package of: > Qt5.1.sdk: > Samples/ > Frameworks/ > QT Creator.app > > If one don't need some features in the app they can be stripped away from > particular framework, i.e. removing Headers/, particular translations in > Resources/, particular widget backends in QtWidgets PlugIns/. > > What would be even more cool is to put the "moc", "qmake" tools into > QtCore.framework/Versions/5/Support (symlinked to QtCore.framework/Support). > > Altogether this would make Qt SDK 100% OSX friendly. No need for installers, > just add QtCore.framework/Versions/5/Support if you want use command line > tools or symlink them to /usr/local/bin > > Some examples taken from my box: > > $ ls -l `which ruby` > lrwxr-xr-x 1 root wheel 76 26 lip 2012 /usr/bin/ruby -> > ../../System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby > $ ls -l `which java` > lrwxr-xr-x 1 root wheel 74 17 kwi 18:17 /usr/bin/java -> > /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java > > Regards, > -- > Adam Strzelecki | nanoant.com | twitter.com/nanoant > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
