Why are you tying it to a programming language (Python)? The standard should not be tied to a particular programming language. Past attempts keep making these mistakes:
1) Ties it to a specific programming language or OS 2) Packs in crap not related to UI's: EMACS-syndrome. That makes something too hard to keep up-to-date/plugged. 3) Uses a binary protocol instead of text-based 4) Proprietary 5) Designed for LAN's, not HTTP (like X-window) 6) Relies too much on DOM/CSS, which is screwy because it wasn't meant for desktop GUI's. 7) Relies on client to adjust or re-format flow/placement. This makes the client too fat (#2), and inconsistent as different versions/brands will flow different, making testing a bear. The server can adjust spacing based on client size preferences so as to not bloat & buggify the client with this task.
If Electron can get most the bugs and security holes out of it and it shows to be time-proven, then perhaps it can fill that role. In the past for similar tools, one had to keep upgrading the local JavaScript libraries to stay compatible with browser releases/changes.
Remember Javascript won over ActiveX, Java applets and Flash so it's not going anywhere.
Largely because Flash and ActiveX proved full of security holes, similar to Java Applets (see #2). JavaScript/DOM is merely a consolation prize; it's still not a GUI standard itself, and sucks when it tries to be.
This just requires old-fashioned thoughtful parsimony: put in the standard what's needed and ONLY what's needed for GUI's. Shift as much to the server as possible to keep the client lean, mean, clean, and focused on one job.
Being just for C++ doesn't help much. A good standard would work in any language that can send/receive text over HTTP, probably with the UI communication express-able as text protocols like XML and JSON.
It's been a while since I checked out Java GUIs, but you can make them
Do you mean make a GUI browser with Java, or use Java applets? Applets failed because Java tried to do and be too many things, creating versioning and security headaches.
Tcl/Tk that have cross-platform GUI options.
It relies too much on client-side auto-flow, similar to HTML/CSS's big flaw. And it lacks a text-able communication standard, similar to Qt's issue. I suppose the Tcl commands could be considered the "text protocol", but that's using an entire language, which risks the same problems as Java applets. We just need the bathwater, not the baby also. If we require the baby, then we have to download baby security fixes etc. even if we don't use the baby (or most its features). Lean-ness of the standard and it's "browser" matters.
X-Windows doesn't buffer input, in case somebody brings that up.
Either of those hosing it is not a good sign. I don't remember the install parts. I did have to go to Microsoft.com to get a required component or two, but I don't remember what those were.
I don't get the Core hype. It's supposed to be more cross-platform, such as running on Linux and Android, but for typical business apps, what does it give one besides migration headaches from pre-core?
There is no cross-platform UI framework. MS is porting WPF to.net core, but for Windows only.
The industry is sorely missing a desktop-friendly GUI standard for productivity/CRUD applications. HTML/JS/CSS has sucked for that. You can get HTML+ to act like a real desktop with lots of blood, sweat, and tears, but why does it have to be that way? Billions are wasted using UI rocket science on what should be bicycle science.
Java applets tried to solve that, but Java tried to be an entire OS, making it bloated and full of security holes. A standard should focus on GUI's and only GUI's, offloading as much work to the server as possible to keep the client & standard simple.
Make it coordinate-based on the client-side with any "auto-flow" being calculated on the server. Client-side layout auto-flow is probably THE biggest mistake of the HTML stack (except maybe missing common GUI widgets). The client can send its dimensions or size preferences to the server, and the server can then auto-flow placement as needed, and send simple x,y,z coordinates to the client ("z" being the panel overlay level.). People would also have a choice of layout engines, since they are on the server, not the browser.
Controlling the layout is why PDF is still common. People can't stand it when HTML browsers butcher their layout plans and intent. "Autoflow this, Tim Burner Lee!"
Trace-able machines may be more important than "instant" smart machines. If a bot decision is made that's wrong that has big consequences, society is going to want to know WHY the decision was made. Lawsuits will pile up if there's no trace-ability. This is both public lawsuits, and business-to-business lawsuits as claims made in contracts may be difficult to verify and/or quantify.
Trace-ability is why things like chains of Factor Tables (sig) appear more practical. DNN's are powerful, but are a dark grey box that's hard to dissect, debug, and understand. Factor tables may be harder to train, but offer better trace-ability and manual tuning by non-PhD's as a possible upside. And they are probably more modular than DNN's, as intermediate operations and templates can be plugged in as needed.
AI experts may set up the outline/framework, but "regular" office workers can study, trace, and tune the intermediate results using familiar tools that resemble and/or use spreadsheets, RDBMS, and statistical packages. Regiment-tize an otherwise dark grey art.
The ones near me do have cheap food, but it tastes cheap to me, or at least inconsistent. You get what you pay for. But it's tempting because, for example, a bag of popcorn is $1 there but $4 elsewhere, unless I drive far. Compromise: how about a two-fifty store?
I agree, it is a waste of time. They should use their skills for something more practical, like fixing unicode handling/filtering in Slashdot. That would be a nice Christmas gift to Slashdotters.
Slashdot Mirror
Why are you tying it to a programming language (Python)? The standard should not be tied to a particular programming language. Past attempts keep making these mistakes:
1) Ties it to a specific programming language or OS
2) Packs in crap not related to UI's: EMACS-syndrome. That makes something too hard to keep up-to-date/plugged.
3) Uses a binary protocol instead of text-based
4) Proprietary
5) Designed for LAN's, not HTTP (like X-window)
6) Relies too much on DOM/CSS, which is screwy because it wasn't meant for desktop GUI's.
7) Relies on client to adjust or re-format flow/placement. This makes the client too fat (#2), and inconsistent as different versions/brands will flow different, making testing a bear. The server can adjust spacing based on client size preferences so as to not bloat & buggify the client with this task.
If Electron can get most the bugs and security holes out of it and it shows to be time-proven, then perhaps it can fill that role. In the past for similar tools, one had to keep upgrading the local JavaScript libraries to stay compatible with browser releases/changes.
Largely because Flash and ActiveX proved full of security holes, similar to Java Applets (see #2). JavaScript/DOM is merely a consolation prize; it's still not a GUI standard itself, and sucks when it tries to be.
This just requires old-fashioned thoughtful parsimony: put in the standard what's needed and ONLY what's needed for GUI's. Shift as much to the server as possible to keep the client lean, mean, clean, and focused on one job.
Being just for C++ doesn't help much. A good standard would work in any language that can send/receive text over HTTP, probably with the UI communication express-able as text protocols like XML and JSON.
Do you mean make a GUI browser with Java, or use Java applets? Applets failed because Java tried to do and be too many things, creating versioning and security headaches.
It relies too much on client-side auto-flow, similar to HTML/CSS's big flaw. And it lacks a text-able communication standard, similar to Qt's issue. I suppose the Tcl commands could be considered the "text protocol", but that's using an entire language, which risks the same problems as Java applets. We just need the bathwater, not the baby also. If we require the baby, then we have to download baby security fixes etc. even if we don't use the baby (or most its features). Lean-ness of the standard and it's "browser" matters.
X-Windows doesn't buffer input, in case somebody brings that up.
Either of those hosing it is not a good sign. I don't remember the install parts. I did have to go to Microsoft.com to get a required component or two, but I don't remember what those were.
Do you mean RINO?
I don't get the Core hype. It's supposed to be more cross-platform, such as running on Linux and Android, but for typical business apps, what does it give one besides migration headaches from pre-core?
The industry is sorely missing a desktop-friendly GUI standard for productivity/CRUD applications. HTML/JS/CSS has sucked for that. You can get HTML+ to act like a real desktop with lots of blood, sweat, and tears, but why does it have to be that way? Billions are wasted using UI rocket science on what should be bicycle science.
Java applets tried to solve that, but Java tried to be an entire OS, making it bloated and full of security holes. A standard should focus on GUI's and only GUI's, offloading as much work to the server as possible to keep the client & standard simple.
Make it coordinate-based on the client-side with any "auto-flow" being calculated on the server. Client-side layout auto-flow is probably THE biggest mistake of the HTML stack (except maybe missing common GUI widgets). The client can send its dimensions or size preferences to the server, and the server can then auto-flow placement as needed, and send simple x,y,z coordinates to the client ("z" being the panel overlay level.). People would also have a choice of layout engines, since they are on the server, not the browser.
Controlling the layout is why PDF is still common. People can't stand it when HTML browsers butcher their layout plans and intent. "Autoflow this, Tim Burner Lee!"
I tried installing Paint.NET about 7 years ago, and it hosed up my PC. The memory of that keeps me hesitant to try again.
640gig downloads oughtta be enough for anyone.
Um....
How often have you been a tree in order to test this? (I confess I often feel like a stump on Mondays.)
Anyhow, the entire "must mirror biology" is a dubious claim. It's like saying in order to make flying machines, you must mirror flapping wings.
There may be multiple paths to intelligence, not just Darwinian selection and survival-related emotions.
Trace-able machines may be more important than "instant" smart machines. If a bot decision is made that's wrong that has big consequences, society is going to want to know WHY the decision was made. Lawsuits will pile up if there's no trace-ability. This is both public lawsuits, and business-to-business lawsuits as claims made in contracts may be difficult to verify and/or quantify.
Trace-ability is why things like chains of Factor Tables (sig) appear more practical. DNN's are powerful, but are a dark grey box that's hard to dissect, debug, and understand. Factor tables may be harder to train, but offer better trace-ability and manual tuning by non-PhD's as a possible upside. And they are probably more modular than DNN's, as intermediate operations and templates can be plugged in as needed.
AI experts may set up the outline/framework, but "regular" office workers can study, trace, and tune the intermediate results using familiar tools that resemble and/or use spreadsheets, RDBMS, and statistical packages. Regiment-tize an otherwise dark grey art.
Maybe it's a me-too fad that will die off as people gradually realize they miss it and stop buying lame phones.
"This research is delicious!"
Japan has a strange obsession with whale meat.
Good point. Men are called "fags" all the time on the Webnets.
I'm too lazy to wash the greasy pan. Next!
https://www.youtube.com/watch?...
Elves go postal, a Christmas Story
The ones near me do have cheap food, but it tastes cheap to me, or at least inconsistent. You get what you pay for. But it's tempting because, for example, a bag of popcorn is $1 there but $4 elsewhere, unless I drive far. Compromise: how about a two-fifty store?
Thanks!
Careful, though, if you mistype that you get tickling smut. (Not that it's necessarily a bad thing, but some may be at work.)
I agree, it is a waste of time. They should use their skills for something more practical, like fixing unicode handling/filtering in Slashdot. That would be a nice Christmas gift to Slashdotters.
This version of "you are all cows, say moo" is too eloquent. Bring back the drunk immature cow troller. Change Bad.
Aaachoo! Hey, what's wrong with you, I see plenty of stars.
Let's feed into their whacky conspiracies and see where it leads them all, just for the hell of it.
"Hey, by golly, you're right, no stars! We've been duped! Go take those phonies on! Here's $10 for your cause..."
The worst that can happen is enough of them believe it to vote a conspiracy nut into office. But since we already have one...
If it affected him, nobody would probably notice any difference.
Someone can put up a site about the Tk GUI library under "tk.tk". I checked, nothing of note.
Just don't pronounce it at the airport, that sound makes them nervous, unless you like free medical exams.
Never? That's a stupid prediction. "640 miles high oughtta be enough for anyone."
That's odd, it only turns up pics of the President's hair.