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

[Elvis Stansvik]

2017-09-11 10:57 GMT+02:00 Eike Ziller <Eike.Ziller at qt.io>:
>
>> On Sep 11, 2017, at 10:31, Elvis Stansvik <elvstone at gmail.com> wrote:
>>
>> 2017-09-11 9:24 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>> 2017-09-10 11:31 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>>> 2017-09-10 11:03 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>>>> 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?
>>>>>
>>>>> 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?
>>
>> I could think of one other "detail" question (then I'm finished, promise!):
>>
>> I see that MainWindow is the one responsible for creating the ICore
>> instance (passing in itself to its constructor), and has been made a
>> friend of ICore to be able to call its private constructor.
>>
>> What was the reason for that arrangement? Could not ICore itself be
>> responsible for creating the MainWindow?
>
> Again historically.
> When I tried to change this, I started moving around so much code (because of dependencies on initialization order etc etc), that I decided it’s not worth the effort.

Alright.

Elvis

>
> Br, Eike
>
>>
>> Elvis
>>
>>>>
>>>> As soon as I hit send, I realized I have a third question:
>>>>
>>>> 3. Communication Between Plugins:
>>>>
>>>> There seems to be two main mechanisms through which plugins
>>>> communicate: Either objects that implement shared interfaces are added
>>>> to the plugin manager object pool and picked up by downstream or
>>>> upstream plugins (in the top-down or bottom-up phase of plugin
>>>> initialization, respectively), or a singleton instance is acquired and
>>>> calls made on it.
>>>>
>>>> Is the former approach used when dependants provide functionality to
>>>> their dependees (which are unknown), and the latter approach used when
>>>> dependees use their dependants (which are known)? Is that the deciding
>>>> factor?
>>>
>>> And finally, a couple of more down-to-earth questions:
>>>
>>> 1. ICore, the class is concrete, so why the I in the name? Was it
>>> abstract at one point? How do you decide whether a class should get
>>> the interface 'I' in its name? The same with e.g. IContext, though
>>> that one at least has a few virtuals and is used as a base class (but
>>> no pure ones AFAICS, so still concrete).
>>>
>>> 2. The relatively liberal use of singleton classes. We all know that
>>> is a debated subject, and I don't have an opinion either way. I'm just
>>> interested in if you have some (spoken or unspoken) policy regarding
>>> singletons in the project. Do you want to minimize the use of them, or
>>> is it OK for newer code, or is it judged on a case-by-case basis? Have
>>> you had any moments where you really wish you hadn't used singletons?
>>> (e.g. I know it can sometimes hurt testability).
>>>
>>> Elvis
>>>
>>>>
>>>> Elvis
>>>>
>>>>>
>>>>> Many thanks in advance,
>>>>> Elvis
>> _______________________________________________
>> Qt-creator mailing list
>> Qt-creator at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.ziller at qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
>