View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009217 | Scribus | Import / Export | public | 2010-06-29 02:38 | 2010-10-31 21:28 |
| Reporter | christoph_s | Assigned To | fschmid | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.3.9 | Fixed in Version | 1.3.9.svn | ||
| Summary | 0009217: Improvements to the handling of colour palettes | ||||
| Description | As 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 Information | Problems/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. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
| related to | 0008397 | closed | christoph_s | Provide useful documentation for solid colours in general, colour theory, as well as our new palette sets |
| related to | 0008184 | closed | christoph_s | Colour palettes: US FS 595, Geology |
|
|
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". |
|
|
Next issue: Why not add a "Path" option for palette directories to the Prefs? (1.5 only) |
|
|
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' |
|
|
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. |
| 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 |
