[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Annotation support
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-04-24 10:30:16
Message-ID: 200504241330.16433.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 23 April 2005 16:53, Jens Herden wrote:
> Hi Andras,
[...]
> Right, maybe the structure tree is not a good place. Maybe we should
> think about removing everything from the structure tree that has no
> real tree structure. Link the links, functions etc. these are simple
> lists and could better find another representation in the GUI than a
> tree.

What we can do is create a structure for annotations for structure like 
the one for Functions, Variables.

> > I'm not sure they have background project parsing. The CPP parser
> > is threaded AFAIK, but the project parsing is not.
>
> Well, than we should invent it ;-)

Well, yes. ;-)

> Well I see some positive effects in not storing them in the
> filesystem but in a file:
> - faster scan (as you said)
> - less clutter in the folders
> - less opening and closing in remote filessystems

Ok, I agree. We will not store them in a separate file, but see below.

> > The problem is that in most languages comments can be one or
> > multiline. In case of multiline comments hiding may be possible,
> > for one line comments I'm not sure it even makes sense.
>
> For oneliner it does not make sense at all since you need one line to
> unfold it again. Is there a codefolding interface so that Quanta
> could fold the comments away?

No, codefolding in Kate is controlled by the syntax highlighting XML 
files. But I think Kate already folds multiline isn't it so? Seems so 
for CPP and HTML.

> I did not say that you should drop the feature, just this
> implementation ;-)

Part of it. ;-)

> > This solves the problem of line shifting. moving and editing
> > outside of Quanta. But doesn't help in parsing the whole project
> > for comments.
>
> good!

Great that we agree!

> > 2) in the project file (or the session file?) create an index with
> > the files having annotations in the form of:
> > <annotations>
> >  <item url="filename" time="timestamp" lines="11, 23, 50" />
> >  ...
> > </annotations>
>
> I can not clearly remember what was supposed to go into the project
> file and what into the session file.

The session file is not shared between the users, so this clearly goes 
to the project file. I don't know why I wrote that question in the 
parentheses.

> So the project file is what you 
> have in the remote project and the session file can stay local, I
> would suggest the session file, because you loose nothing if you
> loose the annotations. You can rescan you files.
But we seem to not agree. ;-)

> I wonder if we should store the annotation itself there not a
> reference. This would mean more data in the file but no need to
> rescan the files on startup to show the global annotation list.

Right, but we introduce the same problem of editing the file outside of 
Quanta that we solved with the commented @annotation.

> Please store also the files that have no annotation inside, so that
> you will not scan them again and again because they are not in the
> list.
That's not a problem. It can be even integrated with the standard list 
of files inside the project.

> > - On startup only the files from the project not under
> > <annotations> or those having a different timestamp than stored
> > there are scanned.
>
> If you create a background parser this is good. Maybe this is the
> point where you want to get involved in programming with threads?

I started once, but aborted soon. :-) Maybe we can do it together here?

> > - editing of the annotations can be done either by entering the
> > comment manually or editing in the annotations view. I'm not sure
> > if in this case we need the context menu entry or not.
>
> I rather would not create a new dialog for this. 

Doing that was only some lines of code, no UI file involved.

> I would suggest to 
> create a toolbar button for a comment with annotation. So people can
> assign a shortcut and can type right away without disturbance form a
> dialog.

Good idea. 

> If you want a dialog it might be an idea to enhance the tag-editor
> dialog so that you can invoke it on an comment. There should be a
> tickmark if you want a annotation tag inside and a multiline editor
> to type your comment.

Sounds good.

>
> > What do you think about this proposal?
>
> I like it and I would even more like it if you could keep in mind
> that this is a good candidate for a KDevelop plugin. So please don't
> tie it to closely to the rest of Quanta. Think about: new feature ==
> new class(es)

Sure. I had this is mind, even if the #include "project.h" in the 
annotationoutput.cpp doesn't show this. :-)

Andras
-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]