Announcement

Collapse
No announcement yet.

Features Baking For KDE 4.11

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

  • #11
    Originally posted by Ericg View Post
    So if you hate that bug you have to upgrade to 4.11 to not be affected by it.
    Or simply use an alternative tasks widget like Smooth Tasks2 and although I haven't tested it, I'm pretty sure the QML taksbar also works with 4.10 because kdelibs is in freeze since 4.9 or so now.

    Comment


    • #12
      Originally posted by Awesomeness View Post
      I'm pretty sure the QML taksbar also works with 4.10 because kdelibs is in freeze since 4.9 or so now.
      Sort of: The Task Manager widget uses the libtaskmanager library that's shipped with kde-workspace (the same module also containing the applet), and the QML rewrite coming with 4.11 depends on a matching version of the library (which however has otherwise stayed API compatible for third-party users). While it's possible to build just the library and widget and run them against 4.10, you'll run into runtime problems with some windows not being listed unless "Only show windows from this activity" is disabled in the settings (because the way windows are tagged to be on all activities has changed in 4.11, so there's a need for libtaskmanager and the rest of the shell to be in sync as well / the 4.11 lib doesn't agree with 4.10 shell behavior on the activities front).

      Cheers,
      Eike, who wrote the new QML version

      Comment


      • #13
        Originally posted by Sho_ View Post
        While it's possible to build just the library and widget and run them against 4.10, you'll run into runtime problems with some windows not being listed unless "Only show windows from this activity" is disabled in the settings
        Sounds like a rather small tradeoff. In such a case I wonder why the QML widgets aren't released to KDE Look or wherever for users to beta test them without getting the beta-quality rest.
        Incompatible options could be disabled.

        Comment


        • #14
          Originally posted by Awesomeness View Post
          Sounds like a rather small tradeoff. In such a case I wonder why the QML widgets aren't released to KDE Look or wherever for users to beta test them without getting the beta-quality rest.
          Incompatible options could be disabled.
          I could see myself having done so if it were just the widget, however as mentioned it does require a matching library, so at that point you're looking at:

          - Releasing something that requires compilation, immediately limiting the audience (and the audience who is fine with compiling is more prone to being fine with just running a beta of the whole set).
          - Putting together a new tarball for lib and widget, which involves such things as extracting the relevant translation files from the repositories (they are not kept with the source to make things easier for the translators), writing a new build system, ...
          - Making the changes you suggest to deal with the incompatible-features situation, which invites the risk of creating entirely new bugs that result in feedback noise.
          - Not to mention that testing against a workspace version it isn't destined to be used with might also turn up additional incompatibilities that were previously unknown, resulting in more feedback noise about things that don't actually need fixing.
          - Dealing with the fact that our bug tracker doesn't know a version for this out-of-band release.

          And so on, and so on - now imagine every developer doing that for their little piece of the whole, and it's a substantial overhead burden.

          Edit: One more: Since the library has third-party users it involves keeping track of whether the changes that were done to it broke the ABI or not, and if it did, naming it differently in the special test release to avoid breaking other widgets the user may be using. More changes = more opportunities for bugs to creep in. This wouldn't be relevant for the actual 4.11 (beta or final) release because we put no ABI stability guarantee on libtaskmanager (unlike with kdelibs), so distros know they're going to have to rebuild downstream users of it.
          Last edited by Sho_; 06-12-2013, 11:37 PM.

          Comment


          • #15
            Originally posted by bwat47 View Post
            With most other file managers, such as nautilus, thunar, or pcmanfm when you access a network share it mounts it on the fly using GVFS. This makes it so any application can access/play these files because they are treated like local files.

            KDE does not mount the share, instead it browses the shares with its own KIO/Kioslaves system, the problem with this is typically only KDE software supports kioslaves, and in some cases even KDE software doesn't support them well enough (for example dragonplayer doesn't seem to support a smb kioslave and simply fails to play videos from a smb share in dolphin). Gnome's GVFS solution works with ALL software, its far superior.

            I don't find mounting the share in fstab to be an acceptable solution. This is a laptop and the share is not always available, and with a CIFS mount you can get locking up issues in KDE when the share is not available. To me the only acceptably solution is something where I can easily mount and unmount the shares on the fly, as a user. SMB4k is the best I've found so far for kde but its kind of buggy unfortunately.
            Hmm? It works via fstab just fine. Here's how it looks for me:


            Note the "/export/storage on dragon". It's an NFS share. It's not mounted by default. When I click it, it gets mounted. When I right-click it and select Unmount, it gets unmounted.

            I set up the whole NFS share not even by editing /etc/fstab, but by just using YaST with these settings (sorry for the localisation, but it should be straight-forward to understand):

            Comment


            • #16
              Originally posted by Sho_ View Post
              Releasing something that requires compilation, immediately limiting the audience (and the audience who is fine with compiling is more prone to being fine with just running a beta of the whole set).
              You mean like every bit of software KDE released since years. ;-) I can't remember when ftp.kde.org hosted binary packages (RPMs or whatever). Must have been during KDE 2.x times or so.

              Originally posted by Sho_ View Post
              Putting together a new tarball for lib and widget, which involves such things as extracting the relevant translation files from the repositories (they are not kept with the source to make things easier for the translators), writing a new build system, ...
              - Making the changes you suggest to deal with the incompatible-features situation, which invites the risk of creating entirely new bugs that result in feedback noise.
              - Not to mention that testing against a workspace version it isn't destined to be used with might also turn up additional incompatibilities that were previously unknown, resulting in more feedback noise about things that don't actually need fixing.
              - Dealing with the fact that our bug tracker doesn't know a version for this out-of-band release.
              Well, I get the argument for 4.10 but considering that 4.11 is supposed to be an “LTS” release some Plasma widgets may actually get new feature releases before PW2 is ready for widespread consumption. Tweaking things like version support in BKO sounds to me like less work than to do a whole “4.12” just because some QML Plasma applets have been updated and released possibly just released via GHNS.

              Comment


              • #17
                What are gains when building KDE with c++11?

                Comment


                • #18
                  Originally posted by Thaodan View Post
                  What are gains when building KDE with c++11?
                  If the code now compiles cleanly as C++11 it means that they can start using features from c++11 language update. As far as performance or stability improvements... I can't think of any, not from just compiling it as one C++ version vs another. But it does benefit developers who are developing if C++11 has been "greenlit" by upstream.

                  Comment


                  • #19
                    Originally posted by GreatEmerald View Post
                    Hmm? It works via fstab just fine. Here's how it looks for me:


                    Note the "/export/storage on dragon". It's an NFS share. It's not mounted by default. When I click it, it gets mounted. When I right-click it and select Unmount, it gets unmounted.

                    I set up the whole NFS share not even by editing /etc/fstab, but by just using YaST with these settings (sorry for the localisation, but it should be straight-forward to understand):
                    Does yast allow you to do the same thing with samba shares? That would be a perfectly acceptable solution for me if I could mount and unmount the share on demand in dolphin as user. Once KDE 4.11 comes out and fixed my tearing issue (and it becomes available in opensuse's KDE:Stable repo) I'll have to give opensuse another shot if I can achieve this with samba.
                    Last edited by bwat47; 06-13-2013, 10:22 PM.

                    Comment


                    • #20
                      Originally posted by Awesomeness View Post
                      Well, I get the argument for 4.10 but considering that 4.11 is supposed to be an “LTS” release some Plasma widgets may actually get new feature releases before PW2 is ready for widespread consumption. Tweaking things like version support in BKO sounds to me like less work than to do a whole “4.12” just because some QML Plasma applets have been updated and released possibly just released via GHNS.
                      If you're thinking about releasing PW2 widgets for testing on 4.11 before releasing PW2, I don't think that's going to be practical because of API changes in the Plasma libraries and QML components. PW2 is by necessity seeing some of the bigger API breaks in the next-gen dev cycle, because Qt swapped out QML's backend and we've been using some of the lower-level APIs this affects, and because the Plasma 1 QML components have been frozen for a while and we've got a list of changes we'd like to make there. Once the new Task Manager is ported to PW2 for example, it will no longer be practical to release a Plasma 1 version of the same code.

                      Comment

                      Working...
                      X