This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Additional window chrome button: Close Embedded View

-1

Votes
6
7
Tags: None
(comma "," separated)
User avatar
dotancohen
Registered Member
Posts
59
Karma
0
OS
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 [0] help
reduce this common error.

‎To clarify: 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 [4] 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.


[0] I have not performed any usability tests, this is my personal assessment.
[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
[4] http://bugsfiles.kde.org/attachment.cgi?id=64802


dotancohen, proud to be a member of KDE forums since 2008-Oct.
radiadoring
Registered Member
Posts
2
Karma
0
o clarify: 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.
User avatar
arkascha
Registered Member
Posts
192
Karma
0
OS
This makes sense, I like it.
But maybe the button can be named more general, since "browsing" is specific for certain applications tasks.

- "close mode" or
- "return to base mode"
User avatar
Fri13
Registered Member
Posts
397
Karma
4
OS
That functionality is suppose to be in the app itself, not in window manager.

Like when you go from thumbnail view to preview or fullscreen view, the way how you got there should be same way to back.

Examples: Click/Double click the image to get from thumbnail view to preview mode. So Click/Double click to get back.

Click "Full screen" button in toolbar and the view should get back by pressing same button (like Preview view to Thumbnail view) and it is presented as button is pressed and normal.

The not correct way is to move the action to somewhere else than where you came from. Like thats why we have one button what maximize the window and what un-maximize the window.
We have button what selects a file and what un-selects it as well (as Dolphin single click function).

Example of Dolphin functionality when you add "preview" button to toolbar. When you dont have previews enabled, the button is like any button on toolbar. But when you click "preview" then it gets pressed and you can see previews of the files. When you want out of that mode, you press again the same button what is signaled with the visual effect it is enabled.

If user gets to one situation by one way, it should be possible get back by doing same thing in reverse.

And that is one reason to configure KDE in one specific way.
I have noticed people close windows too easily. When not needed or actually not meant. The thing is that people finds it messy if there is many window open. They want to clean up the view to think straight.
And they either plan to ahead a lot. Like they browse few websites and then they close window. And after few minutes they re-open browser and reopen the same sites or other sites.
Why didn't users just minimize the window to taskpanel or let it be behind other apps?

Minimizing windows is other thing. You have button on window decoration but when pressing it, the window gets hided. Where is it? Even this kind thing is hard to people as they dont understand it goes to taskpanel unless it is animated (thanks magic lamp effect!).

How to get window back? You click it on _taskpanel_.
What I did? I removed the "minimize" button from decoration and teached people that when they want to get window minized, they need to click it on taskpanel.

So people learn that taskpanel is the place where window can be hided and unhided when not needed. Logical and very easy.


The embedded view is something from what should be easy to come back with the app own UI itself. Like when we open a okular inside a konqueror when opening a PDF file. The embedded view is like opening a folder. To get back, you click up or you click back button. It is browsing after all.

What version of digiKam it is about?

Example of the current 2.2 version it looks like this:

http://imgur.com/a/Atdx4#1

Look closely the toolbar buttons of "Thumbnails" and "View Image" (should be changed as "preview" as digiKam can show videos). From those two buttons, you can switch between image preview and thumbnails mode.

With that example, to clarify the different ways to allow user to switch view modes, the buttons "Thumbnails" and "View Image" could be merged. So they are the one what switch icon and text.
When in thumbnail mode it could say "preview mode" and when in "preview mode" it could say "thumbnail mode".
But it should be as well pressed and un-pressed depending situation.

But usability studies has shown that changing text when changing the button state is not good thing. As then two different modes change same time. ON/OFF mode and action.

But that is how the "embedded view" mode should be possible "turn off". Not from window managers button what has nothing to do with the window manager.

For konqueror embedded views (via kparts) I can not talk so much, as it should be brought up in kde usability mailing list as well. But it seems that digiKam have been changed since the version what you use.

The Gwenview has as well two buttons on its toolbar, a "Browse" and "View" and I believe it is clear on it.

One thing what I once tested as well as I did with minimize button. Was that I removed the "Close" button.
So only way to close a window was to middle click on taskpanel. It really well teached users habits to close windows when it was not actually smart thing. So instead people using time to manage windows and spend time to relaunching applications so much. They started to keep them open and actually switching between them and using virtual desktops more. And they liked it very much.

And few days ago one of my friend said that graphical desktops should have such feature as smart phones do. That the program process is hibernated instead being shutdown.
And the close button at window decoration would simply hide the application and store its place, state and file until recalled later. And he did not know what Apple had done with Lion with its saving system.

And I explained we could do the same thing with KDE and its activities. Instead just hibernating activity, we could simply hibernate the current application. So when user opens the file, it and application opening it would be refreshed from hibernation.

And that is sorta made with Blender (3D modeler) application what allows to store application state to file itself. So when you send file to someone else or open it up on other computer. You get your settings (view, shortcuts etc) as well.

And even Inkscape does partially same thing.

So instead being just files and applications. They work more like content. But it demands you have the content what can be opened with same application and the file format is such it can store such information.

This just saying about the peoples habit to close the window too quickly when they dont even want or meant that to be done.

You could try as well that, removing the "close" and "minimize" buttons. Make the taskpanel to be usefull instead just "there". And you can as well use KWin functions more like to maximize window by dragging it top of the screen or 50% or 25% size by dragging side of the screen.

By that way, you can remove all the buttons from KWin. And if wanted to easy way to close windows, configure KWin so that double click at window decoration close it.

As I have always wondered why people insist having just one or two window open at same time while we have enough RAM and screen space to actually hold them all open at same time and virtual desktops to get when needed a new empty desktop.
Way Walker
Registered Member
Posts
17
Karma
0
OS
I'd like to see this, or something similar, since it would also allow applications to work better with kwin grouping. In rekonq and Opera I turn off their own tabbing functionality and use kwin's grouping instead. This also works nicely with Okular and KWrite. So, it would be nice to be able to distinguish between "close document" and "quit application" in the titlebar.

Another possibility would be something like the gesture support to the window manager where, instead of a gesture, you could add a custom button that would send a command to the window.


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Sogou [Bot]