Sometime when working with Konqueror I accidentally close the entire application when I mean only to exit from an embedded content. Until recently I considered this an instance of the problem being between the keyboard and the chair. However, recently I have seen users close Digikam and Gwenview in a similar manner: they mean to exit the embedded view and return to the thumbnails, but accidentally close the entire application. I propose an additional window chrome button to reside beside the X (Close) button, which would leave the embedded view and return to the thumbnails / file manager. The presence of such a button near the X (Close) button might [1] help reduce this common error. Thanks. [1] I have not performed any usability tests, this is my personal assessment.
I am sorry, I do not understand what you want to have. Could you please rephrase what exactly is the problem you want to solve.
I think closing a tab in konqueror and switching view in digikam or gwenview are two completely different concepts. Tabs in a MDI application represents different documents, while views in digikam or gwenview are different representations of the same document (album or directory).
Created attachment 64802 [details] mockup Thank you, Martin. Often when using an application which supports both browsing and viewing objects [1][2], users [3] close the entire application when they intend to return to the browsing mode from the embedded file view mode. This RFE attempts to solve or at least mitigate that phenomenon. Attached is an image of three mockups of the Kwin chrome with an additional button for returning to the browsing mode. The intention is to have the "Return To Browsing Mode" button near the X button which is where each of these users clicked to close the application. Thanks. [1] Konqueror: file browser, supports embedded PDF files, text files, and others [2] Digikam: thumbnail browser, supports embedded videos [3] Myself, my neighbour, my mother-in-law
> I think closing a tab in konqueror and > switching view in digikam or gwenview > are two completely different concepts. > Thanks, Anders. I am not referring to different tabs: in each of the applications listed the embedded mode replaces the browsing mode, as opposed to having been opened in a new tab. > Tabs in a MDI application represents > different documents, while views in digikam > or gwenview are different representations > of the same document (album or directory). > The list of files in a directory is certainly _not_ a different view of any particular file in that directory! Maybe I misunderstood your statement.
The window content is completely opaque to the window manager. The window manager does not know whether the window is in an "embedded viewer" mode. There is nothing we can do about that. This has to be solved in a different layer and for that this bug tracker is not useful at all. As from inside KWin we cannot implement this, I set to wontfix. I appreciate that you often bring up ideas for improvements, but in general this bug tracker is not able to handle such feature requests. Ideas like yours should first be evaluated on brainstorm.forum.kde.org and later-on be verified by useability experts and the involved developers for feasibility.
Thank you Martin. I filed the idea here: http://forum.kde.org/brainstorm.php#idea97444_page1 Perhaps a new hook to the window manager could provide this feature for KDE applications when run in Kwin.
(In reply to comment #3) > Often when using an application which supports both browsing > and viewing objects [1][2], users [3] close the entire application when they > intend to return to the browsing mode from the embedded file view mode. This > RFE attempts to solve or at least mitigate that phenomenon. Client issue. (In reply to comment #6) > Perhaps a new hook to the window manager could provide this feature for KDE > applications when run in Kwin. Superflous, the clients receive and can intercept the close request - try to eg close a kwrite window with and unsaved file or think of clients "minimizing" to systray. The client has perfect knowledge about the current state and can treat "the close button" respectively - you want to file a bug against the client. I doubt a new button that would at wost be faked by pressing close twice would help.
Thanks for your input Thomas! It sounds to me that you are suggesting a close-confirmation. Although a close-confirmation would in fact help for the times when the user does not intend to close the application, it would be annoying for the times he does! It would also lead to inconsistency within KDE: some applications will have the confirmation, some wont, and those that do will do it differently. That is why I think that the extra "Close the embedded view" button is an elegant solution: The UI item to close the embedded view is _right_next_to_ the button that the user is going for: the close button. Thus, the user gets the natural workflow that he expects while also getting the ability to use the application properly. (no annoying confirmations or messages that once again, silly user, you have clicked Close when you shouldn't have)
(In reply to comment #8) > It sounds to me that you are suggesting a close-confirmation. Nope, just referred them as proof of concept. Since the client knows that it has entered a confusing state that could mislead users to close the "wrong" window (as you suggested as use case in comment #3) it can simply "ab"use the close request to eg. return from viewing to browsing mode (and actually close on the follow-up close request)
I see what you mean. I respectfully disagree: you are suggesting that the Close button become ambiguous: sometimes it closes the application, sometimes it closes the view. I happen to think that is a step backwards. Some apps (say Digikam and Konqueror) will train the user that he can close the view with the Close button, but then in another app (say Gwenview) the whole app closes! Rather, I think that a KDE-wide, uniform interface object for "Close view" is long overdue. That is what makes KDE a software collection: the idea of consistency across KDE applications. Currently there is no consistency because there is no KDE-sanctioned way to close a view and each app is implementing it differently.
Digikam & Gwenview use toolbuttons to switch between browse & view (digikam btw, shows me a browsing list in the lighttable anyway - i've never tried playing videos with it) Konqueror is a "thing" that iirc started off as webbrowser, and in general it's not uncommon for webbrowsers to open pdfs just as html - but if you went to kde.org, click some link and then close the window, do you expect to return to kde.org? Nope, you'd naturally press "back" what works the same in the filebrowsing mode. I've not seen dolphin showing previews inline. So you basic issue is "konqueror as filebrowser" acts similar to "konqueror as webbrowser" in using kparts and you call that kind of local-webbrowsing-kinda-MDI-wannabe feature into "overdue"? Even if it was, it would certainly not be in the WM (despite that we'd *never* get this through NETWM, a WM with interface items to support client side WM, ie. MDI would be... err perverse) Konqueror would be better off by showing previews in (one or n) additional windows or at least tabs and actually digikam and gwenview should use separate windows as well. This mode switching is just some sort of MDI and since the key issue about MDI is ambiguity a) it should be avoided anyway :-P b) more ambigious close-to-return can by definition not harm more (you're in the very same situation now by misinterpreting the button - this was the trigger for the wish, yesno? By intercepting the close event the client -konqueror- that did would just work as some ppl. might expect while others would still not) Please don't get me wrong - i do see your issue and i take it for real (at least for konqueror and gwenview w/o a side panel), but i see it in the semi-MDI approach and i have to doubt that one could ever turn a control element to control features of specific clients into some sort of protocol extension. So if you'd ask /me/ for a common way to do this, i'd reply to just do not. BTW: There's a MDI UI class in Qt - it's just not used anywhere. PS: Because I've just read comment #5, i'd kindly ask you to continue this by mail if you need and we'd then just post a final conclusion, thanks.