4 ms·

While I like the way NeXT looks too (“Lickable, like concrete!”), a lot of the comments are getting wrapped around the axle of skin deep appearances. What’s ex

While I like the way NeXT looks too (“Lickable, like concrete!”), a lot of the comments are getting wrapped around the axle of skin deep appearances. 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.

trunkmaster 8y ago
Exactly! Look at architecture (https://github.com/trunkmaster/nextspace/wiki/Architecture-and-design https://github.com/trunkmaster/nextspace/wiki/Architecture-a...). NEXTSPACE is a marriage of Linux quite mature technologies (D-Bus, PolKit, systemd) and OpenStep implementation frameworks (GNUstep) to create SPACE where NeXT or NeXT-like applications can live or reborn. Essential part of this is a UX (mature, consistent) with attention to any tiny piece of applications look and feel. That's what I though when started this project.
staticautomatic 8y ago
>Projects that chase skin-deep appearance of macOS are a dime a dozen. Cue the best fundraising pitch ever. https://m.youtube.com/watch?v=aEdrey6U5dU https://m.youtube.com/watch?v=aEdrey6U5dU
mediocrejoker 8y ago
As someone who is not familiar with OpenSTEP, what are the implications of a desktop built with it? 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?
- bunderbunder 8y ago
  I think a lot of that comes from the fact that OS X GUI developers can look to a single authoritative source for a fairly clear set of guidelines. 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/ https://xkcd.com/927/
  - peatmoss 8y ago
    I think it’s more than guidelines. I think it’s the APIs and tooling that provide a happy path for developers to build apps that conform. 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.
- derefr 8y ago
  I know that when I'm developing Linux desktop apps, there are a few things I miss from macOS that I think go back all the way to NextSTEP: • 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.

trunkmaster 8y ago

Exactly! Look at architecture (https://github.com/trunkmaster/nextspace/wiki/Architecture-and-design https://github.com/trunkmaster/nextspace/wiki/Architecture-a...). NEXTSPACE is a marriage of Linux quite mature technologies (D-Bus, PolKit, systemd) and OpenStep implementation frameworks (GNUstep) to create SPACE where NeXT or NeXT-like applications can live or reborn. Essential part of this is a UX (mature, consistent) with attention to any tiny piece of applications look and feel. That's what I though when started this project.

staticautomatic 8y ago

>Projects that chase skin-deep appearance of macOS are a dime a dozen. Cue the best fundraising pitch ever. https://m.youtube.com/watch?v=aEdrey6U5dU https://m.youtube.com/watch?v=aEdrey6U5dU

mediocrejoker 8y ago

As someone who is not familiar with OpenSTEP, what are the implications of a desktop built with it? 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?

bunderbunder 8y ago
I think a lot of that comes from the fact that OS X GUI developers can look to a single authoritative source for a fairly clear set of guidelines. 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/ https://xkcd.com/927/
- peatmoss 8y ago
  I think it’s more than guidelines. I think it’s the APIs and tooling that provide a happy path for developers to build apps that conform. 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.
derefr 8y ago
I know that when I'm developing Linux desktop apps, there are a few things I miss from macOS that I think go back all the way to NextSTEP: • 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.