Graphview Plug for Silverbullet

Plugs and Libraries
22

I have the same issue with v2 compatible plug

image
image986×856 118 KB

can you share your configuration ?

23

Can you just remove the default_color setting if you have it ? My guess is this is just the default color overriding it globally across light and dark modes. That’s a setting that carried over from the older version that I inherited - might be worth removing it now since it’s just causing confusion.

24

I don’t have this setting configure. Take a look of my CONFIG file:

config.set {
  plugs = {
    "github:joekrill/silverbullet-treeview/treeview.plug.js",
    "ghr:MrMugame/silversearch",
    "github:logeshg5/silverbullet-plantuml/plantuml.plug.js", 
    "ghr:deepkn/silverbullet-graphview"
  },
graphview = {
    ignoredPrefixes = {
      "Library", 
      "template", 
      "Journaux"
    }
  },
...
25

Hmm.. that’s really odd. That configuration works just fine for me on dark mode. Can you maybe just hard refresh the page and make sure that the worker for the plug has restarted? Was it working fine for you on v1?

26

I try a reload UI, reload system and update Plug and the issue still there.
Now, I change my Config file like this to see someting :

config.set {
  plugs = {
    "github:joekrill/silverbullet-treeview/treeview.plug.js",
    "ghr:MrMugame/silversearch",
    "github:logeshg5/silverbullet-plantuml/plantuml.plug.js", 
    "ghr:deepkn/silverbullet-graphview"
  },
graphview = {
    ignoredPrefixes = {
      "Library", 
      "template", 
      "Journaux"
    },
  default_color = "ffffff",
  colormap = {
    path = {
      java = "96020e",
      spring =  "0bbd02",
      projet = "ffc533",
      personne = "01017a"
      },
    tag = {
      maison = "02bdb6"
    }
   }
  },
....

and it’s look like this:

image
image599×607 75 KB

maybe there’s a conflict with treeview plug because they share the same panel??? i don’t know…

27

If you remove the ‘default_color’ from this (working) configuration of yours, does it f** it up ? This has to be some override acting up - but this is confusing to me as well. Let me dig into it a little.

28

With default color = “ffffff”:

image
image1321×887 122 KB

without :
image
image1321×887 110 KB

:man_shrugging:

29

I’ve discovered a very odd bug (and added a github bug report) for a behavior where overwritten images (uploading an image and naming it the same as an existing one) creates a perpetually present orphan node in the graph that cannot seemingly be removed.

image
image524×546 55.7 KB

They appear as orphaned files with the same name as connected ones, and link to said connected images. If using the local graph view, they even show as a second “hub” in the graph.

image
image527×357 11.3 KB

Anyone have any ideas where this data might be being stored so it can be purged?

30

Thank you for the bug report. I’ll have to take a look at this to make sure that the plug is not doing anything funky - but in general, it just makes a regular lua query to SB itself to fetch the nodes and links data. And this would mean that it’s possible that the orphaned nodes are still in SB’s index. Are you getting two entries if you specifically query for the name in SB itself? What about after forcing a reindex of the space ?

31

Did look into this a bit - my suspicion is silverbullet is not setting the darkmode property correctly upon startup. The plug reads that to set some sensible default colors in dark mode and light mode - turns out if I just toggle the dark mode once and back, everything is good. Just that once dark mode is set and the silverbullet reloads or opens a new tab, the setting is honored, but the property itself is not set. Could you check if toggling the dark mode once does the job for you as well, even without the default_color setting in CONFIG?

32

Unless there’s something not in the command list, I’ve tried all the commands that say anything like refresh, re-index, etc. and tried deleting and reinstalling the plug, so I’m thinking it might be part of the database but I’m not sure how to verify. Images don’t show when searching for something since they aren’t pages (I’m not very familiar with LUA).

33

@StellasFun Toggle dark mode twice, this should fix it.

@deepkn You should be using editor.getUiOption("darkMode") not clientStore.get("darkMode"). And careful, it can be undefined in which case you should use the system default. Although it may make sense to change that.

34

Thank you @MrMugame - released a new version with the darkmode fix, some UI polish etc. @StellasFun Looking into the other bug of multiple image entries in the index - been a bit busy, will update soon.

35

I don’t think it’s fixed. So let’s do a little deep dive into how this works.

So the editor preact component has a state object which has all the necessary state for the UI and also has a uiOptions property, which contains stuff like darkMode, vimMode or newly the clean syntax mode. This state object is in ram and is populated on every load of the component. This is done using a syscall, namely the editor.setUiOption syscall, by a core plug. What it’s doing is looking if there is a stored value in the clientStore on editor:init and if there is it sets the uiOption using the syscall to said value. This stored value in the clientStore is in turn set by the Toggle Dark Mode command (which also reloads the editor, so another editor:init is fired). The reason the clientStore is used here is so the value persists across reloads.
The issue here now is that the type of the property looks like this darkMode?: boolean. It can be undefined, in which case the component will use a media query to determine the system preference. Now why is it undefined? Because it wasn’t set from the clientStore why was it not set from the clientStore? Because it didn’t contain a value/was undefined.
This is exactly what you are seeing, after a wipe. The clientStore is undefined, so no uiOption will be set and thus the editor will chose the system preference (e.g. dark mode). Your code gets the uiOption / clientStore casts that to a boolean which will be undefined → false, which means white mode. This is there it’s failing. After you toggle the dark mode the value will be written to the clientStore and will be correct.

So don’t ask me why it’s typed like that, in my opinion this is hugely confusing and causes bugs like that, but whatever. So you have a few options at fixing this.

  • Also use a media query to get dark/white mode in the undefined case.
  • Easier approach would be to use css/query the document.documentElement.dataset.theme value as this will be set correctly.

(I hinted as using getUiOption as this would internally be the value that’s certainly correct. While the clientStore is just used for caching. Normally they should mirror each other, but you may never know …)