One of the areas of Konsole which I really want to give a little love for KDE 4 is the terminal setup ( terminal features, colour schemes, display options, character encoding etc. ) and creation of profiles for different types of terminal.
To get a better idea of what users need from their terminal, I have set up a survey. There are 28 questions, all optional, and opportunities for additional comments at the end. Aside from helping me to understand how you use and set up your terminal, this also gives you a chance to prioritize a few features for KDE 4.
Please help improve Konsole by telling us about your needs and preferences. Completing the survey should only take 5-10 minutes of your time. Thank-you in advance.
Konsole Usage and Preferences Survey
On the subject of surveys, I had difficulty finding a good PHP-based survey system to use. I used phpESP in the end, but recommendations about alternatives would be welcomed.
Thanks to seele for checking the questions and spotting a few problems.
The current roadmap is to implement the new terminal setup facilities in the next month or so, and then merge the development branch into the main KDE 4 trunk. After much tidying up of loose ends, it will be ready for the feature freeze in June.
Showing posts with label konsole. Show all posts
Showing posts with label konsole. Show all posts
Sunday, March 18, 2007
Wednesday, March 7, 2007
Konsole progress - Searching the history
The "Search History" feature has undergone some changes for Konsole / KDE 4. It now uses an incremental search bar in the same vein as Firefox.
Pressing Ctrl+Shift+F ( or using the menu item ) brings up the search bar. Typing in a search term jumps to the first match and highlights all matches in the currently active window. I have seen similar features introduced or improved in other KDE applications for KDE 4. Currently I believe they all use different implementations of the search bar. Ideally we could unify at least some of them.
As well as searching large blocks of text, this is a convenient way to highlight blocks of text on screen matching given patterns. Typical examples include highlighting errors in compiler output or matches for part of a file name.
Under the hood, the searching of large histories ( particularly when using unlimited history ) has been optimized. History saving now uses the ioslaves mechanism which allows saving over SSH, to remote FTP servers amongst others.
Screenshot of new history search (Please note there are some problems in this shot that I am aware of: Main menu items in the wrong order, 'Debug' menu item, not using the session name in the window title etc.)
It has been suggested that "History" should be renamed to "Scrollback" in KDE 4 to avoid confusion with the command history which is maintained by the shell program and typically accessed via the Up/Down arrows. Opinions on this would be welcome.
Other notes, in no particular order:
- Having received much feedback on my first Konsole post, I am using tabs as the navigation mechanism for the time being, unless I can resolve the problems with the other approaches. I also received some help on getting information about the foreground process in the session which I hope to use to enable more helpful tab titles by default.
- This work is being done in a separate branch as I mentioned earlier. Before merging back into trunk, I need to research/design/implement the new Konsole settings system and fix some outstanding issues with split views.
Pressing Ctrl+Shift+F ( or using the menu item ) brings up the search bar. Typing in a search term jumps to the first match and highlights all matches in the currently active window. I have seen similar features introduced or improved in other KDE applications for KDE 4. Currently I believe they all use different implementations of the search bar. Ideally we could unify at least some of them.
As well as searching large blocks of text, this is a convenient way to highlight blocks of text on screen matching given patterns. Typical examples include highlighting errors in compiler output or matches for part of a file name.
Under the hood, the searching of large histories ( particularly when using unlimited history ) has been optimized. History saving now uses the ioslaves mechanism which allows saving over SSH, to remote FTP servers amongst others.
Screenshot of new history search (Please note there are some problems in this shot that I am aware of: Main menu items in the wrong order, 'Debug' menu item, not using the session name in the window title etc.)
It has been suggested that "History" should be renamed to "Scrollback" in KDE 4 to avoid confusion with the command history which is maintained by the shell program and typically accessed via the Up/Down arrows. Opinions on this would be welcome.
Other notes, in no particular order:
- Having received much feedback on my first Konsole post, I am using tabs as the navigation mechanism for the time being, unless I can resolve the problems with the other approaches. I also received some help on getting information about the foreground process in the session which I hope to use to enable more helpful tab titles by default.
- This work is being done in a separate branch as I mentioned earlier. Before merging back into trunk, I need to research/design/implement the new Konsole settings system and fix some outstanding issues with split views.
Wednesday, January 24, 2007
Introductions and the future of Konsole
Hello,
I have been maintaining KDE's terminal program ( Konsole ) since August last year. I'd like to give a brief overview of what is happening for KDE 4. I spent some time triaging bug reports, and talking to KDE users and developers at aKademy to get an idea of what people would like to see in the future. From this I have defined a few goals for the KDE 4.0 release:
- Make it easier to work with many terminal sessions open ( this means navigating between sessions, monitoring activity in sessions etc. )
- Better performance ( mainly when scrolling large screens of output, and also quick startup )
- Make the configuration of Konsole more intuitive
Good progress is being made on the first two of those goals, mostly in the branches/work/konsole-split-view branch in SVN.
As the branch name says, the major feature is the ability to split the view top/bottom so you can, for example, write code in Vim or Emacs in the bottom view and watch the result of a compilation in the top view. Views can be detached and reattached (via a "Merge Windows" option which merges all the open Konsole windows into one). In order to allow views to be moved between windows, I rewrote the front-end as a single-instance application. The KDE libraries make this extremely easy to do. This means that if you launch say, a couple of Konsole windows from the panel, another from the K-Menu, and perhaps another from a shell script, they will all be part of the same process ( plus secondary windows open instantly and less memory is used ).
Split-view screenshot (navigation area not shown)
A much more experimental feature I am playing around with is abandoning tabs and using a list at the side of the window. A little like Kate. The problem with tabs is that they are not very expressive, with only a small amount of text and a tiny icon. Web pages often have sensible titles and associated icons, so this isn't such a problem, but terminal sessions don't. Lists allow the possibility of providing arbitrary information to help users monitor activity in various sessions, and also perhaps using colours or images to make it easier to locate a particular session in the list quickly. The obvious downside is that they consume horizontal space. It is also important to avoid the temptation to go overboard and put too much distracting information there. I want Konsole to feel 'clean' and 'simple', despite its feature set.
It is easy (in the code) to switch between using a list or using tabs, so if the experiment does not work out, or users don't like the change, I can go back to tabs.
A number of backend changes have been made to improve performance. In KDE 3, every time Konsole scrolls the display up one line, it has to move 40KB of data in memory (for a default-sized window) because the screen image was held in one array. In KDE 4, lines of output are stored as reference-counted vectors, so moving the display up one line just involves adjusting the array which keeps track of which vector goes with which line. A side benefit of this is that if you resize the Konsole window to make it smaller, and then make it larger agan, output is not lost as it is in KDE 3. The change which makes the biggest difference for day-to-day usage on large displays is that in KDE 3, every time the display is scrolled, the entire terminal view is repainted from scratch - which involves lots of computationally expensive text rendering. In KDE 4, the emulation gives hints to the view about how the image has been transformed since the last display update, and the view can use this to achieve the same result in a cheaper fashion (eg. using the standard widget scrolling mechanism instead of repainting every line when you scroll up or down one or two lines).
KDE 4 is still a long way from release, so there is a "new" KDE 3 feature to keep the 'candy whores happy ;). KDE 3's Konsole has a compile-time option to enable true-transparency. This is not very convenient because you have to recompile the code yourself to get the effect. So for KDE 3.5.7 it has been made into a command-line option, accessible like so:
konsole --real-transparency
This is not enabled by default because I need to find a reasonably reliable test for a compositing manager, and also because UI changes are necessary to allow users to choose between fake and real transparency ( yes, there are plenty of users who prefer the "fake" system used at present ) - that will probably have to wait until KDE 4.
I have been maintaining KDE's terminal program ( Konsole ) since August last year. I'd like to give a brief overview of what is happening for KDE 4. I spent some time triaging bug reports, and talking to KDE users and developers at aKademy to get an idea of what people would like to see in the future. From this I have defined a few goals for the KDE 4.0 release:
- Make it easier to work with many terminal sessions open ( this means navigating between sessions, monitoring activity in sessions etc. )
- Better performance ( mainly when scrolling large screens of output, and also quick startup )
- Make the configuration of Konsole more intuitive
Good progress is being made on the first two of those goals, mostly in the branches/work/konsole-split-view branch in SVN.
As the branch name says, the major feature is the ability to split the view top/bottom so you can, for example, write code in Vim or Emacs in the bottom view and watch the result of a compilation in the top view. Views can be detached and reattached (via a "Merge Windows" option which merges all the open Konsole windows into one). In order to allow views to be moved between windows, I rewrote the front-end as a single-instance application. The KDE libraries make this extremely easy to do. This means that if you launch say, a couple of Konsole windows from the panel, another from the K-Menu, and perhaps another from a shell script, they will all be part of the same process ( plus secondary windows open instantly and less memory is used ).
Split-view screenshot (navigation area not shown)
A much more experimental feature I am playing around with is abandoning tabs and using a list at the side of the window. A little like Kate. The problem with tabs is that they are not very expressive, with only a small amount of text and a tiny icon. Web pages often have sensible titles and associated icons, so this isn't such a problem, but terminal sessions don't. Lists allow the possibility of providing arbitrary information to help users monitor activity in various sessions, and also perhaps using colours or images to make it easier to locate a particular session in the list quickly. The obvious downside is that they consume horizontal space. It is also important to avoid the temptation to go overboard and put too much distracting information there. I want Konsole to feel 'clean' and 'simple', despite its feature set.
It is easy (in the code) to switch between using a list or using tabs, so if the experiment does not work out, or users don't like the change, I can go back to tabs.
A number of backend changes have been made to improve performance. In KDE 3, every time Konsole scrolls the display up one line, it has to move 40KB of data in memory (for a default-sized window) because the screen image was held in one array. In KDE 4, lines of output are stored as reference-counted vectors, so moving the display up one line just involves adjusting the array which keeps track of which vector goes with which line. A side benefit of this is that if you resize the Konsole window to make it smaller, and then make it larger agan, output is not lost as it is in KDE 3. The change which makes the biggest difference for day-to-day usage on large displays is that in KDE 3, every time the display is scrolled, the entire terminal view is repainted from scratch - which involves lots of computationally expensive text rendering. In KDE 4, the emulation gives hints to the view about how the image has been transformed since the last display update, and the view can use this to achieve the same result in a cheaper fashion (eg. using the standard widget scrolling mechanism instead of repainting every line when you scroll up or down one or two lines).
KDE 4 is still a long way from release, so there is a "new" KDE 3 feature to keep the 'candy whores happy ;). KDE 3's Konsole has a compile-time option to enable true-transparency. This is not very convenient because you have to recompile the code yourself to get the effect. So for KDE 3.5.7 it has been made into a command-line option, accessible like so:
konsole --real-transparency
This is not enabled by default because I need to find a reasonably reliable test for a compositing manager, and also because UI changes are necessary to allow users to choose between fake and real transparency ( yes, there are plenty of users who prefer the "fake" system used at present ) - that will probably have to wait until KDE 4.
Subscribe to:
Posts (Atom)