Groupy's Blunt Auto-Grouping Logic Breaks Modern Web Development Workflows Action-Oriented

A solution would help many developers user issues with Groupy

from Stardock Forums

Hello Stardock Development Team,

As a developer and long-time Groupy user, I love the utility for managing primary application windows. However, there is a major friction point with Groupy's process-level auto-grouping heuristics regarding secondary windows, popups, and debugging contexts.

Currently, Groupy's auto-grouping logic appears to hook into low-level window creation events (e.g., matching parent process names like chrome.exe or msedge.exe) and aggressively tabs secondary windows that are explicitly designed to run as isolated floating frames.

The Problem:

When web applications or desktop tools spawn secondary windows—such as OAuth authorization flows, debugger panels, or explicit window.open() popups—Groupy intercepts the new window handle and forces it into an existing tab group. Because these secondary windows often share the base process executable and dynamic titles, static process-name exclusions are insufficient (as excluding the process completely breaks standard browser tabbing).

Proposed Solution:

Please consider adding a window-style or attribute-based exclusion filter to Groupy's auto-grouping engine, such as:

  1. Window Style Flag Filtering: An option to ignore windows created with specific Win32 window styles or extended styles (e.g., checking for WS_POPUP, lack of standard sizing frames, or presence of WS_EX_TOOLWINDOW / specific HWND parent-child relationships).

  2. Explicit Developer Exclusion Flag / API: Support for a command-line flag, environment variable, or window property (such as a custom window property/atom) that external applications or browsers can set upon creation to signal: "Do not auto-group this specific HWND."

Giving developers and power users a way to prevent auto-grouping based on window classification rather than blunt process-name matching would eliminate this workflow clash entirely.

Thank you for your time and for maintaining a great utility.

Stardock Software Object Desktop DesktopX DesktopX Wishlist Type: Discussion
46 views 1 replies
Reply #1 from Stardock Forums Top

Subject: Follow-up: Groupy desperately needs window exclusion rules (so developers can actually tell users how to fix this)

Body:

To follow up on the missing auto-grouping controls: it is absurd that a window management utility still lacks basic exclusion rules after all these years.

Right now, Groupy operates as an all-or-nothing trap. When secondary windows or popups (like those with titles starting with Sidetoolz /) are forcefully hijacked into tab groups because they share a browser process, developers are left helpless.

Without a basic carve-out or exclusion engine, we can't even give our users a straightforward instruction manual on how to configure Groupy so it stops breaking our software's UI layout.

At a bare minimum, please add:

  1. Title-Based Substring Exclusions: A simple rule option to skip auto-grouping for windows matching a specific text string (e.g., Sidetoolz /).

  2. Window Style Filtering: Ignoring windows with properties like WS_POPUP or WS_EX_TOOLWINDOW.

Give developers the tools to tell our users how to fix this, instead of forcing a blunt process-wide block that breaks standard tabbing.