Re: Possible UI Freeze Break in Clearlooks

Il giorno Wed, 14 Feb 2007 16:58:28 -0600
Shaun McCance <shaunm gnome org> ha scritto:

> On Wed, 2007-02-14 at 22:39 +0000, Thomas Wood wrote:
> > Shaun McCance wrote:
> > > On Wed, 2007-02-14 at 22:24 +0000, Thomas Wood wrote:
> > >> The latest release of gtk-engines (2.9.3) has a new checkbox
> > >> style for ticked checkboxes. It uses a cross rather than a tick
> > >> mark to indicate an activated checkbox.
> > >>
> > >> My question is, does this break the UI freeze as the
> > >> screenshots, in documentation might be affected. Does this
> > >> change need to be reverted in order to have consistent
> > >> documentation?
> > > 
> > > I'd say it's a pretty substantial UI change.  Any number
> > > of screenshots in any of our documents could be affected
> > > by this change.
> > > 
> > > Can I ask why this change was made?  Check marks are pretty
> > > much standard check box markers on most platforms.
> > 
> > I think you mean tick marks ;-)
> > 
> > Andrea thought this style was more usable - it being bolder and
> > more visual. I CC'd him on this e-mail in case he wants to explain
> > more.
> Could you provide a before-and-after image of this change?
after: (here
we are showing an added style, btw the checkboxes and arrows are the
same accross all those styles).

Using clearlooks-cairo 2.8.x versions I've noticed i got few
difficulties reading checkboxes/radiobuttons, while with other engines
and previous version of clearlooks those widgets looked nicer and more
visible. The light color of the tick (taken from bg[SELECTED], and the
design of it was causing few usability problems with a lot of themes.
That's why i've proposed those new checkbuttons, more visible, with a
clean style, and that are using text[NORMAL] which is the correct /
logical color since the background of those widgets is taken from a
base[NORMAL] (in the past clearlooks was not supporting text[colors]
and just bg and base ones, that's why it wasn't implemented in 2.8.x
branch, but this was an _error_, not an improvement).
For usability point of view, error fixed (base[normal] and text[normal]
and not base with bg[selected]), better style I really think that's
there's no reason in remove those improvements.
Gnome users are expecting nice improvements in 2.18 release, they will
use that release for 6 months, we _really_ should provide our new cool
stuff (remember kde4 is coming... :D) 

> > There have been a few other (what I would consider) minor changes,
> > such as refinement of the arrow shapes, and even smaller changes
> > with the gradients in buttons etc. What is the documentation team's
> > opinion on such changes with regard to the various freezes in the
> > GNOME schedule?
> I would judge based on whether I expect a non-anal-retentive
> reader to notice.  If you refine the drawing of an arrow to
> make it crisper or less pixelated, that wouldn't concern me
> much.  Technically, any change to the look of a theme is a
> UI change, but changes that don't create differences that
> are obviously noticeable can usually slide by.
> --
> Shaun
Changes were made to _improve_ desktop experience, they're anyway
subtle but very elegant and usable!

Cimi - Andrea Cimitan

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]