Show HN: Yue – A new library to create cross-platform GUI apps
github.com
github.com
You're using large parts of WebKit source code (LGPL) in your proprietary library. This is against the license. Please compare:
https://github.com/yue/yue/blob/master/nativeui/gfx/gtk/pain...
https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
Created an issue for this to prevent anyone else using it.
Let's see how the author will respond.
Actually it is horrible. See, for example, the criticisms and questions being raised on the whole thread about this library.
(Until anyone point a better alternative, I'm for "if you don't want anyone using them, don't publish your sources".)
What makes it proprietary?
Bad choice of words on my part, and I can't correct my comment anymore. That said, LGPL works still aren't compatible with MS-RL, so you can't distribute the combined work as MS-RL.
> But once you have done modifications to Yue's source code, all your code linked with Yue have to be open sourced with MS-RL. The only way to remove this limitation is to subscribe to Yue's paid plan.
> The license seems like a non starter.
> Note that the license of Yue has less restrictions than LGPL, it does not require you to open source your project when you statically link with Yue, or compile Yue's source code as part of your project.
> So if you are fine with LGPL libraries, there is no reason to worry about Yue's license.
> Yue is just another open source project with dual licenses, and it has less restrictions than most dual licenses projects.
With the LGPL you can change the code, compile and dynamically link without releasing your own code. It's a significant difference.
There is no difference here.
Lest you doubt:
Reciprocal Grants- For any file you distribute that contains code from the
software (in source code or binary format), you must provide recipients the
source code to that file along with a copy of this license, which license will
govern that file. You may license other files that are entirely your own work
and do not contain code from the software under any terms you choose.> The Yue project is under the Microsoft Reciprocal License (MS-RL) with following clarifications: [...]
Using a modified version of this software is considered as containing this software's code, so any code linked to it has to be licensed under MS-RL.
That at least to me reads like a different interpretation, which is worrysome.
In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.
If you want to see some screenshots and example code, check out the sample apps repo: https://github.com/yue/yue-sample-apps.
If you are wondering how this library is different from other GUI toolkits, check out the FAQ: https://github.com/yue/help#faq.
If you want to learn this library quickly, there is a detailed tutorial on using Yue with Node.js: http://libyue.com/docs/v0.2.0/js/guides/getting_started.html.
In particular, does Yue spawn the Chromium processes and Blink?
If I understand correctly, one can build JS interfaces in Yue without it, though (either with Node.js or with its Yue-specific fork, Yode). It uses Chromium base, but not Blink, right?
> Uses windowless controls on Windows;
Don't these contradict each other? What do you mean under "windowless" and why it is important?
Btw, you can list particular advantages/comparison at least over top 3 popular C++ cross-platform UI toolkits: Qt, wxWidgets, Gtk+/Gtkmm.
Doing a cross platform UI library that uses native controls seems a lot of work.
Are you the same developer Roger Wang wrote about in his "Statement on the history of node-webkit project" public post?
https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...
He claims you misrepresented the scope of your work as an intern on the node-webkit project (now named nw.js), and that you removed copyright notices from code in Electron that was derived from node-webkit.
>I had been the solo developer of Electron and node-webkit (now known as NW.js) for a very long time, and today big corps are building their new apps on them. So I think it should not be hard to be confident about Yue.
" I wouldn't like to spend time on this, but as the previous co-maintainer of node-webkit project, keeps spreading misinformation about his internship work in the node-webkit project on his blog post" ...
Why are you misrepresenting your work..
I see no details at all about how this library is different [or not]. While not an UI expert, I have some low-level experience with gtk, qt, appkit and uikit, vcl, immediate ui, and full manual drawing / event processing. When considering new ui framework, these questions are of high priority: how does it integrate with, or supports for, existing custom run loop; what layout system is used and which problems it elegantly solves (i18n, baselining, excessive boxing, complex constraint cases); how does it implement repeating cell rendering and caching, if any; what are base classes and how metamechanics like scrolling/resize/animation/state cues are distributed across these; how does ui state interact with controlling entity and vice versa; which non-ui mid-controllers exist to reduce or abstract out basic boilerplating. Without these details, it is yet another "throw edits, buttons and labels to fixed form and call it a day framework" at most. UI is usually hard because of internals and extension, not because it lacks fixed functionality. Web is partly so popular because it feels like everything is possible from the styled box primitive (but has its obvious downsides; like a 100mb complex c++ rendering engine that only few groups in the world can implement correctly and somewhat effectively on latest i7). Without all this and many more, there is nothing to reason about — ui is not a yesterday's demand, and regular cases are covered by virtually any mature library. Drawing static hearts with beziers is not a big deal.
Tbh, I'm highly doubting any of listed topics can be designed in just one version step, because even most decent frameworks have so many hidden flaws that require insane efforts to overcome under specific requirements.
It would be great to see how it is actually better, e.g. by comparing side-by-side examples of solving normal-to-hard ui tasks in different libraries.
And as explained in the FAQ, you can always go to the yue/help repo to report things and I will read them.
>To report a bug, you have to create a pull request with a test case of your problem, or you can choose to subscribe to paid plans.
Polite translation:
> The issues page of this repo is disabled. To report a bug, please create a pull request with a test case of your problem.
> For support, please go to the yue/help repo for help from the community. Paid plans are also available if you want to receive support from the project maintainers.
I wouldn't say the original is exactly impolite, but it's definitely more curt and direct than usual or than you would expect in the business world. Especially the text on the yue/help repo comes across as slightly combative or defensive in different areas. For example "You can ask any question about Yue in the Issues page here, but please do not expect to get an answer" sounds fairly dismissive to a native ear.
That's not quite true - the other option is to provide a pull request with a test case showing the bug.
The author literally says: "for help please go to the yue/help repo where users help themselves.
To report a bug, you have to create a pull request with a test case of your problem, or you can choose to subscribe to paid plans."
What's exactly hostile there?
The author gave you, the potential user, a gift, totally free of charge, and even explained politely where and how to find help. They even organized a premium support, if someone's problem is so important that it needs extra care.
I'm still puzzled...
Some small modifications to the text can make the messaging more friendly. For example "To report a bug, please create a pull request with a test case of your problem." (instead of "you have to")
It's a small change, but conveys the same requirements without conveying a notion that the reader is a burden. Instead it just asks a favor, since we're all humans talking to each other in good faith.
It seems small, it seems pedantic, but we're guided by our emotions. The fact that this thread exists is proof that it affected at least some people enough to comment about it
In other words, it is a gift. You get something useful for nothing.
As for the other point, I agree that the author should use more business friendly tactics if he wishes to sell his services better, but that was not the point. The original complaint was that his approach is somewhat offensive. Which I didn't agree with. I think his approach was genuine, if not very skillful.
The attitude of the author is definitely relevant to whether the library can and should be relied upon for inclusion in a project. Personally, this is a non-starter if I can pick up such a hostile, anti-community tone in a two minute review.
Examples:
> You can ask any question about Yue in the Issues page here, but please do not expect to get an answer.
> I know, and probably I know it better than you, I have been a long time open source project maintainer.
> To report a bug, you have to create a pull request with a test case of your problem, or you can choose to subscribe to paid plans.
I think "I'm an engineer, to save time let's just assume I'm always right" is the maximum size for a T-shirt joke.
I'd suggest putting more emphasis in the library details, and why it is good (not just how good it is) especially before all that licensing information.
Nevertheless I'm still afraid that features / maintenance will be unsustainable, since you are the only developer [1] ( considering your expertise ).
I hope there are companies that support the project.
I'm not even a potential user of this library. I'm just amused with how people expect open source programmers to work for peanuts.
https://github.com/yue/yue/tree/fb08ff884c6f9b7fb7a767dde937...
Nope.
I mean in this case I'd say the copyright is transferred to a nameless entity, e.g. "the Yue project". IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
Yes. Pretty much all the most successful FOSS projects operate like this by default—there's no central authority and contributors retain their copyright. It's only in the last couple years or so that a weirdly high amount of orgs even started cargo culting the CLA process. And the reason for the CLAs seems to be that this was happening for nascent, quasi-corporate projects from orgs who were making their foray into open source and were under the impression that this is just how everyone else was already doing things. Meanwhile, back in reality, the old standards and posterchildren for open source were actually humming along with no CLA in sight. (E.g., Linux, Mozilla.)
The CLA trend is waning, though, as people realize that they were never necessary, they only really only introduce friction to contribution process, and the only reason anyone ever adopted them was because they were looking around and trying to emulate each other. (You know the phenomenon where someone seems to be famous just for being famous?) Projects that came about during this time (e.g. NodeJS) have actually been getting rid of their CLAs.
EDIT:
> IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
This is not true wrt Google. Contributors retain their copyright. Where did you learn otherwise? Comments like this are how famous-for-being-famous happens.
A CLA is still necessary in some form in this case for the owner of the repo to re-license the product under the commercial dual licensing scheme.
And of course there are tons of Open-Source projects that don't have CLAs at all.
As stated else where it seems like author has copied/forked existing project. Then (if I understood the license correctly) you are required to open source your software if you were to use the library, or pay $5k. On top of that if you contribute to the project you sign away your copyright.
If these things are correct it seems like a one hot mess of a project.
With that said, it would be nice if the sample apps included more components of the native UI. Eg, a bunch of buttons, text editors, etc - a sort of kitchen sink screenshot. Just to understand what it looks like on each OS. All the samples I saw so far seemed very limited, visually.
With modern high-DPI monitors, when number of pixels is 4...9 times larger than on old 96ppi monitors, non-GPU rendering is not an option anymore.
As far as I understood Yue is a GUI toolkit that wraps the platforms' native widgets, whereas Electron is a Node runtime and a Chromium instance (which lets you build GUIs with web technology).
Its a WIP
Maybe now we'll finally see accessible and efficient GUI apps from those who insist on writing desktop applications with JS.
Too bad it ignores accessibility entirely: https://news.ycombinator.com/item?id=15219025
As long as you don't make any changes, sounds like it's free and unrestricted.
Compounded with the other HNer's comments regarding its licensing, make your own judgments.
Edit: Not trying to start a controversy or anything, I've never seen the Microsoft Reciprocal License before, it just looks like a similar idea. I'll just go look it up.
Vue Yue Vue Yue Yao Yue.