View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015740||Scribus||Plug-ins||public||2019-07-16 15:15||2019-08-14 18:23|
|Target Version||Fixed in Version|
|Summary||0015740: It's not possible to add a plugin to the document settings but not to the preferences|
|Description||In a plugin context it does not seem to be possible to attach the preferences panel to the document settings but not to the preferences.|
for the "normal" code, this seems to be done by two different calls to PreferencesDialog(), one with a doc and one without...
the PreferencesDialog constructor should probably pass the doc to the plugin and let it decide if it wants to be attached to the current dialog (by returning true or false) and not take itself the deicision.
|Tags||No tags attached.|
||Hmmm, your issue summary is a unclear... Because script plugins and shortword plugins are for sure already creating their own panel in preferences.|
||And having document specific plugin options is probably the start of a dangerous path: that may imply you may need a specific plugin installed to have a document render correctly.|
shortwords settings will make a document different, depending on the shortwords settings (well, maybe not in the specific case... but it could...)
it does not make a difference if two scribuses have different preferences or two documents have different document settings.
except that a scribus might ignore document settings set by another scribus.
in my use case, i'd like a non-dynamic table of contents (it fills the table of contents on demand, not automatically) to store the paragraph styles used for the TOC in the document settings.
i need a solution here: i'm creating a table of contents plugin, which could be converted to a tool before being committed... but i'd really like not to have to change dozen of "common" files for adding it (menus, preferences, ...).
if you don't want the table of content implemented to be added as a plugin, i'd really like a path for adding it in a modular way.
this would make it much easier to contribute new code and it would also help new contributors to understand how the scribus code works.
(as an example, it is currently hard to understand all the steps one has to do for creating a menu entry).