[Qt-creator] Project <-insert cool name here->

[eike.ziller at nokia.com]

On Nov 4, 2010, at 9:40 AM, ext Nicolas Arnaud-Cormos wrote:

> Hi,
> 
> I would like to propose a community effort to enhance the API of Qt Creator.
> I can see several areas where the community can help Nokia developers.
> 
> Coding style
> ========
> I was a little frustrated with my first big merge request, when I had to make 
> all those little changes to follow the coding style, whereas the existing code 
> is not following it:
> * use of m_ for class members
> * use of d-pointer for exported classes
> * use class instead of struct
> 
> I can also see some inconsistency, I'm sure I can find 5 different way to create 
> a d-pointer (private class inside the class, private class outside, append 
> Private to the class name, just Private, struct, class...).
> 
> Documentation
> ==========
> The documentation of exported is sometimes missing, or incomplete.
> I'm talking about the code documentation, for plugin developers, not the 
> documentation of Qt Creator.

I'll be very glad to review and accept merge requests for API documentation.
BTW, you can generate the little stuff that is there by
cd <qtcreator>/doc/api
qmake -r && make

> API
> ==
> The API is sometime strange, I have two examples in mind I came across 
> recently:
> * it looks like exporting the plugin class is a bad idea, but the 
> ProjectExplorerPlugin is exported whereas other plugins are using 
> handler/manager/whatever

Yes, historically. Should be renamed to ProjectExplorer, and a separate ProjectExplorerPlugin class created.

> * the openEditorAt method is a static method in BaseTextEditor, whereas the 
> EditorManager has openEditor and openEditorWithContents

The EditorManager should in the best case not know about the concept of "text editors" at all, so couldn't even know what openEditorAt should mean ;). But yes, there crept some api for it into IEditor over the years.

> Maybe there are good reason for those choices, it just feels strange.
> 
> There are also some lack for the plugin developers. I know that the policy is 
> to not export anything until it's used, but some method seems so useful that 
> they should be exported, so the developer can use them directly (changing the 
> Qt Creator code can be discouraging). Some example:
> * there's no method to get the different panes
> * I'm biased here but I think switchHeaderSource can be really really useful 
> (see my MR #188)
> 
> 
> The goal of the project is to:
> * collect all these (I'm thinking of a wiki page on Qt DevNet)
> * discuss what should be done with the Nokia developers
> * propose some MR to enhance the code
> 
> I totally understand that Nokia developers don't have time to polish the API,

Well, as a plugin developer you'll probably find that we actually polish the API, breaking compatibility again and again ;). But the polish and changes are often related to what we do in features here, true.

> and need more features (Meego target, QML integration...), but it can't 
> succeed without your help.
> What do you think?


Suggestions for API changes are welcome to be discussed of course. (And after agreement also be accepted for merge, has happened before ;) .)
I think QtDevNet Wiki is the right place for collecting that stuff, but I'd suppose that the discussion itself has to be done through other mediums (looks like the QtDevNet Wiki doesn't have any commenting/discussion functionality like MediaWiki).

++ Eike