Store results of Biblatex backend detection and use it in consequent runs

Review Request #106363 - Created Sept. 6, 2012 and submitted

Information
Eugene Shalygin
kile
268047
Reviewers
kile
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.
Manual testing

Issues

  • 22
  • 0
  • 0
  • 22
Description From Last Updated
Could you leave the methods 'public' here? Michel Ludwig Michel Ludwig
Just to keep the naming convention: writeBibliographyBack... -> setBibliographyBackendToolName readBibliographyBack... -> bibliographyBackendToolName() Michel Ludwig Michel Ludwig
This should take a KActionCollection* parameter and be moved before "setupGUI". Michel Ludwig Michel Ludwig
I'd leave the logic for detecting the backend here, i.e. in the LaTeX tool class. Michel Ludwig Michel Ludwig
You can connect each of these actions to appropriate slot, like "biberBackendToolSelected" or "bibliographyBackendAutoDetectionSelection" and then do the appropriate changes ... Michel Ludwig Michel Ludwig
I don't think there is a need to declare a class variable for this string. A preprocessor definition will be ... Michel Ludwig Michel Ludwig
There's no need to declare a variable here. Michel Ludwig Michel Ludwig
You can write "ToolConfigPair(QString("BibTeX"), QString())" instead of "defaultTool" here. Michel Ludwig Michel Ludwig
These methods should no longer be required. Michel Ludwig Michel Ludwig
Instead of exposing the map, could you use methods to access it instead? like "containsBibliographyTool" or "findTool...". The code will ... Michel Ludwig Michel Ludwig
Can you use a QHash instead of a QMap? This is faster. Michel Ludwig Michel Ludwig
Can you use "NULL" instead of "0"? Michel Ludwig Michel Ludwig
Can you make it take "const ToolConfigPair& p" as argument? In that way we don't have to convert back and ... Michel Ludwig Michel Ludwig
Can you make it return a ToolConfigPair? Michel Ludwig Michel Ludwig
Same as above. You can return a ToolConfigPair("","") to indicate that no tool has been set by the user. Michel Ludwig Michel Ludwig
Can you connect this slot to the "configChanged()" signal from the configuration manager ("configurationmanager.h") instead of calling it directly? Michel Ludwig Michel Ludwig
Above all, I don't want to waste memory. If you declare a class variable, it will end up in the ... Michel Ludwig Michel Ludwig
What you probably meant was return a reference to a ToolConfigPair (ToolConfigPair&). Unlike Java, C++ does not consider every object ... Michel Ludwig Michel Ludwig
Could you use the same code as in "LivePreviewManager::buildLivePreviewMenu"? (which actually isn't right as there should be a call to ... Michel Ludwig Michel Ludwig
Hehe, what I ideally want are a few methods with self-explanatory names that make it clear what they are supposed ... Michel Ludwig Michel Ludwig
The Qt documentation states that "QHash provides faster lookups than QMap". QMap will also compute hash values of strings, but ... Michel Ludwig Michel Ludwig
nullptr is part of C++11, which is not yet supported by all of the compilers that are supposed to be ... Michel Ludwig Michel Ludwig
Eugene Shalygin
Michel Ludwig
Eugene Shalygin
Michel Ludwig
Eugene Shalygin
Michel Ludwig
Eugene Shalygin
Michel Ludwig
Eugene Shalygin
Eugene Shalygin
Michel Ludwig
Michel Ludwig
Eugene Shalygin
Eugene Shalygin
Michel Ludwig
Eugene Shalygin
Review request changed

Status: Closed (submitted)

Loading...