The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
True — but why would I want Blender's UI in, let's say, VirtualBox environment? My point was: Unity is a huge company, earning a lot, they do not need to depend so much on these free and open source tools. Or at least, they can start investing some and making these UI better.
Microsoft is coming up with XAML Standard. That is set to solve these resource problems, but I cannot say anything for certain.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Oh wait, everywhere else you use a text editor type thing, even WPF on windoze (so many years old) doesn't have a GUI designer, even building a vs2017 distribution is lines of text - so microsoft are barely keeping their nose in the GUI game either.
anyhoo vs vs. unity: not really a fair comparison.
It's nice to see a well designed UI, particularly when there's a lot of information to display but you want to minimize the space a dialog takes up because it covers important other stuff, and it also needs to convey the usage of said dialog in a manner that someone with domain knowledge (or even not) can easily understand what is going on and how to use it.
Unlike most dialogs I've seen, that have excessive white space, excessive font sizes, excessive button sizes, like the designer was trying to compensate for something.
My quantum physics is a little rusty (he said, keeping a perfectly straight face...) but isn't that wrong? Because he doesn't observe Christmas it CAN have a definite date - and contrarily, if he DID observe Christmas, then it could not. No?
Because he doesn't observe Christmas it CAN have a definite date - and contrarily, if he DID observe Christmas, then it could not.
Exactly vice versa.
The Copenhagen interpretation of QM implies that until a wave function collapses, the state of a particle is indeterminate (== the date of Christmas is unknown). Only after it collapses (i.e. the particle is observed), will the particle be in a determined state (== the date of Christmas is known).
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
So after spending the better part of my Sunday and a good bit of time today trying to get nUnit tests working in a VS2015 .NET Core (netstandard1.6) class library, I gave up and installed VS2017. Took maybe 5 minutes to move code over and everything works fine
Now I'm wondering why it wouldn't work in VS2015 considering it's the same NuGet packages - Microsoft.NET.Test.Sdk 15.5, nUnit 3.9, and nUnit3TestAdapter 3.9. Anyone have a similar issue and find out the cause? I'm just curious at this point. It wouldn't even recognize the tests in VS2015
Everything works in VS2017 just fine but for some reason wouldn't in VS2015. Same runner which supposedly should work for VS2012 and up (nUnit3TestAdapter 3.9) according to its documentation. So I'm just left scratching my head on what was going wrong in VS2015
Unless I'm missing something that is an extension for the nUnit engine/GUI to load VS projects. I was testing inside VS itself with the Test SDK and nUnit3TestAdapter.
I tried a few older versions of the NuGet packages in case something broke when they added the csproj support since VS2015 .NET Core class libraries still use the project.json format but had the same results. Oh well, as good an excuse as any to finally move over to VS2017 for personal projects