NSTextAlignment NSRightTextAlignment and NSCenterTextAlignment have different values from AppKit

[DTW-Thalion]

The NSTextAlignment constants in AppKit/NSText.h are ordered:

NSLeftTextAlignment      = 0
NSRightTextAlignment     = 1
NSCenterTextAlignment    = 2
NSJustifiedTextAlignment = 3
NSNaturalTextAlignment   = 4

AppKit uses NSTextAlignmentRight = 2 and NSTextAlignmentCenter = 1, i.e. Right and Center are swapped relative to GNUstep (Left, Justified and Natural agree).

Code that uses the symbolic names round-trips correctly, but the raw integer stored differs (for example -[NSText setAlignment: NSRightTextAlignment] yields 1 on GNUstep and 2 on AppKit). This affects keyed archives written by one and read by the other, and any code comparing raw alignment values.

Aligning the values with AppKit would be an ABI change (archives, and any code relying on the current numbers), so I have not sent a patch. Filing to check whether the project wants to align these (and, relatedly, NSFloatingWindowLevel which is 2 vs AppKit 3, and NSTabViewControllerTabStyleUnspecified which is 3 vs AppKit -1). @fredkiefer ?

Found while adding NSText/paragraph-alignment tests.

[DTW-Thalion]

I looked into what a renumber would actually touch, since the values end up in archives.

NSCell stores the alignment as a raw value in its keyed archive: -[NSCell encodeWithCoder:] does cFlags2 |= ([self alignment] << 26) and reads it back the same way. NSMutableParagraphStyle also encodes _alignment directly as an NSInteger. So an existing .gorm or document that saved a right-aligned cell (1) would decode as centered, and centered (2) as right, if the constants were renumbered. Anything already saved against the current values would flip right and center.

The modern names are swapped too, not only the deprecated ones. NSTextAlignmentRight is defined as NSRightTextAlignment (1) and NSTextAlignmentCenter as NSCenterTextAlignment (2), so code using the current names is off relative to AppKit as well.

The Source files that use the symbolic names stay correct across a renumber because they are recompiled together. The break is limited to persisted raw values and anything passed as an int over the wire. GSXib5KeyedUnarchiver has its own alignment handling for imported xibs (the mask.flags.alignment block), which would need to line up with whatever we pick.

NSFloatingWindowLevel (2 vs 3) is a runtime value that is not persisted the same way, so that one is low risk to change. NSTabViewControllerTabStyleUnspecified (3 vs -1) is on a newer class with little archive history.

Given that, the choices seem to be:

1. Renumber to match AppKit and accept that older archives flip right and center, possibly with a versioned decode for old nibs.
2. Keep the current values and translate at the keyed-archive boundary so cross-platform archives interoperate without changing existing GNUstep ones.
3. Leave it and document the difference.

Do you have a preference? I can prepare whichever one you want once the compatibility side is settled.

cc @fredkiefer

[fredkiefer]

I would suggest that we change the values all at once and break backwards compatibility. In places where we could adjust, as in none keyed archives, we increase the class version and add code to handle the old values. But for keyed coded archives we cannot decide whether one is an old one, or a new or even one from MacOS. Somebody will have to fix such archives one by one.

@gcasa is this OK with you? You already checked some of these cases in Gorm.

[DTW-Thalion]

#893 renumbers NSTextAlignment as agreed. NSParagraphStyle stores its alignment in an archive that is not keyed, so its class version goes to 4 and anything below that has right and centre swapped back on decode. NSCell stores the alignment in the NSCellFlags2 bits of a keyed archive, which is the break. One correction to what I wrote above: GSXib5KeyedUnarchiver reads "left", "center" and "right" from the xib and assigns the symbolic constants, so it needs no change.

Two corrections to the other constants I raised.

The window levels are not one value apart. On macOS 26 they read normal 0, floating 3, submenu 3, torn off menu 3, main menu 24, status 25, modal panel 8, pop up menu 101, screen saver 1000. GNUstep has floating 2, main menu 20, dock and status 21, and modal panel 100, so five differ. The order differs as well: a modal panel sits below the main menu and the status windows on macOS and above them here, so matching the values moves windows in front of and behind each other rather than only renumbering them. That needs its own decision.

NSTabViewControllerTabStyleUnspecified is -1 on macOS, and the other three are 0, 1 and 2 as here. NSTabViewControllerTabStyle is typed NSUInteger in GNUstep, so taking the -1 means the typedef becomes signed.