|This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107804/|
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?
On December 19th, 2012, 8:22 p.m., Eugene Shalygin wrote: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 27th, 2012, 12:33 p.m., Eugene Shalygin wrote:Whether projects infrastructure has to be updated or not, there are changes (for the parser, for commands definitions) that are independent form the projects. If you are going to accept this review I can work on them right now.
On December 28th, 2012, 9:54 a.m., Michel Ludwig wrote:Unfortunately, I'm still very busy with other things at the moment. But anyway, it would be good if you could split up the patch (if possible). We could discuss it easier then.
On December 28th, 2012, 10:33 a.m., Eugene Shalygin wrote:I see. Do I understand correctly that you want to see a review request for the parser and command definition changes? P.S. Despite the fact that you are busy, I would like to put your attention at https://git.reviewboard.kde.org/r/106616/ again :) It is really small and easy to understand.
Yes, it would be nice if you could set up separate review requests for those changes.
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.