V2.0.0 Rewrite

[kusti8]

This is a culmination of a lot of issues that have been faced and is my attempt to address them and make proton-native more powerful and more in-line with existing projects. The following high level changes are being planned:

• Create NAPI bindings for Qt5
• Mirror React-Native syntax as closely as possible
• Implement yoga layout (flexbox)
• Clean up inheritance mess, see Potential changes for major revision #211
• Implement styling through Qt Style Sheets
• Add more components

Progress can be seen on the v2 branch.

I'm going to track more fine detail TODO here:

Qt NAPI bindings

• Start Qt NAPI bindings
• Add basic components (Application, Window, Widget)
• Make cross compatible
• Pre package binaries
• Fix node-pre-gyp not being installed on Windows
• Add missing functions
• Add more components (Button, Text, Entry etc.)
• Clean up copied functions
• Add more compolicated components (Image, Table, Area, etc.)

Proton Native rewrite

• Rewrite renderer without ugly root component
• Rename basic functions to be in line with react-native
• Add App, Window, and View (w/o flexbox)
• Add flexbox to View
• Finish testing flexbox
• Add styling
• Finish setting up code structure
• Add missing props
• Fix event loop not quitting
• Add more components (all w/ React Native names)

[goranmoomin]

As far as I understand, does this mean that Proton Native is migrating from libui to Qt?
Are there special reasons for that? I don’t know much about Qt, but what I understood is that Qt draws it’s own widgets, not using the system toolkit, as opposed to libui which uses the system toolkit.
Is that the case?

[kusti8]

That is correct. This is being done because Qt is more mature, supports more features that are aligned with react such as css styling, and the fact that I can control the bindings and work more quickly.

[goranmoomin]

While I understand about why Qt is used, Proton Native's best features was that it was cross platform, while using 'Native components. No more Electron'.
While I understand that Qt is a much mature/better supported library and has a look-and-feel much similar to native widgets, what I feel (from my heart) is that Qt is no different from using Electron with 'native looking' HTML elements 😞
(My English skills are poor, sorry for that)

[kusti8]

That is very much not true. Qt is still native C++ code that draws on the screen. Native system libraries must do the same thing anyway.

The difference between Qt and Electron is big. Electron runs a full Chromium browser to show a GUI. Qt natively draws on the screen without the overhead of a web browser. There is very little performance difference between it and system toolkits.

[goranmoomin]

What I meant is not about performance; what I was saying was that (by deviating from the system-provided toolkits and using Qt) providing consistency with system-native toolkit apps and following HIG becomes harder.

For example, in macOS, all Cocoa text boxes allow keybindings defined in ~/Library/KeyBindings/DefaultKeyBinding.dict. This allows easier cursor navigation in text boxes with emacs keybindings, and I also added some more keybinding to the file. (If you use macOS, press ctrl-a or ctrl-e, ctrl-b, ctrl-f in any textbox in Safari, Alfred, Spotlight, etc...)

Maybe Qt can add support for keybindings in text boxes in macOS manually. (I'm not sure which app uses what toolkit, so I'm not sure if Qt already has this) But, if a new (possibly minor) feature appears that applies Cocoa-wide or System-toolkit-wide, (by using Qt) it will be hard to provide the feature in Proton Native until the developers of Qt add the feature.

[kusti8]

I understand what you're saying, but libui is progressing slowly because it has to be written ground up and is still missing many features. Qt is more fully featured and although it isn't native in design, it allows the library to grow a lot more and I feel is the best choice.

[goranmoomin]

Okay, after some searching (I have only developed GUIs with cocoa...) it looks like Qt has a native-mode that uses native styling APIs. Is it possible for Proton Native to force Qt to use native APIs or use another (native) toolkit like wxWidgets? I would really appreciate that 👍

[kusti8]

Could you link that? I can't seem to find it. I'll try doing it if I can, but it is not that high on my list of priorities.

[goranmoomin]

@kusti8 I first found that information from Wikipedia:

Recent versions of Qt use the native style APIs of the different platforms, on platforms that have a native widget set, to query metrics and draw most controls, and do not suffer from such issues as often.

The wxwidgets wiki from here also says,

It's worth mentioning though that Qt comes with special styles for Mac OS X and MS Windows XP and Vista that use native APIs (Appeareance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application.

I also found this after additional search.

Unfortunately, I couldn't find any more info 😞 I'll inform you if I get to find some...

[goranmoomin]

It looks like Qt is rendering with macOS’s own API 😆

Source here

Qt's widgets use HIThemes to implement the look and feel. In other words, we use Apple's own APIs for doing the rendering.

Looks like Windows and GTK doesn’t have that advantage 😕

_{Sent with GitHawk}

[magicpriest]

Hi @kusti8
Thank you for your work. Do you need help with any task in your milestone?

[kusti8]

Thanks for the offer. I need to finish up setting the structure Ana a few components but then you can help with adding more components and documentation.

[magicpriest]

Yeah, thats okay.

A little notice, I've spend past year for porting RN to WinCE and obviously failed, but learned a lot. So, if you have any issues with QT/cpp or anything native related – feel free to write me.

[anidotnet]

Regarding using Qt, how is it going to affect the licensing of the app? Qt is not free unless you use LGPL licensed dynamic link libraries. Does it mean proton native application also have to GPL compliant? If it is then it would be a deterrent.

[kusti8]

If you dynamically link to the Qt libraries then you aren't modifying the source code so it can be kept closed source. On Linux it is dynamically linked by default. I am using this project as a reference and they bundle qt libraries for Mac and Windows, so it can be dynamically linked.

[kusti8]

I've also finished much of the basics, so there are some small bugs that need to be fixed (biggest one being the event loop) and just more props/components needing to be implemented in node-qt-napi and proton-native. Final step is to add documentation.

[Gorzas]

Is any way I can help? Currently working with Proton Native in Ubuntu 👋 .

[kusti8]

@Gorzas Currently I'm working on adding more components like Buttons, which I want to do myself just to make sure the structure is sound. However, the existing components like Text and Window need more props to actually make them usable (mirror the ones in React Native for Text) and we also need to copy the documentation folder from master and rewrite that for this new version. If you have a change, feel free to send a pull request to the v2 branch.

[herlarb]

@kusti8 is there an ETA for the v2

[kusti8]

No current ETA. It'll probably be finished by the end of the summer, but I can't really promise anything.

[Sadless74]

Hello @kusti8
Do you know about https://github.com/status-im/react-native-desktop ?
What do you think about it architecture https://github.com/status-im/react-native-desktop/blob/master/docs/HowRNDesktopAppWorks.md ?

[kusti8]

I've seen that and there are a few key differences in proton-native and react-native-desktop:

• React-native-desktop is built as an extra target for a react-native app. Now there are pros and cons of this, pros being that you shouldn't need to change your code at all, but there are a few reasons I don't like this.
  • Desktop and mobile act in different ways. I want to keep the spec as close to react-native as possible, but I don't want to sacrifice on usability if it comes to that. For example, I've added window support because that is a fundamental of desktop.
  • They have to keep their fork constantly up to date with react-native. By me building my own reconciler, I get to be mostly independent of any kind of react-native changes and not have to worry about merging their code constantly.
  • Harder to debug. I would have to learn the inner workings of react-native as well and it introduces a lot of code that is harder to debug should something go wrong.
• My focus is always on ease of use for the end user and documentation. I can't speak for the other project, but my goal is to get something working out so others can use it.

[TzenkuGames]

Thank you for your work, and others who contributing. Looking forward for Proton Native updates, this excites me.

[jardenliu]

Thank you for your work

[lacymorrow]

Great project, just wanted to point to another current-ish project that is attempting to wrap QT bindings with node: nodegui/nodegui

[NastuzziSamy]

Wonderful project ! <3

I see that the last commit was pushed 21 days ago.
If you need any help, I would be happy to give a hand :)

[Rhaal]

Greetings @kusti8 !
First of all, thanks for putting your time and effort into this: it's a really great project!

Secondly, while you have already done a lot of work to integrate Qt in v2, I'd like to point out that licensing might be an issue: it really doesn't work with the MIT license, especially on commercial use.

I've used Qt for commercial uses quite often, and the Qt License requires some substantial fee: from a quote I obtained for a project that I have in front of me, we're in the odds of € 8k for the "Qt for Device Creation" license, and some € 0.5k for "Qt for Device Creation" distribution license.
Please note that "Device Creation", as far as I could understand it, is required for something simple as selling any physical device with Qt software in it. While I don't have a quotation for a purely software product, I do know for a fact there is a fee and a proprietary license to subscribe.

Therefore, using Qt would limit Proton Native to only the very small subset that complies with both LGPL2.1 and MIT.

Give it some consideration! If I may be of any assistance, feel free to reach out!

[kusti8]

Proton native uses Qt which is basically LGPL, meaning that as long as you dynamically link with the code (ie the user can change Qt libraries without changing your code) then you are free to keep the source closed. By making this project MIT, anything you write with proton native can be closed source. Because proton native under the hood dynamically links with Qt, there should be no problem.

[benbucksch]

@kusti8 : Thanks for Proton Native. It sounds awesome, and I've just tried it (master) out, and it is awesome, too. Great and very skilled work, congratulations!

Regarding Qt, for your information, I had seen react-native-desktop before I found Proton, but I immediately dropped it from consideration, because it's based on Qt. Running Qt on Windows or Mac works technically, but it's not a "native" app. It's like running an Android app on iPhone. Mac users don't accept that, they insist on native Cocoa widgets.

[kusti8]

I understand that it isn't truly native, but there's truly a lack of alternatives that fit the bill. I moved away from libui because it wasn't stable and was missing features. Qt is the best option for this. I've considered wxWidgets, but the entire API is convoluted and difficult to work with. Qt is easy because it has CSS styling built in and the API just works.

If there was a good alternative then I would use it and I'm open to suggestions, but currently there doesn't seem to be one.

[kusti8]

I've actually been thinking that since this has become such an important issue, I can split the code to be library agnostic. Have Qt be a backend implementing a standard API and then have wxWidgets be another backend, so that the user can choose. I want to try out wxWidgets and porting it for JS to see how it fully works. I was just finishing up fixing some bugs and then I had to write documentation, but this will push the release back a bit.

[apollolux]

Hello! Before proton-native I don't think I ever heard of libui, though I have known andlabs through the retro video game emulation community. When programming directly in C++ I use the "hiro" toolkit wrapping library by byuu the author of the emulators bsnes and higan. hiro is nearly identical to libui in purpose, but implementation is wildly different; byuu favors C++1x practices as modern as possible to make the code more readable. There has not yet been a hiro-node, but I would certainly like to see such a thing supplant the more-or-less unmaintained libui-node and be used in projects like proton-native and vuido. For the record, he set hiro to use native on Windows and Mac, and on Linux tries to use gtk first, otherwise Qt, otherwise whatever X-based GUI toolkit exists.

What do you think about such an idea? The latest version of hiro seems to be in higan if you'd like to peruse it.

[kusti8]

Proton Native V2 is now released!

[alidcast]

@kusti8 congrats on the 2.0 release :)

time/focus wise, do you think it makes sense to make proton native library agnostic right now? rather than making it a value add later, once the proton native rewrite stabilizes and react native mirror API has been completed

it seems likes the main dislike of Qt is its license, but you've already clarified that as long as you dynamically link to it, code could be kept closed source

Proton native uses Qt which is basically LGPL, meaning that as long as you dynamically link with the code (ie the user can change Qt libraries without changing your code) then you are free to keep the source closed.

[kusti8]

It largely is library agnostic already. That's how the wxWidgets backends works. Proton Native defines an API and then there are backend files that translates that into commands for the actual library.

I want to continue adding components and slowly build up the wxWidgets backends at the same, but the framework is already in place.

[apollolux]

IMO the main dislike of Qt has always been and will likely continue to be for the near future how non-native it looks and feels on Windows (and less so on macOS but still relatively less native-looking & feeling than Cocoa/whatever now), with its signal-based event handling workflow in a fairly close second. Those two factors alone have dissuaded me from using raw Qt in any of my C++ projects, and I wouldn't be surprised if it discouraged others as well.

[xinhash]

Why aren't you tagging your releases ?

[shayneoneill]

Qt done carefully looks very native, and due to the sheer number of commercial apps that use it, I suspect you'd find a hell of a lot of apps that you might think use native apis but are using QT.

Theres a reason QT is as popular as it is with commercial software.