Entries tagged 'cat:Computer'

SBWG 0.13 Entry created on 2025-11-10 (edited 2025-11-18) Authors: steeph (347) Categories: Bash (31) Code (31) Computer (76) Linux (35) Projects (40) SBWG (18) Scripts (28) Software (52) Languages used: en (248) Topics: Projects → Code → Bash Scripts → SBWG (17) Projects → Web Sites (20)

Wow, has it been more than a year again without publishing a new SBWG version? Another year where I didn't have much energy for things besides work. But I finally worked on it again. It's still evolving a lot. But the list of things I still want to do is slowly becoming shorter.

SBWG 0.13.0 is a pretty stable version again. I've tested it with several sites for a while and I'm now also using it to generate this web site. You can get it from there.

Apart from the almost permanently ongoing task of cleaning up the code formatting line by line because I started out with a mess of tabs and spaces mixed in different circumstances, I find the following changes worth describing here.

File attachments: Image files are now only embedded as a thumbnail and displayed as a gallery if the file type is one of the following: image/avif, image/bmp, image/gif, image/heic, image/jp2, image/jpeg, image/jpm, image/jpx, image/jxr, image/png, image/svg+xml, image/tiff, image/vnd.microsoft.icon, image/webp or image/x-jp2-codestream. Even though not all of them are supported by most web browsers and there are browsers that support formats not on the list, those are the image types that I find widely supported enough to try to display their contents instead of only linking to the original files. If a file attachment is in a subdirectory, the same sub-path is now used on the generated web site, allowing for several files of the same name to be attached to different entries. That is something that is now possible because file attachment now not necessarily need to be named after the entry they are attached to. Their file name does not matter if the directory they are in is named after the entry. For axample: ENTRYNAME, ENTRYNAME-files or ENTRYNAME-images

Since SBWG sometimes changes how certain features work, it is possible (as in thinkable. It's not like SBWG is used by so many sites that there has been an actual example of it.) that a web site created for one version of SBWG is not generating as expected with a newer version of the script. That is why it is now possible to declare in a site's settings file that it may not be generated by a SBWG script newer than a certain version. If your site uses hooks it may be a good idea to use this new feature so that you get a message when trying to use a wrong version of SBWG instead of noticing after a possibly long generation process that everything does not look right. To activate this restriction, simply add a < sign followed by the latest version allowed to the first line of the site's settings file. For example: #SBWG <0.13.0

Accessibility as an afterthought: For some reason I didn't many things wrong from the start when it comes to accessibility. I've always felt that design decisions are and should be subject to my personality and mood. This is why SBWG is only written for Bash (so far) and so many specialty features are the way they are. I guess I've let this policy spill out on decisions like how readable generated sites are. I've never been good with designing web pages entirely on my own. I'm better at implementing CSS than at design decisions. But this goes so far that I've created an image gallery feature (for image file attachments) with modal preview without using any JavaScript. To realise that I had to break some HTML rules and create HTML that is not viewable without a basic minimum of styling (to hide some elements). I am very very slowly drifting off that course of not caring about things like that. As a start, I've changed the layout of web sites generated with SBWG to contain their menu after the content. For a styled site there's no difference (e.g. using the default "elth" style). But in text browsers (and hopefully also screen readers) this means the entire menu with all topics and the whole tagcloud isn't displayed/read before getting to the actual content of a page. To make it easy to access the menu, there is now a "Jump to the menu" link at the top of every page. Another improvement in this regard is inclusion of image descriptions as alt attributes where descriptions are found in the meta information embedded in the image files. SBWG now looks for all sorts of tags that might hold a useful description of an image, or at least a title or keywords. Fields meant for image descriptions are preferred over others that probably only hold inferior information. This should in some cases already generate useful alt attributes. But I know that I'm going to have to actually write those image descriptions for images used on my site. It's a start. Like I said. I'm moving very very slowly on this.

Style set handling: The most recent large change has been the rewrite of everything related to fetching and embedding style sets. I made some minor compromises but simplified some parts a lot. Changes emerging from the re-write include: Style sets can be placed in different directories now. SBWG looks for the requested style sets in the web site's own styles directory as before. If it isn't there, it continues looking in the user's home directory (`~/.local/share/sbwg/styles/`), then in a global styles directory (`/usr/local/share/sbwg/styles/`), then in the styles directory relative to the script file (in case SBWG is used as a portable directory, not installed). This way styles can be provided globally, e.g. with an install script, additional or altered styles can be installed by a user for their own sites and additional or altered styles again can be limited to a single web site. And lastly a stylesheet file can be chosen by path no matter where it's localed. But this file will be its own style set. Special use case, I know. But if you happen to have a use for that feature, there you go. Style files named reset.css are no longer treated specially. It wasn't a requested feature and I never used it myself. If you use alternate styles on your site (which is unlikely enough) and there are style definitions you want to be included in all style sets, simply include them in all style sets. If you want to refrain from using redundant CSS, put that code in a separate file like before with reset.css) and create links for each style set. The result will be same as before but more self explanatory. When using alternate styles on a web site (so the user can select from them in the browser), all non-styling files from all style sets are now being used. Again this is more in line with what you would expect. Although I might change this again later because the way it used to be was more practical. There were good reasons for it. The basic minimum of styling that should be applied to a site generated by SBWG is now hardcoded. If no style whatsoever is requested, a file with those minimal rules is generated and linked on generated HTML files.

Other than that it's mostly code improvements, HTML cleanliness improvements, formatting improvements and UI/style improvements of a tiny nature. But I'm glad I have two of the larger todos - attachment changes and the style rewrite - (almost) done.

Comment via email
Blank Keyboard Entry created on 2024-11-23 (edited 2024-11-24) Authors: steeph (347) Categories: #100DaysToOffload (41) Computer (76) Hardware (15) Keyboards (10) Typing (1) Languages used: en (248)

Some 10 years ago, I picked up a simple USB keyboard from the scrap box of a hackerspace before to see whether it really was broken. It was missing one key, which made me think maybe that's all that's wrong with it. Turns out I can do without the Numlock key and all other keys work perfectly. When I have to press the Numlock key I use a pen. I never had to move another keycap onto it.

My idea when I took this keyboard was to same working tech from being dumped and destroyed and to have a random spare in case I needed a USB keyboard because I only had spare PS/2 and one very cheap and bad 2.4 GHz USB keyboard (if not 800 MHz). But there's something special about it. It's a BLANK keyboard, which seems to be a brand solely marketing keyboards without any markings or labeling on any key. I had heard of them before and thought it's an interesting idea. But I wouldn't have chosen to buy one. At some point I needed a USB keyboard and tried the blank one for a while. Since then I use this keyboard for my desktop PC intentionally, not because I don't have another one. I thought I'd write down my experience in getting used to it and what it did to my typing.

It appears a bit surprising to me now but at my first experience with the Blank keyboard was what I expected at the time. I was using it at an opened laptop with a broken keyboard. And I was very glad to have a labeled reference in front of me. Typing a word or two took ten or twenty times as long because I didn't know what most of the keys were. Well, some are obvious (Return, Escape, Space, etc.). I must have cought a particularly patient time in my life. Because I kept trying to hit the right keys when typing. I also didn't really type long texts on that machine at that time. So it wasn't too much of a dive into label-less typing. There must have been enough moments where I hit the right key first try to motivate me to keep trying and maybe learn to type blindly. When the laptop keyboard had dried sufficiently I was very glad about being able to switch back again. Such a relief. But I chose to go back to the blank one for a while every now and then. There were so many times where I started to type one or half a key to the left or to the right, so I started to produce gibberish, deleted the last few characters, adjusted my hand's alignment a few millimeters and try again. Sometimes (actually still pretty often) it took five or more attempts to hit the right keys. That was how I typed for a long time. When I wanted to type "Foo Bar Baz" I typed something like "Gpp<<<Doo<<<Foo Nar<<ar<<<Nae<<<Nar<<<Bae<<ar Bau<u<u<u<t<t<z", sometimes much longer. That was the period where I was surprised to bring up enough patience to continue. There was pretty much no progress for months.

I'll leave it at that one example. But it was a long time during which I accepted that I often had to type things three or four times. I eventually stopped because I hardly noticed any progress. But when I again needed a USB keyboard and the blank one was the nearest one, I gave it another try. And I was glad about how quickly I got back into it. Now I did notice progress after a few weeks. Maybe the fact that I was off and on that keyboard every other day played a roll in that. That was a couple of months ago. And I am happy to be able to say that I am typing blindly now. Still not without errors. I probably hit a wrong key about a dozon times in this paragraph already. But it's bearable. And I'm not sure how many such mistakes I made before on a labeled keyboard because I never payed that much attention to that. Typing blindly always was something that I always thought of a very nice skill to have but one infinitely far away. Now I look once at the keyboard before I start typing and that's enough. Maybe I wouldn't need to do that on a keyboard with very clear J and F markings. But I doubt it. When I look at the keyboard before starting to type I look for the first key that I want to press, not F or J.

Now that I got that far I will probably continue to get better at hitting the right key at first try more often. Because I noticed that I stopped lookign at other keyboards as well, even with nice large labels or glowing keys. That should give me the necessary training over the next couple of years. Although right now I don't feel like I'm making any progress again.

Comment via email
HelenOS Entry created on 2024-11-23 Authors: steeph (347) Categories: #100DaysToOffload (41) Computer (76) Operating Systems (22) Software (52) Languages used: en (248)
This entry is referencing the entry 'Alternative Operating Systems'.

HelenOS

One of those operating systems that is used for operating system research here and there. I think that's also what it was made for. The last releast was earlier this year, which makes it seem one of the more actively developed research OSs. With the release there are also prebuilt ISO for a variety of platforms including the usual, Raspberry Pi, other ARM platforms and older PCs.

There are similarities to UNIX-like systems but it is clearly not a POSIX system. Basic utilities are included as well as some basic console and graphical applications and demos. I didn't look for any additional software, yet. I'm not sure if I will use this os much more. But by booting flawlessly without any changes and effort, this is one of the more usable OSs I've tried. So I might. It has network capabilities, a basic GUI and TUI, window manager and its own shell.

The GUI is optional. Most applications run in the console mode as well, which is a TUI that mimics the GUI with its start menu. Which is good to have because the GUI is really slow to the point that the mouse pointer is lagging behind.

On my desktop PC neither a PS/2 nor a USB mouse worked. But the touchpad in my old latitude worked fine, including the second set of mouse buttons that work in almost no OS. Graphics mode worked with the appropriate resolutions automatically. Above that I haven't tested any hardware.

There are screenshots in the official wiki.

Comment via email
Alternative Operating System: Haiku OS Entry created on 2022-03-29 (edited 2024-11-15) Authors: steeph (347) Categories: Computer (76) Haiku (2) Operating Systems (22) Software (52) Languages used: en (248) Topics: Software → Alternative Operating Systems (18)
This entry is referencing the entry 'Alternative Operating Systems'.

Haiku OS

Haiku OS is a BeOS clone. I didn't use BeOS back in the day (although I wish somebody would have showed it to me). So I'm not sure, but Haiku seems to be pretty much the same experience. But Haiku is open source, still actively developed and compatible with newer hardware. It ran relatively well on the Core2Duo PC I've tested it on. Except for the included web browser. That thing crashed. For a lot of people whether a desktop OS is usable is decided on how good of a web browser is available for it. Haiku OS Beta 3 looked promising with its WebPositive using WebKit 612.1.21. But at least on the old PC I've tested it on it wasn't usable. It was slower than imaginable and kept crashing after one or two page loads. (The simple included help pages at that. I didn't even feed it something complex, like YouTube or Google Docs.) But I've heard others hat a pretty good web experience with it. At least as long as nobody asks about security. The rest of the system is snappy enough. It's no KolibriOS, but on any x86 or x86_64 from the last ten years it should be as fast as anyone wishes their OS to be and much older computers run it just fine. There seems to be a not so small community of users and developers. Every new Beta that is released comes closer to a desktop OS that has everything that people ask about/for. (Let's not talk about big games people are familiar with.) And because of the growing community and the fact that the 32 bit version can still run many applications compiled for the original BeOS this is not just a small OS with theoretical goals bigger than its community. It's really usable already and it looks to me that it has good chances of becoming more important in the future. I'm not sure if I'd have said that five years ago. It's moving slowly (compared to Windows and Linux), but consistently towards its goals.

Edit 2024: The have been two new alpha releases since I wrote about Haiku here. It is definitely capable of being an everyday desktop OS even though the release candidate's version labels are modest. The biggest change recently has been that GTK3 has been ported to Haiku, meaning that a large number of graphical applications becomes available or portable. Applications that have been written with other operating systems in mind. This has been demonstrated with Inkskape and GIMP. But many more applications will follow, I'm sure. I suspect that this also means that Firefox or some fork of it will be the web browser most people will use on Haiku. It certainly makes it more usable as ther main OS for many people.

File Attachments (4 files)
Haiku_OS-1.png (image/png, 346461 B)
Haiku_OS-1.png (image/png, 346461 B)
Haiku_OS-2.png (image/png, 288045 B)
Haiku_OS-2.png (image/png, 288045 B)
Haiku_OS-3.png (image/png, 260590 B)
Haiku_OS-3.png (image/png, 260590 B)
Haiku_OS-4.png (image/png, 814785 B)
Haiku_OS-4.png (image/png, 814785 B)
Comment via email
Alternative Operating System: Essence Entry created on 2022-03-29 (edited 2024-11-15) Authors: steeph (347) Categories: #100DaysToOffload (41) Computer (76) Operating Systems (22) Software (52) incomplete (24) Languages used: en (248) Topics: Software → Alternative Operating Systems (18)
This entry is referencing the entry 'Alternative Operating Systems'.

Essence

This is one I'm continuasly disappointed to not have been able yet to get running on real hardware. I like what I've seen. But I can't get it to boot, as do others. I don't know too much about the internals of Essence. But it seems to be relatively far in develpment. There is a sleek GUI with tabbing windows in the look of early Chromoium browsers, which looks very inviting, if only I could get it to even try to boot on any computer. The focus has not been on making the OS actually boot on real hardware so far. And unfortunately there has been no release since 2022 and no update to the code for over a year. So I stopped hoping that it might be working soon. I was looking forward to getting to know a knew OS that doesn't take a Unix-like approach and has nice tabbing windows.

(tba:screenshots)

Other new OSs not for real hardware

While Essence is what I created this entry for because I really hoped to be able to try this GUI on real hardware, I'll use the spacce left by the lack of an experience report to mention a few other PSs that look promising but aren't (yet) made to run on actual hardware.

Munal OS

An experimental operating system fully written in Rust, with a unikernel design, cooperative scheduling and a security model based on WASM sandboxing.

TacOS

My from-scratch OS with its own kernel written in C and assembly

TacOS is a UNIX-like kernel which is able to run DOOM, among various other smaller userspace programs. It has things like a VFS, scheduler, TempFS, devices, context switching, virtual memory management, physical page frame allocation, and a port of Doom. It runs both on real hardware (tested on my laptop) and in the Qemu emulator.

Comment via email
Alternative Operating Systems Entry created on 2024-11-03 Authors: steeph (347) Categories: #100DaysToOffload (41) Computer (76) Operating Systems (22) Software (52) Languages used: en (248) Topics: Software → Alternative Operating Systems (18)

A few years ago I became interested in operating systems that are positioned off the main stream; in other words: That are not Linux, macOS or Windows but still usable as a desktop OS. And since BSD is so well known, I exclude it from the list of systems I will write about here, too. I've started to write about alternative OSs over two years ago. But I didn't find the time and energy to actually look at much and write about it at that time. I've decided to start anew with this entry and put my reviews, tests and introductions of OSs under the topic top:Software:Alternative Operating Systems. You may ignore everything that I've previously written about this topic.

Comment via email
F(x)tex Pro¹ X Entry created on 2024-08-03 Authors: steeph (347) Categories: #100DaysToOffload (41) Android (4) Batteries (6) Computer (76) Crowdfunding (4) Hands-On (3) Hardware (15) Keyboards (10) Phones (3) Smartphones (4) Languages used: en (248)

First of all: Look at the title. That's how the name of this device is spelled. I've never, and probably will never, be able to spell that correctly without looking it up.

I've contributed to the crowdfunding campagne in 2020. Various pandamic-related issues, a partly re-design, Chinese lock-down delays, devious shipping-issues and, during the last few years, suspected additional, unexplaned issues caused the delivery date to be postponed uncounted times. More than three years later, I've received my Pro¹ X arrived. That means that I guessed right about the makers not being the worst scum of the earth because the ran off with the money without sendind out the devices that we knew had already been produced. I don't know how this scam should have worked unless they sold the devices again to other people. But that was the general tone to which the comments on Indiegogo had goaded each other over the years.

I wanted a keyboard phone for years. I've had My experience with the Planet Computers devices, which some see as the competition. I've had more hopes for the Pro¹ X being the device I was whishing, searching and waiting for becasue it's keyboard is closer to those of the later slide-out qwerty smartphones, like Nokias N900 and because the Pro¹ X's predecessor, the Pro 1, has been reviewd positively by people with the same preferences as me.

So, the phone finally arrived. And, it didn't work. The battery hasn't been charged in years. It didn't charge. It did nothing electronic. But luckily some other campagne contributor has figured out a way to persuade the phone to charge. Interesting that they decided to send out the devices without knowing how the receipients could use them. Of course, the battery's capacity isn't what it was advertised as. In airplane mode with the display turned off and no app running the battery lasts for just over 24 hours. When used, the battery gets drained respectively quickly. But it works. Enough for a few sentences about my first experience.

The keyboard is not the theoretical ideal my brain has developed in the last 10 years. But I don't think that ideal exists. There probably are keys with a nicer preassure point and a click that feels nicer and is even more reliable. There have been in 2O02. But I didn't honestly expect that in a sub-1000-€ phone. The slide-lout mechanism is as snappy and firm as I've seen it described by users od the previous F(x)tec phone. I hope it lasts at least a few hundret times as long as the one on the Astro Slide.

The camera is fine. Much better than the alibi camera of the Titan Pocket that I'm currently using as my main phone. As it happens, I the week after I received the phone I stayed in the same hotel I was in when I tried out the Astro Slide. So I was able to make the same pointless test photos that I've posted in the Anstro Slide entry back then. (See below.) Okay resolution, mediocre sensore, unreliable auto white balance, usable but not enjoyable under artificial light (of normal brightness).

The screen is nice, which is the absolute minimum one expects in the cheapest of phones nowadays. It's bright enough, has a higher resolution than I need, has noticable colour-shift when viewed at an extreme angle. One edge is rounded, which is a first in my personal phone, but not really something I'll expect to use. It's more than fine. I don't need a display as great as what's common nowadays.

It's the best phone I had in my hands in years. The best for my preferences. If only the battery hadn't been killed by it's years-long storage period, the software would be the only thing I'd have to concern myself with in order to make this my primary phone. The pre-installed Android is very very Google-y. Not to my taste anymore. It works well, as one would expect. Not as buggy as with the Astro Slide and previous Planet Computers' Mediathek-based PDAs. Once I've installed LineageOS and replaced the battery, this may become my favourite smartphone ever. It might finally be the one to beat the Nokia 9300 for practical reasons.

File Attachments (4 files)
Pro1XHandsOn-IMG_20240704_225118.jpg (image/jpeg, 7535497 B)
Pro1XHandsOn-IMG_20240704_225118.jpg (image/jpeg, 7535497 B)
Pro1XHandsOn-IMG_20240704_225238.jpg (image/jpeg, 7967355 B)
Pro1XHandsOn-IMG_20240704_225238.jpg (image/jpeg, 7967355 B)
Pro1XHandsOn-IMG_20240704_225350.jpg (image/jpeg, 9063434 B)
Pro1XHandsOn-IMG_20240704_225350.jpg (image/jpeg, 9063434 B)
Pro1XHandsOn-IMG_20240704_225444.jpg (image/jpeg, 9548019 B)
Pro1XHandsOn-IMG_20240704_225444.jpg (image/jpeg, 9548019 B)
Comment via email
SBWG 0.12.8 Entry created on 2024-07-04 Authors: steeph (347) Categories: #100DaysToOffload (41) Bash (31) Code (31) Computer (76) Linux (35) Projects (40) SBWG (18) Scripts (28) Software (52) Languages used: en (248) Topics: Projects → Code → Bash Scripts → SBWG (17) Projects → Web Sites (20)

I've recently published a new version of SBWG, my web site generating bash script. The time that I'm able to allocate to working on SBWG fluctuated a lot in the last year and when I do work on it, I often just feel like doing one type of thing. So, when that is starting a new feature, all the other types of tasks can take on a pile that takes months to resolve. But eventually I managed to test and stabilise the features that I've added and changed, edited the README file and tried out the new version with real web sites. Well, testing could be more professionel, but it's okay for a hobby project, I think.

It's been well over a year since I wrote a blog entry about what's new in SBWG. This entry goes through the main new things since version 0.11.1.

A big new thing, at least from the view of the author/me, is that certain options where that makes sense now support multiple arguments. For example if you've edited three entries and want to re-generate just those three, you don't have to run the script three times but rather define the entries like this: sbwg -e ENTRYNAME_1 ENTRYNAME_2 ENTRYNAME_3. The same goes for pages, tagpages, entry attachments and galleries. This doesn't just make it easier and quicker to generate just some changed pieces of content. It also allows the usage of shell globbing (like *, ? and […]) and brace expansion ({…}). For example you can now regenerate all entries that are stored in one subdirectory or all entries whose names start with a vertain string of characters. Another practicle use case is to add external entries and/or to the site that are not stored in the respective directories in the web site's input directory. Using option -E/-P on the contents of an entire directory creates HTML files in the web site's output directory that look like any other of the web site's pages, but without integrating them in the structure of categories and other tags.

There is now a way to create a custom menu in the navigation bar without writing any code in the settings file of a web site. By using the new 'menu:' tag type in the header of a page or entry source file, the page or entry will get added to the menu. This allows for a list of pages you want to link to from the site's navbar, or a nested tree of interesting blog entries. The tag can be used similarly to the 'topic:' tag with the main difference that it doesn't add the entry or page to a list of entries with that topic, but rather directly in the navigation bar. In the default style set that is a drop down menu like the list of categories, authors, languages and topics. But it is just an unordered list, so it can be styled like any web site menu.

The default style set has changed a bit over the year. It basically looks the same but it's a bit cleaner now and is split into more file more logically. It will become even cleaner in the future though. It now also makes use of the new possibility to present the list of categories in the navigation bar in the form of a tag cloud. Audio attachments are better to look at now, especially when there are several audio files attached to an entry. Image attachments are can now be previewed in a modal without loading the (large) original file and without leaving the page. This almost gallery-like display is about as far as I'd like to go without starting to use JavaScript in the default styleset. Some parts of a web site generated with SBWG are now collapsible/expandable. The parts with this new feature are: entry attachments, entire entries on tagpages, entire entries on their own pages, the custom menu, the category list, topic list, language list and author list in the navbar and the entire navbar. By default all of those things are extanded upon page lead and collapsible by clicking/tapping on their titles. But you can add a setting in your settings file for each of those types of things to be collapsed upon page load and expandable by cliking/tapping on them.

Another thing that behaves similarly is content warnings. Hiding the content of an entry, or parts of it, could always be done by hand, e.g. by adding a <details> and <summary> tag pair to the body of the entry. But it is now easily possible by adding a warn: tag to the header of an entry. For example adding warn:This entry contains spoilers. to an entry header results in the entire content being hidden behind a collapsed <details> tag. Initially visible is only the summary "This entry contains spoilers. (click to open)". The default style set makes this warning line very visible but dunking it into a strong red. If the entry has attachments, those will be collapsed and their title marked in red, too. Both the entry content and its attachments will be collapsed by default if the entry has a warn: tag, independently of what your settings for those parts is in the settins file.

New special tagpages: If there are entries that have a language tag and others don't have one, 'nolang.html' will be created that lists all entries that don't have a language tags. Similarly, if at least one entry on the blog has an author tag, but other entries don't, 'noauthor.html' is created and linked to from the navigation bar.

RSS feeds are now created for every tagpage. That means visitors can now subscribe to individual topics or categories or authors or languages. It also means a longer generation time for a complete regeneration process. But permanent caching reduces that to an acceptable amount. Other feed formats are still not created because I reckon that writing those will be particularly fun and satisfying. So I want to get to that when more of the less interesting todo bullet points are done.

Many small changes make web sites with different structures than mine cleaner. Empty directories or menu entries aren't created. There are new hooks for the various different new functions and loops which a user might want to hook into. Various changes around the default language being used for RSS feeds and HTML documents in order to abide by the standards. Many bugs around all sorts of things have been fixed. The logging option works pretty reliable now. It may still be completely removed one day because it's a large chunk in the code, makes the script slower when enabled and can now be entirely replaced by redirecting output from the script on the shell level. The new flags 'hideinfeeds', 'noshow', 'nogal', 'noatts' and 'noheader' control how and where entries are presented and which parts are visible. See the README for descriptions of those flags.

Reading these update blog posts shouldn't be seen as a replacement for reading the CHANGELOG file. If you have a SBWG web site and consider updating SBWG, at least check the CHANGELOG for lines marked with ! since your current version. That makes it much much less likely that you miss something that you should change upon updating SBWG. I mean, I don't think anybody except me uses any version of SBWG. But I've always approached this project working as if it would be used by others in order to produce something that is practically usable without reading and understanding the codebase first.

The list of things that I'd like to do with SBWG is still long and includes heavy changes on how content is placed in the website's input directory. I reckon that it would take me something like 10 - 16 years to get there is I would continue advancing through the todo list at the pace at which I have in the last year. But if I would loose interest at any point along this path, I could feel okay for at least have gotton as far as testing and publishing version 0.12.8 because it's getting closer to looking how I want it to look in regards to the results it produces.

Comment via email
Go To Navigation Page
Show/Hide Navigation
Mastodon