Skip to content

Adding Gershwin filesystem layout and vars#62

Merged
rfm merged 2 commits intognustep:masterfrom
pkgdemon:feat/add-gershwin-layout
Feb 9, 2026
Merged

Adding Gershwin filesystem layout and vars#62
rfm merged 2 commits intognustep:masterfrom
pkgdemon:feat/add-gershwin-layout

Conversation

@pkgdemon
Copy link
Contributor

@pkgdemon pkgdemon commented Feb 2, 2026

Hi @rfm a while back we discussed with @gcasa about contributing a Gershwin filesystem layout in one of the GNUstep meetings, and it seemed acceptable. I had a PR open previously but realized it was not going to work for additional variables we wanted to add.

This PR adds:

  • The gershwin filesystem layout
  • New variables: GNUSTEP_UTILITIES, GNUSTEPCORE_SERVICES, GNUSTEP*_CORE_SERVICES_APPS across all domains

Would something like this be acceptable, or could we work out an easier way to introduce new variables via filesystemlayouts alone? Is this going to be too much? I couldn't find a way to do this without so far adding to everything shown in the PR, but please do let me know if there is a way to make this work touching less.

@pkgdemon pkgdemon requested a review from rfm as a code owner February 2, 2026 23:41
Copy link
Contributor

@rfm rfm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no problem with the basic filesystem layout stuff; seems fine to me.

Add review comment
Markdown input: edit mode selected.
Write
Preview

I'm not completely sure about the additional variables though (I think we may already have more than is ideal). It's not clear what the new variables are intended to be used for, so at the very least I think it would be good to add that documentation (it would be good to document existing ones too).

Have you considered that, when you add extra variables for installation locations in gnustep-make, you also need to add corresponding constants to NSPathUtilities in gnustep-base as well (one reason to be cautious about adding them)? The only reason I'm aware of for having extra variables is if you want/need things using them to be installed in some completely separate location rather than in a subdirectory. Otherwise it may be easier (and perhaps more managable) to simply defined/document a convention that utilities are in the 'Utilities' subdirectory of NSApplicationDirectory and that core services applications are in the 'Applications' subdirectory of NSCoreServicesDirectory, rather than adding GSUtilitiesDirectory and GSCoreServicesApplicationsDirectory to base.

That being said, I don't see any real problem, and indeed I think Apple added NSCoreServicesDirectory and we never fully implemented it, so adding that one at least seems like a good thing.

@pkgdemon pkgdemon force-pushed the feat/add-gershwin-layout branch 5 times, most recently from a7f49a5 to dcdc3ec Compare February 7, 2026 05:59
@pkgdemon pkgdemon force-pushed the feat/add-gershwin-layout branch from dcdc3ec to 0f4dca3 Compare February 7, 2026 06:02
@pkgdemon
Copy link
Contributor Author

pkgdemon commented Feb 7, 2026

Thank you @rfm I have pushed changes, hopefully this looks a lot better. Yes the purpose was to move certain things like WindowManager.app, Menu.app, LoginWindow.app out of /System/Applications but still have them work with openapp for convenience without a full path, to make nice GNUmakefiles, and to have these components install somewhere that feels familiar. Gershwin has a menu now which lists apps in all domains but we do not want WindowManager showing up there and so this also fixes that. I can confirm installing those things in CoreServices nicely via GNUmakefiles, running without fall paths works fine with my latest changes.

I was not aware additional changes were required to libs-base but I now do see that CoreServices is already here in libs-base where you mentioned?

https://github.com/gnustep/libs-base/blob/master/Source/NSPathUtilities.m#L2304
https://github.com/gnustep/libs-base/blob/master/Headers/Foundation/NSPathUtilities.h#L137

So with all of this I believe NSCoreServicesDirectory is complete now if I understand right?

@pkgdemon
Copy link
Contributor Author

pkgdemon commented Feb 7, 2026

Actually @rfm after looking over libs-base again I see it only includes NSSystemDomainMask would you prefer I make a follow up for libs-base to add the additional domains for NSCoreServicesDirectory, or remove the additional domains from this PR for NSCoreServicesDirectory? I could see it being useful for Gershwin to have for all domains, but let me know your thoughts when you can.

@rfm
Copy link
Contributor

rfm commented Feb 7, 2026

Please do add the missing domains. I would do it myself but am away from my computer this morning.

@pkgdemon
Copy link
Contributor Author

pkgdemon commented Feb 7, 2026

Please do add the missing domains. I would do it myself but am away from my computer this morning.

Done, PR created gnustep/libs-base#576

@rfm rfm merged commit 9d5b9da into gnustep:master Feb 9, 2026
@rfm
Copy link
Contributor

rfm commented Feb 10, 2026

Sorry, after I merged this pull I realised I'd made a mistake and had to revert it.

The problem was the ...CORE_SERVICES stuff. I had failed to notice that we already have variables for this using the _SERVICES suffix rather than a _CORE_SERVICES suffix.

Please could you regenerate the pull request using the existing variables. Sorry for the extra work.

@pkgdemon
Copy link
Contributor Author

Thanks @rfm no problem I will take a look, and make a new PR.

@pkgdemon
Copy link
Contributor Author

Hi @rfm it seems these existing vars will install to SERVICES not CORESERVICES.

GNUSTEP_SYSTEM_SERVICES            = $(GNUSTEP_SYSTEM_LIBRARY)/Services

I think that would be fine. Interesting enough it doesn't seem the path's work like CoreServices did. When things were installed in CoreServices I could still openapp Menu and it would work. Not sure why it doesn't work the same with Services? Perhaps missing things in NSPathUtilities?

Screenshot 2026-02-14 at 8 46 22 AM

@pkgdemon
Copy link
Contributor Author

I've been talking it through with @probonopd and I think we are liking the idea to use Services vs CoreServices anyway. I'll get the PR ready. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants