kdenetwork/kit/icons

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday November 01, 2002 02:02, Antonio Larrosa Jiménez wrote:
> El Viernes, 1 de Noviembre de 2002 02:49, Neil Stevens escribió:
> > 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.

So any users who have highcolor with KDE 3.0 will have kdeclassic when they 
load KDE 3.1?  This wasn't true when I tried just a few days ago.

> > 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.

Well, you seemed to have missed where this discussion started.  I've said 
I'm going to maintain the highcolor/kdeclassic icons.  Torsten Rahn made 
copies of every one of those highcolor icons, calling them crystal.  Then 
Stephan Binner sent a second copy of each of those icons to kdeartwork.

I'm saying that having these two copies is bad, and instead, I should just 
install one copy of the same icons to highcolor, where it will be 
accessable to all icon styles.

The question is, to copy, or not to copy.

> > 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.

Unless you tested it, how do you even know there is a 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.

But unless you've tested it, this is just speculation.

>
> > 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.

No, these people are trying to force upon me an unproven optimization of a 
few stat calls on app startup, over what I'm trying to do which has the 
same effect with less file duplication.

Nobody has yet volunteered to actually look after these icons.  So it's 
still me and my no art skills and limited acquision power, having to watch 
over two icons where, by your own vehement statements on your page, one 
would work exactly the same (minus the alleged speedup).

> 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?

I don't know, but does that make my responsibility for them any less?  And 
they are my responsibility, I take that seriously, regardless of where 
they are in cvs.

> 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.

A script can rename files.  Scripts are not maintenance.  Torsten has not 
done one thing for Kit art-wise.

> Also, this is the same situation than the lo->hi change, but you didn't
> say anything at that time.

No, it's not.  That didn't require two copies of the files in cvs.

Or are you implying that Kit will never have any crystal icons, just as it 
never got any icons that took advantage of the larger highcolor palette?

> > 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).

False.  Go check the commits by Stephan Binner.  He copied every single 
highcolor icon into kdeartwork.  Do you deny that?

> > 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.

So nobody's responsible for the icons of my app but me.  Exactly.  This 
comes down to maintainership.  People who aren't willing to take 
responsibility for these icons are trying to dictate where they get 
installed, despite the fact that only person in the whole billion people 
on earth willing to maintain them is trying to install them in a place 
that is technically correct in every way.

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

But I am right.  According to the cvs records, and your own page, keeping 
these icons in Kit and installing them to highcolor will work exactly the 
same (minus the alleged speedup) as the way you're saying (minus the 
proven duplication).

- -- 
Neil Stevens - neil at qualityassistant.com
"The nearest I can make it out, 'Love your Enemies' means, 'Hate your
Friends'." - Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9wmynf7mnligQOmERArI+AJ0QTTTsbf0Yet4ozh9EGX1k5VC+RwCfVGLQ
MKvbnZLHPvrnwPB8xrhxo84=
=DVBO
-----END PGP SIGNATURE-----