D16228: Raise window group together with group transient

graesslin added a comment.


  In D16228#353813 <https://phabricator.kde.org/D16228#353813>, @zzag wrote:
  
  > In D16228#353706 <https://phabricator.kde.org/D16228#353706>, @graesslin wrote:
  >
  > > Now I have a question: what is a real-world example for a group transient?
  >
  >
  > Relevant mailing list thread:
  >
  > - https://mail.gnome.org/archives/wm-spec-list/2002-December/msg00020.html
  >
  >   As an example, each desktop effect KCM dialog is a group transient (probably, because we don't set parent).
  
  
  No they are not. They don't have a transient parent, it's just that the EWMH evaluates that to be group transients. But that's in that case wrong. It's just a window without a parent.
  
  > This patch tries to put "group transients" on par with transients for toplevel windows. If user raises a transient for a toplevel window, its main windows will be raised too. Why should it be different case for "group transients"?
  
  I would say: don't fix what is not broken. I'm afraid of side effects if we change such old code. I'm probably not the only one who hasn't known that transient for has such a behavior if set to root and I maintained a large window manager for almost a decade. Chances are that if we change the code it will cause regressions as applications break.
  
  If you present me a real world use case where this feature is used and our current behavior is broken I might consider such a change. But without a real world use case I would say it's an obscure feature of ewmh which nobody uses any more

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D16228

To: zzag, #kwin, graesslin
Cc: graesslin, davidedmundson, kwin, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart