|
|
colorsandfills.patch (435 bytes) |
|
|
Here's a screenshot illustrating the "new" wider dialog, where most color names aren't ellipsized: scribus_colors_and_fills.png (85,960 bytes) |
|
|
Not a fan of this patch. The length of color names depends on current system font and theme. On Windows, with current dialog width, just a few colors names are ellipsized in the case of Wikipedia RAL Classic swatch. With your patch the dialog appears much too wide, with lots of useless blank space. |
|
|
@jghali while I understand your point, I'm not sure whether that's the right perspective... [1] If the list is too wide, and there's blank space, that has little to no practical disadvantage [2] if the list is too narrow, and entries are ellipsized, colornames can't be read without resizing the window, forcing users to act on something, that really shouldn't require any action in 99% of cases. So I'd argue that [1] is much less worse than [2]. The width I chose is a compromise already, and does not remove ellipsization entirely, going over all the included swatches there's still longer color names that will still be ellipsized, but this now happens much less than without my patch. |
|
|
" So I'd argue that [1] is much less worse than [2]." I agree. |
|
|
For me in the case of [1], my first reaction will be to reduce the dialog size, especially as with this patch it gets almost two times as wide as necessary. So for me [1] is as bad as [2]. |
|
|
Imo a solution could be to use QFontMetrics functionnalities. The idea would be to guarantee that the tree view can display a certain minimum number of character by default. QFontMetrics allows us to retrieve an average char width (by using averageCharWidth()) for a quick estimation or text size by using boundingRect() or size() for a more precise estimation. |
|
|
Here is my attempt at using QFontMetrics. Some adjustments related to screen pixel ratio may still be needed. I'll have to test on my other laptop tomorrow. 16890_colorsandfills.patch (1,842 bytes) |
|
|
i wonder if switching the panes would allow to have a list with a variable width... scribus_colors_and_fills-2.png (91,912 bytes) |
|
|
@jghali, thanks for the patch, but as-is there's no point, two reasons: [1] It resizes the Tree, not the window, it's not good to have the buttons change size. [2] It resizes the Tree, when the window is opened, based on the current contents of the tree, which means it will be as tight as it can, which by default is way to tight, meaning, there are loads of colornames (if added) that will still be elipsized. Having to close/re-open to window for it to resize, isn't faster/easier than just resizing manually, which is what this ticket was all about in the first place. What would be much more useful, is to determine the window size on a static string, for example something along these lines: fontMetrics.horizontalAdvance("HCL 000 00 00 Bright Orange") That would still account for different fonts, and leave rooms for most names to not be ellipsized, with a few rare exceptions. |
|
|
I'm wondering whether we're in fact wrong about this issue and if we should just make this dialog remember its size like palettes or file dialog. One thing I've noticed tho is that the dialog resize itself when loading new palettes and that's bad, that will require additional fixes. |
|
|
The dialog remembering it's size, doesn't fix the real issue. The real issue, is that it's way too narrow by default, in which case the user would still commonly need to make it wider. This should rarely if ever be needed. |
|
|
>> The real issue, is that it's way too narrow by default Sorry, but that's not the case on Windows. So I don't see why I would make a change which would make the dialog way too big for 80% of our users. The dialog remembering its size would be a compromise solution. |
|
|
>> One thing I've noticed tho is that the dialog resize itself when loading new palettes and that's bad, that will require additional fixes. Unfortunately it looks like that one will be tricky to fix. |
|
|
I agree that something needs to be done to this window. In 1.7.x, we should rewrite it. For 1.6.0, we need to get it to a reasonable state. Its not acceptable how it is now. |
|
|
Arghhh! It seems QFontMetrics is not giving expected results on some screens. Probably something related to logicalDpi() / physicalDpi() / devicePixelRatio(). |
|
|
Maybe this should just be an #ifdef !_WIN32 then resize(532, 427) for the time being? |
|
|
Sorry for the delay, i have been rather busy recently. After tests in various Linux distros and systems, including Mac, it was decided to define a minimum size for Colors and Fills dialog data tree and set that minimum size to be at least sufficient to display color items of around 20 characters. Unfortunately setting that size to something bigger, I had initially considered 30 or 35 characters, would have made the dialog much too large by default on Ubuntu and Macs. I have additionally committed a patch which allows the dialog to remember its size. |
- Anonymous
