@prologic@twtxt.net ORLY? š¤©
tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:
With multicolored TUIs, I find it usually hard to immediately tell which button is selected if there are just two.
Indeed, I wouldnāt be able to tell in that example, either. movwin works around that by (mostly) assuming that there is no support for colors at all, so there should always be a way to tell which widget has focus, even without colors. Thatās why it puts brackets around a buttonās label when focused:
The fewer colors you use, the better, I guess. š¤
tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:
Now Iām curious how movwin deals with that. ;-)
Focus handling? I hardly remember, lol. š Did that 6 months ago and havenāt touched it since. Letās see.
The core main loop gets keyboard/mouse events from curses. At this level, the main loop only knows about exactly one widget, so it passes the event to that widget (whatever that is, doesnāt matter ā they all inherit from the Widget base class, it could be a Window, a WindowManager, or an Edit box directly).
The outermost widget is usually a WindowManager. It implements a few hotkeys of its own, like switching to another window. If none of those hotkeys match, it passes the event to the currently focused window.
Same story here: Window implements some hotkeys (like opening the menu bar). If none of those match, then ⦠the magic happens.
Each Window acts as a focus manager. It can descend into its child widget hierarchy and collect all child widgets in a depth-first search. They are collected into a flat list. Each Window then has an attribute _focus_position, which is an index into that list. Pressing Tab or Shift+Tab increases or decreases that index and that allows you to select the next/previous focusable widget in the current window.
Eventually, Window passes the input event to the currently focused widget.
Usually on initialization, the application can ask a Window object to focus a certain widget. The file selection dialog does that, for example, because the ānaturalā focus order would be to focus the Edit box at the top of the window first ā but thatās not what the user wants, the Table showing the list of files should be focused.
If no widget ever feels responsible for handling a certain input event, then thereās a global unhandled_input callback that the application can provide (same as in urwid).
I think thatās it.
Hm, thatās more complicated than I remembered, but apparently it works fine, because I completely forgot about this. š
All I did in the last few months was make new classes that inherit from Widget, like the new Table class or Edit or HexEdit or whatever, and if they want to get input events, then they must implement the methods input_key() or input_mouse().
Does this answer your question? š (I admit that I didnāt exactly understand your scenario, so I just went ahead and rambled about my implementation. š )
tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:
Another thing: With multicolored TUIs, I find it usually hard to immediately tell which button is selected if there are just two. Iām asking people for any relevant information. :-)
tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:
Getting the vim key bindings to work for focus switching in this modal dialog took me forever. Only cursors and (Shift+)Tab are supported out of the box. I absolutely understand that, itās fine. I installed an input handler on the dialog, but the focus always stayed the same.
After two wasted hours, I was in despair to copy the tview.Modal into my own code base. Of course, I had to fix all the private tview field accesses first. But even installing the input handler directly on the buttons themselves did not work. Even though, the handler was definitely executed, the focus did not shift. Forcing redraws as a last resort also did not work.
Looking through all the messy chained input handling, I eventually stumbled across another place in the tview.Form, which is internally used by tview.Modal. This messed around with app focus receptions and input handlers. This gave me the idea to make the tview.Application refocus my modal dialog after I told the modal dialog which button to select. And would you look at that, this did the trick! I havenāt completely figured out what is going on exactly, but I could get rid of my Modal clone again.
I always go through hell with focus handling in tview. Each and every time. It just does not feel natural to me. Complete brainfuck to wrap my head around. The Urwid API felt sooo much more refined, it never was an issue. It just works. In fact, I cannot think of any other TUI library that has remotely the same pain level when it comes to focusing widgets as tview.
Now Iām curious how movwin deals with that. ;-)
Every now and then, I think that I have carefully proof-read my message enough times and hit the āAdd messageā button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up ttās cache. This is rather tidious:
- Recall the
sqlitebrowser ~/.local/share/twtxt/tt2.sqlitefrom my shell history.
- Switch to the āBrowse dataā tab.
- Go to the
messagestable and wait a second or two until itās loaded.
- Sort by the
created_atcolumn twice, so that I get descending order.
- Select the first message, which is typically the one in question.
- Find the āRemove currently selected rowā button in the tool bar.
- Commit the changes.
- Close sqlitebrowser.
So, I finally implemented the removal of messages from the cache in tt. I can now hit d and confirm the removal. Bam! Should have done that ages ago!
https://lyse.isobeef.org/tmp/tt-confirm-message-removal.png
Next up is the search, I think.
Belhod! I present Swag ā Build offline-first web apps in pure Go and HTML.
@movq@www.uninformativ.de Right, at work, nobody gives a fuck. At all. There are so many universes between my definition of quality and everybody elseās.
Letās stop here and enjoy the weekend or vacation. :-)
@movq@www.uninformativ.de Just working on swag š Andā¦.. Building an Offline-first Yarn/twtxt client that has no server requirements (_other than you need to publish your feed somewhereā¦)
@prologic@twtxt.net Hmmmmmmmm ⦠š¤
Hmmmm
@lyse@lyse.isobeef.org Thanks!
On the AI changelog part, though, Iād rather recommend to just not have a changelog at all.
Iām afraid that ship has sailed. You can rest assured that someone who uses AI/LLMs for their code (which is almost everybody at this point) will most certainly also use it for changelogs.
I actually considered not mentioning AI output at all, because this just opens a huge can of worms ⦠š
While going through these terrible GitHub release pages, I also found these āNew Project Contributorsā sections
Yeah, they play on a nerdās pride.
Now, itās just the same auto shitshow with MR titles in a rolling date-versioned release scheme. Itās just our team who has to deal with that, though. I think Iām the only one who is not a fan of it.
Iāve found that this whole situation is much worse at work than it is in the Free Software world. At work, itās literally work and hardly anybody actually cares. We still donāt have all people convinced that writing good commit messages or using good branch names is worth the time. Itās ⦠oh god, no, Iām going to stop here, this is bad for my mental health. š
Suffice it to say, all release notes at work are now AI-generated. Nobody gives a fuck.
@movq@www.uninformativ.de Hahaha, great timing! :-D I love your article and agree with almost all your points.
On the AI changelog part, though, Iād rather recommend to just not have a changelog at all.
Another important thing for me is the deprecation notice section. What do I need to look out for in the future? Should I start to migrate to another API soon? Even right now? Or does it have time?
While going through these terrible GitHub release pages, I also found these āNew Project Contributorsā sections (yeah, for that, they found the time to make a section) annoying. Donāt get me wrong, sure, credit where credit is due. But come on. Soooooo much space for an inefficiently formatted (and also unsorted) list. At least it was easy enough to skip over it.
And then, there are also these changelogs or rather notice documents in general that are infested with multicolored emojis all over the place. My brainās spam filter kicks in and shoves everything to /dev/null immediately. Itās especially a thing at work.
In my previous work project, we also used the Keep A Changelog Format. That was great. You wouldnāt believe how often I resorted back to that document. At least twice a week, often several times a day. I was very glad that we put in this effort. Of course, writing the changelog took its time, but it was worth every minute and more. Reading a many months old item, it was immediately clear. I was our best customer in that regard.
Now, itās just the same auto shitshow with MR titles in a rolling date-versioned release scheme. Itās just our team who has to deal with that, though. I think Iām the only one who is not a fan of it.
I just fixed it.
@lyse@lyse.isobeef.org Now that you mention it, there is some steam from manholes in the winter. š¤ This is all energy that gets lost ⦠I donāt know how much of it, but itās lost. š¤·āāļø
@lyse@lyse.isobeef.org This is the draft so far, let me know what you think: https://movq.de/blog/drafts/changelog/POSTING-en.html
@lyse@lyse.isobeef.org ⦠I am literally writing a blog post about changelogs at this very moment ⦠š I am certainly adding the āāadd Xā and then later āremove Xāā to my list of DONāTs. š
@movq@www.uninformativ.de Next town, they use FernwƤrme from the waste incineration plant to heat the hospital and probably also parts of the neighborhood. I donāt know how good it works, but in the cold months thereās always steam coming out of the manholes along the road through the woods. I very rarely am in this area, but whenever I am, the steam on the side of the road always amazes me.
@bender@twtxt.net Yeah, you absolutely must experience them yourself in person. :-)
Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this āchangelogā is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then āAdd feature Xā, seventeen kilometers further down āRevert āAdd feature Xāā. Fuck you! Donāt include this shit in the first place!
Fits absolutely perfect in the pattern of rapid decline.
I must rip out all dependencies as soon as possible whose maintainers just donāt give a shit.
@apptester@twtxt.net Cool! š My Offline-first Go/WASM + HTMX powered Yarn / Twtxt client is working š
@marcorocco@roccodrom.de such a feast! I had lentils soup, and a couples of eggs with onions in a scramble. Not bad, but not great. Your sounds very appealing!
@lyse@lyse.isobeef.org having seeing, and played with fireflies as a child I envy you. We have none around here. Children have no idea what a firefly is. I mean, they do, but vague, and based on videos and telly.