Since you guys have a bugzilla entry but seem to not want to use it, i'll repeat my comments here.

With breeze my kmail explodes in vertical space making it unable to show the same amount of information that the oxygen one does. Which basically makes me unable to use Breeze since i need to do work and stuff not fitting on my screen is kind of bad for my productivity.

KMail with Breeze: https://bugs.kde.org/attachment.cgi?id=89601
KMail with Oxygen: https://bugs.kde.org/attachment.cgi?id=89602

See how kmail with oxygen can show 12 folders more than breeze and still has some space on the bottom.

Sorry, I missed the bug report TSDgeos. We will, of course, try to recover some space in the list view design in the Breeze style.

However, comparisons to the Oxygen style or any other style wlll always provide only limited validation because they are, by definition, different styles with different design goals regarding spacing and layout. The weakness and limitations of particular application layout design choices will unavoidably be revealed when significant design variations attendant to different styles get applied. The Breeze design intentionally uses more spacing in several places. That doesn't mean adjustments for practicality can't or won't be made. We just need to make sure we aren't always compensating at the style design level for problems that should properly be resolved at the application design level.

In this case, we'll try to recover some space, but I'll say upfront that the spacing is unlikely to be as small as oxygen. Additionally, while any reduction in spacing for list view items will provide some improvement in your specific case, the nature of the tree view makes the highlighted problem data dependent - someone else with more folders will inevitably run into the same problem. So, yes, the situation can be improved, but not solved at the style design level.

I went looking for the bug but, unfortunately, was not successful in finding it. Would you mind sharing the bug report number?

Thanks and hope this helps!

While maybe it's possible to make things a little more dense, having listview items as tightly packed as in Oxygen would clearly be against the design direction of Breeze.

This goes in the same direction as several other threads about Breeze's spaciousness that popped up recently, and therefore I'd solve it together with the others by providing a Look & Feel package optimized for getting more stuff onto the screen (people have suggested "Wheeze" as the name in other threads ).

Aesthetically the current margins and padding in Breeze is superior to Oxygen, but I do understand that for some users or situations, getting more stuff into the available screen estate is more important than aesthetics, so providing a space-optimized Breeze variant does make sense, but it should encompass all elements (including Plasma theme and window decoration).

alake wrote:I went looking for the bug but, unfortunately, was not successful in finding it. Would you mind sharing the bug report number?

https://bugs.kde.org/show_bug.cgi?id=340623
https://bugs.kde.org/show_bug.cgi?id=340999

There's one thing i don't understand, if you look on the right hand side, those listviews actually have the same height, so it's only for treeviews that the is so much more spacing, not for listviews, is that actually wanted? I'd find it somehow inconsistent that lots of spacing is applied to treeviews but not for listviews.

And yes, obviously the "doesn't fit on screen" metric is totally dataset dependant, it was just a way to show how extreme the change is, sure buttons and stuff are a bit bigger, but you don't have 100 buttons in a row, adding 5 pixels to each tree view item, suddenly you end up needed 500 pixels more

There's one thing i don't understand

The message list will have a custom delegate which ignores CT_ItemViewItem.

luebking wrote:

There's one thing i don't understand

The message list will have a custom delegate which ignores CT_ItemViewItem.

That makes sense.

That said: i'm sceptical about the screenshot (visual POV, not "you torture my rodant!" pov
While the oxygen spacing (probably just QWindowsStyle?) is far too narrow, the breeze one may be almost to ... breezy.

I'm currently experimenting w/ additional 3px spacing (together, not per side - and of course DPI aware and so far figured, that I won't use it on plain listviews w/o alternating colors for sure. They start to get disconnected.

The entire spacing on the screenshot is imo (perhaps "already too") close to a spaced teeth effect?

@Andrew
You didn't find it because it was marked as a duplicate by someone else. Default searches ignore resolved bugs. The advanced Search page in bugzilla is the only useful search page. Style bug emails always go only to Hugo. If that isn't ideal, please tell me and we can fix that.

@David, maybe just allowing adding the VisualDesign flag to design-related bug reports against Breeze would be enough - especially since it's still early days for the style design. That way a standard search for bugs with the VisualDesign flag will catch these.

@TSDgeos
As mentioned, we'll definitely take a look at the item heights to try to improve things a bit while attempting to respect the Breeze design goals. I commented on the bug report as well. There's Breeze widget style design work for us to do this cycle as well so now is a good time to consider this. As mentioned, application level design choices have as much to do with spacing issues as the style. We'll address what makes sense to address in the style design, but what will remain at the end of those efforts will be application design challenges that we'll all need to make an effort at improving as well. I just want make sure there's no misunderstanding about what should be expected from style design improvements.

@luebking
Feel free to share the result of your experiments of spacing here.

Hi
In current breeze style, 4 pixels are added on all sizes of each items via CT_ItemViewItem on top of what QCommonStyle. Equivalent for oxygen was "zero".
Personally (but that's obviously subjective) I like it this way, because I favor having items being more readable and easier to select than putting as many as possible on click.
Now I have experimenting with reducing this number to 2, or 3.
Results are at: http://wstaw.org/m/2014/11/19/plasma-desktopLE2433.png
(2 pixels on the left, 3 in the center, 4 on the right)

Also, if you have a self-compiled version of breeze, the setting iss pretty straightforward to change, just alter the value of ItemView_ItemMarginWidth in
breeze/kstyle/breeze.h

Comments/suggestions to a more appropriate value are welcome.
We could also make it an option, but I would not encourage it.

All in all I am all in favor of a compact version of breeze, that is not breeze.
(and as a matter of fact, I think 'compact' would be a nice theme name). But then this must be carefully crafted, to alter all margins/spacings consistently. Button margins; list headers; list items (for instance it makes no sense to reduce the later without reducing the former); spacing between text and icon, spacing between toolbar items, menubar items, menu items, etc.

Hugo, can you make the screen shot with the breeze icons theme. the breeze icon theme has also 2 px empty space in difference to oxygen.

andreas_k wrote:Hugo, can you make the screen shot with the breeze icons theme. the breeze icon theme has also 2 px empty space in difference to oxygen.

Not really, sorry. Don't have it installed here (or rather, most of the icons on the applications I run are still oxygen once I switch to breeze)...
Also, should the choice really be dependent on the icon theme ? I'd rather take the worse case scenario.

I only want to know if for a compact breeze theme the breeze icons also should remove the 2 px margin.

hugo.pereira@free.fr wrote:

andreas_k wrote:Hugo, can you make the screen shot with the breeze icons theme. the breeze icon theme has also 2 px empty space in difference to oxygen.

Not really, sorry. Don't have it installed here (or rather, most of the icons on the applications I run are still oxygen once I switch to breeze)...
Also, should the choice really be dependent on the icon theme ? I'd rather take the worse case scenario.

Your system maybe suffering from this bug[1]. Try removing ~/.kde/cache-fedora/icon-cache.kcache and log out/in. Folder location will depend on your system. But you have to delete icon-cache.kcache from ~/.kde folder. And your KDE 4 apps will use Breeze theme. If this does fix your issue please reply in the bug report to confirm it.

[1] https://bugs.kde.org/show_bug.cgi?id=340580