| Summary: | Create empty settings object if none is created from outside okular core library | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Bogdan Cristea <cristeab> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | aacid, cristeab |
| Priority: | NOR | ||
| Version: | 0.14.80 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | create empty settings object if none is created from outside okular core library | ||
Created attachment 70906 [details]
create empty settings object if none is created from outside okular core library
That's a quick and dirty solution but not really optimal since you have no access to the settings headers so you are stuck with the default options that might not suit you. The solution I would like is make it so that the user of the library can create it's own settings instance, the problem is that settings now mixes things used in core like the memory and things used in the ui like should show the sidebar or not. What do you think about splitting the current settings into CoreSettings and UISettings and then installing the CoreSettings headers? That could be even better. Maybe we could create some documentation about the available settings. They are documented in okular/conf/okular.kcfg |
A better separation is needed between okular core library and the front-end. Currently one Settings object is initialized from part.cpp, which is not in okular core library. Also, settings.h file is not exposed to the user (at least not in openSUSE 21.1 okular devel package) and thus it makes impossible to use okular core library only. Reproducible: Always Steps to Reproduce: 1. Use okular core library in a stand alone program (not okular front end) 2. Try to open a document Actual Results: The program exists immediately saying that Settings object has not been initialized Expected Results: Should be able to use Okular core library using the exposed header files. This issue could be fixed by calling Settings::instance("") in DocumentPrivate ctor. See the patch below: From a24c05938c3097d4d821dd71db5f7e49ea34855a Mon Sep 17 00:00:00 2001 From: Bogdan Cristea <cristeab@gmail.com> Date: Sun, 6 May 2012 22:11:25 +0200 Subject: [PATCH] create empty settings object if none is created from outside okular core library --- core/document_p.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/core/document_p.h b/core/document_p.h index 4f78d9a..c3bcd66 100644 --- a/core/document_p.h +++ b/core/document_p.h @@ -26,6 +26,7 @@ // local includes #include "fontinfo.h" #include "generator.h" +#include "settings.h" class QEventLoop; class QTimer; @@ -87,6 +88,7 @@ class DocumentPrivate m_fontsCached( false ), m_documentInfo( 0 ) { + Settings::instance("");//make sure that Settings object is initialized calculateMaxTextPages(); } -- 1.7.7