This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106363/

On September 10th, 2012, 6:58 p.m., Michel Ludwig wrote:

Thanks for changes! Here are a few comments:

1. Instead of using strings, I'd do everything with enums. For example, have the following methods in LaTeXOutputHandler:
   enum BibliograhpyBackendSettings {AUTO_DETECT_BACKEND, BIBTEX_BACKEND, BIBER_BACKEND}
   
   BibliograhpyBackendSettings bibliographyBackendTool();
   void setBibliographyBackendTool(BibliograhpyBackendSettings s);

   void setAutoDetectedBibliographyBackendTool(const QString& s);
   QString autoDetectedBibliographyBackendTool() const;

   Also, I think that BibliograhpyBackendSettings should only be a very light class, only there for reading/storing settings. So, the logic for auto-detecting the tool should go back to the LaTeX tool class.
2. The KSelectAction needs to be added to a action collection (see one of the 'createActions' methods). If you give it a name like "set_bibliography_backend" in the addAction method, you can add it in "kileui.rc" (the version of that file also has to be increased in the 'kpartgui' tag).
3. There is need to access menus directly. This can all be done using KXMLGUI techniques (see 2.).
4. I think it should be enough to use to the "General" group. This will also avoid having to take of varying group names.
5. That's because Kile also works with single documents. It's of course possible to add the backend settings to the project configuration dialog.

It seems a bit complicated at the moment to store the backend settings for single documents. I'll think about how this can be done best.
Dear Michel,

thanks for the review, first of all! 
1. It seems like we have a bit different points of view on this backend question: I would absolutely agree with all of your suggestions about enums and locations of the code if I'd be sure that there will be no other backends. Is it really the case? I was not sure and that is why I use strings (and a map). If one would need to add one more backend (bibtex8? bibtexu?) then that part would need adding new identifier only, but not two new functions. Also, in the current logic of backend selection one needs something to say "no data avaliable". Empty string is easy for that. Enum value "NO_BACKEND_INFORMATION" is ugly for me, exception (logically ideal) is too heavy for that. That is another reason why I choose strings.
Regarding item "2" I'm grateful and will try.
3. Do not understand, sorry.
4. As you wish.
5. I remember Visual Studio was creating projects is memory to make use cases identical... That was quite nice

- Eugene


On September 9th, 2012, 11:02 p.m., Eugene Shalygin wrote:

Review request for Kile.
By Eugene Shalygin.

Updated Sept. 9, 2012, 11:02 p.m.

Description

As we can detect what backend is used by Biblatex only when it prints it out, we need to store that information for next updates of bibliography

This patch use dirty approach: it just stores this as dynamic property of TextInfo object and uses it afterwards. I believe we must store this information somewhere or parse \usepackage{biblatex}.
Maybe in the future Biblatex will provide some other setup commands for specifiyng backend which will be needed to parse also.
I understand, that dynamic property is not the best place to store it. From the other hand, it is kind of local information in this approach, because property name is not used outside.

Testing

Manual testing
Bugs: 268047

Diffs

  • src/documentinfo.h (27ad09f)
  • src/documentinfo.cpp (2c3a3bb)
  • src/kile.cpp (8061b54)
  • src/kileproject.h (e77035a)
  • src/kileproject.cpp (dd4087d)
  • src/kilestdtools.h (769e8ca)
  • src/kilestdtools.cpp (0c6e5f0)
  • src/kiletoolmanager.h (86e2258)
  • src/kiletoolmanager.cpp (d06e36f)
  • src/outputinfo.h (096c708)
  • src/outputinfo.cpp (8d18adc)

View Diff