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?)
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.
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.
> 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.
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.
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.
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.
Yeah, but mostly because these applications do not work properly on mobile devices (smaller screen size, too slow, etc.) and a native (in the sense of NOT browser-based) application makes sense. However my hypothesis is just, that the LOOK does not have to fit into the OS.
Its not nearly as bad as you make it seem. Also you can embed objective c and native cocoa widgets in Qt apps so you cam make it as native as you want.
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.
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.
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.
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.
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.
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.
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.
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.
The "out of place" argument is one I commonly used by Mac and Linux users because they want everything to look native in their OS of choice and disregard dev time (to use a different window framework for each OS) and look in every other OS.
No one can win that argument to favor THEIR own OS look over another.
Qt apps are pretty reliable across platforms and are speedy to develop so that's what should be important instead of getting an impossible native look.
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.
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.)
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):
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).
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.
Mono changed the license so that it could be used in Unity to begin with. Mono was available under a copyleft license. To everyone. Including Unity. Unity couldn't/wouldn't accept it under those terms, so folks at now-Xamarin said, "We'll offer it to you under a commercial license if you won't take the copyleft offering." That's standard fare. Unity said, "Okay, deal." Mono continued to improve over the years. Unity was interested in those improvements. Mono said, "Okay. You can get those under a commercial license, too." Unity balked.
So what we're really talking about is that Unity wants the improvements that have been made to Mono, but doesn't want to pay for them.
Get this: They're still free at any point to accept Mono under the copyleft license that's available to literally everyone, but they won't accept it under any terms other than their own. That's it.
That seems like a very unfair description of the situation.
Do you know the specific licensing terms that Xamarin offered to Unity? Probably none of us here do. Given that, why would you assume Unity was the unreasonable party, and not Xamarin?
Regarding the copyleft license, while it is an option for everyone in general, it isn't an option for Unity, which needs to ship on platforms that do not allow such licenses (iOS, game consoles). Products like Unity will always need a commercial license as long as such platforms exist.
> Given that, why would you assume Unity was the unreasonable party, and not Xamarin?
I don't know what this means. What we know of the situation is that Unity doesn't want to pay a commercial license for Mono. This is even the way that pro-Unity/anti-Mono folks frame the situation. What do you have in mind here?
> Regarding the copyleft license, while it is an option for everyone in general, it isn't an option for Unity
That's all well and good, but it doesn't have much to with any obligations Mono has. Those are completely synthetic restrictions that the platform vendors are placing on the people targeting them. How does Mono get the blame for Apple and Nintendo's choices here? Why do Apple and Nintendo get treated as bedrock? Even so, that's bedrock that Unity knows they're working with. It's their choice to target those platforms.
EDIT:
> That seems like a very unfair description of the situation.
Unfair. Every reference to the Unity/Mono relationhip I've ever come across has been from someone who heard Unity's creative retelling of the conflict and parroted it exactly, down to overtly identifying Mono as the bad guy.
It means: Xamarin offered a commercial license to Unity for $X under Y terms. We don't know what X and Y are, since this was not a public negotiation. X and Y could be reasonable, or they could be totally unacceptable. They could be offered in good faith, or they could not.
We just don't know the answer, and you're assuming the party offering X and Y is reasonable. But it might not be. We don't know.
edit to your edit: if you heard people on the internet being wrong in some way, that doesn't justify you being wrong in the opposite way.
There's no "opposite" emanating here. I'm making no assumptions beyond what we do know, and what I describe is what we do know, sans Unity's spin. There's only me saying, "I'm a little sick of seeing Unity's going swallowed without critique." You characterize that as unfair somehow.
Companies A and B couldn't come to agreement to license something under terms Y that include $X in payment. Okay. There's neutrality in that statement. My comment says that (and no more).
What let's not do is say, "That makes company B a bunch of jerks." That is what the comment I'm responding to does, and it exists in a sea of others with the same tack.
> So what we're really talking about is that Unity wants the improvements that have been made to Mono, but doesn't want to pay for them.
which paints Unity as the bad guy, when for all we know, it might not be. Perhaps Unity is totally OK with paying for a license, but the Xamarin terms would have bankrupted it.
But thank you for clarifying what you meant. I agree there is no point in saying either party is the bad guy, since there is not enough public information to know.
In what way at all? Entity A doesn't want to pay entity B $X. That's the only thing the comment of mine that you quote says.
There are shops around that sell quadcopters for hundreds of dollars. I want a quadcopter. I don't want to pay hundreds of dollars. Have I just painted myself as a bad guy?
I repeat: the only reason my comment sounds pro-Mono is because, at neutral, it resists the spin of the one that paints Unity as a victim and Mono as a fiend.
"X wants Z, but doesn't want to pay Y for Z" implies several things. Perhaps you didn't intend them. But almost every reader will make those assumptions.
In particular, it sounds like Y is offering Z at a standard rate, as in "Sam wants a Chipotle burrito, but doesn't want to pay Chipotle for the burrito." Sam doesn't look good here - does Sam expect to get the burrito for free? Why does Sam think he is entitled to that?
Readers may not realize that there isn't a standard, objective rate for commercial licenses for Mono. Especially for the single biggest consumer of Mono, Unity, which uses it in products that its customers ship - a particularly complex situation.
Again, maybe you didn't intend to, but it sounded like you were saying something very negative about Unity. A less biased way to say it might be
"Unity and Mono could not arrive at mutually acceptable terms for Unity to license newer versions of Mono."
The only thing I'm saying are very negative things towards people who read (or heard the story of) Unity's PR-level attempt to make it sound like the people behind Mono are jerks, and then bought in to it full force and now repeat the line at every opportune moment (and then some inopportune ones, too, like the comment I replied to).
What we also don't know are the terms for the first negotiation. It's as possible that Mono made one offer and Unity countered with an insultingly lower one, then Mono accepted due to being a poor position to negotiate something "reasonable", but are no longer in a position to have to accept whatever is offered, now that Xamarin is off and running.
I'm aware of the terms, and they were ridiculous. Unfortunately, I can't disclose them, but they didn't make sense, and that's why Unity is on the path it's on now.
.NET's cross-platform support is still a work in progress. In particular, it doesn't have a web port, which is crucial for Unity. il2cpp is an AOT compiler to C++, which makes it trivially portable to practically everywhere, including the web, and unlike a VM there is no need to write a JIT for a new CPU, no need to port a runtime to a new OS, etc.
AOT-compiled code can also be very fast. I'm aware .NET has options there too, but il2cpp is literally focused on doing just that, and doing it very well.
il2cpp has advantages other than licensing (Mono is indeed open-source, but it is LGPL so it can only be used on platforms that comply with the LGPL; Unity runs on various non-LGPL platforms). il2cpp combines ease-of-use (C#) for Unity developers with native (C++) performance. What's not to love about that? :-P
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.
> 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.
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.
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?
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.
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.
... 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.
Point taken; I made the mistake of writing a prescription for the world based on my narrow English speaking world view.
I stand by what I said for ASCII, but in a Unicode world, I think you're right. When the mapping stops being simple, the principle of least surprise reverses in the favor of case sensitivity.
Case insensitivity is a nice way of phrasing "there are these arbitrary mappings between two sets of character codes which are meaningful only to the human being looking at the screen." This only works for ASCII and is complete madness as soon as you consider that any symbol you support for input anywhere in the world can and probably will be used by someone to name their files (try explaining why they can't to an irate user). Really, of the hundreds of thousands of unique symbols that human beings use an arbitrary subset of 26 of them have been deemed to be identical when it comes to naming things with symbols. I would say more but it would come out even worse.
They don't only work for ASCII. While the majority of writing systems in this world do not have case distinction, some that are widely used do. And arguably it is easier for the user to understand. The people who do trip over it are mostly programmers with the wrong assumptions about how things work and then complaining that things can't ever be simple ...
> 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.
Indeed; if everything were case-sensitive, or case-insensitive, we definitely wouldn't have these problems. But alas, it's not, and in 2015 here we are still having problems with case sensitivity. :-P
> 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.
I also personally prefer it ('a' and 'A' are not the same character!!!!), but I'm not sure if thats because it's inherently 'right' or because I'm used to Linux where case sensitivity is more or less a given. :-)
If I had a time machine they would be high on the list of people to visit and give a stern talking to.
Problem is that this goes back a long ways, e.g. back to the days of 36 bit computers.
Why 36 bits? Because that was just enough to encode 10 decimal digits, the standard back then for scientific computation.
Back then as in the days before core memory was used, so not much main memory either, and it was still expensive and painful after core was developed. So with that limited a budget, 6 bit character systems were common, that's enough to get things done and you can fit 6 in a word. One reason mainline Lisp doesn't use '?' in function names, why old languages like it and FORTRAN are or were case insensitive.
I think the issue is related, but in the underlying problem is slightly different because in the cases you describe there wasn't even enough room for a second set of symbols, so in reality there was no problem. The issue arises when there is a second set of symbols that can be encoded by the computer.
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.
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.
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. :-)
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.
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.
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.
I wanted to play around with Unity several times so if I get to do that it would be fun, thanks to you and your company for looking at making it a reality.
I think the point that grandparent was trying to make is that with Debian support, Ubuntu support comes almost for free, and you get other Debian descendants included as well. It broadens your set of officially supported users quite a lot for a cost comparable to adding support for a new Ubuntu release.
While generally it's also true the other way around (if something is made for Ubuntu, it's likely it will work on Debian without big issues), it would be nice for companies to recognize Ubuntu's roots and make the support official.
Of course in practice the community will quickly report back to you something like "hey, change your dependency to include libjpeg-turbo8 or libturbojpeg0, in Debian there's no libjpeg-turbo8" (real example from early Steam package), however, maybe it's just me, but when I see something having official support for Ubuntu only it sounds like "we were too lazy to give it a try on other distros", while explicitly stating support for Debian-based distributions starts sounding much more professional :)
You haven't been asked to support every distribution, just Debian, and possibly Ubuntu. Please pay attention to this advice. Supporting Debian practically gets you Ubuntu support for free, as well as a number of other popular distributions.
Steam and most Linux games can be run on any distribution with a bit of work on the user's part. The problem with officially supporting something is that suddenly the vendor is responsible for the game not working. That shit costs time and money. You say Debian, but sooner or later someone will demand support for Damn Small Linux. It's better to just stop at Ubuntu and let users of other distros install the right dependencies themselves.
Perhaps you're new to Linux. Let me assure you that Debian is a very popular distribution upon which many other distributions are based, and is in no way equivalent to suggesting support for one or a number of niche or less popular distros. I don't even use Debian myself, but I suggest it because I know that if Debian is supported then getting support for my preferred distribution will be effortless; the same is true for Ubuntu.
If they already have a build system set up, it's probably exceedingly trivial to build .deb package for Debian and Ubuntu, if such a thing is even required.
That said, the reason why they support Ubuntu is that it provides static targets. 12.04 will be supported until late 2017, which means that they users two years from now can install a .deb built today. Likewise, supporting 14.04 means .deb packages will work until late 2019. Especially for companies that want to develop on Linux, there's a huge benefit in first-party support from your vendor for the next four years.
case sensitivity is a classic when porting C/C++ codebases from Windows (I did my fair share). It starts with #include "whyShouldiCAReFoRSENSITivity.h", but for file I/O heavy those are the simple ones...
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.
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>
> 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.
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. :-)
Thanks for the reply! Most of them make much more sense now. As to 1. and 2., I'd say you could want to consider merging those clarifications into the original article. In 1., arguably some background knowledge of Unity could be expected from the reader, and maybe I'm just not the intended target. But especially in 2., I'm afraid I can't agree that those clarifications are there, just hidden between words. There are very little words in 2. in the article. As to 3.2 & 3.3, I don't really get the clarifications unfortunately; I think it shows even more that I don't really have knowledge of Unity, so I'm starting to think maybe that wasn't really an article for me to start with. Thanks for the interesting and insightful discussion!
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!
"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.
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.
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.
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).
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.
113 comments
[ 2.7 ms ] story [ 187 ms ] threadIn 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?)
https://youtu.be/DEumkKjE2YQ?t=8m15s
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.
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.
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.
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.
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.
You last sentence tells me you have never used a QT app on a Mac, because it does not look and feel native.
I still prefer it over any other free IRC client for OSX simply because the feature set rocks.
Precisely because users (at least iOS and Mac users) do care.
Doing native is without a doubt the right call.
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.
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.
https://developer.ubuntu.com/en/apps/
The "out of place" argument is one I commonly used by Mac and Linux users because they want everything to look native in their OS of choice and disregard dev time (to use a different window framework for each OS) and look in every other OS.
No one can win that argument to favor THEIR own OS look over another.
Qt apps are pretty reliable across platforms and are speedy to develop so that's what should be important instead of getting an impossible native look.
Besides, the whole "wasted effort because there's 2 projects that 2 similar things" is a fallacy.
As a Qt developer let me give you a big resounding no and ask you a question: Have YOU developed with Gtk in Windows?
We chose GTK over QT for Linux because Unity 5.1 ships with CEF (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework) as the embedded browser and CEF already pulls in a dependency on GTK).
(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.)
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/
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).
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
Mono changed the license so that it could be used in Unity to begin with. Mono was available under a copyleft license. To everyone. Including Unity. Unity couldn't/wouldn't accept it under those terms, so folks at now-Xamarin said, "We'll offer it to you under a commercial license if you won't take the copyleft offering." That's standard fare. Unity said, "Okay, deal." Mono continued to improve over the years. Unity was interested in those improvements. Mono said, "Okay. You can get those under a commercial license, too." Unity balked.
So what we're really talking about is that Unity wants the improvements that have been made to Mono, but doesn't want to pay for them.
Get this: They're still free at any point to accept Mono under the copyleft license that's available to literally everyone, but they won't accept it under any terms other than their own. That's it.
Do you know the specific licensing terms that Xamarin offered to Unity? Probably none of us here do. Given that, why would you assume Unity was the unreasonable party, and not Xamarin?
Regarding the copyleft license, while it is an option for everyone in general, it isn't an option for Unity, which needs to ship on platforms that do not allow such licenses (iOS, game consoles). Products like Unity will always need a commercial license as long as such platforms exist.
I don't know what this means. What we know of the situation is that Unity doesn't want to pay a commercial license for Mono. This is even the way that pro-Unity/anti-Mono folks frame the situation. What do you have in mind here?
> Regarding the copyleft license, while it is an option for everyone in general, it isn't an option for Unity
That's all well and good, but it doesn't have much to with any obligations Mono has. Those are completely synthetic restrictions that the platform vendors are placing on the people targeting them. How does Mono get the blame for Apple and Nintendo's choices here? Why do Apple and Nintendo get treated as bedrock? Even so, that's bedrock that Unity knows they're working with. It's their choice to target those platforms.
EDIT:
> That seems like a very unfair description of the situation.
Unfair. Every reference to the Unity/Mono relationhip I've ever come across has been from someone who heard Unity's creative retelling of the conflict and parroted it exactly, down to overtly identifying Mono as the bad guy.
We just don't know the answer, and you're assuming the party offering X and Y is reasonable. But it might not be. We don't know.
edit to your edit: if you heard people on the internet being wrong in some way, that doesn't justify you being wrong in the opposite way.
Companies A and B couldn't come to agreement to license something under terms Y that include $X in payment. Okay. There's neutrality in that statement. My comment says that (and no more).
What let's not do is say, "That makes company B a bunch of jerks." That is what the comment I'm responding to does, and it exists in a sea of others with the same tack.
Overton window and that.
> So what we're really talking about is that Unity wants the improvements that have been made to Mono, but doesn't want to pay for them.
which paints Unity as the bad guy, when for all we know, it might not be. Perhaps Unity is totally OK with paying for a license, but the Xamarin terms would have bankrupted it.
But thank you for clarifying what you meant. I agree there is no point in saying either party is the bad guy, since there is not enough public information to know.
In what way at all? Entity A doesn't want to pay entity B $X. That's the only thing the comment of mine that you quote says.
There are shops around that sell quadcopters for hundreds of dollars. I want a quadcopter. I don't want to pay hundreds of dollars. Have I just painted myself as a bad guy?
I repeat: the only reason my comment sounds pro-Mono is because, at neutral, it resists the spin of the one that paints Unity as a victim and Mono as a fiend.
In particular, it sounds like Y is offering Z at a standard rate, as in "Sam wants a Chipotle burrito, but doesn't want to pay Chipotle for the burrito." Sam doesn't look good here - does Sam expect to get the burrito for free? Why does Sam think he is entitled to that?
Readers may not realize that there isn't a standard, objective rate for commercial licenses for Mono. Especially for the single biggest consumer of Mono, Unity, which uses it in products that its customers ship - a particularly complex situation.
Again, maybe you didn't intend to, but it sounded like you were saying something very negative about Unity. A less biased way to say it might be
"Unity and Mono could not arrive at mutually acceptable terms for Unity to license newer versions of Mono."
What we also don't know are the terms for the first negotiation. It's as possible that Mono made one offer and Unity countered with an insultingly lower one, then Mono accepted due to being a poor position to negotiate something "reasonable", but are no longer in a position to have to accept whatever is offered, now that Xamarin is off and running.
We don't know. Hypotheses non fingo.
AOT-compiled code can also be very fast. I'm aware .NET has options there too, but il2cpp is literally focused on doing just that, and doing it very well.
The same people who couldn't maintain their fork of Unity are now writing their own home-grown runtime, complete with their own garbage collector.
I don't see a chance of this working out "well" for any sane or bizarre notion of "well".
The same people who couldn't maintain their fork of Unity are now writing their own home-grown runtime, complete with their own garbage collector.
I don't see a chance of this working out "well" for any sane or bizarre notion of "well".
(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.
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.
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.
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 (see table titled "English vs. Turkish Case Mappings") (this is just the first example I could find with a quick search)
I stand by what I said for ASCII, but in a Unicode world, I think you're right. When the mapping stops being simple, the principle of least surprise reverses in the favor of case sensitivity.
Indeed; if everything were case-sensitive, or case-insensitive, we definitely wouldn't have these problems. But alas, it's not, and in 2015 here we are still having problems with case sensitivity. :-P
> 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.
I also personally prefer it ('a' and 'A' are not the same character!!!!), but I'm not sure if thats because it's inherently 'right' or because I'm used to Linux where case sensitivity is more or less a given. :-)
Problem is that this goes back a long ways, e.g. back to the days of 36 bit computers.
Why 36 bits? Because that was just enough to encode 10 decimal digits, the standard back then for scientific computation.
Back then as in the days before core memory was used, so not much main memory either, and it was still expensive and painful after core was developed. So with that limited a budget, 6 bit character systems were common, that's enough to get things done and you can fit 6 in a word. One reason mainline Lisp doesn't use '?' in function names, why old languages like it and FORTRAN are or were case insensitive.
"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.
> 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.
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.
While generally it's also true the other way around (if something is made for Ubuntu, it's likely it will work on Debian without big issues), it would be nice for companies to recognize Ubuntu's roots and make the support official.
Of course in practice the community will quickly report back to you something like "hey, change your dependency to include libjpeg-turbo8 or libturbojpeg0, in Debian there's no libjpeg-turbo8" (real example from early Steam package), however, maybe it's just me, but when I see something having official support for Ubuntu only it sounds like "we were too lazy to give it a try on other distros", while explicitly stating support for Debian-based distributions starts sounding much more professional :)
That said, the reason why they support Ubuntu is that it provides static targets. 12.04 will be supported until late 2017, which means that they users two years from now can install a .deb built today. Likewise, supporting 14.04 means .deb packages will work until late 2019. Especially for companies that want to develop on Linux, there's a huge benefit in first-party support from your vendor for the next four years.
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.
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>
The author is a lady.
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.
#else #error #endif
If you work this way, you immediately know where to change your code.
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. :-)
This 2001 page has some possible reasons. (Much simpler; some benefits).
http://xahlee.info/UnixResource_dir/_/fileCaseSens.html
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.
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.
The editor is, however, largely written in Unity (uses the same APIs, etc, in addition to a bunch of private ones).
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.