Bug 362774 - KDE Activities do not have a well-defined ordering
Summary: KDE Activities do not have a well-defined ordering
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Activity Switcher (show other bugs)
Version: master
Platform: unspecified Linux
: NOR normal
Target Milestone: 1.0
Assignee: Ivan Čukić
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-07 08:06 UTC by Steve Phelps
Modified: 2016-10-09 20:17 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Phelps 2016-05-07 08:06:12 UTC
Activities do not have a consistent ordering, and appear in a different sequence depending on the kind of widget used for switching.  This makes it hard for the user to navigate between activities, since they need to remember that activities appear in a different order in different widgets.  

For example, I have the following activities defined: { "System", "Development", "Lab", "Latex", "Office", "Reading"}.  In the activity manager, they are sorted alphabetically from top to bottom: ["Development", "Lab", "Latex", "Office", "System", "Reading"].  However, I also have an activity pager widget in my task bar, and the activities there appear in the following sequence: ["Development", "System", "Office", "Latex", "Reading", "Lab"].  This makes navigation between activities very error prone.

Activities should have an associated well-defined extrinsic ordering.  Moreover, the user should be able to *configure* the ordering, because some activities are related to each other. Allowing the user to specify the ordering would ensure that it is quick and painless to switch between related activities.  

This functionality was previously provided by virtual-desktops in KDE 4.x, but is no longer provided in KDE 5.

Reproducible: Always

Steps to Reproduce:
1.  Configure some activities in a particular sequence
2.  View the activities in the activity manager; they will be sorted alphabetically
3.  View the activities in the activity pager; they will be sorted arbitrarily

Actual Results:  
 In Step 2 the activities will be sorted alphabetically whereas in Step 3 the activities will be sorted arbitrarily.  

Expected Results:  
The sequence of activities should be consistent between different views. 

The sequence that activities should appear in should be consistent across different UI views.  Moreover, the sequence should be configurable by the user.
Comment 1 Kai Uwe Broulik 2016-05-13 08:38:38 UTC
I thought activities were supposed to be sorted by last use, Ivan?
Comment 2 Ivan Čukić 2016-05-14 13:41:03 UTC
@Kai - activities in the switcher, yes, but in other places they use UUID ordering which is not really a good idea :)

I think an alphabetic ordering will be sufficient for the other places.
Comment 3 Steve Phelps 2016-05-20 10:02:41 UTC
Alphabetic ordering is not ideal.  It is not unreasonable for users to have a preference over the ordering. For example, if two activities are related, and the ordering can be configured, then the user can group those two activities together so that they can easily switch back and forth between them with a single (Shift)-Meta-Tab key press. Moreover, if related activities are adjacent to each other in the UI, it is also easy to navigate between related activities using the mouse. 

If you insist on an alphabetic ordering, then a user who prefers related activities to be adjacent is forced to name their activities by manually prefixing them with a letter; e.g. "A - System", "B - Development", "C - Latex" etc.., which is *extremely clunky*.

Most modern software allows the user to re-position or re-order key user-interface elements according to their preference.  For example, nearly every e-mail app allows users to customise the order in which folders belonging to different accounts appear in the main application window.  Why should alphabetic ordering be imposed on the user?
Comment 4 Ivan Čukić 2016-09-18 09:08:20 UTC
@Steve

Activities in the switcher are ordered by the most recently used - and that will not change (at least when the default switcher is concerned).

There were some ideas of allowing the users to group activities, and to create sub-activities - to have the related ones grouped, but it was decided it would be an overkill. Activities are meant for macro-management of user's work, and micro-managing them seems like a 1% use-case.

> Most modern software allows the user to re-position or re-order key user-interface
> elements according to their preference. For example, nearly every e-mail app allows
> users to customise the order in which folders belonging

Yes, people tend to have a few dozen mail folders. And sub-folders in them. And this requires being able to reorder them to keep the organization sane.

If you have a few dozen running activities, you are doing something unorthodox (not to say wrong).

The 'unorthodox' use-cases do not warrant creating a complex mechanism (and the overhead it would produce) of syncing the order in all the different places.

If you want to have grouped activities - or related as you have put it - you can prefix their names with the name of the thing that makes them related. Something like:

 "KDE > Localization"
 "KDE > Development"

It will have the benefit that you get all kde-related activities in the switcher just by typing 'kde', and in the alphabetical-ordered lists, they will appear together.
Comment 5 Ivan Čukić 2016-09-18 10:57:01 UTC
Git commit 19d64627dffff9251adf1a24fec7bdfb9a931d58 by Ivan Čukić.
Committed on 18/09/2016 at 10:52.
Pushed by ivan into branch 'master'.

Sorting activities in the cache alphabetically by name

Many activities clients just show the exact list of results
that the library returns them. in the order that the library uses.

Since this order ends up being shown to the user in quite a few places,
the library now sorts the activities internally.

This affects:
 - KWin (window menu)
 - KCM for window rules
 - Activity pager
 - maybe something else as well

M  +0    -10   src/common/dbus/org.kde.ActivityManager.Activities.h
M  +26   -17   src/lib/activitiescache_p.cpp
M  +27   -11   src/lib/activitiescache_p.h
M  +2    -2    src/lib/info.cpp

http://commits.kde.org/kactivities/19d64627dffff9251adf1a24fec7bdfb9a931d58
Comment 6 Erik Quaeghebeur 2016-10-09 14:40:56 UTC
I landed in this bug because I was frustrated by the fact that I couldn't give my (6) activities an order, mostly in the pager.

I have the feeling the RESOLVED FIXED refers to the activity manager. Is there another bug for the pager?

One more thing I wanted to react to, because I found a response unfair to the submitter (and myself, given that my use case is mostly the same):

(In reply to Ivan Čukić from comment #4)
>
> There were some ideas of allowing the users to group activities, and to
> create sub-activities - to have the related ones grouped, but it was decided
> it would be an overkill. Activities are meant for macro-management of user's
> work, and micro-managing them seems like a 1% use-case.
>
> > Most modern software allows the user to re-position or re-order key user-interface
> > elements according to their preference. For example, nearly every e-mail app allows
> > users to customise the order in which folders belonging
> 
> Yes, people tend to have a few dozen mail folders. And sub-folders in them.
> And this requires being able to reorder them to keep the organization sane.
> 
> If you have a few dozen running activities, you are doing something
> unorthodox (not to say wrong).

You've built a strawman argument here. The submitter just wants to order some activities (6 in his example) and ordering already makes sense (in the pager or elsewhere) starting from 3 or certainly 4 activities, not dozens. Moreover, ordering is not the same as sub-activities, grouping etc.
 
> The 'unorthodox' use-cases do not warrant creating a complex mechanism (and
> the overhead it would produce) of syncing the order in all the different
> places.

I agree that complexity can be a good reason to not implement a feature. But adding an integer for the order to whatever object represents the activity will not have any discernible overhead. Sorting based on that integer will certainly not be less efficient than sorting based on activity name. Alphabetic sorting makes no sense unless there are an ‘unorthodox’ large number of activities, so that approach could be dropped in the code to only rely on the ‘order integer’ (which could default to alphabetic upon activity creation to preserve the current behavior).

I understand that this may not be a priority in a sea of other things that you can contribute to, and I accept that and don't request that this issue be reopened, but the arguments used were, I think, not fair.
Comment 7 Ivan Čukić 2016-10-09 17:28:59 UTC
> But adding an integer for the order to whatever object represents the activity

Not as simple as that. That integer needs to be synchronized across all clients, to be introduced in a backwards-compatible manner to the syncing protocol, and be done so that all possible cases of service supports or doesn't support reordering, client supports or doesn't support reordering work (since the service and the client library are released separately).

Then, you need to implement a pretty drag and drop UI for reordering.

Then, you need to deal with the model updates - where does a new activity go? (and then deal with all the bug reports related to where you chose for it to appear - like we have for applications in the menu)

> elsewhere) starting from 3 or certainly 4 activities, not dozens

Reordering is (IMO) useful when you want to find something more quickly. If you have 3 or 4 activities, you can not have problems to find a specific one.

p.s. Nothing here is about the pager specifically. It would be 'easy' to make the reordering for one thing, if the order does not need to get propagated to all the other places. And the pager is in the kdeplasma-addons so it can do whatever it wants to - they are less constrained to fit well into the rest of the Plasma workspace, than components that actually ship with Plasma. If this weren't the case, activity pager would not exist in the first place.
Comment 8 Erik Quaeghebeur 2016-10-09 19:23:03 UTC
(In reply to Ivan Čukić from comment #7)
> 
> Not as simple as that. 

Thanks for the further explanation. 

> p.s. Nothing here is about the pager specifically.

That is useful to know. I'll see whether the pager authors are receptive to such a feature request.
Comment 9 Erik Quaeghebeur 2016-10-09 20:17:09 UTC
(In reply to Erik Quaeghebeur from comment #8)
> (In reply to Ivan Čukić from comment #7)
> >
> > p.s. Nothing here is about the pager specifically.
> 
> That is useful to know. I'll see whether the pager authors are receptive to
> such a feature request.

Bug 370372