Bug#27716: see function under container file in project treeview
linuxgroupie at ivanhawkes.com
Fri Jun 29 18:32:38 UTC 2001
Hey hey all,
I've been away for a while programming the new telegraph jobs site and the
communities site for London Stock Exchange, but I hope to get back into
helping out with KDevelop again ;-)
These suggestions all look pretty sensible, but maybe we should make it user
FINGERPRINT: 9C39 2EB4 9EC6 1A5A 0863 9344 628B 9D32 B338 EE0D
"My brother went to London and all I got was this lousy tagline."
> -----Original Message-----
> From: Mailing list agent [mailto:mdom at barney.cs.uni-potsdam.de]On Behalf
> Of jbb
> Sent: 29 June 2001 12:59
> To: kdevelop-devel at kdevelop.org
> Subject: Fwd: Bug#27716: see function under container file in project
> ---------- Forwarded Message ----------
> Subject: Bug#27716: see function under container file in project treeview
> Date: 26 Jun 2001 07:30:24 -0000
> From: aaime at libero.it
> When developing project in pure C it would be useful
> to see which function in defined/declared in which file...
> now I can only see a flat list of function and variable...
> it would be nice to see them in the project treeview,
> each function listed under the file in which is defined/declared
> (yes, both
> under .h and .c files), and to see the difference between exported
> and static (local) ones. As such it would be easier to
> develop program in a modular fashion even in C (don't
> tell me to develop in C++, if you are volounteering in a
> project based on C you cannot change the language...)
> I agree with this one.
> a c file usually reflects a "module".
> And another wish for kdevelop3.0
> can we have the global namespace as well in the class view
> + global
> + KIO
> + blah
> Otherwise most of the classes are missing.
> and yet another
> in the other mode (not namespace) rather than just every class in
> the tree
> how about spliting them into the subdirs they are in - presumably the
> programmer did that to organise the files. Having the dir
> structure reflected
> in the tree would be better that everyclass merged.
> options upon options eh :-)
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel