Hi everyone, I have written a C++ library for creating native GUI apps, it also has language bindings for Lua and JavaScript (V8).
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.
What part of electron gets used? Why would it be used? Is it to package an app?
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?
Those two statements do contradict each other. According to my own quick analysis, this library uses truly native controls on Mac and GTK+, but its own windowless implementations on Windows. The Windows control implementations use uxtheme so they look more or less native, but that's not "native controls" as far as I'm concerned.
If better skinning is the intended advantage, then it's apparently not implemented yet. I would also like to know the developer's reasoning, since using non-native controls makes it much harder to support accessibility, and this library hasn't yet addressed that.
I think it's easier to port your own drawing code from platform to platform. That's probably why Firefox and Chrome can be multi platform because their rendering code is the same.
Doing a cross platform UI library that uses native controls seems a lot of work.
> 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.
Are you the same developer Roger Wang wrote about in his "Statement on the history of node-webkit project" public post?
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.
Definitely, and those same claims are made in the yue docs.
>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.
" Furthermore, the Intel copyright notices were removed and were replaced by GitHub copyright notice in Electron when pieces of code was copied and derivative work was made from some code of node-webkit " ....
" 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" ...
>If you are wondering how this library is different from other GUI toolkits, check out the FAQ
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.
Is that as amazing as I think it is? The Electron killer, the Holy Grail of UI frameworks, the El Dorado of cross-compatibility, the One Library to rule them all?
I'm sure this is an amazing project. But the readme and FAQ and such have such an aggressive, almost hostile tone---if you want to communicate with the author at all, even to report a bug, it'll be five thousand bucks a month...
No need to say sorry, it is clear, succinct, and reasonable. Most projects don't offer the option for premium support (which is also reasonably priced, fyi). I'm not sure what the comment above me is/was expecting.
I don't get that either.
Also look at https://github.com/yue/help. The author is basically saying "I'm a really cool developer, was there, did that, anything else?". Every single sentence consists of narcissism (or how should I call that?). This is only how I see that, I'm sorry if I offended somebody.
I'm not a native speaker either, but having a quite high exposure to English language, I am still puzzled at why would anyone think those sentences were hostile. Can any native speaker translate what I quoted to a non-hostile version, so we can see what's it all about?
> The issues page of this repo is disabled on purpose, 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.
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.
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.
The author is trying to sell a freemium product, its a gift insofar as Dropbox's 2 gigs are a gift. (EDIT: maybe the premium support is more to support this project than being the main objective. I don't mean to assume too much on motives)
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
> The author is trying to sell a freemium product, its a gift insofar as Dropbox's 2 gigs are a gift.
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.
No, the point made was that the author was unnecessarily aggressive. That does not imply that the author was not genuine.
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.
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.
I'm not expecting it to be free but 5000 usd for just for the right to not redistribute it when you modify the source, seems a bit expensive, but maybe I'm just a poor fella
It's just a standard grant of copyright for contributions to an open source project. Your code will still be available to you under the same license as the rest of it. It just might be incorporated in the differently licensed (paid) version.
Nifty! I look forward to (hopefully/eventually) someone making Go bindings for this :)
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.
Im very confused what is going on here. He works for electron full time but is releasing something else thats basically the same with more confusing terms?
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).
Is there any open source project where the author retains copyright?
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.
> Is there any open source project where the author retains copyright?
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.
I don't understand what point you're trying to make. The tone of your comment comes across as if you're refuting/disputing something (that may be implied?) in what I wrote, but I'm not sure what it is.
While a CLA is necessary for a dual-licensed project, it doesn't have to include a transfer of copyright, and many don't. E.g. Google's doesn't, the one for Python doesn't. On the other side, the ones for MongoDB and the FSF do. (At least MongoDB's is also clever enough to have a fallback to pure licensing, since "transfer of copyright" isn't possible in some jurisdictions)
And of course there are tons of Open-Source projects that don't have CLAs at all.
I don't get why you're so attached to a PR you make to another library. So you're not contributing because you want to improve that other library, you're contributing because you want to sue them after so theycan pay you for your share of the project since you've added 10 lines of code?
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.
> 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.
With Yue's license you can change the code, compile and dynamically link without releasing your own code.
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.
It'd be really helpful if there were screenshots of a sample app from each supported platform. Is this wrapping native elements or providing custom elements?
If I'm understanding you correctly, what you've asked for is already there. Follow the "Sample Apps" link to here https://github.com/yue/yue-sample-apps and then click on one of the sample app directories and there are screenshots.
With a quick glance, I learnt about the intrincate details of the license. However, I have no idea of the technical details behind the library or how the relevant code may look like (note that I can go to the sample sources, but without a proper introduction it takes some work to follow).
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.
Right, So I am doing a research project and If I want to use this library in that project, does that mean I have to pay to use it. My project is currently closed source , because don't want anyone to steal stuff before I publish my paper. After that the code goes public.
Unfortunately, this library has no support for accessibility, e.g. for blind users with screen readers, particularly on Windows, where it implements its own windowless controls without implementing the UI Automation API. So I advise against using this library for any application with a broad target user base until this problem is addressed.
For being a library designed to assist with creating cross-platform GUIs, the website itself—which should give a good first impression of the project's attention to user interface details or user experience—is a joke.
Compounded with the other HNer's comments regarding its licensing, make your own judgments.
Your last sentence, "How would you respond to these?", is fairly passive-aggressive. Pointing out the issue (use of LGPL code with a license that does not permit it) is sufficient.
I don't see that the author has clearly copied anything there. Maybe he did, maybe he didn't. This situation only proves open-source licensing is in a bad shape.
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".)
The comments, flow control and variable names are the exact same, and the comments at the top of the file have the same emails as the WebKit source code. If that's not a clear cut sign of plagarism, I don't know what is.
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.
105 comments
[ 2.9 ms ] story [ 171 ms ] threadIn 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.
https://github.com/yue/help
" 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.
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
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.
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.
https://github.com/yue/yue/tree/master/docs/paid_plans
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...
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.
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).
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.
1: https://github.com/yue/yue/graphs/contributors
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.
> 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:
> 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.
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.
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.
Vue Yue Vue Yue Yao Yue.
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.
https://github.com/yue/help/issues/4
https://news.ycombinator.com/item?id=15219048
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.
0. https://sciter.com/
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.
Its a WIP