From kde-core-devel Fri Nov 01 10:02:13 2002 From: Antonio Larrosa =?iso-8859-1?q?Jim=E9nez?= Date: Fri, 01 Nov 2002 10:02:13 +0000 To: kde-core-devel Subject: Re: kdenetwork/kit/icons X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103614505120718 El Viernes, 1 de Noviembre de 2002 02:49, Neil Stevens escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday October 31, 2002 05:22, Antonio Larrosa Jim=E9nez wrote: > > El Viernes, 1 de Noviembre de 2002 00:48, David Faure escribi=F3: > > > 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=20 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=20 want to install both? install the crystal ones and they'll also be used=20 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=20 first icon theme you look into (which will never be hicolor) or you find=20 it in the second one (or third, or fourth...). Noticing that each lookup=20 in an icon theme involves several stats to see if a file exists in several= =20 directories, there's nothing to benchmark, the fastest we find icons, the=20 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= =20 "hey, I'll mantain this app with the rest of the KDE people". The fact=20 that many people tried to fix this situation by moving those hi* icons to=20 another place and keep the cr* icons without you having to do anything=20 means basically that there are other people helping you to mantain your=20 application. You're basically saying that you're going to have a lot of work if we move= =20 "your" icons as we've done for the rest of icons in cvs because "you" will= =20 have to mantain icons in two different directories, but just have a look=20 at history, when was the last time you had to do something about those=20 icons? Since 15 Oct 2000 (which was the first cvs commit I could find) only tackat= =20 has commited anything to those files and I couldn't find a _single_ time=20 where you (or anyone else) commited anything related to them (except this=20 nonsense, reverting the changes of others). In fact, in May 2001, tackat=20 renamed them to be hi* (as they were installed to the locolor icon theme=20 before and that theme was no longer installed by default). Given that, I'd= =20 say that those icons are mantained by tackat more than you (even if=20 they're your app icons) so please, let the mantainer decide and mantain=20 it. Also, this is the same situation than the lo->hi change, but you didn't say= =20 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= =20 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)= =20 to disappear. And it hasn't disappeared, it only has changed its state=20 from "actively mantained" to simply "mantained". I don't think tackat=20 alone can paint and keep up to date two icon themes, so if you're not=20 helping painting icons, there's nothing you (or I) can do about it, except= =20 making tackat's life easier and not annoy him too much so that he has more= =20 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, =2D- Antonio Larrosa Jimenez KDE core developer - larrosa@kde.org http://devel-home.kde.org/~larrosa/ Mejor leer algo en ingl=E9s que una adivinanza en espa=F1ol.