Is it possible to compile okular without all KDE dependencies? Or it is too tightly integrated to KDE? Did anybody try to decouple it?

Why would you want to decouple it?

for more simple packaging and distribution for Windows and/or Mac OS X, see for example here
http://aheinecke.blogspot.nl/2012/08/th ... ckage.html

I think a lot of work in that direction is being done for KDE 5: libraries are being split, and stuff is being merged back into Qt where possible. Thus, hopefully the dependencies of some KDE applications will become more lightweight in the future.

Other than that, I think trying to build KDE applications without... the KDE libs, or whatever, makes no sense. It sounds comparable to editing a GTK application to not depend on GTK; of course that is possible, but you'll need to reimplement all the functionality which GTK provides. It will require massive forking and maintenance effort. Maybe a better solution can be found by e.g. linking against kdelibs statically for such purposes or similar?

In other words: The problem is the distribution / build method, and not the dependency itself in my opinion.

Greetings,
Sven

zeliboba wrote:for more simple packaging and distribution for Windows and/or Mac OS X, see for example here
http://aheinecke.blogspot.nl/2012/08/th ... ckage.html

To be honest, there's already windows and mac ports of okular, if you don't like them, offer to improve the distribution methods, removing functionality is not a good idea if you ask me.

to be precise, there is windows and mac ports of KDE, not okular. let we not discuss this distribution method, but come back to original question. could you be more specific, what functionality will be sacrificed in ocular if dependency on kdelibs will be removed?

scummos wrote:Other than that, I think trying to build KDE applications without... the KDE libs, or whatever, makes no sense. It sounds comparable to editing a GTK application to not depend on GTK; of course that is possible, but you'll need to reimplement all the functionality which GTK provides. It will require massive forking and maintenance effort.

I always thought that GTK plays the same role for Gnome as Qt to KDE, being widget library. Since I do not want get rid of Qt dependency, but on KDE libs, your comparison does not look fair to me. Or you mean, that integration with KDE is so tight?

To be clear, I do not propose okular developers to fork and maintain. I have my own project in mind and try to estimate the efforts.

zeliboba wrote:to be precise, there is windows and mac ports of KDE, not okular.

KDE is a community, so no, there's not ports of KDE to anything. There are ports of KDE applications to windows and mac, and Okular is a KDE application that has been ported to windows and mac. Because it perfectly works on windows and mac. Maybe your idea of a port to windows is use MFC?

zeliboba wrote:could you be more specific, what functionality will be sacrificed in ocular if dependency on kdelibs will be removed?

Everything?

P.S: I'd appreciate of you spelt Okular correctly

TSDgeos wrote:

zeliboba wrote:to be precise, there is windows and mac ports of KDE, not okular.

KDE is a community, so no, there's not ports of KDE to anything.

KDE used to mean "K Desktop Environment" environment", I hope it is obvious from the context. I'd really appreciate if stopped terminological flame and came closer to the subject.

TSDgeos wrote:

zeliboba wrote:could you be more specific, what functionality will be sacrificed in ocular if dependency on kdelibs will be removed?

Everything?

Few major points would be a good start.

zeliboba wrote:

TSDgeos wrote:

zeliboba wrote:could you be more specific, what functionality will be sacrificed in ocular if dependency on kdelibs will be removed?

Everything?

Few major points would be a good start.

I'll leave the exercise to you since you seem to be interested in pursuing this.

zeliboba wrote:Few major points would be a good start.

Just... forget it. Look at the code. You have to rewrite half of the application if you want to remove all the KDE dependencies. Look at just the occurences of KUrl, it's hundreds of them. My comparison with GTK is not that bad, since KDE builds upon many of the Qt widgets and extends them.

Look at a random header in the sources. This, for example.

Code: Select all

#include <kaction.h>
#include <kapplication.h>
#include <kcmdlineargs.h>
#include <kfiledialog.h>
#include <kpluginloader.h>
#include <kmessagebox.h>
#include <kmimetype.h>
#include <kstandardaction.h>
#include <ktoolbar.h>
#include <kurl.h>
#include <kdebug.h>
#include <klocale.h>
#include <kmenubar.h>
#include <kio/netaccess.h>
#include <krecentfilesaction.h>
#include <kservicetypetrader.h>
#include <ktoggleaction.h>
#include <ktogglefullscreenaction.h>
#include <kactioncollection.h>
#include <kwindowsystem.h>

Those are all technologies from KDE. Translation, buttons, windows, mime type handling, file dialog, message boxes, toolbars, KIO for accessing remote files, command line argument parsing -- what do you plan to do with those? Reimplement them?

Again: Just forget it. Trying to make KDE applications not depend on KDE any more is not the correct way to make them easier to install on windows. I agree that this is a problem, but *this* is not the correct way (or, not a way at all), to tackle it.

Greetings,
Sven

zeliboba wrote:I always thought that GTK plays the same role for Gnome as Qt to KDE, being widget library.

This is not true for a long time now, at least for Qt. There are abstraction layers to help you with string manipulation, arrays, Unicode support, network communication, accessing files and so on across different operating systems. Qt is not simple widget library anymore.

Anyway, kdelibs is yet another abstraction layer that implements all things that KDE SC devs thought are missing in standard Qt.

I think that outcome of this thread is clear - Okular is so tightly integrated with KDE SC, that building it without kdelibs would require too much effort. None of KDE SC devs is even interested in it.

But what exact features of Okular do you find superior? In it's core, Okular uses poppler to read and display PDF files. So it might be easier to find another poppler-based PDF viewer (there are plenty of these) without so much dependencies, or even write your own.

Side note: for Windows users, I would recommend Foxit Reader. It is lightweight, feature-rich and free (as in beer). I have also heard good opinions on Sumatra PDF, but I have never used it.

scummos wrote:Again: Just forget it. Trying to make KDE applications not depend on KDE any more is not the correct way to make them easier to install on windows. I agree that this is a problem, but *this* is not the correct way (or, not a way at all), to tackle it.

Thanks, Sven! Just wanted to mention that the packaging is just one of the aims, actually I'm thinking about a bundle of customized applications to work with scientific literature. Preferably they should be based on Qt (cross-platform/well-supported) and open source (further modifications may be required).

Minio wrote:But what exact features of Okular do you find superior? In it's core, Okular uses poppler to read and display PDF files. So it might be easier to find another poppler-based PDF viewer (there are plenty of these) without so much dependencies, or even write your own.

For me the killing feature of Okular is filters in thumbnail preview, where you can see the words in the page like in
http://www.linuxlinks.com/portal/conten ... okular.png Sumatra PDF and Foxit are not cross-platform. Anyway thanks for suggestions and comment.

zeliboba wrote:

scummos wrote:Again: Just forget it. Trying to make KDE applications not depend on KDE any more is not the correct way to make them easier to install on windows. I agree that this is a problem, but *this* is not the correct way (or, not a way at all), to tackle it.

Thanks, Sven! Just wanted to mention that the packaging is just one of the aims, actually I'm thinking about a bundle of customized applications to work with scientific literature. Preferably they should be based on Qt (cross-platform/well-supported) and open source (further modifications may be required).

For writing custom applications based on things like okular, you should consider using the KParts framework, in that case, the okular KPart. It just gives you the viewer window and some features, and you can design the UI around it yourself. It's especially useful for embedding a PDF viewer widget into some other application.

Greetings