R: One more suggestion about ClassView

[Carlo Sirna]

----- Original Message -----
From: Gygax Hans-Peter <Gygax at twi-ag.ch>
To: <kdevelop at fara3.cs.uni-potsdam.de>
Sent: Thursday, September 02, 1999 3:39 PM
Subject: RE: One more suggestion about ClassView


> Hi,
>
> I think the "TIP" comments are not necessary. The KDOC standard (used by
KDE
> developers) allows programmers to document classes and class members in a
> standardized and machine-parsable way; all we need is to have KDevelop do
> that parsing.

I knew... I wanted only to express the idea... Of course I agree about using
the KDOC
standard.
 One day I will get it working...

> As for grouping: I agree here, but I find it a little verbose. How about
> "extending" the keywords "public", "protected" etc. by appending the
section
> name in a comment ?

 I don't agree about this... If would want to put in the same section both
private and
public members, I couldn't do it... And when I am developing a class I focus
more on
members how members are related each other rather on their visibility...

> Like:
> class XXXX {
> public: file://$S user-interaction
>   void foo();
> public: file://$S widget rendering
>   void bar();
> private:
>   int notInterested;
> };
>
> since nothing forbids specifying "public", "protected" etc. more than
once.
> ("$S" means "this is a section"; omitting it means this is not a section).
>
> I don't know about sub-sections, though... shouldn't that be left to inner
> classes ?
>
> Just my thoughts
> JPG
>
> > -----Original Message-----
> > From: Carlo Sirna [SMTP:carlo.sirna at digisoft.it]
> > Sent: Thursday, September 02, 1999 10:51 AM
> > To: kdevelop at fara3.cs.uni-potsdam.de
> > Subject: One more suggestion about ClassView
> >
> > > > Christian
> > > It would be even better if you´d put public, protected and private
> > member
> > > functions and the variables into a separate sub tree each.
> > > (maybe make this configurable?)
> >
> > You gave me another idea!
> >  It would be GREAT to be allowed to put in the source code some special
> >  comments, like these
> >
> > class MyClass
> > {
> >
> >    // SECTION("User Interaction", "These functions are fired in response
> > to
> > user interaction with the widget")
> >       virtual void onEntering();   // TIP("Fired when widget gets input
> > focus")
> >       virtual void onKey(); // TIP("Fired on key press events")
> >    // ENDSECTION
> >    // SECTION ("Widget rendering", "on screen drawing procedures and
> > options)
> >      virtual void Paint(); // TIP("Performs actual rendering");
> >      void SetBkgColor(TColor t); // TIP("Set background color")
> >   // ENDSECTION
> > }
> >
> > This should allow to build a ClassView tree like this
> >
> > class myclass
> >    |- User Interaction
> >    |    |-onEntering()
> >    |    |-onKey()
> >    |-Widget Rendering
> >         |-Paint()
> >         |-SetBkgColor()
> >
> > I wish that sections could be also nested (this is why I proposed used a
> > begin/end structure).
> >
> > While I was writing I had another Idea: inserting in the code some
> > tooltips
> > (sorry for the windows slang, but I am still not experienced with linux
> > GUI
> > programming...) to be showed when mouse cursor moves on an item of the
> > tree...
> > This is why the SECTION keyword has 2 arguments: the second is the
> > tooltip.
> >
> > but (forget tooltips) being allowed to define some grouping for the
> > members
> > it would be incredibly useful... especially with classes containing
tenths
> > of members.
> >
> > C'mon guys...Keep on coding, you are doing great :-)
> >
> >
>