Bug 384782

See also bug 362077 comment #5.

*** Bug 293753 has been marked as a duplicate of this bug. ***

Why wontfix?

Christoph's link has the details. Unfortunately the code is sufficiently fragile here that we really can't touch it without a total rewrite at some point in the future, and it doesn't help anyone to keep open tickets that we can't resolve.

If you can submit a patch that implements this in a scalable and sustainable way, please feel free though!

*** Bug 391197 has been marked as a duplicate of this bug. ***

Fragile code hazard. I hope this is on a roadmap or todo somewere. If it is please let me know.

Re-opening to reflect the fact that we'll consider this with a sufficiently robust patch. :)

We decided not to do this. Instead we went for an alternative approach: Applets are now grouped into logical sections and retain their positions in those sections. So at least they shouldn't jump around anymore, and the ordering will never change.

If everyone hates this after a few releases, we can consider alternatives.

*** Bug 429146 has been marked as a duplicate of this bug. ***

*** Bug 433474 has been marked as a duplicate of this bug. ***

*** Bug 434629 has been marked as a duplicate of this bug. ***

*** Bug 436063 has been marked as a duplicate of this bug. ***

Maybe we should reconsider this. Requests are piling up. We could perhaps put the UI in the Entries page of the settings window, by making the list items draggable.

Having it as a optional thing wouldn't be a bad idea :)

Items are now sorted in SortedSystemTrayModel. It already has two sorting algorithms (SortedSystemTrayModel::SortingType): one for configuration page and second one for items in system tray. It should be pretty easy to add manual order. There is one issue with this: we need the same sorting for configuration page and system tray, if now manual sorting will need separate page in settings.

Or another idea, sorting is done in system tray itself, by drag and drop. It could work similarly as in Android notification area, when it is possible to add/remove/move icons in edit mode.

Thanks to Nate Graham for considering my demand and idea (sorting in Entries page with a draggable system).
I've suggested that idea because I thought the icons were sorted in the same order of the entries page from system tray settings (as it is where we can set the icons we want to always show or hide). But if the sorting can be implemented directly in the system tray as an easier solution, that one is best !

I think making it a drag-and-drop thing on the config page makes the most sense. The config page is the only place where you can see all entries--visible, hidden, and disabled--to be able to control the ordering of everything. It we implement drag-and-drop for the items themselves on the panel or in the popup, you would be unable to easily control the ordering for hidden or disabled items. And the ordering would change when a hidden item becomes visible, or vice versa.

I was thinking about this today. It would be really cool to have something similar to Android or Windows 10 but it has several usability problems:
* some icons can change status between active and passive - in visual edit mode it is hard to show all in one list
* there are icons visible on demand (like battery, bluetooth, keyboard layout)
* use can enforce status - dragging would be confusing, especially between hidden and active area
* plenty others



Entries list is good place to put ordering. I have few questions and concerns:

* Entries page and system tray icons have different ordering:
** on entries page, items are grouped by category, categories sorted alphabetically, then items in category are sorted alphabetically
** system tray show notification item always as first, then items are grouped by category, categories have explicit order ("UnknownCategory/Miscellaneous", "ApplicationStatus", "Communications", "SystemServices", "Hardware"), then items in category are sorted alphabetically
With different ordering on Entries page we can't just enable manual ordering - it must be consistent. Should we change ordering on Entries config page?

* we need a way to reset to default ordering (by category, then alphabetically). IMO the best would be to add dropdown with ordering options on General page: "Default (by category, then alphabetically), Manual (order manually in entries page)". I would like to avoid adding new controls to Entries page - list with icons/items should occupy as much space as possible. From the other side separating ordering options and Entries list is not intuitive. Maybe just one new checkbox ("Manual order") which enables custom order?

* Notification icon is always first - in manual ordering should we allow to move it?

More questions:

What to do with new items (first start of new application)? 
* Add them as first? Last? Add some more sophisticated heuristics and try to guess where it should be (that might be tricky)?

After manual ordering we will have a list of items stored in settings.
* should we ever remove items from it? Probably no.
* when new item appears, should we store it is settings automatically? Probably yes (to avoid random order with more new items).

My understanding is that ordering should be done in Entries page, I agree with Nate that is does more sense as it is the place where all items are shown, the one activated, deactived, showing/not showing.

Konrad, you have very good questions.

Either way looks good to me :
- adding the "items ordering" options in general page (just like icons size option) with "default mode" and "manual mode", radio button or dropdownlist.
- adding the checkbox in the Entries page aside the existing one, but for "manual ordering" option.

In the Entries page :
- In "default" mode, we shall keep the actual behavior.
- In "manual" mode, at first time I suggest to have Notification icon at the top of the list and the other items sorted alphabetically. Then the user would change the order (drag-and-drop), and of course he could also move the Notification icon.
In case the user deactivates the "manual" mode, nothing should be lost but kept in his preferences (stored settings). That way, in case the user would reactivate the mode, the items would be in the same order than previously.

If possible, when "manual" mode is set, the system tray should be consistent/aligned with the order set by the user. That means the system tray would behave differently in "manual mode" than in "default mode". So, in "manual mode" it should not care of categories, but care of user's ordering only.

In case any new icon/item appears, i think it should go at the last position. Then it is up to the user to rearrange it later.
In case the manual mode was used at least once (settings stored) but deactivated, any new item/icon should also be added/recorded at the end of the manual ordering list.

Adding items as first may annoy the user in case he doesn't care of that new item. Also, the more he gets new icons, the more his manual order would get changed/messed up. So adding items as last seems to be the best option.

I think we could add resize handles to the list items themselves. It's a built-in Kirigami thing, actually.

We'd need to either:
1. Only allow manually re-ordering items within their own groups
2. Allow re-ordering items to be outside of their groups, and then re-think the current grouping or the UI by which we present it to the user.

*** Bug 439244 has been marked as a duplicate of this bug. ***

Nate, if I understood Yannick correctly, in "manual mode" there would be no grouping, right? So the items would all be listed by alphabetical order (with the Notifications item being first), and the user would be free to move them all around.
The current groups would only show up in "default mode", where the user wouldn't be able to re-order the items.

Or we could just do away with groups entirely, in which case the user would be able to re-order the list freely (i.e. having just the "manual mode").

Grouping would make no sense in manual mode, yeah.

I don't even see a grouping option. Just entries with categories. Are you guys getting confused with Task Manager icons/text?

This is meant to be about System Tray Settings screen and adding a manual adjustment to its entries. For example I would like my VPN icon to be next to my Network Icon etc.. But atm it can't do that as its automatically sorted (and not very well)..

Yeah, by "groups" we mean the various categories (i.e. Application Status, Hardware, etc).
Nate said on #22 we could maybe add handles to the items themselves on the configuration list so we could move them around, but since we have those categories (groups), they would stop making sense if we could just move the items anywhere across them.
I agree with that, but I don't think we'd have that issue if we introduced the "manual mode" (see #21), where there would be no categories (the items would simply be sorted alphabetically, in one big list) and the user could re-arrange them freely; on "default mode", it would be the same as now: the current categories would apply, but the user wouldn't be able to move the items (so there would be no issues with inconsistent/redundant categories).

Therefore, I think Nate's resize handles suggestion would be perfect, if combined with Yannick's "manual mode"; I believe this would solve Nate's concerns expressed on #22, and it shouldn't be too hard to implement, making use of existing Kirigami code.
I'm really excited for this, hopefully we can finally make it happen :)

*** Bug 444845 has been marked as a duplicate of this bug. ***

*** Bug 452600 has been marked as a duplicate of this bug. ***

*** Bug 457567 has been marked as a duplicate of this bug. ***

*** Bug 457566 has been marked as a duplicate of this bug. ***

*** Bug 461607 has been marked as a duplicate of this bug. ***

(In reply to veggero from comment #32)
> *** Bug 461607 has been marked as a duplicate of this bug. ***

i had some suggestions on how to sort of do this here, if anyone wants to look into that.

I could try and see if i could find at least a better solution to this than what seems to be the current system, it would be an incomplete solution though. What it would do, is theoretically allow more customization, though i don't know enough to apply that in a great way right now.

(In reply to João Figueiredo from comment #27)
> Yeah, by "groups" we mean the various categories (i.e. Application Status,
> Hardware, etc).
> Nate said on #22 we could maybe add handles to the items themselves on the
> configuration list so we could move them around, but since we have those
> categories (groups), they would stop making sense if we could just move the
> items anywhere across them.
> I agree with that, but I don't think we'd have that issue if we introduced
> the "manual mode" (see #21), where there would be no categories (the items
> would simply be sorted alphabetically, in one big list) and the user could
> re-arrange them freely; on "default mode", it would be the same as now: the
> current categories would apply, but the user wouldn't be able to move the
> items (so there would be no issues with inconsistent/redundant categories).
> 
> Therefore, I think Nate's resize handles suggestion would be perfect, if
> combined with Yannick's "manual mode"; I believe this would solve Nate's
> concerns expressed on #22, and it shouldn't be too hard to implement, making
> use of existing Kirigami code.
> I'm really excited for this, hopefully we can finally make it happen :)

I think one potential idea as well, is to maybe modify how the hidden, shown, and categories list works, and decouple them all to different lists

That way, you can have the categories alphabetically ordered, and define the icons to be defined by two configs, one for when it's hidden, and one for when it's shown, potentially followed by reverting to an alphabetical listing for anything that isn't defined in those configs.

Maybe for a future plasma version though, if it would be a lot of work to rewrite all of that.

The best-sounding solution to me (a user, not really a developer) is to add two separate radio or checkbox lists: one for selecting how items are grouped, and one for selecting how items are sorted. The tray would manage the icons by first grouping them into the selected groups and then applying the selected sorting method to each group separately.

For example, you could select items to be grouped into the "default" groups, into a single group (AKA. no groups), or into "display" groups where it would group items based on whether they are always shown, sometimes shown, or never shown. Items would be sorted only within their own group. For sorting, you could select "manual" or "alphabetical" using radio options or a checkbox.

The items in the configuration list would have handles that would allow you to drag them around within their own group to order them while using manual ordering.

I don't know how difficult this would be to implement, but I believe that by separating this issue into two parts (grouping and sorting) we solve all conflicting problems, give the user the most control over their system tray, and make the process of organizing items intuitive and natural to the user (you group, then order).

Additionally, I hope that this solution will create a robust code implementation that is easily expandable by adding simply more grouping or sorting options if needed down the road. For example, if we wanted to add reverse alphabetical sorting you would only have to implement the sorting behavior, wouldn't have to worry about breaking the grouping behavior, and the interface wouldn't need to be redone (Just add a dropdown/radio/checkbox item to the existing list and provide it with your sorting function).

During the 6 years of this case being open there has been lots of positive discussion regarding design, I would like to shift the focus of discussion to project management. 

While the invitation for a volunteer to provide a solution has kindly been made, that approach is obviously ineffective. At some point, somebody with appropriate authority, needs to delegate this task to an appropriate developer, to begin implementation. Let's talk about how to make that happen? 

I unfortunately feel that I'd be the perhaps the least appropriate developer, given that I have little and aged experience with the toolchains in use, and I've long ago moved from development to management of development teams, but I'm not one to shirk responsibility, so if you must delegate it to me, do that, but please, let's put it in *somebody*'s to-do list.

I think the solution here could be pretty simple. A draggable ordered list of entries in the settings menu, with two options of how to place newly-appeared ('shown when relevant') icons: always in the specified order, or always added onto the end.

(Plus another option to reverse the displayed order of the tray, if you want the up-arrow on the other side, perhaps)

In the popup's grid of hidden icons, the order would also follow the ordered list of entries. (Or, if really desired, we could have one ordered list for in-tray, and a separate ordered list for in-popup, but that'd maybe be excessive)


To illustrate:
>Entries:
>App 1        Always shown         [-Drag-]
>App 2        Shown when relevant  [-Drag-]
>App 3        Always shown         [-Drag-]
>App 4        Always shown         [-Drag-]
>App 5        Always hidden        [-Drag-]
>App 6        Always shown         [-Drag-]

Tray when App 2 is idle:
> [1] [3] [4] [6] ^

Tray when App 2 becomes relevant (in-order setting):
> [1] (2) [3] [4] [6] ^

Tray when App 2 becomes relevant (added-onto-end setting):
> [1] [3] [4] [6] (2) ^


I don't think having the icons themselves draggable is important, as it might complicate the logic, but I think it'd be possible to still pull off. No groups/categories necessary in the entries list.

*** Bug 481566 has been marked as a duplicate of this bug. ***