On Sun, Sep 10, 2017 at 11:03:13AM +0200, Elvis Stansvik wrote: > Hi all, > > In a quest to find inspiration for good Qt application architectures, > I've been looking at the plugin based one you're using in Qt Creator. > It strikes me as a really nice design. > > I've been reading the available docs on it, and dug into the code a > bit. This may be a bit much to ask, but I was wondering if any of you > devs could answer a few questions that popped up? It would be much > appreciated! > > It's really just two questions, about two different topics: > > 1. The Invoker / invoke<...> Thingie: > > You have ExtensionSystem::Invoker and the associated invoke<..> > helper, which are syntactic sugar for achieving "soft" extension > points. It seems it's not used that much (?). I grepped for > "Invoker|invoke<" in the code and could only find a few uses of it. I > also grepped for "invokeMethod" to see if the approach was being used > "manually" so to speak (without the sugar), and found a few more hits. > > What was the motivation for adding this? I assume it's for cases where > you want a looser coupling between plugins (no linking, no shared > header), but can you give an example of when you really wanted that > looser coupling and why?
The initial idea was to use it for dependencies that somehow enhance the functionality of some plugin, but are not strictly necessary for its primary operation. E.g. there's no strict reason that the target platform plugins depend on all tool plugins. I.e. it's imaginable to use Android without Debugger. Or I might want to use qmake but never use the resource editor as I prefer to handle .qrc manually, or not at all. Looser coupling is beneficial for various reasons, both on the user side and the developer side. The ability to disable plugins one doesn't need not only give faster load times for the end users, but also affects developers trying to debug Qt Creator itself. Specifically for developers the ability to get "slim" Creator builds with only a subset of plugins is quite some help for bug hunting by bisection. It's also kind of mandatory to have if you have plugins developed independently from the monolithic base by different parties, perhaps even following different release cycles. The fact that the Invoker/invoke facility is not as heavily used as it could be has various reasons. On the technical side, there are other "soft dependency" mechanisms in use, e.g. have a topic-specific place where callbacks of some kind can be registered. After all, there always needs to be some shared knowledge on what functionality is shared. Whether that's a function name, or some enum, or some registration facility is more an implementation detail the a conceptual need. > 2. The Plugin System in General: > > Is there anything about the plugin system in its current form, or how > it is used, that you would do fundamentally different if you could do > it all over again? Any areas that you find messy/awkward, that need a > re-think/makeover? In short: What are the biggest warts in the code in > your opinion? For my personal taste there are still too many hard dependencies that could be soft, and there are one or two oddities that probably should not exits, e.g. plugin "inheritance" for code sharing reasons, or the non-systematic qmakeandroidsupport. But all things considered, that's not a problem of the plugin mechanism as such, which is fine as far as I am concerned. Andre' _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
