Nostr notes by Screwtapello

I've been enjoying some Fancy Tea I got for Christmas. I ...

2026-01-21T03:58:11+01:00

I've been enjoying some Fancy Tea I got for Christmas. I don't know much about Fancy Tea, but my impression was that black tea is generally served with milk, and green tea or things with lemon do not go so well.

So it's weird to me that the Fancy Tea with oolong (approximately black tea) specifically says "serve without milk", but the Fancy Tea that includes green tea, lemongrass and lemon balm says "serve with milk if you want".

(yes, I know that lemongrass and lemon balm aren't actually made from lemons)

This is the bit I've actually been working towards. As I ...

2025-08-27T16:16:50+02:00

In reply to nevent1q…qu2d
_________________________

This is the bit I've actually been working towards. As I think I mentioned before, on the 42S some buttons have a shifted function with a shaded background. Those functions open a menu, rather than performing an action immediately (a bit like the "..." suffix on menu items in GUIs). In previous screenshots, I used a black background, but that always seemed too high-contrast and eye-catching, so I was looking for something less blatant.

This was one of my first attempts, but trying different design ideas by painstakingly redrawing all the buttons in GIMP was just too tedious, so I've spent months writing this tool to automatically lay out a keypad, so I could test a bunch of different ideas quickly.

And now I have that tool, and I've tried a bunch of different ideas, and I still like this one best.

(I still appreciate the tool allowing me to quickly adjust the horizontal and vertical spacing)

has a small-but-flexible website engine called "kiki" ...

2025-08-21T11:12:27+02:00

In reply to nevent1q…qzja
_________________________

has a small-but-flexible website engine called "kiki" that seems like a nice compromise between "designed by somebody with taste" and "it's possible for other people to extend", which seems important from a permacomputing perspective.

https://tomodashi.com/kiki

I didn't realise Microsoft had leaned so hard into custom ...

2025-08-12T05:10:46+02:00

In reply to nevent1q…uu06
_________________________

I didn't realise Microsoft had leaned so hard into custom title-bars in the Win3.1 days. I assumed that was an Office 95 affectation.

Even less obvious than that, I changed the way the corners of the ...

2025-08-06T11:13:05+02:00

In reply to nevent1q…qu2d
_________________________

Even less obvious than that, I changed the way the corners of the buttons are drawn. Although I originally copied them from a screenshot of System 6, I was recently playing with System 6 in an emulator, and noticed that the buttons looked a little bit different.

On Windows 3.1, the borders of a button are always 3px thick, so the corners are always the same size no matter what size the button is.

On System 6, buttons have rounded corners, where the radius is calculated from the button size. So a very small button might be drawn with a 1px or 2px corner radius, but a very large button might have a 50px corner radius.

With Decker's font metrics, I'm generating 20px buttons, so I changed the corners to reflect the border-radius used by the original System 6 buttons at that size.

A number of changes since the last post: - I added more room at ...

2025-08-06T10:50:31+02:00

In reply to nevent1q…afs0
_________________________

A number of changes since the last post:

- I added more room at the top of the grid, leaving room for annunciators and the display
- we now draw the grid of "pressed" button images beside the unpressed ones, as Plus42 expects
- Not shown here, but the "layout" tab now contains (most of) the skin layout declarations that Plus42 requires
- The "Export Canvas" and "Export Layout" buttons at the bottom offer to export the contents of those tabs. If you save them with the same basename, but ".gif" and ".layout" extensions, you'll have a valid Plus42 skin!

After a little confusion and a lot of yak shaving, I now think ...

2025-07-21T15:02:53+02:00

In reply to nevent1q…wy2t
_________________________

After a little confusion and a lot of yak shaving, I now think I've ironed out all the issues I had in text measurement and rendering. There's no invisible whitespace pushing things to the left, the "0.5px" rounding errors that come from centering text are no longer compounding, and I even made it round pixel coordinates *right* instead of *left* to compensate for the visual weight of capital letters.

This is a little unfortunate for the "Backspace" key, whose label is uniquely right-heavy rather than left-heavy. But I'm going to have to fix that manually is an image editor afterward, because I think I've automated about as much as I can.

Maybe next I'll be able to iterate on coming up with button artwork that looks nice.

Out of curiosity, where did you get authoritative cycle counts?

2025-07-20T09:57:11+02:00

In reply to nevent1q…n2qa
_________________________

Out of curiosity, where did you get authoritative cycle counts?

Tonight I finally got around to investigating the button-spacing ...

2025-06-19T17:23:05+02:00

In reply to nevent1q…sdva
_________________________

Tonight I finally got around to investigating the button-spacing issue.

Turns out that in #Decker a font has a "space" value that controls how many pixels are left between each character. If you ask Decker to measure the dimensions of the string "zzz", you'll get a width that is three times the width of the "z" glyph, plus three times the "space" value. If you are assembling a line of text, that's great - you'll wind up with even spacing no matter how many chunks the text is broken into. On the other hand, if you are trying to render a short label, the extra spacing can be an appreciable proportion of the total length. If you're trying to *centre* the label, that extra width makes everything subtly unbalanced.

So now whenever I measure text, I take care to subtract the font space value from the result.

I think there's still some source of unevenness I haven't ironed out; the "View" button on the second row still looks a bit odd. But if you flip between these images and look at the "7" key, you'll see the newer one looks better.

I finally wrote the code that combines the "button ...

2025-05-20T15:35:01+02:00

In reply to nevent1q…mhkx
_________________________

I finally wrote the code that combines the "button definitions" and "button grids" and "button shape" data to draw the actual Plus42 keys graphic.

My first attempt is not pictured; some of the table rows that put a button in a grid used a numeric button ID, while the table rows that define buttons use a string button ID. As a result, when I joined the two tables, half the buttons failed to show up.

The two big problems here are that the numeric keypad buttons are vertically shorter than the others (they should be the same height) and the keypad grid should be aligned with the right-edge of the main grid.

After that, I don't like how some of the text is centered within each button (check "View", second from the end of the right-hand row). I bet there's some spacing I've forgotten to account for, or double-counted.

You might also notice a "Back" button below the grid item ...

2025-05-01T13:21:10+02:00

In reply to nevent1q…zmh0
_________________________

You might also notice a "Back" button below the grid item list. Although Decker has a "Card" menu that lets you flip between cards manually, and even a "Card List" dialog that gives you a list of cards with thumbnails, it seemed more in the spirit of Decker and Hypercard generally to have the first card in the deck have buttons to take you to the others, and each card to have a "back" button. Maybe it's a bit superfluous, but I've already been using it, and it was super-easy to set up.

Another day's work, and now I have a function that renders a ...

2025-04-19T12:03:16+02:00

In reply to nevent1q…0x7t
_________________________

Another day's work, and now I have a function that renders a custom button. Now there's four button templates at the top-left, for every combination of "normal vs. pressed" and "the shifted function executes a command vs. the shifted function opens a submenu".

In the test area at the bottom right, I can type a label (that appears on the button's face) and a shifted label (that appears above the button). The button automatically sizes to fit the longer of the two strings (respecting the configured margins around each string) and keeps the shorter string centred. There's also a checkbox called "Menu" that marks the shifted function as opening a submenu, and clicking on the button displays the "pressed" version.

I'm a little bit alarmed that so many inputs are required to render a button, but it *is* kind of cool to have them all in one place, and to get immediate visual feedback after changing each one.

It does make me wonder what a tool closer to the Unixy end of the ...

2025-04-15T15:14:37+02:00

In reply to nevent1q…2q84
_________________________

It does make me wonder what a tool closer to the Unixy end of the spectrum ("mechanism, not policy") might look like, but I can't fault the guy for having a clear aesthetic vision and a determination to limit scope creep.

I think the model for sharing data between cards is that you put the data in a field, then you can access it from anywhere with `deck.cards.cardname.widgets.fieldname.value`. If you don't want it to be exposed to the "user", you can make the field invisible, or just stick it on a "global variables" card that no other cards link to. This is a bit like, on a spreadsheet, hiding your data in the ZZ99 cell.

For a Product, that's not enough, you need to keep the implementation hidden behind the interface. But I don't think that's what Decker is going for; one of the taglines it shows at startup is "an interactive sketchbook", and I think the Brutalist exposure of the inner workings is part of the point.

I'm probably not going to make Decker my primary development ...

2025-04-15T10:59:19+02:00

In reply to nevent1q…0x7t
_________________________

I'm probably not going to make Decker my primary development environment for everything in the future, but it's been an interesting ride so far and I'm glad I gave it a try.

Here's how far I got after a few hours' messing about. ...

2025-04-15T10:58:23+02:00

In reply to nevent1q…gdhm
_________________________

Here's how far I got after a few hours' messing about. Although Decker has a "canvas" widget, it's really for code to draw on, rather than the user. However, the user is allowed to draw directly on the background of each card, so on the left I have little boxes that represent the images I want to use for buttons.

On the right are a bunch of fields - the "Normal" fields describe the size and location (on the card background) of the "normal" image of the button; the "Pressed" fields describe the location of the "pressed" image (it's assumed to be the same size). Below that, we have margins around the button that describe which parts of the image can be stretched to fit around the text that must fit within it. Then formatting: text on a normal button is rendered in colour 47 (black) while text on a pressed button will be color 32 (white), and the button label should be drawn with the "menu" font.

At the very bottom, the "Test" pane shows the resulting button drawn around the text "Hello". Whenever I change any field on the right, the test pane redraws to take my changes into account, so I can very quickly tweak all the settings to get to a button I like. The actual button drawing is in a separate function so I can re-use it to render the entire Plus42 skin later.

So I created a deck with the intention that it would just contain ...

2025-04-15T10:47:25+02:00

In reply to nevent1q…f5f5
_________________________

So I created a deck with the intention that it would just contain the widgets and resources I needed to render the calculator skin, and then I'd just automate it with Lilt. But as I started messing around, I got a better idea of how Decker *wants* to be used.

I'm not sure what I expected; maybe something like Visual Basic, which is just a regular programming language except it has a graphical editor for some of its data structures. Turns out it's a lot closer to something like a spreadsheet: if you want to do a calculation, you plop down some input fields and an output field, and write some code to calculate the output field when the inputs change. It's not a template that gets instantiated when you compile and run, that's the data - if you change the value in an input field, it stays changed forever.

If your program has a bunch of data structures it needs to work with, that will persist from one invocation to another, instead of writing a bunch of constants in a header file, you plop fields on a card and type the data into them. As a result, writing a program *is* creating a GUI for it. Maybe not a polished GUI, maybe not the one you'd make if you could wave a magic wand, but it lets you describe, arrange and annotate things much more fluidly than traditional plain-text source.

Unfortunately, it turns out there's some significant ...

2025-04-15T10:34:54+02:00

In reply to nevent1q…0vad
_________________________

Unfortunately, it turns out there's some significant limitations to Decker, and Lilt even moreso. I'm sure most of these are deliberate, to keep Decker's API easy to learn and implementation easy to maintain, and to stick firmly within the "ditherpunk" aesthetic it's going for, but they caught me by surprise, so I wanted to make note of them.

- Although Lilt can do everything Decker can do (you can literally load a Decker deck, send it events which can trigger arbitrary code, and read back the results), most of that functionality is not available to Lilt itself. For example, in Decker you can plop a Canvas widget on a card and then write code to manipulate it, but you can't create a "headless" Canvas widget in Lilt, short of loading a deck that already has one.

- Although GIF files are limited to 256 colours, on import Decker dithers them to black-and-white, or posterises them to a 16-colour palette. Lilt can read GIF files, but it's even more limited - it only supports Decker's default 16-colour palette, it doesn't let you choose a different one.

- Like widgets and palettes, fonts are only available within the context of a deck. Since my whole goal was to make an image with text labelling buttons, this was a show-stopper.

Then I remembered I've been wanted to look at Decker for a ...

2025-04-15T10:16:56+02:00

In reply to nevent1q…5nkk
_________________________

Then I remembered I've been wanted to look at Decker for a long time. Or rather, since I wasn't super-interested in a GUI development environment, I wanted to look at Lilt, the command-line interpreter for Decker's scripting language. It has functions, it can read and write GIF files, let's go!

https://beyondloom.com/decker/

I've been messing around with a Plus42 skin just as a design ...

2025-04-15T10:14:29+02:00

In reply to nevent1q…zqry
_________________________

I've been messing around with a Plus42 skin just as a design exercise, but despite the handy web-based tool above for annotating a skin image, I got heartily sick of making a minor change to the layout and then having to adjust the size and spacing of all the buttons, and trying to recenter the text in each one. This seems like an excellent job for automation!

But what tool to use? Browsers are very flexible, but they make it really difficult to get information *out* of them. I looked at https://love2d.org/ but although has good support for graphics and interactivity (it's a game engine) it doesn't support reading or writing GIF files, while Plus42 *only* supports GIF files. Sure, I could add a conversion step, but I'd rather not.

A free download of a password-protected zip file. :/

2025-04-02T02:25:38+02:00

In reply to nevent1q…ul33
_________________________

A free download of a password-protected zip file. :/

Free42, the Free Software re-implementation of the classic HP 42s ...

2025-03-31T09:54:03+02:00

Free42, the Free Software re-implementation of the classic HP 42s RPN calculator, supports using custom skins, a bit like WinAmp skins but more complex - instead of just a bunch of bitmaps, you get to define the size and location of each button and graphical element.

I have discovered that it its parsing of the layout file is not very strict, so I can wrap some HTML, CSS, and JavaScript around it and get a polyglot file that I can load into Free42 to test, and also load into a browser to visualise the coordinates as I edit them.

(the attached screenshot depicts a skin for Free42's slightly more capable cousin Plus42, but the skin files are interchangeable)

#free42 #hp42s #hpcalc

Makes me wish Decker had a native Android runtime. ...

2025-02-15T10:46:37+01:00

In reply to nevent1q…h9wy
_________________________

Makes me wish Decker had a native Android runtime.

https://beyondloom.com/decker/

I'm watching Bill Atkinson talking about 25 years of ...

2025-02-15T10:38:17+01:00

I'm watching Bill Atkinson talking about 25 years of Hypercard and being simultaneously impressed and depressed. I've definitely felt the joy of making a little software widget that did exactly what I wanted, and also the frustration that there's not really anything like that today—at least not without a custom build and deployment system, a quarter-gigabyte runtime, and ten-second startup.

https://dialup.cafe/@vga256/114004724719847054

Good luck with finding the font! For a completely unknown ROM ...

2025-01-25T01:14:58+01:00

In reply to nevent1q…lm45
_________________________

Good luck with finding the font!

For a completely unknown ROM image, you might want to start with a tool that shows individual bits in the dump, and lets you change the start and wrapping width to look for patterns that line up. If you happen to already know the dimensions of each character, that'll help a lot.

I don't have a complete answer, but I think part of the ...

2025-01-23T02:04:11+01:00

In reply to nevent1q…z4qp
_________________________

I don't have a complete answer, but I think part of the answer is "friction". I think the lesson of the original Usenet, email, Twitter, and Facebook is that if you allow any person in the world to effortlessly communicate with any other person in the world, what you get is a whole lot of noise. Even systems like Reddit have problems with "brigading" where, because somebody with a Reddit account can interact with any subreddit at any time, people in one group can talk amongst themselves and decide they're all going to visit some other group and harass them.

At the same time, it's incredibly valuable to be able to communicate with and learn from other people with different perspectives and experiences, and not to be discarded lightly.

And so, friction. Don't make communication impossible, just put up some hurdles to clear. Maybe that's rate-limiting for sign-ups or posts. Maybe that's an "enforced lurking" period where you have to spend some time reading before you can post. Maybe that's a "sponsor" system where a new member must be invited by an existing member of good standing. Maybe that's a sign at the entrance of the alleyway saying "no tourists". Maybe every tomo community should be able to choose their own.

I don't know what the correct answer is, or if there even is one, but I'm pretty sure friction will be part of it.

Incidentally, from that screenshot we can demonstrate that ...

2025-01-18T06:30:27+01:00

In reply to nevent1q…xru0
_________________________

Incidentally, from that screenshot we can demonstrate that LGR's VT320 has firmware v1.1, since the bottom of "t" is slightly curved. On firmware v1.2, it's a crisp right-angle.

I found some close-up shots of a real VT320 in ...

2025-01-18T06:29:20+01:00

In reply to nevent1q…q9hg
_________________________

I found some close-up shots of a real VT320 in https://www.youtube.com/watch?v=RuZUPpmXfT0 at 9:31.

You can *just about* see a gap in the top scanlines of "r" and "n", and between the bottom of the bowl of "g" and the stem.

Looking at the same text in the font extracted from the firmware, we can see that those gaps are 1px wide, so I'm pretty confident it didn't use pixel doubling.

I don't think that applies to the VT320. For one, it's ...

2025-01-18T00:38:31+01:00

In reply to nevent1q…g66d
_________________________

I don't think that applies to the VT320. For one, it's not mentioned on the page. For two, the VT220 glyphs are drawn with single pixel lines and need to be doubled to be legible; the VT320 glyphs are already drawn with two pixel lines.

I'd love to see a close up picture of an actual VT320's textual output.

When I was a kid, I played a game called Keen Dreams — a game ...

2024-10-31T12:25:28+01:00

When I was a kid, I played a game called *Keen Dreams* — a game in the Commander Keen series that Id Software did not publish through Apogee, so it didn't get an official number. Keen gets sent to bed because he refused to eat his vegetables, and winds up in a nightmare facing all kinds of vegetable-themed enemies. The "BROCOLASH" is clearly a head-banging broccoli, the "TOMATOOTH" is just a tomato with teeth, etc. However, there's one enemy I still don't recognise, FRENCHY.

I was going to guess "candy corn", but the colours are wrong and that's not really a vegetable. It might be "French Fry", but what's with the green bit? And all the other vegetables are fresh/unprocessed. And I think it lobs grenades or something? MELON LIPS spits melon seeds, which is very melon-themed; I don't know why a French Fry would lob grenades.

#retrogaming #commanderkeen #dosgaming

The Dig was an iMuse game, I think? So the sound track should ...

2024-10-11T04:26:24+02:00

In reply to nevent1q…lpn5
_________________________

The Dig was an iMuse game, I think? So the sound track should have been MIDI data, and probably designed to loop. Anyone who could extract the data could render it to audio for as long as they wanted.