[runSofa] Fix compilation when SofaGuiQt is not activated

[fredroy]

It was not possible to compile runSofa without activating SofaGuiQt, because GuiDataRepository was instantiated in SofaGuiQt library.
As GuiDataRepository seems to be rather generic and not tied to Qt, GuiDataRepository has been moved to SofaGuiCommon ; and allows runSofa to be compiled without enabling SOFA_GUI_QT.

---

This PR:

• builds with SUCCESS for all platforms on the CI.
• does not generate new warnings.
• does not generate new unit test failures.
• does not generate new scene test failures.
• does not break API compatibility.
• is more than 1 week old (or has fast-merge label).

Reviewers will merge only if all these checks are true.

[damienmarchal]

Hi fred,

The sofa::qt::GuiDataRepository is pointing to the set of resources that are specific to the qt application complementing the shared DataRepository ("share/"). Consequently it is the expected behavior to have it only usable when SofaGuiQt is enabled.

I quickly looked in the code base where it is used and the only usage are in qt specific code which shouldn't prevent the compilation. If it does then something is wrong and the right fix is to prevent non qt base code to use this repository.

But maybe the problem you are facing is not a compilation problem but is more about sharing UI resources in different GUI.
To do that I my suggestion is to:

• always consider to have a specific GuiDataRepository in your application namespace, this repository should point to your application specific resource (the ones that are tied to you GUI functionality).
• use the DataRepository to store shared UI elements because this one is already shared by sofa (but do we really want to have UI resources in SofaCore ?).
• or, and I think this is the real way to go, make a plugin (SharedUIResources ) to hold and expose the UI elements we are considering as re-usable by different GUI projects.

But maybe I'm all wrong, if so please tell me.

Damien.

[fredroy]

Hi @damienmarchal

Actually, it was more a linking/DLL problem than a compilation problem. (at least for OS X)
GuiDataRepository is used in runSofa:

GuiDataRepository.addFirstPath(Utils::getSofaPathTo("share/sofa/gui/runSofa/resources").c_str()) ;

runSofa knows the symbol as the header is included ; but if you dont compile SofaGuiQt, the symbol wont be present when the linking occurs (with SofaGuiMain which is supposed to load SofaGuiQt if present)

Anyway, for now I was considering GuiDataRepository as a "global" repository for all GUIs. And making it into SofaGuiCommon seems to do the trick (at least in my point of view). But your solution with the SharedUIResources is more elegant indeed.

[damienmarchal]

Ok I see the problem (why qtcreator is not capable of showing this "usage" of GuiDataRepository is a mystery to me).

Anyhow you are right in moving GuiDataRepository in SofaGuiCommon you need to fix then the path

In SofaGuiCommon.cpp
FileRepository GuiDataRepository("GUI_DATA_PATH", Utils::getSofaPathTo("share/sofa/gui/common/resources").c_str());

And somewhere in qt:
GuiDataRepository.addFirstPath(Utils::getSofaPathTo("share/sofa/gui/qt/resources").c_str()) ;

[fredroy]

Yes, you are right about the path when GuiDataRepository is instanciated !

[fredroy]

[ci-build][with-scene-tests]