wayland-explorer
GoJS, a JavaScript Library for HTML Diagrams
wayland-explorer | GoJS, a JavaScript Library for HTML Diagrams | |
---|---|---|
25 | 13 | |
175 | 7,439 | |
- | 0.6% | |
7.8 | 6.1 | |
13 days ago | 7 days ago | |
TypeScript | HTML | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wayland-explorer
-
PCSX2 Disables Wayland Support
Wayland is good until you hit the corner cases that they decided to abandon, without leaving any alternatives. We can always have extra protocol that can be optionally enabled, but good luck with standardizing that. It feels as if Wayland people are abusing their committee to keep Wayland as-is, instead of extending it. The protocol dashboard[1] doesn't look exactly good.
[1]: https://wayland.app/protocols/
-
Inter-process Communication between two programs on Linux.
Wayland is itself an IPC system (that uses UNIX domain sockets). I would make a custom Wayland protocol (if there isn't already an appropriate one available, look here: https://wayland.app/protocols/). You can define the protocol in XML and generate the boilerplate code in C using wayland-scanner. I assume smithay also has an equivalent of wayland-scanner.
-
The reality of Wayland input methods in 2022
https://wayland.app/protocols/ and https://wayland.freedesktop.org/docs/html/ are just API references.
-
Swingland: Recreating Java Swing for Wayland
Given I will be using most of the Wayland protocol to achieve anything (it's minimal) and Wayland is well specified then the 'start at the bottom and build up' design pattern fits. Wayland has a wire protocol based on a Unix socket, and usefully Java has supported Unix sockets since release 16, so I can write everything in Java to (de)serialise messages. This gets me going quickly, providing positive feedback that I'm on the right track..
-
Red Hat considers Xorg “deprecated” and will remove it in the next RHEL
The core is bare-bones, there are numerous standard protocols since, and many other are in standardization. Here is a site to review their state: https://wayland.app/protocols/
-
Unix philosophy and compositor development
There is some lock-in in some places where tools adopt a protocol that is only implemented by wlroots compositors, or only implemented by KDE, etc, but I suspect this will improve over time as protocols stabilise ( and you can browse the available protocols here: https://wayland.app/protocols/ )
- Wayland Explorer
-
X12
This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.
A few key points:
1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.
2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.
3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.
4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.
5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.
6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!
- A better way to read Wayland documentation
-
Is it placebo or is X11 more stable than Wayland
So that brings me to Wayland Protocols!. In X11 land, X11 defines a lot of behaviors for you. There is no such definition in Wayland-land by design - this is to give compositors a lot more freedom and flexibility in how they function. It also means that it required time for protocols to develop to cover all of the things that we would need in a desktop window compositor to bring it up to snuff for desktop usage. These protocols evolved through the past 4-5 years of everybody seeing it's shortcomings on a Desktop system compared to a mobile phone based UI. With the latest fractional scaling protocol we have more or less finally "closed the gap" between Wayland and Xorg on the desktop - it's just a matter of compositors implementing full support for all of the protocols people want.
GoJS, a JavaScript Library for HTML Diagrams
-
Burning money on paid ads for a dev tool – what we've learned
Have spent six figures yearly on ads, mostly for reach for the developer-focused diagram library GoJS (https://gojs.net)
> Each experiment will need ~$500 and 2 weeks
I would add a zero if you want serious data. I would also double the timescale. $5,000 over 4 weeks
I second the uselessness of Google Display, it might look like conversions numbers are good but they are 100% too good to be true. As soon as you look into them you find the sources are things like "ad from HappyFunBabyTime Android app". You have to ruthlessly prune daily for months to get anything real, and even then I'm skeptical of value. For a developer tool with very strict conversion metrics!
But I disagree on Google Search:
> Good for conversion, bad for awareness.
Before we were popular it was excellent for awareness. Post popularity its much more arguable.
-
Purescript bindings for GoJS
Creating the Halogen components would be simple enough if one takes inspiration from gojs-react. The issue is that there are no PureScript bindings for the GoJS types themselves, but GoJS does provide .ts.d declarations, which means I could use purescript-read-dts, but that library's maturity/usability seems somewhat ambiguous, according to an author's post from 3 years ago.
-
Any Ideas How to Create a Graph Builder UI in React?
used goJS in one project and konva in another
-
Ask HN: What is the most impactful thing you've ever built?
I built GoJS, which is one of the most popular commercial JS diagramming libraries: https://gojs.net
I built carefulwords, a very fast thesaurus and quote site for inspiration, used by... tens of people a day. Eg: https://carefulwords.com/gift https://carefulwords.com/solitude
I mostly made it for myself, me and my wife use it all the time. I am slowly editing down the thesaurus to managable size.
I built a 12x16 "Goose Palace" barn out of local pine timbers, which taught me timber framing, and taught my tiny baby who turned 2 years old while doing it that this is just the kind of thing that people normally do, build barns in their driveway. Some context: https://simonsarris.substack.com/p/the-goose-palace
Some photos of building it with the baby: https://twitter.com/simonsarris/status/1584169368203956225
I designed my house, and have been writing extensively about that. Maybe this is the most impactful, since photos of it are all over Pinterest and other sites, now. The first post on that: https://simonsarris.substack.com/p/designing-a-new-old-home-...
I am not sure what is most impactful. Maybe ultimately it is building my family.
-
Node-Based UIs
I made a pull request for GoJS (https://gojs.net)
I have been building this canvas-based graphing library since 2011, and it contains a good number of features around customization and interactivity that are not found in other libraries. It is commercial for non-academic use however.
-
Where I can learn how to do the following in React?
in one project we use konva, in another we used gojs. Any of them or some other library needs some training and introduce own limitations but it still way way way better than handing all the coordinates, calculations, routing etc on your own.
-
TypeScript is terrible for library developers
I am really surprised by this guy's opinion. I make GoJS (https://gojs.net/), a diagramming library written in TypeScript. The project began in 2011 and we converted it to TS in 2018. It's been a huge plus. The sole downside was the initial time it took during conversion, but even in doing so we caught bugs with incorrect input types, documentation mistakes, etc.
On our end, it enforces type safety better than the Google Closure Compiler. There has scarcely been a problem with type complexity that was not ultimately our fault. Just a couple minor things that TS amended later. For that matter the TS experience has only gotten better, generally.
On our users end, we can now give them a .d.ts file that's much richer and easier for us to produce to aid their autocompletion. And we can use that .d.ts file to ensure that all the methods we intended to expose/minify are getting exposed. The advantages with the .d.ts and documentation make it feel almost essential to me for library developers to consider TS.
TypeScript has only made debugging easier, much easier since it catches errors at time of typing unlike the closure compiler. The sole exception is that debugging is a bit slower since I have to transpile instead of just refreshing the browser. But I have tsc set to compile a relatively unminified version of the JS. But if the slowness gets to me, I can just edit the JS output until I solve the issue, and then carry those edits over to the TS. This has never felt like a problem, though maybe his library is significantly more complicated.
Feel free to ask me anything if you have questions about library design + TS.
-
Ask HN: How to quickly animate sketches and 2D diagrams?
GoJS might work for you: https://gojs.net
Although the focus of the library is interactivity and not setting up sequences of animation, but that is possible too.
-
It's always been you, Canvas2D
My livelihood has been primarily building a Canvas diagramming library since 2010 (https://gojs.net), if anyone has any questions about 2D Canvas use in the real-world I'd be happy to answer them.
roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). I'll have to do some performance comparisons, since that's the operative thing for my use case (and any library author).
text modifiers are very welcome. It's crazy how annoying measuring still is, especially if you want thinks to look perfectly consistent across browsers. Though the chrome dominance is making things easier in one way, I guess.
context.reset is kinda funny. Most high-performance canvas apps will never want to use it. For that matter you want to set all properties as little as possible, especially setting things like context.font, which are slow even if you're setting it to the same value. (Or it was, I haven't tested that in several years).
I'm sure most users know this by now, but generally for performance the fewer calls you make to the canvas and the context, the beter. This is even true of transforms: It's faster to make your own Matrix class, do all your own matrix translation, rotation, multiplication, etc, and then make a single call to `context.setTransform`, than it is to call the other context methods.
-
Problem with some gojs gantt model
I have some problem with gojs(https://gojs.net/),
What are some alternatives?
Pion WebRTC - Pure Go implementation of the WebRTC API
d3 - Bring data to life with SVG, Canvas and HTML. :bar_chart::chart_with_upwards_trend::tada:
kondo - Cleans dependencies and build artifacts from your projects.
draw.io - draw.io is a JavaScript, client-side editor for general diagramming.
tera - A template engine for Rust based on Jinja2/Django
react-vis - Data Visualization Components
gnome-gesture-improvements - Touchpad gesture improvements for GNOME on Wayland/X11
three.js - JavaScript 3D Library.
Zip Foundation - Effortless ZIP Handling in Swift
fabric.js - Javascript Canvas Library, SVG-to-Canvas (& canvas-to-SVG) Parser
rupy - HTTP App. Server and JSON DB - Shared Parallel (Atomic) & Distributed
joint - A proven SVG-based JavaScript diagramming library powering exceptional UIs