Godot Engine to get improved Linux support in the upcoming Godot 4 release

It's already pretty good, godot is fantastic. I hope that they don't change the structure as 3.0 changed from 2.0, a lot of good 2.0 tutorial don't work.

In the category "Headlines you won't see about Unreal Engine".

Multi-windows could be seriously useful in a multi-monitor setup.

I know I'm in the minority here, but the current layout can be very cramped on a 5:4 display. Being able to offload some less-used windows to a second screen will be a huge help.

Hm, why are they working directly with X instead of using something like SDL?

This is the kind of things that made me switch from Unity to Godot. They *do* care about Linux, and it shows . Also, being able to pop out windows from the main editor looks neat!

It's already pretty good, godot is fantastic. I hope that they don't change the structure as 3.0 changed from 2.0, a lot of good 2.0 tutorial don't work.

Sadly, there's quite a bit of that already planned :/ Pointless renames like Node -> Node3D will break most existing scripts/tooling. They promised some sort of limited support to automate the conversion, but YMMV. These renames *may* make things clearer, but the cost of an API break just for this is too high IMO.

This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?


Last edited by setzer22 on 20 October 2020 at 4:04 pm UTC

This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?

Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.

I don't know the complexities involved, but it seems to me that GIMP handled multiple windows for the last 25 years or so?

This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?

Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.

I think the pros and cons depend to some extent on the life cycle of the software. When software is young, many major features have yet to arrive, and use is growing but there isn't a huge installed base, you don't want to sweat backwards compatibility. You'd hamper your ability to add those important features, and all you'd gain is a bit of convenience for early adopters who can handle a bit of fiddling and are also waiting impatiently for those features.
When software is mature and already dominates the industry, or maybe doesn't but has a fairly static, loyal user base, then you want to think seriously about whether a bit more ease adding new bling which probably doesn't represent any kind of core feature ('cause you did those already) is worth pissing off all the users who are doing production work with your stuff.

Godot is still towards the early end of that, so it would be foolish of them to stress backwards compatibility.


Last edited by Purple Library Guy on 21 October 2020 at 9:07 am UTC

I don't know the complexities involved, but it seems to me that GIMP handled multiple windows for the last 25 years or so?

There is a certain irony in the fact that a single-window mode was celebrated as a great advance for the GIMP, and now a multi-window mode is being presented as an advance for Godot.

In fairness, I didn't mind the old GIMP interface, but find myself using single-window mode all the time now, and as I said, multiple windows will definitely come in useful in Godot.

This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?

Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.

I'm sorry if my comment came off as harsh criticism on Godot. I still love the engine and think they're doing a great job (heck, I use it myself almost daily!)

I'm all in for useful API changes and removing cruft from older versions. But you should always aim for backwards compatibility whithin reason. Minor API changes is also what caused the great divide between Python 2 and 3, and we're paying the price for some of those decisions still today. When you have thousands of users, you should consider every API break carefully.

I was mentioning the Node->Node3D switch not because it's difficult to upgrade (I, too, know how to do global search and replace ), but because it is an API breaking change that has very little point. But even for such an easy change, my point stands: There's hundreds of tutorials out there that will become outdated. How many of them will be fixed by their original developers? Because otherwise, they're as good as gone.

Take this amazing Godot plugin for example: https://github.com/Stoeoeoe/godot_data_editor It's unfortunately built for Godot 2. After half an hour attempting to port it to 3.X, I decided to stop and just roll my own thing, which I'll probably never release to the public. A great piece of software was lost just because someone decided their API was not "clean enough", that's what happened.

This may be quite a bit off-topic for this forum, but the kind of philosophy shown in this talk is precisely what I'm talking about: https://www.youtube.com/watch?v=oyLBGkS5ICk And let me tell you this guy is no charlatan, he's the main designer of a programming language used by thousands of developers, and he managed to do so for 10+ years while never breaking an API :)

There's hundreds of tutorials out there that will become outdated. How many of them will be fixed by their original developers? Because otherwise, they're as good as gone.

Then let them be gone.

A clean API that is easier to learn and understand is worth more than having old tutorials or plugins that haven't been updated in three years still be valid.
Every programmer worth their salt knows that they have to take old, unofficial (!!) tutorials with a grain of salt.
Everyone who writes tutorials knows this, too.
This is software development. Things can change rapidly, and so do APIs.

It isn't possible to create middleware API (which Godot is) and never change it for its entire lifetime if you also strive to improve it. That would require an amount of foreknowledge that nobody has.
At best, you can offer long-term support for older versions, which is the standard method most use, including Godot.

Also, you are mistaken about the Node->Node3D thing.
The current situation is that there is the base class, Node.
Then there is the 2D class deriving from it, Node2D.
Then there is the 3D class deriving from it, Spatial.
Wait, what - Spatial? That doesn't fit with the rest. And it has confused new users since the beginning of Godot.
Renaming it to Node3D will make it easier for everyone.
And I don't really doubt that people finding "Spatial" in some old tutorial will manage - if they aren't directly told by the editor "Hey, you typed Spatial. Did you know that Spatial is now Node3D?".

https://www.youtube.com/watch?v=oyLBGkS5ICk And let me tell you this guy is no charlatan, he's the main designer of a programming language used by thousands of developers, and he managed to do so for 10+ years while never breaking an API :)

That's nice and all, but not comparable. First of all, programming languages are way more static than middleware.
A lot more thinking goes into designing their API than what is done or even possible for most middleware.
They change very slowly, if at all. Just look at the snail-pace of changes in C++.

Also look at PHP for a language that everyone knows is in dire need of a redesign with all its myriad of different styles and paradigms all mixed together (hell, not even function names follow a singular naming pattern).
Yet it isn't changed - why? Because it would almost literally break half the internet. It can't do that redesign anymore. It's too late.

Changing Godot API would only "break" some old, unofficial tutorials and require some small effort if you are porting from 3.X to 4.X - that's it.


Last edited by TheSHEEEP on 23 October 2020 at 8:53 am UTC