Version: (using Devel) Compiler: 4.3.81SVN OS: Linux Installed from: Compiled sources The new window grouping feature should remember the windows size and fall back to that size after closing the new window tab. For example it can be easily reproduced when using gmail, when i click to delete a mail from All Mail it opens new window group which is small (just a confirmation window) but when i close that (by pressing ok) it closes the window tab but the size of the old window stays the same which is a bit annoying. It should be implemented by default for kwin to remember window tabs sizes.
I want to add that this not only is a problem when closing windows, but also when I remove I window from a group by dragging it out with the middle mouse button (or however this is done, the middle mosue button may be my own configuration). Another kwin feature I use is dragging window to the left/right edge, so they get resized and occupy half the screen. When I drag the window back, it gets the sioze it had before. This is how I would like it to be for window groups, too.
*** Bug 285921 has been marked as a duplicate of this bug. ***
One of the ideas behind window tabbing is to synchronize the window sizes. This makes it rather difficult to figure out what should be the correct size for the remaining windows. What you want is a smart heuristic to set window sizes. This is just not possible. A much better solution would be to not tab with windows which don't fit. So the solution proposed in this feature request solves the symptomps but not the problem.
All I really want is for the windows to return to the size they were before grouped when ungrouped. Please excuse my ignorance, but is it really that hard to set a variable containing the previous window size and reapply that variable during the ungroup event?
> All I really want is for the windows to return to the size they were before > grouped when ungrouped. Please excuse my ignorance, but is it really that > hard to set a variable containing the previous window size and reapply that > variable during the ungroup event? You see it too simple. Consider you have window A with size Y, now you group it with window B of size X and the size changes to X. Now the window A has a programmatic reason to change the size to W. Now you untab and the logic would restore to the incorrect size Y. It is a non trivial situation where it is quite likely that the window manager would use wrong sizes which makes the current solution more correct than any other solution.
(In reply to comment #6) > For example it can be easily reproduced when using gmail, when i click to > delete a mail from All Mail it opens new window group which is small In other words the browser opens a "dialog" popup (with fixed size, i assume?!) which gets autotabbed and thus hides the actual browser because it's no dialog but just another browser window? Sounds nasty enough. -> Setup a *very* sharp rule (regexp on the title?) for this window to alter the window type to "dialog". Issue solved.
(In reply to comment #5) > > All I really want is for the windows to return to the size they were before > > grouped when ungrouped. Please excuse my ignorance, but is it really that > > hard to set a variable containing the previous window size and reapply that > > variable during the ungroup event? > You see it too simple. Consider you have window A with size Y, now you group > it with window B of size X and the size changes to X. Now the window A has a > programmatic reason to change the size to W. But why would it do this, when it is grouped to another window? I'd think that its size should still stay as X. And return to Y when it is ungrouped. >Now you untab and the logic would > restore to the incorrect size Y. Which would sound correct to me. Sorry if I sound ignorant here, I don't want to be, and I know you guys know a lot more about this stuff than I do, and things might very well be not as simple as I think they are. But in my opinion the ungrouping worked fine for me in the past, and exactly as I would like and expect it to be. But this may be my simple setup, usually I only ungroup my group of Dolphin and Konsole windows. Which also means I do not care too much about this. Well, here we have one of KDE's problems: You developers invent a REALLY COOL feature like grouping windows, which leads to some potential inconsistent behaviour, and now we users complain :)
I have to agree, I see no logical reason why this isn't possible. I think it would be more appropriate if the developers classify this as "WEDONTWANTTOFIX".
(In reply to comment #7) > But why would it do this, when it is grouped to another window? The window has absolutely no idea that it is in a tabgroup. KWin could suppress such resize, but that would be wrong because the window likely has a good reason to do so. > I'd think that its size should still stay as X. And return to Y when it is ungrouped. And to what size should it return if the user has changed the size of the window/group explicitly (what is not in all cases know by the WM to be "explicit") > Which would sound correct to me. For the limited case you observed because of a buggy tagged window. What is effectively a dialog should not end up in a window group. Autotabbing is thought for similar windows. > But in my opinion the ungrouping worked fine for me in the past, and exactly > as I would like and expect it to be. The behavior has never changed and certainly not before KDE 4.4 > You developers invent a REALLY COOL feature No, tabbing is faar older. No idea, but guess BeOS was the first DE to have this, > which leads to some potential inconsistent behaviour See comment #6 how to resolve it. Dialogs won't be autotabbed. > and now we users complain :) That's actually what developers expect. Otherwise there's no progression. Just in this very case of yours the issue is not size restoring but the fact that a popup dialog is grouped into it's main window. What browser, btw?
> (In reply to comment #7) > > > But why would it do this, when it is grouped to another window? > The window has absolutely no idea that it is in a tabgroup. KWin could > suppress such resize, but that would be wrong because the window likely has > a good reason to do so. Ah, okay. I just thought KWin would already do so, because that would affect all other windows in the group, which maybe would prefer to keep their size. > > I'd think that its size should still stay as X. And return to Y when it is ungrouped. > And to what size should it return if the user has changed the size of the > window/group explicitly (what is not in all cases know by the WM to be > "explicit") To the size it had before it was being put into the tab group. That's what I would expect. I group a window, so it temporarily gets the size of the window group, whatever this size is, and whatever I do with the window group. For me this is a temporary state, and after this, I'd like it to be back as before. But that's only how I see this, and it's not important for me, so just do what you think is correct. > > Which would sound correct to me. > For the limited case you observed because of a buggy tagged window. What is > effectively a dialog should not end up in a window group. Autotabbing is > thought for similar windows. That's what Piotr wrote, not me. I use window groups to group Kontact with Claws, and two Firefox instances that use different profiles. They all stay at their size. And I also group a Dolphin (having two tabs for music and videos, having two panels each) with a Konsole, and normally I also do not change that. Sometimes I maximize the dolphin window, and I am happy that KDE 4.8 will restore the size back as it was before maximizing, which was not working in 4.7, but some time before that. > > But in my opinion the ungrouping worked fine for me in the past, and exactly > > as I would like and expect it to be. > The behavior has never changed and certainly not before KDE 4.4 Hmm... I'm pretty sure that was the case. Anyway, it's not that important. > > You developers invent a REALLY COOL feature > No, tabbing is faar older. No idea, but guess BeOS was the first DE to have > this, Okay :) But for me KWin is the only window manager that I know that has this feature, and I liked and loved it from the very moment when I first tried it. I like the integration of mail, feeds and usenet in Kontact, but I had problems with KMail, and sometimes with Akregator. So I simply grouped replacement programs with Kontact, and again I have all stuff in one window again. > > which leads to some potential inconsistent behaviour > See comment #6 how to resolve it. Dialogs won't be autotabbed. Not my concern :) > > and now we users complain :) > That's actually what developers expect. Otherwise there's no progression. > Just in this very case of yours the issue is not size restoring but the fact > that a popup dialog is grouped into it's main window. > > What browser, btw? Maybe Piotr will answer this... Thanks for the explanations!