Bug and thoughts on multiple languages
John R. Zedlewski
zedlwski at princeton.edu
Mon Jul 26 05:20:46 UTC 1999
There seems to be a bug in the app template's slotSaveFile() method: it
calls: doc->saveDocument(doc->getPathName()+doc->getTitle()); but
"getPathName()" already returns the full absolute path. So instead of saving
"/home/jrz/filename.txt", you get "/home/jrz/filename.txtfilename.txt". The
"save as" however, is fine. It seems like this would have popped up a while
ago, however, seeing as how kapptemplate isn't just used by KDevelop.
BTW, how does one get CVS access? I feel bad having to hit the list with
something like this when I could change it in about two seconds.
Also, I agree with people who suggest that KDevelop be extended to include
other languages, but I agree even more strongly with those who said that it
should start by solidifying its C++ capabilites. Maybe it would be smart,
however, to start designing that C++ functionality in such a way that it could
be expanded later. For instance, we could add a "language=" line to .kdevprj
files, and just make it "CPP" for now.
In the long-run, it would be cool if you could use KOM/OP and base each language
on a simple config file, like:
extension=c cc C cpp
Then it could just load KOM modules for "kdevelop/parsing/cpp_parser" and
"kdevelop/options/cpp_options" and they would take care of the
Of course, I mention this largely as an indication of how far away I think this
would really be. It's a lot of work. And it would need KDE 2.0, IMHO, to be
really done right. Maybe in the meantime, though, it would be smart to
experiment with making an abstract base class for the parser and the project
options dialog. If we really just wanted Java, IDL, and C++ , subclassing and
hardcoding would probably be enough, but if we want to cover and conceivable
language (and I'm not sure we do), you'd probably need KOM.
Sorry that I ramble so much,
More information about the KDevelop