Hi Ivan, thanks for your suggestions. Please let me add some more technically motivated comments.
In the same way as developers have to care for user experience, plans for possible changes must take technical boundary conditions into account that at least might have an influence on when something can be done and how long it will probably take. This can be much more than the apparent effort that is obvious at a first glance. Ivan M wrote: > 1) Get rid of old icon sets. Industrial and Classic are two good candidates > IMO. I don't know who actually uses or needs this icon sets. So not the developers should be asked, but rather the users. I never switched icon sets except for testing the feature, but that's only me. > > 2) Run PNGOUT [2] on all icon sets to reduce the size of each PNG file. > Small reductions across many files add up substantially. IMHO it doesn't make sense to save a little space in the installation set at the price of blowing up the size of the code repository. Each new version of an image enlarges the repository with its size, as binary files can't be stored as a diff. Please read more about that below. > 3) Reduce the duplication of images in each icon set. The high contrast icons > also appear to be duplicated in the Galaxy icon set - does anyone know why? I assume that not all are duplicates, so it makes sense to keep the hc images. We won't support incomplete packages, with fallback magic that messes up the code and makes it slower. *If* the hc images package makes sense, I rather would expect that it should be fixed to contain hc images only. > 4) Increase/decrease the compression of each icon set depending on the > performance impact (i.e., we can reduce compression if it will make > OOo load faster, or we can increase it if the extra memory use is > inconsequential). See 2). Besides that I expect this effect to be unmeasurable. > #2 alone could save a few megabytes and would require no code > modifications whatsoever. At the very, very least we should do this, > and it could be done in time for OOo 3.3 (maybe even 3.2.1?) I have my doubts about the "few megabytes". But even if I took that for granted, I wouldn't believe that shaving off a few MB disk space is what will make OOo more attractive to users. I know for sure that it will raise complaints about the size of the OOo source code repository, as explained. Most users won't notice this change ever. But developers will, and they won't like it. We are thinking about a possible code repository split somewhere in the future. At that point in time it wouldn't be a problem to exchange all images as we could move them all into a new repository. So if the modifications were prepared (and no other reasons exist not to make them), we could arrange for them as soon as we know when the split will happen. A repository split will happen only when a new code line is split off. As the 3.3 code line split will be too near to prepare our build system and other tooling for the move of some modules to an own repository, I assume that it could happen for 3.4. Regards, Mathias --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
