kossebau added a comment. Here a more detailed description of the problem:
`KoOdfLoadingContext::KoOdfLoadingContext(...)` uses the passed componentData to get path of `defaultstyles.xml`, by `KStandardDirs::locate( "styles", "defaultstyles.xml", componentData )` In all 3 known usages where `KoOdfLoadingContext` does not get a default invalid one the componentdata is taken from `KGlobal::mainComponent()`: - `KoPAPastePage::process(...)`: `KoOdfLoadingContext loadingContext( odfStore.styles(), odfStore.store(), KGlobal::mainComponent() );` (other than `KoTextPaste::process(...)`, why?) - `KoPADocument::loadOdf(...)`: `KoOdfLoadingContext loadingContext( odfStore.styles(), odfStore.store(), KGlobal::mainComponent());` - `KWOdfLoader::load(...)`: `KoOdfLoadingContext odfContext(odfStore.styles(), odfStore.store(), KGlobal::mainComponent());` Just... all factories create their component data usually after the `KApplication` has created its, so the factories one will not become the main component data (first one wins). That way registering the "styles" dir (and other resource dirs) to the factories' componentData will never be seen if looking at the main componentData. So with code which does not know about the factories and tries to take the componentdata from some central registry (here the mainComponent), another solution is needed. Sheets works around any such problems by always explicitely fetching the componentdata directly via Factory::global(). For Author/Words the solution could be to simply hardcode the path in the one place where the default styles should be used on loading, as proposed in this patch. Avoids any indirection by registering the path in the factory component data only to fetch it indirectly later, but also prevents customization by 3rd-party apps that would like to use the Words part. I would argue for now there are none anway, so let's for now not complicate our code for usecases noone uses. Simply one default styles here. For Stage and Flow this is more complicated (though Flow currently does not install any default styles, still users could customize those for themselves): the point in code where the resource path needs to be known does not know whether it is Stage, Flow or perhaps something else. So it needs to fetch the info from some context. Just, which would be best? Note it with the part perhaps, by creating a special KoPAPart with a respective property? Or else? I am not happy at all with adding the `defaultStylesResourcePath()` property to `KoPADocument`. So far I just haven't had a better idea, and it seemed less invasive for now. For the future I hope this will be resolved to something more clean together with more MVC-refactoring, when the "part" will be removed and some other component instance would be available, where document/view instances can fetch central settings, which could be even configurable by whatever app uses the docs/views. But that is 3.x stuff. For now this is the best idea I have to solve the bug that the installed files are never read. Multi format apps like Gemini will also need another approach in any case, as there is no the one central component for the one type of document. This patch works for Gemini as well. BTW, Krita is safe WRT the problem of rivaling main componentdatas, because it does not use `KApplication`, so no main componentdata will be created on instantiating the app class itself. INLINE COMMENTS libs/kopageapp/KoPAPastePage.cpp:29 Ah, forgot to remove this one from previous experiment to solve this with parts & componentdata. REPOSITORY rCALLIGRA Calligra REVISION DETAIL https://phabricator.kde.org/D128 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kossebau Cc: Calligra-Devel-list _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
