Ubuntu 14.04 Looks Toward Qt 5.2, Qt Mir In 14.10

[anda_skoa]

Sure, there are other formats, but the point was that Poppler shows how document support can be provided in a way suitable for viewers using different UI technologies.

I would assume that, for example for PostScript, both Evince and Okular are also using the same library, most likely Ghostscript.

Supported formats and respective library usage will depend on the application's target scope.
A program intended to be just a PDF viewer would only need Poppler, e.g. for avoiding any unnecessary or maybe even unwanted dependencies.

Anyway, it was just an illustration how application developers using quite different technology stacks are collaborating on common code.

Cheers,
_

[zoomblab]

you quoted me on the very topic on contributing to Qt. And that requires CLA.

And that is perfectly normal. You are free to contribute without CLA by forking, because the actual freedom is guaranteed by the GPL.

[pingufunkybeat]

Exposing new API takes time, code and justification. This is not free to Qt or its customers. Nokia did it because they wanted Qt to become phone toolkit (and failed). KDE was not asked if they liked this or if the new ways suited them well. Hell Plasma Active was started by former KDE/Qt people because KDE was no longer a good fit for the new Qt. THAT is disruptive. Meanwhile GTK was stable as ever and served what ever needs Gnome had. Without being disruptive and requiring Major version released out of sync with Gnome.

You are a hilarious troll.

In your next breath, you will be defending systemd, clutter and PulseAudio, which expose new APIs, to which your answer was "take it and eat it!".

But, like a good troll, you made a ridiculous, blatantly wrong and inflammatory statement, but left a little backdoor -- justification. Then you will claim that systemd and clutter were erally really needed, while a declarative language which simplifies UI development and speeds it up 10x is not needed. Until GTK gets something similar, in which case you will claim it's an innovation and scold Qt for not using that instead. And it will go on in circles, always slightly changing the argument, to hook new unsuspecting users with your outrageous bullshit.

[benalib]

You are a hilarious troll.

In your next breath, you will be defending systemd, clutter and PulseAudio, which expose new APIs, to which your answer was "take it and eat it!".

But, like a good troll, you made a ridiculous, blatantly wrong and inflammatory statement, but left a little backdoor -- justification. Then you will claim that systemd and clutter were erally really needed, while a declarative language which simplifies UI development and speeds it up 10x is not needed. Until GTK gets something similar, in which case you will claim it's an innovation and scold Qt for not using that instead. And it will go on in circles, always slightly changing the argument, to hook new unsuspecting users with your outrageous bullshit.

and that's the point

I hope systemd will pick up more software and become linux only. Because that is efficient. And since no one sane want to maintain all the bits outside systemd, the vocal people can go to ubuntu and experience the same single stack approach happening over there. The only difference is the slower adoption, lower quality, single vedorism and Canonical CLA.

[timofonic]

Sure, there are other formats, but the point was that Poppler shows how document support can be provided in a way suitable for viewers using different UI technologies.

I would assume that, for example for PostScript, both Evince and Okular are also using the same library, most likely Ghostscript.

Supported formats and respective library usage will depend on the application's target scope.
A program intended to be just a PDF viewer would only need Poppler, e.g. for avoiding any unnecessary or maybe even unwanted dependencies.

Anyway, it was just an illustration how application developers using quite different technology stacks are collaborating on common code.

Cheers,
_

It's okay if you want to develop just a PDF viewer, but it's a mess if you want to do a more universal viewer (and it's the most user friendly approach, even experienced users find it more comfortable than specialized viewers).

There's lots of libraries to support those formats. That's why lightweight viewers like Zathura (it uses a plugin system and can support pdf over poppler or mupdf, djvu, ps and comic book) and Apvlv ( supports pdf, djvu, umd, txt)lack support of certain formats, it's too much work for smaller projects and even the major viewers lack certain formats!

I would agree if you say me "so do it!". I would do it if I were a developer.

[anda_skoa]

As your own example shows it is not really that difficult to either use those libraries directly or abstract them into plugins.

Almost no software is developed without usage of libraries, it is just no feasible.

Abstractions, like that application's plugin system or Okular's renderers or KDE's KParts system, have usually two consequences:
- they make the underlying functionality easier to use
- they hide some aspects or advanced functionality

Which is why they are most often added on a high level, e.g. as an application specific plugin API, because the then closely known use cases make it easier to find the right balance between the two.

Creating an abstraction on a lower level is usually a lot more work and only viable if there are both many prospective users and enough similarity between the different parts below. Good example for that are media frameworks like GStreamer: lots of potential users, very similar properties of codecs.

There is probably just not enough need for a low level document rendering abstraction, i.e. the "market" for universal document viewers is not that big.
Hence those that exist putting their abstraction into places that fits their respective requirements the best.

Cheers,
_