4 ms·

Please do not slander OS X like that. I've been a happy OS X user since 2005. I look at GNOME 3/Unity and I vomit. Vigorously. If this was an attempt to be Mac

by nknight 15y ago

Please do not slander OS X like that. I've been a happy OS X user since 2005. I look at GNOME 3/Unity and I vomit. Vigorously. If this was an attempt to be Mac-like, then it was pure cargo-cult UI design. They clearly have no understanding of the actual design process. The last Linux desktop environment I was reasonably happy with was KDE 2.x. I tolerated 3.x.

morsch 15y ago
Please, a bit less hyperbole and more constructive criticism.
- nknight 15y ago
  Fine: > When a maximized window is behind an active non-maximized window, the panel serves as its title bar. But it actually spells out the name of the active window. Very confusing. This just doesn't happen in OS X that I've ever observed. It's in fundamental conflict with the OS X window management paradigm. > Additionally, in the same situation, all of they standard mouse gestures on the panel (e.g: double-click to unmaximize) do not work. Maximized windows don't get the right-click-title gesture to work at all. Again, this is just inapplicable to OS X. > No window list at a glance (useful for remembering your context/state with the UI) This is true for OS X, as far as it goes, but OS X UI practices seem to make it less of an issue than it would be on Windows or a typical Linux desktop environment. > Hides important buttons such as close window, as well as the menus, where non-power-users will not know to look. I'm not even sure what this one is about. It seems inapplicable to both Unity and OS X. > Panel unhide takes a relatively long time -- slowing down almost every interaction with the UI. Hiding off by default in OS X, quite fast to unhide. > Workspace switcher does not support window drag, unlike the gnome panel workspace applets. OS X supports this fully. > Workspace switcher requires multiple selections to switch to a window. Not true of OS X. > Alt-tab switches applications, not windows True of OS X. 8 properties total, 1 I can't make sense of, 2 that are more or less shared. If my post was hyperbole, the one I responded to claiming "many" of these were shared with OS X was, too.

by nknight 15y ago

morsch 15y ago

Please, a bit less hyperbole and more constructive criticism.

nknight 15y ago
Fine: > When a maximized window is behind an active non-maximized window, the panel serves as its title bar. But it actually spells out the name of the active window. Very confusing. This just doesn't happen in OS X that I've ever observed. It's in fundamental conflict with the OS X window management paradigm. > Additionally, in the same situation, all of they standard mouse gestures on the panel (e.g: double-click to unmaximize) do not work. Maximized windows don't get the right-click-title gesture to work at all. Again, this is just inapplicable to OS X. > No window list at a glance (useful for remembering your context/state with the UI) This is true for OS X, as far as it goes, but OS X UI practices seem to make it less of an issue than it would be on Windows or a typical Linux desktop environment. > Hides important buttons such as close window, as well as the menus, where non-power-users will not know to look. I'm not even sure what this one is about. It seems inapplicable to both Unity and OS X. > Panel unhide takes a relatively long time -- slowing down almost every interaction with the UI. Hiding off by default in OS X, quite fast to unhide. > Workspace switcher does not support window drag, unlike the gnome panel workspace applets. OS X supports this fully. > Workspace switcher requires multiple selections to switch to a window. Not true of OS X. > Alt-tab switches applications, not windows True of OS X. 8 properties total, 1 I can't make sense of, 2 that are more or less shared. If my post was hyperbole, the one I responded to claiming "many" of these were shared with OS X was, too.