2013/9/17 Casimiro, Daniel C CIV NUWC NWPT <daniel.casim...@navy.mil>:
> I think that plugins are supposed to have the "so" suffix on Mac OS X, but I
> am not sure. I don't have a mac handy right now.
Honestly, I don't know. I just noticed that all the other plugins wer
dylibs so I just went for that. It probably makes sense since plugins
are technically not dynamically linked at lauch time, they are
dynamically loaded at run time. It may very well make no difference,
for all I know, but it makes more sense in my head :)
> The plugin has to be in a subfolder named "generic" (i.e.
> Qt/5.1.0/clang_64/plugins/generic) for Qt to find and correctly load it. The
> folder should already exist and contain the plugins for mouse and keyboard
> handling. You will have to copy the plugin manually. I haven't tried to make
> cmake handle that aspect yet.
Weird, I didn't have any generic subdir in there. Anyway, I've created
one and symlinked it there. Now, except for a failed assert in
qtuiotouch.cpp:190, it seems to work :)
I'm not sure if this is the right way, I'll look and see if I can
influence the search paths for plugins with some env variable. For
now, I'll just leave it like that.
> FYI, you can set the QT_DEBUG_PLUGINS environment variable to get diagnostic
> information about plugin loading.
Tried that. The only thing I got from that is a huge list of error
messages along the lines of
QFactoryLoader::QFactoryLoader() looking at
"/Users/morpheu5/src/Qt/5.1.0/clang_64/plugins/platforms/libqcocoa.dylib"
loaded library
"/Users/morpheu5/src/Qt/5.1.0/clang_64/plugins/platforms/libqcocoa.dylib"
QLibraryPrivate::unload succeeded on
"/Users/morpheu5/src/Qt/5.1.0/clang_64/plugins/platforms/libqcocoa.dylib"
Got keys from plugin meta data ("cocoa")
but that's probably another story.
--
Andrea Franceschini
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
