[FR] Inject cMenuModalBar in .mod-vertical.mod-root instead of body child.

[Write]

Hi, I just discovered the plugin and love the idea,

I noticed the plugin's bar doesn't self adjust to side panels (open/closed and their size)
I tried on my side to change (https://github.com/chetachiezikeuzor/cMenu-Plugin/blob/master/main.ts#L73)
document.body.appendChild(cMenuModalBar);
to
document.body.querySelector(".mod-root .view-content").appendChild(cMenuModalBar);
and it work like a charm (for me, at least), the bar will always stay centered in the .view-content, where the "writing content" actually is.

PS : I'm not sure about Obsidian's rules as to what are bests practices so maybe what I propose isn't recommended at all.

[chetachiezikeuzor]

Thank you! The main issue I see with this is that when you have multiple notes open, the menubar will remain within the view of the initial note, (which makes it hard to navigate).

Your Request:

Current:

I'll have to consult with a friend of mine (he's a much more experienced developer than I am 😅). But thank you for the tip!!

[Write]

Oh, sorry i didn't even thought of testing it with multiple notes open.
I found a way to have it centered and so when we expand the left or right sidebar, it's still correctly centered inside the "center" (writing) view.

PoC
This is only a proof of concept used for information purpose, I don't ask to implement this. Your plugin, your vision.

First, we inject the bar in the .mod-vertical.mod-root view, which is, as far as I tested, always the "center" (writing) view.
document.body.querySelector(".mod-vertical.mod-root").appendChild(cMenuModalBar);

Then, we change #cMenuModalBar CSS Code.
We use a fixed width for the #cMenuModalBar and set it to a variable so it can be used multiple times.

Create a new variable in #cMenuModalBar
--cmenu-width: 340px;
Change position to absolute instead of sticky
position: absolute
We need fixed height and width
height: 43px;
width: var(--cmenu-width);
**The position is absolute, and since we want to center it from .mod-vertical.mod-root view, we can set left: 50%, but we need to reduce half of the actual bar width to center it correctly. We need to use the --cmenu-width variable we created earlier, and use the css calc() function.
left: calc(50% - calc(var(--cmenu-width)/2))

Tadam !

Video example
https://user-images.githubusercontent.com/541722/127786164-99fef3d1-3f88-4cd2-aa69-a84fcc73deea.mp4

New #cMenuModalBar

#cMenuModalBar {
  z-index: var(--layer-status-bar);
  --cmenu-width: 340px;
  left: calc(50% - calc(var(--cmenu-width)/2));
  bottom: 4.25em;
  padding: 3px;
  display: grid;
  margin: 0 auto;
  height: 43px;
  width: var(--cmenu-width);
  min-width: 100px;
  position: absolute;
  user-select: none;
  border-radius: 6px;
  grid-template-columns: 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
  border: 1px solid var(--background-modifier-border);
  justify-content: space-around;
  background-color: var(--background-primary);
  box-shadow: 0px 3px 25px rgba(31, 38, 135, 0.1);
}

Old #cMenuModalBbar

#cMenuModalBar {
  z-index: var(--layer-status-bar);
  bottom: 4.25em;
  padding: 3px;
  display: grid;
  margin: 0 auto;
  width: fit-content;
  min-width: 100px;
  position: sticky;
  user-select: none;
  border-radius: 6px;
  grid-template-columns: 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
  border: 1px solid var(--background-modifier-border);
  justify-content: space-around;
  background-color: var(--background-primary);
  box-shadow: 0px 3px 25px rgba(31, 38, 135, 0.1);
}

[chetachiezikeuzor]

I think this can work quite well. I do think the fixed height and width will be an issue for further updates, as I add more to the menu.

What I will do is have the width found dynamically in JavaScript. That way, the width and height won't be hard coded (and will allow more flexibility for me to add to it). But thank you for the tip!

[chetachiezikeuzor]

Version 0.2.0 of cMenu is now able to append to workspace with no need for fixed height or width. The width is found within the generation of the menu, stored in a variable, and the left property is set. And with a few CSS adjustments to the child elements, fixed height is unneeded. Thank you for your input!

cMenu.v0.2.0.mp4

[Write]

Cool !
It seems injecting the bar as last element in .mod-vertical.mod-root create a resizing handle on the right, even when there's only one note open. The workaround I found for now is to instead inject the bar directly at the top of .mod-vertical.mod-root with insertAdjacentElement() instead of appendChild()

Like so

document.body
    .querySelector(".mod-vertical.mod-root")
    .insertAdjacentElement('afterbegin', cMenuModalBar)

Thanks to this post

DOM Structure would then look like that :

Where #cMenuModalBar div will always be above first <hr class="workspace-leaf-resize-handle"> and first <div class="workspace-leaf [...]"> instead of being last element (at least at the moment it's injected injected in the DOM).

[chetachiezikeuzor]

Oh wow, nice catch! Could you explain a bit more about the resize handle issue?? Everything seems to work fine on my end but perhaps I'm missing something.

[Write]

7U78cUrFvo.mp4

Yeah this is quite subtle, look at the bar on the right that disappear when i disable the plugin, it's a resizing handle that's not supposed to be there. And when i re-enable the plugin (and then click on a pan to init the plugin), you can the at the moment the bar appear, the resizing handle on the right too. You can actually even grab it and try to resize the main note but only when in fullscreen (at least for me, with my theme i can't grab it if i'm not in fullscreen). - In the video it actually resize the obsidian frame since i'm not in full screen -
My guess is Obsidian add a resizing bar (either with css or js, I didn't check) before last note, and Obsidian think cMenuModalBar is the last "note" when inserted as it's the last element in the list, so a resizing bar is added.

[chetachiezikeuzor]

Very interesting. My hesitation was definitely warranted. I'll add a new update now, thank you very much for your insights!

[chetachiezikeuzor]

How strange. Is this what you are talking about? I wouldn't have caught this at all! You have a very good eye! It's not an awful bug but I'll add the fix in just a bit. Thanks again!

Obsidian.-.Forest.-.Obsidian.v0.12.12-4.mp4

[Write]

Yes exactly that ! I saw the bug when enabling / disabling the plugin when I was trying to do some test with the code to get the bar to show directly when the plugin is enabled (instead of waiting to click on a pan), that's when I stumbled upon the weird offset.

[chetachiezikeuzor]

It was brought to my attention that cMenu doesn't play too nicely with plugins like Sliding Panes. This is why I was hesitant to do the FR. I'll have to look into this one.

Obsidian.-.Forest.-.Obsidian.v0.12.13.1.mp4

[Write]

Yea, I kinda expected there'll be breakage too.
This one is really tricky, I worked on it for the last hour i've kinda found a fix but it's far from perfect. I'll have to check all Sliding Panes options again to see if it works with everything.
I'll have to do a little more testing, I'll try to post it there tomorrow.

[Write]

Well, unfortunately I failed to make it work correctly at all.
This is a real bummer because I really like this plugin but my knowledge on this one is limited.

[chetachiezikeuzor]

Lol, no reason to feel bummed! I'm literally a beginner developer so my knowledge is super limited. I think the best option for now would be to have a toggle-able setting "Append to Body/Append to Workspace." That way, Sliding Panes users can just toggle to fit their needs

[Write]

Lol, no reason to feel bummed! I'm literally a beginner developer so my knowledge is super limited. I think the best option for now would be to have a toggle-able setting "Append to Body/Append to Workspace." That way, Sliding Panes users can just toggle to fit their needs

Love the idea.
In all honesty, I really think this plugin has a great future.

---

If we can make toggle-able settings i'll post my draft anyway, at least my work may not have been totally useless.
I made it work with Sliding panes but it break things without Sliding panes.
I haven't done extended test on it, so there's a high chance it break easily.

---

We need to set a fixed height & width to #cMenuModalbar and switch it to sticky position.
Also since it's sticky, we can't use bottom we'll use top: 90%

position: absolute;
height: 42px;
top: 90%;

Now we have done this, we can see the bar "works" correctly, but theres an issue : Since #cMenuModalBar is now sticky and not absolute and is positioned as first element, when going all left and expanding / collapsing the left sidebar will show a gap with a width equal to the modalbar width.

All we have to do is then to target the 'first' note, which is the 3rd elem. inside .mod-vertical.mod-root.
1st elem: cMenuModalBar:.
2nd elem: the invisible hr resize-handle
3rd: The actual first note.

Also we can remove box-shadow of the first note, since the first one doesn't have a shadow when it's the first elem.

body.plugin-sliding-panes .workspace > .mod-vertical.mod-root > .workspace-leaf:nth-child(3) {
    margin-left: -328px; (Actually the cMenuModalbar width, which we calculate on startup)
    box-shadow: none;
}

After that there's still one pixel border on the left first note that's added (you can check by adding / removing the menumodal bar) but I couldn't find which CSS rules to negate as I did with box-shadow.