Announcement

Collapse
No announcement yet.

Ubuntu 14.04 Looks Toward Qt 5.2, Qt Mir In 14.10

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by Honton View Post
    Digia sponsors KDE for now. Because it adds more value. Having Ubuntu doing Unity8 on Qt will provide Digia with a far more interesting target for advertisement.
    I would assume that the small investment into KDE is always doable from Digia's perspective even if they get some cooperation with Canonical for other things goiing.

    Originally posted by Honton View Post
    I think that is pretty clear the Ubuntu is bigger than KDE.
    That will take a while, assuming that Canonical or the wider Ubuntu community keeps their current development direction. KDE's product portfolio is huge.
    I am not sure if there is any other single vendor that exercises all of Qt's APIs.

    Originally posted by Honton View Post
    One thing is sponsoring Ubuntu, another thing is selling licenses(closed) and support to Canonical.
    Hmm. I can see Canonical buying commercial licenses but I don't see them as someone buying Digia's services. They are more likely to hire their own Qt experts.

    Cheers,
    _

    Comment


    • #47
      Originally posted by Alex Sarmiento View Post
      What kind of freedom are you talking about?
      Honton is the resident CLA troll here on Phoronix. Just about any article about Ubuntu will have him popping up and trolling about CLA red herrings. Its a red herring. Ignore his posts.

      Comment


      • #48
        Originally posted by Honton View Post
        Of course they appear happy. There is no other way. No Qt, no KDE.
        Then where is the problem. Let them be happy. And maybe - in the future - they will regret the binding to Qt. But why do you make THEIR potential future / fate to YOUR problem? Have you been a Qt-dev?

        Originally posted by Honton View Post
        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.
        For me as a user KDE developed very well in the last years. More stable, faster etc. The mobile stuff / plasma active I did not test because I did not care. Maybe they failed in this part. But I experienced no disruption on plasma-desktop. So no problem for me that they throw workforce.

        Originally posted by Honton View Post
        "KDE5" is being sold as a huge leap forward, but it is nothing more than catching up with Qt's disruptive behavior and fixing some long standing bugs along the way.
        I read about KDE5 much and nowhere it was sold to me as a huge leap forward. They always say it will be a small transition compared to kde3 to kde4. And this catching up with Qt - wasn´t that always the case? Qt developed something new and KDE afterwards tried to make use of it.
        I still do not have a clue why you interpret all those things in such a negative way - interesting - spock would say

        Comment


        • #49
          Originally posted by Delgarde View Post
          It's not like there was any kind of formal takeover, if that's what you're asking. It's just that Gnome has always been one of the biggest users, and biggest contributors to the toolkit. Basically, they control it simply by virtue of being the ones doing all the work.
          Ah, okay. That makes sense

          Comment


          • #50
            Originally posted by Honton View Post
            "KDE5" is being sold as a huge leap forward, but it is nothing more than catching up with Qt's disruptive behavior and fixing some long standing bugs along the way.
            What are you talking about? Everything I've seen about KDE5 says it's a simple straight forward port. The only thing that's really changing is their breaking up kdelibs into separate parts to hopefully make it more useful to standard Qt developers.

            Plasma2 is a bigger change, with the Wayland support, but that's fairly separate from KDE5.

            Comment


            • #51
              Originally posted by anda_skoa View Post
              Two of those three examples are not really good.

              The maintainers of KWallet and GNOME Keyring have worked on a shared specification called Secret Service. They have either already implemented it or have staged it for upcoming releases of their respective storage service.

              Phonon and GStreamer are aren't even two implementations of the same facilities. Phonon is a simple Qt style API for easier use of platform media frameworks such as GStreamer if the application use case does not require full media framework capabilities.


              Actually there is. It is called Poppler and unsurprisingly used by both Evince and Okular.



              Progress there is often not very obvious but happening nontheless.

              Cheers,
              _
              Poppler is a PDF renderer. There are LOTS more documents formats out there:

              - LaTeX
              - PS
              - Tiff
              - CHM
              - DjVu
              - Images (they can be considered a "document" in some way)
              - DVI
              - XPS
              - ODT
              - Fiction Book
              - Comic Book
              - Plucker
              - EPub
              - Fax
              - Mobipocket
              - Microsoft Word

              http://okular.kde.org/formats.php
              https://wiki.gnome.org/Apps/Evince/S...ocumentFormats

              If you say: use the following libraries... That's not realistic, as there are just two applications supporting the major formats (and the best one is Okular, using Qt and having many KDE dependencies). A proper "DocKit" framework would be nice to have.

              Comment


              • #52
                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,
                _

                Comment


                • #53
                  Originally posted by Honton View Post
                  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.

                  Comment


                  • #54
                    Originally posted by Honton View Post
                    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.

                    Comment


                    • #55
                      Originally posted by pingufunkybeat View Post
                      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

                      Originally posted by Honton View Post
                      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.

                      Comment


                      • #56
                        Originally posted by anda_skoa View Post
                        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.

                        Comment


                        • #57
                          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,
                          _

                          Comment

                          Working...
                          X