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

[Kurt Hindenburg]

Hello,

On Thu, May 24, 2012 at 9:40 AM, Jekyll Wu <adaptee at gmail.com> wrote:

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

Thanks again for all your work on Konsole.  It is much better shape now
thanks mostly to you.


>
> 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.
>
>
I personally have never like the "split" in Konsole.  Mainly due to the
number of bugs and complexity it added to the code.  I would prefer people
use apps such as tmux.   I do agree that the model should be changed to
what you have above.


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

Yes, this has been asked for and Robert originally coded the (KDE 4.0)
classes so this would be possible.  You're free to give it a shot.  The tab
title spacing has been a thorny issue and I'm not sure it is adequate now.
 Also, the ordering and sub-folders of tabs and profiles have been asked
for a long time.


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

A long time ago I pondered why Konsole doesn't use its own kpart.  If I
recall, Robert didn't care for that.  If it did, the kpart would always be
up to date.

Other things I think need done:
1. Redo the entire manage profile dialog and code.
2. Perhaps combine the Settings, manage profile and profile into 1 dialog.
3. I've always dislike the bookmark dialog - redesign it to be specify to
Konsole
4. What's your thoughts on adding a toolbar?

Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20120525/b3b9fae1/attachment.html>