The main target of the Godot Engine are game developers. But Godot's easy workflow and functional UI elements, makes it also a good fit for non-game applications. There are already some out there you may know, like Pixelorama, an Open Source 2D sprite editor.

  • murtaza64@programming.dev
    link
    fedilink
    arrow-up
    6
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Without much experience building UIs aside from web, my limited experience with Godot leads me to believe that building an application this way would lead to a lot of decentralization of logic, which might be a bad thing for complex applications. For example, various UI elements might have a bunch of logic attached to them instead of having a centralized place where the logic lives. I guess this happens in web too, and maybe native UI frameworks/toolkits?

    • Sethayy@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Would you not be able to decentralize/centralized as you please? Usually this already happens for high performance godot apps, with c++ (and there's autoloads if you want mor)

    • crittecol@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Like others have said, it's pretty much the same as web development. The logic can live anywhere, so you could build your own app with whatever architecture you want and even use best practices from other fields as inspiration (Like the Redux comment.)

      What we're missing is mostly more people actually doing it, having opinions on how best to organize app-like builds. I've built some small apps using it but nothing complicated enough to answer these questions.

      But there are some examples that are open source to look at.

      https://github.com/LyffLyff/Veles

      https://github.com/Mad-Cookies-Studio/mad-productivity

      https://github.com/RodZill4/material-maker

    • I Cast Fist@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      1 year ago

      I think that'll depend on the application. For a painting program like Pixelorama, the logic being attached to the UI element, like the brush button dealing with the brush specific logic, it makes sense, it should be intuitive to look for how it works on a "brush.gd" file.

      With Godot, the logic tends to reside within scenes and, without taking a look at Pixelorama, I would wager that most of the logic is already centralized, as I suspect the scene containing all the canvas-interacting buttons (fill, color pick, brush, select, etc) are all coupled in the same scene. Most of the time, you'll have 1 script per scene, so all the logic of that scene is "centralized"

      From my very hazy recollection, that decentralization was a problem with Delphi/Lazarus (Pascal), each UI component had a separate file to handle its logic. Might be remembering it wrong.

    • nnullzz@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I guess it’s more likely to have “decentralized” code using Godot to build an app because of how it’s used in game dev. But that’s seen a lot in web dev too. You might have a react component handle state and children components with their own logic. Sometimes those components are “pure” and only deal with data given to it, sometimes they’re “stateful” and you end up needing to pass data up to the parent.

      With proper planning, one could probably avoid mixing up what parts of the app should be pure/stateful.

      • worldsayshi@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        Is there a good way to make a redux-like central state container in Godot?

        (I'm sure there are many ways to do it but wondering if there is someone who has found a good practice for it.)

        • crittecol@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          You could pretty easily do this as an autoload so it's accessible from anywhere. You could store the actual state as a dictionary or a resource, or even a whole db if you wanted depending on what you're storing.

          It's a little old but looks like someone even implemented a redux inspired store! https://github.com/glumpyfish/godot_redux

          No idea if that still works, but probably would be too hard to use it as inspiration or even update it to the latest 3.x version