Arch Linux User Repository

For minimal changes, this package is based on https://www.archlinux.org/packages/community/x86_64/code/ . There is no plan on adding further changes/features except transparent window support.

About building, currently code 1.47.3-1 uses nodejs-lts-dubnium (Node 10.x) as a makedep. It will conflict with your already installed nodejs (latest version of Node) package, usually installing with AUR helpers or directly running makepkg.

Here are two recommended solutions:

Solution A:

Build this package in a clean environment with Arch Linux devtools (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way) to build the package.

extra-x86_64-build (comes from devtools) will build the package in a clean environment, without bothering your local packages.

Solution B:

Use archlinuxcn repo (https://github.com/archlinuxcn/repo).

Frantic1048 added code-transparent to archlinuxcn repo, which follows updating of this AUR package. You can install code-transparent with the prebuilt package from archlinuxcn repo.

@Kandelborg I was posting some general instructions to pin since I found many users being confused about building.

I am talking about the monthly VS Code updates. As of right now, there's a new version 1.47.x and this package still isn't updated to use it.

It should have been updated, for now. I know upstream VS Code updates frequently, so do as community/code package. I'm not updating the package immediately after community/code update because I have to check if the transparency patch is still working in the new version.

The transparent feature is not an officially supported feature (It is not enabled by just a build-time feature flag, but a real patch to source code, and the patch itself is also maintained by me). There were awesome guys implement this feature, but sadly, being rejected by the Code team after opening a PR over a year( Long story here: https://github.com/Microsoft/vscode/pull/52707 )

It is necessary to test before updating the new version because upstream changes could break the patch (code conflict, or the transparent feature being broken). This happens several times during the days I was maintaining aur/atom-transparent.

Anyway, testing is not that time-consuming work and update could be quicker, I'm sorry for it. BTW I'm using code-transparent from day to night every day.

Furthermore, the package is perfectly buildable with Node >= 10.x <= 12.x not just one node lts version e.g dubnium. I have tried building with node 12.x by following the official build guide it worked without problems. The official build guide says it's possible within the range i disclosed before.

This package follows community/code's config, and of course the node version. It is working and I do not found much gaining maintaining a derived PKGBUILD from community/code with a different toolchain.

Instead of having to edit the PKGBUILD in order to get the latest version of VS Code, would you be so kind as to maintain the package and update the version numbers? This has nothing to do with node version or anything else, simply keeping the package updated.

As mentioned above, I'd do my best to keep this package up to date :)

On a side-note; VS Code reverted the use of Electron 9 in the latest version bump, they are going to upgrade soon, and in fact, was already upgraded. This package should be updated to use the correct version of electron at that point.

This is the same issue with node version, community/code is using electron7 package for code 1.47.3-1. If a change to electron version is need(as required by upstream) and it is working, community/code would update electron version first, and possibly create a separate electron package for the new code with the new electron version.

E.g. electron 9, in your case, there could be a new electron9 package for code(just like current electron7 package), because official repo does not have separate electron 9 for now.

I am talking about the monthly VS Code updates. As of right now, there's a new version 1.47.x and this package still isn't updated to use it.

Furthermore, the package is perfectly buildable with Node >= 10.x <= 12.x not just one node lts version e.g dubnium. I have tried building with node 12.x by following the official build guide it worked without problems. The official build guide says it's possible within the range i disclosed before.

Instead of having to edit the PKGBUILD in order to get the latest version of VS Code, would you be so kind as to maintain the package and update the version numbers? This has nothing to do with node version or anything else, simply keeping the package updated.

On a side-note; VS Code reverted the use of Electron 9 in the latest version bump, they are going to upgrade soon, and in fact, was already upgraded. This package should be updated to use the correct version of electron at that point.

For minimal changes, this package is based on https://www.archlinux.org/packages/community/x86_64/code/ . There is no plan on adding further changes/features except transparent window support.

About building, currently code 1.47.3-1 uses nodejs-lts-dubnium (Node 10.x) as a makedep. It will conflict with your already installed nodejs (latest version of Node) package, usually installing with AUR helpers or directly running makepkg.

Here are two recommended solutions:

Solution A:

Build this package in a clean environment with Arch Linux devtools (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way) to build the package.

extra-x86_64-build (comes from devtools) will build the package in a clean environment, without bothering your local packages.

Solution B:

Use archlinuxcn repo (https://github.com/archlinuxcn/repo).

Frantic1048 added code-transparent to archlinuxcn repo, which follows updating of this AUR package. You can install code-transparent with the prebuilt package from archlinuxcn repo.

@frantic1048 Are you going to maintain this package? There will be updates each month.

It would be great if we didn't have to download a complete version of node to compile. I am e.g. using NVM to manage my node versions.

VS Code also isn't relying on that specific version of node, it's a range of versions: Node.JS, x64, version >= 10.x, <= 12.x -> https://github.com/microsoft/vscode/wiki/How-to-Contribute#prerequisites

I also think this package should give a warning somewhere that there's problems saving files with sudo.

@frantic1048: I got it working somehow, before now I had only tried opening a second window, not a third, and opening a third worked! I have one last question, and that is if there is a way to get themes that arent normally transparent to show as transparent?

I have translucency enabled in the desktop effects and I have my settings, dolphin and Konsole all transparent with blur.

@Tillter: If other windows like Konsole are showing in transparent correctly means your compositor is supporting transparent windows.

To clarify, transparent means the window have a transparent background, not the entire window(the text is still opaque so we can still read it). If you are using KDE, it should be supported without further configuration.

Ive opened many windows, no luck.

@Tillter: Did you keep multiple code windows open? i.e. Open a code instance, do not close the existing one, and open more code instance. Sometimes the first code window is not transparent, but the second, third ... is transparent, and we can open two, close the non-transparent one to workaround this. I haven't find the reason for this case so far.

Personally, I'm using i3wm+picom and sway, did not experience much in KDE.

ensuring the compositor has transparency enabled means:

On X11, you need to configure your compositor to enable its transparent feature(of course the compositor needs to have this feature). The compositor is a separate compositor(e.g. picom, formerly knowns as compton) which working with a stand-alone window manager(e.g. i3wm), or a compositing window manager(a window manager with some compositing features, like kwin, the wm for KDE) For separate compositor like picom, follow the compositor's document about how to configure its transparency feature. For compositing window manager like kwin, check kwin settings about window transparency, and window rules about transparency.

On Wayland, there is only one compositor(it handles both window managing and compositing). e.g. Sway, it supports transparent windows without explicit configuration.

The key is to figure out what window manager(or compositor) you're using, and check its config(text config file, or GUI settings).

Sorry for the late, my PC's heatsink was broken and spend a while to install a new one.

How to set up the code "transparent-enabled" like root/code-transparent.install say ?

@EPSILONJOHN: Could you please specify which section you doubt with?

So Ive installed this and I just cannot get the transparency working. Ive done the color settings, Ive opened many windows, no luck. The only thing I havent done is is the second step mentioned about ensuring the compositor has transparency enabled. Im not entirely sure how to do that. I have translucency enabled in the desktop effects and I have my settings, dolphin and Konsole all transparent with blur. Any advice or help would be greatly appreciated