SpacingBat3 / WebCord

A Discord and SpaceBar :electron:-based client implemented without Discord API.
MIT License
1.96k stars 98 forks source link

Client side decorations #303

Open OwczarekGit opened 2 years ago

OwczarekGit commented 2 years ago

I think that proper CSD's could make WebCord look much more native and blend much better with desktop additionally saving some vertical space by eliminating the need of titlebar.

Here is a quick mockup in style of GTK4/libadwaita that i made to get an idea on how that could look like in practice. Personally i think it could be pretty slick.

webcord-csd-mockup

mark-russ commented 2 years ago

Beautiful!

orowith2os commented 1 year ago

Considering Electron depends on GTK, this might be possible to do if Electron has a way to customize the CSD.

SpacingBat3 commented 1 year ago

Considering Electron depends on GTK, this might be possible to do if Electron has a way to customize the CSD.

It's not a matter of Electron supporting a customizable GTK CSD, it's a matter of non-native titlebar with somehow rounded corners and all that stuff adapted for GTK, which could be possible, yet hard to implement. I've actually worked on using GTK with the web applications, but I stopped working on that for some time, the main problem is to actually know about the current GTK theme ideally without using entire GTK library or module for that. Then we could probably use stuff in there like CSS and icons to actually inject that into the window and simulate the CSD.

orowith2os commented 1 year ago

@SpacingBat3 Electron already depends on GTK, so why would it matter to try not use the entire GTK lib?

SpacingBat3 commented 1 year ago

@SpacingBat3 Electron already depends on GTK, so why would it matter to try not use the entire GTK lib?

Well, consider that for non-Linux platforms. Electron there doesn't depend on GTK and uses native APIs instead.

As for other reasons, I believe module itself is quite complicated to implement in case of Electron, especially it needs to be avoided to be used within preload scripts. Avoiding native modules has also a benefit of shorter compilation time and better cross-platform support, since we don't have to care about making modules compatible with different architectures. This also makes the build on its own a bit less complex.

orowith2os commented 1 year ago

Wouldn't this CSD be Linux-only, though? I don't believe Windows and macOS support CSDs (I've heard macOS supports DWD, though)

SpacingBat3 commented 1 year ago

Wouldn't this CSD be Linux-only, though? I don't believe Windows and macOS support CSDs (I've heard macOS supports DWD, though)

Yeah, but the module itself would have to be still installed on Windows and MacOS, it's quite hard to have a static types and optional modules…

Usually that means it has to be resolved on module side (either if it is native or not) and probably bypass some TypeScript / ESLint protections (to use require on CommonJS or dynamic import on EcmaScript modules and infer proper types).