jpoles1 / obsidian-litegal

GNU General Public License v3.0
6 stars 1 forks source link

Plugin not working – Electron 32 issue? #6

Open jwhitley opened 2 weeks ago

jwhitley commented 2 weeks ago

Setup: Obsidian 1.7.5 with Electron 32 installer (macOS)

Repro steps

  1. In a new vault, install the Lite Gallery plugin (1.0.6)
  2. Create a test page, drag images into that page. I used the top three images at this Instructables article. These happen to be webp images, FWIW.
  3. Switch to Source view, copy the block of image insertion markdown into a new litegal code block. I then edited this to remove the ![[ prefix and ]] suffix for each image, so just the image names are present in the code block.

Actual results

Lite Gallery reports "No images found" for the block rendering, and pops up Obsidian alerts Lite Gallery: Image not found: [...] for each image in the block. Yet the same images inlined as ![[<image name>]] from the original drag are found and render just fine.

Expected results

The images are found and the Lite Gallery renders.

Sample Markdown

![[FHL4MN0JRYUCBC2.jpg.webp]]

![[FA65HYUJRQOM9DU.jpg.webp]]

![[FNFRDNIJRQOM9E9.jpg.webp]]

```litegal
FHL4MN0JRYUCBC2.jpg.webp
FA65HYUJRQOM9DU.jpg.webp
FNFRDNIJRQOM9E9.jpg.webp
Graywaren commented 3 days ago

This plug-in requires you to list every folder you might have an image in individually (with full path for each sub folder) in it's settings for it to find an image in your vault. As in if you put / for root it will only search the top level of that folder and no other sub folder. If you have a /media/instructables folder you need to list that full path as a folder to search. If you didn't set that up, it won't find the images. I'm unsure if that's what you're encountering since it wasn't listed in your steps, but I wanted to mention. I'm really hoping they change this so it'll just get all image files from the entire vault or at least search subfolders, but for now you need to list every folder.

jwhitley commented 3 days ago

@Graywaren Thanks, that clarifies things. I’d just assumed it was a set of recursively searched image directories mostly because that’s kinda what everything does. I’m using the Local Images Plus plugin, which imports external web assets into note-specific folders… so an explicit list of every leaf folder with images is super unworkable.

jpoles1 commented 3 days ago

I think this could probably be an easy fix, but I'm currently super busy with work and unable to work on this feature at the moment. Can try when I have time, but code contributions are also always welcome! Perhaps can use a * at the end of a path if we want to include all subfolders (or could make it default behavior, Id just have to think if there are any cases where this could cause problems...).

jwhitley commented 2 days ago

@jpoles1 I think the path forward here is to drop this configuration entirely and simply leverage Obsidian’s idiomatic link path matching, ala how [[…]] file finding works. The relevant snippet go from [[filePath]] to a TFile is:

        var linkpath = getLinkpath(filePath)
        var tfile = this.app.metadataCache.getFirstLinkpathDest(linkpath, filePath)

If a user needs to constrain the litegal block to a specific subset of the vault (e.g. there are multiple folders with image001.jpg), these can be path prefixed to disambiguate them just like regular wikilinks.

I’ll work up a PR to test this approach out.