Version: (using Devel) Installed from: Compiled sources OS: Linux When you enter Ctrl+Shift+n it gives you a new tab, it would be nice to have a selection of profiles if I have defined more than one. If there is only one profile then it can just open that one. If you do not have this then you have to resort to the menu each time which is not very quick, plus you have to remember different actions for your default profile compared to others.
> When you enter Ctrl+Shift+n it gives you a new tab, > it would be nice to have a selection of profiles if I have defined more than one Ctrl+Shift+N means "new tab using my default settings." Popping up a selection of profiles every time you pressed it would certainly annoy me and I'm sure it would other users. There is a way to get quick access to different profiles which is to set a shortcut for the profile in the Manage Profiles dialog. Pressing the shortcut will create a new tab using that profile. eg. I use "Ctrl+Shift+K" for a new KDE 4 development session and "Ctrl+Alt+R" for a release-mode KDE session.
I see... In that case, can this bug be changed to something like 'Shortcuts in edit profiles does not work'. If you look at the edit profiles dialog: 1. The default shortcut is not populated next to the default 2. The shortcut box does not use the same selector as system settings (ie. Desktop->Desktop Effects->All effects->settings or keyboard & mouse->keyboard shortcuts).
> 'Shortcuts in edit profiles does not work' They do work, it is just that the shortcuts have to be typed out manually at the moment. eg. "Ctrl+Alt+L" rather than pressing those keys. > 1. The default shortcut is not populated next to the default Pressing "Ctrl+Shift+N" will always launch the default profile but you can assign an additional shortcut to whichever profile happens to be the default. I could add a note to the dialog that the default profile is the one which is opened when triggering the "New Tab" or "New Window" actions. > 2. The shortcut box does not use the same selector as system settings That has been reported as bug# 149626
How about removing the concept of changing the default shell alltogether? If you made 'Shell' the default permanently then you can still edit the default shell plus you could then populate the short cut next to it and remove it from the profile list in the file menu. Not having default looks like it would reduce a lot of complexity and an advanced user could still replicate the functionality we have now. I cannot really see a use case for that though.
> Not having default looks like it would reduce a lot of complexity I don't really a see "a lot of complexity" in the way Konsole works now. The only complexity having a customisable default adds is a single button in the Manage Profiles dialog. Ultimately when Konsole starts up it needs to get the settings for the first terminal from somewhere and I think it makes sense to allow users to choose that 'somewhere'. > an advanced user could still replicate the functionality we have now Profiles are really only of interest to heavy terminal users. Light users will set Konsole up the way they like it during the first few times they use it and then leave the settings alone thereafter. > I cannot really see a use case for that though. I can. I have profiles for doing certain types of work (eg. KDE Development). When I find myself doing that a lot for a period of time then I can make that the default for a while, still keeping the standard "Shell" around for when it is needed.
> They do work, it is just that the shortcuts have to be typed out manually at the moment. That has now been fixed.
Re : complexity. I did not mean to remove the default alltogether, but just to disallow the changing of the default. Confusing is the default menu. You currently have new tab, new window and 'Shell' - shell is exactly the same as 'new tab'. This is confusing. I have also learned that a surprisingly large number of users do not have a clue what default means (I have been asked a few times). Once you add some profiles then you have to understand that new tab is the same as what you have set for default. It would be better if 'Shell' was removed so only advanced users will see the extra profiles. It might be even better if the new window and tab could have a sub menu. Having an advanced usage where konsole can change default profile on startup could possibly be added with a command line switch and the ability to set default could just be removed. That way the default profile shortcut could be populated without worrying about what happens when they change default (ie ditch any custom shortcut for the new default and replace with ctrl+shift+n).
"I have also learned that a surprisingly large number of users do not have a clue what default means" Those are probably not users who would ever use a terminal though, unless they were being walked through fixing a problem with their system. I assume that everyone using Konsole for any extended period of time is a technically competent power-user. They might be new to Unix, Linux or command-line interfaces generally but are otherwise power users. > You currently have new tab, new window and 'Shell' - shell is > exactly the same as 'new tab'. This is confusing. Okay I see. In that case it seems that the problem can be fixed by re-arranging the File menu. There is a related problem that it is not currently possible to create new windows with a non-default profile. The obvious alternative is to make "New Tab" and "New Window" sub-menus with the profile list in each. The problem then is that it adds an extra menu that people have to go through.
OK - To try to simplify things, here are my main problems (from a usability/consistency POV), and possible solutions. 1. 'Shell' is the same as new tab (unless you have changed the default). Solution - Remove the default from the extra list, this means that only new window and new tab will show on a new install. 2. When you open the edit profiles dialog the shortcut for 'Shell' is not set. Does this mean I can have 2 shortcuts for the same thing (with one being variable depending on my default profile)? The solution is to set the Shortcut next to the 'Shell' as Ctrl+Shift+n, the problem is when you change the default this will change too and possibly overwrite the new profile's shortcut. This problem leads me to... 3. The 'change default' feature changes some of the above actions so maybe the ability to change default could be removed from the GUI. You will still have default as 'Shell' but the user will not normally be able to change it. You will then be able to populate the edit profiles shortcut and it will not be possible to have 2 shortcuts for the same thing. I do not think sub menus are nice, it is good the way it is. 4. Could we have a look at bookmarks and profiles? I think the metaphors are borrowed from konqueror, but they are different in their action (correct me if I am wrong). In konqueror the profile completely changes the app and the way it behaves, bookmarks take you to a specific url. In konsole, profiles give you a shell with a certain background color and maybe executes a different shell or sets some variables, bookmarks are just a way of cd'ing to a directory. To me a profile should actually be a bookmark, there is little use in having a quick cd command, power users can create symlinks if they are hard-of-typing. Another anology, on my browser I have a bookmark on my sites administration, in konsole I have a very similar thing, but for some reason in that app it is called a profile (ie. log into same server via ssh). 5. This is getting slightly off-topic, but the profiles reorder themselves (in the file menu) every time you change something. The aim of KDE4 (again correct me if I am wrong) is to simplify applications whilst still retaining power. I feel that because konsole is seen as a power app, it is somehow exempt from this, but even power users want simple to use but powerful apps. I feel that some options and features are extraneous and cause complications for both the user and the developer (because of extra possible bugs or misunderstandings).
> 3. The 'change default' feature changes some of the above actions so > maybe the ability to change default could be removed from the GUI. As I said before, I have a need for this feature and other people who often use a different shell or environment will likely also have this need. > I think the metaphors are borrowed from konqueror, Bookmarks consist only of a location, which may be a local folder or an SSH login and basic metadata such as a name and comments. This is consistent throughout KDE and the same editor is provided to edit bookmarks, import and export bookmarks in all applications. The same icons and menu items are used for them everywhere. As far as I can see, the function is the same in Konqueror and Konsole. In Konqueror a bookmark takes you to a directory or web page. In Konsole it takes you to a directory or computer. Bookmarks don't manage any other settings. I agree that there are alternatives for bookmarks for quickly changing to a directory or connecting to a computer. This was a feature left over from KDE 3 which doesn't add a lot of complexity to the code or noise to the UI so I left it in. Ultimately I view the "Bookmarks" feature as a hack around the poor directory navigation features which bash provides. It would be better to fix the problem at the shell level. Profiles are a concept specific to Konsole. They are a complete set of settings which define a working environment. This includes the shell to run, environment, initial directory, color scheme, terminal settings and key bindings for input. > The aim of KDE4 (again correct me if I am wrong) is to simplify > applications whilst still retaining power. That is a goal of mine and I think Konsole 2.0 achieves this for the most part. KDE 4 itself as a big umbrella project lacks a well-defined global vision unfortunately. > I feel that because konsole is seen as a power app, it is somehow > exempt from this, but even power users want simple to use but powerful apps. They also want flexibility. Walking around the workstations and laptops at KDE's conferences I can see a fair variety in the way people have their terminals set up, the applications they use with them and so on. I am sure that I would get unhappy users if I stripped them of basic choices. > cause complications for both the user and the developer > (because of extra possible bugs or misunderstandings). In this case, the presence of a changeable default adds very little complexity to the code. You can verify that for yourself if you wish. As for user confusion, there are a number of usability bugs in Konsole 2.0 which have been reported, this has not been one of them. The most common problem naturally is the change from KDE 3 to 4 where users expect things to work the same way as they did in the past. That is to be expected.
> Bookmarks consist only of a location, which may be a local folder or an SSH login and basic metadata such as a name and comments. I did not know that a bookmark allowed you to bookmark a SSH login, there is no way to know unless you RTFM. Will it also save the directory on the remote server?, or any environmental variables that I have set? Will it also save a chroot on this machine or a local one? These might sound like unreasonable requests but some of them are possible by using profiles. If profiles were beefed up slightly in some areas, trimmed down in others and then renamed bookmarks then it would reduce a lot of complexity (from a user point of view), whilst still keeping all of the power. I suppose your main objection to this would be this > In Konqueror a bookmark takes you to a directory or web page. In Konsole it takes you to a directory or computer. Bookmarks don't manage any other settings. In which case you are restricting the use of bookmarks just because of a browser, other apps could require extra data in a bookmark, amarok for example could bookmark a song at a specific point, I am sure other apps could add their own data to a bookmark which is not needed for konqueror (ie current tool in Krita, visible toolbars etc). You may not think it adds complexity but it makes the user think about what they are doing and how konsole works in the background. Consider this case.. I have 2 bookmarks, on shh://server and one /mydir on my local machine. I click the bookmark for /mydir, do something, then I click the bookmark for the server and then remember I forgot to do something in /mydir so I click its bookmark. /mydir does not exist on the remote machine and therefore just produces an error. Then I have to stop and think and press Ctrl+D and then select the bookmark. > I agree that there are alternatives for bookmarks for quickly changing to a directory or connecting to a computer. This was a feature left over from KDE 3 which doesn't add a lot of complexity to the code or noise to the UI so I left it in. Ultimately I view the "Bookmarks" feature as a hack around the poor directory navigation features which bash provides. It would be better to fix the problem at the shell level. I suspect the reason that it does not add a lot of complexity is because it is almost useless (and because there are better solutions to the problem). If you are concerned about navigating directories then it would be really nice to have a dolphin-like navigation bar which could be used to change directories. Not sure how this would work though.
> or any environmental variables that I have set? No, it only remembers the host and username passed on the shell. Ideally it would include the directory on the remote machine but that information is difficult to get. > In which case you are restricting the use of bookmarks just because of a browser This is not the case. The limitation is that bookmarks deal with locations (which happen to be represented by URLs), they do not include any state information. Of the examples you gave, pointing to a specific point in a song would be a compatible with this concept. Recording the state of toolbars in Krita would not be. That would be like including your browser cache settings in a website bookmark. > I suspect the reason that it does not add a lot of complexity is because it is almost useless The reason is that most of the functionality is provided by the KDE IO libraries. Bookmarks are indeed a pretty simple and crude feature in Konsole. However, some people do find them useful so I left them in.
The big difference is that a browser ties the state to the location, all the other apps do not. There could be 2 bookmarks for the same location but with different background colors or env vars in which case you have to resort to profiles because that is one feature too far. Couldnt konsole store what it can in the KDE bookmarks, but then store its own additional data based on the bookmark not the location? I realise this would cause problems with the default bookmark editor, but I am not sure how big those problems would be. There are also concepts which blur the state/location boundary (selected layer in krita), so I still think the need for extra metadata in bookmarks are needed globally.
> The big difference is that a browser ties the state to the location, all the other apps do not. That isn't right. Browsers keep site-specific state information in cookies, which are not kept in bookmarks. Some websites may encode state information in URLs but I would not expect bookmarking my banking site to remember my authentication state or expect bookmarking a product page in a shop to remember the contents of my shopping basket. I think it might actually be useful to have a feature which could record the complete state of a browsing session or a terminal session that could be replayed in future but you would have to pick a new name (ie. not "Bookmarks") for the feature to avoid breaking expectations based on existing use of the term. Both on the web and in the terminal there are technical hurdles to implementing such a feature. In the web, the current state is often held partly by the browser and partly by the web site. Quite often the browser stores only a unique ID and everything else is recorded by the web site in a database somewhere. In the terminal, the current state is mostly held by a process outside of Konsole which may well be running on another computer. The accessible information is limited to a local processes' /proc/pid/status file. So the current bookmarks implementation represents the best of what I can do within the confines of Konsole.
> That isn't right. Browsers keep site-specific state information in cookies, which are not kept in bookmarks. Some websites may encode state information in URLs but I would not expect bookmarking my banking site to remember my authentication state or expect bookmarking a product page in a shop to remember the contents of my shopping basket. What I meant was that the state information is TIED to the location, ie. one location == one state. You cannot view a website with one set of cookies and then switch to another set of cookies (except with some advanced webmaster tools). Also when you change location the state (ie. the set of cookies associated with that domain) changes as well. In konsole you want a state to persist across different locations and a single location to have more than one state. If I cd to another directory the state will not change, but on the web each location only has access to a particular set of cookies (state). > In the web, the current state is often held partly by the browser and partly by the web site. Quite often the browser stores only a unique ID and everything else is recorded by the web site in a database somewhere. The state may be actually stored in cookies, but it is not the browser that controls that state, the location (web site) is in control of setting and deleting cookies, even server side state is controlled by cookies. In konsole there is no sentient website at a location, it is normally a dumb directory which cannot tell you to make the konsole background yellow here. Konsole is 100% in charge of the state. > In the terminal, the current state is mostly held by a process outside of Konsole which may well be running on another computer. The accessible information is limited to a local processes' /proc/pid/status file. So the current bookmarks implementation represents the best of what I can do within the confines of Konsole. I am aware that there are probably a lot of limitations, by state I mean konsole state like color, environmental variables set, starting program etc. If there are limitations which mean that half of the functionality does not work then it is just confusing to have that functionality. At the moment the only way to test if something actually works is to try it. Switching profiles does not work properly, and neither do bookmarks, so I really think something is needed here.
> Switching profiles does not work properly What exactly do you mean by "does not work properly"? There are a small number of properties (command, initial directory, environment) which cannot be changed after starting a session but everything else can be. I think a little common sense and very basic UNIX knowledge can tell you which settings can be changed after starting a session. > and neither do bookmarks All that is supposed to happen when you click on a bookmark is that it prints "cd <dir>\n" or "ssh usr@host\n" to the terminal. That works. If you want it to do something else then it is a case of prototypes or UI designs welcome. In any case this is getting away from the original bug report. It is something which I will not be implementing because there is a mechanism to provide quick access to profiles.