Comments (49)
Also, clicking on the desktop outside of the glava 'window' causes it to disappear. It'll still be running just not visible
I was having a similar problem with a terminal visualizer. Setting window_type to "utility" using devilspie seemed to work for me
Setting the xwintype to 'desktop', glava only shows on the active workspace when the program is initially run.
This was fixed for me using devilspie's (pin)
from glava.
@wacossusca34
Ok so I will post here my kwin config:
#request setdecorated false
#request setxwintype "normal"
#request addxwinstate "undecorated"
#request addxwinstate "above"
// #request addxwinstate "below"
#request addxwinstate "skip_taskbar"
#request addxwinstate "skip_pager"
#request addxwinstate "pinned"
#request addxwinstate "sticky"
#request setclickthrough true
Keeping everything the same.... but changing window typing:
-
normal
[x] minimize all will minimeze glava
[x] glava appears inalt+tab
[x] stays above other windows
[ ] stays above fullscreen applications -
splash
[x] minimize all will minimize glava
[ ] glava appears inalt+tab
> thus I cannot focus it in order to stay above fullscreen
[ ] stays above other windows
[ ] stays above fullscreen applications -
dock/utility
[ ] minimize all will minimize glava
[ ] glava appears inalt+tab
[x] stays above other windows
[ ] stays above fullscreen applications
Also#request addxwinstate "skip_taskbar"; #request addxwinstate "skip_pager"
doesn't matter here. -
desktop
[x] takes over the desktop entirely: no wallpaper, icons; after a click it dies...
[ ] minimize all will minimize glava
[ ] glava appears inalt+tab
[ ] stays above other windows
[ ] stays above fullscreen applications
So after all that I can say that... dock is the least intrusive but if you want glava to stay on top of fullscreen stuff you need to have it appear in the alt-tab
switcher and focus it. if #65 would be fixed then awesome.
from glava.
@flying-sheep thanks for your input. I will start with trying to get in touch with people that work more closely with KWin on IRC (or mailing lists).
from glava.
I had issues with plasma too but they're a bit unrelated: varlesh/xwinwrap#1
Anyways, if it's still broken, one fix is to parent glava under the Plasma window (which contains wallpaper and clock)
An example of this is here: https://github.com/Aaahh/xwinwrap/blob/master/xwinwrap.c#L245
sadly xwinwrap won't work on glava, as it creates a window that glava would have to output to, instead of editing glava's window, i'm working on it
from glava.
Try mmhobi7@d0fcb35
from glava.
I was having a similar problem with a terminal visualizer. Setting window_type to "utility" using devilspie seemed to work for me
@ujjwal96 does setting the window type to "utility"
within GLava also fix the issue? These should affect the same property.
This was fixed for me using devilspie's (pin)
Looking into how devilspie pins windows, I finally found a solution for issues with multiple workspaces via the EWMH standards! Apparently, I missed this portion of the specification:
_NET_WM_DESKTOP desktop, CARDINAL/32
Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client MAY choose not to set this property, in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF indicates that the window SHOULD appear on all desktops.
So a simple client message may fix a wide range of workspace-related bugs. Apparently wmctrl
can do this as well if you move a client to desktop of ID -1
(underflow).
from glava.
Setting the xwintype to 'desktop', glava only shows on the active workspace when the program is initially run.
This is seemingly just how KDE Plasma handles desktop windows, they belong to a workspace (which might be an EWMH compliance issue, but the spec isn't clear on this). Do separate workspaces in KDE also have their own desktop icons?
Also, you can try to play around with window types other than "desktop"
in GLava, as a temporary fix. I will research a way to get it to persist across workspaces later, when I get around to installing KDE.
Also, clicking on the desktop outside of the glava 'window' causes it to disappear. It'll still be running just not visible.
This is strange. This is almost certainly the desktop windows that KDE provides being reordered when you click them (ie. you are focusing the desktop background and it gets stacked over GLava), as if they are operating in their own layer for stacking windows -- but this makes no sense for desktop features!
A solution for KDE might just be to add code in GLava to make it run (optionally) as an actual KDE widget, since it looks like Plasma behaves weird in general.
from glava.
I added a #request addxwinstate <state>
directive that can be used to further tweak how the GLava window behaves. See https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 for details of what this (should) tell your WM.
Specifically for KDE Plasma, try:
#request addxwinstate "above"
#request addxwinstate "sticky"
As an attempt to solve both of your issues.
In the future, I may add an #request embed
option (and command line flag) that automatically detects the WM in use and adds the specific state/type xwin requests behind the scenes, but I need to play around with other WMs a bit first.
from glava.
Also, see this issue, as it may be related. I changed the default values for setfloating
and setfocused
to false in the default copy of rc.glsl
, as it's unessecary and seemed to cause issues with some WMs.
from glava.
I am unable to install KDE in a systemd-nspawn
container, preventing me from testing this myself. If someone else could play with addxwinstate
values and other requests on KDE, it would help me address this issue.
from glava.
I have the same problem @jpope777 described. I tried every single option from addxwinstate
and some combinations of the options, including the suggested, but to no success. problem persists in the exact same manner as the original problem. I have also tried setting setxwintype
to other options, but still nothing.
from glava.
It looks like I will have to write GLava as an actual KDE widget to get it to work correctly.
from glava.
probably better would be a wallpaper engine, because i don’t think you can maximize widgets. like widgets, the engines work by writing QML and usually a DataSource. QML also has a few ways to include custom OpenGL code
another way would be to create widgets from the modules, which would forego the glava config in favor of the config GUI that KDE users are accustomed to.
a third option is to get in touch with the KDE devs. they’re friendly, responsive, and helpful, and will try to help you to get your approach to work (or give you a friendly and well-reasoned explanation why it can’t)
from glava.
Note: KDE 5.12+ supports Wayland -- if you are using Wayland instead of X11, you will run into numerous issues with transparency, window hints, etc. Try to avoid using the Plasma (Wayland)
session when providing details on this issue, the aforementioned problems are separate from the problems mentioned here.
from glava.
#17 (recently fixed) may be related to the issues described here. Let me know if any of the fixes in unstable
or for the 1.3 release are fixed with the relevant commit.
from glava.
@aaahh that is extremely helpful. I will just implement this in GLava itself, see xwin.c
for how GLava handles most X11-related tasks (other X11 code can be found in glx_wcb.c
, but that is mostly for creating the OpenGL context).
xwinwrap
probably doesn't work because you would need to perform some (possibly terrifying) hacks to redirect the GLX context to the new window it creates. I wouldn't worry about it not working with GLava.
Unfortunately this will have to wait until at least Monday, though.
from glava.
Well I use it with mpv for example, as I can set the WID with a flag on mpv
I’m tweaking the code to modify the existing window rather than create one that is then passed. I already have code to modify an existing window and with XReparentWindow I can easily move it to the place I want
from glava.
@aaahh GLava (by default) will attempt to create a direct GLX context. This is probably why it's not working with xwinwrap
. See the documentation from Khronos for ARB_create_context
:
Direct rendering is requested if <direct> is True, and indirect
rendering if <direct> is False. If <direct> is True, the
implementation may nonetheless create an indirect rendering context
if any of the following conditions hold:
* The implementation does not support direct rendering.
* <display> is not a local X server.
* Implementation-dependent limits on the number of direct
rendering contexts that can be supported simultaneously are
exceeded.
Use glXIsDirect (see below) to determine whether or not a request
for a direct rendering context succeeded.
Ultimately, GLava should be able to position itself accordingly without xwinwrap
, so it's best if you either look to implement a solution in xwin.c
or wait until I do so.
from glava.
If anyone can comment on whether @aaahh's fork fixes the issue, it would help me decide whether to keep poking at this issue or to just close it.
from glava.
Doesn't seem to do much for me.
from glava.
set the window type to desktop
from glava.
No visible difference with @aaahh's branch or not.
from glava.
@ephemient and workspaces are still broken with GLava on the desktop (the topic of this issue)?
from glava.
If @aaahh's attempted fix using XReparentWindow
doesn't actually seem to fix the problem here, I will probably omit that code for 1.5. Calling XReparentWindow
might confuse some window managers anyway, as the window will already be reparented once to the associated frame window created by the WM.
from glava.
I just tried @aaahh's branch and GLava still disappears whenever I left click on the desktop on the setxwintype
set to desktop
.
from glava.
@jpope777
For the sake of experimentation
https://github.com/Aaahh/xwinwrap
Download that and run it with
xwinwrap -ovr -s mpv https://www.youtube.com/watch?v=TV1767i8X4Q
from glava.
@ujjwal96 This is great, I'll load Plasma over the weekend or some time and try implementing a proper fix into glava
Glava also suffers with multiple displays on ubuntu
from glava.
@wacossusca34 Yes, setting window type to utility
fixes the first issue.
For pinning you can see
https://github.com/GNOME/devilspie/blob/e3431f18c11a1a80fd846c899a3f16aa5ee91de0/src/actions.c#L380-L384
It uses libwnck
from glava.
The above commit allows the following line to pin GLava to all desktops:
#request addxwinstate "pinned"
The changes are non-breaking and don't affect anyone not using this option so I made the changes immediately to master
, but they are untested. If @ujjwal96 or @jpope777 could report if this issue is fixed by the above commit, I can finally close this issue and look at creating an option in GLava that automatically sets all the needed X11 atoms and window types for the underlying WM.
from glava.
Stacking order issues may be solved with #request addxwinstate "below"
, as mentioned in #54, due to the hint sometimes placing desktop windows in the same stacking order as other normal clients. If this works for kwin, then this issue can be finally closed!
from glava.
I thought I didn't have a problem with this so it might be my install but "below" does literally nothing. I used to use it and it used to work but I can't be certain. My xwinwrap works perfect with below so I'm blaming glava. Using any window type
from glava.
Haha jokes my WM is broken, I remember it working before but again I don't remember
window.window = XCreateWindow(display, window.root, window.x, window.y, window.width, window.height, 0, depth, InputOutput, visual, flags, &attrs);
if the parent is set to the root window it works.
from glava.
Pinning issues should be fixed in master
. Stacking order issues are going to be hard to address since KDE just plainly handles desktop windows strangely. I have created a new branch called kde_fixes
with two new approaches to fix GLava hiding behind the desktop when the background (or icons) are selected:
-
By default, the
glx
backend will parent the GLava window to whatever it finds as the desktop window. Usually this is the root window, but in Mutter this is a window titled"mutter guard window"
, and in KDE this is a desktop window with theWM_CLASS
property set to"plasmashell"
. Seexwin_get_desktop_layer @ xwin.c:28
for source. -
I have also added a brute force method to keep GLava above all other windows. At the moment it does this periodically, but I will find a way to get it to detect when it is no longer visible before merging into master (
VisibilityNotify
events do not seem to fire upon the window being masked). You can enable this using#request setforceraised true
in thekde_fixes
branch.
I'm not sure how these approaches will actually effect KDE and need testing. The first might do nothing, or further confuse the WM. The second will definitely keep GLava above desktop windows, but I'm not sure if it will also be placed above regular windows as well.
@ujjwal96 @jpope777 @ephemient @flying-sheep please report if the kde_fixes
branch improves the situation.
from glava.
I finally got KDE running in a container (after a jumping through a few hoops). I found a solution, but the above attempts just make the problem worse because:
-
Re-parenting the window causes KWin to throw a fit and will permanently hide the window (it still maps and renders fine, though).
-
Raising the window works, but only when a desktop window is selected. When normal clients are selected, you cannot raise a desktop window (???). This just makes raising GLava in KWin unreliable.
I discovered some strange things:
-
KWin hardcodes all desktop windows to have the
_NET_WM_STATE_BELOW
property set (to_NET_WM_STATE,
) for all desktop windows (_NET_WM_WINDOW_TYPE_DESKTOP
). Doesn't really matter what the application sets. -
KWin pretty much ignores every action on desktop windows except when grabbing input (focus).
-
KWin bugs the hell out of
"xroot"
transparency for me, but I'm usingllvmpipe
for rendering, and there's some oddity going on with the root window contents, and the plasma desktop. I may look into this later.
All this crazy nonsense when it comes to how the WM behaves with desktop windows in order to get the plasma shell to behave the way KDE developers want. Ideally, only the plasma shell should be subject to this treatment, probably with a KDE-specific property set on the window.
So I thought I should try "normal"
windows, with the "below"
state set (don't forget to disable borders and use native transparency). Turns out that works! No changes to GLava needed, but you can't click through to the desktop. @aaahh provided a fix for this in other DEs, going to try applying that here on normal windows.
from glava.
And it turns out the fix for click-through that @aaahh provided works like a charm on KDE! I think I'm going to enable clickthrough by default. At the moment, you will want the following options for KDE (in addition to defaults):
#request setdecorated false
#request setxwintype "normal"
#request addxwinstate "below"
#request addxwinstate "skip_taskbar"
#request addxwinstate "skip_pager"
#request addxwinstate "pinned"
This should finally conclude this issue. Don't use real "desktop"
windows on KDE. Also, the kde_fixes
branch is garbage, don't use it.
from glava.
The latest changes to master
provide the above fix built into GLava. Just run with the --desktop
flag now.
from glava.
Testing this further, it looks like "Show Desktop" (Ctrl + F12
by default) will still hide the GLava window, although it restores itself when you select normal clients afterwards. Not a major issue, but I intend to fix it.
Turns out KDE has some (undocumented?) protocols: _KDE_NET_WM_TEMPORARY_RULES
can be used to send non-standard rules to the window manager, including a 'force' below/above rule that strongly asserts the stacking order in KWin itself. For some reason the default EWMH below state is weaker, and only verifies the stacking order when regular clients are selected.
I had to dive into the source of KWin and kstart5
to figure this out. All of this insanity should just be default for desktop windows (like in other window managers!). Fun fact: conky suffers from these same issues and requires users to manually set window rules in KDE's "Window Management" settings menu.
from glava.
Continuing the troubleshooting we've been doing on Reddit, I have more information after testing the latest master
. Upon running it for the first time, this was returned:
$> glava --desktop
Using backend: 'glx'
No presets for current desktop environment ("KWin"), using default presets for embedding
Failed to load default presets at '/home/scar45/.config/glava/env_default.glsl': No such file or directory
I copied the env_default.glsl
from the source shaders
directory into my ~/.config/glava
directory, and then ran GLava with the --desktop
flag. Everything started up fine, but when I clicked my desktop, GLava disappeared again. I'm not sure if I've done something wrong, or if there are no sane defaults for KWin per the message in stdout? Even after I copied the env_default.glsl
file under .config/glava
, I still get the "No presets for current desktop..." warning, though maybe this is safe to ignore.
I've also used the following params at the bottom of rc.glsl
:
#request setdecorated false
#request setxwintype "normal"
#request addxwinstate "below"
#request addxwinstate "skip_taskbar"
#request addxwinstate "skip_pager"
#request addxwinstate "pinned"
Happy to help troubleshoot more when possible, and I hope I am not doing something wrong myself either. I've also recorded a quick video demo which shows the behaviour with these latest tests. Note that I am using KWin with compositing on, in a VM with a GeForce 1050Ti host GPU, and latte-dock
is what blurs GLava.
from glava.
@scar45 see my reply to you on reddit:
Yeah, you need to copy over
env_KWin.glsl
, as those are the settings for your window manager. Normallyglava --copy-config
will do this for you, but if you update with an older config, then you need to either run that again (will overwrite files) or copy over the files you want yourself.Alternatively you can build GLava with
make INSTALL=standalone
and then run it in-place with./glava
, to use the configuration files in theshaders
directory of the repository.
Also, note:
I've also used the following params at the bottom of rc.glsl [...]
Setting these flags with the --desktop
flag in your rc.glsl
will have poor results, since the --desktop
flag looks for presets in env_*.glsl
files and ignores addxwinstate
options in rc.glsl
to prevent conflicts. Additionally, the default presets will override to desktop window types, which are horribly broken on KDE (outdated).
from glava.
I had to dive into the source of KWin and
kstart5
to figure this out. All of this insanity should just be default for desktop windows (like in other window managers!). Fun fact: conky suffers from these same issues and requires users to manually set window rules in KDE's "Window Management" settings menu.
I am quite sure I didn't do that. I just edited the conky file according to this.
own_window_type normal
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
Window type set to desktop actually makes conky not transparent for me.
Back to Glava... I took this to wmctrl
(not to say the #requests
doesn't work, but even if I set the exact stuff as conky has... doesn't cut it).
wmctrl -r KWrite -b add,skip_taskbar,skip_pager
- works as expected - kwrite disappeared from the taskbar.
wmctrl -r KWrite -b add,below
- works as expected.
Now, I did the same in glava, after I commented out the requests in my rc file. I even recopied the configs. I noticed that whatever I do, wmctrl doesn't do anything to glava.
from glava.
I am quite sure I didn't do that. I just edited the conky file according to this.
The conky config you linked is precisely what GLava does/allows, look at the hints themselves.
Now, I did the same in glava, after I commented out the requests in my rc file.
Note that if you are using --desktop
, it will prioritize options from env_KWin.glsl
. If you updated an existing older install, you will need to copy over the new configs/shaders. You shouldn't really need to set anything yourself, as I'm trying to provide defaults for each WM that handles these issues gracefully.
You didn't really specify what the problem with GLava's window was. Is it not visible, or is it just stacking issues again (ie. stuck under wallpaper)? If it's not visible to do off-screen placement, I have noticed that KDE saves window positions and will happily ignore where applications initially map their windows to. You can work around this at the moment with #request setforcegeometry true
.
I noticed that whatever I do, wmctrl doesn't do anything to glava.
That's weird. You should verify it's setting the atoms properly with xprop
-- if it's not, it could be a bug with wmctrl
. Otherwise, it could be the window manager just not reading changes due to some strange combination of GLava's hints and wmctrl
.
from glava.
@wacossusca34 well again, seems to me that GLava is treated a bit differently. wmctrl -r
ignores it but wmctrl -l
finds it. "above" in kde plasma doesn't also mean above fullscreen thus glava is not also above fullscreen apps, and the taskbar is skipped and all but the alt+tab
is not (though conky is).
Glava shows fine for me. I can click through, it is above (not fullscreen stuff). I just pointed out that wmctrl doesn't apply rules to it.
from glava.
@RaitaroH you might want to try "above"
with other window types, like "dock"
or "splash"
. Also, KDE doesn't list desktop windows in its client list, which wmctrl
reads from, so that's where your issue is.
from glava.
@RaitaroH unfortunately "above" windows are going to have X11 and/or WM limitations, especially with fullscreen windows that use the override_redirect
attribute. Windows that use _NET_WM_STATE_FULLSCREEN
seem to have similar restrictions on many WMs, including my own.
If you want anything to be visible above fullscreen windows it will need to maintain focus in most (if not all) WMs. To do this, you will need to use a less-than-optimal solution, but I have already written it into GLava since I expected some people would want forced focus:
#request setfullscreencheck false
#request setforceraised true
setforceraised
is unusable on my WM and I predict it will cause problems on KDE. It's deprecated because it essentially steals focus repetitively (edit: outdated):
static void raise(struct glxwin* w) {
XClientMessageEvent ev = {
.type = ClientMessage,
.serial = 0,
.send_event = true,
.display = display,
.window = w->w,
.message_type = ATOM__NET_ACTIVE_WINDOW,
.format = 32,
.data = { .l = {
[0] = 1, /* source indication -- `1` when coming from an application */
[1] = 0, /* timestamp -- `0` to (attempt to) ignore */
[2] = w->w /* requestor's currently active window -- `0` for none */
}
}
};
/* Send the client message as defined by EWMH standards (usually works) */
XSendEvent(display, DefaultRootWindow(display), false, StructureNotifyMask, (XEvent*) &ev);
/* Raise the client in the X11 stacking order (sometimes works, can be blocked by the WM) */
XRaiseWindow(display, w->w);
XFlush(display);
}
So unless you want to juggle window focus around, you are not going to be able to see GLava on top of fullscreen windows. It's possible to write a better focus-grabbing implementation that works only when windows are fullscreen, but it gets complicated when you want to interact with the fullscreen window since that will cause the WM to restack the window -- I would then need to listen to visibility notify X11 events to raise immediately after, which still might briefly cause GLava to lose visibility.
At this point I'll make two final suggestions for your issue (#65):
-
Use
wmctrl
orxprop
to get GLava focused and have it bound to a key on your system so you can focus it when you want. This should get around your issue of not having GLava present in youralt+tab
menu, and will work for fullscreen windows you don't want to interact with (ie. a video). -
Modify the fullscreen window instead to be 'fullscreen borderless'. This involves making the application borderless, not fullscreen, floating, above all windows, and positioned and sized to cover the entire screen. GLava's
"above"
window state with a dock/utlity window type will likely work this way.
The latter suggestion is undeniably the best option here, but it's something better suited to external utilities (wmctrl
) to accomplish that.
edit: also see added "!+"
unmanaged window type
from glava.
It's worth noting some users have ran into placement issues on KDE when KWin tries to re-position GLava when its window is mapped, probably from some saved position. This is fixable via setforcegeometry
, however, that is not an optimal solution due to using periodic X11 calls. Unfortunately this may also require usage of non-standard protocols for KWin.
from glava.
Is there a way to get transparency working on KDE (KWin)?
With setopacity "native"
the background stays black and with setopacity "xroot"
weird things happen (backgroud filled with previous window content but not cleared).
from glava.
@wacossusca34
Ok so I will post here my kwin config:#request setdecorated false #request setxwintype "normal" #request addxwinstate "undecorated" #request addxwinstate "above" // #request addxwinstate "below" #request addxwinstate "skip_taskbar" #request addxwinstate "skip_pager" #request addxwinstate "pinned" #request addxwinstate "sticky" #request setclickthrough true
Keeping everything the same.... but changing window typing:
- normal
[x] minimize all will minimeze glava
[x] glava appears inalt+tab
[x] stays above other windows
[ ] stays above fullscreen applications- splash
[x] minimize all will minimize glava
[ ] glava appears inalt+tab
> thus I cannot focus it in order to stay above fullscreen
[ ] stays above other windows
[ ] stays above fullscreen applications- dock/utility
[ ] minimize all will minimize glava
[ ] glava appears inalt+tab
[x] stays above other windows
[ ] stays above fullscreen applications
Also#request addxwinstate "skip_taskbar"; #request addxwinstate "skip_pager"
doesn't matter here.- desktop
[x] takes over the desktop entirely: no wallpaper, icons; after a click it dies...
[ ] minimize all will minimize glava
[ ] glava appears inalt+tab
[ ] stays above other windows
[ ] stays above fullscreen applicationsSo after all that I can say that... dock is the least intrusive but if you want glava to stay on top of fullscreen stuff you need to have it appear in the
alt-tab
switcher and focus it. if #65 would be fixed then awesome.
Your config is totaly working, I got some workaround though. If using KDE, there is a section in KDE settings called Window Rules. Try to make changes there and set the window type to ! in rc.glsl and set the window type there, it shall fix the problem. I setted to dock(pannel), it works perfectly except above all desktop icons. for my condition.
from glava.
Hello, I don't know if this is useful enough, but setting a new window rule like given in the image below seems to solve this problem
I have set the window type for glava to be a dock
Doing the same in the config file doesn't seem to have the same effect of fixing this issue.
from glava.
Doing the above does work, but glava then won't correctly detect when it's fully obscured, so performance may suffer in that case.
from glava.
Related Issues (20)
- Manjaro KDE setup no longer works after unplugging and replugging the monitors
- Glava stops running after some time
- Idea: add ALT-F4 ignore flag or config option
- cant figure out how to change the color of glava or resize glava when it is embedded to my desktop
- Transparency not working in Arch Linux with KDE Plasma (KWin) HOT 1
- How to uninstall Glava from Ubuntu HOT 1
- ninjac -C build throwing error while installing. HOT 1
- [Request] desktop mode support for qtile.
- Glava starts on wrong screen
- Would you please clarify in the readme if this works on xwayland, i.e., on Ubuntu 22+ HOT 1
- Problems with audio input
- Is this project dead? HOT 6
- AUR package fails to install with yay on artix HOT 1
- Wayland support. HOT 14
- error when executed "ninja -C build" command as given in readme.md, what is it, how to resolve? HOT 3
- can't build glava on Freebsd due to missing dependency error HOT 1
- Glava is showing on top of all windows
- --define similarly to --request
- Failing to build libglava.so: libglava.so.p/glava_glsl_ext.c.o:(.bss+0x0): first defined here
- Clickthrough with Wayland (Plasma 6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glava.