View Issue Details

IDProjectCategoryView StatusLast Update
0009217ScribusImport / Exportpublic2010-10-31 21:28
Reporterchristoph_s Assigned Tofschmid  
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Target Version1.3.9Fixed in Version1.3.9.svn 
Summary0009217: Improvements to the handling of colour palettes
DescriptionAs per discussion on IRC, we want to prevent standardised colour palettes like Resene or the dtp-studio palettes from being edited inadvertently. While it's possible to add an extra tag to palettes in the Scribus XML format, this approach won't work for other formats that can be imported by Scribus, e.g. EPS or AI.

Proposed solution:

1) We will create an additional install directory under ~/swatches, e.g. ~/swatches/industry (/locked, whatever). All palette files in this directory cannot be edited from within Scribus, and standardised palettes will be installed here. If a colour is selected when no document is open, the "Edit", "Delete" and "Duplicate" buttons will be disabled (just like "Registration", CMYK Black and CMYK White are at the moment).

2) If a user wants to create a customised palette (e.g. by removing unneeded colours), he needs to work with a copy. This copy will be stored in the user's home directory, which will probably require a new subdirectory $HOME/.scribus/Resources/swatches (or the equivalent on non-*NIX systems). These customised palettes will use the Scribus XML format, no matter what format the original palette uses.
Additional InformationProblems/additional requirements:

A) Working with a duplicated palette is already possible in the current colour editing dialog (via "Save Colour Set"). However, a user should be warned that working with a copy removes the safety mechanism, which may be dangerous when using standardised colours. A user should also be informed that the copy will be saved to his $HOME directory, that it won't be available for other users/on other computers, and that the copy will be stored in the native Scribus XML format. Therefore, we may also need to add a "Save As" option that allows for easy exporting of custom palettes to any given location (again: only Scribus XML is needed, as palette files can be easily converted using SwatchBooker).

B) Users should be able to use standardised palettes by copying them to the $HOME/.scribus/.../swatches directory without touching system-wide directories. Hence the requirement to
a) add another subdirectory to ~/swatches (for convenience with the same name as in the system-wide directory) and
b) allow for reading of all supported palette file formats if such a file has been copied to this directory.

C) I think it would be useful to add an additional warning to an already existing function: If the default palette has been edited when a document is open (i.e., after editing and clicking "OK" in the "Edit Colours" dialog), a user should be notified that the changes are only stored in the current document.
TagsNo tags attached.
Patch

Relationships

related to 0008397 closedchristoph_s Provide useful documentation for solid colours in general, colour theory, as well as our new palette sets 
related to 0008184 closedchristoph_s Colour palettes: US FS 595, Geology 

Activities

christoph_s

2010-06-29 02:48

administrator   ~0024257

Another thought: Shouldn't importing a palette when no document is open result in an automatic addition to the palettes under $HOME/.scribus/.../swatches?

Currently, the colours of an imported palette are added to the selected palette.

An "easy way" out of this problem would be to add two options to the drop-down list: "New Palette" and "Load Palette".

christoph_s

2010-06-29 03:45

administrator   ~0024258

Last edited: 2010-06-29 04:55

Next issue: Why not add a "Path" option for palette directories to the Prefs? (1.5 only)

joncruz

2010-06-29 05:35

reporter   ~0024259

One factor is to coordinate with the XDG Directory Spec. A shift in approach would then be to not use a single subdirectory as a read-only location, but instead have a parallel read-only directory tree (or trees).
http://standards.freedesktop.org/basedir-spec/latest/

then a read/write user directory hierarchy would be under:
$XDG_DATA_HOME/scribus/.../swatches

and a list of read-only 'system' directories would be under:
$XDG_DATA_DIRS/scribus/.../swatches

Of course, the key difference is to have a single user *hierarchy*, and a *list* of 'system' hierarchies that are read-only (and not to push an actual change from $HOME/.scribus to $XDG_DATA_HOME/scribus). Appending ~/localusr/ or such to the equivalent of XDG_DATA_DIRS gives the ability for non-root users to install 'system' resources 'safely'

christoph_s

2010-10-31 21:27

administrator   ~0024774

Thanks to the latest fixes by Franz, we have all we need in 1.3.9svn and much more in 1.5svn, so I'm closing this one as fixed.

Issue History

Date Modified Username Field Change
2010-06-29 02:38 christoph_s New Issue
2010-06-29 02:38 christoph_s Status new => assigned
2010-06-29 02:38 christoph_s Assigned To => cbradney
2010-06-29 02:48 christoph_s Note Added: 0024257
2010-06-29 02:58 christoph_s Relationship added related to 0008397
2010-06-29 02:59 christoph_s Relationship added related to 0008184
2010-06-29 03:45 christoph_s Note Added: 0024258
2010-06-29 04:55 christoph_s Note Edited: 0024258
2010-06-29 05:35 joncruz Note Added: 0024259
2010-07-17 20:53 cbradney Target Version 1.3.8 => 1.3.9
2010-10-31 21:26 christoph_s Assigned To cbradney => fschmid
2010-10-31 21:27 christoph_s Note Added: 0024774
2010-10-31 21:27 christoph_s Status assigned => resolved
2010-10-31 21:27 christoph_s Fixed in Version => 1.3.9.svn
2010-10-31 21:27 christoph_s Resolution open => fixed
2010-10-31 21:28 christoph_s Status resolved => closed