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

[Jekyll Wu]

于 2012年05月25日 22:34, Kurt Hindenburg 写道:

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

Yes, splitting means complexity.

I occasionally hear about various opinions about whether emulators 
should support splitting itself. Some see it as a killer feature, while 
some see it as an sign of feature bloating. I personally tend to see it 
as a killer feature. There are some konsole features  which do not work 
well with the splitting provided by tmux. For example, the monitoring 
activity/silence (you can only monitor the whole tmux instead one 
session within the tmux).

So at least we have one consensus: the current model of splitting is not 
that good. I will do more experiment to have better idea of the cost of 
new model of splitting.


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

Yes, konsolepart is a second-class citizen in current design. But I do 
not have enough confidence of changing that design at now or near future.

What I have proposed in topic 4 is: split and provide a Qt only library, 
just like vte is gtk only. That might be a crazy idea, but
the influence of vte just makes me keep thinking about it.


> Other things I think need done:
> 1. Redo the entire manage profile dialog and code.

I'm not sure what is your plan for the redo. Do you mean provide better 
management of profiles, like grouping, sorting, etc?


> 2. Perhaps combine the Settings, manage profile and profile into 1 dialog.

I think it should be fine to add the "manage profiles" dialog as another 
page within the "Configure Konsole" dialog. But we need to make sure the 
'manage profiles' dialog is still accessible for konsolepart.


> 3. I've always dislike the bookmark dialog - redesign it to be specify to
> Konsole	

The whole bookmark system feels like a trick around KUrl.  If we want to 
rework that bookmark dialog, we should better first redesign the 
underlying data first.

Another related idea: maybe we can provide some integration with 
commandlinefu.com if we really rework the whole bookmark system. That 
idea is inspired by clicompanion.

 > 4. What's your thoughts on adding a toolbar?

I currently have no favor of toolbar in an terminal emulator. A toolbar 
encourages users to put hands on mouse, instead of on keyboard. And I do 
not see much need for a toolbar, except for maybe the monitor 
activity/silence actions. I also have the worry once we add a toolbar 
some new users to the terminal world would ask adding the "go to home 
directory" button, "go to previous directory button", etc. I might 
change my mind when we provide more actions after the proposed splitting 
and sidebar are implemented.

Regards
Jekyll