[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