[Qt-creator] projectexplorer foldernavigationwidget extraction

[André Pönitz]

On Sat, Jan 03, 2015 at 12:28:27PM +0100, Petr Vaněk wrote:
> > On the other hand, splitting out individual widgets from the project
> > explorer has impact on everyone else. "It will be useful for my product".
> > is unlikely to be enough justification. If there's functionality in
> > projectexplorer that belongs to cppeditor (or elsewhere), moving those
> > piece to where they belongs should be fine. But if all you need
> > is FolderNavigationWidget without the rest of projectexplorer, then
> > you could simply copy to that to your language support plugin.
> 
> It can affect QtCreator devs for sure. But I believe that copying the
> source code is not a good way to go due increased maintenance etc.

Maybe at some time there should be some kind of "mission statement" on
what Qt Creator is meant to be, and what it is not meant to be.

Until then I need to base my comments on my personal view on the matter,
and that's the following: In my opinion Qt Creator primarily serves two
purposes: (a) as development environment for Users of Qt (in the broadest
sense, even non-Qt "side uses" of Qt users are in-scope), and (b) as a test
bed for Qt technologies. Every other use is fine, but ranks lower.

Any increased maintenance for out-of-tree non-Qt-related modifications of
Qt Creator would not hit anyone in the "primary" target group, in so far
that would not be a primary consideration.

If harmless, non-intrusive, generally sensible patches to make the codebase
more friendly to such use cases appear on codereview, there's a good a
chance to get them applied. But that'd also pretty much the limit of
support for that scenario. 

> Correct me if I'm wrong but if I move some widgets out of
> projectexplorer into eg. new plugin (or into core plugin) and the plugin
> will be a part of the official repository/releases with autoloading set
> on, then the end user cannot see any difference, right?

Increasing the number of typically loaded plugins does not come for free.
There are a couple of mechanisms that scale linearly, or even quadratically
with the number of involved plugins, like startup times or deployment
considerations. So splitting plugins into "too small" parts does not make
sense.

> Also the file system browser does not looks project related to me. And I
> can imagine lots of usage where there is no "project" required - simple
> scripts, independent plaintext files editing, editing files over
> webdav...

I currently see code dependencies of FolderNavigationWidget on core,
texteditor and lib/utils. You could try to find out whether moving the
widget to one of these would be an acceptable option. texteditor should be
straight-forward technically, whether it "makes sense" I can't judge.

On the other hand, I don't see too much of a C++ dependency in 
projectexplorer, so I am not sure I see the cause of this discussion
right now.  What exactly stops you from using projectexplorer?

> Again - I understand that QtCreator is C/C++ IDE *now* but I
> can really see the potential to become an universal platform for IDEs.

[I see that people see that potential, but ...]

> Maybe Hermann can share summary of his patches/changes to show his
> problem domain as well.

That, independently, would be nice.
 
> So conclusion finally ;)
> 
> - it's a chance to make QtCreator more open (from the technical point of
> view) if somebody can help me to analyze projectexplorer and core and
> cppeditor plugins in terms of what belongs where.
> - I'll definitely accept any of the QtCreator "board" decision

I wouldn't expect a "board" decision on Qore specific questions, rather
there will be individual decisions on individual patches by the reviewers
of those patches.

> - I offer to make the changes on my own and post it to review/acceptance
> process

Having the changes on codereview would be nice.

Best regards,
Andre'