Live data from Hacker News

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

natoshabard.com

101–110 of 114 posts

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

#101
post #84

Earlier quoted context omitted.

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 of…

You can use gtk styling in Qt apps and it looks just like GTK. Also Ubuntu Unity is switching to Qt for unity 8. As for dependencies, there are definitely more Qt apps on linux than just KDE apps.

[deleted]

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

#102
post #79
post #56

Earlier quoted context omitted.

Even worse, on Mac OSX some people use case-sensitive file systems. So you’d have to support it anyway.

No, the only sane way is if only the standard OSX config is supported. You can't do all kinds of weird things with your system and still expect it to be supported. As a developer, you want to support as few types of systems as possible, because that's easier and a tiny number of types comprise the great majority of systems. The extreme variant of this is of course console exclusivity.

iOS uses a case-sensitive file system, so that's one reason to keep it working if you already support the other OS in the family.

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

#103
post #95

Earlier quoted context omitted.

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.

What are examples that you can just do with a native toolkit?

One example that comes to mind is adding custom force touch events on Apple's new trackpads.

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

#104

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!

This only applies to ASCII (at best). Case insensitivity is very annoying.

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

#105
post #90
post #73

Earlier quoted context omitted.

> 2. No OS #ifdefs >Um;... so... like... what else to use instead?... You misread. The problem was that it was written in the form of if Windows do this, else do something that only works on OS X. The alternative is an explicit if for OS X, so that when you have a third OS to support you don't have to add that.

Hm, still not quite sure how that'd help; one still has to edit all that places, no? and in case one had "#else nothing", I don't see how that's more useful in any way. And the suggested "do something sensible by default" - if one could, one wouldn't have the ifdefs at all I suppose.

One possibility would be to have

#else #error #endif

If you work this way, you immediately know where to change your code.

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

#106
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.

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

#107
post #66

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…

Hi! I'm glad to see that the post is promoting constructive dialog about what does or doesn't make portable code, which is what the point actually was (in addition to shedding a bit of light about the state of porting Unity to Linux).

I'll clarify a few things:

1. Unity was originally written for Mac OS X, then later ported to Windows (not the other way around). Given that it's more than possible to have a case-sensitive HFS+ filesystems (since, I think OS X Panther released in 2003?), IMO it would have been more future proof for us to be sure to develop on a case-sensitive filesystem. Unity users over the years have tried to run Unity on a case-sensitive HFS+ filesystem and failed, so it would have been nice for all of those guys. :-)

2. Note that the point in the article was not to avoid using OS-specific defines (that's impossible), it was to make sure to do something sane (like #error) in the #else case that would make it immediately clear something need to be implemented there.

3.1. Yes, the higher-level point is indeed, "Be smart/cautious about what language features to use for the sake of portability".

3.2 & 3.3. Of course it's just a matter of opinion, but I wish that we'd considered a more platform-agnostic approach to GUI handling when the number of platforms that Unity was ported to went from 1 to 2. I (and others) are still a fan of the menu-system-written-entirely-in-Unity-GUI idea, but others (within Unity), for very good reasons, disagree. Fair enough.

Anyway, thanks for sharing your thoughts; when I write about anything I'm always looking forward to hearing a different perspective, and one of the main goals I had in writing the post was to promote constructive dialog about what it means to write "portable" code. :-)

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

#108

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

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

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

#109

Earlier quoted context omitted.

You can use gtk styling in Qt apps and it looks just like GTK. Also Ubuntu Unity is switching to Qt for unity 8. As for dependencies, there are definitely more Qt apps on linux than just KDE apps.

Plus "KDE apps pull a lot of deps" claim is already outdated, as recent releases of KDE Frameworks are highly modularized.

Not sure that this is true on the ground as yet. I guess it will filter from upstream to LTS distributions over the next few years.

Although I don't actually mind as I find that once you've got one KDE app you end up installing more as they are often quite a lot better (for me) than Gnome ones - and disk space is pretty cheap these days anyway.

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

#110
post #46

Earlier quoted context omitted.

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.

But do the users care? I do not think so. Otherwise a lot of famous websites would have native UI clients.

Absolutely. A QT/GTK/Java UI framework is immediately noticeable on OS X, and IMO even Windows though to a lesser extent.

Doing native is without a doubt the right call.

Post reply on HN