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

List:       kde-artists
Subject:    Re: K-ARTIST:New Icontheme
From:       Torsten Rahn <tackat () kde ! org>
Date:       2002-04-17 11:39:31
[Download RAW message or body]


> what do you think about it?
> is anybody able to code something like this here ;) ?

The problem is not about actually _coding_ this stuff (That's what Simon 
MacMullen <simon.macmullen@aspect-proteus.com> was volunteering for in his 
mail "K-ARTIST:Directory overlays - removing the white sheet").

It's about having a proper concept. 
In fact I had the idea around the release of KDE 2.0 that ...

> Ideally the mimetype-symbol would be a single symbol (without the sheet)
and 
> it would be overlaid over the sheet (according to the mimetype of the 
> document) or over the folder-icon (if the folder contains mostly items of 
> that particular mimetype).

but this mainly would have the drawback of diminuished flexibility.
The artist couldn't do such stuff like the holes in the punchcards which are 
shown on the mimetype-icons (or one would have to define some sort of 
cut-away masks). It also wouldn't make things much easier as the 
mimetype-symbol e.g. always has different sizes (as you've always got to take 
care of proper proportions).

Also it would be hard to get and configure for the user - how would the user 
get what items of an icon are overlays and which aren't? How would you deal 
with other iconthemes where overlays don't exist. How would a user have to 
configure this stuff? What would an artist do if he didn't want a paper to be 
shown for certain mimetypes (tgz, etc. e.g.)?

This basically comes down to two questions which would have to be solved in 
terms of concept BEFORE someone starts to implement something that generates 
a huge mess in the end:

- How would one make sure that the artist will have the same flexibility as he 
does have right now?
- How will you make sure that the user will never have to deal with the stuff 
that happens behind the scenes (think of other mimetype-icons which are parts 
of other iconthemes and not seperated into paper and mimetype).

Another item is of course that we have to stay compatible in terms of 
icon-names and paths during the KDE 3.x-series so I fail to see how 
introducing such a new concept before KDE 4.0 in a clean manner is feasible 
at all.

Tackat




> luci

_______________________________________________
kde-artists mailing list
kde-artists@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]