Hi Massimo! Regarding the pdf I would split up the language-support-plugins in an indentation part (indent-c-style, indent-python) and the support part. This will clean up the architecture a lot I think - and it is a good starting task for Moritz. Regards, Johannes Am Montag, den 30.04.2012, 18:57 +0200 schrieb Massimo Cora':
Hi, I've attached a pdf with a schema of the (new) architecture as I see it. Suggestions are welcome. Regards, MassimoOn 04/30/2012 05:30 PM, Massimo Cora' wrote:Hi, On 04/22/2012 11:44 PM, Abderrahim Kitouni wrote:I'm not sure what you mean. IIUC, the symbol listing is currently handled by the symbol-db plugin using ctags, do you want to make it so that language-support plugins push the symbols to the symbol-db using better parsers than ctags?symbol-db is currently used for: 1. displaying the current project-file symbols on the GtkTreeView. 2. providing an interface to retrieve info for project _and_ global symbols. See IAnjutaSymbol on libanjuta.idl 3. providing an helper interface (IAnjutaSymbolQuery) for symbol completion, which is used by cpp-parser on language-support-cpp-java. 4. using global packages' headers files to create a cache to speed up the queries on the symbols. Using clang as parser library would mean to drop the cpp-parser implementation on language-support-cpp-java, and the public interface IAnjutaSymbolQuery, as the info of the saved symbols would only be useful for the GUI (as they can be fooled by ctags regexes). I would implement clang as a separate plugin because "symbol-db", as its name suggests, would be only a database of symbols. At this point I would not implement logic there. Its behaviour could be to provide only gtk+ symbol icons (tree, etc), and can work with ctags backend. We may instead create a new plugin, a "generic completion-engine", which could receive requests for C/C++/Python/Vala/etc. An adapter or a strategy pattern can detect which language you want the completion for, and do it. The exchange resulting objects can be defined as a CompletionSymbol with common-language fields (icon, kind, file, comments (to be displayed by a completion-widget on GUI-end). This seems quite elastic to be expandable in the future. Regargs, Massimo _______________________________________________ anjuta-devel-list mailing list anjuta-devel-list gnome org http://mail.gnome.org/mailman/listinfo/anjuta-devel-list_______________________________________________ anjuta-devel-list mailing list anjuta-devel-list gnome org http://mail.gnome.org/mailman/listinfo/anjuta-devel-list
Attachment:
signature.asc
Description: This is a digitally signed message part