View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017323 | Scribus | General | public | 2024-11-26 19:29 | 2024-11-29 18:27 |
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. | ||||
Patch | No | ||||
|
|
|
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. |
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 |