So many ideas, so little time. So many todos, no little time. So little time, so much rest of my life. But the
todo list has actually started to become a little shorter for the first time in a long time. As with the previous entries
about my progress with SBWG, I'm not going to address or list everything that I've improved or added. But I feel like it's
time for another update.
File attachments pretty much work as intended now. Text files still can't be file attachments to entries, because text
files are entries. But I think that will stay as it is for now because I don't need to attach text files to entries and if
I would, I could gzip, bzip or 7z them. I mainly wanted file attachments for entry images and podcast support. Both works
as well as I need it to. But some things could still be improved in the future.
Referencing tags are improved, their notes look better and there is now a way to mark an entry as an update of an other
entry, giving both entries a note that tells the reader about the newer/older version. And since this works now, I dropped
the idea to introduce any form of content revisioning. An entry revision system would be over the top for a feature that I
hardly use. This could still be implemented just with hooks.
SBWG was relying on a feature of ImageMagick's mogrify that turned out to be a bug and was fixed. So I had to switch to
convert with worse tolerance/support for broken image files. That's annoying, but I'm over it now. I mean, I wasn't
complaining. Those tools are amazing and I'm so glad that they are free.
There were a number of other bugs that I've fixed. Some of them old and overlooked. But most of them were introduced not
long ago. Well, I guess that's what happens if you don't do proper tests every time. SBWG is starting to become a
feature-rich tool and every new feature that gets implemented could cause trouble with other features or combinations of
features. In early versions of SBWG I didn't always test everything I changed. I now do, and I now also try to think of
some related things the change could have effected unintentionally and test those basically. But proper tests of all sorts
of scenarios every time I publish a new version? That would be professional but not worth the effort in this case. If I'm
not using a feature, it doesn't matter much if I break it. I think I'll probably do more extensive tests every now and
then.
Entries can now have comment links. If there is an email address available for an author, all their entries get an email
link below them to allow readers to reply to them. For a public blog it might be best to use throwaway addresses that can
quickly be replaced if they start to receive spam. I'd have some ideas to improve the email composed by this comment
feature. But they would have to become HTML emails. So I forgot about them again.
New tag types, expanded README file, improved navigation by adding parent links and things like this, improved CSS a bit
here and there, very small improvements to the code style. I didn't make any relevant improvements or corrections in terms
of code quality. I think this is where SBWG could improve most. It's not a professional thing, so I declare myself fine
with the way it is (which isn't that bad compared to some other software, I think) but I could learn a lot there.
Command line options can now be grouped to make typing commands easier. Long options (starting with --) didn't change (I
may make those things POSIX-like, too, some other time) but short options (starting with a -) now don't need to be
separated and all have their own dash. So sbwg -v -p -e blub can now be shortened to sbwg -vpe
blub. And if you want to run the command again but with added verbosity, you can add the second -v
wherever you want.
There is now a waiting animation that starts to play if there is no update on stdout for three seconds. Both the
animation frames and the time delay can be changed. The animation is only enabled if SBWG runs with any verbosity. Then it
is enabled by default. It will be disabled by default in future versions though, I think, because it's such an unnecessary
messing around with terminal output. It does work pretty well though. I thought it may be harder to make it work as
smoothly as it does now (which isn't 100% perfect, but pretty good).
The new default style set 'elth' is a working hybrid with different styles for small phone screens and larger screens of
phablets, tablets and laptops. It's composed of several CSS files, which should make it easier to create a custom style
now, since just the basics (without any colors and fancy embolishment and without any tag-specific stuff) can be copied for
a template, or just the mobile style can be copied and used to create a new mobile style. Style sets can now also include
files whose name don't end in '.css'. That means they can contain any file type. So JS or background images or whatever
will be copied as part of the style set and placed in the 'styles/' directory of the generated web site.
More things are now cached that may be used more than once in one run of SBWG. Permament caches (option -C/--cache) can
now be enabled for only parts of the web site. I still need to decide how permanent caches should be managed. The way I
had/have it in mind does not seem very intuitive. It is to me because I know how it's built. But... well, maybe it's enough
that I think that it makes sense. Maybe I should just start using it and if it works well, write it down in the README
file.
Added new hooks, gave the helper scripts makeovers, made how HTML footers are made logical, sorted much of the remaining
todos. Overall: progress.
So, I've published SBWG version 0.10.7 now. I wish I'll find the time to
create and publish new versions more frequently again in the near future. But I doubt I will.