4 ms·

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 nev

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.
- peatmoss 8y ago
  Yes! This is a great list. It could almost serve as a partial roadmap for endeavors like NEXTSPACE.
- trunkmaster 8y ago
  Interesting wish list. Some items are quite easy to implement, some require more developer hands. I think after the 1.0 release there will be some distinct shape of the desktop environment and style guide/project plan. We can discuss it then. If you are ready to take some feature to implement - we can join our efforts.
trunkmaster 8y ago
I've spend some time to make keyboard shortcuts consistent across applications and window manager part. My thoughts partly described here https://github.com/trunkmaster/nextspace/wiki/Keyboard https://github.com/trunkmaster/nextspace/wiki/Keyboard. I hope this document help you answer to your question.
itomato 8y ago
Nextspace seems simply to be two existing projects (with patches) packaged specifically for Red Hat Linux; GNUstep and WindowMaker. 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).
- trunkmaster 8y ago
  Let me clarify some things a bit. GNUstep is a libraries and set of tools for development: Makefile environment (gnustep-make), Gorm (Interface Builder) and ProjectCenter (Project Builder). NEXTSPACE's Workspace was written from scratch and has no any connection to GWorkspace. Workspace and WindowMaker is one application (binary) - it is not "repackaged GNUstep and WindowMaker". Patches for WindowMaker was a quite challenging part of Workspace development process. WindowMaker injected into Workspace minimally uses WINGs.

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.

peatmoss 8y ago
Yes! This is a great list. It could almost serve as a partial roadmap for endeavors like NEXTSPACE.
trunkmaster 8y ago
Interesting wish list. Some items are quite easy to implement, some require more developer hands. I think after the 1.0 release there will be some distinct shape of the desktop environment and style guide/project plan. We can discuss it then. If you are ready to take some feature to implement - we can join our efforts.

trunkmaster 8y ago

I've spend some time to make keyboard shortcuts consistent across applications and window manager part. My thoughts partly described here https://github.com/trunkmaster/nextspace/wiki/Keyboard https://github.com/trunkmaster/nextspace/wiki/Keyboard. I hope this document help you answer to your question.

itomato 8y ago

Nextspace seems simply to be two existing projects (with patches) packaged specifically for Red Hat Linux; GNUstep and WindowMaker. 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).

trunkmaster 8y ago
Let me clarify some things a bit. GNUstep is a libraries and set of tools for development: Makefile environment (gnustep-make), Gorm (Interface Builder) and ProjectCenter (Project Builder). NEXTSPACE's Workspace was written from scratch and has no any connection to GWorkspace. Workspace and WindowMaker is one application (binary) - it is not "repackaged GNUstep and WindowMaker". Patches for WindowMaker was a quite challenging part of Workspace development process. WindowMaker injected into Workspace minimally uses WINGs.