Willamin

We do use UINagivationController in our app, so that's no issue.

Crossing the boundary from UIKit to SwiftUI involves instantiating the SwiftUIView, handing that over to a UIHostingController, then presenting that controller. Something like this:

  let myView = MySwiftUIView()
  let hostingVC = UIHostingController(rootView: myView)
  navigationController.present(hostingVC, animated: true)

Crossing the boundary from SwiftUI to UIKit is slightly more boilerplate to write, but it's not too bad. You have to implement either a UIViewControllerRepresentable or a UIViewRepresentable (depends on your needs). Those protocols only needs two functions defined: makeUIView/makeUIViewController and updateUIView/updateUIViewController. For the simplest views and view controllers, you can leave the update definitions empty.

You can absolutely slowly migrate a UIKit project to begin using SwiftUI – it's part of what I've been doing at work for the past 8 months.

The way to cross the boundary from UIKit to SwiftUI or SwiftUI to UIKit (either direction) involves implementing one or maybe two classes/structs and is not too difficult to do.

Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle.

In fact, you can jump back and forth between UIKit and SwiftUI as many times as you like throughout your app's view hierarchy.

The current project I'm working on involves slowly porting an older UIKit+Storyboard app over to SwiftUI, so I'm seeing this in practice every day.

Great point!

I'd then suggest that formatting that always conveys meaning (bold, italics, etc) should be copy/pasted.

On the other hand, formatting that often doesn't convey meaning (font face, foreground color, background color, shadows, etc) should not be copied by default.

A three-way option to system-wide (and per application) configure the behavior for control/command + x/c/v would be nice:

    * smart copy/paste (what I just described) as the default
    * copy/paste as plain text
    * copy/paste with full formatting

> simple statically typed scripting languages for generating YAML/HCL/etc configs

Do you actually want a statically typed _imperative_ language for generating configs?

Or do you want a sane, statically typed, declarative language for configs?

I agree that it'd be cool for browsers to add a per-site color-scheme toggle in the UI.

While it does lack in many other areas, Safari on MacOS has a wonderful interface for per-site default behavior for: automatically using reader-mode, allowing permissions (microphone, etc), setting page zoom, etc. This would be the perfect place for per-site overrides of the system light/dark mode.

Something I don't see talked about often is a variation on the "checkbox hack": using radio groups. The checkbox hack gives you a nice binary piece of state without JS, but using radio buttons gives you any number of options that you need.

For a light-mode/dark-mode toggle that doesn't use JS, I would suggest using radio buttons. It's really a situation that calls for 3 distinct states: follow the system preferences, override to force light mode, and override to force dark mode.

---

I totally agree though that JS should be used to augment, especially to save the state across page loads. At best, Firefox will autofill radio buttons across page reloads within a session, but that's not sufficient enough.

I was recently considering the approach of keeping this transient state in the URL somehow: the only place that makes sense (for CSS to access it) is in the fragment. Rather than toggling a checkbox or radio group, link to a fragment of the page. This gets tricky with multiple pieces of state though; you have to permute all of the state on the page into increasingly long (or unreadable) fragments (eg. `example.com/my-page.html#color-scheme-override-dark-and-sort-by-title-asc`). However on the plus side, you get state for free _and_ can share your set of state with other people (which makes sense for page state like sorting and filtering, but not so much color scheme overrides).

I recently discovered that Safari on both iOS and MacOS lack the ability to use a custom search engine. You're stuck with the few options Apple has hard-coded into the app.

A few Safari extensions exist that try to skirt this limitation by watching your browsing for a Google, DDG, etc search. These extensions grab the query from those search engines then redirect your tab to your preferred custom search engine.

Of all of the missing common features to implement, I feel like custom search engine is incredibly simple: * User entered string for search URL with some marker for "the query". * User entered string for the label of the search engine. * Option to edit/delete already entered custom engines. * In the search engine selector, also allow users to choose any custom engines.

Sure, there are specs out there for making this a cleaner customer experience. For instance, OpenSearch lets web sites tell browsers if the website is a search engine, and what query string pattern should be used with it. But at the bare minimum, Safari (on iOS and MacOS) should implement the simpler "just enter a query string pattern" feature.

I use a seed phrase for wallets that I care to backup. I print or write the phrase on paper, then store it in a safe physical place.

This has the added benefit that you can trivially create offsite backups as well: print or write another copy.

If you're on MacOS, there's a third party program that's relatively simple to use that does exactly what you've described: Little Snitch

Maybe FileCoin is what you're looking for? https://filecoin.io

Looks like a previous version was mostly a Clojure DSL, but the latest major version no longer is. There are variables and other useful features we know from other programming languages that aren't mentioned on the landing page.

Of course there are also varying definitions of what a programming language is. For instance, I consider CSS to be a programming language, but I know many people disagree with that position (and that's okay). I personally don't think that a "programming language" must be a general-purpose, turing-complete language. Alda seems to be a non-general purpose, turing-incomplete language. At this point though, we're maybe getting into semantics a bit.

Syntax change: https://github.com/alda-lang/alda/blob/master/doc/alda-2-mig...

Wouldn't you be able to spread your digital IDs out between multiple devices?

Yes, that would be more expensive if you don't already have multiple devices. I'd wager than many people here on HN (who are in the Apple ecosystem) have at least 2 devices on which they could add payment/IDs/access (Apple Watch, iPhone, iPad, MacBook).

Excellent point! I was mostly referring to the issue of loss or theft of a single device containing all forms of payment/ID/access not being that different from loss of theft of a single wallet/purse containing all forms of payment/ID/access.

On the note of charge, Apple has recently included a feature that lets certain cards work even when the phone doesn't have enough charge to be normally used. It seems they shutdown the phone before the battery is entirely depleted, reserving a small amount of charge to be used for these cards.

https://support.apple.com/guide/security/express-cards-with-...

How would this differ from keeping your hotel keycard, ID card, cash, and credit cards in your wallet/purse? If you lose your wallet/purse in that case, you'd also have no key, no ID, no money, etc.

I'll be looking forward to Cascadea coming to iOS (hopefully).

https://cascadea.app

> Apple uses ALAC (Apple Lossless Audio Codec)

I think this is the closest I could get the toolbar to match the article on Big Sur.

- There's an unremovable vertical separator, which is related to the new sidebar behavior. - The filter button seems unremovable. - Other toolbar buttons can be moved to the left of the sidebar-related vertical separator, but the flex-space doesn't work the same as described in the article. As a result, the search bar can't be centered.

=> https://media.rymate.co.uk/file/professibly.png

I wonder why SSL Client Certificate Authentication hasn't become popularized for the web.

1. Browser visits a site that needs authentication. 2. Browser checks if there's already an existing client cert. 3. If not, browser generates one. 4. Browser uses it in the SSL handshake, resulting in the user being signed in without passwords, cookies, email links, etc.

Apple's App store doesn't list permissions, but permissions are not given until the user is asked for each individually. I think it's against the app store guidelines to require permissions that aren't actually necessary (eg. requiring microphone permission before displaying a news article to the user).

Wow! This is incredible! Having extensions so that users can save content that's behind a paywall makes a ton of sense. As a (hopefully long-term) user of your service, I'd appreciate the ability to do something like this with the non-demo app so I could add articles when using my phone or other devices.

And if you took it a step further I would _love_ some form of API access (even with reasonable usage limits and legal restrictions to personal use only).

Your service looks really neat! Is there a way I can use it without the extension? For example, can I paste a url into the website?

I use Safari as my primary browser and am not interested at switching browsers at this time. However I am interested in trying My Screen Break!

I read it as "42 is stored in age". The works particularly well for a long chain of methods that should end in storing the resulting value in a variable. I know this might seem to be the most conventional way that Ruby is written; it makes a single statement take 8 lines instead of 1, it transforms a value over the course of the statement instead of sending messages to tell an object to transform itself, and it ignores the concept of encapsulation by moving the interesting actions into the foreground rather than being hidden within an object.

Below is an _incredibly_ contrived example. Take note how the `=> final_value` syntax is useful. The alternative is to place a `final_value = ` at the _top_ of the statement. I'll admit: placing the assignment at the top of the method chain helps point out to the reader of the code that an assignment is happening. However, more useful I think is quickly recognizing the flow of data.

  "hello"
    .chars
    .size
    .*(10980643.4)
    .to_i
    .to_s(36)
    .upcase
    => final_value
  
  puts(final_value)
  # => WORLD

> What would be the point of different compilers be then?

When given the same input and expecting the same output, there remains only one thing: compile speed.

> I'm not sure how much space it would take up to store a list of urls that have been submitted to HN

I recently was wondering how much space this would take up myself. After a lot of searching, I found this reddit post, which links to an archive of Hackernews. It contains data from HN from late 2006 until mid 2018 and totals just over 2 gigabytes. These dumps contain all comments, job postings, polls, poll options, and stories.

I did some super quick analysis of the 2018-05 archive (the latest provided by this source). I found that there were 237,646 total items, and only 32,473 of those are stories. That's only ~14%. Assuming the ratio of stories to non-stories has been constant for the entire dataset, that's only 280 megabytes for the entire 2006 to 2018 set.

That data can further be shrunk by removing extraneous information from each story in the data. Mirroring the HN api, it has the following pieces of data for each item: author username, id, date retrieved, score, time posted, title, type, url, and whether its dead, how many descendants it has, and what items are its kids. I didn't attempt to reduce the data to only contain links, but I imagine it would be significantly reduce the size.

Once you've reduced the data down to a list of urls, I imagine it can be reduced even more by removing duplicate links.

Depending on the average size of the urls, it's not unreasonable to think that taking a hash of each of the urls would result in a smaller set of data.

On top of that, there's wonderful text compression, but I don't have the numbers on how much that would reduce the size of data.

One solution to this issue is to use an emoji font that is designed to be color-free, like one of the variants of OpenEmoji.

For a light color theme with a slightly different take than usual, I would recommend Flatwhite.

The differentiating idea behind it is that for dark syntax themes, it makes sense to have the foreground of text be different colors. In contrast, for light syntax themes, it makes sense to have the background of text be different colors.

Atom: https://github.com/biletskyy/flatwhite-syntax Sublime Text 3: https://github.com/Willamin/flatwhite

An interesting way to achieve this that I've recently discovered is that I can use Apple's built-in Screen Sharing application to act as the keyboard, mouse, and display when connecting to a clamshell MacBook Pro. The MacBook Pro then only needs to be connected to power and the network.

I’d hope to see a “I understand but would like to see the site anyways” button on the pop-up

As an alternative to getting a smart tv and treating it dumb, I came across this dumb tv a few weeks ago: ironcast.tv