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

[Elvis Stansvik]

Thanks a lot for your detailed answers André.

2017-09-10 13:41 GMT+02:00 André Pönitz <apoenitz at t-online.de>:
> 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'