KMDI maintainership

[Matt Rogers]

On Monday 20 December 2004 02:27 am, Philippe Fremy wrote:
> Do you plan in your maintainership to make it compilable as a Qt only
> framework again ?
>
> 	Philippe
>

No. Development on KDE 4 will be starting soon and KMDI may very well be 
obsolete when Qt 4 comes around.

Matt


> 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>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel