Most of them are now _mandatory_ P3 scripts, because I'm tired of
maintaining everything to be compatible with both versions.
The current exceptions are gdb.py (which has to live with whatever gdb
gives it), and kh2reg.py (which is actually designed for other people
to use, and some of them might still be stuck on P2 for the moment).
The number of people has been steadily increasing who read our source
code with an editor that thinks tab stops are 4 spaces apart, as
opposed to the traditional tty-derived 8 that the PuTTY code expects.
So I've been wondering for ages about just fixing it, and switching to
a spaces-only policy throughout the code. And I recently found out
about 'git blame -w', which should make this change not too disruptive
for the purposes of source-control archaeology; so perhaps now is the
time.
While I'm at it, I've also taken the opportunity to remove all the
trailing spaces from source lines (on the basis that git dislikes
them, and is the only thing that seems to have a strong opinion one
way or the other).
Apologies to anyone downstream of this code who has complicated patch
sets to rebase past this change. I don't intend it to be needed again.
In Python 3, open(path, "w") defaults to text files encoded using some
default encoding, which of course isn't what we want for image data.
Use open(path, "wb") instead, and adjust the write calls to use forms
that work with Python 3. bytes() and bytearray() are available as of
Python 2.6.
(This could be simplified to e.g. b"%c%c%c%c" % (r,g,b,a), and similarly
avoiding the manual .encode call; but %-formatting on bytes requires
Python 3.5, and I thought it might be better to be compatible with older
versions of Python 3.)
"key in dict" was introduced in Python 2.2, and the older
"dict.has_key(key)" form was removed in Python 3. Use the more portable
"key in dict" form instead.
Python 3 changed the built-in round() function to use round-to-even for
exact half-way cases. While this eliminates a bias away from zero and
is thus a better choice in many cases, it's not what mkicon.py expected.
Shadow the built-in with an invocation of the decimal module instead:
this produces identical results for mkicon.py's purposes on both Python
2 and 3.
In Python 2, x/y means floor division if both x and y are ints, and true
division otherwise: that is, 1/2 == 0. In Python 3, x/y always means
true division even if both x and y are ints, so 1/2 == 0.5.
To prepare for porting to Python 3, change all the places that relied on
floor division to use the more explicit // operator, and use "from
__future__ import division" to change the / operator to use Python 3's
semantics even in Python 2. Both of these features have been available
since Python 2.2.
mkicon.py now outputs .pam by hand, rather than using ImageMagick to
go straight to .png. For most purposes the main makefile then uses
ImageMagick anyway, to convert those .pams straight to the .pngs that
the rest of the scripts were expecting. But one script that doesn't do
that is macicon.py, which builds the MacOS .icns file by directly
reading those .pam files back in.
This allows the 'make icns' target in the icons directory to build
from a clean checkout on vanilla MacOS, without requiring a user to
install ImageMagick or any other non-core Python image handling
module.
(I could probably take this change at least a little bit further. I
don't see any reason why icon.pl - generating the Windows .ico files -
couldn't read the .pam files directly, about as easily as macicon.py
did, if anyone had a use case for building the Windows icons in the
presence of Python and Perl but in the absence of ImageMagick. But the
.png files are directly useful outputs for Unix, so _some_ PNG-writing
will have to remain here.)
The Xcode icon composer doesn't seem to exist any more in modern
versions of Xcode, or at least if it does then it's well hidden and
certainly doesn't live at the top-level path at /Developer where web
pages still claim it can be found.
There is a free software 'libicns' and associated command-line tools,
but they're large, complicated, picky about the exact format of PNGs
they get as input, and in any case a needless extra build dependency
when it turns out the important parts of the file format can be done
in a few dozen lines of Python. So here's a new macicon.py, and
icons/Makefile additions to build a demo icon for OS X PuTTY, as and
when I finally get it working.
Also I've deleted the static icon file in the neglected 'macosx'
source directory, because this one is better anyway - the old one was
appalling quality, and must have been autogenerated from a single
image in some way.
my editor, which has defaulted to showing them as explicit ^I for a
while now, but it seems like a generally prudent idea in any case.)
[originally from svn r8472]
match the original icons. (Apparently I managed to introduce errors
while transcribing the originals for detailed analysis.)
While I'm at it, add the obviously useful `make install' target in
icons/Makefile, and fix the svn:ignore property on the icons
directory.
[originally from svn r7068]
suite. In a dramatic break with tradition, I'm actually checking in
the resulting icon files as well as the script that generates them,
because the script requires Python and ImageMagick and I don't think
it's reasonable to require that much extra infrastructure on
everyone checking out from Subversion.
The new icons should be _almost_ indistinguishable from the old
ones, at least at the 32x32 resolution. The immediately visible
change is that all the icons now come in 16x16, 32x32 and 48x48
formats, in both 16 colours and monochrome, instead of an ad-hoc
mixture of whichever ones I could be bothered to draw.
The same code can also be adapted to generate icons for the GTK port
(although icons for the running programs don't seem to be supported
by GTK 1 - another reason to upgrade to GTK 2!).
[originally from svn r7063]
