There is so much bullshit and lies about Qt5, I won't bother finishing that piece of crap: Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB > Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find…
I tried to install qt the other day on Ubuntu, I couldn’t find the free version. I gave up and moved on to an alternative.
Why are they shooting themselves in the foot there?
My question - what happened to microsoft in this space? The get up and go speed of the super old windows forms approach was fantastic. Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still? I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc. This will age me, but for all the decades of "improvements" this tooling has, every time I've…
Visual Studio was a very nice wyswyg but they ceded the mobile space to others.
I did a lot of tutorials on my YouTube channel on how to start making GUI applications with Godot. The visual scripting is really bad for now, so I would stick with GDScript (a Python like language) or C#. It is really a great piece of software to make something quick for non-technical people. I really recommend anyone to explore and play with it a bit and I'm sure you'll find a use for this amazing engine.
> visual scripting is really bad for now Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
I think the main issue with most general purpose visual programming languages is, that they are still languages. So they are modeled in a way that resembles a text representation and can often be mapped to a sequence of symbols (a language). However, there are far less tools if you leave the explicit text representation (things like compatible editors, version control, etc.) so it comes down to being an over-the-top syntax highlighting at the expense of the before mentioned other tools. So, I think that visual programming would only become a viable alternative if it were to let go of the ideas of textual programming (language based) and become fully graph based.
My question - what happened to microsoft in this space? The get up and go speed of the super old windows forms approach was fantastic. Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still? I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc. This will age me, but for all the decades of "improvements" this tooling has, every time I've…
I'm pretty excited to see where the new .NET MAUI [1] goes. It's still in development, but it seems like it could be a great contender for fully cross-platform native UIs.
Paired with F# the proposed Elm-like model-view-update style would be the dream.
No mention of overdraw, pixel perfect rendering, layout performance, power consumption, view recycling/scrolling, or render caching (caching the composition result). Does Godot handle this stuff well? I have no idea. I wish the post did a better deep dive. I know Unity doesn't compare well to the native APIs in these regards.
I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using somethi…
It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)
This is such a bad idea. Try adding a line editor. Now try typing anything that is not ASCII or an emoji. Suddenly you'l see why you generally do not want to use a game engine for a tools. Even the Godot editor itself is not non-English friendly. It's got a horrible experience for any language that uses an IME. If you try to insert an emoji on Mac the IME won't even appear.
That said, complete and robust i18n support may take a while, given the small size of the core development team (< 30 regular contributors) and the fact that text display is probably not the highest priority for a game development tool and engine.
There is so much bullshit and lies about Qt5, I won't bother finishing that piece of crap: Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB > Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find…
I tried to install qt the other day on Ubuntu, I couldn’t find the free version. I gave up and moved on to an alternative. Why are they shooting themselves in the foot there?
I'm 100% sure that Ubunutu has qt in its repos. Just download the *-dev package and you should be good to go.
QtWidgets works really hard to try and remain native (both by reusing the platform window pointers, and mimicking style and functionality). That for me is worth it. While the article constantly complains about dev tooling size, a reasonable complaint, my DLLs I ship w/ my Qt program are just 20MB (so I'd suspect a similar size increase to a single binary were I to statically link). If I didn't care about native look…
It's odd to see the "just 20MB" phrasing. I guess even native applications have expanded to the point where 20MB seems small, but in absolute terms I still consider that quite large --- to put things into perspective, a full installation of Windows 3.11 , the OS with all of its included applications, is less than 20MB. I wonder if, in another 20 years, we may see people speaking of "just 20GB"...
I think this is in comparison with 200M+ Electron executable, which is nowadays bundled with almost every 'native' app.
Do you want to flash image to USB drive? There is Electron app (balenaEtcher) for that.
Do you want to control your mouse/keyboard? There is Electron app for that (Logitech GHub), which also includes many Qt libraries.
Do you want a terminal emulator? There is an Electron based app for that.
I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using somethi…
It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)
I actually did a POC project in Godot, it was a pretty good experience overall.
There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way.
Edit: It was in the editor, just realized I didn't explicitly mention that.