kdenetwork/kit/icons

[Antonio Larrosa Jiménez]

El Viernes, 1 de Noviembre de 2002 02:49, Neil Stevens escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday October 31, 2002 05:22, Antonio Larrosa Jiménez wrote:
> > El Viernes, 1 de Noviembre de 2002 00:48, David Faure escribió:
> > > Your suggestion is finally out loud clear on this list, now the ball
> > > is in the hand of Antonio and Torsten.
> >
> > First, I'm glad that Neil finally said clearly his arguments.
> >
> > Second, I've written a document where I try to explain everything at
> >
> > http://devel-home.kde.org/~larrosa/iconthemes.html
>
> 1.  You say that there are no users of highcolor anymore.  That's not
> true. Currently there are many users of highcolor.  And when they
> upgrade to KDE 3.1, they can reasonably expect that they will still be
> using highcolor, as they will compare the 3.0->3.1 transition with
> 2.0->2.1->2.2.  You may have renamed highcolor, but it's still the same
> set of icons under a different name.
>
> Do you need someone to write a kconf_update script to handle this?
>

No, it's already handled in the icon loader. Wether the user tries to use 
hicolor, it's changed with the default icon theme.

> 2. Your page doesn't address an important issue:  Many apps do not have
> any crystal icons.  Again, more slowly:  Many apps (like Kit) do not
> have crystal icons.  And Kit won't have any crystal icons inf the
> foreseeable future, as nobody has volunteered to make any.
>
> Under your scheme, we have to have *duplicate* icons in cvs for Kit and

nobody said anything about duplicating icons, and that's nonsense.
IF your crystal icons are the same as your kdeclassic ones, why would you 
want to install both? install the crystal ones and they'll also be used 
when the user selects kdeclassic.

> eveyr app like it:  A falsely-labelled crystal, and a truly installed
> kdeclassic.  And what's the reason you give?  A tiny speedup.

Any speedup is a good speedup.

>
> a.  Have you benchmarked this speedup?  How does the magnitude of the
> speedup compare with the random noise of repeated testing?
>

It has nothing to do with random noise, either you find an icon in the 
first icon theme you look into (which will never be hicolor) or you find 
it in the second one (or third, or fourth...). Noticing that each lookup 
in an icon theme involves several stats to see if a file exists in several 
directories, there's nothing to benchmark, the fastest we find icons, the 
better.

> b.  This situation is analgous to manually inlining a function from
> kdelibs every time it used:  It places a burden on the maintainer, it
> increases the disk usage, and it's probably a bad idea.  Isn't the time
> of maintainers like Kit's more valuable fixing a bug or adding a
> feature, than having to watch over two duplicates of every icon in the
> app?

Neil, you know that when you put your app in KDE's cvs you are also saying 
"hey, I'll mantain this app with the rest of the KDE people". The fact 
that many people tried to fix this situation by moving those hi* icons to 
another place and keep the cr* icons without you having to do anything 
means basically that there are other people helping you to mantain your 
application.

You're basically saying that you're going to have a lot of work if we move 
"your" icons as we've done for the rest of icons in cvs because "you" will 
have to mantain icons in two different directories, but just have a look 
at history, when was the last time you had to do something about those 
icons?

Since 15 Oct 2000 (which was the first cvs commit I could find) only tackat 
has commited anything to those files and I couldn't find a _single_ time 
where you (or anyone else) commited anything related to them (except this 
nonsense, reverting the changes of others). In fact, in May 2001, tackat 
renamed them to be hi* (as they were installed to the locolor icon theme 
before and that theme was no longer installed by default). Given that, I'd 
say that those icons are mantained by tackat more than you (even if 
they're your app icons) so please, let the mantainer decide and mantain 
it.
Also, this is the same situation than the lo->hi change, but you didn't say 
anything at that time.

> If we'd just treat all KDE apps the same, both in an out of cvs, this
> duplication and inconvenience is avoided.
>

There's no duplication and there's no inconvenence (expect having to argue 
until death what everyone else thinks it's ok).

> 3.  Who is maintaining kdeclassic?
>

Neil, let's put it clear, you don't want kdeclassic (the old hicolor theme) 
to disappear. And it hasn't disappeared, it only has changed its state 
from "actively mantained" to simply "mantained". I don't think tackat 
alone can paint and keep up to date two icon themes, so if you're not 
helping painting icons, there's nothing you (or I) can do about it, except 
making tackat's life easier and not annoy him too much so that he has more 
free time to paint icons.

To quote myself: "when you're right, you're right, and when you're not..."
well, you're not.

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
Mejor leer algo en inglés que una adivinanza en español.