CGood:
What I am proposing is that the "Colours" dialog - currently shown by menu "Edit -> Colours" - and the "Edit Colour" dialog - currently shown by pressing either the "New" or "Edit" buttons on the "Colours" dialog - are combined into one single non-modal dialog (or palette, depending on how you want to call it).
If the dialog (palette) is designed correctly then it could be resized as the user wants. My recommendation was that it should be able to be sized to fit into a vertical strip that can - if the user wants it to - be docked or simply placed to one side of the main canvas. If the user wants to make the dialog as short as possible then that would be up to them. Conversely, if the user wants to make the sliders as long as possible then they should be able to extend the height of the dialog to accommodate that.
CGood / a.l.e / Martin:
I'm not sure what "Should the list of open palettes be linked to the document or to the Scribus instance?" means. What "palettes" are being talked about - colour palettes or UI palettes (e.g. dialogs), or something else - and what constitutes an "open" one?
If palettes refers to UI palettes (dialogs) then I would agree with Martin that their constitution - open/closed, position, etc. - should not be linked to a document. There are many reasons for this, and Martin has already given one, but one specific case would be if someone using a very hi-res screen (e.g. 4K) passed a document onto someone else with a much lower resolution screen. The main window and the dialogs could have positions/sizes that are outside the lo-res screen area which could render Scribus unusable.
If, on the other hand, palettes refers to colour palettes then I think it would be nice if Scribus could handle multiple palettes within the same document. For example, if someone has a newsletter where the colour scheme changes by season - e.g. orange in summer and blue in winter - then it would be good if the user could easily switch between different variants of the same palette. In this way, the colour "Primary" could be orange in the "Summer" variant and blue in the "Winter" variant. Having this kind of functionality would also mean that the user could test lots of variations of colours while being able to revert back to a particular saved scheme without having to write down the colour values.
Martin:
I don't know how your "Colour Picker" dialog is supposed to work but I think the inclusion of gradients and patterns may have some problems. Gradients and patterns can only be given to fills and not outlines, therefore the user should not be able to choose either a gradient or pattern for outlines. How would you achieve this? Would the dialog "know" that you were picking a colour for an outline and not a fill?
I like the idea of keeping all of the colour stuff together, I just don't know how you intend it to be implemented. Maybe I have just not properly understood what you are doing.
General:
I think some confusion might be starting to creep in here about different dialogs for different things.
The change in functionality that I was suggesting for the "Colours" and "Edit Colour" dialogs - combine and make non-modal - are, in my mind, not to be confused with any kind of "colour picking/choosing/selecting" dialogs/panels/panes/windows.
To me, for DTP purposes, the act of defining/editing colours should be a different function to choosing/picking/selecting colours. The user should define the palette that they want to use and then choose from that palette as needed. A little like going to the DIY store to get the paints you want (defining the colours), then putting your brush in the right paint pot (choosing the colour).
Maybe there is a way of combining the two functions but I don't know how that could be achieved or how effective it would be. I think it would be better to keep the two functions separate. This forces the user to think about how they apply colour to their documents rather than just using whatever they want. I realise this way of working is a bit of a throwback to the old mechanical printing processes but I think it's important that Scribus keeps to this tradition even if most people don't get their documents printed the "old fashioned" way.