On December 19th, 2012, 7:41 p.m., Michel Ludwig wrote:
Thanks for that patch! I also like the idea of making Kile more intelligent when it comes to the detection of dependencies.
However, I think before we make deep changes, we should first discuss what the future purpose of projects should be. As far as I can see it, one major feature of projects was that Kile didn't have to keep track of dependencies as they were imposed by the user through the member files of projects. But if Kile now can determine the dependencies automatically, the requirement to use projects somewhat fades away.
Other that that, I've seen that you've made changes to the parser. Did you do that in order to fix a bug?
As for me, the project is the place where it is possible to store some settings that can not be deduced from the source files. Like, for instance, Kile saves encoding of the project items. Another good option is archiving. So, as for me, it will be logical to keep all this scheme. What is really nice to have is an option "include/exclude to/from project" in the item popup menu in the project view.
Since files can be included by different LaTeX commands, it is needed to know those commands for correct parsing. And user can specify his ones. I'm not sure if parsing of the .aux files can help in all cases. For instance, we need to define a group of commands like \includegraphics to track image in dependencies. Then, for example, datatool package adds command to load CSV tables, PGF/TikZ objects can be included. I just want to say that is not easy to cover all that cases without forcing user to define all the commands he uses for connecting an external content. So, I see no objections for keeping the projects as is. At least until we think that Kile can be easily configured to track all possible types of dependencies.
Concerning the parser: I've included this change in the commit by mistake and then it went to the uploaded diff. I'm sorry. It is not directly related to this patch. That change (const Kurl& -> KUrl) was made to make possible clearing of the url of current parsing document right after the parsing (connected to question #2 in the review request). It it needed for the re-queying of the documents.
Anyway I think usage of the reference is wrong here because you do not know when other thread process the event and thus you shall pass object to the subscribers by copy to be able to change the local one.
P.S. Did you miss https://git.reviewboard.kde.org/r/106616/ ? That is very small change to fix the bibliography backends changes handling.
On December 18th, 2012, 5:49 p.m., Eugene Shalygin wrote:
Review request for Kile.
By Eugene Shalygin.
Updated Dec. 18, 2012, 5:49 p.m.
Kile tracks depepndencies for build and for project view widget using project items only. It is common to have several bibliiographical databases and connect them to many projects. Same partially applies for different text fragments, like tables, for instance. Current Kile implementation demands user to add all these fragments to the project manually. However, it is not hard to detect all such dependecies automatically (by parsing source files or .aux files) and give user a list for selection and check-in. So, one of the goals of this patch is to make it possible and simple. Aslo it might have sence to track dependencies for so to say "external" items. For instance, one can have many \addbibresource commands but does not want to add these files to the projects. For example. they are shared and stored in a separate repository.
Another goal is to fix parsing of multi-level includes, that does not work, generally, in Kile right now. Here is an example:
Since include path is always related to the master document, it is impossible to parse subdir\file1.tex correctly before master.tex. If we do not know how that file was included, we can not deduce a full path to its dependencies (subdir\file2 here). Thus, if subdir\file1.tex is either opened in the editor or placed in the project file before master.tex, parsing does not work.
This patch does not achive all of above mentioned goals, but it became long enough already. It is at the point where it does not break current functionality (I hope :) ), but sets a framework for the future. As an attraction, it fixes the parsing problem :)
Idea: split KileProjectItem class into a class that represents a dependency item (either external or part of the project) and a class that stores project item settings. The DependencyItem class partially implements the Composite pattern.
Further steps: add actions to context menu in project view for including/excluding nodes from the project. Implement bibliography and other dependencies chacking via DependencyItem trees. Improve actual dependencies tracking by parsing aux files (where all conditiona are resolved already by LaTeX).
Questions and problems:
1. It would be nice to have a single enum that describes the file type (source, image, ..). Now there are two in KileDocument and in KileProjectItem. Why? Can I merge them?
2. It would be nice to have a possibility to submit items for the parsing in batch and with priority. Right now the project tree is rebuilding after every parsed item, which is not needed. Are there any objections for this?
I'm working with this for a some time
- src/kile.cpp (37f46fe)
- src/kiledocmanager.h (229968e)
- src/kiledocmanager.cpp (825a845)
- src/kileinfo.cpp (419c5b9)
- src/kileproject.h (1dd0c9b)
- src/kileproject.cpp (33f6962)
- src/parser/parsermanager.h (3daaa99)
- src/parser/parsermanager.cpp (0033741)
- src/parser/parserthread.h (c8206f0)
- src/parser/parserthread.cpp (9a01368)
- src/widgets/projectview.h (97b6f29)
- src/widgets/projectview.cpp (d59c1fc)