Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 10:00:53, Pierre Schmitz wrote: Am Freitag, 27. März 2009 09:26:02 schrieb Dirk Mueller: The significant change is that oxygen-icons was split out of kdebase-runtime and is a seperate tarball now. you have to make sure that you build and install that in addition. The kdebase-runtime packages still has the oxygen icons in kdebase/runtime/pics/oxygen/. This will result in a file conflict between oxygen-icons and kdebase-runtime. So, I made a diff (filenames only) between oxygen-icons and kdebase/runtime/pics/oxygen. While there a lot of new files in oxygen-icons (which is not a problem) there are also some missing or were renamed. For example system-restart.png is called system-reboot.png now. I attached the diff; the problematic lines are those with a leading +; those files are in kdebase-runtime but not in oxygen-icons. I don't know if those icons are used at all, but I think kdebase/runtime/pics/oxygen should be merged into oxygen-icons and the first should be removed then to remove any confusion or file conflicts. Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. Andreas -- Are you making all this up as you go along? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 11:07:50, Pierre Schmitz wrote: Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. And what is this about: /tags/KDE/4.2.2/oxygen-icons/ Somebody screwed up tagging as far as I can see, that module doesn't belong there if the original is in trunk/KDE/kdesupport (which it is). So either someone copies trunk/KDE/kdesupport/oxygen-icons to branches/kdesupport-for-4.2 and removes oxygen icons from kdebase and re-tags or kdebase ships with oxygen icons and that directory you mentioned gets removed. If this shouldn't be used with 4.2.2 it's fine, but all this is still confusing. Yeah, apparently someone did not know about the kdesupport-for-4.2 branch. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not meant to be used with KDE 4.2.2? Because it was in the tag I guess. Andreas -- You will gain money by a speculation or lottery. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 08:16:01, Helio Chissini de Castro wrote: On Sexta-feira 27 Março 2009, Pierre Schmitz wrote: Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. And what is this about: /tags/KDE/4.2.2/oxygen-icons/ If this shouldn't be used with 4.2.2 it's fine, but all this is still confusing. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not meant to be used with KDE 4.2.2? Pierre is right, kdebase-runtime tarball is wrong, icons still there. Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. Andreas -- You will hear good news from one you thought unfriendly to you. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On Sexta-feira 27 Março 2009, Pierre Schmitz wrote: Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. And what is this about: /tags/KDE/4.2.2/oxygen-icons/ If this shouldn't be used with 4.2.2 it's fine, but all this is still confusing. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not meant to be used with KDE 4.2.2? Pierre is right, kdebase-runtime tarball is wrong, icons still there. -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: 4.3 Schedule.
At Wednesday 25 March 2009 10:48, you wrote: On Sunday 25 January 2009, Tom Albers wrote: No reply from Dirk, Anyone an idea how we can move forward with the 4.3 schedule? Sounds like the release schedule on techbase is still not filled, and people are wondering about when is the feature freeze (and other details about the release, but I suspect the freeze is the one that matter now): http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule I'm quite done with this schedule/thread to be honest. Pre-announcement: someone else can do the next one. Since Dirk hasn't responded yet, I like to suggest to simply mark the 4.3 schedule as it is on techbase right now as final. We can revisit a change in the beta sequence for 4.4. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
Am Freitag, 27. März 2009 13:10:30 schrieb Andreas Pakulat: Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. The problem is that tags/KDE/4.2.2/oxygen-icons is copied from trunk and that is not compatible with KDE 4.2. Some icons are missing or are renamed. So, I see too solutions here: 1) move branches/KDE/4.2/kdebase/runtime/pics/oxygen to branches/kdesupport- for-4.2/oxygen-icons and create the tag in 4.2.2 fro mthat one 2) forget about a separate oxygen-icons package in KDE 4.2 and keep it in kdebase-runtime -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pie...@jabber.archlinux.de WWW http://www.archlinux.de ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: 4.3 Schedule.
On Friday 27 March 2009 13:30:26 Tom Albers wrote: At Wednesday 25 March 2009 10:48, you wrote: On Sunday 25 January 2009, Tom Albers wrote: http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule I'm quite done with this schedule/thread to be honest. Pre-announcement: someone else can do the next one. Since Dirk hasn't responded yet, I like to suggest to simply mark the 4.3 schedule as it is on techbase right now as final. We can revisit a change in the beta sequence for 4.4. Toma There is no 4.3 schedule on techbase, that's the problem! So nobody currently knows when is the freeze and so on. It should also indicate the ast date to put stuff in kdereview in my opinion. Anne-Marie ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: 4.3 Schedule.
At Friday 27 March 2009 14:36, you wrote: On Friday 27 March 2009 13:30:26 Tom Albers wrote: At Wednesday 25 March 2009 10:48, you wrote: On Sunday 25 January 2009, Tom Albers wrote: http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule I'm quite done with this schedule/thread to be honest. Pre-announcement: someone else can do the next one. Since Dirk hasn't responded yet, I like to suggest to simply mark the 4.3 schedule as it is on techbase right now as final. We can revisit a change in the beta sequence for 4.4. Toma There is no 4.3 schedule on techbase, that's the problem! So nobody currently knows when is the freeze and so on. It should also indicate the ast date to put stuff in kdereview in my opinion. Anne-Marie There is, just follow the link above and scroll down... Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: 4.3 Schedule.
On Friday 27 March 2009 13:40:18 Tom Albers wrote: There is, just follow the link above and scroll down... Best, Toma ooops, sorry, not really intuitive... Anne-Marie ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On Friday 27 of March 2009 09:33:07 Pierre Schmitz wrote: Am Freitag, 27. März 2009 13:10:30 schrieb Andreas Pakulat: Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. The problem is that tags/KDE/4.2.2/oxygen-icons is copied from trunk and that is not compatible with KDE 4.2. Some icons are missing or are renamed. So, I see too solutions here: 1) move branches/KDE/4.2/kdebase/runtime/pics/oxygen to branches/kdesupport- for-4.2/oxygen-icons and create the tag in 4.2.2 fro mthat one 2) forget about a separate oxygen-icons package in KDE 4.2 and keep it in kdebase-runtime Independent or move/copy, etc.. i decided go in this way here: Package oxygen tarball Remove oxygen from kdebase-runtime package. If there is some missing icons on oxygen tarball, it's time to throw up on oxygen team to solve the mess. They discussed everything in the internal list and just communicate us when the mess are done. Many of the issues would not exists if they communicate with packagers and dirk *before* take the decision. Now, i expect that they figure out a better way to solve. But i think back to a big kdebase-runtime package now is out of question for me. -- Helio Chissini de Castro KDE Developer Brasil/South America Primary Contact ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
At Friday 27 March 2009 14:02, you wrote: Many of the issues would not exists if they communicate with packagers and dirk *before* take the decision. Actually, they did. See the archives of the r-t list. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 12:20:38, Jonathan Riddell wrote: On Fri, Mar 27, 2009 at 01:10:30PM +0100, Andreas Pakulat wrote: Pierre is right, kdebase-runtime tarball is wrong, icons still there. Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. This is a bugfix release, there should not be any new tarballs or moving around or sources. +1 on that fact. Andreas -- Today is the tomorrow you worried about yesterday. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 14:07:16, Tom Albers wrote: At Friday 27 March 2009 14:02, you wrote: Many of the issues would not exists if they communicate with packagers and dirk *before* take the decision. Actually, they did. See the archives of the r-t list. But nobody told Dirk where to get the icons for KDE 4.2.2, so the option he was left with was copying from trunk, which apparently doesn't work with kdebase-runtime 4.2.2. So someone needs to step up and fix this mess and IMHO the right way to do that is have the icons in kdebase for the lifetime of KDE 4.2 as that doesn't break anything. Andreas -- Your object is to save the world, while still leading a pleasant life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
Am Freitag, 27. März 2009 14:17:45 schrieb Andreas Pakulat: So someone needs to step up and fix this mess and IMHO the right way to do that is have the icons in kdebase for the lifetime of KDE 4.2 as that doesn't break anything. Sounds like the best and easiest solution to me. So, no unexpected changes in a bugfix release and noone gets hurt. Imho its not worth the effort to split out the oxygen-icons within the 4.2 branch. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pie...@jabber.archlinux.de WWW http://www.archlinux.de ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? It's icons, we shouldn't have any regressions, and we have decided to split the release exactly to provide the most fresh icons possible. But then, I'm not sure if we want to break packaging scripts in a minor release. Bye, -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 27.03.09 10:05:11, Riccardo Iaconelli wrote: On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? Because you're sometimes changing names of icons and that breaks existing code - unless you backport the code-changes before the release. Andreas -- Try to get all of your posthumous medals in advance. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On Friday 27 March 2009 10:05:11 Riccardo Iaconelli wrote: On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? It's icons, we shouldn't have any regressions, and we have decided to split the release exactly to provide the most fresh icons possible. But then, I'm not sure if we want to break packaging scripts in a minor release. I think removing the icons from branch and shipping them from kdesupport is a bad idea. With this kind of structural changes to a stable branch, we're making it harder for packagers to ship our updates and bugfixes, they're now either stuck with putting the icons back into the old location and ship this, or offer the icons as separate package, which creates more work for these poor people. Shipping Oxygen separately might be interesting for third party applications to use the icons, the names are standardized and they don't depend on neither KDE nor Qt (in fact they depend on being rendered with Inkscape ;)). We need to consider that Oxygen is part of a stable platform. Even if we fix the apps that we ship together with Oxygen, that still means that we might screw some third party apps that suddenly loose icons in a x.y.z bugfix and translation update. It's fine to update the Oxygen icons also in a stable cycle, the large majority of the updates to Oxygen is probably a 100% safe to backport. For trunk, we can make these changes, but we need to consider the above points just as well. Backwards compatibility is just as important across major cycles (4.2 - 4.3) releases. I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. -- 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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: On Friday 27 March 2009 10:05:11 Riccardo Iaconelli wrote: On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? It's icons, we shouldn't have any regressions, and we have decided to split the release exactly to provide the most fresh icons possible. But then, I'm not sure if we want to break packaging scripts in a minor release. I think removing the icons from branch and shipping them from kdesupport is a bad idea. With this kind of structural changes to a stable branch, we're making it harder for packagers to ship our updates and bugfixes, they're now either stuck with putting the icons back into the old location and ship this, or offer the icons as separate package, which creates more work for these poor people. Shipping Oxygen separately might be interesting for third party applications to use the icons, the names are standardized and they don't depend on neither KDE nor Qt (in fact they depend on being rendered with Inkscape ;)). We need to consider that Oxygen is part of a stable platform. Even if we fix the apps that we ship together with Oxygen, that still means that we might screw some third party apps that suddenly loose icons in a x.y.z bugfix and translation update. It's fine to update the Oxygen icons also in a stable cycle, the large majority of the updates to Oxygen is probably a 100% safe to backport. For trunk, we can make these changes, but we need to consider the above points just as well. Backwards compatibility is just as important across major cycles (4.2 - 4.3) releases. I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. 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. 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. this is a solution to that issue, no one came up with a beter one.. -- Oxygen coordinator ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. I guess it's not the case here, as distributions usually follow weekly unstable snapshots as well, so it's very unlikely they will miss Oxygen icons release. On Saturday 28 of 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. 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. Exactly, that's actually the reason, why in Gentoo, we get some number of duplicated icons causing file collisions that need to be handled. Of course, usually after some time, they are eventually removed from those packages. Some applications still ship some icons on their own (I could give some examples, like digikam, and used to - koffice). The possible reasons are: - some application developers don't know whether some icon is shipped already with KDE4 - some application developers don't want to assume that KDE4 shipping those newly added application icons is installed on user machine, so just in any case they ship icons themselves. The idea, of frequent updates to Oxygen icons in kdesupport (and frequent releases) - will work and will give this control over icon distribution - provided backward compatibility issues with 4.2.x and 4.3.x regarding icons are resolved, and provided 3rd party (extragear/plasma and other as well) KDE application developers will respect that way of distributing them. (in short, any icon missing or report about icon being duplicated - contact Oxygen team - icon set updated and released in weekly manner as usual or sth like this - so that in effect every Oxygen icon create is in kdesupport/oxygen-icons) -- regards MM signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. And KDE packagers could use the same weekly manner of automatic packaging oxygen icons along with unstable (SVN) snapshots (so called 4.2.67 etc) -- regards MM signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Saturday 28 March 2009 00:55:32, Sebastian Kügler escreveu: 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... yeap 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? the idea was to put every single icon there 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. yeap in the end it will be quite a large group it allready is and im gessing about arround 100 are outside already, 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. Realy im fine with anything as long as it works, by working i meen having some way of geting a complete overview of the intire icon set, with i dont right now, and nor do developers, a developer serching for an specific icon for his app as no place to go and look for all of them unless he instales every single app out there that ships oxygen icons, and heven if he does he cant be sure its realy an oxygen icon or a icon some application developer found some ware and put it in his install oxygen directory... I have no perfect anser for this but I can complain about it I have spoken about this to the other icon designers we all agrea that a centralized place for all icons is beter... -- Oxygen coordinator ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:47:23, Maciej Mrozowski wrote: A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: Some applications still ship some icons on their own (I could give some examples, like digikam, and used to - koffice). The possible reasons are: - some application developers don't know whether some icon is shipped already with KDE4 Then they should start to look at the icons in kdebase/runtime (or now oxygen-icons in kdesupport). An app developer should at least coordinate these things somewhat with the artists, unless they want to ship their own iconset. - some application developers don't want to assume that KDE4 shipping those newly added application icons is installed on user machine, so just in any case they ship icons themselves. Thats a moot point, any KDE app has kdebase/runtime as runtime dependency so oxygen icons are _always_ there. Andreas -- You may worry about your hair-do today, but tomorrow much peanut butter will be sold. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On Saturday 28 March 2009 02:26:26 Nuno Pinheiro wrote: A Saturday 28 March 2009 00:55:32, Sebastian Kügler escreveu: the idea was to put every single icon there 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. yeap in the end it will be quite a large group it allready is and im gessing about arround 100 are outside already, 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. Realy im fine with anything as long as it works, by working i meen having some way of geting a complete overview of the intire icon set, with i dont right now, and nor do developers, a developer serching for an specific icon for his app as no place to go and look for all of them unless he instales every single app out there that ships oxygen icons, and heven if he does he cant be sure its realy an oxygen icon or a icon some application developer found some ware and put it in his install oxygen directory... That makes sense. So for the future, we'll ship Oxygen separately. That shaves of quite some MBs from the kdebase tarball (you mentioned 20K files), makes it easier to maintain for you and keep in a sane state for others to work with. How should those releases be shipped? Is it simply OK to grab a snapshot from kdesupport anytime? Otherwise, tags would need to be created for the snapshot release revisions. I have no perfect anser for this but I can complain about it I have spoken about this to the other icon designers we all agrea that a centralized place for all icons is beter... Then the solution to this is to do with KDE 4.2.2 whatever Dirk thinks it's sensible (I can imagine that it's really way to late to change this for 4.2.2.) For trunk we'll keep the separate Oxygen in kdesupport anyway. -- 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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:55:32, Sebastian Kügler wrote: 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. Another reason to ship icons with an application is that there's only a limited amount of artists available and they have only limited time. In KDevelop we have currently two icons copied from an oxygen icon (and one coming from KDE3) that we ship, simply because the artists didn't yet get around to work on the list of icons posted in the wiki for KDevelop. I'm trying to keep such things out of kdevelop and thats why there are no icons in the menus for some of the most-used actions, but in some cases having text is simply not an option (toolbars in dockwidgets for example). Am I assuming correctly that the only regressions caused by icons is when an icon gets a different name and needs to be moved? Yes in that case we'd either need a copy of the old name still around or make sure all apps using the icon are updated. 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? Yeah, I think the problem is rather that a) app devs don't know that kdebase/runtime is a dependency for _every_ kde app and they might also not know they should pick icons from there or request them from the oxygen tema b) what I said above about limited resources for creating icons 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. I don't really see how shipping a huge tarball that all kde apps depend on outside of kdebase is better than shipping it inside. But I don't have a good idea how to fix the size of the oxygen dir (in terms of files) without starting to scatter around app-specific icons to the applications - which might again lead to duplication and confusion as Nuno pointed out. Andreas -- You're ugly and your mother dresses you funny. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:26:26, Nuno Pinheiro wrote: A Saturday 28 March 2009 00:55:32, Sebastian Kügler escreveu: 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. Realy im fine with anything as long as it works, by working i meen having some way of geting a complete overview of the intire icon set, with i dont right now, and nor do developers, I can only speak for myself, but I as a developer always use kdebase/runtime/oxygen to get an overview over icons that I should use and to find one when I have a certain action. a developer serching for an specific icon for his app as no place to go and look for all of them unless he instales every single app out there that ships oxygen icons, and heven if he does he cant be sure its realy an oxygen icon or a icon some application developer found some ware and put it in his install oxygen directory... Hmm, I'm not a guru in the icon-spec, but shouldn't apps install their custom icons not into the oxygen directory but rather into the fallback hicolor or what it is called? At least thats what KDevelop does with the three custom icons it has and that gives other developers a clear hint that these icons are not part of the oxygen iconset. (I just see that we're creating quite some mess actually in kdevelop/pics, I'll try to fix that tomorrow). I have no perfect anser for this but I can complain about it I have spoken about this to the other icon designers we all agrea that a centralized place for all icons is beter... I don't see why that centralized place cannot be kdebase/runtime as that is already a hard runtime requirement for all kde apps. I do understand that you could more easily produce releases yourself from a kdesupport/oxygen-icons module, so I'm not saying you should go back to kdebase/runtime if the separate releases are an important factor. Apart from that I mostly see education problems and the problem of people copying existing apps to start their own (and existing apps doing it wrong). And you can't fix those problems with throwing software or hardware at them, btw. anybody knows what the tutorials on techbase tell people about icons? Andreas -- Beauty and harmony are as necessary to you as the very breath of life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
