RSS/Atom feed Twitter
Site is read-only, email is disabled

RFD03 - Getting the splash screens from gimp CVS, not gimp-web

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

1 of 1 message available
Toggle history

Please log in to manage your subscriptions.

RFD03 - Getting the splash screens from gimp CVS, not gimp-web Raphaël Quinet 21 Oct 18:54
Raphaël Quinet
2003-10-21 18:54:34 UTC (over 20 years ago)

RFD03 - Getting the splash screens from gimp CVS, not gimp-web

The splash screens displayed in the About section of the new web site are all stored in the gimp-web CVS module. Whenever a new splash screen is added to the GIMP (in the gimp module), it is necessary to copy it to the gimp-web module, generate a preview and commit the results. This has not been done for several months, so the last splash screen in http://mmmaybe.gimp.org/about/splash-1.3.html is for GIMP 1.3.10.

In addition, doing a cvs checkout of the gimp-web module is a bigger download than doing a checkout of gimp HEAD *plus* the gimp-1-2 branch. This is due in large part to the images for the tutorials (25 MB for gimp-web/tutorials/) and the splash screen history (17 MB for gimp-web/about/). The tutorials are obviously important, but it would be nice to reduce the size of this download by not including the splash screens in the gimp-web module.

Instead of having to copy the splash screens by hand, it would be nicer to create a script that can do most of the work automatically. Those who want to fetch the gimp-web module from CVS and test it could choose to run the script or not (this could be decided at configure time - see RFD01), depending on whether they intend to use that part of the site or not.

The script would work in the following way:

- It would take as input a list of the names that have been used so far for the file containing the splash screen. This list would not include any version numbers, so it would be relatively short and easy to maintain: gimp_splash.ppm (maybe also the variants 1_0, 1_1 and 1_2), data/images/gimp_splash.ppm, ....gif and ....png.

- For each file, it would do a "cvs log" to check the list of CVS revisions and the list of release tags (marked as "symbolic names" in the log). Using the regexp "GIMP_(\d\d?)_(\d\d?)_(\d\d?)", it is possible to extract the GIMP release number from the tags: major, minor, micro as $1, $2, $3. Getting this information directly from CVS would ensure that the script would get the latest revision of the file. It is not a problem to get the correct cvsroot because it can be copied from the one used for the gimp-web module.

- For each revision that was part of at least one GIMP release, it would do a "cvs checkout -r $revision -p" and store the result in a file with the appropriate name.

- After that, it would build the index pages and the thumbnails for the images. For each splash screen, it would show its CVS file name and revision number (small text, because this is not important) and the list of all GIMP releases that used that splash screen.

In addition, the script could check that at least one of the files has a current state that is not "dead". If all of them are "dead", indicating that the splash screen has been renamed again, it could warn the user who is trying to update the web site, so that it would be obvious that something should be updated. The icing on the cake would be to display the last log entry so that the user can see the new name of the file. Or someone builds some AI in the script that parses the log entry, understands natural language and does the whole thing automatically. ;-)

I think that automating the process of fetching the splash screens from gimp CVS would make it easier to keep the gallery up-to-date. In addition, it would reduce the download and make it easier for potential contributors to get the gimp-web module if they do not need all splash screens.

I am willing to write such as script, as soon as I have some spare time. I think that I already have most of it in my head, so it should not be too hard to implement. Still, any comments on this idea are welcome.

-Raphaël