CORE(3)
β¨ Core β the Core widget class β¨
okay bestie, this is Core(library call), the literal blueprint of the whole widget world, and I'm gonna walk you through it π
πΈ SYNOPSIS πΈ
#include <Xm/Xm.h>
π DESCRIPTION π
okay so Core is the Xt Intrinsic base class for windowed widgets. like, if a widget has a window, Core is its ancestor. no cap.
and the Object and RectObj classes? those are the ones that give you support for windowless widgets. different vibe, still iconic. π¦
π Classes π
All widgets are built from Core. every single one. the way that literally everything descends from this? main character energy fr fr. π
- the class pointer is
widgetClass - the class name is
Core
π§ New Resources π§
so the table below defines a set of widget resources that you (the programmer, yes you, hi π«Ά) use to specify data. you can also set the resource values for the inherited classes to set attributes for this widget, so don't forget your ancestors.
here's the lil trick for .Xdefaults files, and it's giving cheat code:
- to reference a resource by name or by class in a
.Xdefaultsfile, remove theXmNorXmCprefix and use the remaining letters β¨ - to specify one of the defined values for a resource in a
.Xdefaultsfile, remove theXmprefix and use the remaining letters (in either lowercase or uppercase, but include any underscores between words) β οΈ
and the codes in the access column? they tell you exactly what you're allowed to do with each resource, and they mean:
Cβ it can be set at creation timeSβ it can be set by usingXtSetValuesGβ it can be retrieved by usingXtGetValuesN/Aβ not applicable, so don't even try it
π Core Resource Set π
XmNacceleratorsβ classXmCAccelerators, typeXtAccelerators, defaultdynamic, accessCSGπ«XmNancestorSensitiveβ classXmCSensitive, typeBoolean, defaultdynamic, accessGπ«XmNbackgroundβ classXmCBackground, typePixel, defaultdynamic, accessCSGπ«XmNbackgroundPixmapβ classXmCPixmap, typePixmap, defaultXmUNSPECIFIED_PIXMAP, accessCSGπ«XmNborderColorβ classXmCBorderColor, typePixel, defaultXtDefaultForeground, accessCSGπ«XmNborderPixmapβ classXmCPixmap, typePixmap, defaultXmUNSPECIFIED_PIXMAP, accessCSGπ«XmNborderWidthβ classXmCBorderWidth, typeDimension, default1, accessCSGπ«XmNcolormapβ classXmCColormap, typeColormap, defaultdynamic, accessCGπ«XmNdepthβ classXmCDepth, typeint, defaultdynamic, accessCGπ«XmNdestroyCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCπ«XmNheightβ classXmCHeight, typeDimension, defaultdynamic, accessCSGπ«XmNinitialResourcesPersistentβ classXmCInitialResourcesPersistent, typeBoolean, defaultTrue, accessCπ«XmNmappedWhenManagedβ classXmCMappedWhenManaged, typeBoolean, defaultTrue, accessCSGπ«XmNscreenβ classXmCScreen, typeScreen *, defaultdynamic, accessCGπ«XmNsensitiveβ classXmCSensitive, typeBoolean, defaultTrue, accessCSGπ«XmNtranslationsβ classXmCTranslations, typeXtTranslations, defaultdynamic, accessCSGπ«XmNwidthβ classXmCWidth, typeDimension, defaultdynamic, accessCSGπ«XmNxβ classXmCPosition, typePosition, default0, accessCSGπ«XmNyβ classXmCPosition, typePosition, default0, accessCSGπ«
okay that's the resource set, and there is so much more coming, part 2 is right there bestie, don't go anywhere π
XmNacceleratorsβ bestie this one holds a translation table that's bound with its actions in the context of one specific widget. Then you can install that whole accelerator table on some destination widget. β οΈ heads up tho: the default accelerators for any widget are always installed, no matter whether you specify this resource or not. Like, they're showing up regardless. periodt.XmNancestorSensitiveβ says whether the widget's immediate parent receives input events. If you wanna change this argument, useXtSetSensitiveso your data integrity stays intact (peepXmNsensitivefor the tea). For shells: default is copied from the parent'sXmNancestorSensitiveresource if there is a parent; if there isn't, it'sTrue. For other widgets: default is the bitwise AND of the parent'sXmNsensitiveandXmNancestorSensitiveresources. πXmNbackgroundβ the background color for the widget. that's it, that's the resource β¨XmNbackgroundPixmapβ a pixmap for tiling the background. The first tile gets placed at the upper left corner of the widget's window. πXmNborderColorβ the color of the border, given as a pixel value.XmNborderPixmapβ a pixmap used for tiling the border. First tile goes at the upper left corner of the border. π¦XmNborderWidthβ how wide the border is that surrounds the widget's window on all four sides, in pixels. A width of0(zero) means no border shows at all. π but fr fr, you should be using resources likeXmNshadowThicknessandXmNhighlightThicknessinstead ofXmNborderWidthto specify border widths. like, that's the move.XmNcolormapβ the colormap used for conversions to the typePixelfor this widget instance. When you change this resource, previously generated pixel values are not affected, but newly generated values live in the new colormap. For shells without parents, the default is the default colormap of the widget's screen. Otherwise, the default is copied from the parent.XmNdepthβ the number of bits that can be used for each pixel in the widget's window. π¨ Applications should not change or set this one β it's set by the Xt Intrinsics when the widget gets created. For shells without parents, the default is the default depth of the widget's screen. Otherwise, the default is copied from the parent.XmNdestroyCallbackβ a list of callbacks that gets called when the widget is destroyed. rip to that widget π«‘XmNheightβ the inside height (border not included) of the widget's window.XmNinitialResourcesPersistentβ whether resources are reference counted or not. If the value isTruewhen the widget is created, the resources referenced by the widget are not reference counted, no matter how the resource type converter is registered. If your app expects to destroy the widget and wants resources deallocated, specifyFalse. Default isTrue, which implies the assumption that the widget won't be destroyed during the life of the application. β¨XmNmappedWhenManagedβ if this is set toTrue, it maps the widget (aka makes it visible) as soon as it's both realized and managed. If it'sFalse, then the client is responsible for mapping and unmapping the widget. And if you flip it fromTruetoFalseafter the widget has been realized and managed, the widget gets unmapped. πXmNscreenβ the screen on which a widget instance resides. It's read only, so don't even try it. When the Toolkit is initialized, the top-level widget gets its default value from the default screen of the display. Otherwise, the default is copied from the parent.XmNsensitiveβ decides whether a widget receives input events. If a widget is sensitive, the Xt Intrinsics' Event Manager dispatches to it all keyboard, mouse button, motion, window enter/leave, and focus events. Insensitive widgets don't receive any of those. Use the functionXtSetSensitiveto change the sensitivity argument β and usingXtSetSensitiveis the whole point, because it makes sure that if a parent widget hasXmNsensitiveset toFalse, the ancestor-sensitive flag of all its children gets appropriately set. that's the queen bee energy right there πXmNtranslationsβ points to a translations list. A translations list is a list of events and actions that are to be performed when the events occur. β οΈ and again: the default translations for any widget will always be installed, no matter whether this resource is specified or not. they're not going anywhere bestie.XmNwidthβ the inside width (border not included) of the widget's window.XmNxβ the x-coordinate of the upper left outside corner of the widget's window. The value is relative to the upper left inside corner of the parent window.XmNyβ the y-coordinate of the upper left outside corner of the widget's window. The value is relative to the upper left inside corner of the parent window.
π§ Translations π§
There are no translations for Core. that's the whole section. nothing. zero. empty. a vibe check with no vibes π (iykyk)
π RELATED π
Object(3) and RectObj(3). go read those next, they're part of the family π«Ά
and that's the whole Core page bestie!! πΈβ¨ this one's from the Core(library call) collection β no date stamp on this one, just the source, so consider this your official sign-off: you ate that, now go build something iconic πππ
π¦ where this page comes from
- alpine 3.24: motif-doc 2.5.2-r0 Β· LGPL-2.1-or-later
- arch rolling: openmotif 2.3.8-4 Β· LGPL-2.1-or-later
- centos-stream 9: motif-devel 2.3.4-32.el9 Β· LGPLv2+
- centos-stream 9: motif-devel 2.3.4-32.el9 Β· LGPLv2+
- epel 10: motif-devel 2.3.8-2.el10_2 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-1.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-1.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-2.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-2.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: motif-devel 2.3.8-3.fc44 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: motif-devel 2.3.8-3.fc44 Β· LicenseRef-Callaway-LGPLv2+
- nixos 26.05: motif 2.3.8
- nixpkgs unstable: motif 2.3.8
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms