inseven / bookmarks Goto Github PK

Right now we're adding and removing the view from the view hierarchy, which will almost certainly have an impact on performance. We should explore whether thumbnail downloading can work without adding the WebView to the hierarchy and, if not, what needs to be done to make it work.

It should be possible to share bookmarks using the share sheet.

https://pinboard.in/settings/password

Right now there's a bunch of gnarly script that installs a provisioning profile (in scripts/build.sh). This bloats out the build script and makes it a little harder to see what's going on. It'd be great if this could be added to the new build-tools Python script so that it's just a one-liner in the build script.

The code in question is:

# Install the provisioning profile.
file="macos/Bookmarks_Developer_ID_Application.provisionprofile"
uuid=`grep UUID -A1 -a "$file" | grep -io "[-A-F0-9]\{36\}"`
extension="${file##*.}"
PROFILE_DESTINATION=~/"Library/MobileDevice/Provisioning Profiles/$uuid.$extension"
if [ ! -f "$PROFILE_DESTINATION" ] ; then
    echo "Installing provisioning profile '$PROFILE_DESTINATION'..."
    mkdir -p ~/"Library/MobileDevice/Provisioning Profiles/"
    cp "$file" "$PROFILE_DESTINATION"
else
    echo "Provisioning profile installed; skipping"
fi

It should be possible to use the context menu to open a bookmark in the in-app browser, or in Safari.

Modern macOS apps put the search box in the toolbar. We should adopt this style for the new macOS app. Probably the easiest way is to add a dependency on the Interact package (see https://github.com/jbmorley/interact) and ensure the SwiftUI search toolbar item is available in this library for use here.

Right now, the search looks for a full string match, meaning it's not possible to, for example, search for multiple tags, or tags and terms together. The search string should be tokenised and the tokens searched for independently. Ideally, this would support quoted strings, and even use of the '-' prefix to indicate strings that should be omitted.

This would ideally determine a dominant colour for the site (perhaps using the favicon) for the placeholder.

This should include:

• Swift Algorithm Club
• Interact
• SQLite.swift
• Introspect
• TFHpple

Apparently Terrence would like this as it stops him loosing context.

The Pinboard API is designed with incremental fetches in mind. Right now (mostly because we don't store the bookmarks in a database, see #8), we perform a full fetch each and every time we update. This is both slow and puts unnecessary load on Pinboard; we should fix it.

The defunct release procedure should also be removed from the release notes.

Stuff was the initial name for the project and it's since been renamed to 'Bookmarks'. We should change 'Stuff' to 'Bookmarks' wherever it appears to--at the very least--make the codebase a little less confusing.

This should have been removed when the tags were removed from the UI.

Even though the Bookmarks app is pretty limited in functionality, it would make sense to have a manual test plan fo the basic UI functionality so it's harder to regress when adding new features.

• Document the new script
• Remove the legacy documentation

The Catalyst UI experience is pretty terrible, so we should create a dedicated macOS build.

Cycling through different application tint colours is slow and adds little. We should remove it.

Right now, the macOS app is a Catalyst build of the iOS app, but that leads to a pretty terrible product experience, and--at the moment at least--it's impossible to write an app with a sidebar that feels native.

We should introduce a new library which allows code to be shared between iOS and a new, dedicated macOS app. It's probably cleanest to also introduce a workspace to manage the two apps and library.

When looking at this issue, it's worth considering whether it makes sense to support the in-app browser on macOS. It's definitely the iOS way of doing things, but it doesn't seem to make as much sense on macOS.

The collection view insets aren't right; they're currently over-inset (see attached screenshots).

[email protected]

These break the build on both the server and on subsequent checkouts: we should try to catch this early in automated builds.

It'd be great if there was a way to change the size of bookmark thumbnails.

Or consider deferring it briefly while scrolling to mean we don't do lots of unnecessary work and respond quickly when the user settles on a page.

It would be great to allow users to have saved searches (or smart folders) that show up in the sidebar. I would use these to quickly access bookmarks for projects I'm working on.

We should make sure any API keys are purged from the source before making the repository public.

It would be great to be able to find bookmarks using Spotlight.

It's pretty much expected that the Command + R hotkey would refresh the data.

The current implementation simply caches the bookmarks in a flat file. This makes more complex query operations difficult to achieve, and gets in the way of adding functionality like searching by page contents, deriving additional data, etc. We should explore using something like CoreData or SQLite to store the data.

I had to disable test builds on GitHub actions as the UI host seems to need to be signed for test builds to succeed. It'd be great if there was a way to generate a certificate expressly for this purpose to ensure that genuine app store keys aren't available to GitHub actions.

The current implementation performs an asynchronous fetch even if the image is in the cache. We should see if checking the cache at render time leads to better performance by preventing the need for a second layout.

Warnings should be treated as errors to ensure the quality of the code remains.