Longer List -- (Re: KFilterModel and assorted issues)

[Adam Treat]

On Monday 06 February 2006 4:12 am, Roberto Raggi wrote:
> > Roberto, Harry, I'd appreciate it if you guys and any of the Troll's
> > responsible for the model/view stuff could have a look at the
> > KDevCodeAggregate/KDevCodeProxy stuff I committed.  It seems to work, but
> > I am not sure I have all the signals and inter model interaction figured
> > out correctly.
>
> I will.. and I'll ask Marius to look at it too.

Awesome!  Pay particular note to how I disable the 'clear' and 'modelRefresh' 
signals from the aggregate to the proxy and reconnect them.  Tell Marius that 
one limitation seems to be that proxy's outside of TT's control don't have 
access to the underlying persistent index list.  I think the 
QPersistentModelIndex class that Qt4.1 exposes is useless.  I can't retrieve 
an instance of one from any model or proxy.  All I have to alter the 
persistent indexes is changePersistentIndex(...), but no way to retrieve a 
list of them like QSortFilterProxyModel does.

The reason that I went this way is because of the futility of using one big 
model and having the parser update it from multiple threads.  That creates 
all kinds of locking issues and it just really wouldn't work.

Now, Roberto, while I have your ear, the biggest thing I'd like to see is some 
attention paid to the location info in the parser/preprocessor/codemodel.  
Right now, I'm storing info, but it is *BAD* info as the locations are from 
the preprocessed source!!  We need some way for the preprocessor to build a 
table of locations during its pass and then somehow translate them to the 
codemodel during the parser/binder pass.

Also, it is **very** important that we record and keep track of 
__actual_file__ information.

For instance, if I have api.cpp as my currently active file and I modify it 
then it will be passed to the preprocessor as a QByteArray.  The preprocessor 
needs to be told what file it came from too ie, api.cpp.  Also, when the 
preprocessor goes through the includes it needs to query kdevelop whether a 
particular include is an opened file... because if it is, then kdevelop needs 
to pass it a QByteArray instead of the preprocessor just reading that include 
from disk.

So, api.cpp is passed to the preprocessor which records all the filename 
information for the various nodes and also the original location information 
and then this information need to be preserved for the parser/codemodel.  I 
can't stress enough how important it is to get this information **absolutely 
correct** for everything we do: problem reporter, code view, completion, etc, 
etc.

Some other things while I'm going on at length:

1.  Trolltech needs to push hard on the necessary 
QMainWindow/QAction/QDockwindow changes necessary for us to switch over to a 
KMDI replacement without needing Q3support.  KDevelop's (and many KDE apps) 
GUI development is idle till this is resolved.  I have a prototype for a 
lightweight idea how to replace KMDI, but it is going to require changes to 
QMainWindow, specifically we're going to need access to the underlying layout 
for the dockwidgets.

2.  I'm going to work on loading language parts in tandem hopefully pretty 
soon.  I think that we should get another language support part ( *but only 
one*) in svn pretty soon so that we can make sure the things we're doing work 
for languages agnostically.  I'd prefer Java as the other partner right now 
as I'm anxious to see Jakob's parser in action.

3.  I want to move the background parser to lib/* as I think this could be 
done in a language agnostic manner.  The background parser would just query 
the language support part for a ParseJob for the particular document that is 
activated.

4.  Some reorganization of the source I think should be on the table.  The 
classes in /lib* are scattered as it is and some of the things probably 
shouldn't be.

Well, I guess that's good for now and I'm tired of typing.

Cheers,  Adam

> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel