mirror of
https://github.com/kusti8/proton-native.git
synced 2026-05-15 14:15:50 -06:00
[GH-ISSUE #213] V2.0.0 Rewrite #146
Labels
No labels
bug
documentation
enhancement
libui issue
pull-request
question
wait for libui implementation
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/proton-native#146
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kusti8 on GitHub (May 5, 2019).
Original GitHub issue: https://github.com/kusti8/proton-native/issues/213
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:
Progress can be seen on the v2 branch.
I'm going to track more fine detail TODO here:
Qt NAPI bindings
Proton Native rewrite
@goranmoomin commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
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 commented on GitHub (May 6, 2019):
@kusti8 I first found that information from Wikipedia:
The wxwidgets wiki from here also says,
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 commented on GitHub (May 6, 2019):
It looks like Qt is rendering with macOS’s own API 😆
Source here
Looks like Windows and GTK doesn’t have that advantage 😕
Sent with GitHawk
@magicpriest commented on GitHub (May 7, 2019):
Hi @kusti8
Thank you for your work. Do you need help with any task in your milestone?
@kusti8 commented on GitHub (May 7, 2019):
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 commented on GitHub (May 7, 2019):
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 commented on GitHub (May 9, 2019):
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 commented on GitHub (May 9, 2019):
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 commented on GitHub (May 9, 2019):
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 commented on GitHub (May 28, 2019):
Is any way I can help? Currently working with Proton Native in Ubuntu 👋 .
@kusti8 commented on GitHub (May 28, 2019):
@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 commented on GitHub (Jun 3, 2019):
@kusti8 is there an ETA for the v2
@kusti8 commented on GitHub (Jun 4, 2019):
No current ETA. It'll probably be finished by the end of the summer, but I can't really promise anything.
@Sadless74 commented on GitHub (Jul 2, 2019):
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 commented on GitHub (Jul 3, 2019):
I've seen that and there are a few key differences in proton-native and react-native-desktop:
@TzenkuGames commented on GitHub (Jul 17, 2019):
Thank you for your work, and others who contributing. Looking forward for Proton Native updates, this excites me.
@jardenliu commented on GitHub (Sep 23, 2019):
Thank you for your work
@lacymorrow commented on GitHub (Oct 4, 2019):
Great project, just wanted to point to another current-ish project that is attempting to wrap QT bindings with node: nodegui/nodegui
@NastuzziSamy commented on GitHub (Oct 12, 2019):
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 commented on GitHub (Oct 15, 2019):
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 commented on GitHub (Oct 15, 2019):
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 commented on GitHub (Dec 7, 2019):
@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 commented on GitHub (Dec 7, 2019):
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 commented on GitHub (Dec 7, 2019):
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 commented on GitHub (Dec 15, 2019):
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 commented on GitHub (Jan 19, 2020):
Proton Native V2 is now released!
@alidcast commented on GitHub (Jan 26, 2020):
@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
@kusti8 commented on GitHub (Jan 26, 2020):
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 commented on GitHub (Jan 27, 2020):
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 commented on GitHub (Jan 30, 2020):
Why aren't you tagging your releases ?
@shayneoneill commented on GitHub (Feb 23, 2020):
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.