[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: [kde-artists] oyxgen style + kmultitabbar
From:       Jamboarder <jamboarder () yahoo ! com>
Date:       2007-10-01 19:49:43
Message-ID: 345833.70611.qm () web37314 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

Hello Mathew,

My responses are below.

Matthew Woehlke wrote:
> > - Should use cases for different display resolutions
> > be added to the QA section?
> 
> Possibly, did you have something in mind? (Currently I don't think we 
> make any adjustments for different resolutions... nor does any style, 
> for that matter, as far as I know.)

Since many widgets have increased in size compared to the previous default style, \
this was really only a suggestion to audit some criteria (content-window size ratios, \
widgets falling outside of window contents, toolbar item fall-off, etc.) at \
resolutions on the lower and perhaps even the higher end.   The intention here would \
be to identify any regressions (compared to say plastik) that might be unacceptable \
and address them either in the style, if it affects many apps, or in the app if it is \
more isolated.  Depending on the results and how they're addressed, it might also \
help identify a minimum "recommended" resolution for the style.

Matthew Woehlke wrote:
> > - Have we selected a benchmark against which we can
> > measure the "performance" of this style to aid
> > regression testing?
> 
> Nope, although I do know there are performance issues currently :-). 
> Like, the slab* and group box backgrounds should probably be cached and 
> aren't.

I suppose I also meant "performance" in the not-just-how-fast-it-goes sense but also \
perhaps against some criteria like those I mentioned above.  Maybe even request \
someone from the usability group supply a simple list of criteria to look for during \
regression testing.  The "benchmark" in this case would (at least) be the previous \
default style. As with any regression testing, the point would be to make sure that, \
based on the regression test criteria, we are no worse than the previous default.

Matthew Woehlke wrote:
> > Beyond pointing out these and other things, I'm
> > willing to volunteer some time each week to help.
> 
> Coding help would be awesome (especially things like fixing the metrics 
> stuff that doesn't need so much artistic direction and isn't always 
> obvious), but even pointing out "TODO"s is useful.

I didn't get a chance to get on #oxygen this weekend.  But I'm happy to help with \
testing and simple code fixes.  (I might also be able to tackle the just-not-yet-done \
stuff that already has a clearly defined artistic direction.)  I'll get on #oxygen \
early this week.  Till then, or anytime, anyone from the oxygen team can feel free to \
contact me via email.

Respect,
Jamboarder

----- Original Message ----
From: Matthew Woehlke <mw_triad@users.sourceforge.net>
To: kde-artists@kde.org
Sent: Monday, October 1, 2007 11:29:29 AM
Subject: Re: [kde-artists] oyxgen style + kmultitabbar

Jamboarder wrote:
> Perhaps that should be added to list of things that
> need fixing/completion on the Oxygen project Techbase
> page.  I'll volunteer to add it, if there are no
> objections.  

I object ;-). Mainly because the page already says:

*  tabs are not drawn correctly
   * [assigned: mwoehlke] we need "inverse slabs" to fix this
   * directions other than north aren't done at all

But I'll entertain improvements to the current wording if you think it 
is needed.

(Since I see it looks like you - or at least someone - already edited 
the page, I guess you noticed this :-).)

> - Content padding on the buttons in the lower right is
> too small. (I thought I saw a commit that seemed to
> fix this...)

Some fixes have been attempted, but there are still quite some issues. 
Thanks for the addition, I am going to add a QA note as well.

> - Should use cases for different display resolutions
> be added to the QA section?

Possibly, did you have something in mind? (Currently I don't think we 
make any adjustments for different resolutions... nor does any style, 
for that matter, as far as I know.)

> - Have we selected a benchmark against which we can
> measure the "performance" of this style to aid
> regression testing?

Nope, although I do know there are performance issues currently :-). 
Like, the slab* and group box backgrounds should probably be cached and 
aren't.

(* internal term for the "visual idea" used for buttons, non-editable 
combos, etc.)

> Beyond pointing out these and other things, I'm
> willing to volunteer some time each week to help.

Coding help would be awesome (especially things like fixing the metrics 
stuff that doesn't need so much artistic direction and isn't always 
obvious), but even pointing out "TODO"s is useful.

-- 
Matthew
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane

______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists



______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists


[prev in list] [next in list] [prev in thread] [next in thread]