A look at GNOME 2.14, comparison to KDE

[Sandro Giessl]

On Wednesday 22 February 2006 20:54, Aaron J. Seigo wrote:
> On Wednesday 22 February 2006 00:58, Anders Lund wrote:
> > Frames was added to KMail windows at some point, probably to address the
> > problem with the look/feel of splitters

In controversy to that, I remember KMail having had a hardcoded frame size of 
1 pixel at the time around the import of Plastik into CVS. This was meant to 
make KMail "look better" with Keramik (the default style at that time) by 
removing the visible "3 pixel line" (splitter aligned to 2 px frame).

But the problem was that this didn't work with the kind of frames used in e.g. 
Plastik (By the time I have changed KMail to use the style's frame width for 
all styles != Keramik).

This is also why I'm generally not in favor of hardcoding something 
gui/style-related into applications: It won't be possible anymore to change 
it centrally (e.g. in a QStyle), so it means additional work for someone who 
might decide to change this behavior in the future (for whatever reason).

> > does not position a
> > scrollbar at the edge of the window: you can't throw the mouse at the
> > edge of the screen with a maximized window and drag to scroll.
>
> it would be nice if we communicated into the widgets that the window was
> maximized so that "outermost" widgets could do things like get ride of
> frames and margins.

One possible solution for instantly providing "Fitt's law" in a wide range of 
applications at once: Position scroll bars on top of the outer frame (e.g. 
when there is a horizontal scroll bar there would be only three frame borders 
visible).
The trolls promised me to add such a QStyle switch for 
QAbstractScrollArea-based widgets in a future release of Qt.

> > I don't know how it would be best to address that problem -- maybe by
> > allowing to specify if a splitter should have a border on either side?
>
> another approach may be to say in the KDE4 HIG "don't use frames around
> widgets that are bound by splitters or which are the outermost widget in a
> tabwidget" and then specify that splitters MUST have borders for a style to
> be HIG-compliant.

In a clearly defined manner like this and if feasible (e.g. it's probably a 
bad idea to remove the frame of tab widgets), this sounds good to me.

Regards, Sandro