1

Virtual desktops are great. So are tabs for separating Windows. My idea is to mix both making it possible for the user to show the virtual desktops as tabs with descriptive names that could be easily rearranged, added or closed like most tabs nowadays.

There could be an option for also closing the applications running on the virtual desktop being closed or to move them to the next tab, as well as whether to ask the user for confirmation or if she should be asked about what to do in those situations.

The current widget for alternating between virtual desktops doesn't make easy to remember what is on each tab, be it represented by number or by some small preview... Tabs titles are much more descriptive.

The tabs could be some panel that could be set auto-hide or that could be shown/hidden by some key shortcut for avoiding wasting space on screen. There should also be shortcuts for creating, closing and move tabs.

The cut and paste could also be applied for windows. For instance, one could cut (mark) some window(s) in a virtual desktop and paste (move) it to another one.

As I explained to you in the other thread, kwin developers have said that they will not implement adding or removing virtual desktops except at the end or implement changing their order. I told you in that thread that any idea including these features would be closed as wontfix. This idea includes all of those features. Therefore I am marking it as wontfix.

It is also multiple ideas. The appearance of the widget is independent from the cutting and pasting bit. The idea about using desktop names is also a separate idea, but it is already implemented in the current pager, so it would be marked as pre-existing. The thing about making the tabs a panel also isn't the correct approach, it should just be a standard plasma widget so it can go in a panel or directly on the desktop. Being able to open and close panels with a keyboard shortcut is a separate idea as well.

So this is five separate ideas, 2 of which are invalid:

1. re-ordering, opening, or closing any desktop: this is wontfix, as I already explained.
2. desktop names: pre-existing
3. keyboard shortcut for hiding or showing panels: valid
4. tab appearance for pager: valid
5. cutting and pasting window: valid

Please re-submit 3 through 5 as separate threads. Please do not include 1 or 2 in any of the ideas.

Once again, please only submit one idea per thread. If it is possible to implement part of the idea without implementing another part, they need to go in different threads. I know you think that the features could be useful if used together, but that doesn't change the fact that they are independent ideas. The fact that 40% of your idea is invalid while the remainder is valid should make it clear exactly why we have this policy.

Hi, before I create the new ideas, let me try to show you how some of them that are considered invalid could be implemented...

Tab moving: if you have tabs "a", "b" and "c" and want to have "a", "c" and "b", KDE can move the original windows in "c" to "b" and the windows in "b" to "c". I know there are more things that could be specific to some virtual desktops like widgets, wallpaper, etc. Personally, I don't care about them, but if someone cares, they could be moved too...

Tab closing: if it is possible to close the last tab, then it would be a matter of moving the tab to be closed to the last tab and closing it...

Although it seems a lot of work, I guess this would be a really fast operation that the user wouldn't be able to even perceive what is happening behind the scenes...

Could you talk to the developers about this possibility?

If I'm not mistaken... isn't this explaining what activities are supposed to do? You can essentially start or stop an activity which includes a unique desktop with specific applications open on it. Which makes it more efficient than what you are proposing right now.

rosenfeld wrote:Tab moving: if you have tabs "a", "b" and "c" and want to have "a", "c" and "b", KDE can move the original windows in "c" to "b" and the windows in "b" to "c". I know there are more things that could be specific to some virtual desktops like widgets, wallpaper, etc. Personally, I don't care about them, but if someone cares, they could be moved too...

kwin developers have said they are not going to do this. If you want to convince them otherwise, then you can discuss it on the mailing list. On the brainstorm forums we have a policy of respecting the developer's decision on whether they will or will not implement a feature.

rosenfeld wrote:Could you talk to the developers about this possibility?

The mailing lists are open to anyone. Staff on the KDE forums have no special channel to developers, you can contact them just as easily as we can.

Considering the number of people who have asked for something like this an been turned down, I sincerely doubt such a request will get anywhere, but you are free to try. I would, however, be ready for the possibility that asking them for the same thing they have already definitively stated, and you already know they have definitively stated, that they will not implement will only annoy them.

rosenfeld wrote:Although it seems a lot of work,

That is exactly the problem. It is not just a lot of work, it requires essentially re-writing from scratch the entire virtual desktop handling system. And considering the number of important tasks they have on their docket, and what they consider to be the very tiny benefit from this feature, they think there are far better uses of their time.

This is what I was trying to tell you in the other thread. Developer time is not unlimited. They have a lot to do, and they do it in their free time. A feature that only requires incremental changes is much more likely to get accepted, but even that is a long shot. If your idea requires massive changes to the underlying system, it is almost certainly not to get implemented.

There are only I think 2 or 3 major kwin developers right now, all doing it in their free time. They already have a massive problem handling the bugs from X11 and Mesa, moving to opengl ES, refactoring and dividing up the code in preparation for the move to wayland, better plasma integration, work on mobile platforms, and numerous other top-priority tasks. Most parts of KDE, and the FOSS world in general, have man-power limitations like this.

So it is in your best interest to come up with a way to make your ideas as easy to implement as possible.

envalin wrote:If I'm not mistaken... isn't this explaining what activities are supposed to do? You can essentially start or stop an activity which includes a unique desktop with specific applications open on it. Which makes it more efficient than what you are proposing right now.

Hi envalin,

While I think the idea of activities are valid and was interested on this feature when I first heard about it, I still couldn't apply it in practice... I couldn't use activities yet and I don't know exactly why...

Let me explain how I work and what I believe activities were made for, and then you may agree that they don't fit very well. We are talking about application organization here.

From what I understand, activities were created for people that have a somewhat static applications group. I mean, the overhead of creating an activity and deciding which application is visible in which activity is ok once your applications group don't change very much.

This is not what happens to me. I want to rearrange applications very often depending on what I'm doing in the moment. So the overhead is too high for me to get used to activities.

I used to feel the same about code editors in the past. I wanted some way of organizing the source code so that I could change between some files very easily. But I didn't use some features from Netbeans, for instance, like horizontal splitting because they were too costly most of the time.

When I started learning Vim, some time ago, I was pretty unsatisfied with the IDE's and editors I tried before, so I decided to take some time to learn Vim.

After that, I found that editing multiple files on the same screen could be very easy and very helpful. Usually I do MVC web programming, which means I need to write code in the controller, view, model and Javascript. Sometimes I need to view and edit all of them at once. This is very easy to achieve with Vim.

Besides the editor, I also need one or two web browsers as well as a terminal session, at least. Than I miss the same easiness of Vim on my desktops for organizing windows. I need something that can help me organizing my windows dinamically, preferentially without the need of using the mouse for that. I wasn't able to get this flow with activities yet. Maybe it is possible but I couldn't find any documentation on that. Also I don't find it very intuitive, like tabs are.

That is why I'm proposing some ideas that I think could create a better experience for desktop users. But I don't know enough of KDE internals to help me propose the ideas in some way that is easier to implement. I just know what I want, and I hope you can understand that and help me providing more information so that I can understand the limitations and try to think how to achieve some similar effect without too much rewrite on KDE internals...

TheBlackCat, I'll reply to you as soon as I finish the pizza that just arrived...

Just finished the pizza

TheBlackCat, first of all, I'd like to thank you for being patient with me all this time and for your time on moderating the Brainstorm and to guide people here. I really appreciate the work you've been doing.

Also, I do understand now, that this subject was already discussed with the developers, including the idea of simulating tab moving, so I will not insist on that, since it seems the decision was already taken about this and I don't want to bother the developers either, so I'm giving up on this idea.

Then, I would like to change a bit the subject to talk about the KDE Brainstorm Ideas goals.

When I first read about it, when it was created, I guessed, from the reading, that it was a place for users (possible non developers) to ask for features or changes in KDE. I was very excited about this idea, so I started sending some thoughts I had about usability on the desktop.

I didn't understand that the ideas should be somewhat easy to implement for the idea to be accepted. I do understand how open-source works, since I have already contributed to some projects, like Rails, Redmine, Gitorious, etc with some minor patches. So, I understand that developer resources are both valuable and limited.

I don't feel that the developers should take any of these ideas and implement them. They will do if they want to, when they have the free time and they will take the time they need.

However, I separate very well the idea from the feasibility. One thing is to decide that the idea won't be implemented because the KDE community don't think it fits in the KDE goal.

Another thing is to decide that the idea, even being interested, won't be implemented because it would require too much work that do not pay off.

While in the first case there is too little chances to change the situation, in the second case, as the code base evolutes or when some possible new contributer wants to try the refactoring work, there are some chances that the idea may become feasible in the future.

So, I guessed that in the second case, KDE Brainstorm would be the right places for these ideas too. I guessed that an accepted idea definition would be something that KDE agrees that it fits on KDE environment and that it's useful, then if someone is interested enough to work on it, it would be ok.

That is one of the goals of KDE Brainstorm I thought. Now, I understand I was probably wrong from the beginning. I'm understanding that an idea to be accepted must be feasible now and should not change substantially from the current implementation or it won't be done.

Then, from our conversation, I realized that what I'm asking for a better desktop experience is actually too hard to be done in this moment, with the current developers resources, and so, it won't be an accepted idea.

Also, while designing mentally a user experience on desktop, it is very hard for me to separate an overall idea in several pieces because I can only see its usefulness when integrated to each other.

I like some Agile processes like Extreme Programming. It values the interaction between the end users and the developer team, reducing its barrier through one or two managers. When the developers are able to talk directly to the end users in some meeting, chances are good that the goals of the meeting will be better achieved.

In Scrum, also the backlogs are good things. You write several stories in the backlog and then decide in which sprint each should be done. Some of them will be changed by the end user as time goes and some of them could be even dropd from the backlog.

This mean that an idea could be accepted now but rejected in the future and everybody (the team and the end user) is ok with that. Agile is all about embrace changes.

I've wrongly associated the KDE Brainstorm with some sort of backlog and the place where developers and end users could discuss about the subject helping designing a common term story that both could agree with.

In XP or Scrum meetings, the developers will listen about the client's ideas and suggest some changes trying to make it easier to implement some changes while still meeting the end user needs. That is one of the things that allows the project to be finished sooner and with quality.

That process works for me, but the current one adopted by KDE brainstorm doesn't work very well for me.

Having said that, I'm very sorry for being giving up completely on my ideas. This is not personal, and I really value your contribution to KDE moderating this important project that is KDE Brainstorm.

I'm sorry for wasting your time, but I realized that if I insisted on this I would just waste more of your time, which I don't want to do.

Thank you very much for your patience and guidance, explaining with details how things do work in KDE and I hope you can forgive me for taking too much of your time and giving up on my ideas in the end.

Best regards!

rosenfeld wrote:I didn't understand that the ideas should be somewhat easy to implement for the idea to be accepted.

That is not a rule. Ideas can be as difficult to implement as you want, although it can't be fundamentally impossible or already rejected by developers. I was simply giving you some practical advice that if there is a way to modify the idea to make it easier to implement, it is more likely to get implemented. You don't have to do that to get it accepted, it just increases the chances that someone will actually implement it.

This was mostly directed at your "one-screen multi-desktop idea", where as it was currently written is very difficult to implement, but with slight changes could be very easy. I said both ideas would be accepted here, but the latter would be more likely to actually be implemented, and at least in my perspective having something that is almost what I want is better than having nothing at all.

So I was not stating the rules of the brainstorm section, I was simply trying to help you increase your chances of getting the features you want implemented.

rosenfeld wrote:
So, I guessed that in the second case, KDE Brainstorm would be the right places for these ideas too. I guessed that an accepted idea definition would be something that KDE agrees that it fits on KDE environment and that it's useful, then if someone is interested enough to work on it, it would be ok.

But if the developers have already rejected the idea, that means they are aware of the idea. The purpose of brainstorm is to pass ideas along to developers. Once the developer is aware of the idea, we close the idea as "submitted". So the idea would still be closed. If there comes a time when the developers changed their mind, we will update the status of the idea here as well.

So any idea that developers know about is closed. The "wontfix", "done", and "in progress" statuses provide more details about the developer's stance on the idea once they found out about it.

rosenfeld wrote:
Then, from our conversation, I realized that what I'm asking for a better desktop experience is actually too hard to be done in this moment, with the current developers resources, and so, it won't be an accepted idea.

That is not a decision we make here. If an idea is very hard to implement we still accept it. The only things we don't accept are where it is either fundamentally impossible given the current code-base, or where developers have explicitly stated they will not do it. This idea falls into the latter category. Even if I knew it was very hard to implement, I would still accept the idea. But when the developers say it is too hard to implement so they won't do it, we accept their judgment on the matter.

rosenfeld wrote:
Also, while designing mentally a user experience on desktop, it is very hard for me to separate an overall idea in several pieces because I can only see its usefulness when integrated to each other.

You shouldn't think about it in terms of usefulness, you should think about it in terms of implementation. "Is it possible to implement part of the idea without implementing another part?" That is the question you should be asking. If that is the case we need them in different threads.

The problem is this: we mark which ideas have been implemented. What if part of the idea is implemented, and part isn't? How do mark the idea? What if someone likes part of the idea but not another part? How do they vote? What if developers say part is impossible but part is good? How do we mark it then? Splitting the ideas up is the only way we can keep track of the progress of the idea.

rosenfeld wrote:I've wrongly associated the KDE Brainstorm with some sort of backlog and the place where developers and end users could discuss about the subject helping designing a common term story that both could agree with.

Although there was some hope about this initially, that is not how things turned out. Very few developers read the brainstorm forum. The goal now is to move popular ideas to bugs.kde.org, which many developers do read. There is nothing we can do about that, developers choose how to spend their time.

Ok, I think I understand much better now how Brainstorm works and what are its goals, thank you once more for explaining it in more details.

Then, I was trying to adapt my workflow to what is currently already possible in KWin. After getting Google Chrome to work with applications grouping setting it to use the title bar, I think that with some minor modifications I could get most of what I really want.

So, I would like your help for guiding me on how many ideas I should split the overall idea and how to approach them.

First, forget about the tabbed desktops. I realized that the tabbed application group would be enough for me.

What would really make my life easy is the ability to have a window container instead of an application in the applications group. I mean, instead of grouping applications, we could group window containers.

By default, every launched application would actually be a window container, containing a single application.

With some shortcuts, each window container could be split horizontally or vertically.

In the new empty space, there could be an application launcher widget for running a new application fulfilling that space.

If any window is moved to the empty space instead, it would occupy that space. Whenever some window is grown or reduced, the remaining windows would be resized to fit the remaining space.

Remember that each window is actually some container containing the application. This mean that each of the split could be either split again both vertically or horizontally and so on.

And any of them could be added to some application group, so that we could alternate between different layouts and application using tabs as it is already supported.

Was I clear? If you didn't understand it exactly feel free to ask me and I'll try to explain it in another way...

Thanks in advance!

Make mockups. People like them more because they don't have to read as much, and anyone trying to implement it knows exactly how to draw it

Hi envalin, I'll try to. Since it will take me more time, I'll probably will only be able to start working on them on next weekend. Do you recommend some software for the mockups?

You'll generally notice that people will take screenshots of what they have, and add what they want using the GIMP, and then preferably cropping out everything not pertaining to the idea to highlight it. You'll notice the most successful ideas have little writing but clear pictures. Time isn't an issue if you intend on getting your idea fully supported.