Dynamic Layout Adaptation: Adjusting Main-Content Width with Changing Contexts

[FlorianF]

@mentaloid

• If it doesn’t look good, why don’t you use a smaller width?

A smaller width that is hard-coded in the CSS is NOK because, when you open the Right Sidebar to half-half of the screen, main-content becomes a newspaper-like narrow column that can’t be worked on properly. So then I need to type T W to get it as wide as possible in the allowed space (half screen). So, after taking whatever I need from the right sidebar, i toggle the right sidebar off and now that one full-screen-height narrow column stretches on 4 lines of full-width screen. It’s an awful experience.

@mentaloid

• If your screen is that wide, why do you toggle the side-bars off?

Sidebars are useful when you use some information from there, otherwise they are just noise. I use the left sidebar quite seldom but the right sidebar gets a lot of use. It is busy with lots of Opened Cards and It would be very eye-straining to have it always on. So I use it to know what I need to work on (among other things) and open that Card in the main pane, then I hide the right sidebar so I can have an as close to a distraction-free environment as possible. That is when a full-width content-pane is NOK.

Hence, I would like to find a way to automate my own T W-ing all the time by having a function that does it for me like so and the easiest I can think of is judge by the main-content element’s width. If it’s less than 60% of the screen width (ex: when both the left and right sidebars are open) then do a “Toggle Wide On” and if it’s more than, say, 70% (ex: only left sidebar is open or no sidebar is open) then do a “Toggle Wide Off”.

[mentaloid]

@FlorianF

otherwise they are just noise

Instead of opening/closing/stretching/minimizing the bars and messing with percentages and pixels, just hide the noise with visibility: hidden (and later visibility: visible). That also ensures that the content in the main pane remains still during toggling, thus zeroing eye-straining.

[FlorianF]

I don’t want the main-content width to be a static value, it makes sense to be dynamic and adapt to the layout. I don’t understand what you mean with visibility … it seems liek a CSS property…

I am merely trying to get Logseq UI to fit my workflow and my workflow involves toggling on and off the right sidebar often, working with different optimal widths of the right sidebar depending on Cards’ content types (if it’s only a TOC then narrow is ok but if it’s The Day Planner then it needs half screen, etc).

I gave it some more thought and, if I leave it Toggled Wide it is adaptive enough with all the sidebars to re-flow nicely. The only situation when Toggle Wide is not doing it for me is when the left sidebar si closed and the right sidebar is less than 25%. If I new the right name (similar to “rightbar.style.width”) for the main-content I can try to play with it myself and add some code when I set the rightbar width to different values…

[mentaloid]

• visibility is a CSS attribute that can be used in place of attribute display
  • It works great with static widths.

@FlorianF

working with different optimal widths

• Optimal width is an illusion.
  • If a screen is small-enough, all widths are compromises.
  • If a content is big-enough, all widths are compromises.
  • When having small content in a big screen, be thankful for the luxury and move on.
    • Real work has very little to do with widths.

@FlorianF

I am merely trying to get Logseq UI to fit my workflow

• You have long gone beyond the point of “merely”.
• Workflows can be as problematic as the applications.
  • Frequent toggling sounds problematic-enough.

@FlorianF

If I new the right name (similar to “rightbar.style.width”) for the main-content

• You already know the right name: main-content-container
  • Take it with const main = document.getElementById("main-content-container")
  • Use it with main.style.width
• Could also experiment with css class .w-full
  • currently set to width: 100%
• Keep your expectations low.

[FlorianF]

@mentaloid

You have long gone beyond the point of “merely”.

true that, i suppose.

@mentaloid

• Take it with const main = document.getElementById("main-content-container")
• Use it with main.style.width

Thanks for this, I’ll try to experiment with it.

[FlorianF]

ok, this doesn’t seem to be what I am after. When I set main.style.width at 70% it actually does it within that element, not in relation to the whole width of the UI like T W does…

[mentaloid]

• You can try with its ancestors:
  • main-content (without -container)
  • left-container
• Keep your expectations low.
  • These are mere hacks, they don’t address the actual issue of desirable flow.

[FlorianF]

I managed to advance on this:

• I dropped the above approach;
• I tried to access, with javascript, the CSS property “–ls-main-content-max-width”;
• I ended up with a code like this:

const root = document.documentElement;
const leftbar = document.querySelector('#left-sidebar.is-open'); 
// `getElementById('leftt-sidebar')` would always return true

if (leftbar) {
    root.style.setProperty('--ls-main-content-max-width', '100%');
} else {
    root.style.setProperty('--ls-main-content-max-width', '70%');
}

The above approach works and I have implemented it for the right sidebar widths but I also have to take into account the left sidebar. My desired UI-situation is that if left sidebar is not visible and right sidebar is less than 25% --ls-main-content-max-width is set to ‘70%’, otherwise it’s 100%…

Now I need to turn this to an observer (right term?) so that anytime the left sidebar is not visible the width is reduced to 70% and in all other cases it’s 100%, but don’t really know how to do that.

The other option would be to create an EventListener that looks for the T L key sequence and analyze the visibility status in the Listener. Which would be a better approach?

[mentaloid]

Try this css:

:root:not(:has(.is-left-sidebar-open)) {
  --ls-main-content-max-width: 70%;
}

[FlorianF]

hmm, nothing happens for me in the layout … I even reloaded Logseq, which shouldn’t be necessary for CSS changes …

[FlorianF]

Tried this but it doesn’t work and somehow rendered my other EventListener for cycling Right Sidebar widths unresponsive for the set key combo (`“Alt+w”):

document.addEventListener('keyup', (e)=>{    
    if (e.Key === "T") {
		document.addEventListener('keyup', (e)=>{	
			if (e.key === "A") {
				const leftbar = document.querySelector('#left-sidebar.is-open');
				if (leftbar) {
					root.style.setProperty('--ls-main-content-max-width', '100%');
				} else {
					root.style.setProperty('--ls-main-content-max-width', '70%');
				}
			}
		}	
    }
})

[mentaloid]

• It works to me.
• Try in an empty graph, to ensure that it doesn’t conflict with the rest of your customizations.
• Check in the inspector that it actually gets toggled when you toggle the left sidebar.
  • Filter the styles by name.
    • e.g. ls-main
  • The rule should:
    • appear when the left sidebar is closed
    • disappear when the left sidebar is open

[FlorianF]

@mentaloid

:root:not(:has(.is-left-sidebar-open)) {
  --ls-main-content-max-width: 70%;
}

I tried with empty graph and it does trigger but I can’t understand where is my main graph conflicting. In my main grapg’s css I have the following:

:root {
--ls-main-content-max-width: 70%;
--ls-main-content-max-width-wide: 100%;
}

:root:not(:has(.is-left-sidebar-open)) {
  --ls-main-content-max-width: 70%;
}

Could these two overlap somehow? I can’t see anythin else to cause conflict and wouldn’t know where to look …

Left Sidebar hidden/Closed:

Left Sidebar Visible/Open:

Is the js observer or eventListener such a bad idea for this?

[mentaloid]

From what I see:

• You still have javascript code that sets --ls-main-content-max-width: 70%; in both cases.
  • This overpowers all css.
• You don’t have --ls-main-content-max-width: 100%; anywhere. I would expect to either:
  • have it inside :root
  • remove --ls-main-content-max-width: 70%; from :root

@FlorianF

Is the js observer or eventListener such a bad idea for this?

Given its complexity and the bad code that you have already come with, yes.

[FlorianF]

Ok, then won’t show my code but I managed to make it to work with an EventListener. It’s not my first choice to try code myself but I can’t expect people in the forum to write code for me. At least I should put some elbow grease and strive to get there myself.

[palindrome]

Out of curiosity, what is the workflow that means you can’t just size the window to show the content at the size you wish?

[mentaloid]

Read Logseq UI: Right Sidebar Width Presets & Keyboard Shortcuts to work in conjunction with T R

[FlorianF]

Just for a simple example case where an auto-adjusting width, instead of manually using T W to widen or make narrow the contents of the Main Work Area, would be useful. You have your contents in the Narrow preset, then toggle the Right Sidebar to read something in there but it’s too much text and the sidebar is narrow so you adjust it with the mouse, making it wider. The Center Pane, being in the narrow stance, gets squeezed too much to be usable for many situations. Now imagine you toggle the left sidebar on top of it to access a Favourite Page that you want to Shift-Click and send to the Right Sidebar. Your Center Column (Main Work Area) is at 70% of it’s possible width, which is not much because of the left sidebar and the resized rightbar. That 30% is precious space that could have been used. That’s why we have T R right? Sure, but how often would you manually re-adjust? If you always have to be taken out of flow when you are working on something just to readjust the layout of the UI to work fror you you would wish, too, that all this was automatic

I was advocating for a dynamically adjustable widths of the middle column (working pane) and the Right Sidebar to accommodate whatever contents might be there. The right sidebar I have managed to have with a shortcut at two different widths (the super wide wasn’t so useful) so, depending on what contents I am looking at in the right sidebar (ex: TOC, Legend - which can fit in a narrow column- or heavier content, tables, etc, which require wider span to be ergonomic.

This post is about getting the center column to full width if at least one sidebar is visible and a more confortable width of the center pane’s text if no sidebars are visible on screen (the same principle for which newspapers split text into columns ox some number of words instead of spanning the whole width of the paper).

[palindrome]

I meant why don’t you always leave it on wide mode? What benefit are the extra margins compared to having a narrower window (which can be widened when needed)?

I don’t think an app should add dead space the way Logseq does, but I’m not confident enough to be loud about this. (I can only say none of the really good apps I use do this–only the weird ones like Teams and the bloatware that came with my laptop. Logseq is a disturbing exception to the rule)

[FlorianF]

@FlorianF

a more confortable width of the center pane’s text if no sidebars are visible on screen (the same principle for which newspapers split text into columns ox some number of words instead of spanning the whole width of the paper)

Always wide is not comfortable nor ergonomic in this particular situation.