GIMP
News
Docs
Tutorials
More
I (Pat David) am creating this page to keep notes and information for building/maintaining the new site.
Other (Meta) pages of interest:
For anyone who wants to build and view the site, they will need only Python, and a couple of extra components (Pelican, Markdown, typogrify). This is the same procedure anyone can use to test new content they would like to propose or push.
pip install pelican==3.6.2
The version of Pelican the server uses is 3.6.2.
Use this version for now to stay in sync with pentagon (the server).py3-requirements.txt file to install all the requirements at once:
pip install -r py3-requirements.txt.pip install Markdownpip install typogrifypip install bs4For detailed information refer to the Pelican documentation.
Building the site is relatively straightforward:
From the project directory, simply invoke pelican:
pelican
If you are writing content or developing other parts of the site, there is an option to watch the directory of files for changes and to automatically re-compile the site as needed:
pelican -r
In some cases, it can be beneficial to avoid using the cache that Pelican creates internally (to help speed up the build). To avoid using the cache, and to watch for changes and rebuild as necessary:
pelican -r --ignore-cache
Python has a simple web server available to preview the site.
For Python 2:
cd output
python -m SimpleHTTPServer
For Python 3:
cd output
python -m http.server
The site can then be accessed locally at:
localhost:8000
Further notes on using Pelican can be found on the page Using Pelican.
In the root of the project is a JSON file called GIMP_VERSIONS.
This file is meant to contain relevant information for all of the GIMP releases in a parse-able format.
It’s also used to automatically fill out relevant information on the /downloads/ page such as the current stable version and associated hashes + links.
The current stable version is automatically pulled from the most recent entry under STABLE.
The current win/osx versions are automatically determined from the most recent entry under STABLE that includes either ‘windows’ or ‘macos’ respectively. If an entry is not found in a section, it will continue searching down the list until it’s found.
'STABLE': {
'VERSION #': {
'source | windows | macos': {
'filename': 'hash'
}
}
}
For example, at the time of writing this, 2.8.18 was the most recent stable version, and the GIMP_VERSIONS file looked (partially) like this:
"STABLE": {
"2.8.18": {
"source": {
"gimp-2.8.18.tar.bz2": "5adaa11a68bc8a42bb2c778fee4d389c"
},
"windows": {
"gimp-2.8.18-setup.exe": "510bb11abc72443f431226523fa21b6f"
},
"macos": {
"gimp-2.8.18-x86_64.dmg": "76858c813e9974b187edfd71ce6d83c6506d6a3c"
}
},
If there had been no windows section under 2.8.18, then the code at the end of pelicanconf.(local|testing|).py would have checked the next section and so on until it found one.
The work I am doing here is based on a couple of suggestions over the past year (or more, I’m sure) to refresh the design of WGO. In particular, I had created a brief mockup to show and have been using that as a sort of visual guide for approaching the main page. You can view that mockup .PNG here (~1.8MB), or a smaller preview:
There are two main reasons for Why we might want to revamp the site: Modernization and Collaboration.
A new facelift for the website can’t hurt from a PR standpoint. We can also leverage more modern design ideas around responsiveness for various screen sizes.
There was no good method previously of writing news/blog-type postings that would easily maintain a post history that could be referred to. A modernization effort can take that into account and allow for a means to post news items that will be archived and maintained for posterity. For example, you can read about a GIMP Perl release candidate from June, 2014, as well as have a permalink to that particular news item in the future.
I have no data to back this up, but can’t help feel that some of the lack of new tutorials or content for the site could be attributed to the convoluted ways to submit information (plus it is generally more lucrative for folks to host their own tutorials and content in an effort to monetize them vs. sharing them openly here — that’s a different issue).
If someone does want to submit new content, it can only be helpful to make the barrier to collaboration as low as possible.
Currently, if someone wants to contribute content, and test it before attempting to push it, they need to:
Some of these things are non-trivial. Especially for someone who may be good at writing quality content but not technically inclined enough to stand up the build environment.
The How section below covers the means to making things easier to test and contribute.
I thought a bit about the main reasons a person would be visiting the site. What is someone looking to do when coming to WGO?
These are what I thought would be the main reasons for visiting the site (in order):
It seems like #2 could probably cease being a reason after someone has learned about the project.
After talking with schumaml, it was decided to leverage the existing Python on the server to build the site. Some research revealed that the most ubiquitous (read: maintained) static site generator for Python is Pelican.
The basic workflow for just about any SSG (static site generator) is to take a directory full of content (writing, images, and other assets), then process them in some fashion before finally writing a new directory containing the site ready for upload.
The build systems will often help to abstract away portions of the underlying html. For instance, many will take files written as Markdown or reStructuredText, which are simpler format for writing content that can easily be parsed into html (or other formats).
