[Konsole-devel] Konsole development

[Sascha Peilicke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20100304/855572b1/attachment.sig>