I can think of several reasons for this, but there are some aesthetic problems in KDE applications which are fairly easy to deal with, and they do make a noticeable difference. So it is worth fixing them.
Something that was picked up in comments to various kde-look.org mockups for KDE 4 is that they look clean in part because they don't have many of the ugly frames and borders which litter KDE applications at present.
The majority of these frames and borders are not deliberately put there by application developers, they arise as a by-product of the way in which the user interfaces are constructed. For example, a tab widget is created, which is filled by a list box. Both the tab and the list box have borders by default, and so the on-screen effect is an unpleasant double-thick pinstripe border. KDE 3's default Plastik style makes this worse because it uses thickish 3D borders for quite a number of user interface elements. Gnome's aptly-titled Cleanlooks has thinner, less visually pronounced borders for many elements, which helps somewhat.
Removing these borders is, for the most part, easy to do.
Below are a couple of screenshots of Akregator. The first is the KDE 3.5.5 out-of-the-box screenshot. Both the list box containing the list of feeds and the article viewing area have borders around them. The second has both of these removed.
Akregator (KDE 3.5.5)
Akregator (patched to remove frames)
One persistant offender is Qt's tab widget. It has a border around it which I have not yet been able to turn off. This is the fellow responsible for the 3 or 4 pixels of dead space at the bottom of the Konqueror window, and also the reason why Konsole still has a border around the display widget if you hide the window decorations ( the associated bug report has > 200 votes, I really do want to fix it for KDE 4 ).
There are three things which can be done by various parties to improve matters:
- Developers: Take a closer look at your application and see if there are any unecessary visual borders which can be removed
- Users: Take a closer look at the applications you use and bring instances of excessive frames or poor spacing to the attention of developers
- Trolls: Please help me with the QTabWidget issue. Will sweeten the deal with beer at the next Akademy
38 comments:
tres chic :)
I like it more with frames than without it, but thats my opinion.
I also prefer the frames concept more, but then again I express my personal opinion.
Nassos
Robbo you son of a gun... excellent work, that definitely looks cleaner.
well it seems that some of us like it and some of us don't. i personally do not care but the frameless version seems nicer to me.
Some time ago, when I was toying with Qt4 Styles, I also dealt with the frames of TabWidgets.
I cant remember exactly what I did.
Somehow I resized the SE_TabWidgetTabContents, but you might want to look at the code.
http://www.cs.uni-potsdam.de/~sthiele/qt4style/
Please keep in mind, I was just playing. ;)
I prefer with less frames.
The list on the left side though
still has it :-)
Excellent work!
Can you add a small border to the bar between articles list and text, please? I don't like also the line in "status" combobox (between text and the arrow).
tnx
The improved look after removing the frames is remarkably better. I for one, vote to go with the new style.
A lot of the visual clutter on KDE windows borders comes from the fact that menus are "stuck to the windows"--as with Microsoft Windows. This is especially noticeable if you're coming to it from Mac OS X.
Going to System Settings > Desktop > Behavior > Menu Bar at Top of Screen
and checking "Current application's menu bar (Mac OS-style)" immediately improves the look--and, I think, the usability.
You still don't get true application-centred menuing. For example, if you had two Konqueror windows open and chose Location > Quit then you'd only "quit" the frontmost window *not* the application.
But it does streamline the look of the interface.
Great work, Robert.
I was talking to a Kopete user recently who made me aware of these extra borders as one of the reasons why KDE can look more cluttered than its competitors (look at the chat window for an example), it's good to see that you've made the same realisation and are doing something about it.
I suggest we organize a weekend of polishing and buffing for KDE 4 where a few people share the techniques of removing those extra pixels and go through most of the apps methodically.
Bille
Hello,
I dislike all this extra lines and spaces in kde apps. So, thank you for thinking about how to remove them! Hopfully, they are history in the times of KDE 4!
This is also a matter of widget style. Look at my unpatched Akregator (983x898 in 155,3 KB). The style is Serenity available on KDE-Look. (Unashamed plug.) ;-)
> I suggest we organize a
> weekend of polishing and
> buffing for KDE 4 where a
> few people share the techniques
> of removing those extra pixels
> and go through most of the
> apps methodically.
That sounds like a good suggestion. This is an activity that needs a mix of developers and end users.
Probably worth thinking about when we get to the feature freeze, but before the string freeze.
> This is also a matter of
> widget style.
Yes. Ultimately the widget itself specifies roughly what type of frame it should have - so this is something which really needs to be fixed at the application level.
> (Unashamed plug.)
Plug away :) Good work on the style so far.
Yep, that's a start :)
But there's more than only the lines that clutters the look of the applications unnecessarily:
For one, the ugly dots that are put everywhere:
1) at tear-off handles (top left in the screenshot)
2) between resizable "sections" (e.g. right of the feed list, not very noticable in this special case)
3) on scrollbar handles (right hand side of the window)
For my personal use I remove them completely (if I find the time to modify my theme), but I guess at least number 3 should rather see a proper, calmer looking replacement. Ubunutu's Gnome-theme does it right, for example.
Second, a pet peeve of mine; the underlining of shortcut keys: _F_ile, _E_dit and so on, all across the interface. These should be able to be configured so they only show up as soon as you press the Alt key.
Makes more of a difference than you'd think, and especially new users don't understand why they're underlined anyway.
One persistant offender is Qt's tab widget. It has a border around it which I have not yet been able to turn off.
Maybe sometimes a Tabbar is more appropriate, it comes without frames.
Far more elegant without frames. I wrote a blog post on this many years ago (and that extra space at the bottom of Konqueror has been the bane of my existence for God knows how long!). Here's an example of what a Python/KHTML based web-browser that I wrote a while back looks like. See the bigger rendering space?
> Maybe sometimes a Tabbar
> is more appropriate, it
> comes without frames.
In that case though you would end up re-implementing QTabWidget, but omitting the tab rendering code.
As it stands there are also a number of drawing/layout problems when using the tab bar standalone. The tabs are much wider for example.
> For one, the ugly dots that
> are put everywhere:
That is a part of the widget style. I cannot say that I have a problem with them myself - but equally I don't feel that they are all that helpful.
As for the underscores, I'd be a bit more careful about that one - ie. reading up just to make sure there isn't a good reason why they are shown all the time before making them only appear in certain contexts.
Robert Knight:
Many of the things discussed here are controllable by the widget style :)
The default style is important, so I'd say discussion about what it should do does belong here.
But I guess Thomas is well aware of most problems of Plastik and friends...
About the underscores:
Do you have any idea where one could read up on that? Or maybe our accessibility guys should be asked...
awesome work!!
I really like it without the borders so much more!!!
Furthermore I really dislike all the borders in config dialoges:
http://shots.osdir.com/slideshows/slideshow.php?release=752&slide=23
it would look so much more polished if there were no borders... and after all, the borders fullfill no purpose
I absolutely agree!!
Less frames is definitely a plus for mee too.
But in the same time we need to think about providing a clear focus hint. For your aKregator example, I guess that removing the list view frame removes the focus hint.
I proposed displaying a perferctly visible focus hint within the tab to address the problem.
Wonderful. I am not joining the debate whethere it looks better or not, but the fact that this can be done is great.
Any quick howto/pointer how this is done ? Subtle or tricky issues that I should be aware of ?
Thanks in advance for saving me some time in combing the API docs.
I love very much the new border-less look.
But at the same time, the separation between the news-table and the news-preview is not sharp enough.
A solution should be to programatically declare if borders should be added to splitters.
For the tree/tabs splitter, there should be no border because both the tree and the tabwidget have borders. The splitter is very fine looking.
But for the table/html splitter, the programmer should specify to display both top and bottom borders.
I say "both top and bottom borders" because in some case the top widget can have a border (so the splitter should not display a top border) while the bottom widget do not have border (so the splitter should ONLY display a bottom border).
This will solve the mixed feeling talked about in the comments: some love the new border-less look because it is clean, but some do not because it is not sharp enough arround the right splitter.
> Any quick howto/pointer
> how this is done ?
Any widget which inherits from QFrame ( this includes all scrollable areas I think ) has a setFrameStyle() method.
The process just involves identifying which widget the frame belongs to ( usually this is fairly obvious ) and calling widget->setFrameStyle( QFrame::NoFrame )
If this is a KPart container that you are dealing with, the KPart's widget needs to be dynamically cast to a QFrame and then if the widget is actually a frame, setFrameStyle() can be used in the normal way.
QFrame* frame = dynamic_cast<QFrame*>( myKPart->widget() );
frame->setFrameStyle(QFrame::NoFrame);
> But I guess Thomas is well
> aware of most problems of
> Plastik and friends...
There is no harm discussing things - it provides more feedback to base decisions on.
> But at the same time, the
> separation between the
> news-table and the news-preview
> is not sharp enough.
I see what you mean.
Actually I think this might be solveable within the widget style by colouring the middle part of the splitter darker ( at the moment the whole splitter uses the standard light-window colour ).
Finer control over borders ( sides, styles etc. ) is available through the Qt stylesheet mechanism in Qt 4.2. I'm not sure whether this covers this particular use case though.
Very nice.
I agree with Anonymous , the default style (which currently is Plastik) needs some cleaning.
The biggest problem seems to be that the borders/frames Plastik provides are thick and have a 3D effect; I still think some are important to separate different elements. In this example the list of articles and the preview.
By the way, KDE4's default style will be Oxygen, won't it? Does anyone have a screenshot of its current state?
Thanks for tackling this problem, Robert!
Would it be possible to go even further than your second screenshot by collapsing together the borders of widgets that touch each other? Multiple borders would then become a single, thin border.
Here's an example of what I'm referring to. The list title should be made to touch the outer border of the list, and they should share that border, not duplicate it. Currently there's an ugly white space between the two borders.
The one with less borders looks way cleaner IMO. But I wonder why you come up that late with this idea, it's been one of the most discussed things on kde-look.org, and one of the "bugs" everyone agreed on. Take a look at the description of styles - really most of them say that they try to remove all the useless lines (Lipstik, Serenity etc.).
And 3D effects aren't always bad, just take a look at domino!
But actually, before going on with the discussion, I think it would be useful to see a screenshot or realistic mockup of what Oxygen is going to look like (as lars already requested).
Of course we can go on and edit the plastik style, but when it's going to be replaced by oxygen anyway, why not start there?
The comment about the borders in config dialogs hits the nail on the head.
Compare the Kubuntu screenshot in that comment (*) to this one from Ubuntu:
http://shots.osdir.com/slideshows/slideshow.php?release=751&slide=18
The Gnome config screen looks a lot cleaner. Grouping the elements by using headers instead of borders makes sense.
(*: http://shots.osdir.com/slideshows/slideshow.php?release=752&slide=23)
> But I wonder why you come
> up that late with this idea,
> it's been one of the most
> discussed things on
> kde-look.org, and one of
> the "bugs" everyone agreed on.
Yet the problems have remained unfixed for some time in the out-of-the-box KDE 3. This is about bringing the problems to the attention of people who can make the necessary changes.
I did a load of this with Amarok around 1.1/1.2. It makes all the difference.
Since then people have ruined the look again though. I may clean it up again sometime in 2.0 development.
If you add two Qt::MidGrey lines either side of the splitter you'll get a slightly better look.
It may be worth detecting the style and only doing this for plastique. But I imagine it will improve the look for most styles.
Oh, that's great !!
This is not an optional improvement, this is a MUST !
Always hated those frames, they took space and are just ugly.
Isn't there a development wiki where we can collect all the excellent points being made here? KDE could look infinitely more snazzy, and it seems like just the right thing to do for KDE4...
http://labs.trolltech.com/blogs/2008/07/02/some-qtabbar-qtabwidget-love/
Do I get beer?
> Do I get beer?
Absolutely. Name your pint :)
it really very good.
I love it !
I like it !
thanks :)- .
Bathmate
Post a Comment