[Qt-creator] Couple of questions about the design of Qt Creator

[André Pönitz]

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'