Window Transparency Setting Messes with Window Size, Style, and Randomly Remains Opaque

[D-Maxwell]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

After noticing that #948 had been considered for implementation, I couldn't help but upgrade to the latest release and enjoy an acrylic or even a plain blurred background for this great IDE ; to my surprise, I was met with quite a few annoyances, some of which looked terrible, and others outright preventing any use of the IDE as it remained in a collapsed state, unable to be focused, along an empty and tiny preview window from the taskbar entry. (this may or may not happen after disabling Window Transparency, postponing the restart, and enabling it once more, before then restarting, although I am now unable to reproduce this last issue)

Pulsar version

1.118.0

Which OS does this happen on?

🪟 Windows

OS details

Windows 10 Pro 22H2 19045.2788

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

As seen in this first picture, the document's size does not match that of the window. I have also found it impossible to resize the window by its edges, although it does work through AltSnap (a Window Management Script). In such a scenario, the maximise button has no effect either.

Maximising the window through AltSnap --given the inefficiency of the intended button-- will either yield a black background in place of a transparent view --a screenshot for which I lack--, or will result in the title bar reverting to some XP-esque aesthetic.

As previously mentioned, at times, the window will spawn without respect to its last set size, and will default to the minimum window size ; which, in conjunction to the document not filling the whole window for some reason, leads to a purely empty window, unless manually expanded ; once again, through the use of a script, as the edges refuse to be considered as such upon hovering.

Additional Information:

I am quite disappointed seeing this feature that I for one had greatly anticipated, and I would love for it to become usable.

[D-Maxwell]

After some amount of styling, I could get it to look somewhat good ; that being said, resizing the window and opening the editor remain quite painful.

[confused-Techie]

@D-Maxwell While I appreciate the issue, this is very much known.

We tried to get this across in the setting description of Allows editor windows to be see-through. When this setting is enabled, UI themes and user stylesheets can use background colors with an alpha channel to make editor windows translucent. Takes effect after a restart of Pulsar.. Which the important part to note is "UI themes and user stylesheets can use...".

We are aware that just enabling this doesn't really look that great. There were attempts to make this feature usable on our default provided themes, but doing so was much much easier said than done. Leaving us to essentially offer the ability for "community UI themes and user stylesheets" to utilize this feature.

We know you wanted this feature, so we wanted to make sure we could support you and the rest of the community in having it, even if we don't have the time ourselves to make a stylesheet that makes it perfect.

Considering the time you spent working on your user stylesheet to make this work, I'd highly recommend that you could publish those changes as a community UI theme for everyone else, or even if you don't want to, we could look at using pulsar-cooperative to manage the package while getting the changes you've made to make this available to everyone.

But otherwise I apologize if this was an underwhelming change, but our goal in the PR that was merged was to make this behavior possible rather than take advantage of it completely. While that may or may not change in the future, I'd love to see someone from the community be able to turn it into something truly great, now that it is possible at all.

(I'd like to note I don't speak for DeeDeeG who authored the changes themselves, but was communicating with them through the difficulties in attempting to utilize these features in built in themes, and may have supported the current course of action in simply making the feature possible.)

[savetheclocktower]

I'll admit I was surprised to see the difference between the implied dimensions of the window (as indicated by the title bar and placement of the close/minimize/maximize buttons) and the dimensions that we actually occupy. Was that a known issue?

[D-Maxwell]

I'll admit I was surprised to see the difference between the implied dimensions of the window (as indicated by the title bar and placement of the close/minimize/maximize buttons) and the dimensions that we actually occupy. Was that a known issue?

@confused-Techie seems to have focused on exactly the one thing... that I had been expecting.
At no point had I expected Pulsar to incorporate stylings that made use of the window's ability to render transparently. The initial reason I reported this issue --the same as for why i believe its existence was required-- had all to do with every other issue I've (actually) mentioned. Again, at no point was I expecting a ready made theme to be bundled and enabled upon toggling on the setting.
I knew I would have to be spending an hour or two getting familiar and experimenting with Atom's inner HTML layout, in order to create my own theme taking advantage of this newly merged feature.

I would certainly prefer for you to focus on the other issues this seems to have brought --and that I have reported above--, as I reckon you must have misunderstood me by expecting my own expectations to be such that Pulsar would automatically "look good" with this option on.

[D-Maxwell]

Considering the time you spent working on your user stylesheet to make this work, I'd highly recommend that you could publish those changes as a community UI theme for everyone else, or even if you don't want to, we could look at using pulsar-cooperative to manage the package while getting the changes you've made to make this available to everyone.

But otherwise I apologize if this was an underwhelming change, but our goal in the PR that was merged was to make this behavior possible rather than take advantage of it completely. While that may or may not change in the future, I'd love to see someone from the community be able to turn it into something truly great, now that it is possible at all.

I had indeed thought of releasing my humble --somewhat messy and hastily put together-- stylesheet, although I have never done that in the past. I may consider getting to it once I am done covering all use cases (as for some reason some panels are unaffected by the global rules I have defined, such as the Settings pane), and once I finish tidying it up.

[D-Maxwell]

I'll admit I was surprised to see the difference between the implied dimensions of the window (as indicated by the title bar and placement of the close/minimize/maximize buttons) and the dimensions that we actually occupy. Was that a known issue?

I haven't found any related ones prior to opening this issue.
As the entirety of the DOM is restrained by foreign constraints unaccessible to me, I stand unable to fix the improper dimensions of the page within its window, even as a bodge.

Would you be aware of any clues as to where exactly the root cause may lie ?

[savetheclocktower]

Would you be aware of any clues as to where exactly the root cause may lie ?

No; I have no experience with this area of Electron.

This is not very high on my list of concerns right now, but that's just because I've got six other Pulsar-related tasks going at any one time. Another team member may be able to run some quick experiments to figure out what's going on, but if not, this might just be a symptom of the fact that we're on an old version of Electron. @mauricioszabo runs a version of Pulsar updated to the latest Electron; he might be able to check this for you if he's in a good mood.

@D-Maxwell, would it be possible for you to isolate some small amount of CSS that would set a transparent background on most themes? If not, it's OK; it'd just be nice to have something that a user could paste into their stylesheet to test transparency instead of having to create a whole theme.

[D-Maxwell]

@D-Maxwell, would it be possible for you to isolate some small amount of CSS that would set a transparent background on most themes? If not, it's OK; it'd just be nice to have something that a user could paste into their stylesheet to test transparency instead of having to create a whole theme.

Sure, I was already planning on doing something akin to this.
That being said, where should I publish this ? I have no prior experience packaging add-ons for Atom.

Looking forward to those issues being fixed, but take your time, this is no matter rendering the program unusable.

[savetheclocktower]

Sure, I was already planning on doing something akin to this. That being said, where should I publish this ? I have no prior experience packaging add-ons for Atom.

I mean something more like the least amount of CSS/Less that a user can apply to turn their current theme transparent. Ideally this would be something small enough to paste into this issue or into a Gist.

If it helps, try the following more specific exercise:

• Set your UI theme to One Dark.
• Open your user stylesheet.
• See how much CSS you'd need to add to your user stylesheet to override One Dark and make the theme exhibit transparency.
• Take that CSS and paste it into a code block in this issue.

[D-Maxwell]

Literal values were decided arbitrarily, but not including them would yield an absolutely illegible workspace.
I reckon you would be interested in the "Absolutely Necessary" section.

// Translucence //

/// Absolutely Necessary ///

atom-text-editor {
	background-color: rgba(0,0,0, calc(2/3));

	// bodge, bad dobby bad
	& *:not(:is(atom-overlay, .selection.region)) {
		// why should every sub-component have its own background declared independently...
		background: none !important;
	}
}

html, atom-workspace {
	background: transparent;
}

.atom-dock-mask {
	background-color: transparent;

	& * {
		background: none;
	}
}


/// Recommended ///

.atom-dock-mask .item-views {
	background: rgba(0,0,0, calc(3/5)); // 2/3 as well ?
}

.atom-dock-mask * {
	color: white;
}


.pane > ul[is="atom-tabs"] {
	background: none;

	& > li[is="tabs-tab"] {
		--_opacity: calc(1/2);
		background-color: rgba(0,0,0, var(--_opacity)) !important;

		&.active {
			--_opacity: calc(2/3);
		}

	}

}



/// Eye Candy ///

atom-panel-container.footer > atom-panel.panel-footer {
	background-color: rgba(0,0,0, calc(1/2));

	& > * { background: none; }
}

// text selection highlight
atom-text-editor .selection.region {
	// not sure what the default opacity should be, this may turn out overly soft for most, despite being subtile enough to my eyes
	background-color: rgba(0,0,0,0.25);
}

// entry selection highlight
.tool-panel.tree-view ol.list-tree > li::before {
	opacity: 0.5; // quick fix, to reconsider
}

.pane > ul[is="atom-tabs"] {
	// for some reason box-shadow is used as a border ???
	box-shadow: none;

	& > li[is="tabs-tab"] {
		// this could mayhaps be turned into a slight gap
		border: none; // border is overdrawn by accent, only visible past three open tabs
	}

}

.atom-dock-inner, atom-pane.pane {
	border: none !important;
}

.tab-bar .tab:last-of-type {
	// return of the box shadow border
	box-shadow: none;
}



// AutoComplete Modal [WIP] //

atom-overlay[class*="autocomplete"] {
	position: absolute !important;
}

atom-overlay[class*="autocomplete"] > autocomplete-suggestion-list {
	backdrop-filter: blur(40px);
	background-color: rgba(0,0,0,0.25) !important;
}

[savetheclocktower]

@D-Maxwell, I'm reading the Electron docs and I'm wondering what would happen if you tried this:

• Open your config.cson (File > Config…)

• Go to the core: section

• Add the line titleBar: 'hidden' so that the section starts as follows:

  core:
    titleBar: 'hidden'

• Save the file

• Relaunch Pulsar

We didn't read the docs closely enough; window transparency on Windows only works when the frame option for a window is set to false. The only option in Pulsar that achieves that effect is the core.titleBar setting — which is typically only an option on macOS, but in this case we check for the presence of the value without checking the platform.

I don't know what this will end up looking like, but I think there's a good chance you won't have minimize/maximize/close controls. If it improves the situation, we'll see about making that setting automatic on Windows when transparency is on.

I'm sorry that we didn't do this right the first time around.

[savetheclocktower]

Oof; the caveats are pretty severe:

Transparent windows are not resizable. Setting resizable to true may make a transparent window stop working on some platforms.

That's probably going to be harder to work around than the lack of window chrome.

[savetheclocktower]

OK, I poked around to see if I could find a root cause. It's mostly above my head, but this PR explains it a bit:

Frameless windows are opting out of some of the baseline assumptions that Windows makes about… windows. For instance, if a window doesn't have a frame, Windows doesn't really have a concept of what it means for that window to be “maximized” — perhaps since one of the assumptions of framelessness is that it enables you to do oddball stuff like have a window of a custom shape. The Electron folks had adopted some workarounds for this constraint in the past, but they broke over time, so eventually they just documented the constraint and left it at that.

I don't know if this means that the window truly can't be resizable… or just can't be automatically resizable. It wouldn't surprise me if BrowserWindow#setBounds still worked as expected, but neither would it surprise me if it didn't. Maybe opting into framelessness just causes Windows to say “fine, you're in charge of managing your own dimensions.”

The best-case scenario here is that all of this stuff would still be doable… but would just have to be done by Pulsar manually rather than automatically by the OS. In the case of drag-resizing, for instance, that'd probably mean that we'd have to catch click events right on the corner of the window and write a handler that relayed information back to the main process about how to change the size of the window.

That's not good news for you, I'm afraid. I'm pretty sure we'd accept a thoughtful PR that did the necessary work here — but even if you were willing to do that work, I'd suggest that you wait until we upgrade Pulsar to the latest Electron version, since I'd hate for you to come up with a solution and then run the risk of having it break when we update.

Again, I'm sorry we didn't do more research beforehand; we could've set expectations better.

[D-Maxwell]

I don't know what this will end up looking like, but I think there's a good chance you won't have minimize/maximize/close controls. If it improves the situation, we'll see about making that setting automatic on Windows when transparency is on.

This is... better in some ways, and much worse in others.

I had originally attempted to launch Pulsar with this setting already set to hidden, as I previously made use of it, but had to disable it past updating to the release that supported transparency as it introduced bugs that I am now meeting once more.

The issues in question include the window being spawned, this time not as small as it may possibly be with respect to the odd padding the transparency setting introduces past the edges of the document, but rather as a zero-width window, as it features no title-bar to constrain its dimensions by the bottom any longer.

Scaling this visually, either through the absent handles or an AltSnap derivative, revealed itself impossible. Instead, I had to resize the window through the alt space NT window modal.

This then revealed a purely transparent window, lacking its usual background blur.

It then occurred to me --or rather, confirmed an initial hypothesis of mine that I had never taken the time to lean onto-- that the blur effect I had managed to achieve was in fact not due to MicaForEveryone, but rather to a system-wide modification which modifies the way title-bars are rendered in order for them not to display as opaque rectangles, the only customisation to which is allowed being in the form of an accent colour ; that being through DWMBlurGlass.

With the setting now set to hidden, this was no longer the case. It would seem that the whole window was previously getting treated as a region to blur, rather than its title-bar solely. As the aforementioned option disables this very same component of the window, perhaps this same system modification may not recognise this as an area on which to draw at all.

This effectively means that, with this option set to hidden, anyone unwilling to make use of system-wide modifications may use targeted software such as MFE in its place, although the blur effect may be a little dark.
I have found that subtracting about 1/4 from the opacity of each value in the above stylesheet made for an about equal, if not better looking workspace.

The only issue this includes being that the window spawns with null dimensions, neither minimal restrictions nor with respect to its previously set size.

Also, I believe the odd padding may actually be the window's borders, as I am able to use their whole surface as a size handle which to drag.
Additionally, it would seem that the window now spawns as a tiny square. So that's dimensions constraints for you, even if a little too tiny for my taste, and absolutely not respecting of the user's preferences.

[D-Maxwell]

Yet another additional discovery I have made --again, I already had a suspicion but nothing more than a hunch-- is that mods such as DWMBlurGlass (and OpenGlass) actually overwrite the very same component that MicaForEveryone uses for its background blur. So that's interesting.

With the above change, there is close to no need for additional darkening through CSS.

This is how I have got the UI to render with close to no arbitrary literals in the stylesheet, only backed by DWMBlurGlass settings. I have attempted to match the rest of my system's blur, which may not match stock Windows 10. (i can't for the life of me recall how i affected the rendering of stock apps)

This is great news, as this means I now hold deeper knowledge regarding exactly how to setup such a theme. I will definitely be mentioning this once I get around to packaging this as an easy install and template.

[savetheclocktower]

@D-Maxwell, I'm curious what happens if you use the Atom API to set window dimensions explicitly. Open your developer tools with Ctrl+Shift+I (that'll screw up your window transparency, but hopefully only while the dev tools are open), then go to the Console tab and type something like

atom.setSize(2500, 1300)

and see what happens. I'm guessing it'll keep the same annoying “buffer” zone at the bottom and right edges of the window, but maybe you'll get lucky and they'll go away.

[D-Maxwell]

@D-Maxwell, I'm curious what happens if you use the Atom API to set window dimensions explicitly.

@savetheclocktower, your comment regarding devtools and window transparency confused me, and legitimately so ; my Pulsar instance does not fail to render transparently even whilst debugging. (actually, it would seem that it may randomly fail once the devtools are closed, requiring a restart past calling atom#setSize. oh well)

Additionally, hard-setting the workspace dimensions through atom#setSize does indeed make the buffer zone vanish ! This is not an unstable state either, as the window may then be resized to any dimensions from its handles ! This is great, thank you so much ^°^

Hopefully this should be easy to trace and fix, or perhaps a quick bodge could be summarised as calling this method past whatever calls are responsible for the creation of the odd buffer zone.

I may add that with the title-bar hidden, maximising the window --through AltSnap-- now works properly, as there is no title-bar component to revert the styling of back to that of Windows95.

[savetheclocktower]

I'm as surprised as anyone that this has a happy-ish ending.

As for the window opening at a very tiny size: you should be able to handle all this at once with something like this in your init.js:

let { width, height } = atom.getSize();
if (width < 200 || height < 200) {
  atom.setSize(800, 600); // Or whatever size you want
} else {
  atom.setSize(width, height);
}

[savetheclocktower]

@savetheclocktower, your comment regarding devtools and window transparency confused me, and legitimately so ; my Pulsar instance does not fail to render transparently even whilst debugging. (actually, it would seem that it may randomly fail once the devtools are closed, requiring a restart past calling atom#setSize. oh well)

That was my experience on macOS — that transparency went away when I opened dev tools and didn't come back after I closed them. It's also mentioned as one of the many caveats of window transparency.

[Oxey405]

Hey ! Transparency doesn't work currently on Debian 12 with Gnome (even a special stylesheet)... apparently you can make it work by...adding a delay to the window see this stackoverlow question