-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
With the latest version of l-b-g, the "time of day" backgrounds were added to the -gnome subpackage. This ballooned the package by 20+megs and has caused some of the live images to overflow. Previously none of the actual background files were in -gnome and I'm curious why the change was made at this point, particularly when in previous releases there were no images in the -gnome subpackage.
Care to shed some light?
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Fri, 2010-10-15 at 17:16 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
With the latest version of l-b-g, the "time of day" backgrounds were added to the -gnome subpackage. This ballooned the package by 20+megs and has caused some of the live images to overflow. Previously none of the actual background files were in -gnome and I'm curious why the change was made at this point, particularly when in previous releases there were no images in the -gnome subpackage.
The reason why they're in -gnome subpackage is simple: this kind of thing is supported in gnome only. The reason why this late is also simple -- we (design-team) agreed on our regular IRC meeting that we want to make the default wallpaper with time-of-day animation again and this kind of improvement is always done last in wallpaper design. IIRC last time we did time-of-day animation was Fedora 9 so you can imagine why for the past few releases -gnome subpackage was image-empty.
I apologize for the inconvenience -- I should have probably notified the desktop folks ahead that it was highly probable that l-b-g-gnome would increase in size rather drastically (I myself had the info week ahead of the packaging)...
Regards, Martin
On Sat, Oct 16, 2010 at 10:07:24 +0200, Martin Sourada martin.sourada@gmail.com wrote:
I apologize for the inconvenience -- I should have probably notified the desktop folks ahead that it was highly probable that l-b-g-gnome would increase in size rather drastically (I myself had the info week ahead of the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that they aren't going to make their target size without changes.) We either need a way to only get some of that stuff, or some way to not use that package for at least a few spins. We only have a few days to react to this. The two spins that went over size are probably going to have a problem with removing other software and we will probably want to look at some way to use a simpler backgrounds package. If you guys have some ideas in that direction it would help.
I looked and the key provides seems to be system-backgrounds-gnome. That is provided only by laughlin-backgrounds-gnome and is required by gnome-desktop and gnome-desktop3. I didn't check for file dependencies, so I am not sure if XFCE pulls this in via a file dependency or not.
But it does look like we need a package change to deal with this. One option would be to have laughlin-backgrounds-single provide system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then specifically include laughlin-backgrounds-gnome in the ks files for the spins that want the full list of backgrounds.
I'd be willing to adjust the spin kickstart files, but I am not a proven packager so I can't touch that laughlin-backgrounds packages. We'll also need to round up some proven testers as these are critical path packages.
I have about 2.5 hours now I can be free to do stuff, otherwise it will be late tonight (in about 14 hours) or tomorrow that I can work on this.
Another option would be to revert the update. That doesn't seem ideal, but might be less work.
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
I didn't check for file dependencies, so I am not sure if XFCE pulls this in via a file dependency or not.
Unless I screwed up how I checked this, there don't appear to be any direct file dependencies on files in laughlin-backgrounds-gnome.
On Sat, 2010-10-16 at 10:24 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
I didn't check for file dependencies, so I am not sure if XFCE pulls this in via a file dependency or not.
Unless I screwed up how I checked this, there don't appear to be any direct file dependencies on files in laughlin-backgrounds-gnome.
There shouldn't be, it's handled directly via package/virtual provides (there is usually more than 1 file require so it would quickly get messy). With that said, the default wallpaper selection could be handled probably more cleanly, I have some ideas which I'd like to try for F15, but they wouldn't prevent this case from happening as we never know sufficiently far ahead whether we'll do time-of-day wallpaper and it always appear no sooner than the final version of wallpaper...
Martin
On Sat, Oct 16, 2010 at 17:36:53 +0200, Martin Sourada martin.sourada@gmail.com wrote:
There shouldn't be, it's handled directly via package/virtual provides (there is usually more than 1 file require so it would quickly get messy). With that said, the default wallpaper selection could be handled probably more cleanly, I have some ideas which I'd like to try for F15, but they wouldn't prevent this case from happening as we never know sufficiently far ahead whether we'll do time-of-day wallpaper and it always appear no sooner than the final version of wallpaper...
As long as there is a way for ks files to get just the simpler wallpaper the ones that are tight on space can be set to use the simpler one and last minute changes in the package shouldn't be that big of a deal. (But if there is a large change in size, it would still be best to get it in a little bit earlier.)
We still need a plan to deal with the immediate problem. You mentioned some areas I wasn't aware of when I made my previous proposal. Can you combine what you described above with what I mentioned so far and propose a way forward that we can implement this weekend?
On Sat, 2010-10-16 at 11:02 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:36:53 +0200, Martin Sourada martin.sourada@gmail.com wrote:
There shouldn't be, it's handled directly via package/virtual provides (there is usually more than 1 file require so it would quickly get messy). With that said, the default wallpaper selection could be handled probably more cleanly, I have some ideas which I'd like to try for F15, but they wouldn't prevent this case from happening as we never know sufficiently far ahead whether we'll do time-of-day wallpaper and it always appear no sooner than the final version of wallpaper...
As long as there is a way for ks files to get just the simpler wallpaper the ones that are tight on space can be set to use the simpler one and last minute changes in the package shouldn't be that big of a deal. (But if there is a large change in size, it would still be best to get it in a little bit earlier.)
We still need a plan to deal with the immediate problem. You mentioned some areas I wasn't aware of when I made my previous proposal. Can you combine what you described above with what I mentioned so far and propose a way forward that we can implement this weekend?
For the immediate problem -- I'm not sure what is better packaging-wise, but I could do one of the following * move -gnome into -gnome-tod (with the virtual provides and perhaps obsolete -gnome < 14.1.0), create the needed xmls and put them into -gnome * create the needed xmls and put them into -gnome-simple (less work)
In order to help you solve your problem the best would be to create these two sub-packages in a way that the xmls would be the same and thus in direct conflict. I'm not sure how to properly handle the defaults yet. Perhaps adding the virtual provide to the -simple one as well, but the we'd have to make sure to correct package is pulled in...
Any better ideas?
Martin
On Sat, Oct 16, 2010 at 18:32:36 +0200, Martin Sourada martin.sourada@gmail.com wrote:
For the immediate problem -- I'm not sure what is better packaging-wise, but I could do one of the following * move -gnome into -gnome-tod (with the virtual provides and perhaps obsolete -gnome < 14.1.0), create the needed xmls and put them into -gnome * create the needed xmls and put them into -gnome-simple (less work)
I don't think you need to make a laughlin-backgrounds-gnome-tod. We should be able to properly spil stuff between laughlin-backgrounds-gnome and laughlin-backgrounds-single as long as we can get a single xml file to work for both cases.
In order to help you solve your problem the best would be to create these two sub-packages in a way that the xmls would be the same and thus in direct conflict. I'm not sure how to properly handle the defaults yet. Perhaps adding the virtual provide to the -simple one as well, but the we'd have to make sure to correct package is pulled in...
I'd rather not see a conflicts. That is going to cause problems.
Any better ideas?
Is there someplace that describes the details of that xml file? I am trying to search through the gnome documentation but haven't found the reference for that file yet.
On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 18:32:36 +0200, Martin Sourada martin.sourada@gmail.com wrote:
For the immediate problem -- I'm not sure what is better packaging-wise, but I could do one of the following * move -gnome into -gnome-tod (with the virtual provides and perhaps obsolete -gnome < 14.1.0), create the needed xmls and put them into -gnome * create the needed xmls and put them into -gnome-simple (less work)
I don't think you need to make a laughlin-backgrounds-gnome-tod. We should be able to properly spil stuff between laughlin-backgrounds-gnome and laughlin-backgrounds-single as long as we can get a single xml file to work for both cases.
In order to help you solve your problem the best would be to create these two sub-packages in a way that the xmls would be the same and thus in direct conflict. I'm not sure how to properly handle the defaults yet. Perhaps adding the virtual provide to the -simple one as well, but the we'd have to make sure to correct package is pulled in...
I'd rather not see a conflicts. That is going to cause problems.
Any better ideas?
Is there someplace that describes the details of that xml file? I am trying to search through the gnome documentation but haven't found the reference for that file yet.
I have no idea :( These things are really badly documented... Most you can get is inspecting the code directly...
Martin
On Sat, Oct 16, 2010 at 19:17:54 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
Is there someplace that describes the details of that xml file? I am trying to search through the gnome documentation but haven't found the reference for that file yet.
I have no idea :( These things are really badly documented... Most you can get is inspecting the code directly...
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would help to know where to start looking.
On Sat, 2010-10-16 at 12:40 -0500, Bruno Wolff III wrote:
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would help to know where to start looking.
Cannot say for sure, but this would probably be a good start http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-bg.c
Martin
On Sat, 2010-10-16 at 12:40 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 19:17:54 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 11:52 -0500, Bruno Wolff III wrote:
Is there someplace that describes the details of that xml file? I am trying to search through the gnome documentation but haven't found the reference for that file yet.
I have no idea :( These things are really badly documented... Most you can get is inspecting the code directly...
Any pointers to where in the code I should be looking?
I am about out of time now, but can probably look at it tonight. It would help to know where to start looking.
What are you trying to find out about what xml file ?
On Sat, Oct 16, 2010 at 18:12:06 -0400, Matthias Clasen mclasen@redhat.com wrote:
What are you trying to find out about what xml file ?
The file that defines background theme information. In this particular case: /usr/share/backgrounds/laughlin/default/laughlin.xml
What I was hoping to find out is if you could specify fallback images if the first choice image files don't exist. The idea was to make a single config file that would both with and without having laughlin-backgrounds-gnome installed and get the time of day stuff if it is installed.
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
But it does look like we need a package change to deal with this. One option would be to have laughlin-backgrounds-single provide system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then specifically include laughlin-backgrounds-gnome in the ks files for the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the desktop-gnome comps group as a default package, so that people get the full set of backgrounds by default when installing.
On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
But it does look like we need a package change to deal with this. One option would be to have laughlin-backgrounds-single provide system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then specifically include laughlin-backgrounds-gnome in the ks files for the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the desktop-gnome comps group as a default package, so that people get the full set of backgrounds by default when installing.
I believe they get it as it's required by gnome-desktop(3). Try yum-removing it ;-)
Martin
On Sat, Oct 16, 2010 at 17:58:22 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
But it does look like we need a package change to deal with this. One option would be to have laughlin-backgrounds-single provide system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then specifically include laughlin-backgrounds-gnome in the ks files for the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the desktop-gnome comps group as a default package, so that people get the full set of backgrounds by default when installing.
I believe they get it as it's required by gnome-desktop(3). Try yum-removing it ;-)
Part of my proposal was changing that. If we do that, then I think we need it in comps.
The xml file is an issue though. Is there a way to do conditional code in that file? Otherwise it looks like having a different default depending on whether or not laughlin-backgrounds-gnome installed is going to be difficult.
On Sat, 2010-10-16 at 11:27 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:58:22 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 10:42 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:04:59 -0500, Bruno Wolff III bruno@wolff.to wrote:
But it does look like we need a package change to deal with this. One option would be to have laughlin-backgrounds-single provide system-backgrounds-gnome instead of laughlin-backgrounds-gnome and then specifically include laughlin-backgrounds-gnome in the ks files for the spins that want the full list of backgrounds.
I think we might also want to add laughlin-backgrounds-gnome to the desktop-gnome comps group as a default package, so that people get the full set of backgrounds by default when installing.
I believe they get it as it's required by gnome-desktop(3). Try yum-removing it ;-)
Part of my proposal was changing that. If we do that, then I think we need it in comps.
The xml file is an issue though. Is there a way to do conditional code in that file? Otherwise it looks like having a different default depending on whether or not laughlin-backgrounds-gnome installed is going to be difficult.
The important xml for it to appear in backgrounds-chooser is this one: /usr/share/gnome-background-properties/desktop-backgrounds-laughlin.xml the xml that is selected as default background is this: /usr/share/backgrounds/laughlin/default/laughlin.xml
The gnome-desktop(3) requires is because it explicitly selects the background (in gconf schema file) to be /usr/share/backgrounds/laughlin/default/laughlin.xml
I'm really not sure how to handle here two different defaults...
How it's done in spins with different default wallpaper (I believe the education or security have one)?
Martin
On Sat, Oct 16, 2010 at 18:49:12 +0200, Martin Sourada martin.sourada@gmail.com wrote:
The important xml for it to appear in backgrounds-chooser is this one: /usr/share/gnome-background-properties/desktop-backgrounds-laughlin.xml the xml that is selected as default background is this: /usr/share/backgrounds/laughlin/default/laughlin.xml
The gnome-desktop(3) requires is because it explicitly selects the background (in gconf schema file) to be /usr/share/backgrounds/laughlin/default/laughlin.xml
I'm really not sure how to handle here two different defaults...
I don't think there is a good way to have two defaults. I am hoping there is a way to have one default that falls back to using different images if the primary ones aren't available. The idea would be to use the time of day background with the fallbacks all being the images in the -single package (so the appearance would be constant, but the same xml file could be used). I doubt that feature is there, but I am trying to find more information.
How it's done in spins with different default wallpaper (I believe the education or security have one)?
There are ways to run scripts as part of the builds. I don't exactly how they implemented that though. However, different isn't enough. The package needs to be removalable. And given that it is removable, it needs to work sanely outside of the spins.
On Sat, 2010-10-16 at 08:20 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 10:07:24 +0200, Martin Sourada martin.sourada@gmail.com wrote:
I apologize for the inconvenience -- I should have probably notified the desktop folks ahead that it was highly probable that l-b-g-gnome would increase in size rather drastically (I myself had the info week ahead of the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that they aren't going to make their target size without changes.) We either need a way to only get some of that stuff, or some way to not use that package for at least a few spins. We only have a few days to react to this. The two spins that went over size are probably going to have a problem with removing other software and we will probably want to look at some way to use a simpler backgrounds package. If you guys have some ideas in that direction it would help.
It would help to list which spins went oversize and what's their target size. So general info:
For gnome we need a xml file which actually adds the wallpaper into wallpaper chooser. The one in current package points to xml which describes the time-of-day wallpaper version. If you'd need gnome desktop without time-of-day wallpaper you'd need to add two new xmls (one which would describe which images are used at which sizes and another one which would add it to background chooser). In theory, we could split the -gnome subpackage into -gnome and -gnome-tod which however isn't what we (design team) want as we want the time-of-day wallpaper used by default on Desktop spin. It's set not in kickstart, but in gnome-desktop(3), hence the requires.
For KDE we need the wallpaper description via .desktop file (in -kde sub-package). AFAIK, KDE does not have support for time-of-day animation so it does not pull in everything.
For LXDE and XFCE neither -gnome nor -kde sub-packages should be pulled in and if they are, then it's wrong.
Regards, Martin
On Sat, Oct 16, 2010 at 17:26:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
It would help to list which spins went oversize and what's their target size. So general info:
broffice and xfce are the two that went over their targets. They need to get back under 703 MiB. Games was almost hit, but still has enough cushion that I can handle the hedgewars small increase in size which will be showing up in a push tomorrow unless it gets negative karma before then. But I'm still pretty close and will probably still implement whatever we do for broffice and xfce.
For gnome we need a xml file which actually adds the wallpaper into wallpaper chooser. The one in current package points to xml which describes the time-of-day wallpaper version. If you'd need gnome desktop without time-of-day wallpaper you'd need to add two new xmls (one which would describe which images are used at which sizes and another one which would add it to background chooser). In theory, we could split the -gnome subpackage into -gnome and -gnome-tod which however isn't what we (design team) want as we want the time-of-day wallpaper used by default on Desktop spin. It's set not in kickstart, but in gnome-desktop(3), hence the requires.
Can you make some proposal here that we can relatively safely mplement this weekend?
For KDE we need the wallpaper description via .desktop file (in -kde sub-package). AFAIK, KDE does not have support for time-of-day animation so it does not pull in everything.
Were probably OK on KDE as it is about 15 MiB under the limit right now. I'd rather not make changes there right now if we don't have to. But there probably should be a plan to allow for a simpler background on KDE based spins for the future.
For LXDE and XFCE neither -gnome nor -kde sub-packages should be pulled in and if they are, then it's wrong.
Any ideas on how this is happening?
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:26:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
It would help to list which spins went oversize and what's their target size. So general info:
broffice and xfce are the two that went over their targets. They need to get back under 703 MiB. Games was almost hit, but still has enough cushion that I can handle the hedgewars small increase in size which will be showing up in a push tomorrow unless it gets negative karma before then. But I'm still pretty close and will probably still implement whatever we do for broffice and xfce.
AFAIK XFCE should require only -single, unless they pull gnome-desktop(3) for some reason. That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
Martin
On Sat, Oct 16, 2010 at 18:42:10 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:26:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
It would help to list which spins went oversize and what's their target size. So general info:
broffice and xfce are the two that went over their targets. They need to get back under 703 MiB. Games was almost hit, but still has enough cushion that I can handle the hedgewars small increase in size which will be showing up in a push tomorrow unless it gets negative karma before then. But I'm still pretty close and will probably still implement whatever we do for broffice and xfce.
AFAIK XFCE should require only -single, unless they pull gnome-desktop(3) for some reason. That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
That will be lower priority for me. Kevin knows that package better and the solution there doesn't help broffice, whereas working on a general solution will help xfce in the short run, even if there is also another problem that can be fixed.
Am Samstag, den 16.10.2010, 18:42 +0200 schrieb Martin Sourada:
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:26:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
It would help to list which spins went oversize and what's their target size. So general info:
broffice and xfce are the two that went over their targets. They need to get back under 703 MiB. Games was almost hit, but still has enough cushion that I can handle the hedgewars small increase in size which will be showing up in a push tomorrow unless it gets negative karma before then. But I'm still pretty close and will probably still implement whatever we do for broffice and xfce.
AFAIK XFCE should require only -single, unless they pull gnome-desktop(3) for some reason.
libgnome-desktop is required by cheese, control-center and gnome-settings-daemon. We could drop cheese, but we wont get rid of the rest: * control-center is required by gnome-bluetooth * gnome-settings-daemon is required by gdm
There is no alternative to gdm and gnome-blueetooth [1].
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14. * Make gnome-desktop not depend on system-backgrounds-gnome. * Revert the changes on laughlin-backgrounds-gnome.
Regards, Christoph
[1] blueman, the only alternative to gnome-bluetooth depends on gnome-session which depends on control-center, so we end up with gnome-desktop again.
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
Am Samstag, den 16.10.2010, 18:42 +0200 schrieb Martin Sourada:
On Sat, 2010-10-16 at 11:12 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 17:26:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
It would help to list which spins went oversize and what's their target size. So general info:
broffice and xfce are the two that went over their targets. They need to get back under 703 MiB. Games was almost hit, but still has enough cushion that I can handle the hedgewars small increase in size which will be showing up in a push tomorrow unless it gets negative karma before then. But I'm still pretty close and will probably still implement whatever we do for broffice and xfce.
AFAIK XFCE should require only -single, unless they pull gnome-desktop(3) for some reason.
libgnome-desktop is required by cheese, control-center and gnome-settings-daemon. We could drop cheese, but we wont get rid of the rest: * control-center is required by gnome-bluetooth * gnome-settings-daemon is required by gdm
There is no alternative to gdm and gnome-blueetooth [1].
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
This is how design works. You cannot make time-of-day versions of the wallpaper sooner than you have final design. You cannot make time-of-day versions at all if you are late with the final design...
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14.
That would be sensible and probably better solution F15 onward.
* Make gnome-desktop not depend on system-backgrounds-gnome.
That would work as short term solution, but we have to be very careful to install s-b-g wherever gnome desktop is installed and uses system-wide default wallpaper.
* Revert the changes on laughlin-backgrounds-gnome.
You'd have the whole design-team against you for that...
Martin
On Sat, Oct 16, 2010 at 19:48:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
* Make gnome-desktop not depend on system-backgrounds-gnome.That would work as short term solution, but we have to be very careful to install s-b-g wherever gnome desktop is installed and uses system-wide default wallpaper.
You misunderstand. gnome-desktop is going to be installed without laughlin-backgrounds-gnome being installed in this proposal. The question would be how to make that work. One option is not having the time of day based background the default.
On Sat, 2010-10-16 at 13:08 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 19:48:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
* Make gnome-desktop not depend on system-backgrounds-gnome.That would work as short term solution, but we have to be very careful to install s-b-g wherever gnome desktop is installed and uses system-wide default wallpaper.
You misunderstand. gnome-desktop is going to be installed without laughlin-backgrounds-gnome being installed in this proposal. The question would be how to make that work. One option is not having the time of day based background the default.
I'm under the impression that you need to avoid it for broffice an xfce spins only. We definitely want it installed by default on desktop spin, design suite, etc., i.e. everywhere where gnome desktop is installed and size isn't an issue.
I.e. IMHO we need solve two cases: * it is installed and used by default * gnome-desktop is being installed, but not the time-of-day wallpaper but it still works.
In short I don't see any other solution (that would satisfy both parties) than two conflicting defaults... Yeah, if we could make one xml work for both cases that would solve the issue nicely and in better way, but I highly doubt that's possible.
Or maybe making it work using 'alternatives' (I totally don't know how and for what this system works, but maybe worth investigating) -- having one .xml symlinked to the simple .xml one unless the advanced package gets installed (we could probably handle it via %post section) and then add the advanced package to comps where desirable (would it work correctly for spins?).
Martin
On Sat, Oct 16, 2010 at 19:34:24 +0200, Christoph Wickert christoph.wickert@googlemail.com wrote:
* Make gnome-desktop not depend on system-backgrounds-gnome.
I think that one is doable (slightly differently). But there is an issue with the default them. At the worst I think the time of day theme could be made an alternative instead of the default.
Reverting will probably be about as hard and will not even provide the time of day theme as an alternate.
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14. * Make gnome-desktop not depend on system-backgrounds-gnome. * Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most conservative and appropriate action at this time.
On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14. * Make gnome-desktop not depend on system-backgrounds-gnome. * Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most conservative and appropriate action at this time.
This is a big no-no because: * it would degrade the quality of wallpaper (yes, the time-of-day addition wasn't the only thing that was done to the wallpaper) * it would reintroduce errors in cc-by attribution for the extras subpackage
Since the time is tight I'm going now to do the following update * move the time-of-day images to l-b-animated(-gnome), rename and move there also current XMLs with description and info (so that it can be installed concurrent with the default) * recreate the XMLs for non-animated wallpaper and put them in l-b-gnome * run optipng on all images
This would effectively revert the size bump of l-b-gnome while keeping the other changes and giving the user choice to use animated wallpaper.
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Thanks, Martin
On Sun, 2010-10-17 at 10:22 +0200, Martin Sourada wrote:
On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14. * Make gnome-desktop not depend on system-backgrounds-gnome. * Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most conservative and appropriate action at this time.
This is a big no-no because: * it would degrade the quality of wallpaper (yes, the time-of-day addition wasn't the only thing that was done to the wallpaper) * it would reintroduce errors in cc-by attribution for the extras subpackage
Since the time is tight I'm going now to do the following update * move the time-of-day images to l-b-animated(-gnome), rename and move there also current XMLs with description and info (so that it can be installed concurrent with the default) * recreate the XMLs for non-animated wallpaper and put them in l-b-gnome * run optipng on all images
This would effectively revert the size bump of l-b-gnome while keeping the other changes and giving the user choice to use animated wallpaper.
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Ok, I'm done with the packaging, just waiting for the optipng to finish (the already processed images are all seeing slightly above 10% decrease in size). Note that the changes are such that they revert the default wallpaper "infrastructure" to beta version while keeping the new images, move the time-of-day images into l-b-animated and introduce l-b-animated-gnome which contains XMLs needed for gnome. So effectively there is almost zero possibility breaking something by this change.
I'll let you know when the update is ready so you can give karma.
And I reiterate once again. Just un-pushing the previous update is *not* an option.
Thanks, Martin
On Sun, 2010-10-17 at 11:28 +0200, Martin Sourada wrote:
On Sun, 2010-10-17 at 10:22 +0200, Martin Sourada wrote:
On Sat, 2010-10-16 at 18:15 -0400, Matthias Clasen wrote:
On Sat, 2010-10-16 at 19:34 +0200, Christoph Wickert wrote:
That grew by 1MB, probably due to increased complexity of the wallpaper. I'd investigate this one more throughout if I were you.
If I were or a member of the design team I would not push changes like this one that late. I think this level of carelessness is inappropriate.
There are three solutions: * A gnome-desktop-libs package, but it is too late to change for F14. * Make gnome-desktop not depend on system-backgrounds-gnome. * Revert the changes on laughlin-backgrounds-gnome.
The system-backgrounds (-gnome) virtual provides were introduced with for the explicit purpose of making gnome-desktop require them...
Imo, reverting the changes to the background packages is the most conservative and appropriate action at this time.
This is a big no-no because: * it would degrade the quality of wallpaper (yes, the time-of-day addition wasn't the only thing that was done to the wallpaper) * it would reintroduce errors in cc-by attribution for the extras subpackage
Since the time is tight I'm going now to do the following update * move the time-of-day images to l-b-animated(-gnome), rename and move there also current XMLs with description and info (so that it can be installed concurrent with the default) * recreate the XMLs for non-animated wallpaper and put them in l-b-gnome * run optipng on all images
This would effectively revert the size bump of l-b-gnome while keeping the other changes and giving the user choice to use animated wallpaper.
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Ok, I'm done with the packaging, just waiting for the optipng to finish (the already processed images are all seeing slightly above 10% decrease in size). Note that the changes are such that they revert the default wallpaper "infrastructure" to beta version while keeping the new images, move the time-of-day images into l-b-animated and introduce l-b-animated-gnome which contains XMLs needed for gnome. So effectively there is almost zero possibility breaking something by this change.
I'll let you know when the update is ready so you can give karma.
https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
Please log in and give karma. Given the change is small I set the autokarma threshold to 2. It should make the spins small enough again. Given the nature of changes, the only packages that might need quick test are l-b-gnome and l-b-animated-gnome
As I said before, this is IMHO the best short-term solution for the problem, we should however rethink how the default wallpaper is selected (especially given that some spins use different default wallpapers) for F15 and onward. I'll propose something later (maybe today, maybe tomorrow, maybe next week, next month, but definitely before F15 Alpha).
Martin
On Sun, Oct 17, 2010 at 13:09:04 +0200, Martin Sourada martin.sourada@gmail.com wrote:
https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
Please log in and give karma. Given the change is small I set the autokarma threshold to 2. It should make the spins small enough again. Given the nature of changes, the only packages that might need quick test are l-b-gnome and l-b-animated-gnome
Thanks for doing this.
We need a proven packager since this package is on the crit path list.
On Sun, 2010-10-17 at 06:11 -0500, Bruno Wolff III wrote:
On Sun, Oct 17, 2010 at 13:09:04 +0200, Martin Sourada martin.sourada@gmail.com wrote:
https://admin.fedoraproject.org/updates/laughlin-backgrounds-14.1.0-1.fc14
Please log in and give karma. Given the change is small I set the autokarma threshold to 2. It should make the spins small enough again. Given the nature of changes, the only packages that might need quick test are l-b-gnome and l-b-animated-gnome
Thanks for doing this.
We need a proven packager since this package is on the crit path list.
Is it? The e-mails I get from bodhi are missing the [CRITPATH] keyword...
Martin
On Sun, Oct 17, 2010 at 13:09:04 +0200, Martin Sourada martin.sourada@gmail.com wrote:
Please log in and give karma. Given the change is small I set the autokarma threshold to 2. It should make the spins small enough again. Given the nature of changes, the only packages that might need quick test are l-b-gnome and l-b-animated-gnome
I am not sure how to test the actual animation, but the animated stuff is now optional (with gnome installed) and when it is installed can be selected. So it looks good.
On Sun, Oct 17, 2010 at 10:22:55 +0200, Martin Sourada martin.sourada@gmail.com wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
I changed the live desktop to include the animated backgrounds. I also changed broffice to remove them. Once the animated backgrounds hits updates they should be on live desktop based spins other than broffice.
I haven't made it the default yet on the desktop spin. I am looking for the right way to do that and want it in a separate commit.
I didn't add it to the install image. Without a comps change, it won't show up on the install image. I think it should be added to the gnome-desktop group as a default package to get it installed by default with gnome. That may affect what ends up on the live spins, but I think won't cause a problem the way I changed things. If this change does get made it should be done as soon after the animated packages are in stable as possible as we may need a change to fix things. Desktop controls that comps group, so I'll leave the decision there for someone in Desktop to decide. (Note that changing it early could potentially break composes.)
The spin-kickstarts package will be out of date again. I'll look at getting a new version of that into testing tomorrow.
On Sun, Oct 17, 2010 at 10:22:55 +0200, Martin Sourada martin.sourada@gmail.com wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
I added a command in post that I think will use the animated laughlin background by default in live desktop based spins. I added a similar command to broffice to use the normal one. I think this will undo the one in the included file. This will need testing, but until the laughlin-backgrounds update gets in stable I am not sure if we can easily do that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go over in size, by just a few megs. We're still in a "no-go" state until this gets fixed :/
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Tue, Oct 19, 2010 at 13:35:50 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go over in size, by just a few megs. We're still in a "no-go" state until this gets fixed :/
I look at this later tonight, but want to give Desktop a change to make some other change. Otherwise I'll try to use the same change to livecd-desktop that I do for broffice.org. Apparently I have something in the wrong place or otherwise wrong for broffice.org as my fix is breaking that build.
On Tue, Oct 19, 2010 at 15:48:49 -0500, Bruno Wolff III bruno@wolff.to wrote:
I look at this later tonight, but want to give Desktop a change to make some other change. Otherwise I'll try to use the same change to livecd-desktop that I do for broffice.org. Apparently I have something in the wrong place or otherwise wrong for broffice.org as my fix is breaking that build.
broffice.org seems OK now. I am doing a bit of testing with desktop livecd not having the animated background installed. If that looks good and I don't see a fix committed by the desktop team, I'll commit this one and do a new spin-kickstarts package (with a patch). The one Jesse did earlier is in stable so I won't block that one from getting used for the current compose.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/19/10 1:48 PM, Bruno Wolff III wrote:
On Tue, Oct 19, 2010 at 13:35:50 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go over in size, by just a few megs. We're still in a "no-go" state until this gets fixed :/
I look at this later tonight, but want to give Desktop a change to make some other change. Otherwise I'll try to use the same change to livecd-desktop that I do for broffice.org. Apparently I have something in the wrong place or otherwise wrong for broffice.org as my fix is breaking that build.
So the change makes the background on Gnome very plain blue, obviously something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and proposed as a blocker. Could be just as easy as fiddling with the ks script in which case only the Desktop images would need to be respun.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/10 4:35 PM, Jesse Keating wrote:
So the change makes the background on Gnome very plain blue, obviously something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and proposed as a blocker. Could be just as easy as fiddling with the ks script in which case only the Desktop images would need to be respun.
Well this is strange. Trying to repeat the issue I'm no longer able to reproduce...
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Thu, 2010-10-21 at 16:47 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/10 4:35 PM, Jesse Keating wrote:
So the change makes the background on Gnome very plain blue, obviously something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and proposed as a blocker. Could be just as easy as fiddling with the ks script in which case only the Desktop images would need to be respun.
Well this is strange. Trying to repeat the issue I'm no longer able to reproduce...
Perhaps the change to an xml file (or whatever) which defines what wallpaper gets shown at what time of day is in another package and hence still present, and so you'll see a blank blue background at some times of the day (when the intended background file isn't present) and the standard background at the times of day when that one is supposed to be used?
On Thu, Oct 21, 2010 at 20:48:13 -0700, Adam Williamson awilliam@redhat.com wrote:
Perhaps the change to an xml file (or whatever) which defines what wallpaper gets shown at what time of day is in another package and hence still present, and so you'll see a blank blue background at some times of the day (when the intended background file isn't present) and the standard background at the times of day when that one is supposed to be used?
That would be my guess as well.
On Thu, 2010-10-21 at 20:48 -0700, Adam Williamson wrote:
On Thu, 2010-10-21 at 16:47 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/10 4:35 PM, Jesse Keating wrote:
So the change makes the background on Gnome very plain blue, obviously something isn't right :/
https://bugzilla.redhat.com/show_bug.cgi?id=645606 has been filed and proposed as a blocker. Could be just as easy as fiddling with the ks script in which case only the Desktop images would need to be respun.
Well this is strange. Trying to repeat the issue I'm no longer able to reproduce...
Perhaps the change to an xml file (or whatever) which defines what wallpaper gets shown at what time of day is in another package and hence still present, and so you'll see a blank blue background at some times of the day (when the intended background file isn't present) and the standard background at the times of day when that one is supposed to be used?
The package with the xml that defines animated background requires the packages that contain the images:
$ rpm -qf /usr/share/backgrounds/laughlin/default-tod/laughlin.xml laughlin-backgrounds-animated-gnome-14.1.0-1.fc14.noarch
$ rpm -q --requires laughlin-backgrounds-animated-gnome laughlin-backgrounds-animated = 14.1.0-1.fc14
$ rpm -q --requires laughlin-backgrounds-animated laughlin-backgrounds-single = 14.1.0-1.fc14
So it could be broken only if there's a typo somewhere in the xml which does not seem to be the case (I have quickly checked it).
Martin
On Fri, Oct 22, 2010 at 10:37:29 +0200, Martin Sourada martin.sourada@gmail.com wrote:
$ rpm -qf /usr/share/backgrounds/laughlin/default-tod/laughlin.xml laughlin-backgrounds-animated-gnome-14.1.0-1.fc14.noarch
$ rpm -q --requires laughlin-backgrounds-animated-gnome laughlin-backgrounds-animated = 14.1.0-1.fc14
$ rpm -q --requires laughlin-backgrounds-animated laughlin-backgrounds-single = 14.1.0-1.fc14
So it could be broken only if there's a typo somewhere in the xml which does not seem to be the case (I have quickly checked it).
Not on the live spins. Because live-desktop is modified to try to use the time of day background and livecd-desktop (and derivations such as games and broffice.org) have the animated backgrounds removed and try to override the live-desktop override. And something there might be broken. It may be that all the overrides (in the %post sections) for the background get pulled. (I think broffice.org has one as well, since at first there was hope that livecd-desktop could have the animated backgrounds and still fit.)
On Tue, Oct 19, 2010 at 13:35:50 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go over in size, by just a few megs. We're still in a "no-go" state until this gets fixed :/
I removed the animated backgrounds from the Desktop livecd image to get it under size.
I noticed that at least on one machine that a dd'd image to a usb device wouldn't boot because of an isolinux.bin issue. I filed a bug on this, though I don't think it's a blocker.
El mar, 19-10-2010 a las 13:35 -0700, Jesse Keating escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/17/2010 01:22 AM, Martin Sourada wrote:
Would be nice though, if you could then change the desktop spin kickstart to use the animated version of the wallpaper by default as we'd like to see it used on it.
Unfortunately the animated wallpapers on the desktop spin make it go over in size, by just a few megs. We're still in a "no-go" state until this gets fixed :/
Maybe too late for f14, but the following changes to comps could help:
* make planner (6 MiB) optional in office, same for openoffice.org-draw; they're too specialized apps. * make system-config-lvm optional (3.1 MiB) in admin-tools; obsoleted by palimpsest
Perhaps I'm the only one that is wondering if we are we going to stick with OpenOffice as our default or make LibreOffice our default and migrate our users to LibreOffice?
It would be good to get the desktop members view on this for future deployments.
JBG
On Wed, Oct 20, 2010 at 12:42:57PM +0000, "Jóhann B. Guðmundsson" wrote:
Perhaps I'm the only one that is wondering if we are we going to stick with OpenOffice as our default or make LibreOffice our default and migrate our users to LibreOffice?
You're not. This has been asked on fedora-devel:
http://lists.fedoraproject.org/pipermail/devel/2010-October/143728.html
Summary: LibreOffice from F15 onwards
On 10/20/2010 12:47 PM, Sven Lankes wrote:
On Wed, Oct 20, 2010 at 12:42:57PM +0000, "Jóhann B. Guðmundsson" wrote:
Perhaps I'm the only one that is wondering if we are we going to stick with OpenOffice as our default or make LibreOffice our default and migrate our users to LibreOffice?
You're not. This has been asked on fedora-devel:
http://lists.fedoraproject.org/pipermail/devel/2010-October/143728.html
Summary: LibreOffice from F15 onwards
Thanx for the heads up.
JBG
Perhaps I'm the only one that is wondering if we are we going to stick with OpenOffice as our default or make LibreOffice our default and migrate our users to LibreOffice?
It would be good to get the desktop members view on this for future deployments.
JBG
For the zero-added-value that my humble (or not so humble) response represents, having not really looked around much but having seen the announcement regarding LibreOffice in September/early October, I was always assuming that LibreOffice was going to be "coming down the pipeline" in Fedora ASAP given that Red Hat has squarely thrown its support behind LibreOffice.
Of course I never questionned it not being in F14 for simple reasons of logistics and the ensuing nightmare that would be created by the replacement of such a major set of packages a couple of months after branching off of Rawhide. I never had any specific notion in my head of when it would be put into Fedora but I assumed "Well this is Fedora, and further Red Hat is supporting LibreOffice, so LibreOffice will replace OO.o as soon as it's seen to be practical based on whatever set of criteria that TPTB see fit."
Am Samstag, den 16.10.2010, 18:15 -0400 schrieb Matthias Clasen:
Imo, reverting the changes to the background packages is the most conservative and appropriate action at this time.
+1. At this stage we need to be conservative because of our release policies.
Regards, Christoph
I don't have much experience with pngout, but it claims to be able to shave an extra 14% off these images' sizes. I tried it out on the four images in standard/ and got this result:
% for foo in *png; do wine ~/bin/pngout.exe "$foo" out/"$foo"; done In: 3811866 bytes laughlin-01-morning.png /c6 /f5 Out: 3305323 bytes out/laughlin-01-morning.png /c2 /f5 Chg: -506543 bytes ( 86% of original) In: 3471621 bytes laughlin-02-noon.png /c6 /f5 Out: 3009028 bytes out/laughlin-02-noon.png /c2 /f5 Chg: -462593 bytes ( 86% of original) In: 3254979 bytes laughlin-03-evening.png /c6 /f5 Out: 2822083 bytes out/laughlin-03-evening.png /c2 /f5 Chg: -432896 bytes ( 86% of original) In: 3168173 bytes laughlin-04-night.png /c6 /f5 Out: 2735233 bytes out/laughlin-04-night.png /c2 /f5 Chg: -432940 bytes ( 86% of original)
On Sat, Oct 16, 2010 at 8:20 AM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Oct 16, 2010 at 10:07:24 +0200, Martin Sourada martin.sourada@gmail.com wrote:
I apologize for the inconvenience -- I should have probably notified the desktop folks ahead that it was highly probable that l-b-g-gnome would increase in size rather drastically (I myself had the info week ahead of the packaging)...
It's a bit more than an incovenience. It is breaking some spins. (In that they aren't going to make their target size without changes.) We either need a way to only get some of that stuff, or some way to not use that package for at least a few spins. We only have a few days to react to this. The two spins that went over size are probably going to have a problem with removing other software and we will probably want to look at some way to use a simpler backgrounds package. If you guys have some ideas in that direction it would help. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Sat, Oct 16, 2010 at 12:32:54 -0500, Charles Kerr charles@transmissionbt.com wrote:
I don't have much experience with pngout, but it claims to be able to shave an extra 14% off these images' sizes. I tried it out on the four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for all of the artwork, I don't think that is going to help enough here. Given the short amount of time, I don't think this approach (assuming it was expanded to include a larger set of artwork) is going to be practical as an immediate solution.
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 12:32:54 -0500, Charles Kerr charles@transmissionbt.com wrote:
I don't have much experience with pngout, but it claims to be able to shave an extra 14% off these images' sizes. I tried it out on the four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for all of the artwork, I don't think that is going to help enough here. Given the short amount of time, I don't think this approach (assuming it was expanded to include a larger set of artwork) is going to be practical as an immediate solution.
Once, we used optipng for that, but the savings really aren't that much (depending on picture, about 10%) plus they're time-intensive.
Martin
On Sat, Oct 16, 2010 at 20:08:30 +0200, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 12:32:54 -0500, Charles Kerr charles@transmissionbt.com wrote:
I don't have much experience with pngout, but it claims to be able to shave an extra 14% off these images' sizes. I tried it out on the four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for all of the artwork, I don't think that is going to help enough here. Given the short amount of time, I don't think this approach (assuming it was expanded to include a larger set of artwork) is going to be practical as an immediate solution.
Once, we used optipng for that, but the savings really aren't that much (depending on picture, about 10%) plus they're time-intensive.
But it should only be time intensive creating the image. It saves space on every machine that they are installed on. 10% accross the board is pretty good and you probably should be doing that. Not necessarily when you are reviewing stuff, but once you start using them in packages you really should be doing the better compression.
On Sat, Oct 16, 2010 at 8:08 PM, Martin Sourada martin.sourada@gmail.com wrote:
On Sat, 2010-10-16 at 12:43 -0500, Bruno Wolff III wrote:
On Sat, Oct 16, 2010 at 12:32:54 -0500, Charles Kerr charles@transmissionbt.com wrote:
I don't have much experience with pngout, but it claims to be able to shave an extra 14% off these images' sizes. I tried it out on the four images in standard/ and got this result:
While better lossless compression would be a good thing to be doing for all of the artwork, I don't think that is going to help enough here. Given the short amount of time, I don't think this approach (assuming it was expanded to include a larger set of artwork) is going to be practical as an immediate solution.
Once, we used optipng for that, but the savings really aren't that much (depending on picture, about 10%) plus they're time-intensive.
10% is a rather nice improvement ...
"plus they're time-intensive"
That doesn't matter the extra time is *buildtime* not actual runtime.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bruno Wolff III -
Charles Kerr -
Christoph Wickert -
Donald Buchan -
drago01 -
Iván -
Jesse Keating -
Jóhann B. Guðmundsson -
Martin Sourada -
Matthias Clasen -
Sven Lankes