Position the dock more freely

The planned Flexible Edge Offset setting will let users control the distance between the dock and the screen edge to which it is attached. A value of zero will place the dock directly against the edge, while positive values will move it further into the usable screen area.

The feature is being designed for top, bottom, left, and right dock positions. Multi-monitor layouts, taskbar placement, usable work areas, and different DPI scales will be included in the positioning logic. The goal is to keep the dock on-screen and correctly reposition it after monitor or DPI changes.

Customize every corner independently

The current single corner-radius value is planned to be replaced by separate controls for:

• Top-left corner
• Top-right corner
• Bottom-right corner
• Bottom-left corner

When linked-corner editing is enabled, changing one value will apply it to all four corners. When linking is disabled, each value will remain independent. Existing users’ single corner-radius value will be migrated to all four corners so their current appearance is preserved.

The values are intended to drive not only the XAML appearance, but also clipping geometry, the native window region, backdrop boundaries, and hit testing. This consistency is important for preventing black corners, opaque artifacts, overflow, clipping, and mismatched clickable areas.

Choose how MiaDock behaves in fullscreen

Four fullscreen behavior modes are planned:

1. Hide completely: The dock remains hidden while a fullscreen application is active.
2. Show notifications only: The normal dock remains hidden and appears temporarily for supported notifications.
3. Hide at the edge and reveal with the pointer: The dock moves toward its attached edge and returns when the pointer reaches the activation area.
4. Remain normally visible: Fullscreen applications do not change dock visibility.

The modes are intended to operate correctly across multiple monitors and affect only the relevant dock and fullscreen application. Hover, notification, expanded-module, menu, and flyout visibility will be tracked as separate reasons. If one reason ends while another is still active, the dock should remain visible.

More stable context-menu and flyout interactions

Another planned improvement addresses cases where the dock collapses, hides, or changes shape while a context menu or flyout is open. Automatic collapsing and hiding will be suspended for the lifetime of the active menu or panel.

If multiple flyouts are open, closing one will not immediately collapse the dock while another remains active. After the final menu closes, the dock will stay expanded if the pointer is still over it; otherwise, the normal delay will apply. Delayed callbacks will re-check the current interaction state instead of acting on stale information.

More reliable battery information

The update is planned to address cases where a battery-powered device is incorrectly reported as having no battery. The new approach will distinguish between a device with no physical battery and a battery API that is temporarily unavailable or unable to provide data.

Battery information will be refreshed after adapter, charge-state, and percentage changes. The service will re-evaluate its state after sleep and resume. A temporary read failure will not be converted into a permanent “no battery” result, and the last successful reading may be preserved in a controlled way.

Live Bluetooth status

MiaDock 1.3.0 is also planned to correct stale device information after Bluetooth is switched off. Radio states will be tracked separately as on, off, unknown, or unavailable.

When the radio is turned off, cached connection information will be invalidated. When Bluetooth returns, device watching will restart safely. The implementation is intended to prevent duplicate watchers during rapid toggling, stop old callbacks from changing current state, and avoid repeated disconnection-notification storms.

More stable media controls

Canva and other WebView2-based applications can change Windows media sessions very quickly while videos are opened, stopped, replaced, or closed. If an asynchronous operation continues using an old media session after that session has become invalid, it can create a race condition capable of closing MiaDock.

The planned 1.3.0 work will not rely only on catching errors after they occur. The goal is to make media-session lifetime management safe by design.

Safe media-session management

Each active media session will use a generation or revision value. When the active session changes, previous work will be canceled. After important asynchronous steps, MiaDock will verify that the operation still belongs to the current session. Results from older sessions will not be allowed to overwrite information from the latest song or video.

Instead of allowing uncontrolled parallel metadata, playback, timeline, and thumbnail requests against the same session, the service is planned to use a serialized and bounded processing pipeline. Repeated events may be coalesced, queues will not be allowed to grow without limits, and work belonging to an old session should not block the latest one.

Safe data only in the UI layer

Native Windows media-session and stream objects will not be passed directly into the user interface. Title, artist, album, playback state, timeline information, and artwork will be converted as early as possible into a managed snapshot model.

Thumbnail data will be copied into a safe managed representation, and stream resources will be disposed completely. An old thumbnail request will not be allowed to replace artwork from a newer video. If artwork loading fails, metadata and playback information should continue to work whenever possible.

Canva and WebView2 compatibility

Planned stress tests include rapidly starting and stopping videos, switching between media items, closing tabs, moving between different media applications, and simulating hundreds of quick session changes. The intended result is that MiaDock remains open, does not display stale media information, does not accumulate tasks or event handlers, and keeps CPU and memory usage under control.

Disable all Focus features with one setting

A new “Enable Focus features” setting is planned to provide one place for disabling all Focus-related behavior.

When disabled, active profile effects will be removed, time-based and application-based automations will stop, related background timers will be suspended, and Focus indicators will be hidden or disabled. User-created profiles will not be deleted and will remain available if the feature is enabled again.

The setting will remain enabled by default for existing users. If the application starts while Focus features are disabled, unnecessary Focus services should not be started.

Safe settings migration

The new options will be added to the existing settings system and the schema version will be updated. The previous single corner-radius value will be migrated into the new four-corner model. Invalid edge offsets, excessive corner values, and unknown fullscreen modes will be normalized to safe values.

Migration must remain safe when run more than once. A single invalid field should not cause all settings to be reset, and unrelated user preferences should be preserved.

Localization and accessibility

All new user-facing text will be added in Turkish and English through the existing localization system. Numeric controls, individual corner fields, and fullscreen choices will be accessible with the keyboard and screen readers. Meaning will not be communicated by color alone, and existing high-contrast and reduced-motion behavior will be preserved.

Performance and resource safety

The implementation will avoid constant high-frequency polling, unbounded task creation, and uncontrolled retry loops. Event subscriptions, cancellation sources, native window regions, and stream objects will be released safely.

Media sessions, Bluetooth watchers, battery refresh operations, dock geometry updates, and fullscreen edge detection will be included in performance checks.

Phased development and validation

The 1.3.0 work is planned across five phases:

1. Visual Customization: Flexible Edge Offset and Independent Corner Design.
2. Smart Visibility and Interaction: Fullscreen behavior and context-menu/flyout safety.
3. System Status Reliability: Battery and Bluetooth corrections.
4. Stability and Control: Safe media-session management and disabling Focus features.
5. Validation and 1.3.0 Preparation: Migration, regression and stress testing, accessibility, documentation, and release-build validation.

A phase will not be treated as complete until its tests pass. Displaying a control in the interface will not be enough; each feature must be connected to real application behavior and validated against failure, race-condition, disposal, and stress scenarios.