Bug 255096 - split views should each have their own tabs
Summary: split views should each have their own tabs
Status: RESOLVED DUPLICATE of bug 104161
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: LO wishlist
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-24 12:11 UTC by Alexander van Loon
Modified: 2010-11-20 14:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander van Loon 2010-10-24 12:11:04 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

To change the document displayed in the different views, you have to place the cursor inside the view (document) first, then switch to another document with the document list or tab bar to make that view display that document. What I think would work best for Kate would be that each split view would have it’s own tab bar, so you could switch faster without having to place the cursor inside the view where you want to change the displayed document.

Reproducible: Didn't try
Comment 1 Alexander van Loon 2010-10-24 13:12:45 UTC
Please take a look at Konsole’s screenshot in this post – http://alexandervanloon.nl/english/?p=530 – on my weblog. Konsole does exactly what I want; hopefully Kate could copy Konsole in this regard.
Comment 2 Dominik Haumann 2010-10-24 13:50:55 UTC
This does not play together with the concept of the Documents sidebar. Do you have suggestions of how to work around this? (btw, there will be another tabify plugin that uses the standard kde tabs).
Comment 3 Alexander van Loon 2010-10-24 14:37:57 UTC
The documents sidebar could distinguish between the different views that are opened. For example it could show:

View #1
  kdeplanforworlddomination
  bachelorthesis.tex
View #2
  phdthesis.text
  lorem_ipsum
View #3
  etcetera

The documents sidebar could also support dragging, so opened documents could be moved from one view to another. This would effectively replicate the functionality of the tab bar without it’s limitations, and allow it to work nicely with the concept of split views as it works with Konsole and it’s tab bar, I think. While I have no idea at all if this would possible and if it would require much work, it seems like a simple solution.

I don’t understand your last sentence, the Tabify plugin which uses the standard KDE tabs is already available, why is another one necessary?
Comment 4 Thomas Fjellstrom 2010-10-24 14:41:58 UTC
I'm not sure you noticed, but for both Kate and Konsole, each view shows the same set of open documents. So there would just be the same documents in each separate "View #N" section, which really wouldn't be useful at all.
Comment 5 Alexander van Loon 2010-10-24 14:58:14 UTC
Ah, thanks for mentioning that, wasn’t paying attention. Even if each view would show the same documents, I think it would still be useful for quickly switching the displayed document. Unless many documents would be open at the same time, then the Documents sidebar would be too crowded due to displaying opened documents once for each view.

Maybe it could be made so that Kate’s document list doesn’t show the same documents for every view? It doesn’t have to follow Konsole in that regard, right?

Alternatively, maybe this whole idea could be restricted to the tab bar plugin? Using tabs together with the document list doesn’t make sense anyway, so why not disable the document list when the tab bar plugin is activated so that there is no conflict?
Comment 6 Thomas Fjellstrom 2010-10-24 15:22:00 UTC
As far as I'm aware, kate is hard coded to use a single Document Model. Even multiple windows in the same session share the same Document Model, so theres only one single list of documents internally.
Comment 7 Dominik Haumann 2010-10-24 22:33:02 UTC
Thomas is right, there is only a single document manager. Having a tabbar only is rather a wont-fix, we had the discussion quite often already... I've read your blog, Alex, and know about the dissatisfaction in this regard. I'm not sure whether we'll come up with a proper "fix" for your problem. It heavily depends on whether someone is willing to work on it.
Comment 8 Alexander van Loon 2010-10-24 23:27:44 UTC
It’s unfortunate that there is no easy fix, but I’d like to thank you both for taking the time to consider my ideas and reading my blog. I’m hopeful for a solution in the future.
Comment 9 Dominik Haumann 2010-10-25 09:50:09 UTC
Ok, a possible way to "fix" this is as follows: In the Kate Application, the mainwindow has a KateViewSpace. This KateViewSpace can be splitted, such that you have two KateViewSpaces. Then, it can be splitted again etc.
Each KateViewSpace knows all the views it created. So it could indeed show a tabbar for that. While it sounds straight forward to implement, the following issues arise:
- it cannot be implemented as plugin
- right now, for each document a view is created (iirc). This means, that the initial view space has a tab for each document (which might not be what you want).

So basically it's possible to implement this.
Comment 10 Thomas Fjellstrom 2010-10-25 09:59:16 UTC
Hmm, kate really creates a new editor widget (view) per opened document? What would be the consequences of switching to a single editor widget per split view?

I can imagine one, it might have to re parse/colorize the files when switching. But that state could also be separated from the view, hopefully fixing that as well. Are there any other issues?
Comment 11 Dominik Haumann 2010-10-25 16:05:30 UTC
kate/app/kateviewspace.h has the member variable
  QList<KTextEditor::View*> mViewList;
This is the list of all views in the view space container (could be checked with qDebug() how many items are in the list).

kate/app/katedocmanager.cpp has the list of all opened documents.
I'm not 100% sure whether a view is automatically created. Can be checked pretty quickly with some qDebug() statements in the code.
Comment 12 Dominik Haumann 2010-10-25 16:09:25 UTC
Maybe what's not trivial is: when to close a document? Usually, if it has no views anymore. Which would mean: we create a view for each doc. This needs to be clarified somehow. I wouldn't want all my 40 documents shown in the tabbar just because I opened a session. If we can find a workaround for this, then optionally showing the tabbar per viewspace might make sense.
Comment 13 Dominik Haumann 2010-11-20 14:11:41 UTC
Already reported 5 years ago ...

*** This bug has been marked as a duplicate of bug 104161 ***