Okay everyone, it's time for a new task force!
(Imagine the leader-type in a movie bracing him/herself for that inspiring speech before facing a life-or-death situation)

My comrades in the fight for a better visual experience of Plasma 5.1. The situation is dire.
[Pause for effect]
When I tried out the most recent Project Neon 5 ISO (which uses our shiny new Breeze controls style by default), I noticed that a lot of System Settings modules and also other dialogs like Plasmoid configurations have a default window size that fits their content exactly - if the Oxygen style is used. However, in line with its name - the Breeze controls give take more breathing room, and therefore cause the content to just slightly outgrow the boundaries set for it by the initial window size.
This causes scrollbars to appear (which just make things scroll a few pixels) and sometimes elements which are flexible in height like lists or tables to have too few lines by default (see the keyboard layouts tab for example, where the table holding the layouts shows only one row).

This situation is not tolerable. A window which has both horizontal and vertical scroll bars even though there is still plenty of space left on the screen makes us look horribly unprofessional. We need to fix this situation. [Pause for effect, looking everyone in the eyes]
This, my brothers and sisters, is where all of you come in.

Checking every window and dialog for this problem is too much for one man or woman to bear. But together, we're strong, and we can do this!
So we need everyone who either already runs Plasma 5 (and either has not resized the windows yet or would be willing to create a new user to test it) or could test with the latest Neon 5 ISO to take a few of those windows/dialogs and test them both with the Oxygen and Breeze widget style.
Please write which dialogs/windows you've taken in this notepad (you can log in with your Identity account)
If a dialog/window is too small even with Oxygen, file a bug report because that's clearly a problem.
If it's only too small in Breeze, report it in the document above.

The hopes of all Plasma 5 users lies on you, my comrades, we must not disappoint them!
[Raises a fist and waits for a choir of battle cries!]

a dialog that's too small is a bug regardless of the used style, because it relies on some hardcoded initial size - which will fail with just the "wrong" fontsetting.

OK, this is first time for me doing something like this. So i checked all the modules in Appearance and Workspace (with the NEON ISO) so far and there are at least three (Desktop Theme; Application keyboard shortcuts; Window Behavior) that I noticed are wrong (they have bottom scrollbar when there is no reason for them to have it) only in Breeze. I reported those into notepad.

Then there are several dialogs wrong even with old Oxygen theme. Those are: Window Decorations, GTK Style, Accessibility, Task Switcher. I guess I will have to report those as bugs.

The last thing, I may be able to fix those with my knowledge of C++/Qt/QML. But I would like to know are some of these dialogs already rewritten in QML or are all of them still in C++/QtWidgets?

luebking wrote:a dialog that's too small is a bug regardless of the used style, because it relies on some hardcoded initial size - which will fail with just the "wrong" fontsetting.

That was our feeling as well, but we were not sure if it can always be avoided. But if you consider hardcoded initial sizes a bug, we'll gladly report those as bugs and quote you if the devs complain

MatusT wrote:OK, this is first time for me doing something like this. So i checked all the modules in Appearance and Workspace (with the NEON ISO) so far and there are at least three (Desktop Theme; Application keyboard shortcuts; Window Behavior) that I noticed are wrong (they have bottom scrollbar when there is no reason for them to have it) only in Breeze. I reported those into notepad.

Awesome work, thank you a lot!

Then there are several dialogs wrong even with old Oxygen theme. Those are: Window Decorations, GTK Style, Accessibility, Task Switcher. I guess I will have to report those as bugs.

Yes, that would be great, thank you!

The last thing, I may be able to fix those with my knowledge of C++/Qt/QML. But I would like to know are some of these dialogs already rewritten in QML or are all of them still in C++/QtWidgets?

Oh, that would of course be the king of awesome! I'm currently trying to find out if any of those are QML. If anyone reading this knows, please enlighten us
If you have any questions about the fixes, feel free to hop on #plasma on IRC or send a mail to plasma-devel@kde.org . I'm sure people will be glad to help you there!

Update: I only got "A few KCMs are QML. You can tell it from the code and maybe from some visual glitches in QML versions". So I'd suggest you take a look at the code and ask the Plasma devs if you're unsure.

Latest Neon 5 ISO http://files.kde.org/snapshots/ is from 29-Aug-2014, so before reporting bugs it would be nice to try something more recent

lucas wrote:Latest Neon 5 ISO http://files.kde.org/snapshots/ is from 29-Aug-2014, so before reporting bugs it would be nice to try something more recent

Yes, it's quite old, but I don't think that any work has gone into the initial window sizes since then. I'm already nagging the Neon guys to update the ISO, though

Technically, what is the correct way to set a default size for a dialog? I guess I should not do it in pixels ...

have the layouting system do it for you: QWidget::adjustSize()
That's however seldom required and you could usually just set a "preferred" size (fraction of the screen) as the dialog would not underrun ::minimumSize()

The problems start when a widget resides in a scrollarea - you'd the adjust the contained windows size, force that (+margins) as minimum size of the scrollarea, adjust the entire dialogs size and restore the former scrollarea minimum size.

Since the scrollarea exists for a reason, the last step should be a clamp to the ::availableGeometry() of the screen.

luebking.

when you say:

you could usually just set a "preferred" size (fraction of the screen)

Does that mean we could do with making a note of the screen resolution that we're running in that notepad document that Colomar's
setup when we do notice a size problem in case that dialogue has been done using this 'fraction of the screen' method instead of just X pixels x Y pixels?

ken300 wrote:Does that mean we could do with making a note of the screen resolution that we're running in that notepad document that Colomar's
setup when we do notice a size problem in case that dialogue has been done using this 'fraction of the screen' method instead of just X pixels x Y pixels

I'm not 100% sure about what you ask, but please notice:
- Window sizes are *always* set in pixels.
- What I meant by this was just an example to illustrate that *usually* a developer can safely attempt to set the window to a particular size (w/ the screen fraction just being an example on how to determine the size he'll set in pixels) because the layouting system will ensure the window will not end up smaller than is required to show all it's contents.
The "problem" here is that a scrollarea does not need to be bigger than its scrollbar widths, therefore the layouting system cannot ensure the window to be large enough so that no scrollbars are shown. The scrollbars are the very concept of that thing and showing them is (usually) absolutely ok, in the cards and wanted.
-> Any window that contains a scrollarea and wants to prevent it to show its scrollbars if any possible *has* to perform some additional steps to inform the window about the preferred size (which i roughly sketched before, but that's only relevant for developers)

Whenever your code contains something like:
window->resize(640,480); // sufficient to prevent scrollbars ON MY BOX CONFIGURATION
is simply buggy.

Otoh, this:
window->resize(640,480); // i'd prefer the dialog in 4:3, looks more like a stopper
is perfectly fine (implying that 640x480 is just a suggestion to the system)

And this here:
window->setFixedSize(640x480); // force it fullscreen
is a disaster

I'm not sure that this is what you want or not but i noticed this:

In the Neon 5 ISO suggested there's a small issue that is only an issue with Breeze, not Oxygen as far as i can tell - when you go into System Setting > Device Actions and you edit or create an action, a pop-up appears. On that pop-up the box titled 'Devices must match the following parameters for this action', when you're using the Oxygen theme feels plenty big enough & holds just over 7 lines of text - but with the Breeze theme it's (i think) a bit too cramped and only holds just under 3 lines.

OK - I've found a place where using the Breeze theme cases a horizontal scrollbar to appear when one isn't really needed - it only happens in Breeze, Oxygen is fine. It's on the 'System settings > Desktop Behaviour > Activities' page, both of the tabs on that have a horizontal scrollbar when it's not needed when in Breeze.

Here's the question - i also noticed another bug affecting one of the two tabs of that page (there are two tabs on the Activities page) but it affects both Breeze and Oxygen. I'm guessing i should add the 'horizontal scrollbar' issue that's just affecting Breeze to the notepad here and file a bug report for the other issue, is that right?

ken300 wrote:OK - I've found a place where using the Breeze theme cases a horizontal scrollbar to appear when one isn't really needed - it only happens in Breeze, Oxygen is fine. It's on the 'System settings > Desktop Behaviour > Activities' page, both of the tabs on that have a horizontal scrollbar when it's not needed when in Breeze.

Here's the question - i also noticed another bug affecting one of the two tabs of that page (there are two tabs on the Activities page) but it affects both Breeze and Oxygen. I'm guessing i should add the 'horizontal scrollbar' issue that's just affecting Breeze to the notepad here and file a bug report for the other issue, is that right?

Yes, do that for now. We'll probably end up filing bugs for the case that only affects Breeze, too, but let's collect them first. Thank you!

Before you start spamming bugs

Please notice that *all* KCMs that cause scrollbars in systemsettings are *one* bug - a "bug" in systemsettings, so to speak.

I haven't looked into the code, but systemsettings can oc. not predict the size of all the kcm widgets it will open (or starting systemsettings would take ages
So there's probably at one point a "useful" size for systemsettings been chosen and kcm developers sought to get their kcm there fitting - for the default settings.

This is not suddenly a bug because breeze is now more size consuming, but systemsettings could be altered to
a) grow itself to fit the new page - if possible (otherwise "maximize")
b) shrink itself to fit the new page unless the user has at previously set an explicit size

if altering the window size for content updates is OK with the HIG guys.

Colomar - another quick question:

From an earlier post of mine that was overlooked:

I'm not sure that this is what you want or not but i noticed this:

In the Neon 5 ISO suggested there's a small issue that is only an issue with Breeze, not Oxygen - when you go into System Setting > Device Actions and you edit or create an action, a pop-up appears. On that pop-up the box titled 'Devices must match the following parameters for this action', when you're using the Oxygen theme feels plenty big enough & holds just over 7 lines of text - but with the Breeze theme it's (i think) a bit too cramped and only holds just under 3 lines.

Add to the notepad or bug report??