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.

Moved to Groupy area

Stardock Software Type: Discussion
418 views 6 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.

Reply #2 from Stardock Forums Top

Hello,
Sorry to hear you are having issues. I have forwarded your request to the Stardock Support Team for their review and recommendations. Please keep an eye on this thread for any updates. We really do appreciate your feedback, Thanks

Basj,
Stardock Community Assistant.

Object Desktop - Get all of our enhancement utilities in one suite
Reply #3 from Stardock Forums Top

Any feed back on this yet? I've tried about a dozen workarounds to this problem and I still can't find any. And it would take your programmers about a dayto fix it. These are just not complicated rules if they'd just care enough to to code a few.  It would go a long way to removing a lot of resistance to this product. I've had to stop using it altogether. The frustration level is just great, and I love the product.

Reply #4 from Stardock Forums Top

Unfortunately, there is nothing new to report on this one.

Thank you,

Basj,
Stardock Community Assistant

Reply #5 from Stardock Forums Top

You raise some interesting points on this.

Being able to exclude on a more fine level would be useful in these situations.

We will see what we can do.

Reply #6 from Stardock Forums Top

Great news, thank you Neil.  I tried to be as specific as possible so this just didn't sound like random gripe about an edge case. As a fellow developer I know what those can feel like :)