The State & Complications Of Porting The Unity Editor To Linux

[sunweb]

"The Unity developers have been porting their Unity Editor to Linux from Windows / OS X to complement their existing Unity runtime support for Linux. "
Thats a lie. The only reason they even try it is because UE4 is doing it, CryEngine is doing this and Source2 will be available as well.
Last time(right after they announce export to Linux) when i asked them about Linux editor support they said they won't do it and i have to use virtual machine if i want to work inside Linux.

"What platforms do you want to export to from Linux? "
Oh thats gold. They don't want to do much do they?

[DMJC]

The only reason they even try it is because UE4 is doing it, CryEngine is doing this and Source2 will be available as well.

Good. Market pressure pushing people towards Linux is a very good thing.

[souenzzo]

Good. Market pressure pushing people towards Linux is a very good thing.

I think it's more 'windows is bad' then 'linux is good'.

[directhex]

That sounds like the typical mess Windows-only developers would create.

Unity began life Mac-only. The worst legacy crap ion there is from Mac, then ported to Windows.

[mark45]

Don't use GTK/Qt and rewrite UnitySDK in UnityGUI looks like a good idea

Don't use Gtk - correct.
As to Qt - it's the only free, modern, good, flexible and non-moronic (that is not like Gtk) toolkit out there.

[kpedersen]

Re-implement a game engine is like... mono re-implement MS plataform?

? I think a more likely comparison would be something like Reactos re-implementing the MS platform if that's what you meant?

The Unity engine is actually quite small, much of the work is making the "Editor" friendly and fun for prosumers (i.e hobby developers who enjoy making games). So re-implementing the core parts of it was much easier than an operating system haha.

As for whether it should be Gtk or Qt, honestly the tool doesn't need either, toolkits like this are overkill when much of the GUI is done via OpenGL (and Direct X on Windows). Only things like the menu bar and dialogs really use the underlying gui toolkit.

[SpyroRyder]

GTK3 is an absolutely fine modern toolkit to write things in. The main problem here is that they are forced to use GTK2 because the CEF devs can't be fucked to port their program to use a modern toolkit. Honestly I wouldn't mine if the devs of CEF just ported it to QT5 right now because GTK2 reliance is fucking everyone over. You wouldn't ask a competent Windows dev to support XP now so why are we telling new linux devs that they must use GTK2

[ssokolow]

GTK3 is an absolutely fine modern toolkit to write things in. The main problem here is that they are forced to use GTK2 because the CEF devs can't be fucked to port their program to use a modern toolkit. Honestly I wouldn't mine if the devs of CEF just ported it to QT5 right now because GTK2 reliance is fucking everyone over. You wouldn't ask a competent Windows dev to support XP now so why are we telling new linux devs that they must use GTK2

The main reason most of my creations use GTK+ 2.x via PyGTK is because I haven't had time to get comfortable with PyQt and I despise the direction GTK+ 3.x apps are taking my Lubuntu desktop.

(Buggy "use titlebar menu" detection even in versions that trumpet that it's fixed, "pause until brain catches up" changes to the Places sidebar in Open/Save dialog, design by people who revel in ignoring decades of Human-Computer Interaction research, etc.)

I'm not sure what I'll do when I want to write a GUI for a Rust application. If I wanted to write an HTML-based UI, I'd probably use JavaScript and node-webkit and the only Linux-compatible GUI bindings I remember seeing which weren't either horrendously ugly or backed by GTK+ 3.x were the Qt/QML ones. (And, last I checked, native widget support for QML still wasn't ready for prime time.)

(I suppose I could try to ensure strict core/GUI separation for easy migration, use the incomplete GObject Introspection support in GTK+ 2.x (essentially force-loading GTK+ 2.x support via the bindings intended for GTK+ 3.x), and then migrate to Qt bindings once I trust QML to give me a suitably native experience or the Rust community solves the "Rust bindings for complex C++ code" issue.)

[liam]

I think it's more 'windows is bad' then 'linux is good'.

Where do you see him saying "linux is good" in his comment?

[oleid]

The main reason most of my creations use GTK+ 2.x via PyGTK is because I haven't had time to get comfortable with PyQt and I despise the direction GTK+ 3.x apps are taking my Lubuntu desktop.
[...]
I'm not sure what I'll do when I want to write a GUI for a Rust application. [...]

The header bar should work better on classic window managers with recent gtk+ versions (some fixes are in GTK+-3.16, vivid is still on GTK+-3.14). Nevertheless, when programming an app yourself, nobody forces you to use them. You can create GTK+3 apps, which look like GTK+2 ones.

Considering rust and GUI code separation : You could try to use Qt in rust via QML. There is a module available via cargo. It seems to work, recently I toyed around with it.

All in all, I don't think GTK+ is a bad toolkit(*). It's windows and mac ports could use some love, though. When using neither C nor C++, GTK+ has the advantage of only being a GUI toolkit. You don't need the extra stuff Qt provides in e.g. python or haskell (string handling, database access, network stuff, ...). You have your language specific libraries there.

(*): Actually, I prefere some of it's widgets and dialogs over the Qt equivalents, especially the file chooser and the Tree/List widget.