Live data from Hacker News

Making Advanced GUI Applications with Godot

medium.com

81–90 of 259 posts

Re: Making Advanced GUI Applications with Godot

#81
post #6

This just reads like a godot advertisement...it only has good things to say about godot and only bad things to say about any other library. It's really hard to take the article seriously with so much blatant bias. It also seems to leave out any technical information that a developer using the engine would want to know, like how well it integrates with existing code, what paradigms it uses compared to other UI engines…

I made this comment when someone was talking about using GLFW and IMGUI to make an application with a openGL window and I think it applies here too, because it is easy to overlook the things that you will eventually need that are not trivial to add once you go down the road of using tools made for only very basic UIs. "I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL wind…

IMGUI is still pretty impressive though. You can certainly create modal/non-modal windows, menus, custom widgets, file dialogs, fonts, drag and drop, unicode, tables without any other libraries. It's just that the approach is fundamentally different from what you see in retained-mode GUIs. (And if you need any OS-specific functionality like file dialogs, you can easily use other external libraries)

One of the few weaknesses of IMGUI is theming though. Don't expect to create one of those fancy Material-themed apps with animations, it's primarily intended for creating dry, technical tools of the likes of game engines and modelling/animation tools. It's more in the mindset of creating 'tools' rather than 'apps', and it really depends on your usecase.

Re: Making Advanced GUI Applications with Godot

#82
post #2

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"...

Re: Making Advanced GUI Applications with Godot

#84

A great app made using Godot is heavypaint[1]. He explains that in his Blender everyday talk[2] [1] http://www.heavypoly.com/heavypaint [2] https://youtu.be/3jZLTZnIiKU?t=2318

Wow, that's really cool! There has been so much new painting software on linux which makes me really regret selling off my drawing pad.

Here's a good illustration of the program in usage: https://www.youtube.com/watch?v=JCY4dfVNq9Q

Re: Making Advanced GUI Applications with Godot

#85
post #58
post #40

Earlier quoted context omitted.

As mentioned in the article Godot has a low processor usage mode: > If true, the engine optimizes for low processor usage by only refreshing the screen if needed https://docs.godotengine.org/en/stable/classes/class_os.html...

Why would any engine re-render if it's not needed? It will still have benefits even on desktops.

It's more efficient to assume that things change when designing for systems that constantly change (i.e. video-games).

Re: Making Advanced GUI Applications with Godot

#86
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 tried to do the little widget apps thing I used to be able to do trivially I end up wondering in the woods.

Re: Making Advanced GUI Applications with Godot

#87

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…

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

Re: Making Advanced GUI Applications with Godot

#88
post #20

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!).

The 'Vop' (Vex OPerator) context in SideFX Houdini is the best 'node-based' graphical programming environment that I know of - however you're always working at something like a 'shader'-level. It's strength is in automatic use of SIMD and built-in parallelism (would not be a good choice to write an app in though!)

Re: Making Advanced GUI Applications with Godot

#89

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…

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

Is WPF/XAML the right way now to do quick get going windows app development?

Re: Making Advanced GUI Applications with Godot

#90

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.

Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?

They cover that in the documentation.

What were the motivations behind creating GDScript?

In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.

The main reasons for creating a custom scripting language for Godot were:

Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).

Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.

No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).

Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.

GDScript was designed to curtail the issues above, and more.

Post reply on HN