On Saturday 28 March 2009 01:27:58 Nuno Pinheiro wrote: > Well my issue is another as nothing to do with the issues so far. > > its about control, we are creating a new kde3.x mess couse aplications are > creating their hown versions of the same icons, and not teling any one they > do so, couse well they dont have 2.
I see. I don't see another solution than to make it easy to ship all icons from one canonical source. Maybe we should have a mechanism to download missing icons automatically, so Oxygen is shipped as webservice. Or at least educating application developers better. Realistically, there will always be the problem of people not passing their modifications up, it's just too easy to change the name and ship it, while passing it back upstream is hard. This doesn't mean that what Oxygen ships should be clean. Am I assuming correctly that the only regressions caused by icons is when an icon gets a different name and needs to be moved? > second i have alrady done a couple of duplicated icons with slightly > difrent names couse well i forgot i did icon a for app B and icon c for app > D and a=c just that they dont. > i have no idea of how many icons we have done so far no idea of what apps > are using couse its out of the oxygen directory its scatered all around kde > svn. That sucks :/. So to you as icon developer, there should be One Canonical Place To Put All Icons... > this is a solution to that issue, no one came up with a beter one.. Let's try to find a better one then :) I don't see in how far putting icons into kdesupport would solve that problem? Or is the problem the size of Oxygen? I can imagine that you don't want to ship every single special application icon in the world in the kdebase tarball. In that case, it would make sense to ship it separately. This change (which is the point of this discussion) is made already. Still, that's not something we should change in a bug fix update as Andreas pointed out as well. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
