Using Windows for a Day Cost Mac User $100,000 (and it's not related to anything else totally)
-
Now if they'd just provide that for desktop Windows instead of restricting it to Terminal Servers...
You forgot about a shitload of redundant licensing requirements.
-
"looks like a Windows app"
What type of Windows app? WinForms? WPF?MetroModern UI?
And then there's the fact that, thanks to XAML's template-based UI definitions, WPF and metro can be made to look very different from the 'norm'.The fact is, no matter the OS, there's always software that doesn't blend in with 'native'. And that's assuming there's a single 'native' in the first place.
-
I wonder at this point if his definition of "native" is really "looks like a Windows app".
-
The fact is, no matter the OS, there's always software that doesn't blend in with 'native'.
Right; and that software is buggy.
I don't even get why you people are going back and forth on this. What exactly is the debate here?
Linux has no concept of "native UI", right, because it's a buggy piece of shit, remember? Buggy? Piece of shit? That's what Linux is? So what's the back-and-forth?
-
Linux has no concept of "native UI", right, because it's a buggy piece of shit, remember? Buggy? Piece of shit? That's what Linux is? So what's the back-and-forth?
How much practice does it take to be this much of a reprehensible asshole?
-
I just give the people what they want.
-
Linux has no concept of "native UI", right, because it's a buggy piece of shit, remember? Buggy? Piece of shit? That's what Linux is? So what's the back-and-forth?
Have you ever considered the thought that the bright sparks at MIT who originally designed the X Window System decided purposefully not to bake in the policy decisions about how things should look and feel, because they had this thought that "hey, the GUI of 30 years from now might not look like the GUI of today?"
Seriously: have you seen a Motif-based UI? Because that was the level of sophistication of the toolkits available in the early days of the X Window System...
-
That is… not even close to my point, which is that even Windows doesn't have a single definition of 'native'; it has three: WinForms, WPF, and
MetroModern UI. But if you go with the idea that there's only one possible 'native' UI, which of those three is the real 'native'?From the end-user point-of-view, what's the difference between a mix of WinForms, WPF, and
MetroModern UI, and a mix of GTK+ and Qt?
-
How much practice does it take to be this much of a reprehensible asshole?
http://en.wikipedia.org/wiki/Outliers_(book)
Gladwell repeatedly mentions the "10,000-Hour Rule", claiming that the key to achieving world class expertise in any skill, is, to a large extent, a matter of practicing the correct way, for a total of around 10,000 hours.
10,000 hours seems low in this case.
~16 waking hours in a day x 396.24 days in a year x (How old are you @blakeyrat?) = how much time you have spent practicing this particular skill.
-
That is… not even close to my point, which is that even Windows doesn't have a single definition of 'native'; it has three: WinForms, WPF, and MetroModern UI.
Right?
Windows is buggy, too. I never said otherwise; other people put words in my mouth.
-
What exactly is the debate here?
In what ways, exactly, is @blakeyrat wrong this time?
-
Linux has no concept of "native UI", right, because it's a buggy piece of shit, remember? Buggy? Piece of shit? That's what Linux is? So what's the back-and-forth?
Here's the thing, just because it is different, does not mean that it is a bug. You can consider it a bug if you wish, that is your prerogative. That doesn't mean it is correct though.
-
I don't think it being "different" is the issue. It's the inconsistency that is the bug. A "fix" would be a library on top of the toolkit that abstracts which toolkit is under the hood away, so you can write your UI code once, and have it look native in each desktop manager, instead of carrying the desktop manager's theme you developped for with you into every desktop environment. Assuming I'm understanding the issues here.
-
I don't think it being "different" is the issue. It's the inconsistency that is the bug.
This is a distinction without a difference, IMO.
A "fix" would be a library on top of the toolkit that abstracts which toolkit is under the hood away, so you can write your UI code once, and have it look native in each desktop manager, instead of carrying the desktop manager's theme you developped for with you into every desktop environment. Assuming I'm understanding the issues here.
Yes, I suspect this is the sort of thing @blakeyrat is thinking of. It doesn't make him any more likely to be viewed as correct by other people, though.
-
This is a distinction without a difference, IMO.
Eh, depends on how you read Polygeekery's post I was replying to. I interpreted it as him saying that it is not a bug to be "different" to Windows. So I meant to say that while being different to Windows is not a bug, being different to yourself is. Meaning, do whatever you want, but be predictable and consistent in how you do it.
-
I would say "native" isn't even well-defined in the Linux world.
I assume that would be Athena toolkit look or something similar.
-
-
Seriously -- X11 was designed in a toolkit-agnostic manner -- it provides the mechanisms for people to put GUIs up on the screen, but delegates policy -- what those GUIs should look like and how they should behave -- to other components of the system -- the GUI toolkit establishes the nature of widgets, while the window manager controls windowing policy.
To take a side between you and Blakey, I don't see why that's particularly relevant. That just moves around whose fault you consider the "bug."Put it this way: suppose an app running on Windows (where there is a native file picker) doesn't use the native picker and puts up a crappy imitation that doesn't work right. It's... pretty reasonable to consider that a bug; if not that strong, it's at least being somewhat poorly behaved or not as good as one would like.
Now, take the Linux situation: you have two apps, A and B, where A is a Qt app and B a GTK one. They put up different file pickers. In the same way that the poorly-behaved Windows program is poorly behaved, you could pretty easily argue that one of:
- A is poorly behaved
- B is poorly behaved
- The windowing system is poorly behaved (for not giving you a high-quality native file picker)
"has" to be true.
Now, it's a bit less clear, and while I would consider the poorly-behaved Windows program to be "buggy" I think that is too strong of a word in the Linux scenario. In addition, the Linux way of doing things does have some benefits. But I think it is pretty clearly a drawback that you get inconsistencies like that.
-
suppose an app running on Windows (where there is a native file picker)
Two if you're running Windows 8+; Modern UI has its own picker
-
Have you ever considered the thought that the bright sparks at MIT who originally designed the X Window System decided purposefully not to bake in the policy decisions about how things should look and feel, because they had this thought that "hey, the GUI of 30 years from now might not look like the GUI of today?"
To play Devil's Advocate for a minute...Seriously: have you seen a Motif-based UI? Because that was the level of sophistication of the toolkits available in the early days of the X Window System...
And yet, somehow Windows programs designed decades ago somehow manage to pick up many of the stylings that were added more recently. The inability to achieve perfection doesn't mean you shoudn't try.
-
And yet, somehow Windows programs designed decades ago somehow manage to pick up many of the stylings that were added more recently.
Only if they link to Common Controls correctly and provide a suitable manifest
-
-
What planet did you say you were on?
The one that has people who fat finger stuff?
-
And yet, somehow Windows programs designed decades ago somehow manage to pick up many of the stylings that were added more recently. The inability to achieve perfection doesn't mean you shoudn't try.
That's because these were styling changes alone -- I suspect the shift from Motif to GTK+ or Qt wouldn't have been nearly as seamless from an API perspective (different API philosophies, if nothing else)
Now, it's a bit less clear, and while I would consider the poorly-behaved Windows program to be "buggy" I think that is too strong of a word in the Linux scenario. In addition, the Linux way of doing things does have some benefits. But I think it is pretty clearly a drawback that you get inconsistencies like that.
It is a drawback in the sense that there's not One True Way...but you could say that the notion of One True Way isn't consistent with the system X11 was made to run on, for that matter ;)
-
Two if you're running Windows 8+; Modern UI has its own picker
I don't think I agree. Your own words suggest to me that in any given situation there is only one appropriate native file picker.
Filed under: Still on Windows 7, and linux
-
Seriously: have you seen a Motif-based UI?
I assume that would be Athena toolkit look or something similar.
The original UI toolkit was Athena. It was abysmal. Really awful. It was also butt-ugly, but the really awful bit was in the focus handling and the UI design; Athena-based programs did things so awfully that you would lose work by sheer unusability. (I have used an Athena-based desktop, and will not go back to that!)
Motif was much nicer to use, by orders of magnitude, enough that you could use it in production without wanting to send out for a thousand rabid attack dogs to put the original developers out of your misery. I used a Motif desktop for a few years on Solaris and IRIX, and it was more than competitive with the Windows systems of the time.
We've moved on from then; we can do pretty nice GUIs and we can do them easily. We can even do them in a cross-platform manner so that applications can be ported to whichever platform customers actually want to use, which is not trivial; different platforms continue to be pretty fundamentally different in ways that can't be hidden from the application level (e.g., different modalities of standard dialogs; you can't insulate high-level code from that!)
-
I don't think I agree. Your own words suggest to me that in any given situation there is only one appropriate native file picker.
as an application developer that is correct. in fact you cannot even access the wrong one from your context (Metro app can't use a desktop file picker and visa versa)
however from the user perspective they are two very different file pickers that behave very differently and have different rules.
For example at the launch of 8 you could not create a folder using the Metro file picker, you had to choose an existing folder. that was fixed in 8.1 somewhat.... so long as you don't want to nest folders too deeply (more than one folder from the root library, that was later patched up to IIRC 8 folders deep (which does cover most use cases, but not all and certainly not as many as the desktop one with the ability to make folders arbitrarily deep))
-
root library
No access to the full filesystem?
Filed under: Took a while to find an appropriate smiley, Not sure if I succeeded
-
No access to the full filesystem?
no, you get access to that. it appears as a library like documents/pictures/downloads/etc. and the same rules apply to it for folder nesting, despite the aforementioned libraries being subdirectories of (by default)
C:\
-
That just moves around whose fault you consider the "bug."
If a bug doesn't exist, whose fault is that?
-
I don't think I agree. Your own words suggest to me that in any given situation there is only one appropriate native file picker.
Right, but we're debating @blakeyrat here, who has said that there must be One True Way or it's a bug. The context is important here. We told @blakeyrat that there were multiple native file pickers in *nix DEs, so using the appropriate file picker is appropriate, but @blakeyrat says no.
-
Right, but we're debating @blakeyrat here, who has said that there must be One True Way or it's a bug.
So what's the One True File Selection Dialog on Windows 8? The standard one or the Metro one?
-
-
-
So what's the One True File Selection Dialog on Windows 8? The standard one or the Metro one?
DID I EVER CLAIM THAT WINDOWS DOESN'T HAVE BUGS‽ CHRIST WHAT IS WRONG WITH YOU PEOPLE.
-
The fact is, no matter the OS, there's always software that doesn't blend in with 'native'.
And (Mac) designers that insist on violating all sorts of native win32 app design styles. We (devs) push back as much as we can...
-
it has three: WinForms, WPF, and
MetroModern UI.Four. You forgot win32-api. The old "native".
-
-
Which is what WinForms uses
Didn't realize that. Never used them :) Or any .net framework.
-
Thought I'd mention this: one application I use at work allows you to select your preferred UI style.
Mind you, it only looks good in one of them (it looks like the command buttons don't adapt their background colour properly).
Here's the same menu selection when Motif is applied:
-
Here's the same menu selection when Motif is applied:
Motif really did look like that. Except the background colour was usually set to something a bit different. (I'm not surprised that Sun managed to get that one right; they were big users of Motif on their desktop workstations.)
-
No NapkinLAF? No GTK LAF? I am deeply saddened...
-
Thought I'd mention this: one application I use at work allows you to select your preferred UI style.
Guess you have to remember what you picked. Because radio button style menus are hard.
-
Motif really did look like that.
I'm well aware, having used it for several years as a honours student and postgrad at university (and from time to time for a couple of years afterwards in my job of the time). It was a nice bit of nostalgia to see it again — briefly.
-
It was a nice bit of nostalgia to see it again
Not really. But at least it wasn't Athena!
I've only ever encountered one truly good application written using Athena, and that was xfig. The author(s) of that did a good job and made something that was more usable for figure drawing than most of the things I've used since. And yes, I'm including Office, Visio and OmniGraffle in that long list of things that aren't as good. (I've seen many people look at it and think “I can do better than that” and indeed, they can put prettier buttons on it. But actually beating it on long-term usability — on making it so you can put a figure together fast — is really difficult.) It might looked like ass, but it worked ever so well (and didn't have fucked up focus handling, the usual hyper-annoying problem with Athena-based programs).
-
@Scarlet_Manuka said:
It was a nice bit of nostalgia to see it again
Not really.
I didn't mean in this thread, I meant when I started using this software and saw the option and thought "cool, let's give the other styles a go and see what they look like". A few minutes was enough though.
-
At least it wasn't Xt, which was The. Most. Annoying. Object. System. Ever. And all written in C, for extra giggles.
-
This post is deleted!
