Thanks a lot for your detailed answers André. 2017-09-10 13:41 GMT+02:00 André Pönitz <[email protected]>: > 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.
That all makes sense, especially the ability to disable plugins at compile time, and having out-of-tree plugins be more resilient to changes in the application. Though the ability for a user to disable plugins, that's possible now right? > > 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. I see. Any good examples of such other soft dependency mechanisms, where regular callbacks are registered instead? (in Qt Creator I mean) > >> 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. Alright. With hard dependencies you mean where a plugin makes direct calls to another, instead of going through an interface+the pool or a callback mechanism like you described? Elvis > > Andre' _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
