feat(form): Add footer placement and dynamic styling

[mg-dev25]

Addresses #219, #69, #188, #220

New features

1. @footer@ tag

Place fields in the dialog button bar instead of the form grid:

yad --form --field="Name" "" --field="@footer@I agree:CHK" FALSE --button="OK:0"

2. @vexpand@ label

Create vertical spacing that expands.

3. Dynamic CHK background colors

Set checkbox background via CSS using value!color format:

echo "1:TRUE!red" | yad --form --field="Accept:CHK" --listen

4. Button field colors

Fourth parameter sets background color:

yad --form --field=":FBTN" "gtk-ok!Click!echo ok!#4CAF50"

Changes

• src/form.c: Parse @footer@ tag, CSS styling for CHK and FBTN fields
• src/main.c: Footer widget integration

Existing scripts work unchanged. New features are opt-in via special syntax.

[v1cont]

can you provide some use cases for this feature (i mean footer)?

[mg-dev25]

Here are some practical use cases for the @footer@ tag. The common theme is placing checkboxes that modify the action itself (rather than configure parameters) next to the action buttons.

1. License Agreement

This is probably the most common use case. Installers typically place the "I agree" checkbox right next to the Install button, not mixed in with configuration options:

yad --form --title="Install MyApp" \
    --field="Install Path:DIR" "/opt/myapp" \
    --field="Create Shortcut:CHK" TRUE \
    --field="@footer@I accept the license agreement:CHK" FALSE \
    --button="Install:0" --button="Cancel:1"

The agreement is tied to the Install action, not to the installation settings.

---

2. "Don't ask me again"

Confirmation dialogs often have this option. It belongs near the action buttons because it affects future behavior, not the current delete operation:

yad --form --title="Confirm Delete" \
    --text="Delete 15 files? This cannot be undone." \
    --image="dialog-warning" \
    --field="@footer@Don't ask me again:CHK" FALSE \
    --button="Delete:0" --button="Cancel:1"

---

3. Dry run mode

For operations that could be destructive, a "dry run" checkbox changes what the action button does. It's an action modifier, not a config setting:

yad --form --title="System Update" \
    --text="The following packages will be updated:" \
    --field="Clean cache after:CHK" TRUE \
    --field="@footer@Dry run (show changes only):CHK" FALSE \
    --button="Update:0" --button="Cancel:1"

---

4. Post-action behavior

Export dialogs sometimes offer "open folder when complete". This is logically separate from export settings:

yad --form --title="Export Data" \
    --field="Output File:SFL" "~/report.csv" \
    --field="Format:CB" "CSV!JSON!Excel" \
    --field="@footer@Open folder when complete:CHK" TRUE \
    --button="Export:0" --button="Cancel:1"

---

5. Batch scope modifier

File operations may ask whether to apply changes to all selected items. Again, this modifies the action scope rather than the operation parameters:

yad --form --title="Rename Files" \
    --text="Find and Replace in Filenames" \
    --field="Find:" "IMG_" \
    --field="Replace with:" "Photo_" \
    --field="@footer@Apply to all selected:CHK" TRUE \
    --button="Rename:0" --button="Preview:2"

---

Visual comparison

With @footer@	Without
Checkbox in button bar	Checkbox in form

---

Why @footer@ syntax?

• Backward compatible with existing scripts
• No new CLI options needed
• The field definition shows placement intent
• Follows existing YAD conventions (similar to @disabled@)

Note: I pushed a fix (08a761b) that resolved an issue where footer widgets were double-packed, causing GTK warnings. The feature now works correctly.

---

Let me know if you'd like additional examples or any changes.