Posted on by Martin Flöser

What Feature Requests Can Tell Us

As mentioned yesterday I am currently going through all open feature requests for KWin. This of course tells me quite a lot about what our users want to see in KWin and where we have rough edges. Of course everything there has to be seen with some bias as some reports are really old and KWin has done a transition from being a window manager to a compositor and window manager. Given the age of KWin there has also been a dramatic shift in the targeted user audience of KWin and Linux in general.

One of the patterns I noticed in going through the requests is a high demand for our window specific rules framework. In fact I noticed so many requests for them, that I decided to create an own bug component for bugs and requests specific to the rules framework. This shows that the scripting capabilities currently added to KWin are useful and that there are many users who will appreciate that work.

Another area which has quite a rather large amount of wishes is Present Windows and Desktop Grid. This validates my assumption that it is one of the most powerful features we actually have for window management and that we have to make this more prominent. Personally I have quite some ideas to improve this in 4.10.

On the other hand there are hardly any requests for our other effects and if at all it is for accessibility features. When we introduced desktop effects there were many requests to add this effect and that effect, mostly with the reason that compiz has it, too. The more fancy, the better. Lately we have hardly got any new wishes for adding more eye candy. This quite validates some assumptions I already had. As desktop effects are quite normal nowadays on all systems there seems to be no need any more to have the show off effects. Who wants to burn down windows anymore? That was awesome back in 2005 as no other system could do something like that, but nowadays it looks already quite old fashioned.

Another area which really sticks out are advanced window management features like Focus Follows Mouse, Focus Under Mouse or Window Shading. Concepts probably not known to most users, concepts dating back to the early times of X11 and not really used by our current developers. If I think back to the developer sprints I have been over the last years I have not noticed anyone who used Window Shading.

Overall the feature request highlight something I expected before: feature requests are only reported by very advanced users. Only a very small sub group of our user base is able to report them. And that is no surprise. In most cases we can safely assume that a user of the KDE Plasma Workspaces does not know anything about KDE. Even if she does it is unlikely that she knows anything about KWin (try to find the word KWin in our UI). Even if the name KWin is known it is unlikely that a user knows that she could report a bug or feature request. KWin does not have a Help menu with a “Report Bug…” entry. So there is a huge entry barrier for reporting feature requests.

It shows again that bugzilla is hardly useful for interaction with the userbase as your userbase is not represented correctly. For KWin this will of course be fixed by no longer accepting feature requests in the bug tracker, but sending users to the brainstorm section.

33 Replies to “What Feature Requests Can Tell Us”

  1. Please don’t break Focus Follow Mouse.. I absolutely can’t deal with click-to-focus nonsense. Also, while not often, I do use window shading, although I’ve noticed myself using window transparancy/exposee more and more for the things I used to use shading for.

      1. To quote:
        “Another area which really sticks out are advanced window management features like Focus Follows Mouse, Focus Under Mouse or Window Shading. Concepts probably not known to most users, concepts dating back to the early times of X11 and not really used by our current developers.”

        If non of the developers use it, it tends to bitrot, at that point someone needs to start caring, if nobody does, things get released with broken FFM and I get upset 🙂

        Now it might not be that dire yet, but reading that there’s no devs using it did set off alarm bells.

        2. There’re still commits to FFM, personally i’d even say it should be default, but with different settings.
          It becomes very handy with a short auto raise delay, high focus delay, actvate & pass click.
          The result is that you can sneak around and change the stacking w/o impacting the focus (though the GUI only allows for 3 secs, could be changed and also include “never”) – basically swap the general use of activating the window w/o raising it to a more ctf-a-like behavior.
          It’s just not the windows way.

          Whenever we redo the handwritten dialog (no .ui file…) i wanted to change the focus model selection by a 5-6 step slider from “pussy” to “1337” presets (w/o removing finegrained settings, oc. – and maybe not exactly those strings 😉

  2. “If I think back to the developer sprints I have been over the last years I have not noticed anyone who used Window Shading.”

    Strange. I’m using it all the time. I’m really alone here? 🙁

    Besides. KWin team is incredible, and KWin is awesome. Improvement during KDE4 are huge and now none even think about using compiz with KDE, they are simply that happy with kwin. 🙂

    1. I disagree. Compiz has its use cases, but the new effect scripting engine is going to erase all the superiority Compiz has about eye-candy.

      However, we still need someone like QuinnStorm…

    2. I would not say all the time, but I tend to use Window Shading occasionally. Using the mouse scroll wheel to shade/unshade is quite convenient and a nice way to view the underlying window or desktop.
      I guess it’s because i don’t like the transparency stuff some seem to prefer.

    3. Maybe a silly question, but what is Window shading?
      Is it the function that you collapse a window so you only see the title bar?

  3. “Another area which has quite a rather large amount of wishes is Present Windows and Desktop Grid. […] Personally I have quite some ideas to improve this in 4.10.”

    Please tell use more soon 😉

  4. The improvements to Kwin have awesome. I really look forward to it’s future. Having said that, I think Kwin would be 1000% more awesome if I had the option to burn windows when closing them. It may be so 2005 but I miss that from Compiz/Beryl!! 😉

    1. Of course martin only confirms his suspicion, never realizing that it really probably just confirms mine. Most people aren’t caring to report bugs to a largely neglected bug system.

    2. I would also like burn windows! Actually as an additional request I would like a write up of how you do it using the new Javascript API that you are creating. There are a few things I would like to do too but I have no idea how to use the Javascript API but I know Javascript!

      Thanks!

      1. burning windows won’t be possible with the JavaScript API as we don’t have WebGL bindings (yet)

        1. My idea with burn windows using javascript was something like 10 or so different ‘burn’ animations (which are really gif’s of fire and close the window top down and insert those on top). That way we wouldn’t need to create the fire each time (it would be dumb fire), and therefore not need OpenGL. Is this not possible or is my idea just hideous?

  5. I think you probably underestimate your users. I’d be willing to bet 90% of KDE users know what kwin is, and could find the bug tracker (most linux users are relatively advanced users to begin with). it’s just that 90% of them don’t care, or don’t have any reason to. I would guess that most of those have no idea who you are though.

  6. Good accessibility effects are vital to me. The most important of all is invert colors. Although this can be achieved with xcalib -i -a (I’m SO glad this fallback method exists for older systems!), to be able to toggle the color inversion on a per-window basis is really useful to me. Also, I use the show mouse cursor effect very often.
    Well, and the zoom effect is a must-have for any serious DE, IMO.

  7. While brainstroming section is much better for discussing new features I have the feeling brainstorming don’t get much attention from developer side. There are so much good ideas, which have a busy discussion, good mockups and high rating, but in the end nothing (related to the quantitiy and quality of reports) happens. I’ve got the feeling that brainstorming is a place where the users can discuss until the topic gets boring and after some time no one will remember it. This is realy frustrating.
    I would wish that some of the maintainer would write some feedback to the feature wishes of the brainstroming section. Somthing like “It’s on my to do” or “That doesn’t correspond with my plan/vision”.
    Now at the time it’s more likely to get developer feedback if someone write to bugs.kde than to the brainstorming section.

    1. I can of course only speak for myself: I look from time to time into the brainstorm section but AFAIK I have not yet implemented anything discussed there.

      Feature requests are a difficult thing to do. Obviously users cannot know the internals of the application and cannot know the exact plans of the developers.

      It is quite clear to me that developers think on the long scope, like scheduling things to be implemented in two or three years. That does not fit to the users expectation of should be implemented yesterday.

      For me as a developer the brainstorm section is important as it provides a prefiltering bugzilla cannot provide.

      1. My post wasn’t against you. It’s rather in general.
        What I wan’t to say is that from my point of view the contact (feedback) between developers and feature/improvements requester is not as optimal as it should be (compared with bugs.kde).
        If brainstorming section should be successful there have to happen two things:
        – it should be the default place (kde-wide) for reporting feature wishes
        – some more feedback from developers/maintainer (doesn’t mean that the developer has to implement it, or has to give a time plan – something which shows that that someone is interested in it)

        1. Speaking with my forum admin hat on: we had the idea of using some stats to rank the ideas then submit those to BKO as wishlists (not all of them, just those passing the filter). However we lack the manpower to do so at the moment. Help is welcome.

            1. Skills: PHP mostly (brainstorm is written in PHP).
              What needs to be done: review the ranking in Brainstorm and see if it needs improvement, then implement a bridge to Bugzilla.
              The forum team hangs on in #kde-www on Freenode if you’re more interested.

    2. I just want to add something to that. I think it is highly important that the maintainers do not interfere with the discussions. I could basically block every suggestion on KWin just by saying “technically not possible” in the first comment to a suggested idea. But this would of course completely destroy the idea of brainstorming.

      It is a place for users to develop ideas without any limitations. The limitations are added later on by the developers.

  8. One of the first things I do on a new kde install is set:
    focus follows mouse
    click doesn’t raise window
    meta + left click = move window
    meta + right click = toggle raise / lower
    …(probably some other things I forgot)
    Now I have complete control of my windows 🙂

    Yes I also set some window specific rules (eg keep krunner on top and on all desktops) and set-up present windows just how I like it.

    Thanks for an awesome window manager

  9. There are only two things I’m missing for kwin to be perfect.
    1. Some “expo”-like feature, just like gnome-shell
    2. the ability to map a keyboard shortcut to “restore window”. Right now I’ve configured my shortcuts to be intuitive like Windows 7: Meta+Up maximizes, Meta+left fills left half of the screen, Shift+Meta+Right moves window to right monitor… But in Win7 when a window is maximized, Meta+Down restores the window and Meta+Down again minimizes it. In kwin Restore window has to be the same shortcut as maximize so in my case it’s Meta+Up which is completely counter-intuitive. The best would be to have a “Restore window, if maximized or minimize if not maximized” shortcut…

  10. Any chance the tiling functionality might get some attention? It seems quite broken at the moment, especially if you try to remove the title bars. Obviously I can’t speak for everyone but I’d rather prefer that working rather than getting another layer of ghastly glowing blue shine. 🙂

    Anyways, thanks for your work.

    1. yes tiling currently has our full attention, but that might not turn out the way you would like it 🙂

Comments are closed.