Version: 2.9.4-2 (using KDE 4.2.2) OS: Linux Installed from: Debian testing/unstable Packages I'm using a TwinView dual-screen setup where one screen is smaller than the other : one is 1200px tall and the other 1024. Yakuake is configured to use 100% of the height. Opening Yakuake on the small screen does not show the shell tab list at all. Application title bar is correctly drawn and yakuake honors the bottom panel setting (not overlapping it). Using the exact same setup worked differently in KDE 3 except that setting height to 100% had the effect of yakuake using at most 1024px of height wherever I popped it out.
I currently don't have the dual-head setup required to try and reproduce this problem, sorry. I'll try to organize a second monitor, but it may take some time.
I'm seeing this behaviour too. It seems that yakuake's own window is getting correctly resized to fit the smaller screen, but the internal part (the konsole part, or perhaps a container around it which contains both the terminal display and the tabs) isn't getting resized. You might be able to reproduce the bug by switching from a high resolution to one with a lower y value, though I'm not able to test this on my current setup. It looks like something needs to be added to check when the main window is resized by an app other than yakuake, to then trigger a resize for the internal container too. Not knowing the yakuake source very well, I'm not sure if this makes much sense, but that's the way it looks to me :-) Thanks.
Actually the way it works is that when Yakuake gets moved between screens by something other than itself (say, KWin's shortcuts to move a window to a different screen), it does take notice, and will recalculate what "100%" means and adjust its window size and position accordingly, as well as move the widgets within the window into the correct positions. Other circumstances in which Yakuake recalculates and adjusts its size and position are right before it is opened (necessary due to the "Open on the same screen as where the mouse pointer is" option) as well as when the size of the work area changes (due to a screen resolution change or someone changing the size of their panel(s)). (And of course when changing the screen from within Yakuake as well.)
Interesting. I'm happy to have a look at this, since I can reproduce the bug quite reliably. But as I say I don't know my way around the yakuake code. If you could perhaps point me in the direction of the place where the recalculation and adjustment happens in the case described, I could do some debugging... Thanks.
Sure, since I still don't have a multi-head setup (I used to have one when I wrote this stuff, though, and it worked at the time), I appreciate the offer. All the stuff of interest is in mainwindow.cpp. When the Yakuake window is moved around, MainWindow::moveEvent() runs and calls MainWindow::applyWindowGeometry(), which ends up calling MainWindow::setWindowGeometry() where the real work happens. Similarly, switching screens from within Yakuake via the menu calls MainWindow::setScreen() which ends up calling MainWindow::applyWindowGeometry() again. A work area change also results in applyWindowGeometry() being called.
This should hopefully be fixed in git master and the upcoming 2.9.9 release.