Porting Unity Editor to Linux: Things You Should Wanna Do in advance

At this year’s Unite Europe conference, we published our development plan. And although there are a lot of cool things, I personally like the editor for Linux the most. The porting history of the Linux editor is similar to the story of adding Linux support for the runtime environment in Unity 4.0. By and large, this is done for the soul, some Unity employees have periodically worked on this for some time, in many ways this project is one of the outcomes of internal hacker weeks (hackweek) among Unity developers - and I would say that things are moving quite well. Soon enough, we plan to release an experimental build, which you can all try.

Porting the editor to Linux took a lot of effort — much more than transferring the runtime. This is partly due to the fact that most of our own technologies (including complex integration with third-party developments) are embodied in the editor, partly because of the resource database, partly because of problems with case sensitivity. Our editor consists of:



')
* A large amount of code in C ++, most of which (but not all) is shared with our runtime environment, which, of course, compiles to the required platform

* A lot of C # code running on top of Mono

* Various third-party libraries and middlewares that need to be recompiled for Linux

Having dealt with this, you can return to those things that you should have done in advance:

1. Take care of case sensitivity

Unity does not work properly on case-sensitive file systems (what users who have tried to install and run the editor on a case-sensitive HFS + file system might already have encountered). This is mainly due to how exactly the Unity resource database stores the paths to them and associates them with the GUID values. Of course, we tried to take everything into account at the beginning of development, but if you don’t check in practice how the system works on case-sensitive file systems, it will never fall after one of the programmers doesn’t use anywhere with the best intentions toLower ( ) and will not spoil the whole idea.

Definitely I would like us to take care of this in advance, as it is difficult and dreary to correct such things retroactively.

2. Do not use #if WINDOWS #else OSX

A completely unexpected amount of work at the early stage of porting an editor under Windows was associated with things like

#ifdef WIN32 return _isnan(val) != 0; #elif __APPLE_CC__ return std::isnan(val) != 0; #endif 

or alternatively

 #if UNITY_WIN // Some Windows-specific codepath #else // Some Mac-specific codepath #endif 

Conclusion: if you want to write portable code, always do something reasonable (read: with the expectation of the future) in the case of #else.

3. Just don't make assumptions.

The two previous problems were very large, the following smaller ones

* Compiler assumptions. For example, let's take our bug tracking system (bug reporter), which was written largely separately from the main editor and uses some features of C ++ 11. In many places, this standard ... uh ... somewhat uncertain and different compilers implement it differently. This makes porting C ++ 11 code to the third compiler very painful. There were a lot of compilation errors in the spirit of this-C ++ template with c-heap-angle brackets not matching this C-++ template-C-heap-criminal-brackets-in-which-is-constant-where something in the middle.

* Assumptions about native applications, including those items that are automatically included in the application menu. For example, on Windows, things like “copy”, “paste” and the like are included for free, but there is no GTK and we had to add them manually. I will not lie, they don’t automatically add to OS X, but the OS X implementation fell into the #if WINDOWS #else OSX trap described above.

* Assumptions about the work of file dialogs. On other platforms, there are callback systems that allow the parent application to explain to the dialogue that some things cannot be chosen. Standard GTK widgets do not work that way.

* Assumptions in general

Conclusion: assumptions are the source of all misfortunes. :-)

Despite all of the above, the work was definitely very interesting, I would expect similar problems when porting any project comparable to Unity in terms of size and complexity.

For the sake of interest, I will describe a solution that we had to give up during the transfer. The first option used pure X11 to handle windows and events, because we did not want to attach to either GTK or QT. Because of this, the early menu system was written on the Unity GUI. It still seems to me that it would be very cool to come back to this someday. In Unity 5.1, CEF is used as the embedded browser, which is GTK dependent, so we switched to GTK to handle windows and events for all menu systems. But it was the only time that we had to redo something new.

So how's the work on the editor going? Here is what I know:

* only 64-bit Linux will be supported

* Similar to our runtime environment, in order not to go crazy, we will officially support only Ubuntu. But most likely the editor will work in other distributions.

* Most likely we will support Ubuntu versions starting from 12.04 (this is where we build our current builds)

* Dependencies on third-party libraries (like global lighting) will work

* The installer most likely (we have not done it yet) will be a .deb package

* Some of the importers of models, depending on third-party software (like 3ds Max and SketchUp) will not work. Export to FBX can be used as a workaround.

At the moment everything. Small teaser:



Our network demo of a two-dimensional shooter, exported to Linux from the editor on Linux.



Linux editor at Unity Labs. The fonts are so small because it is running on a MacBook Pro with Retina.