[Konsole-devel] Some thoughts on the future or road map of Konsole

Jekyll Wu adaptee at gmail.com
Thu May 24 13:40:00 UTC 2012


Hi:

Now that KDE SC 4.9 is feature frozen, I think it is a good chance to 
discuss the future of Konsole.

At the moment we have 66 bugs + 119 wishes for Konsole on BKO.  That 
number looks acceptable from my perspective, especially when taking into 
consideration what that number was one year ago . So although fixing bug 
and reimplementing lost feature are still of high priority, I feel there 
is enough room for considering the road map problem.

Don't get me wrong. I'm not suggesting to make big change like the KDE3 
to KDE4 rewriting. I just feel a bit lost when considering the question 
of "What should we do in 4.10 and later versions?" in my head.

Topic 1: The split view

Well, I have to admit I'm also confused by its model and semantic at 
first sight.

Its essential semantic is 'splitting the area for two views', not 
'splitting the area for two sessions'. With the help of tabbar, it can 
provide the equivalence of the latter. But the user experience is 
definitely not as natural.

Another problem is the current implementation of that model still does 
not support recursive splitting. That is mainly a implementation 
problem, not a design problem. However, even if correctly implemented, 
the result would not be very pleasant, since there will be multiple 
tabbars scattered around, which is not only confusing and ugly, but also 
takes too much space.

Although I haven't made any survey, I'm quite sure what most users want 
is the split feature provide by tmux, yakuake, and terminator: 'split 
the area for two different sessions' .

I suggest adopting terminator's model of tab and splitting. Each Tab is 
corresponding to one main view, and each main view supports recursive 
splitting. And the essential semantic of splitting is 'for two different 
sessions', although I think it should be possible to also support the 
current semantic of 'for two views of the same session'.

Another advantage of that model  of tab and splitting is that it makes 
it easier to support navigating utility other than tabbar. That would be 
covered in next topic.


Topic 2: The tabbar

There are some limitation when using tabbar.

   * Qt currently only has nice support for horizontal tabbar. Qt does 
support vertical tabbar, but the text on each tab is laid vertically, 
which makes its basically unusable.

   * horizontal tabbar can be easily filled when user open 20+ tabs.

   * It is hard for tabbar to support organizing related tabs into one unit.

   * It is hard for tabbar to support tab filtering

It might be a good idea to use a treeview based sidebar for organizing 
and navigating tabs.  That idea is inspired by how konversation and 
quassel organize networks and channels. The benefit of using a treeview 
based sidebar:

   * It allows users to select and organize related items into one subtree

   * It allows users to drag item between different subtrees.

   * It allows users to type some text to filter the items

   * It allow users to see more items at the same time than using tabbar

   * it should be able to support most tabbar features, like changing 
item icons after detecting activity/silence, changing text color, 
context menu, etc.

   That's just my rough thoughts and imagination. But I already feels 
that tabbar is so limited :) Of course, I'm just proposing adding 
treeview-based sidebar as alternative navigating method, not removing 
tabbar.


Topic 3 : provide scripting support

Some features can be moved out of the core code and rewritten in 
scripts. One typical example is the (regex-based) URL recognition. It 
may not be a good idea to add support for "apt://" URI schema in the 
core code, but it should be easy and fine for debian developers to write 
a extension for "apt://" URI schema if we provide good scripting support.


Topic 4: Move the core emulation code into its own library

Well, although I feel most vte-based emulators are just toys and hardly 
as useful as konsole and yakuake, there are many vte-based emulators but 
few Qt emulators. Clearly, vte makes an important difference. Yes, there 
is qtermwidget(modified from old konsole code), which is basically what 
I am proposing, but I don't think it is actively maintained or can 
satisfy the need of konsole.


Summary:

Those topics are listed in the order of their priorities from my 
perspective.  To be frank, topic 3 and 4 are too far away from current 
situation.  I think topic 1 is the most doable one in the near future 
(but probably no earlier than KDE SC 4.11 or equivalence).

I would like to hear about your opinions about above topics, especially 
the splitting and treeview-based sidebar.

Regards
Jekyll



More information about the konsole-devel mailing list