Bug 155515

Not really keen of doing that, see bug #126724.

It's often needed to keep several documents open at same time. In that situation, single document interface has some drawbacks over tabbed interface:
1) usability: handling the different windows is uncomfortable
2) there is a bigger system resource load
I know that you can use okularpart embedded in konqueror but this may be only a short term solution because it suffers the same kind of problems which prompted KDE developers to replace konqueror as default file-manager: cluttered interface and waste of resource.

*** Bug 156524 has been marked as a duplicate of this bug. ***

When reading ebooks it is sometimes necessary to open another page to look something up. (formula, etc.)
Tabs are a good solution, because you can just close them and do not have to worry about returning to the page where you were reading.

There should be an easy way to create a new tab with the current document opened in it at the same page. Additionally, there should be a way to open hyperlinks and entries from the table of contents in new tabs. (like it is possible in web browsers) 

What has bug #126724 to do with it? We are not talking about MDI and Konqueror uses a tabbed interface, too. 

*** Bug 170530 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

I would like to expand on and stress Sebastian's statement regarding tabs, as he has a very good point. I use Okular for reading engineering and mathematical papers. I need to jump to other places in the text so often that I usually keep the same document open in two windows, so that I can comfortably read one without loosing my place, yet I can browse the document in the other window.

It seems that the only resistance to implementing MDI in Okular is the fact that it was not implemented in KPDF. The only reason that MDI was not implemented in KPDF is because of an outdated HIG doctrine:
http://bugs.kde.org/show_bug.cgi?id=127298

As the HIG doctrine is both outdated and as most other KDE applications break the doctrine (Konqueror, Dolphin, Kopete, Kate, Konsole, and other KDE apps all have tabs or an MDI), I propose that Okular forge ahead and become the first PDF reader with an MDI. I have an entire faculty of students that would switch to Okular for that reason alone!

> I use Okular for reading engineering and mathematical
> papers. I need to jump to other places in the text so often that I usually keep
> the same document open in two windows, so that I can comfortably read one
> without loosing my place, yet I can browse the document in the other window.

This is bug #169847, not this one.

> I propose that Okular forge ahead and become the first PDF reader with an MDI.

Proposal denied, for now.

Btw: do you know you can open Okular as emedded component in Konqueror, and thus use tabs from there?

> This is bug #169847, not this one.

Thanks, Pino, I will vote on that bug. The point that I was making is that I like to have _two_ instances of a document open at a time, whether it be in split view, tabs, or even two monitors.

> Btw: do you know you can open Okular as emedded component
> in Konqueror, and thus use tabs from there?

Thanks for the tip, I had not thought of that!

*** Bug 180549 has been marked as a duplicate of this bug. ***

here is a quick mockup of how it should look like:
http://imagebin.ca/view/fj3DSc.html

i made this image and put it on kde-look.org brainstorm:
http://www.kde-look.org/content/show.php?action=content&content=96443

if you like idea please vote..

Btw. with TDI it would be also possible to think not only of single documents, but sets. So it would be similar to Kate doc/session. This way user could make a set of documents related to Qt programming, or selected papers about graphs, and load them with one click.

I think Okular should become for eBook (and other text document) what Amarok is for music. It should scan user folders and create a collection containing all documents, grouped by Topics, Authors, Custom user Tags and so on. Users should be able to open several documents in a tabbed interface and save all opened documents in a "playlist" in such a way to reload all of them with one click in the future.
Maybe, that will remain just a dream... but I trust in Pino, in all the Okular staff and in their work...

I would rather see tabs support in kwin instead of reimplemented again and again in every app.

Albert: Very important usage of Okular simple document viewer. I think that 'Amarok of documents' should be built as separate application using Okular KPart of viewing.

Amarok case -- sessions are just sets of documents, that's all. I doubt building complex architecture just to store:

graph.algorithms
1=something.pdf
2=another.pdf
...

is reasonable.

(In reply to comment #15)
> Amarok case -- sessions are just sets of documents, that's all.

You are over simplifying Amarok's case.
Have you ever used it without a collection?
Amarok is totally collection-centric, ie you do everything around a collection you have to build before you using.
And even if you don't have a collection, playing something on-the-fly adds the file to the playlist.
This... just to play a single mp3? No thanks.

We will not turn Okular into an Amarok/JuK/digiKam model.
Although, as Jakub wrote in comment #14, anyone is free to implement such a _separate_ application, making use of Okular's embeddable component.

Back to the original topic: other than Jabus's valid point, the same Okular embeddable component said above can be loaded in Konqueror as well, where there are already tabs for free.

Pino, I wrote "amarok case", to keep the topic, but I wish for kate sessions (as I wrote before).

Back to TDI, right -- the "only" problem with embedded apps (not only okular) is hardly to manage UI, conflicting shortcuts, taken space, etc. It is that bad (it is not okular fault) that I always opened documents standalone.

For what it's worth, I second the request for a tabbed interface.

I just checked Adobe Reader for Linux, and it has a tabbed interface. So now there is precedent for a tabbed PDF reader for Linux.

(In reply to comment #18)
> For what it's worth, I second the request for a tabbed interface.

if you want this feature,all you can do it is to vote this bug (on the top of the page there is a "vote" link...you can use up to 20 votes for each bug,so if you really care about this feature you can give it 20 votes

I think that having tabs in Okular is a great idea, in addition to having more than one text open ("sessions" would allow for you to open up easily several books on the same topic or in a series, and easily navigate them) it would be nice to be able to open up more than one copy of the same book as well (Books containing formulas, algorithms, examples, diagrams), I would prefer tabs to a split view (though there's no reason they should be mutually exclusive) and a split view could get impractical if you want to open 4 or 5 different pages on the book at once.

Personally I can't imagine this would be too hard to code, and in any other tabbed application the tab bar is hidden if only one document is open, so it shouldn't cause any inconvenience to those who don't want it.

"Personally I can't imagine this would be too hard to code, and in any other
tabbed application the tab bar is hidden if only one document is open, so it
shouldn't cause any inconvenience to those who don't want it."

Do you have a patch?

Personally, I think it would be quite hard, and intrusive. However a patch would prove otherwise, of course.

I vote on this feature. It will greatly enhance productivity. All modern web browsers have tab view support, even Konsole has it. For a while, I installed acroread9 just to use its tab view feature(however, I deinstalled it due to its heavy cpu usage).

*** Bug 218051 has been marked as a duplicate of this bug. ***

YES PLEASE. Why not. I love tabs too. :)

Created attachment 42204 [details]
Source code: Demonstration of a trivial MDI interface for Okular

Comment on attachment 42204 [details]
Source code: Demonstration of a trivial MDI interface for Okular

Since the developers don't want to implement this (and I believe for a good reason), why not to write some kind of "Okular Manager" or "Meta-Okular", which would implement the MDI and call Okular KPart for viewing? 

It's not that difficult. I tried myself (I am a complete layman in any serious programming) and was able to demonstrate: 
1) possibility to have tabs with Okulars in them 
2) possibility to handle keyboard by the main application and consequently affecting even the tabs not currently active
The demonstration is in the attached source code. It is just a demonstration, not anything like working application. But even only a little more experienced programmer could generalize it easily to a nice working app.

Tabs are a great idea. I really don't understand developers who reject implementing tabs on what they deem is "bad design" grounds. If tons of people prefer to use a tabbed interface, there should be a tabbed interface. Ideally one would have the option to turn this off or on at will, e.g. as with Kate's "tab bar" extension.

> why not to write some kind of "Okular Manager" or "Meta-Okular", which
> would implement the MDI and call Okular KPart for viewing? 

It already exists: Konqueror. I use it extensively as a sloppy workaround until this issue is addressed. It is ridiculous that in KDE one has to open a different file manager depending on which types of files he wants to view.

With the inception of KDE's window tab feature, is this bug report still relevant?

(In reply to comment #30)
> With the inception of KDE's window tab feature, is this bug report still
> relevant?

Yes. Because the kwin tabs show as different tasks in the task bar.

Yes, I find it still relevant. I have disabled kwin tabs because they cause to many trouble (like grouping popups too) and I also agree with #31

Yes, this bug is still relevant. Switching tabs and leaving my Ctrl-Tab window management last-window switching is important.

Thanks!

(In reply to comment #31)
> (In reply to comment #30)
> > With the inception of KDE's window tab feature, is this bug report still
> > relevant?
> 
> Yes. Because the kwin tabs show as different tasks in the task bar.

You can help fix that by voting to implement the feature described in Bug 224690.

I believe this bug report is better handled if people redirected their attention to plasma and it's window tab grouping feature, as fixing/improving plasma improves the usability of not only okular but also countless other programs.

> I believe this bug report is better handled if people redirected their
> attention to plasma and it's window tab grouping feature, as fixing/improving
> plasma improves the usability of not only okular but also countless other
> programs.

The issue is that we do not want _window_ tabbing, but rather _document_ tabbing.

Why is a tabbed interface necessary to deal with several documents at the same time in one Okular window?

That is already possible in a different way:
1) Open the first document and add one or more bookmarks somewhere
2) Open the second document and add one or more bookmarks somewhere 
3) etc.
Enable the navigation panel (F7) and select Bookmarks. At the bottom of the Bookmarks panel deselect "Current document only".

Now you can quickly switch between different bookmarked pages of one document or of different documents by clicking the relevant bookmarks in the Bookmark navigation panel.

What is the benefit of a tabbed interface compared to this workflow?

> What is the benefit of a tabbed interface compared to this workflow?

A tabbed interface is simple. And shares UI consistency with other applications, such as a web browser.

Also, what if the user does not want to bookmark a specific place in a PDF but rather wants to be able to scroll it?

Your method sounds like a terrific workaround, alas, do you think that joe average will figure it out? He doesn't know or care that a PDF file has bookmarks, or that Okular can show the bookmarks of multiple files at once.

(In reply to comment #38)
> > What is the benefit of a tabbed interface compared to this workflow?
> 
> A tabbed interface is simple. And shares UI consistency with other
> applications, such as a web browser.

Oddly enough, web browser projects are starting to implement tabs mimicking KDE's window grouping feature.

Tabs are very useful if you have many PDFs reports and want to find a string
on them.

You just fill a search and go through the tabs using 'find next'.

If you have one report on each window you have to re-type the search string for
each document.

Application centric Okular tabs are the tings we want. I do not think its difficult. Please allow this option.

Using KWin grouping or Konqeuror is not beautiful, rather too crude.

(In reply to comment #14)
> I would rather see tabs support in kwin instead of reimplemented again and
> again in every app.
> 
> Albert: Very important usage of Okular simple document viewer. I think that
> 'Amarok of documents' should be built as separate application using Okular
> KPart of viewing.
I hope the Okular devs don't mind more spam in this bug, but as they suggested in #16 I've begun development of an "Amarok of documents" using kparts. If anyone's interested it's available here: 
http://kde-apps.org/content/show.php/Book+Manager?content=137437
Sorry again for adding to this already very long bug.
Brian K.

Hi Brian, looks cool, any reason why you develop it in gitorious and not in the kde repos?

(In reply to comment #43)
> Hi Brian, looks cool, any reason why you develop it in gitorious and not in the
> kde repos?

I'm using gitorious mostly because I wasn't sure how to join kde, and get hosted here. Something I should probably look into I guess. Thanks for the look btw.
Brian k.

http://techbase.kde.org/Contribute/Get_a_SVN_Account lists how to do it (it's called SVN but most of it applies to GIT too), feel free to mail me in private if you have questions.

why not joining forces with calibre?

On Sun, Jul 10, 2011 at 11:46 PM, Albert Astals Cid <tsdgeos@terra.es>wrote:

> https://bugs.kde.org/show_bug.cgi?id=155515
>
>
>
>
>
> --- Comment #45 from Albert Astals Cid <tsdgeos terra es>  2011-07-10
> 21:46:47 ---
> http://techbase.kde.org/Contribute/Get_a_SVN_Account lists how to do it
> (it's
> called SVN but most of it applies to GIT too), feel free to mail me in
> private
> if you have questions.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are a voter for the bug.
>

(In reply to comment #37)
> [...]
> 
> What is the benefit of a tabbed interface compared to this workflow?

Another situation where tabs could be useful is when you have a PDF with hyperlinks that point to local or external PDF: it could be nice that clicking on such a hyperlink, the other PDF file is open in a new tab (exactly as in Firefox).

Hi guys,

For myself, I can't make use of Okular until it has a tabbed window view.

In my work, I have to read and refer to tons of papers, documents,
specifications in parallel, and if each one were open in an individual window,
it'd mess up my techniques for managing my desktop and be unworkable.

For now, I use acroread.

In fact, a while back (2 years?), the acroread folks tried to make the Linux
acroread version not have a tabbed view (as it apparently is on Windows now)
and there was a revolt -- I rolled back to Acroread v7 and sat pat until they
fixed this. This was all documented on the adobe forums IIRC. Anyway, they did
fix it.

but I'd like to move off of using acroread if I could and use something open
source, but can't/won't until it supports my needs.

these needs are:

tabbed view  (MUST)

 "recent files" scrollable menu with unlimited # of entries (user-settable
limit) (SHOULD, but almost a MUST)  acroread limits it to 50, which is too few
for me.

multi-entry selection in "recent files" menu to enable batch file opening
(SHOULD)

de- and re-attachable tabs a la Chrome & Firefox browsers (SHOULD)

View splitting -- i.e. being able to multiply horizontally split (individually
scrollable) the view on a document in order to poke thru different portions
simultaneously (it boggles me to this day that this feature isn't more widely
available across all apps on today's systems) (SHOULD)

(actually, I'm somewhat puzzled/dismayed that the underlying windowing system
doesns't automatically provide for tabs and split view and such for all apps...
sigh)

I note that status on this bug is "wishlist" and very low priority -- but i really hope it can be changed and addressed such that we can at least get simple tabs

thanks,

=JeffH

BUMB (Bring Up My Bug).
Another vote in favor of tabbed view.

It is a simple feature and it would be easy to implement.
I do not know why it will need a long time.

If it's easy to implement where's your patch?

*** Bug 306467 has been marked as a duplicate of this bug. ***

Kde has always distinguished from others because of large customizability. The obstination of developers w.r.t. this feature is unacceptable.
This and other knots increase the frustration of enthusiast users, that are the ones that keep the community alive.
If the users wants this, the developers should accept patches and modifications into the official trunk!

@Roberto: Please read the thread. The project leaders did state more than once that patches are welcome. They even urged a promising developer to use the official repo.
All we need is some solid code. If the code is there, we're gonna have a tabbed interface.

I probably misunderstood a post above, with apologies.
Thanks for the clarification.

A tabbed interface in okular would be great. However, until developers find the time to implement it, we can exploit the tabbed windows feature of Kwin: Alt+F3 -> Attach as tab to... and select another opened pdf. You can also configure global shortcuts for kwin ("Walk through window tabs").

I know that this is not the same thing as a tabbed interface inside okular, but IMO it is quite close to (and you avoid annoying developers ;-) )

I have started work on a tabbed interface, currently hosted here: https://github.com/jrmrjnck/okular-tabbed. Devs: if you are interested in using my code, I will be happy to continue working on it and go through whatever review process you have.

Very nice work Jonathan, thanks! The only downside seems to be that it doesn't support my standard use case - which is opening multiple PDFs from a webbrowser. It seems that every externally passed PDF is opened in a new window instead of a new tab (PDFs opened from within okular works as expected).

Very good work Jonathan. You could open a review request at https://git.reviewboard.kde.org and upload your patch against okular sources from master. There are still a number of minor issues to solve, but they could be solved later.

Issues I have found:
- the same document can be opened several times in different tabs. Expected behavior: the same tab should be used or a dialog should be shown asking if the same tab or a different tab should be used
- tab size differ among different documents according to their file name. Expected behavior: the same tab size should be used and a tooltip should be shown with the full file name

> - the same document can be opened several times in different tabs. Expected behavior: the same tab should be used or a dialog should be shown asking if the same tab or a different tab should be used

I find it as an expected feature, sometimes I want to look at different pages in a document in two separate tabs (e.g. looking up questions and answers key back and forth)

Interesting, that already people have different use cases for how they would expect a tabbed interface to behave! I would agree with comment #58 and linked to #60 I might sometimes want to open the same document in different windows.

Thank you for your feedback. I had not considered the case presented in #58. I will take these comments into consideration and open a review request when I think the tabs behave reasonably.

(In reply to comment #59)
> Issues I have found:
> - the same document can be opened several times in different tabs. Expected
> behavior: the same tab should be used or a dialog should be shown asking if
> the same tab or a different tab should be used
I agree very much with this suggestion. I would suggest to handle it like this:
Presenting a dialogue asking how to handle it as above, but also have a tickbox
[ ] make this choice standard behaviour
So that the dialogue does not appear again. In Okulur settings there would need to be and option which also allows to change the standard behaviour or reinstate the dialogue.

I agree with m.wege. There should be a switch to control this. This is one use case where this would be important:

https://bugs.kde.org/show_bug.cgi?id=311045

Any news about this patch? Is it available in KDE SC 4.11.1?

(In reply to comment #65)
> Any news about this patch? Is it available in KDE SC 4.11.1?

No. 4.11 version (0.17) features are frozen. So it will be available in 0.18 (December 2013).

The code is ready to merge from my perspective, but we are still working through the review stage. Unfortunately, we have not really gotten into any discussion about the UI design decisions yet, and I suspect the maintainers will want me to change a lot of things. So, at this rate it may be a couple months yet before it's merged.

Git commit 0a982319f466dd6204d8f749e47e1de6630ed0d6 by Albert Astals Cid, on behalf of Jonathan Doman.
Committed on 08/02/2014 at 10:44.
Pushed by aacid into branch 'master'.

Tabbed interface

GUI
REVIEW: 110914

M  +8    -6    part.cpp
M  +1    -0    part.h
M  +220  -37   shell/shell.cpp
M  +34   -2    shell/shell.h
M  +2    -1    shell/shell.rc

http://commits.kde.org/okular/0a982319f466dd6204d8f749e47e1de6630ed0d6

Git commit 7681cdf00404379091a83973ad154217f47a3cc0 by Albert Astals Cid.
Committed on 08/02/2014 at 11:15.
Pushed by aacid into branch 'master'.

Move the open new files in tabs setting to configure dialog

Also make it non enabled by default for now

GUI

M  +1    -0    conf/dlggeneral.cpp
M  +7    -0    conf/dlggeneralbase.ui
M  +3    -0    conf/okular.kcfg
M  +4    -0    interfaces/viewerinterface.h
M  +5    -0    part.cpp
M  +1    -0    part.h
M  +7    -12   shell/shell.cpp
M  +1    -2    shell/shell.rc

http://commits.kde.org/okular/7681cdf00404379091a83973ad154217f47a3cc0