Amen! The UI in the screenshots looks very tasteful to me, and it's nice to see somebody not conflating “no-nonsense” with “ugly programmer art”.
Looking forward to giving this a try.
What’s exciting to me about this is that someone is chasing the notion of desktop environment built on OpenSTEP-compatible technology. Projects that chase skin-deep appearance of macOS are a dime a dozen.
What would be cool, is if all those developers who’ve written software for macOS could also target Linux and BSD without much trouble. And if disappointed macOS developers could still target macOS while running Linux/BSD day-to-day.
The Etoilé project doesn’t seem to have seen any love in some years, but imagine if they’d continued and Apple was forced to play catch up with some first-class bridges to new and exciting programming languages.
This project is exciting not because it looks good or bad, it’s exciting because it’s the seed of a not-skin-deep reimplementation of a desktop environment on top of GUI technologies whose consistency and viability have been bourne out spectacularly by NeXT and macOS.
There are many small things that I like about OS X that never seem to make it into the graphical re-skins. Things like coherence of applications "feel", as well as more tangible features such as consistent and global keyboard shortcuts in every app (ie. Cmd + , for preferences). The visual polish of OS X is the least important thing that makes it usable.
Do you think a project like Nextspace could be the foundation for a Linux desktop experience more on par with the consistency of OS X?
GNUstep's core libraries and build tools are behind Nextspace and Etoile, as well as the GWorkspace environment and the build ecosystem itself; Gorm and Project Center. Gorm is more or less equivalent to NeXT's Interface Builder and Project Center taking on the role of Project Builder (now known as Xcode).
GNUstep is still the foundation and still has parallels with Openstep and Cocoa. Interface consistency is derived from applications using those libraries and components (object relationships, services).
WindowMaker itself uses the WINGs (Wings is not GNUstep) library, which is not really used outside of wmaker and dock apps for it. AppKit and WINGs don't interoperate, which makes the choice of using wmaker for Nextspace questionable when GWorkspace implements window management using PDFKit and other libs, like a GNUstep application should.
Personally, I can't see how this project is any different from GNUstep and WindowMaker apart from a few personal touches (profile.d and .bashrc configuration changes and the like).
• app bundles, their automatic discovery by and registration with Launch Services, including file-type and URI-schema handler registration (modern addition: inhibited as long as the app-bundle is marked with a quarantine xattr)
• user Launch Agents
• the Keychain
• the guaranteed availability of mDNS, and the ability for apps or services to dynamically register Bonjour/mDNS services (which can then be exposed, or not, via Sharing preferences)
• a centralized system-level caching downloader (nsurlsessiond + nsurlstoraged)
• for that matter, the ability to distinguish "cache files" from other files in such a way that cache files can be purged system-wide in response to storage pressure, with some cache files having higher importance/lower priority than other, depending on their origin app + attributes
• the ~/Library directory, with subdirs for item type (so each type can have separate policies applied—e.g. back up ~/Library/Preferences but not ~/Library/Caches.) ~/.foo/ directories are broken; the XDG standard is closer, but there are no high-level Linux APIs for e.g. accessing preferences that will always use XDG_CONFIG_DIR.
• system and user shared-support directories like /Library/Dictionaries, /Library/Sounds, /Library/Voices, /Library/Widgets, etc; where, when there is an API to access e.g. system sounds, it'll automatically merge /Library/Sounds with ~/Library/Sounds and present that as the available sounds set.
• vendor-neutral system-API-supported user state-file storage dirs, e.g. ~/Library/Cookies, ~/Library/Calendars, ~/Library/Mail, etc. (These state-file dirs were originally supposed to allow interoperation of different user agents that want to sync the same content, e.g. multiple web browsers sharing the same cookie jar. Sadly, we don't see e.g. Chrome or Firefox supporting ~/Library/Cookies as their cookie jar.)
• the guaranteed availability of a Directory Services daemon (opendirectoryd), where a computer that hasn't joined a domain is running a stub Directory Services daemon that exposes virtual records based on local configuration files; and a system accounts API that is just the client interface to the Directory Services daemon.
• Locales being available at the system level, even for e.g. kernel logging
There are also a bunch of other things that I miss from macOS that aren't part of NextSTEP but would be worthy additions, too, like the transparent exposure of filesystem-level versioning as versioned NSData; or libdispatch and its daemon.
On the Linux/Unix side, Nextspace can (and, perhaps, should) publish their own guidelines. But, let's face it, it's going to work out like https://xkcd.com/927/
I feel that the UI design guidelines plus the developer APIs and tools are self reinforcing.
And yeah, I think NEXTSPACE, by virtue of at least attempting to answer, with software, more comprehensively the questions associated with building a desktop environment with an OpenSTEP implementation could result in a more consistent Mac-like environment. One that’s more Mac-like than a window dressing clone.
Cue the best fundraising pitch ever. https://m.youtube.com/watch?v=aEdrey6U5dU
nextspace: https://raw.githubusercontent.com/trunkmaster/nextspace/mast...
nextstep: https://upload.wikimedia.org/wikipedia/en/1/1d/NeXTSTEP_desk...
The nextspace screenshot shows apps and icons with very bright colors. Nowadays icons and apps tend to be colorful, and since they follow different color schemes, a collection of them has a high probability of clashing (e.g. the gray Gimp next to the orange Firefox.)
Nextstep could maintain a consistent aesthetic, I think, because: 1) there were not many apps available on it as there are now on nextspace, and 2) a single company, which had a notoriously style conscious CEO, produced these apps. Nowadays, apps are produced by different groups, with different tastes (let alone skills) in designs.
Nextspace faces the problem of maintaining the muted and clean style of nextstep, in a more diversified world. That's what I was reacting to.
https://en.wikipedia.org/wiki/Motif_(software)
Both Windows 3.1 and Amiga OS (Workbench) 2.0 copied the look in 1990.
The entire OS was so polished and stable. I don't think it has been surpassed yet. Maybe by OS X 10.6
Likewise. I only migrated to WXP because AoE3 required it… and it turned out to be terrible but there was no real way to downgrade.
So of course they remove classic from Windows 10 and force the issue.
I know I'm going to get a lot of reflexive disagreement on this point for unrelated "because Windows" reasons, but I think this is objectively true. The entire UI is just basic shapes and line drawings.
However, the first and perhaps only modern user interface feature I find lacking in the screenshot is font anti-aliasing. At a regular viewing distance of about three feet, I find the text much more difficult to read than the fonts rendered by Windows 10 elsewhere on my screen.
Enable a quality subpixel font rendering engine onto that tastefully minimal UI and I think you'd have something real nice.
Specifically, I've found through my own user testing that certain "fancy animations" are important to helping users build a correct mental model of the current workflow—taking them away makes the user take longer to learn the application. For example, the window-minimization animation on macOS: it shows you where to find the window you just minimized, by showing you the window "going into" the Dock rather than just disappearing. Or, for another example, disclosure indicators (triangle buttons), where in most modern app frameworks the results sort of "unfold" into place below the indicator, rather than just appearing. Having the results just flash into place, especially if it causes the document (and thus the scrollbar) to change size, tends to disorient the user.
Having as little useless decoration is commendable, but I'd advocate for user testing on mockup versions of the software that contain some minimal animation, vs. those that don't. (Don't trust the user's opinions on which is better; just watch which version they get used to faster. Basically, do the same thing that game developers do when testing interaction mechanics: find the optimal "communication path" between the user and the software.)