91–100 of 293 posts
I have been developing in HTML/Python for a while now. This works wonderfully. You just need to put all your business logic in Python, use PyQt to run all the platform specific code like file dialogs, printing, etc. but keep the main interface with React. You do that by having a webview with a service object being the bridge between Python and the JS view[0]. If you are a bit careful with the amount of information go…
I’m curious, does that work with sandboxing on the Mac? One of the things that Mac file dialogs do is implicitly expand the sandbox for the process that opens the file dialog . Is the other side of the bridge still able to access the selected path?
Qt will just open a native macOS dialog that will link files into the sandbox. From there you can pass the path returned by the dialog to sandboxing-oblivious C++ code.
As a side note: Flatpaks in Linux use a similar mechanism for sandboxed applications (in Flatpak these are called ‘portals’).
Earlier quoted context omitted.
Please read in between lines... I could easy write any other example. Don't make me compare HTML/CSS's flexibility with Qt's...
No, please do. Explain to users why you need that, and why you feel you are important enough to bypass and ignore all of the existing design guidelines and patterns of whatever OS I'm running on. And why you feel you have to use up all of my CPU and memory to do so.
Furthermore, most people do not care about this, and the value of marketing with a sleek design vastly outweighs any benefit of conforming to system components UI.
If literally every Electron app fixed memory issues and correctly placed OK/Cancel dialog buttons, I'd be fine with it for the rest of my life - and I write native code for a living. ;P
HTML/CSS is nice to display information. Now if you have to input data, then HTML/FORMS/etc. are not that good...
HTML Forms suck until you have to write form classes/UI in native languages, and then realize how annoying it is when you need to customize something or want a unique input that might make said form easier to deal with.
e.g, NSTextField in Cocoa _still uses cells_ behind the scenes.
Earlier quoted context omitted.
"Any Javascript UI experience that I picked up 5 years ago is obsolete." That is only true in the sense that your Python 2.x experience didn't translate into your Python 3.x experience. That is, I think the overlap is similar on a language level. The difference lies in the libs/frameworks.
No its nothing like a minor language change. This actually happened to me and my Javascript UI experience (Jquery) is obsolete in the world of React and Angular or whatever the flavour of the month is.
Earlier quoted context omitted.
Not that most companies would care, as dev cost seems to be all that matters these days, but the upsides are much faster and leaner applications than what you get from Electron.
Can't talk as to rendering and such, but python isn't going to be a performance win vs JS. V8 is faster than cpython by a decent margin for typical tasks on typical data structures. You'll need to dip into clang or whatnot for really hardcore perf either way
> "PyQt is dual licensed on all supported platforms under the GNU GPL v3 and the Riverbank Commercial License. Unlike Qt, PyQt is not available under the LGPL. You can purchase the commercial version of PyQt here. More information about licensing can be found in the License FAQ." Except this sucks if, you know, you want to make some money on your app... Kicking the tires for a potentially commercial app is a FULL sto…
As much as I love Python, I don't want its GUI ecosystem to become the next Delphi.
I don't know of any other cross-platform native GUI library that even matches Qt in quality or features. I don't think WxWidgets is a contender, unless someone here proves me wrong.
EDIT: I see, all it needs is the PyQT license for $500 and the Qt is covered under LGPL, for any commercial release.
> "PyQt is dual licensed on all supported platforms under the GNU GPL v3 and the Riverbank Commercial License. Unlike Qt, PyQt is not available under the LGPL. You can purchase the commercial version of PyQt here. More information about licensing can be found in the License FAQ." Except this sucks if, you know, you want to make some money on your app... Kicking the tires for a potentially commercial app is a FULL sto…
Does PyQT require an additional commercial license for the Qt itself? Qt's website says that its commercial license is $459/developer/month! The subscription fee is pretty hefty. So that means I pay PyQT $500 in addition to $459/month for Qt? As much as I love Python, I don't want its GUI ecosystem to become the next Delphi. I don't know of any other cross-platform native GUI library that even matches Qt in quality o…
Earlier quoted context omitted.
It does reflect the priorities of the community, though. PyQT's page is clearly written by a developer, with an emphasis on explaining the internals of the library. The author clearly saw no need to make it attractive. There is no long-term vision beyond the library itself. While PyQT is navel-gazing, Electron's page is all about grabbing mindshare and establishing clout. It seeks to conquer the world and your deskto…
As a developer, Electron's page shows their prowess in writing good front end code, which is really important. As someone who understands the basic concept of Electron, I want a product that demonstrates those competencies.
I think stuff like this is pretty tribal, which is OK, but we should confuse it with decisions made on technical or experience merits.
Earlier quoted context omitted.
Not saying I don't believe you, but do you have a source for that 90% claim?
The history of fashion and marketing tell us that appearance matters. It drives engineers batty, because it's often irrational. Just because something is irrational doesn't mean it doesn't have a huge impact on something like adoption. If we didn't care how things looked, we might all be wearing google glass.