4 ms·

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 t

by zcbenz 9y ago

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. If you want to see some screenshots and example code, check out the sample apps repo: https://github.com/yue/yue-sample-apps 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 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 http://libyue.com/docs/v0.2.0/js/guides/getting_started.html.

Vinnl 9y ago
Am I correct in my understanding that this does still use Electron? (And if so, what is it used for?)
- zcbenz 9y ago
  It does not use electron, it is total native and does not use web engines, but it can be used in electron as a Node.js mudule.
  - GrayShade 9y ago
    It might be a good idea to have some C++ sample apps.
  - espadrine 9y ago
    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?
zerr 9y ago
> Uses native widgets; > 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.
- mwcampbell 9y ago
  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.
  - zerr 9y ago
    Interesting, what advantages this gives, maybe better skinning/theming support? But that doesn't seem to be the main goal of this framework...
    - mwcampbell 9y ago
      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.
    - maxxxxx 9y ago
      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.
      - zerr 9y ago
        Btw, wxWidgets uses native controls for each platform. You can even get to underlying native control and use platform specific APIs.
jancsika 9y ago
> 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? https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zHtQdo 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.
- c0mpute 9y ago
  Seems so - https://github.com/yue/yue/tree/master/docs/paid_plans https://github.com/yue/yue/tree/master/docs/paid_plans
- jasondemeuse 9y ago
  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. https://github.com/yue/help https://github.com/yue/help
0x1Null 9y ago
" 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" ... Why are you misrepresenting your work..
wruza 9y ago
>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.

by zcbenz 9y ago

Vinnl 9y ago

Am I correct in my understanding that this does still use Electron? (And if so, what is it used for?)

zcbenz 9y ago
It does not use electron, it is total native and does not use web engines, but it can be used in electron as a Node.js mudule.
- GrayShade 9y ago
  It might be a good idea to have some C++ sample apps.
- espadrine 9y ago
  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?

zerr 9y ago

> Uses native widgets; > 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.

mwcampbell 9y ago
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.
- zerr 9y ago
  Interesting, what advantages this gives, maybe better skinning/theming support? But that doesn't seem to be the main goal of this framework...
  - mwcampbell 9y ago
    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.
  - maxxxxx 9y ago
    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.
    - zerr 9y ago
      Btw, wxWidgets uses native controls for each platform. You can even get to underlying native control and use platform specific APIs.

jancsika 9y ago

> 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? https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zHtQdo 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.

c0mpute 9y ago
Seems so - https://github.com/yue/yue/tree/master/docs/paid_plans https://github.com/yue/yue/tree/master/docs/paid_plans
jasondemeuse 9y ago
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. https://github.com/yue/help https://github.com/yue/help

0x1Null 9y ago

" 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" ... Why are you misrepresenting your work..

wruza 9y ago

>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.