Why Some Buttons Should Act on Press—and Others Shouldn't

In Filedini, buttons and menu choices usually take effect when the pointer button is pressed, rather than after it is released.

Most desktop UI frameworks interpret a click as a press followed by a release. Avalonia’s Button, for example, raises Click on release by default.

The alternative behavior became widely known through John Carmack’s post about “Act on press”. Filedini uses the idea as a starting point for its interaction design—but not as an absolute rule.

Acting as soon as the pointer goes down

The time between pressing and releasing a mouse button is short. But a file manager is built around actions that people repeat constantly: navigating folders, switching views, choosing commands, and opening menus.

When every action waits for release, the application can feel slightly behind the user even when the underlying operation is fast. Performance is not only about reducing computation time. It is also about reducing the delay between intent and feedback.

For frequent, immediate actions, Filedini uses Avalonia’s ClickMode="Press". A style can make that policy reusable without changing the default for every button:

<Style Selector="Button.act-on-press">
    <Setter Property="ClickMode" Value="Press" />
</Style>

<Button Classes="act-on-press"
        Command="{Binding SomeCommand}" />

Buttons with the act-on-press class start their command as soon as the pointer goes down. The input and the resulting visual change feel directly connected.

Using a class also makes the exceptions explicit. Controls for important actions can simply keep Avalonia’s default release behavior.

Keeping the timing consistent beyond Button

Changing Button alone is not enough. If a toolbar reacts on press but a ComboBox or flyout waits for release, the same screen has two different response rhythms.

Filedini therefore has reusable behaviors for controls that do not expose the same ClickMode option:

• A ComboBox confirms the enabled item that was pressed and closes its popup.
• A Flyout or MenuFlyout confirms a terminal item on left press.
• An item that owns a submenu is left alone so its expansion behavior is not broken.

These rules live in shared behaviors instead of view-specific event handlers. New screens can reuse the same interaction policy, and tests can cover the policy independently from a particular dialog.

Important actions still wait for a complete click

“Act on press” does not mean that every action should fire immediately.

Filedini keeps important actions with costly mistakes on the normal release behavior.

For example, the minimize and maximize buttons act on press, but the window close button does not set ClickMode="Press". Tab close buttons also remain on release.

If users press a close button and notice the mistake before releasing it, they can move the pointer away from the button and cancel the click. Here, the chance to reconsider is more valuable than saving a small amount of latency.

Press is also wrong when the gesture is still ambiguous

Some pointer actions do not reveal the user’s intent at press time.

Pressing the right mouse button over a file might become either a context-menu request or a right-button drag. Opening the menu immediately would prevent the drag from starting. Filedini waits for Avalonia’s ContextRequested event, which represents the completed context action.

The same principle applies to controls that can be scrolled or dragged. Immediate activation is only safe when the pressed target unambiguously represents the action.

The policy can be summarized in three rules:

Act on press when intent is already clear and the cost of a mistake is small.
Wait for a complete click when the action is important, such as closing a window.
Wait when press could still turn into another gesture, such as dragging or scrolling.

Responsiveness is not useful if it steals another valid interaction.

Responsiveness is more than execution time

Startup time, operation latency, and frame rate are obvious performance metrics. Input timing is easier to overlook, even though users feel it during every interaction.

Acting on press can make repeated commands feel immediate. Waiting for release can preserve safety and gesture disambiguation. The right choice depends on the meaning of the control, not on a blanket framework default.

Filedini chooses between the two by considering three things:

• How quickly should the interface respond?
• How costly would an accidental activation be?
• Could the press still become a different gesture?

Even the timing of a small button says something about how an application treats its users. Filedini acts on press by default, then deliberately keeps release behavior where safety or interaction continuity matters more.