Re: gep-2, Desktop Theme Sets

[Bill Haneman <bill haneman sun com>]

On Fri, 2002-08-30 at 03:42, Seth Nickell wrote:
> I basically agree with Nils here in the need for requirements. I am
> personally slightly resentlful of the strong slanting on this gep (just
> count how many times it goes out of the way to re-iterate that fonts
> will be part of the theme set! :-). 

Resentful? Sorry, nothing personal.

It's the first draft, and I did write it, after all.  I would hope that
the editing process will take care of some of this.  OTOH I didn't think
I was that redundant.  By the way, I like your (Seth's) phrasing
regarding the accessibility 'font' requirement, I agree that it captures
the specific need without being too broad.

Requirements capture is very important and probably the first things we
should do, agreed.  However I don't think we need to wait for consensus
on requirements before proceeding further with proposals; a list of
requirements without proposed solutions or volunteers is hard to get
excited about and even harder to get prioritized.

I am editing the doc now, taking on board your comments, Nils' and
Michael's; I am putting requirements in 2.1 as Rodrigo did.

I still wonder about omitting rationale during the discussion stage, it
more-or-less forces me to maintain separate documents for that, which
increases the PITA factor.

BTW, I did not use a requirements form for this GEP because the GEP
documents clearly state that requirements geps are for projects
*without* specific course of action or implementation, and the purpose
of this gep is to propose a course of action.

Best regards,

-Bill

> I would prefer to start from a more neutral requirements gep with each
> section written by the respective representatives from each field. So
> Bill (and Calum?) would work on drafting some accesibility requirements,
> Nils, Calum and I (and Suz?) would work on drafting some usability
> requirements. All this would be mediated with technical requirements
> detailed by involved hackers who would be able to provide implementation
> constraints (for example, figuring out the minimuum time application of
> proposed theme elements would take).
> 
> Each group drafting requirements has a responsibility to provide the
> most general restriction that fufills their criteria. So for example, it
> would be improper to place a usability requirement that "fonts are not
> included in the desktop theme dialog". Similarly, it would be improper
> to place an accesibility requirement that "fonts are changed by the
> desktop theme dialog". Instead they would be better written as, e.g.,
> "settings that most users will want to change from the theme defaults
> should not be included in the theme" and "selecting an accesibility
> theme should change the fonts too". Otherwise our requirements are going
> to quickly devolve into tools for "locking in" a particular interface.
> 
> -Seth
> 
> On Thu, 2002-08-29 at 16:12, Nils Pedersen wrote:
> > Havoc Pennington wrote:
> > 
> > > Bill Haneman <bill haneman sun com> writes:
> > > 
> > >>gep-2, a proposal for "Desktop Theme Set" support, is now in GNOME cvs. 
> > >>I don't think the push to the website is working yet, so I attach the
> > >>current revision, or you can get it from cvs/gep/proposals/gep-2.html
> > >>
> > >>
> > > 
> > > I force-updated it. Tried jrb's rube goldberg thing but didn't really
> > > succeed.
> > >  
> > > 
> > > Anyway, I want to see us start from the top down. We are basically out
> > > of space in the Preferences menu. Do we add submenus and end up like
> > > the KDE prefs menu or the GNOME 1.x menu of old?
> > > 
> > > If not we need to think this through.
> > > 
> > > Just adding a Theme Set control panel will give us these
> > > appearance-related control panels:
> > > 
> > >  - Background
> > >  - Font           (we should rename this Fonts btw)
> > >  - Theme          (includes toolkit - WM - icon)
> > >  - Theme Set      (includes both Background and Fonts in the set, not
> > >                    just themes)
> > > 
> > > In this setup we're still missing one possibly important panel, namely
> > > Colors where you can just change colors (overriding the theme
> > > presumably). [1] 
> > > 
> > > I believe that having both Theme and Theme Set, with Theme Set
> > > actually grouping Background and Fonts in addition to Theme, makes
> > > little sense. So I'm opposed to just adding a Theme Set control panel
> > > without reworking the big picture.
> > 
> > 
> > Yes, I'm beginning to think we are overloading the theme concept here.
> > 
> >  From the Documentation style guide:
> > 
> > "A group of coordinated settings that specify how a part of your interface
> > appears. For example, you can select a default theme for dialog elements."
> > 
> > Which also seems pretty broad.
> > 
> > 
> > > 
> > > How to rework?
> > 
> > 
> > Well one way might to be take a step back and try and figure out what the
> > requirements are :)
> > 
> > For example:
> > 
> > Gnome should support single switch configuration to support different
> > classes of user. These classes of user could be determined by:
> > 
> > 1) accessibility requirements
> > 2) previous experiences (transitioning windows users)
> > 3) environment (home user, work user, country, language)
> > 4) some custom config that a sysadmin wants
> > etc...
> > 
> > Now the scope of some of these "coordinated settings" are beyond what we 
> > 
> > have been talking about. But if we introduce say the concept of "User Theme"
> > 
> > as well as appearance theme (which we already have), then maybe both Bill
> > and Seth will be happy. I'm not suggesting that we go off and implement
> > something that meets all the above requirements, but the different classes of
> > a11y user could be the first step?
> > 
> > I dunno, just an idea, take it or leave it...
> > 
> > Nils
> > 
> > P.S. and i didn't use the p word once :)
> > 
> > 
> >  
> > 
> > 
> 
>