View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017323 | Scribus | General | public | 2024-11-26 19:29 | 2025-10-25 09:44 |
| Reporter | ale | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0017323: on applying colors | ||||
| Description | the new widget for the colors is cool. but, on my system ,i experience a few problems: - when the color has been applied, the "drop down" does not close. i can use the esc key but i'd prefer if the first click closes the dialog or a double click if there is a reason for multiple clicks. - when the dialog has closed, the focus does not goes back to the previous focus (text or shape). this seems to be already the case in 1.6, but now that it's new, it disturbs me more : - ) - the mouse has to travel far away from the button i clicked to the first color (see the screenshot). i wonder if it could possible to put all the buttons on the same line... but it's a very good change, that's for sure! | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Patch | No | ||||
| related to | 0017540 | new | Metabug: UI fixes for the release of Scribus 1.8 |
|
|
Hi Ale, the current color picker is just an intermediate version. The final version supports real-time color mixing and has more features like color harmonies, see screenshot. In this case, it makes sense to keep the color picker open after color selection/change. For now, we could have a configuration for the "close behavior" in the settings. I prefer to keep it always open until I close it myself. I will think about how to optimize the layout for the current version to reduce more white space. Just another idea I had during development. Do you think it's better if the color picker is a dockable window that the user can place anywhere in the UI, e.g. docked or floating, but always in the same position? |
|
|
I'm not sure if it is a good idea to make defining new color the fastest thing to do. Most of the times, when I open the Colors selectors, I want to pick an existing color. Mostly, one that I am already using in the same document, sometimes new one from a know list of good colors. Personally, I love the idea of making it (much) easier to add new colors, but it's likely that Scribus should stick with forcing the user to create (and use) named colors: the deception will be big, if the printed work comes back with slightly different tones of red on each usage! And, if we stick to that concept, applying an already defined color should IMO the fastest thing. I'd also wish that the list of existing colors (and the list of colors in a swatch) would also come in a nice tiles view: some colorful squares, with the name and RGB/CMYK values in the tooltip (with an easy to reach button for switching back and forth between the current details list and the tiles) Christmas is coming soon : - ) I attach my wish list : - ) |
|
|
what i'm missing in ale's christmas wish is the quick recognition of the color system (rgb, cmyk, spot…) without the tooltip. otherwise i agree. the users shouldn't be encouraged to define a new color instead of picking an existing (or even an already used) one for every use… |
|
|
We've already discussed the tile grid elsewhere. I think switching between compact (tiles) and expanded (list) makes sense. If you've only defined CMKY colors, you probably don't need the color space hint. I also have ideas on how to map this information into the round color buttons. >> the users shouldn't be encouraged to define a new color instead of picking an existing (or even an already used) one for every use… Hmm, maybe I'm the only one who prefers the "playground" approach. If I don't know what colors, styles, fonts and other things my design needs, I usually just create a test page and play around with different combinations. When I've found the right values, I create my color palette, styles and other things. Sometimes it turns out at a later stage that some definitions don't fit yet, and then I change something locally to see which colors, fonts, etc. fit better. Currently, it's very difficult to test color changes without having to create new colors in the color palette every time. What I personally still miss in Scribus is the ability to simply save the local changes, e.g. of paragraph styles or line styles, in new styles, or to apply the changes to modified styles. But I already have ideas for that. >> the deception will be big, if the printed work comes back with slightly different tones of red on each usage! Perhaps a new preflight check could be added to detect similar colors and warn the user? |
|
|
" Hmm, maybe I'm the only one who prefers the "playground" approach. If I don't know what colors, styles, fonts and other things my design needs, I usually just create a test page and play around with different combinations. When I've found the right values, I create my color palette, styles and other things. Sometimes it turns out at a later stage that some definitions don't fit yet, and then I change something locally to see which colors, fonts, etc. fit better. Currently, it's very difficult to test color changes without having to create new colors in the color palette every time." You are not alone. I often work this way too. |
|
|
Today, I've used for the first time the new color widget in a slightly more intensive way. I still think that the default behavior should be to close the dialog as soon as the color has been picked. But it's indeed handy to be able to apply colors to multiple items, one after the other (oh, I'm so used to Scribus not being able to apply a format to multiple items, that I did not even try to apply the color to a multiple selection; but now I digress...): I would suggest to replace the close button by a "pin" one that switches to close when clicked. Users needing to apply different colors to multiple items, would then click on the "pin" button, select the affected items and apply the colors and, when finished, close the colors popup. Some more "random" thoughts: - We need unique ids and not names for the colors. Names should be optional (of course, when you've found the "right" colors, it's a good practice to give them names, but it's not the first thing you should be forced to do, when testing a color... - When trying out colors , we probably don't want Scribus to create a color item for each color we clicked: if no better ideas pops up, we might add a button to remove all unused and unnamed colors. - How to modify a color? (same name, different value...) |
|
|
I second ale. It will be wonderful if the palette closed after applying the colour, and the "pin" button suggestion would come very handy. I guess if the deault action is to close the dialoge box after applying, it is only logical to have such an option to keep it open, for other use cases. |
|
|
ON A RELATED NOTE: Sorting colours has an issue: 1. Right click inside the Colour Widget dialog box. 2. Sort by Colour and/or by Type. Close it. 3. Next time you open it, it is again alphabetical. It is on Scribus 1.7.1.svn on Fedora 42 (Wayland) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-11-26 19:29 | ale | New Issue | |
| 2024-11-26 19:29 | ale | File Added: distance.png | |
| 2024-11-26 20:02 | nitramr | Note Added: 0051667 | |
| 2024-11-26 20:02 | nitramr | File Added: Bildschirmfoto vom 2022-09-09 17-18-02.png | |
| 2024-11-28 10:06 | ale | Note Added: 0051676 | |
| 2024-11-28 10:06 | ale | File Added: colors-tab.png | |
| 2024-11-28 15:03 | utnik | Note Added: 0051684 | |
| 2024-11-29 11:33 | nitramr | Note Added: 0051690 | |
| 2024-11-29 18:27 | PeterBenedek | Note Added: 0051692 | |
| 2025-05-30 06:18 | ale | Relationship added | related to 0017540 |
| 2025-10-25 08:10 | ale | Note Added: 0053114 | |
| 2025-10-25 08:57 | qirat | Note Added: 0053115 | |
| 2025-10-25 09:44 | qirat | Note Added: 0053116 |