CONSTRAINT(3)

πŸ“¦
version 2.5.2 Β· 2 versions
, in alpine 3.24, arch rolling, centos-stream 9, epel 10, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0

✨ Constraint β€” the Constraint widget class ✨

okay bestie, welcome to the Constraint manual page (library call, iykyk) β€” part 1 of this lil saga, so don't go anywhere, there's more coming πŸ’–


🌸 NAME 🌸

Constraint β€” the Constraint widget class, periodt πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <Xm/Xm.h>

πŸ’… DESCRIPTION πŸ’…

okay so Constraint widgets are the ones that keep extra state data for every single child. like, for example, a client can define its own constraints on a child's geometry. it's giving very much "custom rules per baby widget" ✨

when a constrained composite widget defines constraint resources, all of that widget's children inherit all of those resources as their own. and you set them and read them <em>exactly</em> the same way you'd set and read any other resource defined for the child. no special treatment, no secret handshake 🫢

but here's the tea: this resource inheritance goes exactly one generation down. which means only the first-generation children of a constrained composite widget inherit the parent widget's constraint resources. grandchildren? not invited. sorry not sorry πŸ™ˆ

and because constraint resources are defined by the parent widgets and not the children, the child widgets never directly use the constraint resource data. instead, the parents use that constraint resource data to attach child-specific data onto the children. main character energy is the parent, fr fr πŸ’…


πŸŽ€ Classes πŸŽ€

Constraint inherits behavior and resources from Composite and Core. it's giving legacy lineage πŸ‘‘

the class pointer is constraintWidgetClass.

the class name is Constraint.


⭐ New Resources ⭐

Constraint defines no new resources. literally zero. none. a whole lotta nothing, bestie πŸ’€ (but the inherited ones? those are the moment.)


🌈 Inherited Resources 🌈

Constraint inherits behavior and resources from Composite and Core. the following table defines a set of widget resources used by the programmer to specify data πŸ‘©β€πŸ’»βœ¨

the programmer can also set the resource values for the inherited classes to set attributes for this widget. yes, you have range, slay πŸ’…

to reference a resource by name or by class in a .Xdefaults file, remove the XmN or XmC prefix and use the remaining letters. bye prefix, you won't be missed πŸŽ€

to specify one of the defined values for a resource in a .Xdefaults file, remove the Xm prefix and use the remaining letters β€” in either lowercase or uppercase, but include any underscores between words. don't be forgetting those underscores, bestie, they matter 😭

the codes in the access column indicate if the given resource can be:

  • set at creation time (C) ✨
  • set by using XtSetValues (S) πŸ’–
  • retrieved by using XtGetValues (G) 🫢
  • or is not applicable (N/A) πŸ’€
that's the whole vibe check for part 1, bestie β€” the rest is coming, don't you dare close the terminal 🌸

πŸ’… CORE RESOURCE SET πŸ’…

okay bestie, here's the whole core resource set for Constraint β€” every single one, no skipping, no cherry-picking. For each one you get the name, the class, the type, the default, and the access. That's the whole lineup, in order, and I am not dropping any of them. πŸ‘‘

  • XmNaccelerators β€” class XmCAccelerators, type XtAccelerators, default dynamic, access CSG
  • XmNancestorSensitive β€” class XmCSensitive, type Boolean, default dynamic, access G
  • XmNbackground β€” class XmCBackground, type Pixel, default dynamic, access CSG
  • XmNbackgroundPixmap β€” class XmCPixmap, type Pixmap, default XmUNSPECIFIED_PIXMAP, access CSG
  • XmNborderColor β€” class XmCBorderColor, type Pixel, default XtDefaultForeground, access CSG
  • XmNborderPixmap β€” class XmCPixmap, type Pixmap, default XmUNSPECIFIED_PIXMAP, access CSG
  • XmNborderWidth β€” class XmCBorderWidth, type Dimension, default 1, access CSG
  • XmNcolormap β€” class XmCColormap, type Colormap, default dynamic, access CG
  • XmNdepth β€” class XmCDepth, type int, default dynamic, access CG
  • XmNdestroyCallback β€” class XmCCallback, type XtCallbackList, default NULL, access C
  • XmNheight β€” class XmCHeight, type Dimension, default dynamic, access CSG
  • XmNinitialResourcesPersistent β€” class XmCInitialResourcesPersistent, type Boolean, default True, access C
  • XmNmappedWhenManaged β€” class XmCMappedWhenManaged, type Boolean, default True, access CSG
  • XmNscreen β€” class XmCScreen, type Screen *, default dynamic, access CG
  • XmNsensitive β€” class XmCSensitive, type Boolean, default True, access CSG
  • XmNtranslations β€” class XmCTranslations, type XtTranslations, default dynamic, access CSG
  • XmNwidth β€” class XmCWidth, type Dimension, default dynamic, access CSG
  • XmNx β€” class XmCPosition, type Position, default 0, access CSG
  • XmNy β€” class XmCPosition, type Position, default 0, access CSG
ngl, <rainbow>dynamic</rainbow> shows up a lot here. That's not me being lazy, that's just literally what the table says. πŸ™ˆ

✨ Translations ✨

There are no translations for Constraint.

That's it. That's the whole section. Nothing. Zero. Empty. It's giving "ghosted by the translation table" energy. πŸ’€


Composite(3) and Core(3).

go read those too bestie, they're the family this one lives in 🫢

and that's the whole page, fr fr πŸ’– this was Constraint(library call) β€” a library call, iconic behaviour only β€” and if you're wondering about the version and date, they live down there in the footer where footers always are, doing their little metadata moment. slay. πŸ‘‘βœ¨