Here, I just came across these weird things in k-infocenter. I'm uploading attachments. In-case of memory, I have used 74% out of 400GB, remaining amount which should amount to around 80-90GB free memory, but it shows I have only 0.8GB free. I have included 2 screenshots of similar problem. Another one is information is regarding my battery, where it displays my battery is fully charged, but it isn't, and my battery notification shows it is 78% and discharging. Here's the link for screenshots: https://drive.google.com/open?id=0Bw1lzCYKRpNqMzBlNjZvaERlWUk
Could you increase the size of the left section to see if the information was just cropped?
... decrease the size of the left section, or increase the size of the right section ...
Git commit 1fd35936668a168c19beb7c8def4f42380e43a4d by Christoph Feck. Committed on 04/11/2016 at 22:37. Pushed by cfeck into branch 'master'. Fix battery charge state display M +1 -1 Modules/devinfo/soldevicetypes.cpp http://commits.kde.org/kinfocenter/1fd35936668a168c19beb7c8def4f42380e43a4d
Adding Hugo for the KCapacityBar issue. The default rendering of KCapacityBar is visible on https://api.kde.org/frameworks/kwidgetsaddons/html/classKCapacityBar.html "inline text" mode draws the text inside the bar "outline text" mode draws the text below the bar KInfoCenter uses the "outline text" mode. KCapacityBar::minimumSizeHint() assumes this layout. With Fusion style (which does not customize the rendering), the text is correctly drawn below the bar, and elided with trailing dots, if it does not fit completely. With Breeze style, the text is rendered to the right of the bar, and the bar and leading text characters vanish when it does not fit completely. Can KCapacityBar respect the different layout, in other words, is there some QStyle::sizeFromContents() for this custom ControlElements implemented in Breeze?
Created attachment 102042 [details] Bigger Image I'm extremely sorry for the delay, I didn't have internet connection for a while, so please excuse me, being noob I didn't understand anything of comment4 , but I would try my best to help. Here is the screenshot,
When you are viewing disk information, you can resize the sections by grabbing the splitter between them. This should reveal the cropped information. The battery status is already addressed by the comment from comment #3, and comment #4 is for Hugo.
(In reply to Christoph Feck from comment #4) > Adding Hugo for the KCapacityBar issue. > > The default rendering of KCapacityBar is visible on > https://api.kde.org/frameworks/kwidgetsaddons/html/classKCapacityBar.html > > "inline text" mode draws the text inside the bar > "outline text" mode draws the text below the bar > > KInfoCenter uses the "outline text" mode. > > KCapacityBar::minimumSizeHint() assumes this layout. > > With Fusion style (which does not customize the rendering), the text is > correctly drawn below the bar, and elided with trailing dots, if it does not > fit completely. > > With Breeze style, the text is rendered to the right of the bar, and the bar > and leading text characters vanish when it does not fit completely. > > Can KCapacityBar respect the different layout, in other words, is there some > QStyle::sizeFromContents() for this custom ControlElements implemented in > Breeze? Hello Christoph Thanks for adding me to the bug report. So, first, this is not really a bug, right ? i mean, all the information is displayed, provided there is enough space for it. More seriously, in the current kcapacity bar implementation, the drawTextMode you mention is only used when internal rendering is called, it is not known to the style at all. I guess one could pass it via a property on the widget, at the minimum. And then you are right, there is the minimumSizeHint. It basically works only if internal rendering is used. In principle the class should also call a style-implemented minimumSizeHint (some sizeFromContents with the right elements), in case of styled rendering. All in all there seems there is a need for some reworking of the kcapacitybar class if we want to really support sized rendering ....
Created attachment 102044 [details] Image Extending the left section Here is another screenshot, another screenshot was included in google-drive, link https://drive.google.com/open?id=0Bw1lzCYKRpNqMzBlNjZvaERlWUk
Please read comment #6. I did not request a new screen shot, and certainly not of the battery section (which I already fixed). Note that a bug tracker is also used for communication between developers, so you might read discussions that you cannot follow. In that case, it is better not to interrupt.
Hugo, do you remember if there was a reason to change the layout? Or was it just implemented this way in Oxygen/Breeze from the beginning? In the latter case, I could change the internal layout to match what Oxygen/Breeze do, and adjust the mimimumSizeHint() accordingly.