Yeah. It’s a nice toolkit. I worked with him on a different project. He’s an incredibly talented programmer.
Prima used to have first class support for OS/2 btw.
Based on my digging around, I think Rebol was really good for GUI stuff back in the day as there are hundreds of cool examples of things like Tetris in like 1/4 page of code. Delphi was supposedly really good as well in the 90s when people used it for all kinds of desktop apps. VB6 might be in there as well. Matlab makes this all pretty easy as well if you have a license as it has a form designer and just makes it really easy to do that kind of stuff. C# has Winforms and other stuff to build extremely detailed and complex GUIs, but it's not as simple as Matlab for sure. Tcl has a very common library called Tk that can do a lot of simple GUI work like if you want a button on a form, but it didn't seem to be a good bet for scientific work when I checked. There's a toolkit for Pharo Smalltalk that can do really cool graphics stuff, but Smalltalk is pretty niche in a lot of ways. Python has a bunch of GUI toolkits, but none of them seem very good. Java and languages on the JVM can use some of those toolkits like "Swing", but I don't find it very intuitive. 8th has a built-in native GUI, but it's mainly useful for buttons and drop-downs I think. Mathematica surprisingly has a pretty decent GUI setup in their Notebooks as well as advanced shoot for graphics.
What makes a good UI language? The earlier patterns of GUI development (before the "reactive" hype train) were rather object-oriented, so having that helps (otherwise it quickly gets rather verbose, cf. Xt/gtk). And for smaller event handlers, anonymous functions/lambdas etc.
Perl has that, but so do many other languages.
Speaking of verbosity, having to lay out all the widgets in an app with all their individual properties, coordinates etc. quickly gets quite dense. Here having things like good literal definitions, flexible arguments (variable/default) can make that a lot more concise.
If the language itself doesn't do that for you, tooling quickly becomes necessary. This can be a UI designer (which is usefule in any case), or some ad-hoc UI description language. Which tend to suck (UIL, XAML etc.), and thus require a UI builder application anyway.
Performance is sufficient. Perl always had a lot of packages to help integrating with services etc.
So, yeah, I'd say it's pretty decent, but hardly unique. That was true 20 years ago, and even more so now. Not that anyone cares about desktop UIs.
Because that’s not traditionally what readme files were for, and this one is much more of the traditional style of readme file, not the more recent style where a GitHub repository is treated as a landing page and the canonical source of information about a project, and the readme file presented up front.
Traditionally, readme files were for what you might want to do once you had received the code, which most obviously means how to build it. They were certainly not intended as landing pages, as GitHub has co-opted them (and some, perhaps most, other forges have since followed suit). We’ve reached the stage, in fact, where a readme file in a repository is regularly actually something that should be ignored as irrelevant when you obtain a copy of a repository. And quite possibly that it’ll be chock-full of obscure HTML markup that tries to achieve certain appearances by depending on GitHub’s stylesheets and abusing elements. So much for “read me” and the intentions of languages like Markdown.
A better link for this HN submission would be http://prima.eu.org/, which is the actual project page. The GitHub repository currently linked is only the source code. It’s reasonable for it to have a link back to the site for more information, as it does (though it’d be better more prominently placed at the very start), and there’s no call for it to include the screenshots in any form.
Why is it that Perl never had strong usage in the GUI world? Seems like the object oriented nature of GTK and Qt, and all just generally would work well with Perl.
Is it that TCL/TK sort of filled that niche for rapid prototyping and development 10-15 years ago?
Perl actually had a pretty good UI story way back when. Perl/Tk always was well documented and Perl's syntax works quite well with the original Tcl-ish/Shell style.
Note that GIT's default GUI parts are written in exactly that.
Tk then hit a bit of a limit when it came to common widgets, and so got less popular.
Perl also had a good implementation of Win32, if I remember correctly.
These days, both Perl and GUIs are on a steady decline, so there's not much moving in that space. Gmusicbrowser[1] is written in Perl/Gtk, if I remember correctly.
Millions of these things out there, and it makes me wonder why there hasn't been more convergence on something like a "declarative" GUI spec? I suppose it's probably the prevalance/dominance of HTML/CSS/JS, but dang.
XAML? (Okay, I'm not a fan of it, but it's one way to achieve it).
Or Qt's .ui spec (though too Qt-specific).
I like flutter or Unreal's Slate UI approach (e.g. the UI is in the code), and wished we used that more with our own Qt's use (rather than the visual editor). I'm not saying it's the wrong approach, but it adds complexity barrier, for no good reason (we never had dedicated UI person(s) that just does .ui files, it was all us programmers doing it, so why add this extra layer for no good reason).
QML is something else completely, but bundled, part now of Qt. It's not suitable for desktop apps, at least not in the way we want them to be. Also it has the most horrid way of adding code in there, that's like how the fuck this actually works... No, please no. And I wish Qt stayed away from there.
Our use of Qt, is pretty much what Autodesk does with Maya, or the VFXPlatform community (but in our case it's our level editor - Radiant, written in it - it used to be MFC, but changed since)
20 comments
[ 4.1 ms ] story [ 51.2 ms ] threadSpeaking of verbosity, having to lay out all the widgets in an app with all their individual properties, coordinates etc. quickly gets quite dense. Here having things like good literal definitions, flexible arguments (variable/default) can make that a lot more concise.
If the language itself doesn't do that for you, tooling quickly becomes necessary. This can be a UI designer (which is usefule in any case), or some ad-hoc UI description language. Which tend to suck (UIL, XAML etc.), and thus require a UI builder application anyway.
Performance is sufficient. Perl always had a lot of packages to help integrating with services etc.
So, yeah, I'd say it's pretty decent, but hardly unique. That was true 20 years ago, and even more so now. Not that anyone cares about desktop UIs.
Traditionally, readme files were for what you might want to do once you had received the code, which most obviously means how to build it. They were certainly not intended as landing pages, as GitHub has co-opted them (and some, perhaps most, other forges have since followed suit). We’ve reached the stage, in fact, where a readme file in a repository is regularly actually something that should be ignored as irrelevant when you obtain a copy of a repository. And quite possibly that it’ll be chock-full of obscure HTML markup that tries to achieve certain appearances by depending on GitHub’s stylesheets and abusing elements. So much for “read me” and the intentions of languages like Markdown.
A better link for this HN submission would be http://prima.eu.org/, which is the actual project page. The GitHub repository currently linked is only the source code. It’s reasonable for it to have a link back to the site for more information, as it does (though it’d be better more prominently placed at the very start), and there’s no call for it to include the screenshots in any form.
Is it that TCL/TK sort of filled that niche for rapid prototyping and development 10-15 years ago?
Note that GIT's default GUI parts are written in exactly that.
Tk then hit a bit of a limit when it came to common widgets, and so got less popular.
Perl also had a good implementation of Win32, if I remember correctly.
These days, both Perl and GUIs are on a steady decline, so there's not much moving in that space. Gmusicbrowser[1] is written in Perl/Gtk, if I remember correctly.
[1]:https://gmusicbrowser.org/
Or Qt's .ui spec (though too Qt-specific).
I like flutter or Unreal's Slate UI approach (e.g. the UI is in the code), and wished we used that more with our own Qt's use (rather than the visual editor). I'm not saying it's the wrong approach, but it adds complexity barrier, for no good reason (we never had dedicated UI person(s) that just does .ui files, it was all us programmers doing it, so why add this extra layer for no good reason).
Our use of Qt, is pretty much what Autodesk does with Maya, or the VFXPlatform community (but in our case it's our level editor - Radiant, written in it - it used to be MFC, but changed since)