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

QuoteMulti-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!

Quoting: fagnerlnIt'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

Quoting: setzer22This 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?

Quoting: TheSHEEEP

Quoting: setzer22This 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

Quoting: PhlebiacI 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.

Quoting: TheSHEEEP

Quoting: setzer22This 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 :)