[Konsole-devel] Konsole development

[Robert Knight]

> Really? Why would I want a scrollback limit of 10000 in one
> session and a scrollback limit of 100 in another?

For some tabs you might want to run a command which produces a lot of
output which you may want to browse
or search later, in which case unlimited scrollback is useful.  This
however can make the scrollbar very sensitive
in that scrolling it a small amount covers a large number of lines,
which is not so useful if you're only interested
in the recent history of the tab.

There is also a cost in terms of disk space and memory used for
unlimited scrollback.

Often the appropriate thing is to run the command such that the output
goes into a log file and then
use less or other tools to process it.  This however is not always
convenient because you have to remember to
do it before running the command.

So perhaps there is a better way to solve the aforementioned problems
but unless one is implemented,
we need to retain this feature.

Regards,
Robert.

On 4 March 2010 11:20, Sascha Peilicke <sasch.pe at gmx.de> wrote:
> On Wednesday 03 March 2010 23:25:55 you wrote:
>> Hello,
>>
>> > I attached some screenshots which show some issues. IMHO all the View*
>> > related classes are just to complex.
>>
>> Back in the KDE 4.0x days the Q/KTabWidget classes had lots of clutter
>> around them
>> which could not be turned off which is why they were not used.
>> QTabWidget gained
>> a 'document mode' since then which I think does what is needed.
>> Originally I also
>> wasn't sure if we'd stick with tabs, I thought for example it might be
>> useful to have
>> a vertical list of running sessions instead.
>>
>> Hence the ViewContainer class is an abstraction of QTabWidget into a
>> 'content area'
>> plus some (unspecified) way of switching between the views which is
>> implemented by
>> the sub-classes.  The ViewSplitter class provides support for
>> hiearchical splitting of
>> views repeatedly.  This was based partly on the Vim originally which
>> supports this,
>> although in the end it never got polished off so the hiearchical part
>> can be removed.
> And it's not all to easy to grasp all the entangled relationships between the
> View* classes. I believe the splitting feature makes more sense for editors
> (like) vim. Editing the same file at several positions at once or a header/cpp
> pair next to each other is a valid use case. On the other hand, terminal
> sessions are always 'edited' in their last line except for copying or viewing
> some input above. So, agreed on the hierarchical part but I still don't see
> the use case for splitting. And it's not always working as expected (see the
> screenies).
>
>> As it is not much use has been made of ViewContainer abstraction I don't
>> mind it being simplified and replaced with a stock tab widget, provided
>> the existing border-free look can be preserved.
> Yep, that's doable with qtabwidget's document mode.
>
>> > ViewSplitter functionality could be done like this:
>> Am I right in understanding that there would be no functional change
>> there - just the structure
>> of the classes/widgets?
> At least it would lead to a lot less code which has to be supported. Referring
> to my opinion on splitting above, I'd like to see a KTabWidget with one
> terminal session per tab. To allow easier copying/monitoring IMHO one vertical
> split per tab would make sense. It's also easier to grasp for the user and
> needs less actions in the menu.
>
>> > The current Konsole "Edit Prifle" dialog
>> > actually mixes Konsole-wide settings and Session-settings and it does not
>> > allow to restore default values.
>>
>> Settings fall into three levels:
>>
>> - Per-tab settings.  These are settings that only apply to a
>> particular tab and can be
>> set differently for each tab, such as the tab title or the profile.
>> Some of these are settings
>> which default to whatever is set in the profile but can be changed
>> quickly for an individual
>> tab when it is useful, such as the character encoding.
> Do you really change the profile of a tab that often? For example, I've got my
> default Zsh profile, a Root (Zsh) shell and a Python interpreter profile.
> Switching to root is bettern done with su(do) and switching between a shell
> and an interpreter session makes hardly sense. IMHO profiles are handy when I
> want to open a new tab (thus a new session) thus they could be moved to
> Konsole-wide setup.
>
> Setting the character encoding and tab name is useful though, that could be
> moved to a per-tab context menu (tab title context menu).
>
>> - Profile settings.  Each tab is associated with a particular profile
>> and changing the
>> settings for a profile affects all tabs using that profile and all new
>> tabs using that profile.
>> The majority of the settings, including the ones most likely to be
>> changed such as colour scheme
>> go in here.  The idea here originally was to have all the settings in
>> a single fairly simple dialog, except
>> for those where there is a real need to be able to change them per-tab.
> Like I said above, I think (though I do not now absolute) the user most often
> only wants to change a tab's title and sometimes the encoding.
>
>> - Window settings.  These are settings which affect the whole window, such
>> as whether to show the menu bar.  Currently these are indeed mixed in with
>> the profile settings.
>>
>> The most important thing is that it should be easy to get to the
>> settings for the current tab's
>> profile.  The reason I didn't go with Settings -> Configure Konsole ->
>> Profiles -> [Select a Profile] -> Edit
>> was because I felt that would be too many mouse clicks.
> Maybe this could be done like Konqi does it, e.g. having to actions in the
> settings menu: 'Configure Profiles...' and 'Configure Konsole...'. That way we
> would have less clicks and the feature remains more visible.
>
>> > Like I wrote, most of the 'scrollback' stuff is actually
>> > settings and belongs into a configuration dialog.
>>
>> Scrollback settings currently exist in both the 'Edit Profile'
>> dialog and the edit menu.  The reason for having it in the edit
>> menu is that like character encoding and tab title, it is useful
>> to be able to change this setting per-tab.
> Really? Why would I want a scrollback limit of 10000 in one session and a
> scrollback limit of 100 in another? IMHO that's micro-options. The only real
> per-tab important task is to save a specific scrollback history. Again, this
> could be put into the file menu (after all it's for loading and saving) and
> into the per-tab context menu.
>
>> > * Deeper source tree with like this:
>> > ...
>> > src/core  // e.g. all low level stuff shared by the app and part
>>
>> There is only a very small amount of code which is specific to the
>> Konsole part and for
>> ease of maintenance I think it should stay that way.  As for putting
>> the non-graphical
>> code in a separate folder, I'd be fine with that.
>> I wouldn't add more than one extra level though.  src/gui seems fine but
>> src/gui/dialogs seems unnecessary.
> Ok, I'm fine with you recommendations. After all this topic is a matter of
> taste :-)
> --
> Kind regards,
> Sascha Peilicke
> http://saschpe.wordpress.com
>