Can I borrow an apology?
-
@topspin said in Can I borrow an apology?:
Now they’re proposing to add linalg. I already use a library for that (Eigen) and a BLAS implementation (MKL), I doubt the 3 major stdlib implementers have the manpower to beat what’s already available.
It's fortunate that the graphics proposal ended up dead. I think Linalg is more tractable, but there are some parallels. Curious to see where that one is going. My guess is that one or the other (or all) groups of people will discover that the library wasn't designed with them in mind, if it ever makes it into existance.
-
@cvi the graphics proposal was complete and utter insanity.
Absolutely huge implementation effort, wrong API and abstractions (there was a paper focusing solely on how the color model was wrong ), outdated tech stack nobody would use in the real world except for “easy teaching for beginners”, and the usual can’t-improve-ever problem.You know where your million line toy graphics library for teaching beginners belongs? On GitHub!
-
@cvi also, the linalg proposal is apparently backed by people who fortunately have solid experience with linear algebra / BLAS software. But I still think it’s wrong and counter-productive.
-
@topspin said in Can I borrow an apology?:
Absolutely huge implementation effort, wrong API and abstractions (there was a paper focusing solely on how the color model was wrong ), outdated tech stack nobody would use in the real world except for “easy teaching for beginners”, and the usual can’t-improve-ever problem.
Do you have a link? This sounds like a fun read
-
@topspin said in Can I borrow an apology?:
@cvi the graphics proposal was complete and utter insanity.
People often think graphics libraries are easy. Until they see the vast amount of effort required...
[Before anyone asks, that's mostly language-independent effort. Graphics simply require a lot of itty bitty little details to be taken care of to do things like making a 3D border for buttons show right when the screen scales in particular ways. The code isn't difficult per line at all, but there is a vast amount of it to do.]
You know where your million line toy graphics library for teaching beginners belongs? On GitHub!
As good a place as any, and better than many. (Million lines ≠ toy, but you knew that and they didn't.)
-
-
@Zerosquare That qualifies more as an abomination than a toy.
-
It's like gifting a drum set to your brother's kid.
-
@dkf said in Can I borrow an apology?:
@Zerosquare That qualifies more as an abomination than a toy.
What about Deno and Bun?
-
@Arantor said in Can I borrow an apology?:
@dkf said in Can I borrow an apology?:
@Zerosquare That qualifies more as an abomination than a toy.
What about Deno and Bun?
They pretend that they're different?
-
@dkf said in Can I borrow an apology?:
@Arantor said in Can I borrow an apology?:
@dkf said in Can I borrow an apology?:
@Zerosquare That qualifies more as an abomination than a toy.
What about Deno and Bun?
They pretend that they're different?
I haven't spent enough time around them to learn how they make such claims but Bun at least makes some claims that it's better than Node.
But it may be better in as far as a nicely formed turd is better than a splat in the bowl.
-
@dkf said in Can I borrow an apology?:
@topspin said in Can I borrow an apology?:
You know where your million line toy graphics library for teaching beginners belongs? On GitHub!
As good a place as any, and better than many. (Million lines ≠ toy, but you knew that and they didn't.)
That number was of course just ass-pulled what I thought a graphics library would be. Apparently, it actually is on GitHub already with a reference implementation, and that's only like 20k lines according to cloc:
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C/C++ Header 89 1657 1080 13888 C++ 62 1138 1491 7793 CMake 21 172 100 919 Objective-C++ 2 127 5 597 Markdown 6 71 0 231 XML 4 0 1 150 YAML 2 16 11 89 SVG 1 5 1 74 ------------------------------------------------------------------------------- SUM: 187 3186 2689 23741 -------------------------------------------------------------------------------
So why put that in the standard? Just keep that shit there, I don't want it.
@Zerosquare said in Can I borrow an apology?:
@topspin said in Can I borrow an apology?:
Absolutely huge implementation effort, wrong API and abstractions (there was a paper focusing solely on how the color model was wrong ), outdated tech stack nobody would use in the real world except for “easy teaching for beginners”, and the usual can’t-improve-ever problem.
Do you have a link? This sounds like a fun read
The proposal is pretty short, revision 9 is a mere 250 pages. (Linked so that it hopefully doesn't embed.)
The mentioned review of just a portion of it is found here. Probably check out sections 8 and 9. Some excerpts:
8 Bad For Beginners
Beginner teachability is often used as a justification for the current 2D graphics proposal, with the angle that anything is better than nothing. Whether or not this is true, there are several fundamental problems here that would cause me to actively discourage beginners from using the proposed 2D graphics library, if it were standardised today as-is (with some bugfixes applied).- Poor correctness - It provides no hand holding for colour management, and rgba_color is actively harmful. Every beginner is going to mess this up. There are numerous technical mistakes across the 2D graphics proposal and reference implementation, demonstrating the difficulties involved here.
9 Conclusion and Recommendations
The linear algebra types provided by the proposed 2D graphics library are very inadequate generally, and in at least one case dangerous due to inadequate design. The graphics API fails to separate out the concepts of CPU and GPU, which leads to poor performance, unsafety, and a fundamental difficulty in providing basic features offered by other libraries. The text of P0267 and reference implementations both make extensive mistakes surrounding linear colour. As-is, the proposed 2D graphics library overall will be hampered in its future evolution without fundamental changes, and I do not believe it currently caters to any audience of developers, from extreme beginner to expert.
-
@dkf said in Can I borrow an apology?:
The code isn't difficult per line at all, but there is a vast amount of it to do.
Even just using a graphics library requires an awful lot of wiring together the various pieces of the library. Again, not difficult (at least once you understand how to use whatever library you're using), but a lot of rather tedious work.
-
@Zecc said in Can I borrow an apology?:
@Gern_Blaanston said in WTF Bites:
Whenever someone says that I always think "OK. What was in between 1 BC and 1 AD ?"
NewNUL Year's Eve.
-
@dkf said in Can I borrow an apology?:
@Arantor said in Can I borrow an apology?:
@dkf said in Can I borrow an apology?:
@Zerosquare That qualifies more as an abomination than a toy.
What about Deno and Bun?
They pretend that they're different?
The problem of Node isn't so much for what it is and how it works. Well, it is a problem all the same, but it pales next to the fact that a million typewriting monkeys used to be a joke, but now it's become the only accepted solution to everything.
-
@Applied-Mediocrity IOW, the problem is the shitshow of an ecosystem, and how it is dominated by lower-order simians.
-
@dkf Yes and no. Lower-order simians eagerly eat it all up, but they never create anything of note, so they're largely irrelevant. It's the highly functioning untreated ADHD simians that can't sit still without "innovating" all the time.
-
@Applied-Mediocrity said in Can I borrow an apology?:
@dkf Yes and no. Lower-order simians eagerly eat it all up, but they never create anything of note, so they're largely irrelevant. It's the highly functioning untreated ADHD simians that can't sit still without "innovating" all the time.
Javascript developers truly have ants in their pants.
-
@dkf this gave me flashbacks.
The biggest problem with witing UI libraries isn't to make it work, even if that is annoying. It's that it is nothing but corner cases a dressed in a coat. And if you fix one corner case at least 500 other ones break.
-
And then you just half-ass it and tell yourself it's good enough, like... oh... most UI libraries.
-
@Zerosquare said in Can I borrow an apology?:
And then you just half-ass it and tell yourself it's good enough, like... oh... most UI libraries.
I mean, it was as good as it was ever going to get 20 years ago. But then everyone must try to reinvent them over and over without understanding why they all suck.
-
@Carnage and also don’t understand the parts that make them not suck, either for the dev or the user. Scratch that, they don’t understand anything that makes it not suck for the user.
-
@Zerosquare said in Can I borrow an apology?:
And then you just half-ass it and tell yourself it's good enough, like... oh... most UI libraries.
If you three-quarter-ass it, everyone will look at you like a crazy person before keeping using Electron.
-
@dkf is three-quarter-ass better or worse than half-ass?
-
@topspin yes
-
-
@TwelveBaud I didn't watch it, but I love this comment in the description!
You attempt to analyze a binary file compiled in the Rust programming language. You open the file in your favorite disassembler. Twenty minutes later you wish you had never been born.
-
@dcon That tends to happen when the inlining gets aggressive.
-
@Carnage said in Can I borrow an apology?:
@dkf this gave me flashbacks.
The biggest problem with witing UI libraries isn't to make it work, even if that is annoying. It's that it is nothing but corner cases a dressed in a coat. And if you fix one corner case at least 500 other ones break.Recently I stumbled upon Avalonia, a UI toolkit that claims to be pretty much WPF but better. It even has a dock panel control, something I dearly miss whenever I work with anything that isn't WPF. But Avalonia's implementation comes with a huge disclaimer:
WARNING
You must define the child control dimension perpendicular to the docking edge, or it will not show.
Changing one of the most useful layouting tools ever invented into a glorified
position: absolute
.
-
@Gustav said in Can I borrow an apology?:
It even has a dock panel control, something I dearly miss whenever I work with anything that isn't WPF.
Like this?
Unfortunately, it's not nearly as good as it could be. But there's also custom implementations which might be nice (no idea, haven't used it):
-
@topspin said in Can I borrow an apology?:
@Gustav said in Can I borrow an apology?:
It even has a dock panel control, something I dearly miss whenever I work with anything that isn't WPF.
Like this?
Not really. WPF's DockPanel is a much simpler, non-dynamic concept. It doesn't have dragging around and floating, it's strictly just a layouting container. The child control can be sticked to one of the four edges, and it gets max size in one dimension and min size in the other. The next one can be sticked to the edge of the remaining space, and so on. The last child occupies all remaining space. You can lay out most of your application that way without complicated nesting of vertical and horizontal layouts, and barely ever specifying explicit dimensions. Unless you use Avalonia, then you lose that last part and it's nearly useless.
-
@Gustav I think you're looking for MDI, and that's really fallen out of favour. The solutions I know of for any platform and toolkit tend to be very app-specific.
-
@dkf said in Can I borrow an apology?:
@Gustav I think you're looking for MDI
I think you need to specify which MDI. I assume it's not the plastic packaging company.
and that's really fallen out of favour.
Just like the entire concept of easy to work with UI design tools, so that doesn't say much.
-
-
@dkf no, that isn't even in the same concept space as what I'm talking about. I mean a thing that converts this
<DockPanel> <Control1 DockPanel.Dock="up"/> <Control2 DockPanel.Dock="left"/> <Control3 DockPanel.Dock="down"/> <Control4 DockPanel.Dock="right"/> <Control5/> </DockPanel>
into this
Menu bar at the top? DockPanel. Status bar at the bottom? DockPanel. Side bar? DockPanel. Another toolbar just under menu bar? DockPanel. A third, content-specific toolbar that doesn't extend over the sidebar? DockPanel. Several columns of content side by side? DockPanel. You can do almost anything with DockPanel.
-
@Gustav said in Can I borrow an apology?:
@topspin said in Can I borrow an apology?:
@Gustav said in Can I borrow an apology?:
It even has a dock panel control, something I dearly miss whenever I work with anything that isn't WPF.
Like this?
Not really. WPF's DockPanel is a much simpler, non-dynamic concept. It doesn't have dragging around and floating, it's strictly just a layouting container. The child control can be sticked to one of the four edges, and it gets max size in one dimension and min size in the other. The next one can be sticked to the edge of the remaining space, and so on. The last child occupies all remaining space. You can lay out most of your application that way without complicated nesting of vertical and horizontal layouts, and barely ever specifying explicit dimensions. Unless you use Avalonia, then you lose that last part and it's nearly useless.
That doesn't sound complicated as far as layout algorithms go.
How hard is it to implement your own layouting in that Not-WPF-library? (Not speaking of a plugin for the GUI builder to make it useable.)
-
@topspin said in Can I borrow an apology?:
@Gustav said in Can I borrow an apology?:
@topspin said in Can I borrow an apology?:
@Gustav said in Can I borrow an apology?:
It even has a dock panel control, something I dearly miss whenever I work with anything that isn't WPF.
Like this?
Not really. WPF's DockPanel is a much simpler, non-dynamic concept. It doesn't have dragging around and floating, it's strictly just a layouting container. The child control can be sticked to one of the four edges, and it gets max size in one dimension and min size in the other. The next one can be sticked to the edge of the remaining space, and so on. The last child occupies all remaining space. You can lay out most of your application that way without complicated nesting of vertical and horizontal layouts, and barely ever specifying explicit dimensions. Unless you use Avalonia, then you lose that last part and it's nearly useless.
That doesn't sound complicated as far as layout algorithms go.
Yeah, it boggles my mind how come there's only one UI framework in existence that comes with a half decent implementation out of the box. But then, we live in a world where there's still no clear answer how to center a div.
How hard is it to implement your own layouting in that Not-WPF-library? (Not speaking of a plugin for the GUI builder to make it useable.)
About as hard as in WPF, which is quite hard. It's a quite involved multistep process. BTDT with another type of control for another use case (in WPF).
-
@topspin said in Can I borrow an apology?:
it's not nearly as good as it could be
that describes about all software.
-
@Luhmann except Rust. Rust is the best any programming language could possibly be
-
@Gustav centering a dev is easy. Vertically aligning a dev in the middle, there’s the real trick.
(Flex does make it a fuck ton easier however.)
-
@Arantor figures webdevs have a different baseline of what counts as easy.
-
@Gustav to be fair, there isn’t “one clear way” to centre a dev because “it depends” isn’t clear, but you know as well as I do that matters in the specification stage!
-
@Gustav said in Can I borrow an apology?:
@dkf no, that isn't even in the same concept space as what I'm talking about. I mean a thing that converts this
<DockPanel> <Control1 DockPanel.Dock="up"/> <Control2 DockPanel.Dock="left"/> <Control3 DockPanel.Dock="down"/> <Control4 DockPanel.Dock="right"/> <Control5/> </DockPanel>
into this
Menu bar at the top? DockPanel. Status bar at the bottom? DockPanel. Side bar? DockPanel. Another toolbar just under menu bar? DockPanel. A third, content-specific toolbar that doesn't extend over the sidebar? DockPanel. Several columns of content side by side? DockPanel. You can do almost anything with DockPanel.
I remember doing stuff like this with Sizers in wxWidgets back in the day.
-
@boomzilla I remember doing things like this with nested linear layouts in multiple different frameworks. It can be done without DockPanel. It's not hard to do without DockPanel. It's just orders of magnitude more annoying, leads to extremely complicated element tree, and takes much more work to get the window resizing behavior right.
-
@Gustav said in Can I borrow an apology?:
Yeah, it boggles my mind how come there's only one UI framework in existence that comes with a half decent implementation out of the box
I know Tk does that sort of layout directly (it's one of two basic ones that almost all UIs are built out of, along with variations on a theme of gridding). Was that the one you were thinking of, or is "only one UI framework" actually wrong?
-
@dkf well, from personal experience, Tk and decency are orthogonal concepts. But that was decades ago, maybe that ancient piece of shit got better over the years. Got any links to the docs? Navigating them myself would require me to learn the basics of Tk first, and I'm not keen on doing that today.
Of the other 9 frameworks I dealt with over the years, 8 of them didn't have anything even close to it. Considering how easy it was for you to claim "how little the core developers of [Rust] are aware of other programming languages" without a shred of evidence (at least you haven't shown any when I asked), I'd say my assessment was very fair.
-
@Gustav That particular layout is within what
pack
does.set f [frame .dockpanel] pack [label $f.control1 -text "Child1"] -side top -fill x pack [label $f.control2 -text "Child2"] -side left -fill y pack [label $f.control3 -text "Child3"] -side bottom -fill x pack [label $f.control4 -text "Child4"] -side right -fill y pack [label $f.control5 -text "Child5"] -side center -fill both -expand 1
NB: Untested. I don't have a working build at the moment on this machine. No idea what I've broken...
You need to say which side to stick things to and what is expanding to consume extra space and so on because there are other use cases (such as another full width child below
Child1
). If you insist on not having such settings then you instead get far more layouts, each much more specialized, and that's not so much of a win.I prefer gridded layouts. They can also do that specific layout, but it's a bit more verbose and I'm feeling lazy.
-
@dkf said in Can I borrow an apology?:
@Gustav That particular layout is within what
pack
does.I did some googling, this is the closest thing to documentation I could find. So far, I don't think I'm ready to call it even quarter-decent, let alone half. Do you know what's the difference between
side
andanchor
arguments? If it really did the same thing as WPF's DockPanel, it wouldn't make sense to have two parameters. Unless they do the same thing, which sucks as far as API design goes.I prefer gridded layouts. They can also do that specific layout, but it's a bit more verbose and I'm feeling lazy.
You're not making a good case for Tk.
-
@Gustav said in Can I borrow an apology?:
You can do almost anything with
DockPanelZomboCom.
-
@Gustav said in Can I borrow an apology?:
Do you know what's the difference between side and anchor arguments?
Yes. The
-side
says which side of the overall space remaining to stick this space parcel to, and-anchor
says where to put the widget within its allocated space. (Anchoring and filling work together to say how to use the space for the widget.)