Bug 58672 - terminal emulator and shortcuts
Summary: terminal emulator and shortcuts
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist with 50 votes (vote)
Target Milestone: ---
Assignee: Konqueror Developers
Depends on:
Reported: 2003-05-19 07:57 UTC by Norberto Bensa
Modified: 2009-09-13 22:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Norberto Bensa 2003-05-19 07:57:56 UTC
Version:            (using KDE KDE 3.1.1a)
Installed from:    Gentoo Packages
Compiler:          gcc 3.2.2 
OS:          Linux

I like backspace as back shortcut, unfortunately, if I open terminal emulator and I press backspace, konqueror follows my orders and goes back ;-)

So I have two options:

a) use ^H

b) don't mistype commands (unlikely.)

Comment 1 Thiago Macieira 2003-05-19 15:28:25 UTC
Cannot reproduce it in HEAD CVS. 
Are your terminal settings for backspace (as given by stty) correct in the emulator? 
Comment 2 Norberto Bensa 2003-05-19 18:46:29 UTC
Subject: Re:  terminal emulator and shortcuts

nbensa@venkman ~ $ date ; echo ${Thiago Macieira}
Monday 19 May 2003 10:28 am

> Are your terminal settings for backspace (as given by stty) correct in the
> emulator?


I don't know what you mean with stty, how do I check?

As for testing, I forgot to tell you to open konqueror (in file manager mode,) 
browse (open) a folder or two, open terminal, hit backspace. Note: backspace 
needs to be assigned to back (settings -> configure shortcuts -> konqueror -> 
back.) If it can't be reproduced in CVS, then it's fixed.

Comment 3 Thiago Macieira 2003-07-02 13:36:24 UTC
I can confirm this. 
If a key is associated with a shortcut, it takes precedence over the terminal 
settings. That's why the default association is Ctrl+Up. 
Do we want this feature? 
Comment 4 Norberto Bensa 2004-02-05 04:01:13 UTC
> Do we want this feature? 

I'd like terminal to take precedence (if possible)
Comment 5 Imre Tuske 2004-10-07 02:16:49 UTC
I'd like terminal to take precedence, too, please. The current behaviour is very confusing.

Comment 6 Sujee Maniyam 2005-04-04 04:46:17 UTC
confirmed on Konq 3.4 (on Mandrake 10.1, compiled with Konstruct).

I think the solution is, when Term Emulator has the focus, it should be processing the keys, not Konq.
Comment 7 S.H. 2005-06-19 04:50:07 UTC
This becomes even more annoying when you have kghostview part open, which steals all spaces from the terminal.

the terminal is unusable without spaces!

I also think that "when Term Emulator has the focus, it should be processing the keys, not Konq."
Comment 8 Mircea Bardac 2005-07-24 01:27:33 UTC
+1 from me.

IMO, the only reasons for somebody to keep the terminal openend in the same konqueror window (with or without kparts loaded) is to:
1. keep in sync the dir in the (list/tree/*)view with the dir in the terminal
2. see direct actions over the files the current dir, as ordered in the terminal

These 2 activities (or ways of seeing this situation) are mutually exclusive when it comes to keyboard shortcuts and therefore, the solution would be, depending on the situation:
1. enable ALL shortcuts when konqueror (or any kpart) has focus
2. disable ALL shortcuts when konqueror (or any kpart) does not have focus (I have first thought the "editing keys" could be filtered out, but then I've remembered some terminal apps make use of all keys, such as functions keys for example)
Comment 9 Mircea Bardac 2005-07-24 01:49:44 UTC
I feel the need to somehow correct me:
If I am in a KPart, I expect the navigation shortcuts to work consistent within the entire navigation procedure.
The navigation shortcuts which shouldn't be overridden by the KPart:
* up -> focusing on the element represented in the KPart (note that some KParts can navigate throught the files by themselves, thus changing the "originating" selection - this might require adding a new attribute to the KPart (something like "returnPath")
* back -> actually doing the same as "up", but focus should be returned to "originatingPath" - should similar to the "returnPath"; returnPath==originatingPath when KPart is initialized; returnPath changes if the KPart navigates by itself (hmm... konqueror might be doing this right now, haven't checked thoroughly)
* forward

The KPart may define it's own shortcuts for navigating inside itself (PgDown for next page for example).

Anyhow, I don't think the terminal should be considered a KPart because it can run apps inside it, apps which might require full keyboard support.
Comment 10 Mircea Bardac 2005-08-02 01:33:43 UTC
I have rethought this a bit. Note that I don't have much knowledge about the inner workings of KDE and I'm trying to understand it only by follwing its design:

There are 2 types of KParts (the way I think this should be):
a) KParts which can navigate (with attribute canNavigate==true) - these are actually views, just like ListView, IconView, DetailedView etc. and should be treated the same way
b) KParts which can't navigate (with attribute canNavigate==false) - these are only viewers

The history browser should contain paired info on (KPart, KIO_resource) shown at  a certain moment, in a part of a window.

Let's assume a user is browsing through a pictures folder /home/users/pictures. He has highlited picture001.jpg. The current shown resource is /home/users/pictures/. The current KPart is (let's say KPartFileMan). The selected resource is /home/users/pictures/picture001.jpg

There are 2 KParts available for viewing pictures: KPartPictureBrowser (canNavigate==true) and KPartViewer (canNavigate==false).

a) users picks the KPartPictureBrowser from the View options.
Konqueror saves in the history browser (KPartFileMan,/home/users/pictures/picture001.jpg). KPartFileMan is a navigating KPart and, when the full resource is passed to it, it will understand and show /home/users/pictures/ (=KIO_resource.parent()) with picture001.jpg selected. Long-pressing the Back button should only list (icon_for_KPartFileMan /home/users/pictures/). We don't want to confuse users by showing the name of the entire resource, since the user is aware that he was navigating.

While being in KPartPictureBrowser:
1. Up will take the user to KIO_resource.parent(), adding (KPartPictureBrowser,/home/users/pictures/picture003.jpg - the currently selected picture) to the history, listing only (icon_for_KPartPictureBrowser /home/users/pictures/)
2. pressing back (without pressing up), will take the user to KPartFileMan, /home/user/pictures, with picture001.jpg selected.

This way, a good track will be kept throughout the used KParts and resources.

b) when the user would click picture001.jpg, the KPartViewer would load, saving first (KPartFileMan,/home/users/pictures/picture001.jpg) in the history.
1. Assuming the user changes the address without leaving the KPartViewer, in the history you will get (KPartViewer,/home/users/pictures/picture001.jpg), showing up as (icon_for_KPartViewer,/home/users/pictures/picture001.jpg) - full resource path this time since the KPart is not a navigating KPart. The new address (resource) should be interpreted with the default KPart associated for it.
2. If the user presses back, the KPartFileMan would load /home/users/pictures/, with picture001.jpg loaded.
Comment 11 Mircea Bardac 2005-08-02 01:37:23 UTC
for b)
Up pressed should load the default KPart for KIO_resource.parent().
Comment 12 Mircea Bardac 2005-08-06 23:42:00 UTC
old bug/wish, somehow related to this task, but closed with "WON'T FIX": http://bugs.kde.org/show_bug.cgi?id=78445
Comment 13 Zachary Jensen 2005-08-07 00:19:24 UTC
In a related topic, if I assign backspace to the back button for Konqueror, place the carat in a text box (in a web page), then push backspace, Konq will also go back. I'm not sure whether it deletes the character as well.

This may have been fixed a while ago... I havn't checked recently.
Comment 14 Martin Zbořil 2005-08-20 00:17:08 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Mircea Bardac 2005-09-03 16:11:44 UTC
I have a small feeling this could all be resolved redesigning the KParts core. I don't think it has much to do with the terminal emulator shortcuts, I believe it has something to do with shortcuts in KParts in general.
Comment 16 FiNeX 2009-09-13 22:09:20 UTC
All reports about file management mode reported against KDE 3 (konqueror) has been closed: konqueror in KDE 3 is no more developed and mantained. All bugs and wishes which could be interesting for Dolphin in KDE 4 (the new KDE file manager) has been collected into a specific list.

Please try the new file manager before request new features and report bugs.

Before submitting new reports check carefully the already opened KDE/Dolphin reports in order not to add duplicates.

Many thanks.