Version: (using KDE 4.4.1) Installed from: Unspecified Linux Popup dialogues in KDE have no taskbar item, and can be minimized below the current window. An Example from Dolphin include the "Switch Application Language" dialogue. Note that other dialogues, such as the Dolphin "Rename" dialogue, do minimize the application when the dialogue is minimized, and the dialogue is never "invisible" below the app.
one dialog is modal (rename) the other (lang) is not. this _would_ be a kdelibs/kapplication issue, but actually it's probably no bug. at least i don't see why this dialog should be modal at all. not showing up in the taskbar seems a tasklib bug (at least the window has no skip properties set) but could be due to the transient (set) state (no idea what taskbars are supposed to show)
yes, it's getting set as transient and so skipped in the taskbar (which is how that's been since kde2 days :), but when minimized the application isn't going with it. if the window manager is thinking that "transient for, but not modal to" means that the window is still indpendant of the main window, then we need to adjust how the taskbar behaves, indeed. another possibility is to deny minimizing of transient windows, much as happens for windows like the toolboxes for the gimp. i'd much rather see the window manager handle this than work around it in the taskbar though, as i'm concerned that such workarounds will create new edge cases with other apps.
You probably know my answer to it: what if we fix it in kwin and someone uses a different window manager? In case of GIMP I think that GIMP disallows minimizing and I think that should be done for this specific window, too. Fixing the app (if we know of which app) is the better way than adding some unspecified workaround in either the window manager or the task manager.
just checked. compiz prevents minimzation of transient (non modal) windows and openbox treats them as modal ones (except for the focus thing, oc) actually it's not really an application issue as the exlusion of the transient state and minimizability (that's probably not a word, sorry :) is not required at all (eg. not everybody uses taskbars and the tab switchers and window list implementations would keep showing it, so it's still accessable by the WM) iff we'd tag windows that allow minimization while being transient to be buggy, we could easily bypass this bug by implying the "unminimizability". the taskbar provides access to (minimized, there's an extra setting) windows but does in this case an incomplete job. i see why taskbars try to unclutter by not showing this, but that needs some coordination with other window representations - netwm spec doesn't say anything about this. therefore the taskbar has to a) define that it is incomplete and needs support of specific WM behaviour to prevent certain user actions, or b) provide complete access (eg. by showing (only) minimized transient windows) given that other major WMs have apparently made concessions to such taskbar limitations, one could just take it as de-facto, while i myself would not really like such limitation... :-( (it would also be important to keep an eye on other taskbar implementation, anybody knows what eg. awm does?)
This review has an approach to mitigate this issue, i've however frankly no idea whether it actually is helpful, but i find taskbars cumbersome in general anyway :-P https://git.reviewboard.kde.org/r/104696/
@Martin The options from our side would be (regarding non-modal transient dialogs) a) prevent minimization b) turn minimize to shade c) turn minimize to lower d) tie dialog to leader (ie. treat it as if it was modal) e) implicitly unminimize dialog with leader activation If we do not want to make any of such concessions to taskbars, we should pass the bug to libtaskbar (if it actually still exists...)
> If we do not want to make any of such concessions to taskbars, we should pass the bug to libtaskbar (if it actually still exists...) I'm going for that option :-)
Script to auto-unminimize minimized windows which will (likely) skip the taskbar. http://kde-look.org/content/show.php?content=161366
*** Bug 330083 has been marked as a duplicate of this bug. ***
Is there anything on the specs that say that transient windows should not be shown on the taskbar? I mean, if it's not modal, it should behave as an independent window (but attached to the transient_for window, so always on top of it), so I guess it should have it's own taskbar entry. There a skip taskbar hint if it's not supposed to be shown. The current behavior is quite bad, since the user doesn't know where the window went. It's not obvious to click twice on the parent window.
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham