[Konsole-devel] Konsole development

[Robert Knight]

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.

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.

> 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?

> 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.

- 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.

- 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.

> 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.

> One class Foo per foo.h/foo.cpp pair

That's good by me.  Nested classes go in the same source as the parent class.

> * 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.

Regards,
Robert.

On 3 March 2010 21:55, Kurt Hindenburg <kurt.hindenburg at gmail.com> wrote:
>
>
> On Wed, Mar 3, 2010 at 12:15 PM, Sascha Peilicke <sasch.pe at gmx.de> wrote:
>>
>> > For me the most important things are that Konsole starts and feels fast,
>> > has minimal UI clutter, good defaults and straightforward configuration,
>> > so a "fresh and simplified look" sounds appealing - though some
>> > prototype before/after screenshots would be useful to clarify what you
>> > have in mind.
>> Difficult, I'm too bad at drawing things. What I have in mind is like the
>> dolphin configuration dialog which can be reached via "Configure
>> Dolphin...".
>> On the left we could then have categories like "General", "Profiles",
>> "Scrollback", "Advanced", etc. The current Konsole "Edit Prifle" dialog
>> actually mixes Konsole-wide settings and Session-settings and it does not
>> allow to restore default values.
>>
> Yes, I had plans to start this to see how difficult it would be.   I like
> the KCM idea instead of Konsole current approach.  But haven't had the time
> to research further.
>   Kurt
>
>