https://bugs.kde.org/show_bug.cgi?id=362774
Erik Quaeghebeur <kdeb...@equaeghe.nospammail.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kdebugs@equaeghe.nospammail
| |.net
--- Comment #6 from Erik Quaeghebeur <kdeb...@equaeghe.nospammail.net> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
