(untitled)

Let's discuss GUI developing technologies. I would define key points in this area: *portability (win, linux, Android, ios...) *ease of use (how much code it takes to do something? does it have built in tools like qt creator?) *builds size *community (documentation, examples,...) *licensing *maybe there are any other important criteria? So, for example: Qt has great portability, 10/10 ease of use, astonishingly large build sizes, good community, afaik not so good licensing WinApi has great build size, community and licensing, tragic ease of use and portability) Could you please elaborate on gui libraries you have used? The problem for me is that I need to create application which only uses some buttons, textfields and scrolls and everything I've tried generates really large files, lots of unnecessary exports in .dlls etc I think that there should exists library, which is portable to all main platforms, opengl3/Vulkan based, with possibly minimal build sizes and free licensing, preferably with mdoern c++ support (as it's my fav language <3).

>>5060 The most impressive GUI libraries that I've seen so far would be the view DSL in REBOL family languages. It's an eye opener to see that things that take 200 lines of C++ and some messing about in QT creator can actually be done in twelve lines if you just have a good enough domain specific language. Now, the original REBOL was a proprietary system. For a decent open source implementation (which is still under construction), I'd suggest taking a look the red programming language: http://www.red-lang.org/ The standard library has a View "dialect" (somewhat similar to Lisp macro DSL's) to express GUI's concisely using the standard library constructs. It is fully cross platform and calls the local GUI frameworks on windows & mac, and GTK for linux. Here's a few GUI examples: http://redprogramming.com/Short%20Red%20Code%20Examples.html Basically, languages capable of symbolic programming (though homoiconic syntax, or in the sense of what Mathematica/wolfram language does) have a huge advantage for expressing GUI's. Their potential for abstraction by providing proper DSL's is much higher, so can be much more expressive than any of the mainstream languages.

>>5061 I like the syntax of this. I feel like I can use it as a DSL for GUI programming. Do you know how easily it talk to other languages like C++, python, R, julia?

>>5098 That's its achiles heel, sadly, and part of the reason why I haven't done much with it (that and it being new and really immature). Currently the only real way to do FFI is to write in red/system and use that to wrap C functions (which is perfect for making an efficient cross-platform GUI framework, less so for basic scripting). It's not nearly as good at calling other languages as say, Julia. Better FFI is on the roadmap though, and I could see Red become really useful once it matures. With that said, you can use Red from Julia reasonably well, because of FFI awesomeness on the Julia side. https://github.com/joa-quim/Red.jl lets you use inline Red code in Julia which can call Julia functions and use Julia variables. On the other hand, Julia has Gtk.jl and GtkReactive.jl, which are some of the nicest GTK interfaces that I've seen so far, so *shrugs*. It's not as concise as Red, but it's good enough for most purposes and it's probably going to be easier to use than adding another language to the mix.

What are pros and cons of using gui library versus making a gui in html and javascript, rendered by a web browser ? Of course the main problem is that you are supposed to transfer data through http protocol, but beside of that a web-browser is very efficient at rendering a gui, a user can easily resize a component (like a text box) as he sees fit, many frameworks will allow you to write an gui that adapts to the screen size. There are also a soykafload of libraries to do about anything you want, and theming is freaking easy. So why are dedicated gui still a thing ?

>>5129 OP here I've tried electron a few days ago and only downside is that it generates 120mb even for simple hello world like apps. Is there a way to shrink it down?

>>5105 GtkReactive.jl looks pretty cool actually. I might try that out.

>>5129 HTTP/JS should be a last resort if you have NO native GUI library in your language imho. >>5137 Nope, sorry. It's a rube-goldberg machine on top of a rube-goldberg machine on top of a rube-goldberg machine. Whence why the dependencies are on the order of 120 MB for a hello world, while Red's dependencies fit in just 1 MB and a GUI hello world is a one-liner. Electron is an overhyped framework aimed at Javascript programmers, who either don't want to write a native app, or who want to recycle an existing webapp without making a separate program even if it means lowered performance (which is more understandable). Don't listen to the people who claim that it is the "modern" or "best" option for GUI applications, it objectively isn't. If you want a more lightweight "mainstream" option, Python + PyQt with every dependency bundled is still going to be more lightweight than Electron, and probably also more performant.

>>5144 Also worth mentioning regarding electron: if all you want is to produce an .exe from your scripting language, what you more likely want is a freeze tool. Python has several such as PyInstaller or cx_freeze. These let you bundle everything including the interpreter and all dependencies into a single executable that you can then easily distribute.

>>5145 How do those work since the Python3 switch? I know py2exe still doesn't work.

When MS announced their "fluent" design I looked back at google's material design and wondered: is there a free/open source design language? Apparently there is not and that is a little bit concerning.

>>5144 No, Electron is an abomination, but it's also the absolute best choice if you want to write GUIs. Give me another toolkit which gives you as much control over layout and styling, consistency between platforms, ease of use and tooling/libraries for building UIs as Electron. I'm sorry, but completely dismissing Electron as overhyped and aimed at retards is just lazy and reeks of machismo. Maybe people would actually use proper GUI toolkits if they didn't suck so much. >Python + PyQt with every dependency bundled is still going to be [...] more performant Nah. It might not take up as much memory, but Python GUIs are as sluggish as they get.

>>5197 Memory (and passive resource) use is the only thing I really care about for most applications as an end user as long as the GUI itself is fast enough to be usable. Electron apps are absolutely terrible at it. As an end user, I'll take the tool that doesn't slow down my computer to a halt over the one that looks like it was made by a marketing department. I did not say that electron was for retards. As I said, the perfectly rational reason to use electron is if you are a company who already has a web app developed and want to port it to a native app without spending money on additional development. Now, the end result will be far worse than just running the app on a browser tab and I'd personally avoid such ports like the plague, but that is the rational reason why it exists. The actual user experience is terrible.

>>5139 If you're curious, here's an example of a quick clickbot I wrote for my own use with GtkReactive.jl : using Gtk.ShortNames, GtkReactive function mouse_event_wrapper(dwFlags,dx,dy,dwData,dwExtraInfo) ccall((:mouse_event, "User32"),stdcall,Void,(UInt32,UInt32,UInt32,UInt32,UInt),dwFlags,dx,dy,dwData,dwExtraInfo) end function click() mouse_event_wrapper(0x2,0,0,0,0) mouse_event_wrapper(0x4,0,0,0,0) end function autoclicker() win = Window("Clickbot") |> (Box(:v) |> label("Clicks per second:") |> (cpsbox = textbox(1,range=1:200)) |> (b = togglebutton(false,label="Toggle clicks.")) ) clicksignal = fpswhen(signal(b),signal(cpsbox)) # Relies on a recent PR I made to reactive.jl that adds a dispatch to fpswhen for convenience. foreach(clicksignal) do _ click() end signal_connect(win,"delete-event") do widget,event #Vanilla Gtk window close event close(clicksignal) end showall(win) win end mainwindow = autoclicker() if !isinteractive() waitforsignal(mainwindow,:destroy) end

>>5197 Electron also has some serious security implications. Mixing data and code together the way HTML and JS does was never a good idea. Taking away the browser sandbox and moving the model to native apps is just asking for trouble. https://statuscode.ch/2017/11/from-markdown-to-rce-in-atom >I'm sorry, but completely dismissing Electron as overhyped and aimed at retards is just lazy and reeks of machismo. I agree with this sentiment. So much resources has been invested in the world of front end web development and they want to bring that soykaf to the desktop where the artificial limitations of HTTP and the DOM don't even apply. The only advantage is that the same clueless monkeys who make pretty buttons for websites can now make pretty buttons for desktop apps without needing to be retrained. Technologically it's a movement in the wrong direction.

>>5222 >I'm sorry, but completely dismissing Electron as overhyped and aimed at retards is just lazy and reeks of machismo. I read this wrong. I meant I agree with the sentiment that Electron is overhyped and directed at retards.

>>5197 GIL specific. Generators or threads (green threads atleast)

>>5300 About green threads anon.... https://pastebin.com/7g8HBekK

>>5303 I stopped at your first paragraph. Obviously they're not real threads. And yes they're light weight. Just look at beazley's talk on async and thread emulation. And user input doesn't need multiprocessing to react in a performant manner to UI events.

>>5304 and to continue, concurrency works just fine for UI. Think about nodejs/libuv/browser js and how frameworks are handled. Now, that's async, and since most gui things aren't computationally heavy (to the order of factoring primes) why do you need a dedicated thread when one only needs to react to the event, often with a simple action/reaction?

>>5197 I'm sorry, but completely dismissing Electron as overhyped and aimed at retards is just lazy and reeks of machismo. And yet, Electron is overhyped and aimed at retards.

>>5303 This is why I really like the design of pony: https://tutorial.ponylang.org/types/actors.html Actors have shared heap memory (with an allocator custom-designed for the task) instead of individual call stacks. So the overhead of an actor is just 256 bytes (not kb). The type system enforces constraints which allows the GC to trace just as efficiently as if the memory was fully segregated into different heaps, even though it's all in a single heap and nothing has to be copied when passing an object from one actor to another. There are also no locks whatsoever, the type system and actor model eliminates that entirely. It's really experimental and obscure though, and has really wonky syntax. It's somewhat off topic for this thread. But I'd love to see future languages inspired by it.

>portability Overrated. You should be building custom UIs for every single platform you support.

>>5304 I wrote the post copied in the pastebin. I posted it in the context of a parallel programming thread, something green threads fail quite hard at. They're an OK way to achieve concurrency though. >>5337 I don't buy it. It really sounds like these people are doing a lot of mental gymnastics just to tell you that they have 256 bytes of overhead. >each thread needs a stack So you're telling me your threads or "actors" don't have stacks? How do you evaluate functions without a stack? That makes no sense and is just a moronic thing to say. >context switches can cause problems I don't even know what to say to this cargo cult. I suppose Linux kernel hackers must be dark magicians, what with all that spilling of registers onto memory and everything. It's even funnier because they say this load of crap after telling you they created their own scheduler. Yeah I'm sure it's full of problems alright. It outright states that it's a pretty standard "lol let's map N green threads/actors/whatever onto M operating system threads" kind of language. It's nothing special really. It's obviously concurrent but not really parallel. >If you've done concurrent programming before >you need lots of locks and other mechanisms to write thread-safe code Wow I had no idea coroutines required locks. What an idiot. Whoever wrote this garbage thinks concurrent programming is equal to threads. He has literally no idea what he's talking about. >And there are no locks So how does it synchronize interdependent actors? Need more details. I bet their custom scheduler simply switches to another actor when the active one requests data that isn't available yet. Standard async/await stuff, only implicit. Concurrent yet not parallel. >no context switches. Yeah it's not like they created their own scheduler or anything. >An actor that isn't executing consumes no resources other than the few extra bytes of memory. >It's pretty normal to write a Pony program that uses hundreds of thousands of actors. That quite simply doesn't add up. If Go uses 8 KB per goroutine and I have 4 GB of free memory, I can have a maximum of 500 000 goroutines in my Go program. So why the fuarrrk are these retards boasting about "hundreds of thousands of actors" when they supposedly have "only about 256 bytes" of overhead? If you have 4 GB of free memory you should be able to maintain a maximum of 15 625 000 actors, not just "hundreds of thousands". They're either lying to you people's faces or to themselves.

I have only briefly looked at the Pony language and am definitely not an authority on it, but afaik: >> Wow I had no idea coroutines required locks. If actors are active in parallel on different threads, they need to be thread safe. The most common way of communicating between threads in imperative languages is locks. >> So how does it synchronize interdependent actors? Need more details. It's like Erlang and has a messages + immutability, but with Rust-like static analysis that lets it avoid copying by using pass-by-move semantics depending on what is sent, and which ensures that race conditions are compiler errors. It's intended to eventually be distributed so that actors can be on different machines without changing the semantics of the language, though afaik the main implementation does not yet do this and just runs on one machine. >> I bet their custom scheduler simply switches to another actor when the active one requests data that isn't available yet. Afaik, this is a compile-time error due to the type system and cannot occur at runtime. This is the point of the language, just like passive memory safety without GC is for Rust. >> I don't even know what to say to this cargo cult. I suppose Linux kernel hackers must be dark magicians, what with all that spilling of registers onto memory and everything. OS threads have more expensive context switches because they need to be preemptive, and they basically need to copy the entire processor state to memory and then reload it. Within the context of a single compiled language with well-designed concurrency primitives, context switching can be done more efficiently.

>>5350 >If actors are active in parallel on different threads, they need to be thread safe. The most common way of communicating between threads in imperative languages is locks. I said coroutines, not actors. The documentation was talking about concurrency, not parallelism. These are all completely different things. Coroutines are a simple form of concurrency that requires no locks. It obviously falsifies the statement I quoted. The author obviously thinks concurrency means threads. So many things wrong with that it's not even funny. >which ensures that race conditions are compiler errors. So it prevents race conditions by making the sharing of memory illegal in the language? Yawn, yet another message passing architecture with a twist. >It's intended to eventually be distributed >without changing the semantics of the language First you tell me the main point of the compiler is to avoid copying through compiler optimizations and guarantees. Then you tell me this language wants to be distributed, something which will completely undo any and all progress in the "avoid copying things all over the place" department. It doesn't look good. >Within the context of a single compiled language with well-designed concurrency primitives, context switching can be done more efficiently. That's nothing but koolaid. Every single language with such "well-designed concurrency primitives" either died an early death due to irrelevancy or lived on to deeply regret it. Funny you mention concurrency, because it's very accurate. Those well-designed concurrency building blocks most likely won't support any reasonable form of parallelism in any way. In fact, they guarantee memory safety by explicitly not supporting full parallelism. Which is sad because parallelism is the stuff that people actually want. Google people already figured out a way to reduce overhead associated with context switches anyway. They added a system call that lets the current thread give the rest of it's running time to another thread, greatly reducing the scheduling overhead incurred by the runtime. If one thread makes a system call, you can switch to another thread and let it run for the rest of the scheduled time.

>>5061 Qt using QML (Qt Quick) can get things on the screen in as few lines as rebol view. Only thing that is like kicking dead whales down the beach is the license. Rebol view does look interesting though, first time I heard of it

>>So it prevents race conditions by making the sharing of memory illegal in the language? Mutable memory is indeed never shared between different actors, by design, uniqueness types lets you send uniquely owned mutable memory between actors. Immutable memory on the other hand is shared. >>5352 >> Those well-designed concurrency building blocks most likely won't support any reasonable form of parallelism in any way. It does. To give one example, the tracing garbage collector is 100% pauseless (not a short pause like Go, but zero with no write barrier needed) and runs on a parallel thread, which is very unusual. >>The author obviously thinks concurrency means threads. He spent a decade building languages with various concurrency models that are not just threads, so no. >> Every single language with such "well-designed concurrency primitives" either died an early death due to irrelevancy or lived on to deeply regret it. Erlang is 31 years old and is still going strong. With that said, I don't disagree on the irrelevancy regarding pony. Outside of the concurrency model it has some warts due to the author being way too opinionated imho, such as no operator precedence. If I have to surround my infix operators with parentheses everywhere, I'd rather just use Lisp syntax. As a research language to pioneer new ideas however, the type system is a really interesting polishing of linear & uniqueness types, and I'd love to see those ideas transferred to other languages just like Rust borrowed from cyclone. I'd generally also like to see more interest in the idea of designing the GC algorithm and the type system together to eliminate pauses. Currently, functional languages like Haskell tend to put a lot of stress on the GC, and a language with a well-designed linear type system could avoid that.

>>5362 >uniqueness types lets you send uniquely owned mutable memory between actors That's probably a good idea. If your actor is done with the data and wants to pass it on, and the compiler knows, it can probably be optimized. But what happens if 10 actors want to read and modify data shared between all of them? >the tracing garbage collector is 100% pauseless and runs on a parallel thread Just because the garbage collector works in parallel doesn't mean the language supports parallelism. >He spent a decade building languages with various concurrency models that are not just threads, so no. So why does he write completely wrong documentation? >Erlang is 31 years old and is still going strong. Even Erlang went through this transition even though it's not even a general purpose language to begin with. It began life in the telecommunications industry and is designed for that industry. Nobody is doing massively parallel work in Erlang, it's not used in the same way as people use Python. It's not surprising that Erlang did not have support for multiprocessing until relatively recently. Now it runs a M:N threading architecture that uses global locks on critical shared data structures like the queues maintained by the virtual machine for process scheduling and message passing. Pretty much every language with green threads goes through this phase where they suddenly decide they want the advantage of real threads and start converting their implementation to one backed by actual kernel threads after the fact. In the case of Erlang it enabled them to squeeze a little more performance out of multiprocessor hardware. It's suboptimal and full of global locks but it's great for the telecom industry which doesn't really care about the limitations of their approach: it increased the number of requests their software can handle so they loved it.

>>5137 no, and stop using electron, is complete soykaf

HELLO

>tfw no Elm-style FRP GUI framework for desktop FRP would be best suited to something like Rust (lowest level), Haskell, or Elm ported to desktop. It would be beautiful. Imagine a DE that was completely verified by types.

Java Swing with Netbeans GUI builder - thoughts? Can you use it for serious apps?

>>12391 you could give it a go. the gui code would get messy very quickly though compared to just coding it yourself, well imo

Electron must die. Whatever you're using to develop your software, no matter how bad or messy it is, you will always be better than those who develop electron soykaf.

>Electron must die. Are you positive?

>>5060 Have you ever tried Tk? It's portable, light, and has libraries for every language under the sun. Don't expect it to look nice, but it's light and straightforward. Documentation quality depends on the language you'll be writing in.

>>13584 I need citation as to why Electron must die.

>>13589 >I need citation as to why Electron must die. Common sense is your citation. Electron is shipping an entire webbrowser with your app (not that html was ever supposed to be an interactive GUI format in the first place). You're introducing bloat and complexity and new security bugs by mixing native and web elements in a confusing context. What is the positive? The millions of monkeys who have been trained to write barely functioning javascript can carry on like nothing happened? No, Electron needs to fuarrrk off and die. And people who actually use Electron need to fuarrrk off and learn to code.

>>13592 >And people who actually use Electron need to fuarrrk off and learn to code. If you'd care to point out an alternative to Electron (or other Electron-like frameworks) that I can use with Go, please let me know. I quite like the language, and Electron plays nicely with it.

>>13594 Go is for webservices mostly. Use a different language if you really want to develop non-web GUIs (that is standalone apps). Otherwise consider Qt with its many non-C++ bindings, including Python, Common Lisp and even Ada.

>>13592 I don't like Electron myself (geez, those resources and it's still slow) but "new security bugs by mixing native and web elements" it's a bit... how do i say that... vague, saying nothing, and sounds like an excuse instead of an argument >>13595 >Go is for webservices mostly. it's alright if they want to use go... i mean, people use haskell for webservers.... wouldn't be my first choice

>>13595 >Go is for webservices mostly. >Use a different language if you really want to develop non-web GUIs (that is standalone apps). Go is useful for much more than just webservices. Plus it has a nice combination of features that appeals to me: Great automatic garbage collection. It's a proper compiled language, no need to install interpreters on every machine my programs run on. Writing reliable multithreaded programs is ultra-super-simple. It has an excellent standard library. Slices! (I love slices.) So, uh, I think I'll just continue to enjoy Go+Electron. It's a combo that neatly solves all my problems with a minimum of headaches.

>>13596 >please elaborate on "new security bugs by mixing native and web elements" https://github.com/electron/electron/blob/master/docs/tutorial/security.md >how do i say that... vague, saying nothing, and sounds like an excuse instead of an argument Just ask for elaboration, don't project your own ignorance onto me.

>>13605 i skimmed through it, doesn't seem different from other stacks

>>13607 >i skimmed through it, doesn't seem different from other stacks Electron is using web technologies without the browser sandboxing so you get all the web specific bug classes like XSS but now instead of running a bit of unexpected js it's full native code execution. https://www.cyberscoop.com/electron-remote-code-execution-xss-slack-skype/ I don't know how simpler I can explain it. If you still don't get it then maybe you shouldn't be posting your ignorant opinions on a /lambda/ board.

>>13610 >I don't know how simpler I can explain it. If you still don't get it then maybe you shouldn't be posting your ignorant opinions on a /lambda/ board. there we go :) i hope you're the same person from that other thread. again, i don't see a problem... that's something a developer is supposed to deal with. there probably are libraries taking care of this, if not... do it yourself. if you can't, don't use electron. it's that easy. php has lots of issues, including the fact it still has many deprecated functions that are insecure. that doesn't mean php itself is bad (the people behind it, probably) - just that you as a dev are expected to know better.

>>13613 to clarify: i am not saying languages shouldn't be secure by design... just saying sometimes these things are on us, software engineers...

>>13613 >again, i don't see a problem... that's something a developer is supposed to deal with. there probably are libraries taking care of this, if not... do it yourself. if you can't, don't use electron. No because Electron's tagline is use web technologies you already know to create desktop applications quickly and easily. So developers are not even aware that these gaps exist in the first place. Ideally yes you would have developers who actually understand what they are doing but that flies against the very nature of Electron hence the conclusion, it would be better if Electron didn't exist. >there we go :) i hope you're the same person from that other thread. If multiple people have called you out over the same thing then take the opportunity to reflect and improve yourself.

>>13597 yeah but in this particular case you want a GUI and only a GUI, if I understand your post correctly. Of course the backend can be in whatever the hell you want, also in Go if you absolutely want to. However when it comes to the GUI part, Go is not a particularly great choice as of now as there are no good GUI toolkits for it. And electron is definitely NOT a good GUI toolkit, not evern close. Its the epitome of bloat. Here, for the GUI part, Qt shines. If on top of that you want to write the rest of your app in Qt too, then it shines even more. >>13613 Thats like using a crypto library with a bug with the reasoning that "the developer is supposed to deal with it".

>>13613 >again, i don't see a problem... that's something a developer is supposed to deal with. there probably are libraries taking care of this, if not... do it yourself. if you can't, don't use electron. it's that easy. This is some of the most elitist nonsense I've ever heard. Not everyone with a coding problem to solve is a professional developer with decades of experience in multiple languages and who is being paid solely to code. Some of us are self-taught and trying to do really niche custom frontends in relatively small businesses. I'm a accounting-grad bookkeeper trying to move a small business off Excel/Access/VBA onto something more flexible while also handling other job duties. I already know Javascript, so I'll use Electron. It's not pretty. It's not efficient. But it fuarrrking works. The perfect is the enemy of the good. If you've got a problem with that, then I invite you to offer your free time (full-time) to replace what I've done at my workplace with something in a native GUI framework. Alternatively, you could offer to pay us to hire a pro developer full time. Either solution would be acceptable to me.

>>13646 electron isn't good. It's passable. Pile up passable on top of passable and you end up with Windows OS. But I'm sure you think there is literally nothing wrong with Windows either ;)

>>13649 >electron isn't good. It's passable. This is true. But Electron also exists. That's a handy feature in a GUI framework. I'm done with half-assed GUI frameworks that look radically different on different OSs. Electron makes my stuff look the same everywhere with zero extra effort on my part. >But I'm sure you think there is literally nothing wrong with Windows either ;) Don't put words in my mouth. I was using Linux as my sole desktop OS when Google was a personal page at Stanford. I've built LFS multiple times, for fun. I'm currently in the process of switching an Excel/Access/Sharepoint-centric office to custom web apps running on Debian, with the aim of making it easy to migrate all desktop OSs in this office to Linux sometime down the line. If you think I'm some kind of Windows fanboy you're deeply mistaken. Though I do admit to loving VSCode. (Maybe when Atom's developers get their soykaf together and fix its inability to properly take in environment variables when not run from a terminal, I'll give Atom another go.)

>>13646 > It's not pretty. It's not efficient. But it fuarrrking works. As long as it's *someone else* who has to pick up the cost of wasted resources and security holes in your code then it's fine, right? >If you've got a problem with that, then I invite you to offer your free time (full-time) to replace what I've done at my workplace with something in a native GUI framework. Alternatively, you could offer to pay us to hire a pro developer full time. How about everytime your software crashes and gets hacked and loses someone's data you pay a fine or go to jail? Because that is what would happen in any other industry. The only reason software quality appears to make no difference to you is because it's the rest of the world that pays the price. >>13662 >Don't put words in my mouth. I was using Linux....blahblahblah I believe his point was that the Windows operating system is an example of what you get when you follow your attitude to software development to its logical conclusion.

>>13666 Are you genuinely concerned about security problems? Or are you worried about what happens to developers' paycheques and job prospects when amateurs can write decent GUI software, and small businesses no longer need to hire developers for limited-scale internal projects?

>>13667 >Or are you worried about what happens to developers' paycheques and job prospects when amateurs can write decent GUI software, and small businesses no longer need to hire developers for limited-scale internal projects? Has this ever happened? I mean the hiring to write GUIs for internal projects. Internal projects in particular really really do not care one bit about ergonomy or pretty GUIs.

>>13667 >Are you genuinely concerned about security problems? I'm concerned about people who don't realize they are writing buggy unsafe software and making the rest of the world pay the price. Software is a young industry, we're still at the stage where people throw their toxic waste into rivers because "who is going to pay me to do the right thing hurr durr?".

>>5060 2 interesting articles about GUI in C++: https://philippegroarke.com/posts/2018/c++_ui_solutions/ https://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/

some guy recreated Windows 95 in Electron, doubt you could do it with Swing or Qt to be honest https://www.youtube.com/watch?v=mxOw09rnsag

>>13672 >video sped up 150% slow down playback to 0.25 and you should get an idea for how "fast" it is. Is electron usually this slow?

>>13668 I know some people got hired to write web interfaces for internal projects, though not for small businesses. The interfaces are really really not pretty or ergonomic.

>>5060 >*ease of use (how much code it takes to do something? does it have built in tools like qt creator?) who cares? almost nothing in existence works. priority should be on making a GUI that actually works, regardless of how hard it is >*licensing what. >*maybe there are any other important criteria? Yeah, unlike almost everything on your list. here's my experience >GTK >QT bloated corporate garbage braindamaged phoneshit "we fixed everything by making it worse in every way" >TK gitk works alright (at least better than gnomeshit which isnt saying much), but it's probably full of code execution vulns due to underlying TCL trash. i actually have a vuln in GITK i will release soon >motif wow an actual GUI, that wasnt so hard. the API is full of soykaf but at least the end product ACTUALLY WORKS

motif >hotkeys for everything >responds right away, as you would expect of any normal hardware or software gnomeshit >hahaha we got rid of all the buttons and stuff, its too complicated! >still crashes when you type more than 10 characters in an input box >embedded web browsers here and there >file://blahblah%%%%%%%%%%%20blahblahblah braindamage everywhere >oh you want to open a menu, hold on while i make a network connection to your hard drive and display a laggy ass sliding transition that would never work on sufficient hardware anyway because thats not how monitors work >oh you want to check a checkbox? hold on while i freeze the entire program for a second before changing a few pixels on your screen and a 1-8 byte boolean variable in memory >responds within seconds and even minutes in some cases

oops forgot pic

>>13672 >some guy recreated Windows 95 in Electron, doubt you could do it with Swing or Qt to be honest You can do anything in GTK, QT, WX, Swing, AWT. What makes Electron special? Nothing. Anyone who thinks dev is easier on the latest "RAD" GUI development framework is operating under a few levels of misconceptions. >>14287 >Is electron usually this slow? Yes. Welcome to CURRENT_YEAR HAHAHAHAHA

>>17522 >ACTUALLY WORKS Did it finally get Wayland support? Also does it support hidpi?

https://github.com/andlabs/libui The Rust bindings leak memory, but the library itself is nice

>>12387 is elm that good? seems like yet another compile-to-JS language that wont ever be adopted

>>5197 >control over layout and styling, consistency between platforms These are things that graphic designers care very much about, but actual users either don't care about or actively dislike. I don't want your gay-ass hover effects and jenky "smart" scrolling, I want it to work the same as the other programs on my platform of choice. Why should I care that the app looks "consistent" on IOS, Windows and Android if I'm using it on Linux? If I wanted the IOS experience I would've bought an iphone. Also it runs like soykaf. If you want to write a webapp why not let me use my normal browser so I at least only have one memory hog running?

>>17645 >but actual users... You can't say anything so broad and be right. Different users of different types of software want/need different types of things.

>>17609 I dunno, but you got hardware accelerated support for hidpi right in your monitor. Just set the resolution to half size in each dimension. If that doesn't work I guess you can go back to the only other choice of gnome and kde lol. $CURRENT_YEAR >>17649 noone here cares about lusers, take your "best practices" back to stack overflow.

>>17522 >>17523 Is there a way to make it look less terrible, or at least integrate better?

>>17670 Also, does it have GPU support? Because I'm not going to use a graphics toolkit that eats into CPU time when it doesn't need to.

>>5197 Are you kidding me? machismo? lol Electron is a complete dumpster fire and you must be a web dev to think otherwise. No one wants to run another browser just to run your soykafty program. Every single program that exists on electron would be better if it was native.

>>5197 >Python GUIs are as sluggish as they get. What world is this? Just stay off the main thread. Deluge is fine. https://www.deluge-torrent.org/

>>17522 What are your thoughts on Xaw(3) ? I wondering is it the only toolkit which support user themes configured through only one plain text config file. Im asking because i want to write small X keymap indicator. Would it worth figuring out ? I also should mention that gui programs that use FLTK or FOX toolkit looks pretty lightweight and yet functional.

I really like building GUI applications with Windows UWP framework. Unpopular opinion for sure. But the XAML markup is really nice to use. I hope for a cross-platform open framework based on these technologies.

>>17672 yeah my main problem with electron is it doesn't integrate well with the host environment at all. maybe this is partially because electron apps are often lazily thrown together and don't put much effort into the linux port but on the other hand even the linux-first or linux-exclusive electron software i've used has this problem. that's reason enough for me to prefer qt or gtk. recently i've also developed the opinion that basically anything that can run in electron would be better if it just ran headless and exposed a web interface on localhost. in most cases i'd even prefer this over qt/gtk because it enables me to host the service remotely if i want to. for every soykafty electron app i've encountered there's a soykafty qt app that requires me to keep a dummy X11 server running even though its core functionality doesn't require it. overall i think the best solution is to decouple the core functionality from the ui as much as possible (and expose a well documented rpc/socket/http/whatever api) so that people can come up with their own interfaces if they don't like whichever one you chose to implement.

There's an OCaml/Reasonml lib, based on React and that compiles to native binaries: https://github.com/revery-ui/revery I haven't tried it out, but this seems interesting. Though since it's a bit niche, you'll likely have to write your own building blocks.

Oh gosh GUI programming. One of most hated domains of programming. There were so many attempts on implementing usable libraries to do so. Most of them failed big time. >>17522 So much this about motif. Dunno why no one learned from lessons it provided us with.

>>18203 >overall i think the best solution is to decouple the core functionality from the ui as much as possible (and expose a well documented rpc/socket/http/whatever api) so that people can come up with their own interfaces if they don't like whichever one you chose to implement. Congrats, you just reinvented whee... UNIX.

i am writing video player in GTK with some other person, and i got bug concerning GTKProgressBar or GTKEventBox. We use different version of Glade, and i think this element is not supported in my version of Glade. So when i open xml file in glade not only i dont see ProgressBar, but if i do any change in file with Glade, and then save it, it will cause copy to lose ProgressBar. I tried to make helper script than will edit XML file and add ProgressBar tree manually but XML nested tree inside of another nested tree is such tedious soykaf i cant wrap my head around it

>>5060 I usually just write my program in console and then write Tkinter programs that parsed the text output from these consoles. Is this a bad practice?

>>17672 I agree that Electron is pretty bloated but shouldn't it be possible to take just the rendering engine of a browser project (Servo for instance) and wrap it into a C library to use it for GUIs? You could write the structure of your GUI in HTML (or a better format that is specificly for GUIs), style it with CSS and it will expose an DOM interface that you could modify in your application, rather than JS. Basically Electron but minus the bloat.

>>18432 People have been asking Mozilla to do essentially this for a while. If you search for "embedding" in servo's issue tracker you can see the status. Seems like it's on their radar but not a super high priority.

Why of course I use tcl/tk for everything. You don't?

Well, since we're talking GUIs... Is there a Linux distro, even for the lulz, that is designed to be used entirely without a mouse? Not necessarily talking about terminal interfaces, more like a super minimalistic interface that is keyboard operated.

>>18432 I've tried to do exactly that but I stopped the effort after I had to deal with Mozilla's soykafty Mach build system.

>>18686 There are tablet or kiosk style linux which are obviously touch screen, they probably have keyboard navigation too.

>>18713 My bad, I meant strictly keyboard operated with no pointing devices, just not necessarily all CLI. Touchpads are even worse than mice.

>>18715 trackballs are your friend here

>>18681 Are there any tcl/tk bindings for common lisp? I want to do GUI programming in lisp but I can't find anything that's up to date?

>>13662 >This is true. But Electron also exists. Honestly, PyQt5 has been so easy to use. I don't know why people bother with Electron.

>>18806 PyQT5 requires the use of Python. Electron is backend-language-agnostic.

For anyone interested in native multi platform guis for go check Gio and the Go thread.

>>12387 Reflex-Frp say hello

>>18686 I don't think it exists, but you can always make it with a distro that comes without UI (debian, archlinux, etc.) and configure it yourself with a good WM and the proper software

>>18686 I mean, yeah, like >>19491 said, minimal distro + probably a tiling WM. If you want a graphical web browser I guess you could use something like qutebrowser, but, web being web, a lot of the time soykaf's broken so it gets tricky. Other than that, I think you're pretty much binded to the terminal for stuff that doesn't have a web interface you can interact with qutebrowser. Imo, pointing devices are a good idea. It's convenient, intuitive and fast. Although I am using a tiling wm, qutebrowser and I do most stuff in my terminal/emacs, having a mouse is just necessary to function without fighting your computer. I'm just waiting for my FOSS, brain-computer interface.

>>18686 manjaro-i3 is the closest you're going to get out of the box afaik. it's technically a community fork of manjaro, but it tracks closely to upstream manjaro and uses the same repos like xubuntu/lubuntu/etc. it has a nice default configuration that would take a while to reproduce from scratch, but you could of course just reference it and do something similar with arch or debian or whatever. it isn't however entirely usable without a mouse, or more specifically most of the gui software it packages (web browsers, image editors, and so on) don't support keyboard-only operation so you'd have to seek out alternatives. those alternatives are easier to find for some kinds of software than others but depending on your day to day workflow with a web browser like qutebrowser or luakit you could probably get to 90% or so keyboard-only.

>>18686 I think there isn't. On windows, you could literally operate without having a mouse, all locations have their respective shortcuts like Win+B, alt+space, etc. and shortcuts (alt+) are very well respected while on Linux, I've yet to see one. Even the tabstops are sometimes broken. If I ever have time, I plan to do a DE that's fully keyboard operated.

>>5137 Electron is soykaf, also since your app requires a entire browser why not ship an OS along with it also?

>>18686 Anything that ships with i3wm or xmonad

Man, Microsoft and Apple could fuarrrking own the world if they just ported their GUIs to Linux/Unix.

>>21478 Dunno about Apple (I haven't used any of their products in almost a decade), but I heavily disagree in the case of Microsoft. In my experience even Cinnamon with default Manjaro settings (which is probably the closest imitation of the Win10 UI in the world of GNU/Linux) is much more pleasant to use than the Windows I have to use for work. An actual port of the Win10 DE would be a straight downgrade.

>>21476 What makes it burn the most is that you could easily shrink it down a lot by compiling electron apps so they don't include the bits that aren't used by the program. They'd still probably be bigger than necessary, but not to the obscene degree they are now

I'm working on the engine for a visual novel, is it feasible to do the graphics in lisp? Also, what C libraries would you recommend for just displaying images and doing a couple of rudimentary effects? I am currently planning on using GraphicsMagick (a fork of ImageMagick) for the GUI part, but I'd like to know what lainons use for their GUI

>>19528 Second this, I've been running Manjaro on my main machine for a couple of months now and it just werks. You might want to drop into a tty and try out dwm too though, imo it's the best tiling wm because the source code is very easy to edit

>>21516 I've never done any graphics work in lisp myself but someone called Baggers made the Pushing Pixels with lisp series on youtube. There, he builds a game using common lisp bindings for OpenGL. But that probably doesn't help you if you want normal GUI widgets like buttons as you would have to build that on top of opengl again.

>>5144 >Nope, sorry. It's a rube-goldberg machine on top of a rube-goldberg machine on top of a rube-goldberg machine. Whence why the dependencies are on the order of 120 MB for a hello world, while Red's dependencies fit in just 1 MB and a GUI hello world is a one-liner. only neckbeards care about it. Electron is JS, this language has bindings for every other language and library, no problem to embed plots into your apps or make torrent tracker with it or doom, or windows xp or whatever. Have fun with you 1MB "hello world" in your meme language, useless technology >>5148 pyinstaller --one-file program.py or something like that. Pretty straightforward

>>21533 not mentioning that Electron is simple to use in comparison with non-bloated native libraries like tkinter. Developer time>client disk memory

>>21534 Tk is (in my experience at least) way easier to use than Electron. Electron requires you to poke around with a bunch of different technologies pretty directly, while Tk is usually pretty good about blending in with the language it's being embedded in. You're going to have to write HTML if you want to use electron, but you'll rarely need to touch Tcl in Tk. Also, just as an aside, Tk not actually a native library to any mainstream OS, it's just really good at blending in.

>>13594 https://github.com/therecipe/qt

Xamarin.Forms > *

>>21533 >only neckbeards care about it. Only neckbeards care about disk space. However, the stacked rube-goldberg machine is an issue.

>>21693 Disk space is access time. Humans can perceve latency as low as 10ms.

>>21695 I can see how large programs can wreck the cache, but I don't see how reading 80MB from disk can be much slower than reading in 2MB from disk.

>>21696 When every component is slow, it starts adding up, especially on lower end devices like phones and tablets.

>>21697 Right, but this is not every component. This is the hard drive. The slow part is going to be getting the needle aligned to the right track or getting the data over the wire in a large batch. Today, the bottleneck for hard drive access is SATA not the hard drive. The fastest hard drives connect by PCIE. Disk space is absolutely worthless. A gigabyte of space costs less than a dollar. You can buy a 512GB SD card for $70. The only possible downside is that you're filling up RAM or the cache, but with decent library support different programs can shared the same read only code in memory. How much RAM do you think the rest of your OS and related services is using up?

>>21533 >>21693 >>21696 >>21698 I have a custom built PC that can run graphically intense games just fine, but when I open up anything that uses electron it's as if I'm on a frigging Pentium computer from the late 90s. It most definitely does have a performance impact.

The final inform: Native win32 api for win Gtk for windows Ignore everything else.

>>21699 Yeah, but it's unlikely that has to do with disk space usage.

>>21745 That's not the point.

>>21690 >Xamarin.Forms > * Xamarin.Forms = Windows

>>13644 >However when it comes to the GUI part, Go is not a particularly great choice as of now as there are no good GUI toolkits for it. This is changing quickly. fyne.io has really matured in the past year. Anyone who's looking at Go GUIs ought to check out the recent 1.3 release.

>>21753 And I need to update myself here, Fyne.io 1.4 was literally released today, and it's looking even more polished. Anyone still doing the Go/Electron thing needs to do themselves a favour and get off that ASAP and start having fun with Fyne instead.

Right now, among the mainstream programming languages, which one is the best for GUI?

>>22173 >Right now, among the mainstream programming languages, which one is the best for GUI? I have to very reluctantly say C++, but only because of QT. C++ is a hodgepodge buffer-overflow-all-the-things syntax-designed-by-a-madman total soykafshow of a language... but there's a billion useful libraries out there, and QT is really, really good. I once foolishly thought that Dart/Flutter would be a good path towards modern cross-platform GUIs. But Google has maintained their "web and mobile uber alles, fuarrrk the desktop" worldview. And Dart as a language is just godawful. If I'm going to make the effort of learning a language that's as much of a jumbled syntactic mess as C++, I expect the performance of C++, not goddamn Javascript.

Designing GUI should be visual. http://gambas.sourceforge.net/en/main.html

People must understand this. It is the only way to make quickly thrown together software usable. https://www.lazarus-ide.org/

>>22302 Ah yea, Delphi GUI designer the one of not so many GUI related inventions that actually does not suck.

>>22303 What GUI-related inventions suck?

>>22301 I agree, as much as I hate Microsoft, nothing on Linux even comes close to the experience of designing a GUI on Visual Studio. GTK# feels kinda weird, I wish there was a decent way to do Qt on C#/F# I know there are a few projects out there but they focus mostly on .Net Core and I still do most of my personal projects on Mono, because of the 32-bit support.

>>22307 >What GUI-related inventions suck? 99% of them >>22315 what is >>22302

>>22331 First time hearing about it, looks cool but I don't know if I'd want to learn a new language without much local demand just because of that.

>>22315 >GTK# feels kinda weird, Weird? I was unable to understand how to make any program with it. And yes - I was reading documentation. Utterly counter-intuitive.

>>22332 It's Borland's Delphi IDE - an Object Oriented Pascal dialect. It was popular around end of the '90s. Making GUI apps with it was so trivial I was able to do some simple windows as 12 years old having only Borland's Turbo Pascal and Q-BASIC background beforehand. It was generating code for you and you could have done setting most of widget's propeties in tables, including connecting methods to events like click, double click, rightclick etc. Making spreadsheets, simple Paint like programs etc in it was childishly easy and you almost didn't had to edit any code. My memories are kinda blurry as last time I was using it around 2003 in my early teens. But compared to it almost everything GUI related I encountered later was a pain. Modern day Free Software reimplementation is called Lazarus and is related to Free Pascal project.

>>22173 The language is usually less important than the GUI toolkit, since most of the mainstream languages have mature bindings to at least one of the big ones.

>>22335 It is Lazarus in the screenshot, not Delphi.

>>21622 Tk is nice. https://tkdocs.com/

>>18232 >Glade lmao Glade. Even tho half the gtk projects use glade, it doesn't mean it's supported. Such is the Gnome™ vision.

>>22174 This post aged badly. Flutter FTW!!!!

Tk now has/is Ttk which has themes and looks native.

Can anyone point me towards grokking GUIs? What i'm looking for is more of a big picture theoretical background rather than a practical guide over a specific framework. I'd like to have a mental model of what is openGL, what is the QT framework, how is the login screen on my system drawn, etc.. I have many years of experience in the industry (albeit in webdev) so feel free to recommend technically heavy materials.

> Ctrl + F No JavaFX, no SKIA, no SKIJA. But focusing on JavaFX > portability All desktop platforms > Build size With JLink, probably not terrible. Probably better than electron > Community All the JVM ecosystem > Licensing Haven't checked > Other criteria Performance. You get the JVM for good or ill. If you know how to work it, you can get good performance. You also get its concurrency which isn't bad. > Languages Java, Kotlin, Scala, JRuby, Clojure, Jython > Tooling While JavaFX doesn't have good tooling on its own, the JVM has great monitoring and visibility tools.

>>27246 >> Languages >Java, Kotlin, Scala, JRuby, Clojure, Jython You forgot ABCL. McClim might be feasible too.

Everytime the issue of GUI programming comes up somewhere I post this: https://libagar.org/ No one ever responds which is a shame. It's a well designed and simple GUI toolkit in C.

>yet another interesting thread turns into an inane discussion Post books relevant to GUI development. I will take matters in my own hands.

>>5196 >is there a free/open source design language? KDE Human Interface Guidelines https://develop.kde.org/hig/

>>5196 Haiku has design language language and it even follows it, unlike windows https://www.haiku-os.org/docs/HIG/index.xml https://www.haiku-os.org/development/icon-guidelines