Arch Linux User Repository

• Completely rewritten patch with correct implementation of transparency for electron window!
• It actually running from compiled binaries! No need for electron dependency!
• No conflicting with official release! You can have installed both!
• Added support for official marketplace!
• Added support for flags configuration file!
• Added support for Wayland!
• Unblocked proprietary features!

How to change window color?

"workbench.colorCustomizations": {
    //Black window color with 75% transparency (#RRGGBBAA)
    "window.background": "#000000BF"
},

..assuming you have a customized theme with all other transparent elements!

Building within clean chroot!

You can build package in completely clean environment without conflicting with any local dependencies (latest nodejs package etc..)!

Execute the following commands inside the package directory:

yes | sudo pacman -S devtools
extra-x86_64-build -c && rm *.log
mapfile -t _pkgs <<< "$(printf '%s\n' code-translucent-*.pkg.tar.zst | sort -Vr)"
sudo pacman -U "${_pkgs[0]}"

..or just run "build-with-chroot.sh" script!

@jnbooth: Thank you so much, your patch works very well. :)

Since 1.58, I had not found the relevance updateBackgroundColor() code and struggled for about a month.

Here is an update for 1.59 that also re-enables GPU acceleration: https://github.com/jnbooth/code-transparent

@frogtd I cannot remove the ripgrep dependency, it uses ripgrep.

VSCode includes a ripgrep binary in its build output.

community/code replaces its internal ripgrep(comes with VSCode) with system copy(installed by pacman):

https://github.com/archlinux/svntogit-community/blob/95040481eb728d0aeba3849f7bb7b666704efe04/trunk/PKGBUILD#L131-L132

code-transparent(this package) is derived from community/code, also takes the same logic.

Can you remove the dependency ripgrep as it is unused?

@frantic1048 Yes this works! thank you for updating to 1.51 and applying this patch!

@jaap: I just made a small patch similar to your link to workaround the first window issue in 1.51.1-1 version. I've tested the patch on my machines and it works fine.

You can take a try with archlinuxcn/code-transparent (packaged by frantic1048) or this AUR package, to see if the first window issue is gone.

The changes can be seen here: https://aur.archlinux.org/cgit/aur.git/commit/?h=code-transparent&id=c5860490b3f436e97f0d30ae6b4e65083af3d179

Also here(managed with aurpublish): https://github.com/frantic1048/pkgbuilds/commit/8a1dabd18cb221aab677e2bac86e43ca04718fb8

@frantic, I didn't see you already commented and I don't think you'll read my edit.

Yeah the issue is that electron calls "ready" when it isn't ready yet. This is the bug: https://github.com/electron/electron/issues/16809. I had some trouble with where to place the sleep/timeout. At some point I got it to work by adding the sleep in the unit tests.

@jaap: Haha, that's really a weird workaround(the issue itself is also weird though). I will try to add that patch into this package later after testing. Thank you so much for reminding me about this workaround that I never thought about.

Can you make a patch something similar to https://github.com/JAicewizard/vscode/commit/1fff71db2204f494b99482c44155b12508c42b5b? I didnt actually test this patch on the linked repo, I tested that it works on this aur package. You can set the sleep lower but it increases the chance that it wont work.

edit: for clarity, this fix is based on https://github.com/electron/electron/issues/16809

@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.