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.

@jnbooth: Here is a fix for black background in terminals: https://github.com/jnbooth/code-transparent/blob/master/fix-terminal-not-transparent.diff

Thank you, the patch works well. Added to version 1.67.2-2

Here is a fix for black background in terminals: https://github.com/jnbooth/code-transparent/blob/master/fix-terminal-not-transparent.diff

If I dont explicitly install request as a global module I get the following error: "Cannot find module 'request'"

Is it possible to add some explicit install request inside code-transparent? Then I dont have to bloat my global node modules

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

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.

@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

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

If Code is not shown transparent:

1. Ensure color setting of Code is configured with transparent colors. (See "Config" section below)
2. Ensure your compositor has transparency enabled.
3. Open a second Code window. (Sometimes works)

@gusbemacbe

I would like to suggest you rename code-oss to code-tranparent for not confilecting with the testing cxode-oss.

That's reasonable, I will try to rename for the executable, or if you could provide a patch is appreciated.

And would it work with Electron 10

Not tried/planned, this package is directly based on the official code package1, with an extra patch for transparency.

The official package already makes it use an external electron(which currently is electron6), to figure out how it works, refer to lines containing electron in PKGBUILD2:

Currently, the highest electron version in official repo is 8.0.x, and the latest vscode requires3 electron 7. It may need some time for the upstream upgrade to electron 10. However, you could have a try with it. Btw, be sure to checkout electron's release note for breaking changes.

Hello @frantic1048

I would like to suggest you rename code-oss to code-tranparent for not confilecting with the testing cxode-oss. I did that. But I had to git pull every time, to change every time and compile every time via devtools, but I prefer installing via archlinuxcn.

And would it work with Electron 10? Because I refer to https://github.com/electron/electron/pull/19159#issuecomment-597437430.

@XeGrox: If you've got any issue, please, clarify:

1. What is expected?
2. What is not working as expected?
3. What is changed/did you do anything?

(Please consider reading http://www.catb.org/~esr/faqs/smart-questions.html)

For your last message:

Not working as of 18/12/19 after latest update

I cannot figure out WHAT is not working or should be working, after WHAT update or specific operation. Thus I cannot help solve your issue in any way.

Did you follow the instruction after installation (https://aur.archlinux.org/cgit/aur.git/tree/code-transparent.install?h=code-transparent)? BTW, there's new version 1.41.1-1 since Dec, 25.

Not working as of 18/12/19 after latest update

@strimmlarn

According to https://pastebin.com/0AGc5nRy and previous message you mentioned about using yay, it looks yay is using an existing package(built on previous installation process) for your last installation.

The error said something like: "could not find npm nodejs".

I cannot determine what happend here. All the dependencies of this package are from the official repo(no AUR deps), it should not trigger errors like "cannot found package" where the package is in the official repo.

BTW, as the issue mentioned in https://aur.archlinux.org/packages/code-transparent/#comment-714439, if you are building this package yourself, building in a clean environment(like extra-x86_64-build does) is recommended. You can check your AUR helper if it supports building in a clean environment.

Further, you can refer to https://aur.archlinux.org/packages/code-transparent/#comment-714795 for the manually building solution, or use archlinuxcn repo(which delivers a prebuilt code-transparent package to you, also maintained by me).

huh removed code-transparent + all dependencies + npm and didn't get the error this time its just installed.

don't know if it helps but here is the log for that:

https://pastebin.com/0AGc5nRy

If you can help me help you just tell me, thx for the package btw.

@frantic1048

sry I don't know where to search for it.

Used yay and didn't have a default folder for makepkg logs.

The error said something like: "could not find npm nodejs".

Ahh what the hell, I try to reinstall it brb.

@strimmlarn: Any log please ?

Got error when installing this.

fixed it by writing: "npm install nodejs"

then installed it again.

@ShayBox: For minimal changes, this package is based on https://www.archlinux.org/packages/community/x86_64/code/, which uses nodejs-lts-dubnium as a make dependency.

Using nodejs to build may work, but I haven't tried.

Using -bin package is not an option for this package since we have to apply the transparent patch to source code to make things work properly. Patching a compiled -bin package would make code continuously complain about corrupt installation(https://code.visualstudio.com/docs/supporting/FAQ#_installation-appears-to-be-corrupt-unsupported).

To your concern about building, here are two solutions:

Solution A:

Use 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).

I've added code-transparent to archlinuxcn repo. You can install code-transparent with the prebuilt package from archlinuxcn repo.

I love the transparency patches, and I know this is also a problem with the original code package, but unfortunately this just isn't compilable, because it uses nodejs-lts-dubnium instead of nodejs, and because they conflict, I can't install nodejs-lts-dubnium even temporarily to build it, a ton of packages use nodejs as a dependency, and to uninstall nodejs I would have to remove a lot of other packages, you're either going to have to provide some binary source like a -bin package, or an arch repository, or get it to build with nodejs instead of nodejs-lts-dubnium, I haven't tested it, so it may compile.
Ultimately the code's PKGBUILD isn't very good, it uses the wrong nodejs, uses both npm and yarn, python2, and electron4.
I guess the easiest option would be a bin package, that's what all the other aur packages have chosen.