Entries tagged 'cat:Software'

SBWG 0.10.11

It's been two months since I published a new version of SBWG (and therefore since I worked enough on it to make me feel that an increase in the version number may be justified). I hardly get around to working on it, lately. But when I do, I try to make some solid small steps towards the improvements I wish do be done to SBWG.

So, now there is a new version (0.10.11) but I haven't published it yet because before I do I want to test it a bit more when I'm not as fucking tired as I am right now. Writing this entry could actually be considered part of the testing that I still want to do. But as I said, I'm fucking tired right now. So I'll continue this entry another time.

Edit 2022-09-12: I did some tests with fake content offline and feel confident that I fixed more than I broke in this version. I'll add it to the project page soon.

Two long procrastinate areas that have been overdue to get fixed for a while now are permanent caching and parallelisation. For permanent caching, the bugs that I found are fixed. Aggressive caching with option `--cache` (`-C`) works and it certain groups can be selected (excluding others) for permanent caching. In my test this speeds up everyday web site re-generations by up to 100%. But it also means the user has to be aware of the cache files that persist after SBWG is done and will be used the next time. Changes to existing entries will not take effect without removing the relevant cache files. For parallelisation, the bugs that I found and that affect the generated HTML are fixed. I still consider parallel mode to be experimental. Sometimes messages on stdout are weird or cut off. But who used very verbose mode and looks at every message anyway? Parallelisation is functional and usable is what I mean to say. In my test on a Core i5 with 4 cores (8 threads) it speeds up everyday web site re-generation by around 380% with default settings. It depends a lot on how much of web site generation is generating thumbnails and other image sizes of file attachments or gallery images. Those aren't sped up that much because the CPU already is the bottleneck for those. HTML file generation profits more from having more parallel threads than CPU cores (or threads) running.

Comment via email

Klik & Play

I have been wanting to write about this piece of 16 bit Windows software for a quite a while. I don't know why.

I'll just start this entry and continue whenever. Just want to have it started for now…

When I got my first own computer - that must have been around 1996 or 1998 (probably closer to 1998) - I got most of the software that I used for free from magazines that came with diskettes or CDs. Because it was cheap. I reckon the publishers didn't really pay for the software that was on them, or may even have gotten payed for including restricted freeware/shareware on them. Because most of these magazines weren't even pricey for the magazine themselves, and you got the software for free. One of these disks included a demo of "Klik & Play" (That's how it's spelled everywhere. I'm pretty sure it was spelled "Klik 'n' Play" in the logo/intro animation, though. But whatever.) A programme that promised to enable the user to create computer games without previous knowledge, without writing any code, without knowing how to programme at all. I checked it out just because it was there. I remember thinking "who are they trying to fool with that language and why?" because of the slogan and promises (that I don't remember word by word). But after playing with it for a while, I was positively surprised by how true the claims seemed to be. You could really create a video came without knowing how to code.

I thought this piece of software genius back in the day. I was - idk - 12 and hadn't really thought of writing my own software. Computer software, in the minds of the people that I had to do, wasn't something that you wrote or edited yourself. Creating your own programme, writing your own code wasn't really in the realm of possible things to do with a computer. Almost as much as it is viewed now. I mean, editing a .BAT file in DOS was the hackiest one would get among my friends, and even that was rare. So the fact that the developers (Europress Software - Wikipedia credits Francois Lionet and Yves Lamoureux) managed to allow me, to create a simple, 2D, actually playable game, and the way they managed to allow this by using mostly to only the mouse, impressed me.

I think I don't want to explain how creating a game with Klik & Play works in detail. You can search the web or watch a video for that. But to get an idea of what it was like, and of how simple it was: On any given screen ("level") you can click an icon to add an object. You can select from a number of categories or add your own graphics and GIF animations. Then you could choose whether that object is just a background object (not doing anything, not moving, not interacting with other objects, not changing, ...) or if it represents one of the players. If it's a player, you can choose a set of controls. Most of the actual programming takes place in a table. On one axis are all the objects, on another axis something that can happen to or with them. And in the fields of the table, you choose what's supposed to happen when this circumstance ever comes true. So the table sort of represents a huge set of possible interrupts. Common things that can be acted upon are: An object touches an edge of the screen, an object touches another object, a key has been pressed and released, ... And examples for possible actions are: Move an object by incrementing/decreasing coordinates or by setting them to a fixed value, changing an objects velocity, jumping to the next or a specific screen ("level") in the game, increasing the player's points by 1. Just with there few examples, you could: Make the player object jump when you hit the space bar (e.g. in a jump&run style game), make it stand on the ground object and platforms (e.g. in a platform style game), make it move left and right when you hit the arrow keys, make it reappear on the other side of the screen when it leaves of side (like in Asteroids), make it collect and count coins, make it die when it touches a deadly enimy and only one life was left on the counter, go to the next level when this one is won, ... and much more.

Note that this is all done by only clicking on objects, buttons, lists, menus. Once you got used to the interface and know what's available, it's really easy to use. There is a feature that makes getting started with a new game even easier though. You can run the game in a mode where every event for which an action can be defined, interrupts the game and lets you choose an action (or choose that for this event it shouldn't ask/interrupt again) and then continue the game. The ball touched a stone, what do you want to happen? Bounce the ball, delete the stone object, increase variable A by 1, play CLICK.WAV. The ball touched the left edge of the screen. What do you want to happen? Bounce the ball, play CLACK.WAV. …

I think I could have handled writing code myself at that age, at least after having created some silly game-like things in Klik & Play. But nobody showed me and teaching myself seemed overwhelming. (It wasn't really. Good books and reference guides existed back then. But I didn't know.) Anyway.

You could play the game file by opening it with Klik & Play or you could compile it, which produced two files: an 16 bit EXE and a game file. I think the latter contained all the graphics and sounds and the executable was the actual game. But I'm not sure.

There were a number of programmes around in the 90s that promised to let you programme and/or create your own games without knowing anything about computers first (or that made some similar claims of that sort.) I tried two others, that took a completely different approaches. But I think they deserve their own entries. I could probably plan to make a series about these sort of tools where I start with the goal to create a complete list of functional, worth mentioning programmes, and end up with a pile of unexpected feelings of resignation over the fact that there are too many products to mention, like I did with alternative operating systems.

(tbd: proofreading, add links, add screenshots, fix misremembered details, write continuation about Klik & Play games.)

Comment via email

SBWG 0.10.10

I decided to publish a new version of SBWG. I hardly got around to editing it in the last few months. So it doesn't really contain the new things that I had for a while intended for v0.10.10. But there were a few bugs that I wanted to have fixed in the latest published version. There still are known bugs. But now there are a few less.

Well, since it doesn't really contain anything new that's relevant, I didn't have to create this entry. But I did, so I'll use it to say I also fixed the RSS feed of draft0 and the menu link of steephlog on mobile. Bugs that I didn't know I had introduced in the last update and that were very happy that I didn't test things beforehand.

The things that did change since my last SBWG update just aren't that interesting. But I'll list some here, nevertheless: Entries can no have custom notes (using the 'note:' tag; Topic tagpages now also show the author names of entries; Srickied entries are now excluded from the RSS feed because they're jsut used as notices at the top of tagpages and don't belong context-less in the feed (there is a better solution planned); Error reporting inside opf the script now includes information on the basis of which the clean-up routine can decide how to handle things differently for different errors and stuff; SBWG now locks directories; There is now a flag that hides attachments to an individual entry that are of a specific mime type, and, you could just read the CHANGELOG file instead of this if you really are interested in these little changes.

It'll probably continue to be slow in the foreseeable future. There are a lot of ideas in my head and several bugs in the code and probably vice versa. But time… not so much.

Edit: Oh, and another thing: I started to test updates and changes that I made to SBWG live on this web site because it's more fun if something breaks every other day.

Comment via email

Alternative Operating System: MenuetOS and KolibriOS

This entry is referencing the entry 'Alternative Operating Systems'.


This is a really interesting one. Or two. I'll start with MinuetOS. Written in Assembler for 586 systems, open source, very impressive, performance- and size-wise. Including the included applications it fits in 1.44 MB. The boot time on my Core2Duo isn't easily measured because it's completely done before my monitor adjusts the resolution from the boot menu to the desktop. But when I chose the same resolution it uses for its boot option screen, I learned that it boots up completely pretty much instant even if the monitor doesn't have to switch modes. A guess writing 100 % in Assembler makes this possible. Very promising software, but a small community. The developers have been very dedicated when the 32 bit version was still under active development. So it is very stable, packed with useful little applications, especially for development and debugging, but also for daily use and casual gaming. This 32 bit version is not actively developed anymore.

There is a 64 bit version, which is not open source. I'll mention the reason in the paragraph after the next paragraph. It's where the development of MenuetOS is happening nowadays. I don't know how far it has changed since the 32 bit version. I didn't try it, because I'm looking for a 32 or 16 bit system. So, the source is not available, but the information available should be suffice to write drivers and applications for it. Edit: I've tried the 64 bit version briefly. Since there has been years of relatively active development between the last (pre 1.0) 32 bit version and the latest 64 bit version, the changes and advantages are very noticable. If a closed source OS is an option, the 64 bit version is surely what you'll prefer using.

There is a CD image of ~ 22 MB of additional applications that I didn't really try. But it's worth mentioning that there are more than the very basic applications available. There's a media player, even some networking tools (FTP, telnet, but no SSH, as you might have guessed). There is a very rudimentary shell. But it is obvious that the developers' focus was on GUI programmes, as even the ping tool is used by opening a window, entering the target in a text field and starting the ping with a button. Most things worked flawlessly during the time I've tried MenuetOS. But there are a couple of things that may be considered annoying by a demanding user. The most obvious to me was that the mouse is very hard to use. Stopping the pointer in a particular spot takes practice. It seems to drag behind quite a bit. It takes time to do something with a mouse. And when setting the speed slower the pointer sometimes starts moving into the opposite direction. Not completely a matured OS. But many parts are matured and it is usable.


And then there is KolibriOS, a fork of the 32 bit MenuetOS. It doesn't claim to be a fork, though. Its heritage isn't mentioned on the web site. Just once in the web forum by somebody asking about it. Every mention of it in the source code has been removed, but copyright notices have been added by the "new owner". That makes this fork a pretty vile act. I don't know what the motivations behind this have been. It is pretty clear that the KolibriOS developer didn't start KolibriOS from scratch, no matter how much they try to make it look like it. There are people who learn about and get into KolibriOS who don't know where it came from. So, after this fork the developer of MenuetOS has decided to not publish the source code of the new 64 bit version of MenuetOS. I felt it relevant to get into all that because making a decision for KolibriOS and against MenuetOS can be seen as a political statement. (And I'm not saying this in any way as a reference to current international political happenings. KolibriOS is sometimes called "a Russian OS". But people who speak out against using KolibriOS because it's Russian and therefore evil should either produce some sort of evidence, hint or at least rationale for why the OS or its developers have any connection to the war in Ukraine or shut up.)

So, back to the OS itself. It's not fully compatible with MenuetOS. As with previous versions of MenuetOS, some programmes still run, some have problems and many just don't work any more on the new version. I don't know if there are even some programmes left that have run on both systems.

There are still 1.44 MB images for floppy disks being published. But for my first impressions I chose the large image that comes with many more applications. That image is over 130 MB, which is likely mainly due to the applications that are not written in assembler. But still, a multiple of the CD image with additional software for MenuetOS. I'd have to compare them in detail to be able to say why that is. The set of applications that is included in the large KolibriOS image is very good for basic requirements and significanty surpasses what's usually included in OS images. There are editors, file browsers, development tools, quite a few casual games and a few not so basic applications. Some not written in Assembler just for this OS, like DOSBox and Netsurf, others impressively small and fast. Netsurf being the only web browser that's available for the OS makes clear who might want to consider using this OS and who might not.

The whole experience of using KolibriOS was a bit smoother than using MenuetOS. That is, almost everything was perfectly smooth, nothing ever crashed. But, some of the not so basic applications are more resource hungry than what you would expect from an OS written in assembler (which is because those applications aren't written in assembler and probably ported from another platform with functionality as the only requirement). For example, the video player would use hundreds of MB of RAM for the playback of some video files. The whole system would become less and less responsive, even though there were still GBs of RAM unused. I don't know what codex' are implemented and how. But some formats wouldn't play at all, bringing the entire system to a halt until I was able to kill the media player.

The size of the complete KolibriOS image (way over 100 MB, as compared to under 25 MB for MenuetOS) shows how the goal of keeping everything small and fast has been overlooked more and more when porting software to run on KolibriOS. But also that more application have been ported. Those are not part of the OS if you use the normal floppy or CD image. But there is one with everything pre-installed. The fact that those extra applications don't run as fast and aren't as small shouldn't be a problem and isn't a fault of the OS. But the fact that no alternatives have been written specifically for Kolibri might be restricting its use in practice.

The following screen shots are all of KolibriOS.

File Attachments

Comment via email

Alternative Operating System: Solar OS

This entry is referencing the entry 'Alternative Operating Systems'.

Solar OS

Solar OS is a one to few person project. An OS with a GUI with an early 90s feeling. Closed source, if I didn't miss something. There is an API reference, but not much help beyond that. I didn't see a software repository mentioned anywhere. I guess the most likely usage is with your own custom applications or ported software.

Solar OS's advantages are definitely its small size (< 1.44 MB) and how fast it runs (a 386 with at least 8 MB RAM should be enough). I booted it from a USB flash drive (using grub and Syslinux) on an Athlong 64 X2. It was as fast as it could be, of course. Although, movement of the mouse pointer is very laggy with screen resolutions higher than VGA. With HD resolutions it can't really be called usable with a mouse anymore. I don't know if that's a driver issue with my graphics hardware or what. This is not a problem with other systems that use a simple VESA driver.

But, there wasn't much to do to test how well, fast, comfortable, beautiful and error-free everything runs. There aren't many applications included. The things that are included do a good job of demonstrating the OS. There are things like a process manager, a picture viewer, a very simple text editor and other tiny demo and system applications. And there is a help decument, debugger, things like this. For a proper test, I'd wish for more applications to use for practical work. I don't know what exactly. It depends on what you need the os for. Maybe writing your own application would be best included in a test that aims to collect for experience about the OS.

It crashed after less than half an hour trying it out. Because it stopped responding before I made any screenshots and I didn't yet bother to boot it up again, see the screenshots page on the project web site. There are many screenshots that paint a good overall picture of the OS and its GUI.

Comment via email

Alternative Operating System: Visopsys (VISual OPerating SYStem)

This entry is referencing the entry 'Alternative Operating Systems'.

Visopsys (VISual OPerating SYStem)

Visopsys is a real hobby OS created from the ground up. It's very likeable like this. It has a GUI that is kind of a mix of a MacOS-9-style and Windows-95-style desktop. There are a couple of accessories and a limited shell. A very promising OS from what I've seen and read. But also limited in its usability as of now, from my own experience.

I've tried Visopsys 0.91, the currently latest version on the download page. Running it in a virtual machine is recommended because of the limited hardware support. But I think that it is fair to hold an operating system to a standard that requires it to be able to run on real hardware, not on another operating system. I tried it on five computers before I got it to boot. I'm not going to list all the hardware components (I'd have to look up all the motherboards - meh), but the CPUs to get an idea for the age of the system components. First a Core2Duo. It printed bunch of error messages to the screen that I didn't further investigate. Initialisation failed and stopped. Then an AMD K6. I got a message informing me that Visopsys will boot in text mode because of a lack of SVGA support and then it rebooted. The used VGA card is a very old one. So that might be correct. Then I tried an Athlon 64 X2. It did something, the loading bar appeared, then it rebooted. I didn't get anything else out of it. Then I wanted to give The K6 a newer graphics card. But while digging for one, I found another PC with a Celeron E3200 and tried that first. And it worked. So I didn't bother checking the K6 again.

Boot time to live mode is about 3 seconds. Incidently, I also learned something about booting from CD. Booting from any ATAPI CD or DVD drive took many times longer than booting from the same CD in a SCSI CD drive. Like 10 times longer. That surprised me. I didn't think there would be such a big difference. Maybe my IDE cable has a problem or I did something wrong. Anyway, booting from USB or an IDE hard drive was quick enough to not bother to measure how quick exactly (about 3 seconds). Edit: A likely explanation for the load time difference between the SCSI and the ATAPI drives is that the ATAPI drives were all modern, fast-spinning drives that take a long time to spin up before any data is read, as apposed to the old, slow SCSI drives that I have, that allow reading from the disk much sooner.

Installing to a hard drive is straight forward: Optionally choose a language other than English (this also changes the keyboard layout), coose a partition, click a few next buttons, enter a password for the default user account and reboot. There is also a partitioning tool available from the installer. But I didn't find a way go get back to the installer without rebooting. After booting the installed Visopsys and logging in, or after booting in live mode, you get a simple desktop with a few icons and a task bar at the top.

There isn't much to do. As far as I know the included programmes are pretty much all that are available for Visopsys. (Please do correct me if I'm wrong!) There are system settings, a very limited shell with a limited number of commands with very limited options, a few casual games, an image viewer and a few other simple tools. The most useful things included apart from the file browser are probably the text editor, the calculator and the telnet client. There is no web browser and no multimedia applications.

During the time I used Visopsys, nothing crashed or went fundamentally wrong. But I noticed a couple of small things that would need to be sorted out to create a comfortable user experience. The most obvious one is that while dragging, the dragged objects sometimes were lost and dropped too soon. Especially dragging windows vertically has to be done very, very, very, very slowly. It's as if the mouse button had a loose contact otherwise. Another thing I noticed when choosing a new desktop wallpaper. Once the directory in which to look for image files to be used as wallpaper has been chosen, the file names seem to be cached. Image files that I've copied into that directory after that were not listed before rebooting. Little things like this add up to create a bit of an annoying experience.

But I don't want to talk down the state in which the project is in. Many things are working slawlessly and depending on what you need your computer to be able to do, it might even fulfill many of the needs. A web browser is not one of them, though.

I've attached some screenshots that I took. The one where the Snake icon is selected. should have a window with the Snake game in it as well. I don't know why it isn't invisible.

File Attachments

Comment via email

Alternative Operating Systems

There are too many Linux distributions to list and too many Linux-based systems to try all of them out just for fun. There also wouldn't be much of a point to doing this. And there's nothing to say about Windows or MacOS in this entry. But I'd like to write a bit about operating systems not very many people have heard of. Specifically, I took a look at several lesser known desktop operating systems. This entry is like a forword to my coming entries about those alternative PC operating systems.

The less big OSs

There are a few other operating systems that aren't used on as many computers, aren't as well-known as the big three (Windows, Linux, Mac OS) and their derivatives, but are still important for their use case or niche. There's the extended family BSD, MINIX, the PlayStation system and many other Unix-like systems, there's Illumos and other actual UNIXs, a variety of DOSs and many even less widely used OSs for small niches. Those all deserve an article. But this is not one about any of those.

The discontinued ones

There are many UNIXs and Unix-like operating systems that aren't actively developed or not even officially supported anymore but still in use in various industries. (Never touch a running system!) There are many old systems that are still sometimes used by retro computing fans, users with nostalgia attacks and people who just never updated their machines since the 80s or 90s. I'd like to write an entry about those systems. But not right now.

The unnoticed ones

There's also a huge landscape of operating systems on embedded systems that are not primarily seen as computers, such as DVRs, cars, household appliances, toys, parking meters and many many industrial tools and machines. An article about how this landscape of proprietary in-house systems turned into a stable of Linux systems would also be worth writing. Or one that takes a look at some sleek systems, from tiny, incredibly efficient environments for 90s microcontrollers to larger systems like Palm OS. But my motivation for this entry right here is about something else.

The interesting ones

And there are operating systems that don't fit any of the beforementioned categories, but still have a reason to exist or at least had a reason to be made at some point. Independently developed OSs for personal computers that emerged from a single person or a small group of computer enthusiasts as learning projects, to prove a point, or as a recreational coding project. Those are the OSs that I'm interested in this entry.

For a long time I thought that such operating systems don't exist, don't reach a state in which they are worth checking out or aren't shared publicly. I did wonder why nobody seems to write alternative OSs just for the sake of it. Maybe the landscape of existing OSs and the tiny adoption of any OS that isn't one of the big three (or four, or five, depending on where you make the cut) takes away any motivation to start yet another small OS from people who would otherwise pursue such an idea, I thought. But it turns out that I didn't look closely enough to find them. There totally are working alternative operating systems that were made for the sake of it, despite Linux satisfying all requirements of the project's initiators in most cases. Many of them may have 0 to 1 users and some of them may have never and may never be used as anybody's main OS. But some of them are very interesting systems. I'd like to point out a few of those.

My initial intention with this entry was to write a paragraph or two about one or two handful of OSs. But I found that there is more to write and more projects to share about this topic for several different reasons. I will write separate entries about a dozen alternative operating systems when I find the time to check them out myself. I'll use the category Operating Systems for these entries. Since I found more than I thought I'll restrict myself to testing only systems that check the following boxes:

  • is actively developed/has received patches in the last 12 or 24 months or is in a state that seems satisfactory for daily use as a desktop operating system at least for some use cases
  • has a working installation or live image for x86 or x86_64 CPUs available
  • is not a distribution or variant of another system
  • can be considered or used as a stand-alone desktop operating system (no alternative UIs for other OSs or cloud based systems that need a modern browser on the local machine to be used)
  • is freely (at least as in beer) available in full (not just as a demo for a commercial OS)
  • boots on my test system (If I can't make it work, I probably won't mention it.)
  • Those are critera that I thought of and wrote down after searching and finding most of the projects I'll write about and after deciding which ones I find interesting. And I might ignore or change those criteria further when I feel like it. They are here just to give an idea on what sort of projects I'll pick out and write about.

    My impressions/conclusion so far

    There are more alternative desktop operating systems than I expected. I thought after the 90s the landscape has become very flat. But development of a number of commercial and non-commercial operating systems went on for much longer. There have been many large projects I had never heard about. Some of those have been officially ended over the years (like eComStation and Syllable Desktop), others are still worked on (like Redox, MenuetOS and MorphOS). I stumbled over so many names of OSs that are in a state in which they're not really usable as a daily desktop OS, that had been published on some now offline website or that have been discontinued years ago. I thought I'd try out most of what I can find and write an overview of the alternative desktop OS landscape. But that would be a project in it's own that would be huge and take far more time than I want to invest in it. Many names worth mentioning have not been mentioned here and many cool projects also won't be mentioned in any of the articles to come. For example I ignored commercial OSs, like ArcaOS. I just don't want to pay 129 $ just to test a system that I'm likely not going to use.

    I can already, after having only briefly tested a few systems, say that there are usable, stable systems that hardly anybody has heard of that are as good as any commercial OS from the 90s. That's good enough for most desktop users. Each with their own set of features and unique selling points, there are real decisions to be made when selecting an alternative operating system that go beyond the questions one asks when selecting the next Linux distribution during distro hopping. I am happy that there are more than one or two systems in a usable state that focus on supporting old hardware and/or using less hardware resources than we got used to with Windows, Linux and MacOS. Whether you're looking for something to run comfortably on an 80286 or something that runs ridiculessly fast on a modern 64 bit system. There are systems to choose from.

    Comment via email

    SBWG 0.10.7

    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.

    Comment via email