72

The ZUI was the name for the original Activities interface, and it was a great idea, with a great many problems and a bad KDE implementation. Zooming in and out could make it so that you could no longer go back to your desktop and the ZUI presentation showed a sideways scrolling canvas that had a huge length no matter how many desktops you had running. The new activities interface is simpler and it works, but it doesn't work perfectly, and it definitely isn't the ideal solution. Like the Add Widgets interface, the Activities bar sits on top of your bottom panel and goes across the screen, covering up part of your desktop. Before selecting an Activity, there's no way to preview the Activity or know which applications are running. Because of these problems I sat down and drew up some ideas for how Activities could be switched, started, stopped, searched, and previewed. With the minimal amount of usability issues and inconsistencies possible.

A few quick points.
-Only running activities will be previewed by showing the desktop in the space to the right.
-Clicking on a desktop will select that activity, just as clicking it in the activity interface.
-All Desktops will automatically resize to fit within the screen space.
-After a certain number of activities are running, and the desktop previews get to be a certain small size, a right hand scrollbar will show that will allow a minimum expansion of new space vertically.
-Icons showing the running applications for each Activity will be shown below the Activity name.

<a href="https://picasaweb.google.com/lh/photo/AaGHh3-0211NiYOvJazg-fCdtWbyxO-UPjVh_oWQlFE?feat=embedwebsite"><img src="https://lh5.googleusercontent.com/-zzYZqIYLQpY/T2JVyr_4qZI/AAAAAAAAFSM/Qn3L_E6uFyM/s640/Activities-1.jpg" height="400" width="640"></a>

<a href="https://picasaweb.google.com/lh/photo/nAr0bF5_CiI58FPEi-vF7PCdtWbyxO-UPjVh_oWQlFE?feat=embedwebsite"><img src="https://lh3.googleusercontent.com/-7eGLyZ098hc/T2JVyWjTGNI/AAAAAAAAFSQ/ae6pS7NXb_w/s640/Activities-2.jpg" height="400" width="640"></a>

This is exactly what I'm looking for!

I'm learning to use activities recently, and I have set up two activities:
- the "work" activity is a folder view without any other widgets
- the "browse" activity is a desktop containing a lot of social and news widgets.

Because I have some windows open for "work", and some other windows for "browse", I have to put them in separate workspaces, and switch workspaces when I want to switch activities, which is somehow inconvenient.

Currently activities is made to be orthogonal to workspaces, which disassociates windows and widgets. However, in a lot of cases (like my case above), one particular window is associated with one particular activity, so it would make sense to let activities have the ability to manage windows.

I like it, but I don't know if I'm crazy about the "start" and "stop" buttons. Maybe have a list of activities that you can drag into the space on the right, and then X out of them. That way you could have multiple of one activity. Sort buttons could be added to the left column so that you could sort by activity type or last used or something. Maybe it comes too close to virtual desktops, but maybe that just merges the two to have the best of both worlds.

lamda9 wrote:This is exactly what I'm looking for!
Currently activities is made to be orthogonal to workspaces, which disassociates windows and widgets. However, in a lot of cases (like my case above), one particular window is associated with one particular activity, so it would make sense to let activities have the ability to manage windows.

I don't understand you,
in 4.6, activities can mange windows (right-click at a window title, and send the window to an activity)

envalin wrote:I like it, but I don't know if I'm crazy about the "start" and "stop" buttons. Maybe have a list of activities that you can drag into the space on the right, and then X out of them. That way you could have multiple of one activity. Sort buttons could be added to the left column so that you could sort by activity type or last used or something. Maybe it comes too close to virtual desktops, but maybe that just merges the two to have the best of both worlds.

yeah the start/stop button is just part of my obsession with details. It doesnt really matter in the long run, I just tried to come up with something that looked good visually. You could even remove that button completely and just use the entire activity entry as a giant button. If you look closely you can see that the stopped activities are raised and the running ones are inset or pushed down. The main idea is to have the activities interface as a left(or right) sidepanel and not have it sitting on top of the panel and covering up the desktop. The visuals are just my attempt to show an example of my idea that could be used to help a developer. The buttons, icons, colors, sizes, etc. are all just details and not really important.

Another idea is that this setup would work well for adding widgets as well.

The problem with any kind of zooming is that it would require composite (desktop effects) to be enabled.

So, your activities panel would cover a part of the desktop just the same as the current one does.

As for the layout itself, I like it, but when the (new) applet browser was created, people were against lists* (old applet browser) for some reason, so we ended up with a horizontal strip of icons.

So, I'm not really sure how well this would sit with other devs.

* ok, one of the reasons was that it needs to appear as a part of the panel when invoked from the panel...

ivan wrote:The problem with any kind of zooming is that it would require composite (desktop effects) to be enabled.

Would this still be the case if the desktops were noninteractible. meaning, why couldnt the desktops just be svg or some other type of image screenshot of the desktop, instead of actually trying to resize the running desktops and displaying them. instead u just have screenshot previews of the desktops and you wouldnt need desktop effects to display a screenshot. The zooming would just be a ratio resize on the images to fit within the space, which im sure would be pretty easy to do with programming.

ivan wrote:As for the layout itself, I like it, but when the (new) applet browser was created, people were against lists* (old applet browser) for some reason, so we ended up with a horizontal strip of icons.

I remember using the original add widgets browser, and its main problem was that it was a window that took up space in the middle of the screen and it was super buggy. It was difficult to search, the big stars looked weird and it had issues with drag and drop. Most likely the main reason people didnt like the list was that it was not perfect, which is understandable since we're talking KDE 4.0 and 4.1ish. I feel like the old add widgets list is a completely different interface than the left-hand sidepanel interface in my mockups.

Having the interface at the bottom across the screen (kinda like it is now) instead of the left sidepanel is a possibility, but to make it work you would have to shrink the desktop(s) and somehow get the panels to be a part of their desktops instead of the same consistent panels on every canvas. Which is something you guys have had trouble with and are working on iirc.

Anyways, I appreciate all of your work with activities and I know chani has done a ton of work on this, but when I was using the activities interface I just started thinking about how it worked and how it could possibly work better, and I came up with this idea and eventually these mockups.

Doing it without compositing would require dirty hacks (making a screenshot of a hidden window would involve showing it, taking the shot and hiding it) which are not going to happen (as with fake transparency of the panels etc).

That is a policy which was enforced since 4.x development started.


Well, the old appb had much less bugs than the current one has (had before 4.6). But, the bugs weren't the main problem - it was that it didn't feel a part of the desktop/workspace.


I'm lately not really involved much with the UI, especially when the activities are concerned, so that is the main reason I'm talking as an 'involved/in-the-loop' by-stander

We'll be discussing the UI for activities at Tokamak5 (a few months from now) and I'll bring up this idea as a reference of what can be done. What exactly will be the result from the meeting, I have no idea.

ivan wrote:Doing it without compositing would require dirty hacks (making a screenshot of a hidden window would involve showing it, taking the shot and hiding it) which are not going to happen (as with fake transparency of the panels etc).

That is a policy which was enforced since 4.x development started.

We'll be discussing the UI for activities at Tokamak5 (a few months from now) and I'll bring up this idea as a reference of what can be done. What exactly will be the result from the meeting, I have no idea.

I would appreciate you bringing it up. I wouldnt want to have to use hacks to create this interface, so I understand that, but I hope someone can figure out a solution so that we can have different panels for each activity and so that the activities interface doesnt cover up the desktop.

This. Is. Awesome.

plaristote wrote:This. Is. Awesome.

Thanks man. its probably my favorite mockup Ive done so far. it sucks that the devs are saying its impossible

@BSmith1012 - the mockup images and your blog are gone. It would be nice for you to make those available again. Maybe they will inspire someone to find a way to implement it.

Sorry about that. The blog got removed in favor of using Google+, and because I felt I was spending too much time on mockups with very little impact or results. The mockups folder I removed bc I had deleted my blog, but I forgot I had linked to them here as well.