Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

Post reply on HN
Print view View original

271–280 of 295 posts

Re: Proton Native – React Native for the desktop

#271

Post by Traubenfuchs »

jeena wrote: post #149
WaltPurvis wrote: post #98

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

And if we want to compare the syntax then this would be the QML equivalent: import QtQuick 2.9 import QtQuick.Controls 1.3 ApplicationWindow { title: "Example" visible: true width: 300 height: 300 Button { text: "Button" anchors.centerIn: parent onClicked: console.log('Hello') } }

That looks beautiful. Does Qt/QML support the full power of the JS ecosystem? (bleeding edge or at least modern JS, npm)

Re: Proton Native – React Native for the desktop

#272

Post by whowouldathunk »

mlsarecmg wrote: post #238
whowouldathunk wrote: post #17

Earlier quoted context omitted.

> and now we're making traditional UI dev like web It's been like that on Windows since 2006 with XAML. In fact, if you squint at typical JSX, it looks like XAML. Disclosure: I work at Microsoft.

XAML is a template, JSX is a DSL. A template kills scope, duplicates coding semantics, messes up app flow with bindings and needs dependency injection to get local scope back - all of this has been solved with JSX, which now pretty much fulfills Silverlights dream: https://news.ycombinator.com/item?id=16198843 The crazy part is, that you can share code and eco-system components among these targets, no matter if they'…

XAML components ("controls" in MS terminology) contain both declarative markup and code. And it's flexible because the visual presentation can be completely overriden by the component's consumer without altering behavior, and your code can be either C# or C++.

What does dependency injection have to do with anything? There's nothing stopping you from using global variables or an event bus or something like Redux in a XAML app.

Re: Proton Native – React Native for the desktop

#273

Post by WaltPurvis »

mherrmann wrote: post #254
superrad wrote: post #253

Earlier quoted context omitted.

PyQT isn't LGPL though, it only offers GPLv3 or Commercial licensing.

That's true. So using PyQt you likely need a commercial license for PyQt and not Qt. Alternatively, you can use PySide2 instead of PyQt to avoid this restriction, but it's less mature.

Less mature for the moment, but it's getting more official support and resources, so that will probably change. (They've also changed the name from PySide2 to Qt for Python.)

http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to...

License-wise: "Qt for Python will have the same licensing as Qt for Application Development, i.e. it will be available under GPL, LGPL and commercial."

Re: Proton Native – React Native for the desktop

#274

Post by abritinthebay »

dahauns wrote: post #266
mlsarecmg wrote: post #262

Earlier quoted context omitted.

And that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex. There is a major difference between that…

Sorry to go full "get off my lawn" here, but: How is this different from, say, simple GDI rendering or Swing? With both View is a function of state and rendering is done via idempotent function calls (WM_PAINT bzw. paint()/paintComponent()). This is the real traditional method. (BTW: The comparison to MVC doesn't really make sense, unless you add flux/redux/etc. to the equation.)

He means the V in MVC and while they pushed that concept for React at the beginning to help people get what it’s for... it’s not really the same at all.

Re: Proton Native – React Native for the desktop

#275

Post by jcelerier »

mlsarecmg wrote: post #262
jcelerier wrote: post #261

Earlier quoted context omitted.

Here's an equivalent example for your stateful component : Text { property int count: 0 text: count MouseArea { anchors.fill: parent onClicked: count++ } } if you put this in a file `C.qml` or load it as a component ( http://doc.qt.io/qt-5/qml-qtqml-component.html ), then you can reuse it in other components: Item { C { } C { count: 23 } // starts at 23 } For your functionally composed example, all qt objects have a…

And that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex. There is a major difference between that…

.... where do you see imperative registration, layout inflating and MVC in my example ?

Re: Proton Native – React Native for the desktop

#277

Post by mlsarecmg »

jcelerier wrote: post #275
mlsarecmg wrote: post #262

Earlier quoted context omitted.

And that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex. There is a major difference between that…

.... where do you see imperative registration, layout inflating and MVC in my example ?

It just doesn't look comparable to the example i've posted. They were really, really simple, so if QT is the same, i would love to see it do the same. As for imperative registration, didn't you just link me to it? If they were functions, you could do:

    const A = () => ...
    const B = () =>
Notice that the B component can refer to the A component because it's in the same scope. There's no magic and no binding/loading. A is a function that is called inside B's function body. It also isn't done by inference of an ID (which would be registration).

Re: Proton Native – React Native for the desktop

#278

Post by jcelerier »

mlsarecmg wrote: post #277
jcelerier wrote: post #275

Earlier quoted context omitted.

.... where do you see imperative registration, layout inflating and MVC in my example ?

It just doesn't look comparable to the example i've posted. They were really, really simple, so if QT is the same, i would love to see it do the same. As for imperative registration, didn't you just link me to it? If they were functions, you could do: const A = () => ... const B = () => Notice that the B component can refer to the A component because it's in the same scope. There's no magic and no binding/loading. A…

> const A = () => ... ; const B = () =>

Yes, an equivalent in QML would look like this if you want it in a single file:

    Component {
        id: a
        Text { text: "foo" }
    }

    Component {
        id: b
        Rectangle { Loader { sourceComponent: a } }
    }
but the language really wants you to have one component per file, so :

   A.qml: 
   
   Text { text: "foo" }

   B.qml

   Rectangle { A { } }
> if QT is the same,

It's not. QML is at its core not a functional language, it's a declarative & reactive language. In my experience, at least 30-40% of QML code does not need any functions.

> There's no magic and no binding/loading.

I'm not sure we are using the same meaning of binding. The "A" token in your example is obviously bound to the "A" variable declared before.

> It also isn't done by inference of an ID (which would be registration).

ids in QML are just the variable names. eg

   Rectangle { 
     A { id: foo } 
     width: 2 * foo.width
   }

Re: Proton Native – React Native for the desktop

#279

Post by andlabs »

parro-it wrote: post #232
flukus wrote: post #197

Earlier quoted context omitted.

Nice to see this project is still alive, it shows a lot of promise but appeared abandoned for a while. Have they got the data grid API's working yet?

Hi, libui-node author here. I'm glad for your appreciation. The project is well alive now, proton-native give me new motivational energy The data grid has still problems on macOS unfortunately, but @andlabs is working on it...

No, the data grid has problems on Windows, as that code is being contributed by someone else. I already have it on macOS and Linux, and have for years now... Hopefully soon the Windows code will be merged in and we can keep going.
Post reply on HN