22 ms·

Making Advanced GUI Applications with Godot

465 points by artemisart 6y ago

kodablah 6y ago
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 and feel I might have gone GTK3 (absent from the comparison here). Having said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.
- mod50ack 6y ago
  I think if you are going for native widgets with a more lightweight (and more liberally licensed) bent, then wx is a solid option too, though it requires a bit more manual UX work, even though it uses native widgets for real (even in some places Qt doesn't). But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
- solarkraft 6y ago
  Qt Quick, btw, seems to have learned a lot of lessons from game engines by their tech (all OpenGL) and terminology ("scene graph").
- joezydeco 6y ago
  If you take the time and care to build the Qt libraries yourself and configure out all the stuff you don’t need, you can get an order of magnitude smaller. I think Qt even supports a minimal configuration nowadays and markets it as “Qt Lite” In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
- userbinator 6y ago
  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"...
  - watermelon0 6y ago
    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. ...
    - stu2b50 6y ago
      It's unfortunate that traditional desktop GUI frameworks are such an abysmal developer experience that everything from FOSS made by 1 person in their spare time to the cornerstone of multi-billion dollar companies choose to embed a web browser into their desktop app instead. Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD. And honestly, I'll have to admit that how react models GUIs is a really attractive.
      - einpoklum 6y ago
        > Qt is the best I've seen, but it has the normal c++ FUD Not sure what you mean exactly; C++ is complex, but why the fear and doubt? Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.
        bmn__ 6y ago
- account42 6y ago
  > 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) I have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
- Shorel 6y ago
  Qt is not native enough, if you compare it with wxWidgets. Particularly in Windows.
jayd16 6y ago
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.
- deleted 6y ago
  [deleted]
coppolaemilio 6y ago
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.
- mhh__ 6y ago
  > 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!).
  - pierrec 6y ago
    If it's general purpose, then I agree that visual languages always seem to be an annoyance. If it's domain-specific, that's another story, since many domains are all about connecting blocks together. The most common use case is audio/video signal processing, where it works well if you're working above a certain level of abstraction.
    - throwaway43234 6y ago
      Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.
  - afwaller 6y ago
    Yeah redstone in Minecraft is pretty good. Very visual. Few people have made entire CPUs https://youtu.be/ydd6l3iYOZE https://youtu.be/ydd6l3iYOZE It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
  - danwills 6y ago
    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!)
EamonnMR 6y ago
It's not the world's best WYSWYG editor but it sure is a WYSWYG editor, with cross platform exports. You can even write your apps in C# if you want.
- krapp 6y ago
  And using C# gives you the added benefit of the rest of the C# ecosystem. You can use Nuget right in the VS solution file Godot generates to import whatever you like.
qw3rty01 6y ago
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, or whether it uses lazy rendering or if it constantly runs at 60fps, etc.
- tomtheelder 6y ago
  It's not a Godot advertisement. The author is just excited about exploring the possibility of using a game engine for UI development. The point of this article isn't supposed to be a full dive into the nuts and bolts of using of Godot for UI development or anything, just a speculative piece about a novel use for this piece of technology. I doubt the author even knows the answers to a lot of the questions posed. It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question. I don't think the negativity is justified.
  - detaro 6y ago
    The "excited about exploring the possibility of using a game engine for UI development" is fine, the "misrepresenting the alternatives" part, especially while ignoring all downsides of Godot, makes it look dodgy and detracts from the piece.
    - addicted 6y ago
      He’s been very clear about what he does and doesn’t know about the alternatives.
- CyberDildonics 6y ago
  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 window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it. GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "
atarian 6y ago
UIs in game engines are pretty different from the look-and-feel you get using native components or QT. Even with Electron apps, the text fields and buttons that you start with are at least native to the platform.
- tomtheelder 6y ago
  That's definitely true. OTOH it does seem that fewer and fewer applications are designed to match the native look-and-feel. A game engine would not be a good choice if that was a goal of your project, but I don't think most projects these days are too bothered about that.
pier25 6y ago
JUCE is another option one could explore for cross platform non-web UI. It's generally used to make audio apps and plugins, but these require UIs are after all. I'm fairly certain the first versions of Ableton Live were made with JUCE, I'm not so sure about the later ones. MaxMSP is also made with JUCE. https://juce.com/ https://juce.com/
- follower 6y ago
  I looked into JUCE a while back when I was keen to find a good cross-platform UI solution but was put off by the licensing aspects that seemed more complex/onerous than even Qt's. YMMV.
0xdeadbeefbabe 6y ago
> Game development faces some rather brutal conditions to survive. Which begs the question how do other areas of development get such easy conditions?
- dleslie 6y ago
  Business money.
- pjmlp 6y ago
  Game development feasts on people willing to sell their souls to live the dream, so they have an endless supply regardless of the conditions..
- danielscrubs 6y ago
  Competition. When I was in high school some 15 years ago many of my classmates wanted to make games. It was seen as fun and because it was seen as you had to be smart to do it (parents had no clue) it was in my classmates eyes the perfect combination. Fifteen years later and the competition is huge, and the demand in overtime and the stress followed. As you start to make even more “programming is fun” classes, what they don’t see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are. If I get kids, I’ll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.
gameenginz8 6y ago
I’ve often wondered why more desktop software and data analysis stuff isn’t written in something like Unreal. - optimized across platforms - optimized net code libs - modal collaboration tool: build in blueprints or code (basically web components before web components) - advanced visualization - source control integration - the frontend can be backend language agnostic, swap C++ for Rust over time - no web assembly needed - heavily polished ergonomics and UX - custom input map support is robust, tools can have their own keymap (we aren’t secretaries!) The tech world at large is really addicted to the toolkits of the wrong companies, IMO Apples “pro” dev tool in Xcode feels like a boring business tool. Once closed desktop tools are now free for development with a market for making money now. Godot is just as open as Visual Studio or Firefox, minus the DOM, JavaScript, etc. Cloud infra and micro services can still be what they are, all the usual safety features. Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.
- Thaxll 6y ago
  Because the overhead and complexity is huge and useless. Unreal is not optimized to make GUI application, it's used to make games. Engines don't have anything useful to make modern app on the desktop.
  - gameenginz8 6y ago
    The overhead and complexity of a dozen different IDEs, JS frameworks, 4 browsers, 2 mobile phone platforms, etc etc is less complex? In a day to day engineering perspective it’s all a mess of abstraction and indirection anyway? If we’re going to optimize ONE stack, I’d prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we’re hacking into a browser? IMO that is textbook functional fixedness.
    - yoz-y 6y ago
      For one applications need familiarity and uniformity. Games don't. For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over. What about IME? > If we’re going to optimize ONE stack Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.
pxf 6y ago
MaterialMaker https://github.com/RodZill4/material-maker https://github.com/RodZill4/material-maker is also made in Godot :)
lxe 6y ago
The section on "Electron, HTML5, CSS and JavaScript" is worth a read. We might have taken a few wrong turns when it comes to web technologies for applications.
skratlo 6y ago
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 the free version.” ...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross-platform Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB
- rat9988 6y ago
  Last time I tried programming with Qt I remember downloading in the order of Gigabytes too.
  - AtHeartEngineer 6y ago
    I also remember hating my computer for a while after as well
  - yakz 6y ago
    Also: "From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages." - https://www.qt.io/blog/qt-offering-changes-2020 https://www.qt.io/blog/qt-offering-changes-2020
    - skratlo 6y ago
      Yes, binary packages are convenience, you could be paying for those if you're lazy to build the open source from the source.
      - katktv 6y ago
        Which is pretty cynical if you ask me, as most open source toolkits are distributed as binaries for free, to be accessible by everyone.
gavinray 6y ago
Godot is an incredibly good piece of technology, made by fantastic people. But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article. This is what it boils down to for me: IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with. But the latter part of the article focuses on the argument against using web technologies: > My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000. There are a couple of really big problems I see however: 2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage. 3. It is not made for reusable components, like real GUI toolkits. From time to time, I hear this argument about how because web applications are run on the web, they're somehow fundamentally different from an application that might run on your phone or desktop natively in terms of appearance or UI capabilities. It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app. And modern web applications are entirely made of reusable components and the principles behind them. I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms. But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild. Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG. Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB. https://tauri.studio https://tauri.studio
- rudedogg 6y ago
  > It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app. The issue is that no one bothers to do all the OS integrations you get for free when you make a native app. Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day. I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion. I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.
Shared404 6y ago
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 something like a game engine which has no concept about damaged regions and so on. Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour). The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app) Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable. [1] https://news.ycombinator.com/item?id=23580213 https://news.ycombinator.com/item?id=23580213 [2] https://news.ycombinator.com/item?id=23584258 https://news.ycombinator.com/item?id=23584258
- m3at 6y ago
  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?#class-os-property-low-processor-usage-mode https://docs.godotengine.org/en/stable/classes/class_os.html...
  - Shared404 6y ago
    Today I learned, thanks for the link.
  - ladberg 6y ago
    Why would any engine re-render if it's not needed? It will still have benefits even on desktops.
    - runevault 6y ago
qppo 6y ago
How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), localization, and accessibility? I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.
- irq-1 6y ago
  > How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), Very well (it's a game engine) > localization, and accessibility? Poorly and not at all. Godot has a student adding PO files: https://godotengine.org/article/gsoc-2020-progress-report-1#i18n-improvements https://godotengine.org/article/gsoc-2020-progress-report-1#...
  - qppo 6y ago
    I mean game engines are pretty bad at that, that's why I asked
  - follower 6y ago
    I'm not sure that "poorly" is an entirely accurate description of Godot's localization abilities. The GSOC project you linked to is about enhancing the existing .po based feature: "In Godot, we [already] have two ways of importing translation - by using CSV or PO files." Here's a blog post about someone's experience doing a translation for a Godot game: https://sites.miis.edu/vprolow/2019/12/15/godot-game-localization/ https://sites.miis.edu/vprolow/2019/12/15/godot-game-localiz... And here's an official tutorial: https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html https://docs.godotengine.org/en/stable/tutorials/i18n/intern...
- follower 6y ago
  > How well does godot support dynamic/programmatic layout It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well. > I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.
malkia 6y ago
How would this work on 2 or 3 monitors. Asking this, since any serious content creator tool end up using windows across monitors, and there you need good docking support. Qt has some, but not all the way there, like Visual Studio has (but there are some good alternatives for Qt). The other two pain points (for DCC): - HDR support (again across monitors) - Hi-DPI support (and again across monitors) Once you start hitting issues above (among many small others), you realize how much there is to add (wacom tablet support? What next?)
- fish45 6y ago
  I'm not too up to date with Godot news, but I remember that a recent update (maybe devlog?) added good multi monitor support to the editor, and therefore the gui toolkit of the engine, since the editor uses the engine.
keyle 6y ago
I use Godot on a daily basis, full time. Don't try that at home.
- FraKtus 6y ago
  Why?
yoz-y 6y ago
In part criticizing SwiftUI: > While you get a GUI inspector panel for your GUI components you are still forced to largely write the GUI in code. Well yes. The time and experience (at least for me) has shown that designing UIs anywhere outside the code will eventually bite you. Not to mention that from the very moment a second person joins your team you can practically throw your version control system out of the window for UI files. Thanks but no thanks.
- wlesieutre 6y ago
  Interface Builder is all fun and games until you have a merge conflict in a storyboard. It's all XML files so you'd think it'd be solveable, but SwiftUI makes the code representation so much more readable. And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.
  - yoz-y 6y ago
    Exactly. For maintainable code I think this is the way forward.
- follower 6y ago
  > designing UIs anywhere outside the code will eventually bite you. With Godot it is possible to design the UI in code--the editor itself uses that approach, e.g.: https://github.com/godotengine/godot/blob/27d12092821df77a6186d2fd54055c54beefbea0/scene/gui/file_dialog.cpp#L852 https://github.com/godotengine/godot/blob/27d12092821df77a61... > you can practically throw your version control system out of the window for UI files. While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-/blob/master/Main.tscn https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-... While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.
mark_l_watson 6y ago
Interesting Article and also conversation here. I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step. The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality. Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.
typon 6y ago
Are there examples of such advanced GUIs? (links to github)
- krapp 6y ago
  Godot's own editor is one obvious example. Also I saw this Kanban board posted on Reddit earlier: https://github.com/alfredbaudisch/Godello https://github.com/alfredbaudisch/Godello Heavypaint, mentioned elsewhere here: https://news.ycombinator.com/item?id=24046431 https://news.ycombinator.com/item?id=24046431
brunoborges 6y ago
Why is Hacker News not interested in JavaFX at all? Seriously.
- gonzo41 6y ago
  I know right! I watched a scene builder demo and was floored at how easy things were. Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out. It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.
- brnt 6y ago
  In general desktop ui is underrepresented. Then again, if you look at (most of) big tech, they're web first (or only), plus maybe a custom platform (iOS, Windows, Android). None of these companies really do cross platform desktop ui. That's the space of smaller businesses, and perhaps a smaller space in general.
- pjmlp 6y ago
  Too much Java hate over here.
jbritton 6y ago
Does anyone know if Godot can play a live video stream with graphics drawn on top?
- madshiva 6y ago
  Sure it's easy.
- follower 6y ago
  I think that's possible. From a quick search there's this: https://docs.godotengine.org/en/stable/classes/class_videoplayer.html https://docs.godotengine.org/en/stable/classes/class_videopl... (But that may not be a live stream, necessarily, I guess.) Also there's this that may be relevant: https://docs.godotengine.org/en/stable/classes/class_spatialmaterial.html#class-spatialmaterial-property-flags-use-shadow-to-opacity https://docs.godotengine.org/en/stable/classes/class_spatial... The latter is documented as: """ [...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR. """
nitwit005 6y ago
I like the concept, but you're starting your development by throwing out the native UI components, along with all the accessibility features, keyboard shortcuts, and other features that go with them. A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: https://github.com/godotengine/godot/issues/29736 https://github.com/godotengine/godot/issues/29736 There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.
makecheck 6y ago
Regarding sizes for Xcode, etc.: While I think they’re bloated downloads, they include things like dozens of OS simulators, far more than the app/IDE itself.
greggman3 6y ago
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.
- jfkebwjsbx 6y ago
  Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
  - chii 6y ago
    it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron). so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
    - jfkebwjsbx 6y ago
      Handling Unicode and input is not anything that breaks any design. Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
  - jariel 6y ago
    Surprisingly, they won't. Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well. Unicode to start is complicated. Then you have things like bidirectional text. Line breaking is complicated. There are no accepted practices for a lot of use cases. Hyperlinks. Embedded content like images. Copying/inserting html and other formats. Styling content. Rendering 100 000 lines of styled content without screwing up user input. Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables. No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways. Emojis, fat finger cursor navigation on mobile devcies, input managers. It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases. And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big. This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it. All for what? Why would you want to render text in a gaming engine in the first place ... Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
est31 6y ago
Reminds me how in 2015 I built a web server in Godot. It's very limited, uses busy polling to listen for new connections, but nothing else was available at the time (IDK about current Godot). https://github.com/KOBUGE-Games/godot-httpd/blob/master/httpd.gd https://github.com/KOBUGE-Games/godot-httpd/blob/master/http... Where there's a will, there's a way :).
pippy 6y ago
An underlying tone of this article which most people in this thread have missed, was the impact of hitting the ground running. Godot quickly gets something on the screen for someone to build on. Qt is difficult to get something running. The impact of this makes technical benefits one way or the other moot. After all, if it works, who cares what technology is better? I found the hassle of setting up Qt painful, but it didn't scare me away. The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase.
- detaro 6y ago
  > The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase. Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?
jv22222 6y ago
When I came here I was hoping to hear all about godot making minority report type futuristic GUIs... I was surprised to see it was all about a game engine making regular every day 2020 UIs!
georgewsinger 6y ago
Nice post. I look forward also to a future where Godot helps facilitate VR (office) applications as well. We have developed SimulaVR (https://github.com/SimulaVR/Simula https://github.com/SimulaVR/Simula -- a Linux VR Desktop) on top of Godot, and I think there's a lot of potential for this in Linux.
Thaxll 6y ago
That article is very flawed and also misses a critical point about UI in general, the reason why Windows feels like Windows in the last 20 years is because of UI/UX, I used Windows all my life and when I have to open a new app eventough I never used it before I can naviguate easily, everything makes sense, I click it does what it's supposed to, pop messages are all the same, menu looks the same, they all follow the same standard. It's like driving a car, you can have thousand of different models and yet you get inside one you can drive it right away. You don't have that kind of usability if everyone was doing custom GUI running with a game engine. Same reason why there is a learning curve with UI in games, every games are different so every UI are also different, it takes time to naviguate properly in a new game. Consistance is key.
FlashBlaze 6y ago
A great app made using Godot is heavypaint[1]. He explains that in his Blender everyday talk[2] [1] http://www.heavypoly.com/heavypaint http://www.heavypoly.com/heavypaint [2] https://youtu.be/3jZLTZnIiKU?t=2318 https://youtu.be/3jZLTZnIiKU?t=2318
- wraptile 6y ago
  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 https://www.youtube.com/watch?v=JCY4dfVNq9Q
privateSFacct 6y ago
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.
- numlock86 6y ago
  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.
  - privateSFacct 6y ago
    Is WPF/XAML the right way now to do quick get going windows app development?
    - tonyedgecombe 6y ago
      It wasn't for me, it felt like wading through treacle. However if you want to unit test your UI then it makes more sense.
    - ChicagoDave 6y ago
      Still think WPF/XAML was the best layout engine and I'd cry if it replaced CSS.
    - pjmlp 6y ago
      Yes, although the future is WinUI. https://microsoft.github.io/microsoft-ui-xaml/about.html https://microsoft.github.io/microsoft-ui-xaml/about.html
  - pjmlp 6y ago
TheMagicHorsey 6y ago
I feel strongly that OP should check out Google's Flutter project. It has many of the benefits he sees in Godot, with a more general focus rather than the singular focus on games. Flutter is very "game-like" in the way it does its UI. It does not use the native graphics elements. Everything is a component that is rendered by Flutter's own rendering engine ... AND even the inputs (like touch) are handled directly in Flutter.
nslindtner 6y ago
I'm trying doing this with Unity. My main issue is the amount of learning necessary for doing "simple" stuff - I think onboarding of new people will be a challenge. But I guess time will tell :-) That said i do enjoy the experience - and some of the "game" features do give an amazing opportunity to make a nice interface. I you go this route, do prepare yourself to spend your hours very different - making an animation takes no time - making a simple tab sequence takes time :-)
cycomanic 6y ago
Not familiar with godot, but the GUI reminds me a lot of the blender GUI. I always wondered if the devs would ever spin out that GUI so that it became a library, because it always felt blazingly fast compared to e.g. Qt or GTK
- patatapatato 6y ago
  there's this project https://github.com/julianeisel/bWidgets https://github.com/julianeisel/bWidgets
juskrey 6y ago
Several years ago using Unity3d to make an advanced cross platform (half business half industrial) GUI was an excellent experience and result. So yes, I readily believe modern game engines are good for cross platform GUIs and may conquer a niche here.
ngcc_hk 6y ago
Need a hello world, then something extra like a form, a solitaire etc to see how the rabbit goes.
emmanueloga_ 6y ago
Yeah no kidding, choosing a GUI framework is pretty difficult task... all of them suck for a different reason :-). I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice [1]. The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app [2] is built using Kivy [3], which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP. 1: https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx 2: http://www.yeco.io/ http://www.yeco.io/ 3: https://kivy.org/#gallery https://kivy.org/#gallery
fit2rule 6y ago
I am a big fan of the MOAI toolkit, which is similar to Godot in some ways - inasmuch as its a game engine toolkit with a Lua front-end - and with which I have created a number of 'non-game' GUI apps. It was easily one of the nicest projects I've ever done - no web stuff to deal with, only MOAI for the core layer, with Hanappe doing the regular work of providing the GUI controls and abstractions I need - scroller views, buttons, sliders, etc. And since that experience, I really yearn for a similar kind of framework on the better-supported engines out there (MOAI has gotten a bit long in the tooth in the last few years). Its really quite a neat feeling to ship an app that uses highly optimised game code for its lower interface abstractions, with a mid-layer framework on top of it - which then can be packaged and run on any platform: iOS, Android, Windows, Linux, MacOS - and looks the same, functions the same, on every platform. It does take some courage however. You do have to make a great UI experience for the end user - if its half-assed or buggy, the whole thing falls down. But, when it works, it works very well and blows away the whole Web framework. I really don't like doing apps any other way these days ..
madshiva 6y ago
I was playing with Godot to make application my whole Sunday and then a medium article on HN. This make my day. I really think too that is really fun, nice to use but I'm facing the same problem with other editor. The applications is quite easy to create but when I want to "share data" between computer, like for exemple making a simple database, It's too complicated. I mean there's no simple task and I don't want that the applications is storing data on the cloud. I could use sqlite, but then I face other problem too. Anyone could suggest me a better approch regarding this problem?
FraKtus 6y ago
Godot has only OpenGL renderers. Do they plan to add DirectX and Metal?
- follower 6y ago
  For Godot 4.0 the rendering system is being re-worked to use Vulkan.
miki123211 6y ago
If you want to use this in a business, either for an internal tool or for an application you sell, this is a horrible idea. Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform. This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).
- dvfjsdhgfv 6y ago
  Well, if what you are saying were 100% true, the entire VST market would be non-existent. (I agree with you to some extent, but let's not exaggerate to make a point.)
- gridlockd 6y ago
  Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard? Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
  - BossingAround 6y ago
    > Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard? Not sure what are you saying here. Are you saying that while it might become a law, companies that can't find the money to comply don't need to comply in such cases..? Or that it hasn't happened yet, so it's not bound to happen?
ogig 6y ago
The author has a point that game engines may be suitable for some applications. In arquitecture I've used Twinmotion, based on unreal and Lumion, not sure about the engine on that one, probably unreal too. It may be obvious in this field, where game like visualization is directly usable, but I can see other areas where It may work. Anything regarding 3d objects will find in a game engine state of the art, real time, visualization tools.
pkphilip 6y ago
I think Lazarus is a much better environment for creating desktop apps which are small, cross-platform and very fast. The component architecture is much more advanced than Godot and you have access to a huge number of components. Extending these components or creating new components is also very easy.
- hoistbypetard 6y ago
  Don't you have to use Pascal for that, though? I'm sure the tooling is better by now, but I remember being pretty happy not to need to touch Pascal anymore by the late '90s. The APIs that expected Pascal conventions were often pretty miserable to use.
  - pkphilip 6y ago
    Yes, you do need to use Object / Free Pascal but it is actually quite a nice language and you can interface with C libraries quite easily
    - hoistbypetard 6y ago
      That's good. Converting between pascal and C calling conventions is one part of the 1980/1990s that I have absolutely zero desire to revisit. I do recall that some of the Object Pascal class hierarchies that got developed were quite nice, and I am glad to hear there's more development continuing that direction.
imtringued 6y ago
I personally got so used to the look of Gnome3 + GTK that I want all my applications to either use GTK or at least try to attempt to use a similar theme. The most important factor, as petty as it may sound, is the size of the control elements. If there is a generic dark theme it's usually okay but if the standard controls look off it usually doesn't appeal to me.
cercatrova 6y ago
If you're going to do something like this, just use Flutter. It's the same principle, draw pixels to a screen, but it has a lot of advantages over Godot for application development, such as accessibility and only rerendering components when they change.
rcarmo 6y ago
I have been playing around with Godot (to help my kids) and, to be honest, I had largely the same idea. For personal apps that have simple GUIs and have no formal spec, it might be just the ticket. (I've been thinking of building an app to do photo triage, and Godot can certainly load up a bucketload of image assets and render them...)
nnq 6y ago
Anyone interesting in using this to create a code-editor / IDE? I'm dying to try my hands at a next gen IDE created using a game engine :D
- electronstudio 6y ago
  Yes, Godot are doing that. The Godot IDE is created with the Godot engine.
- Alex----- 6y ago
  Check out Glass Editor https://glasseditor.com/ https://glasseditor.com/ it's made using an unreleased game engine.
  - nnq 6y ago
    ...god, my eyes, they hurt, that design, they're bleeding now ...you almost made me change my mind of whether this would be a good idea :) (Hint: I'm interested in mostly using this for creating a graphically rich but minimalistic distraction-free ADHD-friendly experience ...that could also be usable in VR for even more distraction free coding - I mean since most pro devs touch type anyway, using a keyboard in VR would just work for us, without any extra stuff.)
mrpickels 6y ago
flutter is the best. period.
follower 6y ago
This is an area I've been actively exploring and think has real potential. For context, my interest is in: * Cross-platform support. * Ease of distribution. * Ease of construction. * Platform stability. * "Licensing"/business issues. * Accessibility. In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D ) # Platform Native UI If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native and cross-platform then per-platform clients w/shared backend implementation is pretty much required. But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack. I think the key around this is once you've chosen to not be platform native don't pretend to be platform native. Lean into making the UI tailored for your application. And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation. If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you. # Ease of Distribution Trying to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't. With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used. This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases. # Ease of Construction In relation to games, the highest praise I have for Godot is: * Since I downloaded Godot I've actually made and released games. I've found the integrated nature of the IDE really supports iterative development. Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people. # Why not use web technologies? If your project makes sense as a web site then, make it a web site. If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron. But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.) Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS. # Why not Qt? Ah, Qt, I really want to like you. If Qt works for you, then use it. But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2. If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle. # Is Godot ready for applications now? Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :) Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.) Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved. Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future. # A Note on Accessibility As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story. There is at least at least one project that I know of that is working on improving that: https://github.com/lightsoutgames/godot-accessibility/ https://github.com/lightsoutgames/godot-accessibility/ In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might. But if you need your app to be accessible today then Godot probably won't meet your needs. # Bonus: Are InfoSec tools a potential niche for Godot-based apps? I think that's a strong...maybe. :) To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years. Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps: * Many people who are technically skilled but consider themselves "non-developers". * Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI. * Has an affinity for flashy visuals. :) * Need tools that don't only run in the cloud. (In InfoSec and want to make this happen? I'm available for hire. ;) )

465 points by artemisart 6y ago

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 and feel I might have gone GTK3 (absent from the comparison here). Having said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.

mod50ack 6y ago
I think if you are going for native widgets with a more lightweight (and more liberally licensed) bent, then wx is a solid option too, though it requires a bit more manual UX work, even though it uses native widgets for real (even in some places Qt doesn't). But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
solarkraft 6y ago
Qt Quick, btw, seems to have learned a lot of lessons from game engines by their tech (all OpenGL) and terminology ("scene graph").
joezydeco 6y ago
If you take the time and care to build the Qt libraries yourself and configure out all the stuff you don’t need, you can get an order of magnitude smaller. I think Qt even supports a minimal configuration nowadays and markets it as “Qt Lite” In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
userbinator 6y ago
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"...
- watermelon0 6y ago
  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. ...
  - stu2b50 6y ago
    It's unfortunate that traditional desktop GUI frameworks are such an abysmal developer experience that everything from FOSS made by 1 person in their spare time to the cornerstone of multi-billion dollar companies choose to embed a web browser into their desktop app instead. Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD. And honestly, I'll have to admit that how react models GUIs is a really attractive.
    - einpoklum 6y ago
      > Qt is the best I've seen, but it has the normal c++ FUD Not sure what you mean exactly; C++ is complex, but why the fear and doubt? Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.
      - bmn__ 6y ago
account42 6y ago
> 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) I have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
Shorel 6y ago
Qt is not native enough, if you compare it with wxWidgets. Particularly in Windows.

jayd16 6y ago

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.

deleted 6y ago
[deleted]

coppolaemilio 6y ago

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.

mhh__ 6y ago
> 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!).
- pierrec 6y ago
  If it's general purpose, then I agree that visual languages always seem to be an annoyance. If it's domain-specific, that's another story, since many domains are all about connecting blocks together. The most common use case is audio/video signal processing, where it works well if you're working above a certain level of abstraction.
  - throwaway43234 6y ago
    Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.
- afwaller 6y ago
  Yeah redstone in Minecraft is pretty good. Very visual. Few people have made entire CPUs https://youtu.be/ydd6l3iYOZE https://youtu.be/ydd6l3iYOZE It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
- danwills 6y ago
  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!)

EamonnMR 6y ago

It's not the world's best WYSWYG editor but it sure is a WYSWYG editor, with cross platform exports. You can even write your apps in C# if you want.

krapp 6y ago
And using C# gives you the added benefit of the rest of the C# ecosystem. You can use Nuget right in the VS solution file Godot generates to import whatever you like.

qw3rty01 6y ago

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, or whether it uses lazy rendering or if it constantly runs at 60fps, etc.

tomtheelder 6y ago
It's not a Godot advertisement. The author is just excited about exploring the possibility of using a game engine for UI development. The point of this article isn't supposed to be a full dive into the nuts and bolts of using of Godot for UI development or anything, just a speculative piece about a novel use for this piece of technology. I doubt the author even knows the answers to a lot of the questions posed. It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question. I don't think the negativity is justified.
- detaro 6y ago
  The "excited about exploring the possibility of using a game engine for UI development" is fine, the "misrepresenting the alternatives" part, especially while ignoring all downsides of Godot, makes it look dodgy and detracts from the piece.
  - addicted 6y ago
    He’s been very clear about what he does and doesn’t know about the alternatives.
CyberDildonics 6y ago
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 window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it. GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "

atarian 6y ago

UIs in game engines are pretty different from the look-and-feel you get using native components or QT. Even with Electron apps, the text fields and buttons that you start with are at least native to the platform.

tomtheelder 6y ago
That's definitely true. OTOH it does seem that fewer and fewer applications are designed to match the native look-and-feel. A game engine would not be a good choice if that was a goal of your project, but I don't think most projects these days are too bothered about that.

pier25 6y ago

JUCE is another option one could explore for cross platform non-web UI. It's generally used to make audio apps and plugins, but these require UIs are after all. I'm fairly certain the first versions of Ableton Live were made with JUCE, I'm not so sure about the later ones. MaxMSP is also made with JUCE. https://juce.com/ https://juce.com/

follower 6y ago
I looked into JUCE a while back when I was keen to find a good cross-platform UI solution but was put off by the licensing aspects that seemed more complex/onerous than even Qt's. YMMV.

0xdeadbeefbabe 6y ago

> Game development faces some rather brutal conditions to survive. Which begs the question how do other areas of development get such easy conditions?

dleslie 6y ago
Business money.
pjmlp 6y ago
Game development feasts on people willing to sell their souls to live the dream, so they have an endless supply regardless of the conditions..
danielscrubs 6y ago
Competition. When I was in high school some 15 years ago many of my classmates wanted to make games. It was seen as fun and because it was seen as you had to be smart to do it (parents had no clue) it was in my classmates eyes the perfect combination. Fifteen years later and the competition is huge, and the demand in overtime and the stress followed. As you start to make even more “programming is fun” classes, what they don’t see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are. If I get kids, I’ll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.

gameenginz8 6y ago

I’ve often wondered why more desktop software and data analysis stuff isn’t written in something like Unreal. - optimized across platforms - optimized net code libs - modal collaboration tool: build in blueprints or code (basically web components before web components) - advanced visualization - source control integration - the frontend can be backend language agnostic, swap C++ for Rust over time - no web assembly needed - heavily polished ergonomics and UX - custom input map support is robust, tools can have their own keymap (we aren’t secretaries!) The tech world at large is really addicted to the toolkits of the wrong companies, IMO Apples “pro” dev tool in Xcode feels like a boring business tool. Once closed desktop tools are now free for development with a market for making money now. Godot is just as open as Visual Studio or Firefox, minus the DOM, JavaScript, etc. Cloud infra and micro services can still be what they are, all the usual safety features. Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.

Thaxll 6y ago
Because the overhead and complexity is huge and useless. Unreal is not optimized to make GUI application, it's used to make games. Engines don't have anything useful to make modern app on the desktop.
- gameenginz8 6y ago
  The overhead and complexity of a dozen different IDEs, JS frameworks, 4 browsers, 2 mobile phone platforms, etc etc is less complex? In a day to day engineering perspective it’s all a mess of abstraction and indirection anyway? If we’re going to optimize ONE stack, I’d prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we’re hacking into a browser? IMO that is textbook functional fixedness.
  - yoz-y 6y ago
    For one applications need familiarity and uniformity. Games don't. For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over. What about IME? > If we’re going to optimize ONE stack Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.

pxf 6y ago

MaterialMaker https://github.com/RodZill4/material-maker https://github.com/RodZill4/material-maker is also made in Godot :)

lxe 6y ago

The section on "Electron, HTML5, CSS and JavaScript" is worth a read. We might have taken a few wrong turns when it comes to web technologies for applications.

skratlo 6y ago

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 the free version.” ...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross-platform Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB

rat9988 6y ago
Last time I tried programming with Qt I remember downloading in the order of Gigabytes too.
- AtHeartEngineer 6y ago
  I also remember hating my computer for a while after as well
- yakz 6y ago
  Also: "From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages." - https://www.qt.io/blog/qt-offering-changes-2020 https://www.qt.io/blog/qt-offering-changes-2020
  - skratlo 6y ago
    Yes, binary packages are convenience, you could be paying for those if you're lazy to build the open source from the source.
    - katktv 6y ago
      Which is pretty cynical if you ask me, as most open source toolkits are distributed as binaries for free, to be accessible by everyone.

gavinray 6y ago

Godot is an incredibly good piece of technology, made by fantastic people. But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article. This is what it boils down to for me: IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with. But the latter part of the article focuses on the argument against using web technologies: > My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000. There are a couple of really big problems I see however: 2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage. 3. It is not made for reusable components, like real GUI toolkits. From time to time, I hear this argument about how because web applications are run on the web, they're somehow fundamentally different from an application that might run on your phone or desktop natively in terms of appearance or UI capabilities. It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app. And modern web applications are entirely made of reusable components and the principles behind them. I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms. But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild. Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG. Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB. https://tauri.studio https://tauri.studio

rudedogg 6y ago
> It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app. The issue is that no one bothers to do all the OS integrations you get for free when you make a native app. Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day. I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion. I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.

Shared404 6y ago

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 something like a game engine which has no concept about damaged regions and so on. Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour). The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app) Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable. [1] https://news.ycombinator.com/item?id=23580213 https://news.ycombinator.com/item?id=23580213 [2] https://news.ycombinator.com/item?id=23584258 https://news.ycombinator.com/item?id=23584258

m3at 6y ago
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?#class-os-property-low-processor-usage-mode https://docs.godotengine.org/en/stable/classes/class_os.html...
- Shared404 6y ago
  Today I learned, thanks for the link.
- ladberg 6y ago
  Why would any engine re-render if it's not needed? It will still have benefits even on desktops.
  - runevault 6y ago

qppo 6y ago

How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), localization, and accessibility? I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.

irq-1 6y ago
> How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), Very well (it's a game engine) > localization, and accessibility? Poorly and not at all. Godot has a student adding PO files: https://godotengine.org/article/gsoc-2020-progress-report-1#i18n-improvements https://godotengine.org/article/gsoc-2020-progress-report-1#...
- qppo 6y ago
  I mean game engines are pretty bad at that, that's why I asked
- follower 6y ago
  I'm not sure that "poorly" is an entirely accurate description of Godot's localization abilities. The GSOC project you linked to is about enhancing the existing .po based feature: "In Godot, we [already] have two ways of importing translation - by using CSV or PO files." Here's a blog post about someone's experience doing a translation for a Godot game: https://sites.miis.edu/vprolow/2019/12/15/godot-game-localization/ https://sites.miis.edu/vprolow/2019/12/15/godot-game-localiz... And here's an official tutorial: https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html https://docs.godotengine.org/en/stable/tutorials/i18n/intern...
follower 6y ago
> How well does godot support dynamic/programmatic layout It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well. > I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.

malkia 6y ago

How would this work on 2 or 3 monitors. Asking this, since any serious content creator tool end up using windows across monitors, and there you need good docking support. Qt has some, but not all the way there, like Visual Studio has (but there are some good alternatives for Qt). The other two pain points (for DCC): - HDR support (again across monitors) - Hi-DPI support (and again across monitors) Once you start hitting issues above (among many small others), you realize how much there is to add (wacom tablet support? What next?)

fish45 6y ago
I'm not too up to date with Godot news, but I remember that a recent update (maybe devlog?) added good multi monitor support to the editor, and therefore the gui toolkit of the engine, since the editor uses the engine.

keyle 6y ago

I use Godot on a daily basis, full time. Don't try that at home.

FraKtus 6y ago
Why?

yoz-y 6y ago

In part criticizing SwiftUI: > While you get a GUI inspector panel for your GUI components you are still forced to largely write the GUI in code. Well yes. The time and experience (at least for me) has shown that designing UIs anywhere outside the code will eventually bite you. Not to mention that from the very moment a second person joins your team you can practically throw your version control system out of the window for UI files. Thanks but no thanks.

wlesieutre 6y ago
Interface Builder is all fun and games until you have a merge conflict in a storyboard. It's all XML files so you'd think it'd be solveable, but SwiftUI makes the code representation so much more readable. And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.
- yoz-y 6y ago
  Exactly. For maintainable code I think this is the way forward.
follower 6y ago
> designing UIs anywhere outside the code will eventually bite you. With Godot it is possible to design the UI in code--the editor itself uses that approach, e.g.: https://github.com/godotengine/godot/blob/27d12092821df77a6186d2fd54055c54beefbea0/scene/gui/file_dialog.cpp#L852 https://github.com/godotengine/godot/blob/27d12092821df77a61... > you can practically throw your version control system out of the window for UI files. While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-/blob/master/Main.tscn https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-... While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.

mark_l_watson 6y ago

Interesting Article and also conversation here. I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step. The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality. Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.

typon 6y ago

Are there examples of such advanced GUIs? (links to github)

krapp 6y ago
Godot's own editor is one obvious example. Also I saw this Kanban board posted on Reddit earlier: https://github.com/alfredbaudisch/Godello https://github.com/alfredbaudisch/Godello Heavypaint, mentioned elsewhere here: https://news.ycombinator.com/item?id=24046431 https://news.ycombinator.com/item?id=24046431

brunoborges 6y ago

Why is Hacker News not interested in JavaFX at all? Seriously.

gonzo41 6y ago
I know right! I watched a scene builder demo and was floored at how easy things were. Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out. It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.
brnt 6y ago
In general desktop ui is underrepresented. Then again, if you look at (most of) big tech, they're web first (or only), plus maybe a custom platform (iOS, Windows, Android). None of these companies really do cross platform desktop ui. That's the space of smaller businesses, and perhaps a smaller space in general.
pjmlp 6y ago
Too much Java hate over here.

jbritton 6y ago

Does anyone know if Godot can play a live video stream with graphics drawn on top?

madshiva 6y ago
Sure it's easy.
follower 6y ago
I think that's possible. From a quick search there's this: https://docs.godotengine.org/en/stable/classes/class_videoplayer.html https://docs.godotengine.org/en/stable/classes/class_videopl... (But that may not be a live stream, necessarily, I guess.) Also there's this that may be relevant: https://docs.godotengine.org/en/stable/classes/class_spatialmaterial.html#class-spatialmaterial-property-flags-use-shadow-to-opacity https://docs.godotengine.org/en/stable/classes/class_spatial... The latter is documented as: """ [...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR. """

nitwit005 6y ago

I like the concept, but you're starting your development by throwing out the native UI components, along with all the accessibility features, keyboard shortcuts, and other features that go with them. A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: https://github.com/godotengine/godot/issues/29736 https://github.com/godotengine/godot/issues/29736 There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.

makecheck 6y ago

Regarding sizes for Xcode, etc.: While I think they’re bloated downloads, they include things like dozens of OS simulators, far more than the app/IDE itself.

greggman3 6y ago

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.

jfkebwjsbx 6y ago
Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
- chii 6y ago
  it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron). so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
  - jfkebwjsbx 6y ago
    Handling Unicode and input is not anything that breaks any design. Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
- jariel 6y ago
  Surprisingly, they won't. Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well. Unicode to start is complicated. Then you have things like bidirectional text. Line breaking is complicated. There are no accepted practices for a lot of use cases. Hyperlinks. Embedded content like images. Copying/inserting html and other formats. Styling content. Rendering 100 000 lines of styled content without screwing up user input. Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables. No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways. Emojis, fat finger cursor navigation on mobile devcies, input managers. It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases. And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big. This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it. All for what? Why would you want to render text in a gaming engine in the first place ... Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.

est31 6y ago

Reminds me how in 2015 I built a web server in Godot. It's very limited, uses busy polling to listen for new connections, but nothing else was available at the time (IDK about current Godot). https://github.com/KOBUGE-Games/godot-httpd/blob/master/httpd.gd https://github.com/KOBUGE-Games/godot-httpd/blob/master/http... Where there's a will, there's a way :).

pippy 6y ago

An underlying tone of this article which most people in this thread have missed, was the impact of hitting the ground running. Godot quickly gets something on the screen for someone to build on. Qt is difficult to get something running. The impact of this makes technical benefits one way or the other moot. After all, if it works, who cares what technology is better? I found the hassle of setting up Qt painful, but it didn't scare me away. The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase.

detaro 6y ago
> The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase. Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?

jv22222 6y ago

When I came here I was hoping to hear all about godot making minority report type futuristic GUIs... I was surprised to see it was all about a game engine making regular every day 2020 UIs!

georgewsinger 6y ago

Nice post. I look forward also to a future where Godot helps facilitate VR (office) applications as well. We have developed SimulaVR (https://github.com/SimulaVR/Simula https://github.com/SimulaVR/Simula -- a Linux VR Desktop) on top of Godot, and I think there's a lot of potential for this in Linux.

Thaxll 6y ago

That article is very flawed and also misses a critical point about UI in general, the reason why Windows feels like Windows in the last 20 years is because of UI/UX, I used Windows all my life and when I have to open a new app eventough I never used it before I can naviguate easily, everything makes sense, I click it does what it's supposed to, pop messages are all the same, menu looks the same, they all follow the same standard. It's like driving a car, you can have thousand of different models and yet you get inside one you can drive it right away. You don't have that kind of usability if everyone was doing custom GUI running with a game engine. Same reason why there is a learning curve with UI in games, every games are different so every UI are also different, it takes time to naviguate properly in a new game. Consistance is key.

FlashBlaze 6y ago

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

wraptile 6y ago
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 https://www.youtube.com/watch?v=JCY4dfVNq9Q

privateSFacct 6y ago

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.

numlock86 6y ago
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.
- privateSFacct 6y ago
  Is WPF/XAML the right way now to do quick get going windows app development?
  - tonyedgecombe 6y ago
    It wasn't for me, it felt like wading through treacle. However if you want to unit test your UI then it makes more sense.
  - ChicagoDave 6y ago
    Still think WPF/XAML was the best layout engine and I'd cry if it replaced CSS.
  - pjmlp 6y ago
    Yes, although the future is WinUI. https://microsoft.github.io/microsoft-ui-xaml/about.html https://microsoft.github.io/microsoft-ui-xaml/about.html
- pjmlp 6y ago

TheMagicHorsey 6y ago

I feel strongly that OP should check out Google's Flutter project. It has many of the benefits he sees in Godot, with a more general focus rather than the singular focus on games. Flutter is very "game-like" in the way it does its UI. It does not use the native graphics elements. Everything is a component that is rendered by Flutter's own rendering engine ... AND even the inputs (like touch) are handled directly in Flutter.

nslindtner 6y ago

I'm trying doing this with Unity. My main issue is the amount of learning necessary for doing "simple" stuff - I think onboarding of new people will be a challenge. But I guess time will tell :-) That said i do enjoy the experience - and some of the "game" features do give an amazing opportunity to make a nice interface. I you go this route, do prepare yourself to spend your hours very different - making an animation takes no time - making a simple tab sequence takes time :-)

cycomanic 6y ago

Not familiar with godot, but the GUI reminds me a lot of the blender GUI. I always wondered if the devs would ever spin out that GUI so that it became a library, because it always felt blazingly fast compared to e.g. Qt or GTK

patatapatato 6y ago
there's this project https://github.com/julianeisel/bWidgets https://github.com/julianeisel/bWidgets

juskrey 6y ago

Several years ago using Unity3d to make an advanced cross platform (half business half industrial) GUI was an excellent experience and result. So yes, I readily believe modern game engines are good for cross platform GUIs and may conquer a niche here.

ngcc_hk 6y ago

Need a hello world, then something extra like a form, a solitaire etc to see how the rabbit goes.

emmanueloga_ 6y ago

Yeah no kidding, choosing a GUI framework is pretty difficult task... all of them suck for a different reason :-). I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice [1]. The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app [2] is built using Kivy [3], which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP. 1: https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx 2: http://www.yeco.io/ http://www.yeco.io/ 3: https://kivy.org/#gallery https://kivy.org/#gallery

fit2rule 6y ago

I am a big fan of the MOAI toolkit, which is similar to Godot in some ways - inasmuch as its a game engine toolkit with a Lua front-end - and with which I have created a number of 'non-game' GUI apps. It was easily one of the nicest projects I've ever done - no web stuff to deal with, only MOAI for the core layer, with Hanappe doing the regular work of providing the GUI controls and abstractions I need - scroller views, buttons, sliders, etc. And since that experience, I really yearn for a similar kind of framework on the better-supported engines out there (MOAI has gotten a bit long in the tooth in the last few years). Its really quite a neat feeling to ship an app that uses highly optimised game code for its lower interface abstractions, with a mid-layer framework on top of it - which then can be packaged and run on any platform: iOS, Android, Windows, Linux, MacOS - and looks the same, functions the same, on every platform. It does take some courage however. You do have to make a great UI experience for the end user - if its half-assed or buggy, the whole thing falls down. But, when it works, it works very well and blows away the whole Web framework. I really don't like doing apps any other way these days ..

madshiva 6y ago

I was playing with Godot to make application my whole Sunday and then a medium article on HN. This make my day. I really think too that is really fun, nice to use but I'm facing the same problem with other editor. The applications is quite easy to create but when I want to "share data" between computer, like for exemple making a simple database, It's too complicated. I mean there's no simple task and I don't want that the applications is storing data on the cloud. I could use sqlite, but then I face other problem too. Anyone could suggest me a better approch regarding this problem?

FraKtus 6y ago

Godot has only OpenGL renderers. Do they plan to add DirectX and Metal?

follower 6y ago
For Godot 4.0 the rendering system is being re-worked to use Vulkan.

miki123211 6y ago

If you want to use this in a business, either for an internal tool or for an application you sell, this is a horrible idea. Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform. This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).

dvfjsdhgfv 6y ago
Well, if what you are saying were 100% true, the entire VST market would be non-existent. (I agree with you to some extent, but let's not exaggerate to make a point.)
gridlockd 6y ago
Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard? Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
- BossingAround 6y ago
  > Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard? Not sure what are you saying here. Are you saying that while it might become a law, companies that can't find the money to comply don't need to comply in such cases..? Or that it hasn't happened yet, so it's not bound to happen?

ogig 6y ago

The author has a point that game engines may be suitable for some applications. In arquitecture I've used Twinmotion, based on unreal and Lumion, not sure about the engine on that one, probably unreal too. It may be obvious in this field, where game like visualization is directly usable, but I can see other areas where It may work. Anything regarding 3d objects will find in a game engine state of the art, real time, visualization tools.

pkphilip 6y ago

I think Lazarus is a much better environment for creating desktop apps which are small, cross-platform and very fast. The component architecture is much more advanced than Godot and you have access to a huge number of components. Extending these components or creating new components is also very easy.

hoistbypetard 6y ago
Don't you have to use Pascal for that, though? I'm sure the tooling is better by now, but I remember being pretty happy not to need to touch Pascal anymore by the late '90s. The APIs that expected Pascal conventions were often pretty miserable to use.
- pkphilip 6y ago
  Yes, you do need to use Object / Free Pascal but it is actually quite a nice language and you can interface with C libraries quite easily
  - hoistbypetard 6y ago
    That's good. Converting between pascal and C calling conventions is one part of the 1980/1990s that I have absolutely zero desire to revisit. I do recall that some of the Object Pascal class hierarchies that got developed were quite nice, and I am glad to hear there's more development continuing that direction.

imtringued 6y ago

I personally got so used to the look of Gnome3 + GTK that I want all my applications to either use GTK or at least try to attempt to use a similar theme. The most important factor, as petty as it may sound, is the size of the control elements. If there is a generic dark theme it's usually okay but if the standard controls look off it usually doesn't appeal to me.

cercatrova 6y ago

If you're going to do something like this, just use Flutter. It's the same principle, draw pixels to a screen, but it has a lot of advantages over Godot for application development, such as accessibility and only rerendering components when they change.

rcarmo 6y ago

I have been playing around with Godot (to help my kids) and, to be honest, I had largely the same idea. For personal apps that have simple GUIs and have no formal spec, it might be just the ticket. (I've been thinking of building an app to do photo triage, and Godot can certainly load up a bucketload of image assets and render them...)

nnq 6y ago

Anyone interesting in using this to create a code-editor / IDE? I'm dying to try my hands at a next gen IDE created using a game engine :D

electronstudio 6y ago
Yes, Godot are doing that. The Godot IDE is created with the Godot engine.
Alex----- 6y ago
Check out Glass Editor https://glasseditor.com/ https://glasseditor.com/ it's made using an unreleased game engine.
- nnq 6y ago
  ...god, my eyes, they hurt, that design, they're bleeding now ...you almost made me change my mind of whether this would be a good idea :) (Hint: I'm interested in mostly using this for creating a graphically rich but minimalistic distraction-free ADHD-friendly experience ...that could also be usable in VR for even more distraction free coding - I mean since most pro devs touch type anyway, using a keyboard in VR would just work for us, without any extra stuff.)

mrpickels 6y ago

flutter is the best. period.

follower 6y ago

This is an area I've been actively exploring and think has real potential. For context, my interest is in: * Cross-platform support. * Ease of distribution. * Ease of construction. * Platform stability. * "Licensing"/business issues. * Accessibility. In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D ) # Platform Native UI If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native and cross-platform then per-platform clients w/shared backend implementation is pretty much required. But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack. I think the key around this is once you've chosen to not be platform native don't pretend to be platform native. Lean into making the UI tailored for your application. And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation. If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you. # Ease of Distribution Trying to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't. With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used. This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases. # Ease of Construction In relation to games, the highest praise I have for Godot is: * Since I downloaded Godot I've actually made and released games. I've found the integrated nature of the IDE really supports iterative development. Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people. # Why not use web technologies? If your project makes sense as a web site then, make it a web site. If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron. But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.) Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS. # Why not Qt? Ah, Qt, I really want to like you. If Qt works for you, then use it. But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2. If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle. # Is Godot ready for applications now? Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :) Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.) Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved. Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future. # A Note on Accessibility As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story. There is at least at least one project that I know of that is working on improving that: https://github.com/lightsoutgames/godot-accessibility/ https://github.com/lightsoutgames/godot-accessibility/ In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might. But if you need your app to be accessible today then Godot probably won't meet your needs. # Bonus: Are InfoSec tools a potential niche for Godot-based apps? I think that's a strong...maybe. :) To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years. Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps: * Many people who are technically skilled but consider themselves "non-developers". * Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI. * Has an affinity for flashy visuals. :) * Need tools that don't only run in the cloud. (In InfoSec and want to make this happen? I'm available for hire. ;) )