KMDI maintainership

[Philippe Fremy]

Do you plan in your maintainership to make it compilable as a Qt only 
framework again ?

	Philippe

Matt Rogers wrote:
> Hi,
> 
> I'd like to take over KMDI maintainership. Currently, it doesn't really have a 
> maintainer since the person who imported it into kdelibs has been inactive 
> for quite some time. 
> 
> My initial actions as the new maintainer would be the following (not 
> necessarily the order i would do them in):
> 
> - Reformat the source to my liking per the attached HACKING file
> - Reassign all the KMDI bugs to and make myself the owner of the kdelibs/kmdi 
> component in bugzilla
> - start fixing bugs. Applicable fixes will go into kmdi2, albeit more slowly 
> than kmdi1. Depending on kmdi's future, kmdi2 will be phased out in favor of 
> a better behaving kmdi1 for KDE 4.
> 
> While I realize there are efforts underway to replace KMDI, I think it's 
> worthwhile to give it a chance after somebody gives it a little bit of love 
> rather than just replace it outright.
> 
> If there are no objections, I'll start immediately. (please cc me all replies 
> that only go to kwrite-devel since i'm not subscribed there)
> 
> Thanks,
> Matt
> 
> 
> 
> ------------------------------------------------------------------------
> 
> This is the oscar HACKING file. It details the current coding style that is being
> used in this plugin. Thanks to Scott Wheeler for providing the skeleton I based this
> file on
> 
> ================================================================================
> Code Documentation
> ================================================================================
> 
> Please add doxygen comments to the header files where appropriate. I don't expect
> anyone to add comments for functions that they're overriding from the base class
> but comments everywhere would be good.
> 
> Please comment parts of the code that might be unclear, need more thinking about,
> reimplementing, etc. It will help people look for things to do if they want to help
> out.
> 
> Please don't remove the kdDebug lines from any of the source files. If they're
> excessive, either wrap them in an ifdef and put the ifdef in the soon to be
> created oscardebug.h file so that they can be enabled and disabled at the will of
> other developers or users. I also tend to use kdDebug statements to document
> my code in the place of comments for the simpler sections. 
> 
> ================================================================================
> Indentation
> ================================================================================
> 
> I use tabs to indent everything. When I say tabs, I mean the 'tab' character. Please
> don't use 8 spaces to indent. Just hit the 'tab' key, and make sure that space indentation
> is turned off in whatever editor you use. However, the exception to the indentation
> rule is anything that's inside of a namespace block should not be indented.
> 
> 
> static void foo()
> {
> 	if ( bar() ) <-- 1 tab
>         	baz(); <-- 2 tabs
> }
> 
> namespace
> {
> class Foo
> {
> Q_OBJECT
> public:
> 	Foo();
> 	~Foo();
> };
> }
> 
> 
> 
> 
> vim or kate modelines that modify the way tabs are displayed are encouraged, as
> long as they don't actually change the way tabs are saved to a file.
> 
> ================================================================================
> Braces
> ================================================================================
> 
> Braces opening classes, structs, namespaces, functions, and conditionals should be
> on their own line. Here's an example: 
> 
> class Foo
> {
>     // stuff
> };
> 
> if ( foo == bar )
> {
>     // stuff
> }
> 
> while ( foo == bar &&
>       baz == quux &&
>       flop == pop )
> {
>     // stuff
> }
> 
> static void foo()
> {
>     // stuff
> }
> 
> Also conditionals / loops that only contiain one line in their body (but where
> the conditional statement fits onto one line) should omit braces:
> 
> if ( foo == bar )
>     baz();
> 
> But:
> 
> if ( baz == quux &&
>    ralf == spot )
> {
>     bar();
> }
> 
> ================================================================================
> Spaces
> ================================================================================
> 
> Spaces should be used between the conditional / loop type and the
> conditional statement.  They should also not be used after parenthesis.  However
> the should be to mark of mathematical or comparative operators.
> 
> if ( foo == bar )
>   ^ ^          ^
> 
> is correct. However:
> 
> if(foo == bar)
> 
> is not.
> 
> ================================================================================
> Header Organization
> ================================================================================
> 
> Member variables should always be private and prefixed with "m_".  Accessors may
> not be inline in the headers.  The organization of the members in a class should be
> roughly as follows:
> 
> public:
> public slots:
> protected:
> protected slots:
> signals:
> private: // member funtions
> private slots:
> private: // member variables
> 
> If there are no private slots there is no need for two private sections, however
> private functions and private variables should be clearly separated.
> 
> The implementations files -- .cpp files -- should follow (when possible) the
> same order of function declarations as the header files.
> 
> Virtual functions should always be marked as such even in derived classes where
> it is not strictly necessary.
> 
> ================================================================================
> Whitespace
> ================================================================================
> 
> Whitespace should be used liberally.  When blocks of code are logically distinct
> I tend to put a blank line between them.  This is difficult to explain
> systematically but after looking a bit at the current code organization this
> ideally will be somewhat clear.
> 
> Parenthesis should be padded by spaces on one side. This is easier to illustrate in
> an example:
> 
> void Client::foo() //correct
> void Client::foo3( int, int, int ) //correct
> 
> void Client::foo(int, int, int) //incorrect
> void Client::foo(int,int,int) //also incorrect
> 
> Operators should be padded by spaces in conditionals. Again, more examples to
> illustrate
> 
> if (foo==bar)
> m+=(n*2)-3;
> 
> should be:
> 
> if ( foo == bar )
> m += ( n * 2 ) - 3;
> 
> ================================================================================
> Pointer and Reference Operators
> ================================================================================
> 
> This one is pretty simple.  I prefer "Foo* f" to "Foo *f" in function signatures
> and declarations.  The same goes for "Foo& f" over "Foo &f".
> 
> ================================================================================
> 
> There are likely things missing here and I'll try to add them over time as I
> notice things that are often missed.  Please let me know if specific points are
> ambiguous.
> 
> Also, please note that since this library is based heavily off of Kopete's 
> libgroupwise library that the coding style in certain files may not match what's
> written in this document. Those files that don't match will be corrected eventually.
> 
> To make things easier on you, kate modelines are provided at the end of certain files
> to help enforce the coding style. If you're using the new C S&S Indenter that will be in
> KDE 3.4, I can provide a patch that will automatically implement the space padding around
> parenthesis. Please mail me so I can send it to you.
> 
> Matt Rogers <mattr at kde.org>
>