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

List:       kde-core-devel
Subject:    Re: Gnome Article on UI Design on /.
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-04-22 14:31:20
[Download RAW message or body]

On April 22, 2002 12:47 pm, Waldo Bastian wrote:
> On Monday 22 April 2002 05:41 am, Aaron J. Seigo wrote:
> > why do you think it is hard to side with a "single idea"? probably
> > because different people work in vastly diferent
> > ways/methods/environments. so you end up with a large chunk of people who
> > need/want it something one way, and a large chunk who want it another.
> > you can either have a niche product, cripple the interface for many
> > users, or be configurable.
>
> I think the problem is that many features are being added without taking
> the big picture into account, without thinking of the feature in terms of
> "task".

agreed .... many features are useful but not as well thought out as possible 
or simply redundant.

> I am currently looking into kcmfontinst and one the things that puzzles me
> is that you can choose whether to delete a font or to move it to /tmp. This
> is a typical example of a bad feature. I don't want to move a font to /tmp.
> I can hardly imagine anyone else would. Maybe people want to temporary
> disable a font (why?) and you could implement that by moving the font to
> /tmp, but the feature to move the font to /tmp is pretty silly. If I want
> to move files around I use konqueror.

perhaps you want to disable a font to save on memory and/or make your font 
picker menu smaller / faster ... when i used to work more with fonts (on a 
mac. hi tink!) this was the primary reason i'd disable fonts.

that said, yes, "move fonts to /tmp" is silly and won't work that great for 
disabling fonts on systems that clear out /tmp ;-)

personally, i'd suggest removing the delete feature (as you said, if you want 
manage files you'll use konqi) and keep the uninstall font feature (and 
default the uninstall to somewhere better than /tmp). but i'm not writing 
that code, so .........

-- 
Aaron Seigo
[prev in list] [next in list] [prev in thread] [next in thread]