Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: Features Baking For KDE 4.11

  1. #11
    Join Date
    Dec 2010
    Posts
    1,228

    Default

    Quote 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.

  2. #12
    Join Date
    Jun 2013
    Posts
    28

    Default

    Quote 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

  3. #13
    Join Date
    Dec 2010
    Posts
    1,228

    Default

    Quote 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.

  4. #14
    Join Date
    Jun 2013
    Posts
    28

    Default

    Quote 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-13-2013 at 12:37 AM.

  5. #15
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,635

    Default

    Quote 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):

  6. #16
    Join Date
    Dec 2010
    Posts
    1,228

    Default

    Quote 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.

    Quote 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.

  7. #17
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    240

    Default

    What are gains when building KDE with c++11?

  8. #18
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,920

    Default

    Quote 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.

  9. #19
    Join Date
    May 2010
    Posts
    684

    Default

    Quote 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 at 11:22 PM.

  10. #20
    Join Date
    Jun 2013
    Posts
    28

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •