Ky was written to use fetch from the beginning, whereas Axios tries to adapt itself to fetch, which doesn't always work well. We also have much better TypeScript support, including built-in schema validation with type inference.
local appHotkeys = {}
local function remapAppHotkey(appName, fromMods, fromKey, toMods, toKey, delay)
if not appHotkeys[appName] then
appHotkeys[appName] = {}
end
local hotkey = hs.hotkey.new(fromMods, fromKey, function()
hs.eventtap.keyStroke(toMods, toKey, delay or 0)
end)
table.insert(appHotkeys[appName], hotkey)
end
local appWatcher = hs.application.watcher.new(function(appName, eventType)
local hotkeys = appHotkeys[appName]
if not hotkeys then return end
for _, hotkey in ipairs(hotkeys) do
if eventType == hs.application.watcher.activated then
hotkey:enable()
elseif eventType == hs.application.watcher.deactivated then
hotkey:disable()
end
end
end)
appWatcher:start()
-- Remap app hotkeys
remapAppHotkey("Finder", { "cmd" }, "q", { "cmd" }, "w", 0.5)
... etc ...
Any particular reason for that? Are you using specific Linux APIs?
Just to clarify, this looks like a super helpful utility, something that I would personally use. The issue is that I noticed the installation instructions include a link to a prebuilt binary hosted on your website. Without providing access to the source code, you're asking users to trust executing an unknown binary on their system.
I no longer use GitHub for original projects. Source for fftool isn't public yet but I understand the concern — running an unaudited binary is a real ask. My site leans toward educational, so that people consider building the tool from the instructions in the article. I may host the source on the site as a zip or tarball at some point so people can more easily build it.
As for Linux API - TIOCGWINSZ via syscall.IOCTL to get terminal dimensions.
Why Linux and Go - Linux is the only OS I use. I like Go because it produces a single static binary with no runtime dependencies. Thanks for your interest.
This is not what Liquid Glass actually looks like on first-party macOS applications. This needs way more blur and opacity to match even the control center widgets.
A few days ago I built https://github.com/overflowy/parallel-rsync to scratch my own itch: I realized I could just launch multiple rsync instances in parallel to speed things up.
HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.
I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only.
There are things that HTML could do, and should be doing, that is not done or not yet possible simply due to hype and trend from browser vendors. We could continue to polish HTML + sprinkle of Javascript to its absolute maximum before hitting JS Apps. Right now this is far from the case.
Actually, I do think that. Wouldn't it be lovely to have an image format for truly enormous images and have the browser request only the chunk currently visible? It could just be a container format with jpg's in it. Let the file system figure out that x/y means tile number 56436.
You could provide multiple image versions for zooming to get to the TB scale.
Computers are really good, performance is astonishing, no reason why we should never be able to use a TB size image. Never is a really long time.
Have epic panoramas, detailed scans from paintings, extremely easy game design and maps that just work.
Hey the email services has just proved you could offer better than Gmail experience with HTML + small dose of JS. Another example being the new FE on Github.
At the end of the day it isn't really the tech that is the problem. Is how people use the tech. And for thousands of different reasons keeping it simple has always provided better experience evaluated on the whole.
Github's old frontend was mostly HTML with a bit of JS, their new frontend is react. The old UI had its bugs, but it was much better than the react version in my experience. I still commonly find the UI out of sync with itself requiring a reload, but now I also frequently wait for the page to load and viewing large diff's is a performance nightmare.
Not really. I used the HTML version for well over a decade and it was absolutely fine. I guess if you need fancy animations, maybe that doesn't suit you, but I came through Pine and Eudora and Gmail HTML was a million times better than both of those and entirely sufficient for a media that dates back about 50 years.
I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript.
The core idea with htmx is that you transfer hypertext with controls and structure built in, not just a JSON blob that requires additional context to be useful.
I have just shipped a very useful and interactive app surprisingly quickly for my customer using just htmx with a little Javascript.
It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript.
All the http verbs.
Decent html input controls
What else?
Depends on how complex it is meant to be. Just like many wordpress sites that could easily have been static websites, many javascript heavy sites could have easily just have been using htmlx.
If your need really, goes beyond what htmx offers, then you may need Javascript. But in my experience people tend to use the tools they know for their job, not the tools that would be best suited.
FYI, it's easy to cache the html output of a WordPress site, resulting in essentially a static site with graphical admin, page builder, and all the other bells and whistles.
reply