12 ms·

Porting the Unity Editor to Linux: Stuff I Wish We’d Done Then

94 points by mariuz 11y ago

ianlevesque 11y ago
Gtk does sound like a better choice than raw X11, particularly as Wayland, Mir, and friends continue to grow.
- JupiterMoon 11y ago
  Just curious. Why not go for QT for the whole GUI on all platforms?
  - cwyers 11y ago
    Because native GUI on Windows and OSX is better for those users and already exists?
    - JupiterMoon 11y ago
      I'm new to GUI programming and foreign to both Windows and OSX so please forgive my ignorance. In what way are the native GUIs better? Are they faster/more responsive or do they look better? Which would be more work over the e.g. 1,2 and 5 year period maintaining three guis or one? (Or is QT not quite cross platform so one ends up maintaining three inferior versions anyway?)
      - jdub 11y ago
        They behave exactly the way you'd expect, because they don't attempt to copy the expected behaviour. They define the expected behaviour.
        matt_kantor 11y ago
        Not in this case. Unity's editor has a very "unique" UI. It doesn't try to follow OS-specific conventions most of the time. https://youtu.be/DEumkKjE2YQ?t=8m15s https://youtu.be/DEumkKjE2YQ?t=8m15s
        JupiterMoon 11y ago
        Until your user has your program installed on e.g. mac and windows and now it works differently on each... This is actually an annoying problem. As a linux user lack of consistency between apps is frustrating but similarly I know people that struggle with changing from mac to windows regularly.
      - zanny 11y ago
        Qt is cross platform. The difference is that there are UI rendering (say, scaling) behaviors the native toolchains use Qt does not. It comes as close as possible within its widget layout engine it can get away with to native on every platform it supports (which when you consider thats everything from Android to Windows is a feat) but is never a perfect reproduction. Its not something that is going to be "work" for you - you just aren't going to fix it. You get a portable codebase without any of the if WIN else OSX soup, but the experience will never be perfectly native. Though nowadays I don't even know what native Windows means anymore, is it that ribbon crap, or the metro thing? Because Qt apps just use oldschool Windows Forms style menubars / buttons / etc. You can just go test it yourself, go run VLC and see how "native" it feels. Its using Qt everywhere except Android. But if you want to develop cross platform native looking software... Qt is absolutely it. Only option. And it gets better each release. Otherwise you are going the route of the Unity guys, rewriting your program for every single system.
        nzp 11y ago
        > But if you want to develop cross platform native looking software... Qt is absolutely it. Only option. If you want to develop cross platform native looking software, Qt most certainly is not the only option, wxWidgets is. In fact, as you yourself pointed out, Qt isn't really native, just tries to fake the native look and feel. wxWidgets actually is, as it's a thin wrapper around the native toolkits.
    - throwaway24242 11y ago
      I think native UIs are overrated and just cause headaches for developers. E.g. take the most popular UI system: HTML/CSS/JS: users have no problem with the fact that all their favourite websites look different. IMHO it is a better idea when the application enforces the same UI across platforms (like QT) than the platform expecting the same UI for all programs. On top of that QT does support native look&feel.
      - zanny 11y ago
        Theres a major difference between a website and a native application. I'm used to websites having no consistency and having elements all randomly over the page. I'm only there for a few minutes, after all. A lot of productivity software uses Qt. If it were not using native look and feel it would piss everyone and their grams off when system level keyboard shortcuts didn't work, when menu bars weren't oriented system native, when it didn't use the system file dialog, etc. Integrating with the OS is essential to workflow unless the application literally is your entire workflow.
      - rdsnsca 11y ago
        The truth is Mac user expect a Ui to look and feel native, otherwise you will be savaged in reviews, no matter how good your feature set. You last sentence tells me you have never used a QT app on a Mac, because it does not look and feel native.
        shaan7 11y ago
        There are ones that don't (Quassel for example) and there are ones that do (VLC for one). At the end there is always some polish a developer needs to do, no matter how awesome the toolkit gets. If the developer won't do that, your app will look crap. And its not just OSX, you write your Qt app on Windows and then you run it on Linux, you will need some fine tuning to look perfect. I still prefer it over any other free IRC client for OSX simply because the feature set rocks.
        throwaway24242 11y ago
        But do the users care? I do not think so. Otherwise a lot of famous websites would have native UI clients.
    - zanny 11y ago
      There is some insane technical debt maintaining three versions of your application with platform specific plumbing. It almost never is worth the investment to become portable after the fact, but when you start out it always strikes me as incredibly shortsighted to lock yourself into a native toolkit in the first place when Qt is so good nowadays.
      - panic 11y ago
        You could also make this argument in the other direction: it's incredibly shortsighted to lock yourself into Qt when there are some things you can do only with a native toolkit. Using native libraries on each platform gives you flexibility and intra-platform consistency at the expense of lots of extra effort. It really just comes down to whether you're willing to expend this effort or not.
        throwaway24242 11y ago
        What are examples that you can just do with a native toolkit?
        panic 11y ago
        One example that comes to mind is adding custom force touch events on Apple's new trackpads.
  - natosha_bard 11y ago
    Unity only uses native UI systems for Window management, input handling, and menus/file dialogs. The rest of Unity's UI is intentionally written in Unity's own GUI. We chose GTK over QT for Linux because Unity 5.1 ships with CEF (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework) as the embedded browser and CEF already pulls in a dependency on GTK).
  - jebblue 11y ago
    It seems Gtk has won, why don't the QT developers and supporters move to the Gtk camp and work to make it better rather then keep QT alive which just wastes efforts.
    - JupiterMoon 11y ago
      I'm new to this but I thought that QT is more convenient to use on windows and osx?
    - sirtaj 11y ago
      Because for professional development, there's really no comparison; Qt is on a different level from GTK entirely. I just did a keyword search on Monster India - Qt: 69 jobs, GTK: 3 jobs.
      - htns 11y ago
        Yeah, just about the only reasons to use GTK+ in new projects are the plain C API and slightly better bindings. Qt bindings support deteriorated a little from Qt 4 to Qt 5 (python is there but still no java bindings as far as I can tell), whereas GTK+ isn't expanding in features so it doesn't get to have such problems.
    - seba_dos1 11y ago
      "Gtk has won" [citation needed]
      - adrusi 11y ago
        It has essentially won on linux, where Qt is limitted to the KDE subculture and cross platform apps for which linux is not a priority. GNOME, Unity, Pantheon, XFCE, LXDE, Mate, Cinnamon, etc. all work best with GTK. With some of the heavier weight desktops, Qt apps look quite out of place, kind of like how cross platform UI apps look on Mac and Windows. Since most Qt apps on linux come from the KDE ecosystem, they often pull in a lot of KDE dependancies, which means a lot of extra packages lying around your system, creating clutter, which might bother some people. The relatively heavyweight nature of most Qt apps makes them less appropriate on systems that use just a window manager rather than a full desktop environment. Sure, a lot of GTK apps pull in a bunch of GNOME dependancies, but there's also a large contingent of GTK apps from the lighter-weight XFCE world that don't. Outside of linux, Qt has won pretty decisively, mostly because the GTK developers aren't interested in making GTK apps look good on Mac/Windows, so long as they run.
  - rdsnsca 11y ago
    Probably because Unity was a Mac first program. The Windows version came when it was 2 or so i think.
justthistime_ 11y ago
With .NET Core, is there any reason to not just drop IL2CPP completely? (The whole thing only existed in the first place because they are stuck on a completely outdated Mono version, due to Xamarin changing the license of newer Mono versions trying to extract money from Unity.)
- reitzensteinm 11y ago
  I was hoping for a switch to Microsoft's .Net, which would enable use of Arcadia (Clojure in Unity3D) for serious/big tasks. Right now, the GC performance of Unity is horrible relative to what you'd get on the JVM and there's no reason to believe IL2CPP is going to be any better. When you don't have a generational collector, you have to seriously constrain your allocations, crimping your immutable style. The Unity roadmap suggests they're going ahead with a Mono upgrade (I believe they dynamically link every platform sans iOS): http://unity3d.com/unity/roadmap/ http://unity3d.com/unity/roadmap/ So it's probably not on the cards (no pun intended). However, the Mono upgrade will bring a generational GC to the platforms on which it's usable (which will fall somewhere on the spectrum of Editor, PC, !iOS).
  - jebblue 11y ago
    I helped build a web service product that ran on Mono in the early 2000's back when I was still also a Windows dev but with the significant improvements over the mid to latter 2000's to the speed and stability of the JVM I dare say (and consider Mojang's success) the JVM would be a better choice for future game engines than Mono. With so much work having gone into using Mono I doubt it would be changed to the JVM but also Microsoft to their credit is open sourcing some/a lot? of the .NET runtime to open platforms like Linux. The only problem I have with Mono today is Miguel's decision to completely disrespect and disregard the Linux Desktop: http://tirania.org/blog/archive/2012/Aug-29.html http://tirania.org/blog/archive/2012/Aug-29.html
    - GFK_of_xmaspast 11y ago
      That blog post is correct tho?
evmar 11y ago
I worked on the Linux version of a large program and after some years of it I mostly concluded that it's hard to know in advance which things work everywhere and which won't, unless you ensure your programmers are familiar with the quirks of all the platforms you intend to run on (which isn't really practical). (I was working on the Windows -> Linux path, but for some cross-OS examples that aren't that I was surprised to learn that while toupper follows your locale on Linux, OS X uses the "C" locale by default. Or that shm_open has a tiny size limit on OS X.) I think the best you can do is (1) write a lot of tests; (2) whenever you add an OS-specific snippet, use the same ifdef string so it's easy to grep for.
hyperion2010 11y ago
> it’s the place where case sensitivity problems really show up Who made the decision to have case insensitive file systems? If I had a time machine they would be high on the list of people to visit and give a stern talking to.
- TillE 11y ago
  People always bring up the point that it's supposed to be more user-friendly, but all of those concerns are really better addressed in the UI rather than in the filesystem layer.
  - toxicFork 11y ago
    I guess back then things were just more connected, there probably weren't great "best practices", I have seen how there are still some projects that need evolve to be more modular rather than "one file to do EVERYTHING". The OS is just another software project, isn't it?
  - zem 11y ago
    what is the ui layer going to do when you have both hello.txt and HELLO.TXT? if case-insensitivity is to be done at all, it has to be enforced at the file system level that the two names refer to the same file.
- reitzensteinm 11y ago
  I don't think the problem is having case insensitive file systems, the problem is having both on different platforms. A similar problem as with different endians. If everything were case insensitive, it wouldn't cause issues. While as a programmer, I prefer the level of precision case sensitivity provides, I'm hard pressed to make the case that it is better for an average computer user.
  - ploxiln 11y ago
    ... which exact type of case insensitivity would you do? Only for latin letters in ascii? or such letters plus just one accent type? or also less familiar symbols used in other writing systems? Did you know that different languages can contradict one another? [1] Are you also going to normalize unicode representation, like Mac OS X does? (it uses a variant of NFD normalization, which is arguably the wrong one to do but that's life) (I only know this because I've been tripped up by it) Basically, you can't "just do case insensitive everywhere", that doesn't fix the confusion and inconsistency. [1] http://www.i18nguy.com/unicode/turkish-i18n.html http://www.i18nguy.com/unicode/turkish-i18n.html (see table titled "English vs. Turkish Case Mappings") (this is just the first example I could find with a quick search)
jebblue 11y ago
I gave Steam (should be Valve) credit for their work to bring games to Linux, I should have mentioned Unity. Some of the best games I've played in the past 2 years were based on Unity. The Unreal platform brings new promises and will be nice to see games unfold from those on Linux. My money is good for Linux games for my lifetime which hopefully is still decades.
mkozlows 11y ago
So this is framed as a "things we should have done back then", but I think that the part about case-sensitive filenames show why that wouldn't work: "Of course we tried to be smart in the early days, but if you don’t set up a way to actually verify that what you’re doing works on a case-sensitive file system, then it will never fail that some well-intentioned programmer throws a toLower() in somewhere and ruins the party." Because yeah, if nobody's running or testing a code path, it will absolutely decay. You can't write anticipatory code to work for hypothetical future requirements that you don't necessarily understand and are never testing.
- natosha_bard 11y ago
  Right, it's in the category of "things I wish we would have done back then" because it would have been easy to solve: we could have simply had everyone install OS X (which is what Unity was originally written on) on a case-sensitive HFS+ filesystem, but we didn't do that. Ooops. Oh well. :-)
wtbob 11y ago
Wow, I wouldn't have thought that folks would be sloppy about case, but I guess it makes sense if all one's used to is a case-insensitive system. > Same policy as with our runtime; in order to keep our own sanity, we will officially support Ubuntu Linux. … > Installer will (most likely – it’s one of the things we didn’t do yet) just be a .deb package. I really wish folks would support Debian first, and let Ubuntu support flow from that.
- jebblue 11y ago
  I agree in both cases. There would be no Ubuntu today without Debian (although I've never installed it because I tried years ago and found it to be too difficult which is why I went with Ubuntu after becoming less than enchanted with RedHat) and really I thought case issues were a thing of the 90's, early 2000's at the latest. I've read that Debian has gotten easier to install though but I'm not sure from their web site which one. They need to get someone with a marketing background to help them with their web site.
  - natosha_bard 11y ago
    I can totally sympathize, and we'd like to support every distribution. :-( But the simple statistics show that we get the most bang for our buck by supporting Ubuntu because of its desktop market share. The great thing about the Linux community is that it's full if crazy smart people who will go out of their way to make sure stuff is working on their distribution. And of course if something isn't working on your distro, it'll be just like the player -- send us a bug report or poke us on the forums, and we'll do what we can. But in order to not spread our resources too thin (especially considering that this is starting off as an experiment), we have to set some boundaries, and we need to do what will make sense for the largest number of users. And case sensitivity problems will exist as long as we have a mixture of some platforms (Windows/OS X) using case-insensitive filesystems by default, and others (Linux) using case-sensitive filesystems by default.
    - kuschku 11y ago
      Even worse, on Mac OSX some people use case-sensitive file systems. So you’d have to support it anyway.
kayoone 11y ago
Looking forward to this but given the fact that Unity is not the most stable piece of software on it's main platforms, i am still a bit skeptical.
mynegation 11y ago
About 12 years ago I worked on porting pretty large C/C++ codebase from Unix to be compiled also on Windows. What helped is that C/C++ part of the software had no GUI components (that was handled by Java) and by that time it has already supported Linux, Solaris, and HP-UX, which later were dropped, but we already had some experience of multi-platform support. Yes, file system case-sensitivity and dispersed strictly hardcoded pre-processor directives were the problem, but they were the least of the problems for me (every codebase is different, so I am not doubting posted article). The differences between POSIX and WinAPI, GNU-isms in the code (Windows version was compiled by Visual C++ 2002 at the time), and support differences between C++ STL version were bigger problems. My approach was to choose a C library specifically designed to support multiple platforms - Apache Portable Runtime (I also considered QT, NSPR, and GTK at the time). This helped tremendously and I would recommend doing the same to anyone doing similar effort or - better yet - start using something like that at the design stage.
akavel 11y ago
I'm scratching my head after this article, not really sure if the author really believes in what he's complaining on fully? For me, those are kinda nice "wishes", in that if they happened, the porting team would have less work to do now, sure. But, actually, especially those specific things listed - they sound to me like things, which would be unnecessarily hard and really costly things to do "in the past", assuming they were initially aiming just for Windows (and maybe OSX, don't know it well). So, like, I feel like doing them that way originally was actually a very good decision. I'm even starting to think: if the author has just those things to complain about, then maybe actually the codebase should be described as written fairly portably and future-proof... To explain my argument, I'll try to elaborate a bit more on the points raised by the author: 1. Case sensitivity in paths. So, as others mentioned too: on a case insensitive filesystem like Windows, you'd have no chance to verify (i.e. test) "case-sensitive-correctness" anyway. So, you'd fail on this here and there anyway. Ok, maybe using the OSX FS with case-sensitive option would be a guard. But, OTOH, I believe OSX has it case-insensitive by default anyway, no? So, by testing in case-sensitive, you're actually testing the "least used path", which sounds not so smart, actually... especially given that switching from case-sensitive to case-insenstive (i.e. the other way) has its own surprises, then... 2. No OS #ifdefs Um;... so... like... what else to use instead?... 3. "Assumptions": 3.1. Compilers. This point seems actually to be more "no C++11". OK; yeah; sure; but remember: then you'll get maimed for being backwards, "corporate-ish", you'll get no "smart young hackers", people will get more frustrated... Not that you'd really have a good alternative to C++ (Java/Python need huge and messy runtime env; and if you need performance of C++, you need performance of C++; if you started now, you could maybe at least try using Go as a kinda compromise, but depends on your actual needs). You know, whichever way you choose, you have pros and cons. And, supposedly, some time ago when the decision was made, the pros were actually outweighing the cons; so, it wouldn't sound so smart to me to choose otherwise... 3.2. & 3.3. "Assumptions about [GUI]" Sorry to say, but: GUIs are just not portable. Every GUI environment has different "idioms", "interface guidelines", etc. Windows has different. OSX has different. Linux has different. Heck, different versions of the OSes have them different! On Linux, even in the same "OS version" (um, distro? kernel?) you have multiple "desktop environments" with different widgets, layouts, etc (KDE, Gnome, ...). Conversely, on Windows, Microsoft likes to sometimes pull you in multiple directions at the same time too, e.g. when new MS Office introduces new widgets, or new Explorer does the same, or you have Metro+classic, or whatever. Dunno about OSX; I dare suppose it's not all roses there either. I seem to believe now, that if you want to have a cross-platform app with a GUI, you should really write the GUI for each platform from scratch (only trying to reuse some parts). Or, consciously break with staying consistent with any OS interface guidelines. As to "copy & paste": on Linux it has actually totally different underlying mechanism(s) than on Windows. So, you probably have to rewrite even low level parts of it very differently. Not just menu entries. So - I don't really see what's there to complain on. The app was written for some 2 OSes; now guys port it to a third one; awesome! just, sorry, you know, there's gonna be some work needed in order to complete that. <shrug>
Superpelican 11y ago
Having switched to OS X about a year ago after years of Linux usage, I can say that personally I really like the case insensitivity OS X has by default. It doesn't whine every time I accidentally (don't) press caps lock. Case sensitive file systems must be the dumbest invention ever. Who is seriously going to distinguish his/her files by capital and non-capital letters? "Test.txt" and "test.txt" should be the same!
- rodgerd 11y ago
  To borrow a snark from Twitter: the same sort of person who has a cat named mittens and another cat named MITTENS.
- DanBC 11y ago
  What is the reason for case insensitive file systems? This 2001 page has some possible reasons. (Much simpler; some benefits). http://xahlee.info/UnixResource_dir/_/fileCaseSens.html http://xahlee.info/UnixResource_dir/_/fileCaseSens.html
- 4ydx 11y ago
  This only applies to ASCII (at best). Case insensitivity is very annoying.
- tagrun 11y ago
  Did you know that upper <-> lower conversion (which a case-insensitive FS must perform) isn't universal and depends on locale?
GFK_of_xmaspast 11y ago
"The C++11 standard is, ahem, vague in some places and different compilers choose to interpret the standard, well, differently." I'm a little curious to know what they were doing. EDIT: Dammit, I should have kept reading, the very next sentence has: " Lots of compilation errors that involve this-c++-template-thingy-with-lots-of-angle-brackets does not match that-c++-template-thingy-with-lots-of-angle-brackets-that-has-a-const-somewhere-in-the-middle." and personally I would have thought that of course you need the consts to match and it would have been this way for literal decades now.
anon4 11y ago
I still don't understand why so many are jumping on the Linux gaming bandwagon. I mean, it's nice for me and all, I just don't really see the business gains for them.
- tormeh 11y ago
  Costs are slightly lower than sales, I would expect. It's also a political issue when it comes to Humble Bundles and crowdfunding. Costs have dropped with C++11, Unity and Steam for Linux. Sales have risen since Linux' market share is rising (very very slowly). Also of note is that Linux users seem to have beefier setups than their Windows peers, according to Steam Survey (12GB RAM vs 8, 2GB VRAM vs 1, bigger screens and more cores). More money spent on hardware correlates with more money being spent on games.
- white-flame 11y ago
  Right at the top of the article they call it a labor of love for those inside the company.
white-flame 11y ago
Their biggest failure is not self-hosting the editor as a Unity application itself. Any target they support could have become an editor platform.
- natosha_bard 11y ago
  The Editor needs to do all kinds of complex window management, and other stuff, and also uses all sorts of 3rd party middleware (like Enlighten, for global illumination) that wouldn't work as being part of the runtime itself. The editor is, however, largely written in Unity (uses the same APIs, etc, in addition to a bunch of private ones).
natosha_bard 11y ago
So based on all of the feedback we've gotten, I'm going to look at making a platform-agnostic installer as well as a .deb package, for people who want to run Unity on non-Ubuntu installations. We're probably going to still only offer "official" support for Ubuntu, since that is what we build/test on, but we'll try to fix what we can when problems are supported on other distros.

94 points by mariuz 11y ago

ianlevesque 11y ago

Gtk does sound like a better choice than raw X11, particularly as Wayland, Mir, and friends continue to grow.

JupiterMoon 11y ago
Just curious. Why not go for QT for the whole GUI on all platforms?
- cwyers 11y ago
  Because native GUI on Windows and OSX is better for those users and already exists?
  - JupiterMoon 11y ago
    I'm new to GUI programming and foreign to both Windows and OSX so please forgive my ignorance. In what way are the native GUIs better? Are they faster/more responsive or do they look better? Which would be more work over the e.g. 1,2 and 5 year period maintaining three guis or one? (Or is QT not quite cross platform so one ends up maintaining three inferior versions anyway?)
    - jdub 11y ago
      They behave exactly the way you'd expect, because they don't attempt to copy the expected behaviour. They define the expected behaviour.
      - matt_kantor 11y ago
        Not in this case. Unity's editor has a very "unique" UI. It doesn't try to follow OS-specific conventions most of the time. https://youtu.be/DEumkKjE2YQ?t=8m15s https://youtu.be/DEumkKjE2YQ?t=8m15s
      - JupiterMoon 11y ago
        Until your user has your program installed on e.g. mac and windows and now it works differently on each... This is actually an annoying problem. As a linux user lack of consistency between apps is frustrating but similarly I know people that struggle with changing from mac to windows regularly.
    - zanny 11y ago
      Qt is cross platform. The difference is that there are UI rendering (say, scaling) behaviors the native toolchains use Qt does not. It comes as close as possible within its widget layout engine it can get away with to native on every platform it supports (which when you consider thats everything from Android to Windows is a feat) but is never a perfect reproduction. Its not something that is going to be "work" for you - you just aren't going to fix it. You get a portable codebase without any of the if WIN else OSX soup, but the experience will never be perfectly native. Though nowadays I don't even know what native Windows means anymore, is it that ribbon crap, or the metro thing? Because Qt apps just use oldschool Windows Forms style menubars / buttons / etc. You can just go test it yourself, go run VLC and see how "native" it feels. Its using Qt everywhere except Android. But if you want to develop cross platform native looking software... Qt is absolutely it. Only option. And it gets better each release. Otherwise you are going the route of the Unity guys, rewriting your program for every single system.
      - nzp 11y ago
        > But if you want to develop cross platform native looking software... Qt is absolutely it. Only option. If you want to develop cross platform native looking software, Qt most certainly is not the only option, wxWidgets is. In fact, as you yourself pointed out, Qt isn't really native, just tries to fake the native look and feel. wxWidgets actually is, as it's a thin wrapper around the native toolkits.
  - throwaway24242 11y ago
    I think native UIs are overrated and just cause headaches for developers. E.g. take the most popular UI system: HTML/CSS/JS: users have no problem with the fact that all their favourite websites look different. IMHO it is a better idea when the application enforces the same UI across platforms (like QT) than the platform expecting the same UI for all programs. On top of that QT does support native look&feel.
    - zanny 11y ago
      Theres a major difference between a website and a native application. I'm used to websites having no consistency and having elements all randomly over the page. I'm only there for a few minutes, after all. A lot of productivity software uses Qt. If it were not using native look and feel it would piss everyone and their grams off when system level keyboard shortcuts didn't work, when menu bars weren't oriented system native, when it didn't use the system file dialog, etc. Integrating with the OS is essential to workflow unless the application literally is your entire workflow.
    - rdsnsca 11y ago
      The truth is Mac user expect a Ui to look and feel native, otherwise you will be savaged in reviews, no matter how good your feature set. You last sentence tells me you have never used a QT app on a Mac, because it does not look and feel native.
      - shaan7 11y ago
        There are ones that don't (Quassel for example) and there are ones that do (VLC for one). At the end there is always some polish a developer needs to do, no matter how awesome the toolkit gets. If the developer won't do that, your app will look crap. And its not just OSX, you write your Qt app on Windows and then you run it on Linux, you will need some fine tuning to look perfect. I still prefer it over any other free IRC client for OSX simply because the feature set rocks.
      - throwaway24242 11y ago
        But do the users care? I do not think so. Otherwise a lot of famous websites would have native UI clients.
  - zanny 11y ago
    There is some insane technical debt maintaining three versions of your application with platform specific plumbing. It almost never is worth the investment to become portable after the fact, but when you start out it always strikes me as incredibly shortsighted to lock yourself into a native toolkit in the first place when Qt is so good nowadays.
    - panic 11y ago
      You could also make this argument in the other direction: it's incredibly shortsighted to lock yourself into Qt when there are some things you can do only with a native toolkit. Using native libraries on each platform gives you flexibility and intra-platform consistency at the expense of lots of extra effort. It really just comes down to whether you're willing to expend this effort or not.
      - throwaway24242 11y ago
        What are examples that you can just do with a native toolkit?
        panic 11y ago
        One example that comes to mind is adding custom force touch events on Apple's new trackpads.
- natosha_bard 11y ago
  Unity only uses native UI systems for Window management, input handling, and menus/file dialogs. The rest of Unity's UI is intentionally written in Unity's own GUI. We chose GTK over QT for Linux because Unity 5.1 ships with CEF (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework) as the embedded browser and CEF already pulls in a dependency on GTK).
- jebblue 11y ago
  It seems Gtk has won, why don't the QT developers and supporters move to the Gtk camp and work to make it better rather then keep QT alive which just wastes efforts.
  - JupiterMoon 11y ago
    I'm new to this but I thought that QT is more convenient to use on windows and osx?
  - sirtaj 11y ago
    Because for professional development, there's really no comparison; Qt is on a different level from GTK entirely. I just did a keyword search on Monster India - Qt: 69 jobs, GTK: 3 jobs.
    - htns 11y ago
      Yeah, just about the only reasons to use GTK+ in new projects are the plain C API and slightly better bindings. Qt bindings support deteriorated a little from Qt 4 to Qt 5 (python is there but still no java bindings as far as I can tell), whereas GTK+ isn't expanding in features so it doesn't get to have such problems.
  - seba_dos1 11y ago
    "Gtk has won" [citation needed]
    - adrusi 11y ago
      It has essentially won on linux, where Qt is limitted to the KDE subculture and cross platform apps for which linux is not a priority. GNOME, Unity, Pantheon, XFCE, LXDE, Mate, Cinnamon, etc. all work best with GTK. With some of the heavier weight desktops, Qt apps look quite out of place, kind of like how cross platform UI apps look on Mac and Windows. Since most Qt apps on linux come from the KDE ecosystem, they often pull in a lot of KDE dependancies, which means a lot of extra packages lying around your system, creating clutter, which might bother some people. The relatively heavyweight nature of most Qt apps makes them less appropriate on systems that use just a window manager rather than a full desktop environment. Sure, a lot of GTK apps pull in a bunch of GNOME dependancies, but there's also a large contingent of GTK apps from the lighter-weight XFCE world that don't. Outside of linux, Qt has won pretty decisively, mostly because the GTK developers aren't interested in making GTK apps look good on Mac/Windows, so long as they run.
- rdsnsca 11y ago
  Probably because Unity was a Mac first program. The Windows version came when it was 2 or so i think.

justthistime_ 11y ago

With .NET Core, is there any reason to not just drop IL2CPP completely? (The whole thing only existed in the first place because they are stuck on a completely outdated Mono version, due to Xamarin changing the license of newer Mono versions trying to extract money from Unity.)

reitzensteinm 11y ago
I was hoping for a switch to Microsoft's .Net, which would enable use of Arcadia (Clojure in Unity3D) for serious/big tasks. Right now, the GC performance of Unity is horrible relative to what you'd get on the JVM and there's no reason to believe IL2CPP is going to be any better. When you don't have a generational collector, you have to seriously constrain your allocations, crimping your immutable style. The Unity roadmap suggests they're going ahead with a Mono upgrade (I believe they dynamically link every platform sans iOS): http://unity3d.com/unity/roadmap/ http://unity3d.com/unity/roadmap/ So it's probably not on the cards (no pun intended). However, the Mono upgrade will bring a generational GC to the platforms on which it's usable (which will fall somewhere on the spectrum of Editor, PC, !iOS).
- jebblue 11y ago
  I helped build a web service product that ran on Mono in the early 2000's back when I was still also a Windows dev but with the significant improvements over the mid to latter 2000's to the speed and stability of the JVM I dare say (and consider Mojang's success) the JVM would be a better choice for future game engines than Mono. With so much work having gone into using Mono I doubt it would be changed to the JVM but also Microsoft to their credit is open sourcing some/a lot? of the .NET runtime to open platforms like Linux. The only problem I have with Mono today is Miguel's decision to completely disrespect and disregard the Linux Desktop: http://tirania.org/blog/archive/2012/Aug-29.html http://tirania.org/blog/archive/2012/Aug-29.html
  - GFK_of_xmaspast 11y ago
    That blog post is correct tho?

evmar 11y ago

I worked on the Linux version of a large program and after some years of it I mostly concluded that it's hard to know in advance which things work everywhere and which won't, unless you ensure your programmers are familiar with the quirks of all the platforms you intend to run on (which isn't really practical). (I was working on the Windows -> Linux path, but for some cross-OS examples that aren't that I was surprised to learn that while toupper follows your locale on Linux, OS X uses the "C" locale by default. Or that shm_open has a tiny size limit on OS X.) I think the best you can do is (1) write a lot of tests; (2) whenever you add an OS-specific snippet, use the same ifdef string so it's easy to grep for.

hyperion2010 11y ago

> it’s the place where case sensitivity problems really show up Who made the decision to have case insensitive file systems? If I had a time machine they would be high on the list of people to visit and give a stern talking to.

TillE 11y ago
People always bring up the point that it's supposed to be more user-friendly, but all of those concerns are really better addressed in the UI rather than in the filesystem layer.
- toxicFork 11y ago
  I guess back then things were just more connected, there probably weren't great "best practices", I have seen how there are still some projects that need evolve to be more modular rather than "one file to do EVERYTHING". The OS is just another software project, isn't it?
- zem 11y ago
  what is the ui layer going to do when you have both hello.txt and HELLO.TXT? if case-insensitivity is to be done at all, it has to be enforced at the file system level that the two names refer to the same file.
reitzensteinm 11y ago
I don't think the problem is having case insensitive file systems, the problem is having both on different platforms. A similar problem as with different endians. If everything were case insensitive, it wouldn't cause issues. While as a programmer, I prefer the level of precision case sensitivity provides, I'm hard pressed to make the case that it is better for an average computer user.
- ploxiln 11y ago
  ... which exact type of case insensitivity would you do? Only for latin letters in ascii? or such letters plus just one accent type? or also less familiar symbols used in other writing systems? Did you know that different languages can contradict one another? [1] Are you also going to normalize unicode representation, like Mac OS X does? (it uses a variant of NFD normalization, which is arguably the wrong one to do but that's life) (I only know this because I've been tripped up by it) Basically, you can't "just do case insensitive everywhere", that doesn't fix the confusion and inconsistency. [1] http://www.i18nguy.com/unicode/turkish-i18n.html http://www.i18nguy.com/unicode/turkish-i18n.html (see table titled "English vs. Turkish Case Mappings") (this is just the first example I could find with a quick search)

jebblue 11y ago

I gave Steam (should be Valve) credit for their work to bring games to Linux, I should have mentioned Unity. Some of the best games I've played in the past 2 years were based on Unity. The Unreal platform brings new promises and will be nice to see games unfold from those on Linux. My money is good for Linux games for my lifetime which hopefully is still decades.

mkozlows 11y ago

So this is framed as a "things we should have done back then", but I think that the part about case-sensitive filenames show why that wouldn't work: "Of course we tried to be smart in the early days, but if you don’t set up a way to actually verify that what you’re doing works on a case-sensitive file system, then it will never fail that some well-intentioned programmer throws a toLower() in somewhere and ruins the party." Because yeah, if nobody's running or testing a code path, it will absolutely decay. You can't write anticipatory code to work for hypothetical future requirements that you don't necessarily understand and are never testing.

natosha_bard 11y ago
Right, it's in the category of "things I wish we would have done back then" because it would have been easy to solve: we could have simply had everyone install OS X (which is what Unity was originally written on) on a case-sensitive HFS+ filesystem, but we didn't do that. Ooops. Oh well. :-)

wtbob 11y ago

Wow, I wouldn't have thought that folks would be sloppy about case, but I guess it makes sense if all one's used to is a case-insensitive system. > Same policy as with our runtime; in order to keep our own sanity, we will officially support Ubuntu Linux. … > Installer will (most likely – it’s one of the things we didn’t do yet) just be a .deb package. I really wish folks would support Debian first, and let Ubuntu support flow from that.

jebblue 11y ago
I agree in both cases. There would be no Ubuntu today without Debian (although I've never installed it because I tried years ago and found it to be too difficult which is why I went with Ubuntu after becoming less than enchanted with RedHat) and really I thought case issues were a thing of the 90's, early 2000's at the latest. I've read that Debian has gotten easier to install though but I'm not sure from their web site which one. They need to get someone with a marketing background to help them with their web site.
- natosha_bard 11y ago
  I can totally sympathize, and we'd like to support every distribution. :-( But the simple statistics show that we get the most bang for our buck by supporting Ubuntu because of its desktop market share. The great thing about the Linux community is that it's full if crazy smart people who will go out of their way to make sure stuff is working on their distribution. And of course if something isn't working on your distro, it'll be just like the player -- send us a bug report or poke us on the forums, and we'll do what we can. But in order to not spread our resources too thin (especially considering that this is starting off as an experiment), we have to set some boundaries, and we need to do what will make sense for the largest number of users. And case sensitivity problems will exist as long as we have a mixture of some platforms (Windows/OS X) using case-insensitive filesystems by default, and others (Linux) using case-sensitive filesystems by default.
  - kuschku 11y ago
    Even worse, on Mac OSX some people use case-sensitive file systems. So you’d have to support it anyway.

kayoone 11y ago

Looking forward to this but given the fact that Unity is not the most stable piece of software on it's main platforms, i am still a bit skeptical.

mynegation 11y ago

About 12 years ago I worked on porting pretty large C/C++ codebase from Unix to be compiled also on Windows. What helped is that C/C++ part of the software had no GUI components (that was handled by Java) and by that time it has already supported Linux, Solaris, and HP-UX, which later were dropped, but we already had some experience of multi-platform support. Yes, file system case-sensitivity and dispersed strictly hardcoded pre-processor directives were the problem, but they were the least of the problems for me (every codebase is different, so I am not doubting posted article). The differences between POSIX and WinAPI, GNU-isms in the code (Windows version was compiled by Visual C++ 2002 at the time), and support differences between C++ STL version were bigger problems. My approach was to choose a C library specifically designed to support multiple platforms - Apache Portable Runtime (I also considered QT, NSPR, and GTK at the time). This helped tremendously and I would recommend doing the same to anyone doing similar effort or - better yet - start using something like that at the design stage.

akavel 11y ago

I'm scratching my head after this article, not really sure if the author really believes in what he's complaining on fully? For me, those are kinda nice "wishes", in that if they happened, the porting team would have less work to do now, sure. But, actually, especially those specific things listed - they sound to me like things, which would be unnecessarily hard and really costly things to do "in the past", assuming they were initially aiming just for Windows (and maybe OSX, don't know it well). So, like, I feel like doing them that way originally was actually a very good decision. I'm even starting to think: if the author has just those things to complain about, then maybe actually the codebase should be described as written fairly portably and future-proof... To explain my argument, I'll try to elaborate a bit more on the points raised by the author: 1. Case sensitivity in paths. So, as others mentioned too: on a case insensitive filesystem like Windows, you'd have no chance to verify (i.e. test) "case-sensitive-correctness" anyway. So, you'd fail on this here and there anyway. Ok, maybe using the OSX FS with case-sensitive option would be a guard. But, OTOH, I believe OSX has it case-insensitive by default anyway, no? So, by testing in case-sensitive, you're actually testing the "least used path", which sounds not so smart, actually... especially given that switching from case-sensitive to case-insenstive (i.e. the other way) has its own surprises, then... 2. No OS #ifdefs Um;... so... like... what else to use instead?... 3. "Assumptions": 3.1. Compilers. This point seems actually to be more "no C++11". OK; yeah; sure; but remember: then you'll get maimed for being backwards, "corporate-ish", you'll get no "smart young hackers", people will get more frustrated... Not that you'd really have a good alternative to C++ (Java/Python need huge and messy runtime env; and if you need performance of C++, you need performance of C++; if you started now, you could maybe at least try using Go as a kinda compromise, but depends on your actual needs). You know, whichever way you choose, you have pros and cons. And, supposedly, some time ago when the decision was made, the pros were actually outweighing the cons; so, it wouldn't sound so smart to me to choose otherwise... 3.2. & 3.3. "Assumptions about [GUI]" Sorry to say, but: GUIs are just not portable. Every GUI environment has different "idioms", "interface guidelines", etc. Windows has different. OSX has different. Linux has different. Heck, different versions of the OSes have them different! On Linux, even in the same "OS version" (um, distro? kernel?) you have multiple "desktop environments" with different widgets, layouts, etc (KDE, Gnome, ...). Conversely, on Windows, Microsoft likes to sometimes pull you in multiple directions at the same time too, e.g. when new MS Office introduces new widgets, or new Explorer does the same, or you have Metro+classic, or whatever. Dunno about OSX; I dare suppose it's not all roses there either. I seem to believe now, that if you want to have a cross-platform app with a GUI, you should really write the GUI for each platform from scratch (only trying to reuse some parts). Or, consciously break with staying consistent with any OS interface guidelines. As to "copy & paste": on Linux it has actually totally different underlying mechanism(s) than on Windows. So, you probably have to rewrite even low level parts of it very differently. Not just menu entries. So - I don't really see what's there to complain on. The app was written for some 2 OSes; now guys port it to a third one; awesome! just, sorry, you know, there's gonna be some work needed in order to complete that. <shrug>

Superpelican 11y ago

Having switched to OS X about a year ago after years of Linux usage, I can say that personally I really like the case insensitivity OS X has by default. It doesn't whine every time I accidentally (don't) press caps lock. Case sensitive file systems must be the dumbest invention ever. Who is seriously going to distinguish his/her files by capital and non-capital letters? "Test.txt" and "test.txt" should be the same!

rodgerd 11y ago
To borrow a snark from Twitter: the same sort of person who has a cat named mittens and another cat named MITTENS.
DanBC 11y ago
What is the reason for case insensitive file systems? This 2001 page has some possible reasons. (Much simpler; some benefits). http://xahlee.info/UnixResource_dir/_/fileCaseSens.html http://xahlee.info/UnixResource_dir/_/fileCaseSens.html
4ydx 11y ago
This only applies to ASCII (at best). Case insensitivity is very annoying.
tagrun 11y ago
Did you know that upper <-> lower conversion (which a case-insensitive FS must perform) isn't universal and depends on locale?

GFK_of_xmaspast 11y ago

"The C++11 standard is, ahem, vague in some places and different compilers choose to interpret the standard, well, differently." I'm a little curious to know what they were doing. EDIT: Dammit, I should have kept reading, the very next sentence has: " Lots of compilation errors that involve this-c++-template-thingy-with-lots-of-angle-brackets does not match that-c++-template-thingy-with-lots-of-angle-brackets-that-has-a-const-somewhere-in-the-middle." and personally I would have thought that of course you need the consts to match and it would have been this way for literal decades now.

anon4 11y ago

I still don't understand why so many are jumping on the Linux gaming bandwagon. I mean, it's nice for me and all, I just don't really see the business gains for them.

tormeh 11y ago
Costs are slightly lower than sales, I would expect. It's also a political issue when it comes to Humble Bundles and crowdfunding. Costs have dropped with C++11, Unity and Steam for Linux. Sales have risen since Linux' market share is rising (very very slowly). Also of note is that Linux users seem to have beefier setups than their Windows peers, according to Steam Survey (12GB RAM vs 8, 2GB VRAM vs 1, bigger screens and more cores). More money spent on hardware correlates with more money being spent on games.
white-flame 11y ago
Right at the top of the article they call it a labor of love for those inside the company.

white-flame 11y ago

Their biggest failure is not self-hosting the editor as a Unity application itself. Any target they support could have become an editor platform.

natosha_bard 11y ago
The Editor needs to do all kinds of complex window management, and other stuff, and also uses all sorts of 3rd party middleware (like Enlighten, for global illumination) that wouldn't work as being part of the runtime itself. The editor is, however, largely written in Unity (uses the same APIs, etc, in addition to a bunch of private ones).

natosha_bard 11y ago

So based on all of the feedback we've gotten, I'm going to look at making a platform-agnostic installer as well as a .deb package, for people who want to run Unity on non-Ubuntu installations. We're probably going to still only offer "official" support for Ubuntu, since that is what we build/test on, but we'll try to fix what we can when problems are supported on other distros.