XMFILESELECTIONBOX(3)
π NAME π
XmFileSelectionBox β The FileSelectionBox widget class π
(hey bestie, this one lives in the library call section of the manual, so that's the whole vibe we're working with here)
β¨ SYNOPSIS β¨
#include <Xm/FileSB.h>
π¦ DESCRIPTION π¦
Okay so picture this: FileSelectionBox is the widget that literally walks through your directories, shows you the files and subdirectories chilling inside them, and then lets you pick a file. It's giving personal assistant energy. π
A FileSelectionBox has five main areas:
- A text input field for displaying and editing a directory mask used to select the files to be displayed
- An optional text input field for displaying and editing a filter mask used to select the files to be displayed.
- A scrollable list of filenames
- A scrollable list of subdirectories
- A text input field for displaying and editing a filename
- A group of PushButtons, labeled
OK,Filter,Cancel, andHelp. The layout direction of the buttons depends on theXmNlayoutDirectionresource.
(yes bestie, that's six bullets under a "five main areas" heading, iykyk, that's literally what the page says and we do not argue with the page π)
Additional children may be added to the FileSelectionBox after creation. FileSelectionBox inherits the layout functionality provided by SelectionBox for any additional children. To remove the list of filenames, the list of subdirectories, or both from the FileSelectionBox after creation, unmanage the appropriate widgets and their labels. The list and label widgets are obtained through a call to the XmFileSelectionBoxGetChild function. To remove either the directory list or the file list, unmanage the parent of the appropriate list widget and unmanage the corresponding label.
So the tea is: you can specify resources in a resource file for the automatically created widgets and gadgets of FileSelectionBox. Here's the list of the names of these widgets (or gadgets) and the FileSelectionBox areas they're attached to:
FilterLabelFilterText
Filter TextTextField
Directory ListDirList
Directory List LabelDir
DirLβLabelDirTextβTextField
Now for the actual mechanics, bestie, stay with me. π§
The directory mask is a string specifying the base directory to be examined and a search pattern. Ordinarily, the directory list displays the subdirectories of the base directory, as well as the base directory itself and its parent directory. The file list ordinarily displays all files and/or subdirectories in the base directory that match the search pattern.
Optionally, the search pattern mask and the base directory can be displayed in two separate text fields. This option is controlled by the XmNpathMode resource. Using this alternate display does not change the meaning of resources that control the content of these fields: XmNdirectory, XmNdirMask, XmNpattern. (no cap, the meaning stays exactly the same π
)
A procedure specified by the XmNqualifySearchDataProc resource extracts the base directory and search pattern from the directory mask. If the directory specification is empty, the current working directory is used. If the search pattern is empty, a pattern that matches all files is used.
An application can supply its own XmNqualifySearchDataProc as well as its own procedures to search for subdirectories and files. The default XmNqualifySearchDataProc works as follows: The directory mask is a pathname that can contain zero or more wildcard characters in its directory portion, its file portion, or both. The directory components of the directory mask β up to, but not including, the first component with a wildcard character β specify the directory to be searched, relative to the current working directory. The remaining components specify the search pattern. If the directory mask is empty or if its first component contains a wildcard character, the current working directory is searched. If no component of the directory mask contains a wildcard character, the entire directory mask is the directory specification, and all files in that directory are matched.
So how does a user actually drive this thing? π
The user can select a new directory to examine by scrolling through the list of directories and selecting the desired directory, or by editing the directory mask. Selecting a new directory from the directory list does not change the search pattern. A user can select a new search pattern by editing the directory mask or, when the FileSelectionBox has the optional XmNpathMode XmPATH_MODE_RELATIVE display, the filter text field. Double clicking or pressing KActivate on a directory in the directory list initiates a search for files and subdirectories in the new directory, using the current search pattern.
The user can select a file by scrolling through the list of filenames and selecting the desired file, or by entering the filename directly into the text edit area. Selecting a file from the list causes that filename to appear in the file selection text edit area.
The user may select a new file as many times as desired. The application is not notified until the user takes one of the following actions:
- Selects the
OKPushButton - Presses
KActivatewhile the selection text edit area has the keyboard focus - Double clicks or presses
KActivateon an item in the file list
FileSelectionBox initiates a directory and file search when any of the following occurs:
- The FileSelectionBox is initialized
- The function
XtSetValuesis used to changeXmNdirMask,XmNdirectory,XmNpattern, orXmNfileTypeMask - The user activates the
FilterPushButton - The user double clicks or presses
KActivateon an item in the directory list - The application calls
XmFileSelectionDoSearch - The user presses
KActivatewhile the directory mask text edit area has the keyboard focus
When a file search is initiated, the FileSelectionBox takes the following actions:
- Constructs an
XmFileSelectionBoxCallbackStructstructure with values appropriate for the action that initiated the search - Calls the
XmNqualifySearchDataProcwith the callback structure as the data input argument - Sets
XmNdirectoryValidandXmNlistUpdatedtoFalse - Calls the
XmNdirSearchProcwith the qualified data returned by theXmNqualifySearchDataProc
If XmNdirectoryValid is True, the FileSelectionBox takes the following additional actions:
- Sets
XmNlistUpdatedtoFalse - Calls the
XmNfileSearchProcwith the qualified data returned by theXmNqualifySearchDataProc(and possibly modified by theXmNdirSearchProc) - If
XmNlistUpdatedisTrueand the file list is empty, displays theXmNnoMatchStringin the file list and clears the selection text andXmNdirSpec - If
XmNlistUpdatedisTrueand the file list is not empty, sets the selection text andXmNdirSpecto the qualified dir returned by theXmNqualifySearchDataProc(and possibly modified by theXmNdirSearchProc) - Sets the directory mask text and
XmNdirMaskto the qualified mask returned by theXmNqualifySearchDataProc(and possibly modified by theXmNdirSearchProc) - Sets
XmNdirectoryto the qualified dir returned by theXmNqualifySearchDataProc(and possibly modified by theXmNdirSearchProc) - Sets
XmNpatternto the qualified pattern returned by theXmNqualifySearchDataProc(and possibly modified by theXmNdirSearchProc)
FileSelectionBox uses the XmQTactivatable trait. β
π«Ά Data Transfer Behavior π«Ά
Child widgets of a FileSelectionBox support the data transfer operations and targets associated with their widget classes.
In addition, if the source of a data transfer is the directory list and if XmNdirSearchProc has its default value, the directory list supports the FILE and FILE_NAME targets.
If the source of a data transfer is the file list and if XmNfileSearchProc has its default value, the file list supports the FILE and FILE_NAME targets.
In either case, FileSelectionBox adds an XmNconvertCallback procedure to the appropriate list. This procedure adds FILE and FILE_NAME to the TARGETS returned by the list. It treats requests for conversion of a selection to FILE and FILE_NAME exactly like requests for conversion to TEXT.
If an application changesXmNdirSearchProcorXmNfileSearchProcand wants to support theFILEandFILE_NAMEtargets on the corresponding list, it must provide support itself by adding a procedure to the list'sXmNconvertCallbacklist. No free rides, bestie. π
part 2 is coming, don't go anywhere π¦
β¨ Descendants β¨
Okay bestie, here's the tea: FileSelectionBox just births these descendants for you automatically, no assembly required π
. You can grab any of them by name using XtNameToWidget, and honestly you can also use that name when you're setting resource values, so keep these names handy π.
Here's the whole roster, no cap:
Applyβ Class:XmPushButtonGadgetβ Identity: Apply buttonCancelβ Class:XmPushButtonGadgetβ Identity: Cancel buttonDirβ Class:XmLabelGadgetβ Identity: title above list of directoriesDirListβ Class:XmListβ Identity: list of directoriesDirListSWβ Class:XmScrolledWindowβ Identity: ScrolledWindow parent of DirListFilterLabelβ Class:XmLabelGadgetβ Identity: title above filter boxFilterTextβ Class:XmTextorXmTextFieldβ Identity: text within filter boxHelpβ Class:XmPushButtonGadgetβ Identity: Help buttonItemsβ Class:XmLabelGadgetβ Identity: title above list of filenamesItemsListβ Class:XmListβ Identity: list of filenamesItemsListSWβ Class:XmScrolledWindowβ Identity: ScrolledWindow parent of ItemsListOKβ Class:XmPushButtonGadgetβ Identity: OK buttonSelectionβ Class:XmLabelGadgetβ Identity: title above selection boxSeparatorβ Class:XmSeparatorGadgetβ Identity: optional dividing lineTextβ Class:XmTextorXmTextFieldβ Identity: text within selection box
Lowkey important: those two entries that sayXmTextorXmTextField? That's not me being indecisive, that's literally the deal β it can be either one, and which one you get depends on stuff. Pick the name, get the widget, slay π¦.
π Classes π
FileSelectionBox is out here inheriting behavior, resources, and traits from its whole ancestry line, and honestly the family tree is giving royalty π:
CoreCompositeConstraintXmManagerXmBulletinBoardXmSelectionBox
And for the C girlies who need the actual identifiers:
- The class pointer is
xmFileSelectionBoxWidgetClass. - The class name is
XmFileSelectionBox.
πΈ New Resources πΈ
Alright, this next bit is where you get to be the main character and tell the widget exactly what data it should have. The table below defines a set of widget resources that us programmers use to specify data β¨.
And like, you're not limited to just the new stuff β you can also set resource values on the inherited classes to tweak attributes for this widget. Inheritance is a gift, fr fr π.
Now, for the .Xdefaults girlies, here's the naming hack you need:
- To reference a resource by name or by class in a
.Xdefaultsfile, remove theXmNorXmCprefix and just use the remaining letters. - To specify one of the defined values for a resource in a
.Xdefaultsfile, remove theXmprefix and use the remaining letters β either lowercase or uppercase is fine, just include any underscores between words, okay? Don't skip those π.
About the access column: those little codes tell you what you're allowed to do with the resource. Here's the decoder ring, memorize it iykyk π₯: -Cβ can be set at creation time -Sβ can be set by usingXtSetValues-Gβ can be retrieved by usingXtGetValues-N/Aβ not applicable
Periodt. π
okay so before we get into the β¨loreβ¨ of each individual resource, here's the whole guest list β every resource name, its class, its type, its default, and who's allowed to touch it. Bookmark this, bestie, you will be scrolling back:
XmNdirectoryβ classXmCDirectory, typeXmString, defaultdynamic, accessCSGXmNdirectoryValidβ classXmCDirectoryValid, typeBoolean, defaultdynamic, accessSGXmNdirListItemsβ classXmCDirListItems, typeXmStringTable, defaultdynamic, accessSGXmNdirListItemCountβ classXmCDirListItemCount, typeint, defaultdynamic, accessSGXmNdirListLabelStringβ classXmCDirListLabelString, typeXmString, defaultdynamic, accessCSGXmNdirMaskβ classXmCDirMask, typeXmString, defaultdynamic, accessCSGXmNdirSearchProcβ classXmCDirSearchProc, typeXmSearchProc, defaultdefault procedure, accessCSGXmNdirSpecβ classXmCDirSpec, typeXmString, defaultdynamic, accessCSGXmNdirTextLabelStringβ classXmCDirTextLabelString, typeXmString, defaultNULL, accessCXmNfileFilterStyleβ classXmCFileFilterStyle, typeXtEnum, defaultXmFILTER_NONE, accessCXmNfileListItemsβ classXmCItems, typeXmStringTable, defaultdynamic, accessSGXmNfileListItemCountβ classXmCItemCount, typeint, defaultdynamic, accessSGXmNfileListLabelStringβ classXmCFileListLabelString, typeXmString, defaultdynamic, accessCSGXmNfileSearchProcβ classXmCFileSearchProc, typeXmSearchProc, defaultdefault procedure, accessCSGXmNfileTypeMaskβ classXmCFileTypeMask, typeunsigned char, defaultXmFILE_REGULAR, accessCSGXmNfilterLabelStringβ classXmCFilterLabelString, typeXmString, defaultdynamic, accessCSGXmNlistUpdatedβ classXmCListUpdated, typeBoolean, defaultdynamic, accessSGXmNnoMatchStringβ classXmCNoMatchString, typeXmString, default" [ ] ", accessCSGXmNpathModeβ classXmCPathMode, typeXtEnum, defaultXmPATH_MODE_FULL, accessCXmNpatternβ classXmCPattern, typeXmString, defaultdynamic, accessCSGXmNqualifySearchDataProcβ classXmCQualifySearchDataProc, typeXmQualifyProc, defaultdefault procedure, accessCSG
XmNdirectory π
This is the base directory, periodt. It gets combined with XmNpattern to figure out which files and directories end up on screen. Its default isn't just sitting there β it's determined by the XmNqualifySearchDataProc, and it depends on whatever the initial values of XmNdirMask, XmNdirectory, and XmNpattern happen to be. And if that default comes out as NULL or empty? Then it just uses the current working directory. No notes. π¦
XmNdirectoryValid
ngl this one's a little special β it's an attribute that gets set only by the directory search procedure. Nobody else touches it, fr fr. Its value is set to True if the directory that got passed to the directory search procedure can actually be searched. And if it's False? Then the file search procedure does not get called, and XmNdirMask, XmNdirectory, and XmNpattern are not changed. Like, nothing moves. Iconic behavior honestly. π
XmNdirListItems β¨
This specifies the items in the directory list. Big warning though, bestie, listen up: when you do XtGetValues for this resource, you get back the list items themselves β not a copy of the list items. So the application must not free the returned items. Do not. I'm serious. π
XmNdirListItemCount
The number of items in the directory list. That's it. That's the resource. Oh and β the value must not be negative. Be so fr. π
XmNdirListLabelString π
The label string of the directory list. Its default depends on the locale β so it's giving "depends where you are." In the C locale, the default is Directories. Cute, consistent, no cap. πΈ
So, real talk: because default localized label strings now come through message catalogs for the children of composite widgets, the labelString resources cannot be set on the child through default resource files. π Instead, the resource provided at the parent level is the one you've gotta use. That's the whole vibe. Moving on bestie π
XmNdirMaskβ the directory mask that decides which files and directories get displayed. ποΈ The default value is determined byXmNqualifySearchDataProc, and it depends on the initial values ofXmNdirMask,XmNdirectory, andXmNpattern.XmNdirSearchProcβ lets you plug in a whole custom directory search procedure to replace the default one. π FileSelectionBox's default directory search procedure does what most apps need, but since it's literally impossible to cover every application's requirements, you're allowed to swap in your own.
The directory search procedure gets called with two arguments: the FileSelectionBox widget and a pointer to an XmFileSelectionBoxCallbackStruct structure. That callback structure is generated by the XmNqualifySearchDataProc and holds everything you need to run a directory search β the directory mask, plus a qualified base directory and search pattern. Once it's called, it's on the search routine to generate a new list of directories and update the FileSelectionBox widget using XtSetValues.
The search procedure must set XmNdirectoryValid and XmNlistUpdated. If it generates a new list of directories, it must also set XmNdirListItems and XmNdirListItemCount.
If the search procedure can't search the specified directory, it must warn the user and set XmNdirectoryValid and XmNlistUpdated to False β unless it prompts and subsequently obtains a valid directory. π«£ And if the directory is valid but is the same as the current XmNdirectory, the search procedure must set XmNdirectoryValid to True, but it may elect not to generate a new list of directories. In that case, it must set XmNlistUpdated to False.
If the search procedure generates a new list of directories, it must set XmNdirListItems to the new list of directories and XmNdirListItemCount to the number of items in the list. If there are no directories, it sets XmNdirListItems to NULL and XmNdirListItemCount to 0 (zero). Either way, it must set XmNdirectoryValid and XmNlistUpdated to True.
Ordinarily the search procedure should not change the callback structure. But if the original directory isn't valid, the search procedure may grab a new directory from the user. In that case, it should set the dir member of the callback structure to the new directory, call the XmNqualifySearchDataProc with the callback struct as the input argument, and copy the qualified data returned by the XmNqualifySearchDataProc into the callback struct. π
XmNdirSpecβ the full file path specification. π This is theXmNtextStringresource in SelectionBox, renamed for FileSelectionBox. The default value is determined by the FileSelectionBox after it conducts the initial directory and file search.XmNdirTextLabelStringβ uses the specifiedXmStringas the label above the TextField directory. β¨ This resource only takes effect when theXmNpathModeresource has a value ofXmPATH_MODE_RELATIVE. It gets ignored whenXmNpathModehas a value ofXmPATH_MODE_FULL.
And again, because default localized label strings now come through message catalogs for the children of composite widgets, the labelString resources cannot be set on the child through default resource files β the resource provided at the parent level is the one to use.
XmNfileFilterStyleβ decides whether or not the "hidden" files (the ones whose names begin with.(period) on POSIX systems) get listed in the file and directory scrolling lists β that's where the default directory search procedure is used. π The possible values are:XmFILTER_NONEβ does not filter hidden files.XmFILTER_HIDDEN_FILESβ restricts the list of possible file names, such as those beginning with.(period).
XmNfileListItemsβ the items in the file list. π This is theXmNlistItemsresource in SelectionBox, renamed for FileSelectionBox. Heads up:XtGetValuesfor this resource returns the list items themselves, not a copy of the list items. The application must not free the returned items. π«XmNfileListItemCountβ the number of items in the file list. π’ This is theXmNlistItemCountresource in SelectionBox, renamed for FileSelectionBox. The value must not be negative.XmNfileListLabelStringβ the label string of the file list. π·οΈ This is theXmNlistLabelStringresource in SelectionBox, renamed for FileSelectionBox. The default for this resource depends on the locale β in the C locale the default isFiles.
And yep, because default localized label strings now come through message catalogs for the children of composite widgets, the labelString resources cannot be set on the child through default resource files. Use the resource provided at the parent level instead. π
XmNfileSearchProcβ lets you swap in your own file search procedure to replace the default one. π FileSelectionBox's default file search procedure fulfills the needs of most applications, but since it's impossible to cover the requirements of all applications, you can replace the default search procedure.
The file search procedure is called with two arguments: the FileSelectionBox widget and a pointer to an XmFileSelectionBoxCallbackStruct structure. That callback structure is generated by the XmNqualifySearchDataProc (and possibly modified by the XmNdirSearchProc). It contains all information required to conduct a file search, including the directory mask and a qualified base directory and search pattern. Once this procedure is called, it is up to the search routine to generate a new list of files and update the FileSelectionBox widget by using XtSetValues.
The search procedure must set XmNlistUpdated. If it generates a new list of files, it must also set XmNfileListItems and XmNfileListItemCount.
It is recommended that the search procedure always generate a new list of files. If the mask member of the callback structure is the same as the mask member of the callback struct in the preceding call to the search procedure, the procedure may elect not to generate a new list of files. In this case it must set XmNlistUpdated to False.
If the search procedure generates a new list of files, it must set XmNfileListItems to the new list of files and XmNfileListItemCount to the number of items in the list. If there are no files, it sets XmNfileListItems to NULL and XmNfileListItemCount to 0 (zero). In either case it must set XmNlistUpdated to True.
When constructing the list of files, the search procedure should include only files of the types specified by the widget's XmNfileTypeMask. π
Setting XmNdirSpec is optional, but recommended. Set this attribute to the full file specification of the directory searched. The directory specification is displayed below the directory and file lists.
XmNfileTypeMaskβ the type of files listed in the file list. ποΈ The possible values are:XmFILE_REGULARβ restricts the file list to contain only regular files.XmFILE_DIRECTORYβ restricts the file list to contain only directories.XmFILE_ANY_TYPEβ allows the list to contain all file types including directories.
XmNfilterLabelStringβ the label string for the text entry field for the directory mask. π― The default for this resource depends on the locale β in the C locale the default isFilter.
And, as always: because default localized label strings now come through message catalogs for the children of composite widgets, the labelString resources cannot be set on the child through default resource files. Use the resource provided at the parent level. π«Ά
XmNlistUpdatedβ an attribute that is set only by the directory and file search procedures. π This resource is set toTrueif the search procedure updated the directory or file list.XmNnoMatchStringβ a string to be displayed in the file list if the list of files is empty. πXmNpatternβ the search pattern used in combination withXmNdirectoryto determine the files and directories to be displayed. π¦ The default value is determined byXmNqualifySearchDataProcand depends on the initial values ofXmNdirMask,XmNdirectory, andXmNpattern. If the default isNULLor empty, a pattern that matches all files is used.XmNpathModeβ whether or not an additional text field will be used to display and edit the filter. πͺ The possible values are:XmPATH_MODE_FULLβ specifies that no additional text field will be used to display the filter. There will just be a single text field to displayXmNdirMask.
XmPATH_MODE_RELATIVEβ okay so this one gives you two text fields bestie, not one: one of them displays theXmNdirectoryand the other one displays theXmNpattern. And in this mode,XmNfilterLabelStringis the label for the text field holdingXmNpattern, whileXmNdirTextLabelStringis the label for the text field holdingXmNdirectory. Two fields, two labels, no confusion πXmNqualifySearchDataProcβ this one lets you swap in your own search data qualification procedure and boot the default one out. The default data qualification procedure that FileSelectionBox ships with does the job for most applications, fr fr. But since it's literally impossible to cover what every application out there needs, you're allowed to replace the default procedure. Slay.
So what does this procedure actually do? It gets called to generate a qualified directory mask, base directory, and search pattern, all for the directory and file search procedures to use. It's called with three arguments: the FileSelectionBox widget, plus pointers to two XmFileSelectionBoxCallbackStruct structures. The first callback structure carries the input data. The second one carries the output data, and it's your procedure's job to fill it in.
Here's the rundown, no cap:
- If the input
dirandpatternmembers are notNULL, the procedure must copy them to the corresponding members of the output callback structure. - If the input
dirisNULL, the procedure builds the outputdirlike this: if the inputmaskmember isNULL, it uses the widget'sXmNdirectoryas the outputdir; otherwise it extracts the outputdirfrom the inputmask. And if the resulting outputdirends up empty, it uses the current working directory instead. π«Ά - If the input
patternisNULL, the procedure builds the outputpatternlike this: if the inputmaskmember isNULL, it uses the widget'sXmNpatternas the outputpattern; otherwise it extracts the outputpatternfrom the inputmask. And if the resulting outputpatternis empty, it uses a pattern that matches all files instead. - The data qualification procedure constructs the output
maskfrom the outputdirandpattern. And it must make sure that the outputdir,pattern, andmaskare all fully qualified. - If the input
valuemember is notNULL, the procedure must copy it to the outputvaluemember; otherwise, the procedure must copy the widget'sXmNdirSpecto the outputvalue. - The data qualification procedure must calculate the lengths of the output
value,mask,dir, andpatternmembers, and it must fill in the corresponding length members of the output callback struct. - The data qualification procedure must copy the input
reasonandeventmembers to the corresponding output members.
like, yes, there are a lot of "must"s in there. That's not me being dramatic, that's literally the contract. Skip one and things get weird π
The values of the XmNdirSearchProc and XmNfileSearchProc are procedure pointers of type XmSearchProc, and it's defined like this:
void (* XmSearchProc) (w, search_data)
Widget w;
XtPointer search_data;
wβ the FileSelectionBox widget πΈsearch_dataβ a pointer to anXmFileSelectionBoxCallbackStructthat's holding the info for conducting a search
And the value of the XmNqualifySearchDataProc resource is a procedure pointer of type XmQualifyProc, defined like this:
void (* XmQualifyProc) (w, input_data, output_data)
Widget w;
XtPointer input_data;
XtPointer output_data;
wβ the FileSelectionBox widget β¨input_dataβ a pointer to anXmFileSelectionBoxCallbackStructholding the input data that needs to be qualifiedoutput_dataβ a pointer to anXmFileSelectionBoxCallbackStructholding the output data, which the qualification procedure is responsible for filling in
π¦ Inherited Resources π¦
FileSelectionBox inherits behavior and resources from the superclasses described in the following tables. For a complete description of each resource, go check the reference page for that superclass, bestie β that's where the full tea lives. π
π XmSelectionBox Resource Set π
okay bestie, here's the full resource table for XmSelectionBox β every name, class, type, default, and access code, laid out so you can actually read it. no cap, it's a lot, but we're doing it together π
XmNapplyCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNapplyLabelStringβ classXmCApplyLabelString, typeXmString, defaultdynamic, accessCSGXmNcancelCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNcancelLabelStringβ classXmCCancelLabelString, typeXmString, defaultdynamic, accessCSGXmNchildPlacementβ classXmCChildPlacement, typeunsigned char, defaultXmPLACE_ABOVE_SELECTION, accessCSGXmNdialogTypeβ classXmCDialogType, typeunsigned char, defaultXmDIALOG_FILE_SELECTION, accessGXmNhelpLabelStringβ classXmCHelpLabelString, typeXmString, defaultdynamic, accessCSGXmNlistItemCountβ classXmCItemCount, typeint, defaultdynamic, accessCSGXmNlistItemsβ classXmCItems, typeXmStringTable, defaultdynamic, accessCSGXmNlistLabelStringβ classXmCListLabelString, typeXmString, defaultdynamic, accessCSGXmNlistVisibleItemCountβ classXmCVisibleItemCount, typeint, defaultdynamic, accessCSGXmNminimizeButtonsβ classXmCMinimizeButtons, typeBoolean, defaultFalse, accessCSGXmNmustMatchβ classXmCMustMatch, typeBoolean, defaultFalse, accessCSGXmNnoMatchCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNokCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNokLabelStringβ classXmCOkLabelString, typeXmString, defaultdynamic, accessCSGXmNselectionLabelStringβ classXmCSelectionLabelString, typeXmString, defaultdynamic, accessCSGXmNtextAcceleratorsβ classXmCTextAccelerators, typeXtAccelerators, defaultdefault, accessCXmNtextColumnsβ classXmCColumns, typeshort, defaultdynamic, accessCSGXmNtextStringβ classXmCTextString, typeXmString, defaultdynamic, accessCSG
likeβ¦ twenty resources, all accounted for, nothing skipped π
the dynamic defaults are lowkey doing the most (they get computed at runtime, not set in stone), and those access codes are your vibe check on when you can touch each one. keep scrolling bestie, there's more coming πΈπ¦
π XmBulletinBoard Resource Set π
okay bestie, this is the full roster of resources the XmBulletinBoard is serving. every single one, no skips, no cuts β name, class, type, default, and access, all of it π
XmNallowOverlapβ classXmCAllowOverlap, typeBoolean, defaultTrue, accessCSGXmNautoUnmanageβ classXmCAutoUnmanage, typeBoolean, defaultFalse, accessCGXmNbuttonFontListβ classXmCButtonFontList, typeXmFontList, defaultdynamic, accessCSGXmNbuttonRenderTableβ classXmCButtonRenderTable, typeXmRenderTable, defaultdynamic, accessCSGXmNcancelButtonβ classXmCWidget, typeWidget, defaultCancel button, accessSGXmNdefaultButtonβ classXmCWidget, typeWidget, defaultOK button, accessSGXmNdefaultPositionβ classXmCDefaultPosition, typeBoolean, defaultTrue, accessCSGXmNdialogStyleβ classXmCDialogStyle, typeunsigned char, defaultdynamic, accessCSGXmNdialogTitleβ classXmCDialogTitle, typeXmString, defaultNULL, accessCSGXmNfocusCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNlabelFontListβ classXmCLabelFontList, typeXmFontList, defaultdynamic, accessCSGXmNlabelRenderTableβ classXmCLabelRenderTable, typeXmRenderTable, defaultdynamic, accessCSGXmNmapCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNmarginHeightβ classXmCMarginHeight, typeDimension, default10, accessCSGXmNmarginWidthβ classXmCMarginWidth, typeDimension, default10, accessCSGXmNnoResizeβ classXmCNoResize, typeBoolean, defaultFalse, accessCSGXmNresizePolicyβ classXmCResizePolicy, typeunsigned char, defaultXmRESIZE_ANY, accessCSGXmNshadowTypeβ classXmCShadowType, typeunsigned char, defaultXmSHADOW_OUT, accessCSGXmNtextFontListβ classXmCTextFontList, typeXmFontList, defaultdynamic, accessCSGXmNtextRenderTableβ classXmCTextRenderTable, typeXmRenderTable, defaultdynamic, accessCSGXmNtextTranslationsβ classXmCTranslations, typeXtTranslations, defaultNULL, accessCXmNunmapCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessC
like, that's the whole lineup β¨ and yeah, some of these defaults are literally the word dynamic, that's not me being vague, that's just what the page says fr fr π¦
π XmManager Resource Set π
okay bestie, this is the big one β everything your widget inherits from XmManager. Same four-column tea as always (Name / Class / Type / Default / Access), just laid out as bullets so it actually fits on your screen. π
XmNbottomShadowColorβ classXmCBottomShadowColor, typePixel, defaultdynamic, accessCSGXmNbottomShadowPixmapβ classXmCBottomShadowPixmap, typePixmap, defaultXmUNSPECIFIED_PIXMAP, accessCSGXmNforegroundβ classXmCForeground, typePixel, defaultdynamic, accessCSGXmNhelpCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNhighlightColorβ classXmCHighlightColor, typePixel, defaultdynamic, accessCSGXmNhighlightPixmapβ classXmCHighlightPixmap, typePixmap, defaultdynamic, accessCSGXmNinitialFocusβ classXmCInitialFocus, typeWidget, defaultdynamic, accessCSGXmNlayoutDirectionβ classXmCLayoutDirection, typeXmDirection, defaultdynamic, accessCGXmNnavigationTypeβ classXmCNavigationType, typeXmNavigationType, defaultXmTAB_GROUP, accessCSGXmNpopupHandlerCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNshadowThicknessβ classXmCShadowThickness, typeDimension, defaultdynamic, accessCSGXmNstringDirectionβ classXmCStringDirection, typeXmStringDirection, defaultdynamic, accessCGXmNtopShadowColorβ classXmCTopShadowColor, typePixel, defaultdynamic, accessCSGXmNtopShadowPixmapβ classXmCTopShadowPixmap, typePixmap, defaultdynamic, accessCSGXmNtraversalOnβ classXmCTraversalOn, typeBoolean, defaultTrue, accessCSGXmNunitTypeβ classXmCUnitType, typeunsigned char, defaultdynamic, accessCSGXmNuserDataβ classXmCUserData, typeXtPointer, defaultNULL, accessCSG
ngl the way so many of these say dynamic instead of a real default? that's on purpose, bestie β the toolkit figures it out from the widget's context. don't come for me, come for the source. π«Ά
π¦ Composite Resource Set π¦
and here's the lil baby set that comes with Composite β only three rows, she's lowkey iconic for it. β¨
XmNchildrenβ classXmCReadOnly, typeWidgetList, defaultNULL, accessGXmNinsertPositionβ classXmCInsertPosition, typeXtOrderProc, defaultNULL, accessCSGXmNnumChildrenβ classXmCReadOnly, typeCardinal, default0, accessG
noticeXmNchildrenandXmNnumChildrenare accessGonly β read-only, bestie. look with your eyes, not with yourXtSetArg. π
the table format was giving β¨ spreadsheet energy β¨ so I flipped it into bullets, but every single Name, Class, Type, Default and Access value is still there, character for character. no cap. π
more coming, keep scrolling π§
okay bestie, here comes the receipts table π β every single resource this widget inherits, with its class, type, default, and who's allowed to touch it (that Access column is C = create-only, G = get, S = set, so CSG means all three, no cap).
XmNacceleratorsβ classXmCAccelerators, typeXtAccelerators, defaultdynamic, accessN/AXmNancestorSensitiveβ classXmCSensitive, typeBoolean, defaultdynamic, accessGXmNbackgroundβ classXmCBackground, typePixel, defaultdynamic, accessCSGXmNbackgroundPixmapβ classXmCPixmap, typePixmap, defaultXmUNSPECIFIED_PIXMAP, accessCSGXmNborderColorβ classXmCBorderColor, typePixel, defaultXtDefaultForeground, accessCSGXmNborderPixmapβ classXmCPixmap, typePixmap, defaultXmUNSPECIFIED_PIXMAP, accessCSGXmNborderWidthβ classXmCBorderWidth, typeDimension, default0, accessCSGXmNcolormapβ classXmCColormap, typeColormap, defaultdynamic, accessCGXmNdepthβ classXmCDepth, typeint, defaultdynamic, accessCGXmNdestroyCallbackβ classXmCCallback, typeXtCallbackList, defaultNULL, accessCXmNheightβ classXmCHeight, typeDimension, defaultdynamic, accessCSGXmNinitialResourcesPersistentβ classXmCInitialResourcesPersistent, typeBoolean, defaultTrue, accessCXmNmappedWhenManagedβ classXmCMappedWhenManaged, typeBoolean, defaultTrue, accessCSGXmNscreenβ classXmCScreen, typeScreen *, defaultdynamic, accessCGXmNsensitiveβ classXmCSensitive, typeBoolean, defaultTrue, accessCSGXmNtranslationsβ classXmCTranslations, typeXtTranslations, defaultdynamic, accessCSGXmNwidthβ classXmCWidth, typeDimension, defaultdynamic, accessCSGXmNxβ classXmCPosition, typePosition, default0, accessCSGXmNyβ classXmCPosition, typePosition, default0, accessCSG
π Callback Information π
so when the callback fires, this is the lil envelope of info it hands you π β a pointer to the structure below gets passed to each callback:
typedef struct
{
int reason;
XEvent * event;
XmString value;
int length;
XmString mask;
int mask_length;
XmString dir;
int dir_length;
XmString pattern;
int pattern_length;
} XmFileSelectionBoxCallbackStruct;
let's break down every field, one by one, no skipping β¨
reasonβ tells you why the callback got invoked, like the receipts for what just happened πeventβ points at theXEventthat triggered the callback, the actual moment that set it off π«Άvalueβ the current value ofXmNdirSpec, fr frlengthβ the number of bytes invalue. Heads up bestie: this member is obsolete and only hangs around for compatibility with earlier releases πmaskβ the current value ofXmNdirMaskmask_lengthβ the number of bytes inmask. Yeah this one's obsolete too, kept for compatibility with earlier releases πdirβ the current base directorydir_lengthβ the number of bytes indir. Also obsolete, also just there for compatibility with earlier releases πpatternβ the current search pattern
pattern_length
okay so pattern_length is the number of bytes in pattern. BUT β and this is important, bestie β this member is obsolete and only still exists for compatibility with earlier releases. she's a legacy icon, we love her, we do not build new things on her π
β¨ Translations β¨
XmFileSelectionBox inherits translations from XmSelectionBox. that's the whole tea β she's just borrowing her big sister's choreography π
β¨ Accelerators β¨
The XmNtextAccelerators from XmSelectionBox get added to the selection and directory mask (filter) Text descendants of XmFileSelectionBox. so the text widgets lowkey get the same shortcuts as the selection box ones β¨
β¨ Action Routines β¨
The XmFileSelectionBox action routines are iconic, all of them:
SelectionBoxUpOrDown(Previous|Next|First|Last)β the up/down navigation queen π- If neither the selection text nor the directory mask (filter) text has the focus, this action does nothing. vibe check failed, no notes, we move on π
- If the selection text has the focus, the term list in the description below means the file list, and the term text means the selection text. If the directory mask text has the focus, list means the directory list, and text means the directory mask text.
- When called with an argument of
Previous, or0(zero) for compatibility, this action selects the previous item in the list and replaces the text with that item. - When called with an argument of
Next, or1for compatibility, this action selects the next item in the list and replaces the text with that item. - When called with an argument of
First, or2for compatibility, this action selects the first item in the list and replaces the text with that item. - When called with an argument of
Last, or3for compatibility, this action selects the last item in the list and replaces the text with that item.
SelectionBoxRestore()β the "undo my mess" button π«Ά- If neither the selection text nor the directory mask (filter) text has the focus, this action does nothing. again. nothing. she said what she said π
- If the selection text has the focus, this action replaces the selection text with the selected item in the file list. If no item in the file list is selected, it clears the selection text.
- If the directory mask text has the focus, this action replaces the directory mask text with a new directory mask constructed from the
XmNdirectoryandXmNpatternresources.
β¨ Additional Behavior β¨
The FileSelectionBox widget has the following additional behavior (this is the good part, get comfy bestie π):
<Key><osfCancel>β Calls the activate callbacks for the cancel button if it is sensitive. If no cancel button exists and the parent of the FileSelectionBox is a manager, it passes the event to the parent. she's like "not my problem, take it upstairs" π<Key><osfActivate>in Selection Text β Calls the selection text widget'sXmNactivateCallbackcallbacks. IfXmNmustMatchisTrueand the selection text does not match an item in the file list, it calls theXmNnoMatchCallbackcallbacks with reasonXmCR_NO_MATCH. Otherwise, it calls theXmNokCallbackcallbacks with reasonXmCR_OK.<Key><osfActivate>in Directory Mask Text β Calls the directory mask text widget'sXmNactivateCallbackcallbacks, initiates a directory and file search, and calls theXmNapplyCallbackcallbacks with reasonXmCR_APPLY.<Btn1Down>(2+) or <Key><osfActivate>in Directory List β Calls the directory list widget'sXmNdefaultActionCallbackcallbacks, initiates a directory and file search, and calls theXmNapplyCallbackcallbacks with reasonXmCR_APPLY.<Btn1Down>(2+) or <Key><osfActivate>in File List β Calls the file list widget'sXmNdefaultActionCallbackcallbacks and calls theXmNokCallbackcallbacks with reasonXmCR_OK.<Key><osfSelect>in Directory List β Generates a new directory mask, using the selected list item as the directory and the pattern extracted from the current directory mask text as the search pattern. If the search pattern is empty, it uses a pattern that matches all files in the directory. Replaces the directory mask text with the new directory mask. she built a whole new mask from scratch, no cap β¨<Key><osfSelect>in File List β Replaces the selection text with the selected list item. simple. clean. slay.<Btn2Down>in File List β Drags the content of one or more selected list items using the drag and drop facility. If<Btn2Downis pressed on an unselected item, drags only that item, excluding any other selected items.- This action sets the
XmNconvertProcof the DragContext to a function that calls theXmNconvertCallbackprocedures of the file list, possibly multiple times, for the_MOTIF_DROPselection.
- This action sets the
<Btn2Down>in Directory List β Drags the content of one or more selected list items using the drag and drop facility. If<Btn2Downis pressed on an unselected item, it drags only that item, excluding any other selected items.- This action sets the
XmNconvertProcof the DragContext to a function that calls theXmNconvertCallbackprocedures of the directory list, possibly multiple times, for the_MOTIF_DROPselection.
- This action sets the
<Apply Button Activated>β Initiates a directory and file search. Calls theXmNapplyCallbackcallbacks with reasonXmCR_APPLY.<OK Button Activated>β IfXmNmustMatchisTrueand the selection text does not match an item in the file list, calls theXmNnoMatchCallbackcallbacks with reasonXmCR_NO_MATCH. Otherwise, calls theXmNokCallbackcallbacks with reasonXmCR_OK. main character energy fr fr π<Cancel Button Activated>β Calls theXmNcancelCallbackcallbacks with reasonXmCR_CANCEL.<Help Button Activated>β Calls theXmNhelpCallbackcallbacks with reasonXmCR_HELP.<Key><osfActivate>β If no button, list widget, or text widget has the keyboard focus, ifXmNmustMatchisTrueand the selection text does not match an item in the file list, it calls theXmNnoMatchCallbackcallbacks with reasonXmCR_NO_MATCH. Otherwise, it calls theXmNokCallbackcallbacks with reasonXmCR_OK.
heads up bestie: that<Btn2Downup there is missing its closing>in the original β I'm keeping it exactly as written because we do not edit the source, we respect the source π
β¨ Virtual Bindings β¨
The bindings for virtual keys are vendor specific. everyone's got their own little rules, iykyk π¦ For info about bindings for virtual buttons and keys, go read VirtualBindings(3).
π RELATED π
the whole friend group, in no particular order:
Composite(3)Constraint(3)Core(3)XmBulletinBoard(3)XmCreateFileSelectionBox(3)XmCreateFileSelectionDialog(3)XmFileSelectionBoxGetChild(3)XmFileSelectionDoSearch(3)XmManager(3)XmSelectionBox(3)XmVaCreateFileSelectionBox(3)XmVaCreateManagedFileSelectionBox(3)
and that's a wrap on the whole page, bestie!! you read every single resource, every action routine, every binding, and you ATE π
β¨ the footer tags this one as XmFileSelectionBox(library call) β no date on it, she's timeless, she's eternal, she's a library call π go forth and file-select responsibly, ily π«Άπ
π¦ 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