Created attachment 96646 [details] Screenshot of the styles drop down menu Problem description: Styles drop down menu is too narrow in Libreoffice Writer Steps to reproduce: 1. Click on the styles drop down menu to choose a Heading style. 2. The drop down menu is too narrow and does not display all the text as required. 3. In Libreoffice 4.2 and earlier the drop down was wider and allows more of the text to be seen. Current behavior: Styles drop down menu does not display enough of the text due to it being too narrow. Expected behavior: The drop down menu should be wider to show more of the text as was the case in previous versions. Attached screenshot shows the problem. Operating System: Windows 7 Version: 4.3.0.0.alpha0+ Master
Confirmed on 4.2.3.
*** Bug 79220 has been marked as a duplicate of this bug. ***
This has been an issue since the style drop down was shrunk in 4.2, atleast thats why i'm guessing as i'm running 4.2.5. I assume this should be easy to fix, simply by setting the width of the drop down to 150 pixels as it used to be in 4.1.6.
(In reply to comment #3) > I assume this should be easy to > fix, simply by setting the width of the drop down to 150 pixels as it used > to be in 4.1.6. Not sure it's a good idea, because it may look too wide on HiDPI, at least that was the reason for the change. See http://lists.freedesktop.org/archives/libreoffice/2013-December/058146.html for more information. Hopefully it can be resolved in a way similar to Bug 73051, which deals with a similar regression with the font size box, introduced by exactly the same commit.
*** Bug 81900 has been marked as a duplicate of this bug. ***
*** Bug 82701 has been marked as a duplicate of this bug. ***
don't ever bother dropping someone a mail or anything ... (like hi, thanks, we're already on it! - don't ever bother, really) cause we are machines or what ... or cogs in a big machine .) just go the beurocratic way, drop that person some cc :) it took me 15 minutes to report this bug ... i took it seriously, and i meant it ... but i'm sure i'll never do that again Peter on 2014-08-16 / 18:49:01 you wrote: Adolfo Jayme changed bug 76825 WhatRemovedAdded See Also https://bugs.freedesktop.org/show_bug.cgi?id=73051 You are receiving this mail because: You are on the CC list for the bug.
*** Bug 83008 has been marked as a duplicate of this bug. ***
This bug exists since LO 4.0.0.0beta1 - first version where the styles where shown in WYSIWYG. See Bug83008. I set the version to the first 4.*-version. It's the same in Linux, depending on the fonts, which are installed. So I set the platform to "all".
I have increased the size of the dropdown by 10 px in this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=d59e33500a250824e713afacef2ea295576caba6 However, it can still be improved (the size should be calculated based on the width of the items in the dropdown).
*** Bug 87696 has been marked as a duplicate of this bug. ***
Created attachment 112288 [details] Screenshot of the style drop-down in 4.4.0.2 The addition of the button in 4.4 makes this even worse.
The style drop down width shouldnt be fixed to the width of the style control, the same way we are doing it with the font name drop down. Also with bug 62081, we have added the style entry submenu drop down button which takes up 21px, which presently can cover over a style's name, as can be seen in attachment 112288 [details]. The most ideal thing is just like Samuel said in comment 10 that the width of the drop down should be calculated by the items in it, as you could have styles with long names that would be cropped at the current width. Presently we need to have the drop down width set to 180px so that there is ample space with the default styles.
MAB should be set to highest. What is weird is that the person who added this to the MAB list said it's been a problem since 4.0 but the original poster said 4.2.... Also - a bibisect might be useful. https://wiki.documentfoundation.org/QA/HowToBibisect
Starting with LO 4.0, we show entries in the styles drop down not as simple text but as styled text. Bug 83008 (attachment 105195 [details]) states that if you have long style names the drop down doesnt auto resize wide enough to fit the style names. This bug was opened because of the changed in 4.2, which Maxim stated was done by Keith Curtis ( http://lists.freedesktop.org/archives/libreoffice/2013-December/058146.html ), where the control was shrunk as it looked to wide in Gnome 3. The shrinking of the control caused the default style drop down in english to have letters cropped (attachment 96646 [details]) as drop down width isnt been resize wide enough. Samuel's change to the control width in comment 10 recovered half of the space removed by Keith, which stopped the cropping of the default english style names, but bug 62081 introduced a drop down submenu button to each entry which overlaps some of the letters in long names (attachment 112288 [details]). To solve this problem we need to 1) Make the minimum size of the drop down be 180px 2) Accurately calculating the needed space to fit the styled text and add additional space for the drop down submenu button. (In reply to Joel Madero from comment #15) > MAB should be set to highest. What is weird is that the person who added > this to the MAB list said it's been a problem since 4.0 but the original > poster said 4.2.... This doesnt need to be bibisected as it is not a regression in 4.0 as the drop down changed from simple text to styled text in 4.0.
It would be great for Kendy to give his input on this as he was the one who introduced the styled entries in the drop down in 4.0.
Created attachment 113364 [details] err, how it looks for me in 4.4 under gnome3 For me the menu does expand to fit the width of the longest style name (up to a reasonable limit) and looks fine. How some everyone elses screen shots don't look like mine ?
Created attachment 113367 [details] the 4.4.2.0+ Style selection menu button with a wide label as on Windows 7 (In reply to Caolán McNamara from comment #18) > ... How some everyone elses screen shots > don't look like mine ? Attaching a screen clip from Windows 7 sp1, 64-bit en-US with 4.4.2.0.0+ from 2015-02-11_15:55:36 Locale: en_US I would agree it is doing what it is supposed to. Expanding the dropdown width to some limit (~240px? looking at a Pixel Ruler session) to display a sample of the styled text, also displays the style name label aligned right in its fixed box. This all seems correct-- we don't want the menu box to expand, we don't want the "styled" dropdown listing of styles to expand too wide. The split button selector only exposed on the active style selection. Believe it has the right balance--but may not be what folks have been used to.
So what's going on here is that the width is the width of the longest text in the *default* UI font. What we'd have to do is to user-draw *all* the entries and not just the special ones. Then not store the text to be rendered in the combobox drop down itself, but store it elsewhere. Calc the width of each entry ourselves as it will be drawn in the destination text user-draw callback and set that width as the user-added-width to the combobox, i.e the width of the dropdown becomes 0 text entry width as calculated by itself + X extra width as calculated by us.
Created attachment 113368 [details] a long style name in font smaller than Default -- it all fits (In reply to Caolán McNamara from comment #20) Confirming, attached using a font point smaller than Default--it all fits. That is it appears the length of the longest style name present in the document/user profile is the target for resize. But that calculation of the combobox dropdown's width is now using the metrics from the default style's font--rather than of the target, and so is not being set wide enough? But, wouldn't handling them all in advance add a lot of overhead? And where would the style name list be stored? Needed for each user profile, but also needed in the ODF since it would have to be bundled with each document--right?
Only need to calculate the length of the 10 strings shown in the menu as they are entered at runtime. So no biggy. As to where to store the sizes, it can be done the same way as the font name dialog beside it which has to do basically the same thing, except with a lot more entries than the stylename box. It just means the FontStyleListBox has to have a vector of widths which it updates as it enters an entry and massages the numbers to keep its ComboBox superclass happy. Might be able to carve out a little time next week to make it work
(In reply to Jay Philips from comment #16) > This doesnt need to be bibisected as it is not a regression in 4.0 as the > drop down changed from simple text to styled text in 4.0. Whiteboard -> bibisectNotNeeded
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=856e9b5fe2293bef9c45219391aca664d4a0dd20 Resolves: tdf#76825 styles drop down menu is too narrow It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
https://gerrit.libreoffice.org/#/c/15471/
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c66a574ff2532e27b24aec32ac2e590bedffef1&h=libreoffice-4-4 Resolves: tdf#76825 styles drop down menu is too narrow It will be available in 4.4.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 115019 [details] new style drop down Tried it out and it looks good, but had some questions. 1. What is the maximum width of the drop down as i've seen it max out at around 300px? 2. Is it possible to add a little bit of padding between the button and the last character of the style name? possibly simply increasing BUTTON_WIDTH from 20 to 25 or 30.
(In reply to Jay Philips from comment #27) > 2. Is it possible to add a little bit of padding between the button and the > last character of the style name? possibly simply increasing BUTTON_WIDTH > from 20 to 25 or 30. Jay, if you feel strongly about that, please submit a separate report (but increasing the button’s width doesn’t solve anything in my view). This is what some call “feature-creeping” a bug report.
Added patch for what i was mentioning in comment 27. https://gerrit.libreoffice.org/#/c/19210/
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d65d9c546125ab999d645a921731170d60fa14ee tdf#76825 Add padding between style render and context button It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e31192d12f07fd773ce919e8ebb9d14a5677e9f8&h=libreoffice-5-1 tdf#76825 Add padding between style render and context button It will be available in 5.1.0.0.beta0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded) [NinjaEdit]