Community
Participate
Working Groups
When a category is double clicked in the mylar tasklist, it unexpectedly opens the category editor. The standard behavior for trees is to expand or collapse the children. This editor should be reached only from the context menu or rename using F2 to ensure that the users expectations are met
Created attachment 63792 [details] Double Click Patch Attached is a patch that makes double clicking on a category either expand or collapse the subtree instead of opening the properties of the category
Created attachment 63793 [details] mylar/context/zip
Patch applied.
This broke double-clicking on a query to open it.
Double clicking a query was part of the complaint as well. Whether it is a query category or a regular category, double clicking it should behave like a standard tree view and expand and collapse the nodes. I will agree that double clicking a query to open the editor can be useful, it is still not what a user would expect.
(In reply to comment #5) > I will agree that double clicking a query to open the editor can be useful, it > is still not what a user would expect. Personally I never use doubleclicking for expansion (there is [+] for that). But can live with Alt-Click and Alt-Enter for opening properties (similarly to property dialogs on windows).
I applied this patch too hastily and thought it was only regarding categories as stated. I'm updating the summary accordingly. I backed out the patch because I don't think that we have clear enough evidence that this behavior is more usable. Having category and query nodes open on double click was done by design and had some user demand. We decided that open actions were used more often on queries than expansion needed to be used, especially since we have the + for expansion as Eugene points out. This is not consistent with some other tree views, but I don't know of a UI guideline for this. For example, in the Package Explorer a file is a container element, but double-clicking it opens an editor without expanding. (Independently of this we could consider making the query editor an editor instead of a dialog.) Leaving this open since we may want to revisit this decision.
In addition to double click for open I'd like to see open categories restored when platform is restarted- would be happy to open new bug if required.
(In reply to comment #8) > In addition to double click for open I'd like to see open categories restored > when platform is restarted- would be happy to open new bug if required. Yes, please reopen a bug for that because restoring view state is a separate concern. Bumping priority since at least two users want this now.
(In reply to comment #9) > Yes, please reopen a bug for that because restoring view state is a separate > concern. Bumping priority since at least two users want this now. BTW, I am looking at bug 151432 now and it would benefit from restoring all the view settings, including filters, "go into" position and state of the "focus on workweek". 151432: Allow multiple instances of Task List view https://bugs.eclipse.org/bugs/show_bug.cgi?id=151432
Yup, we need a view memento for TaskListView. All we restore right now is filters and sorters, not expansion or Go Into state.
Opened bug 187955 for restoring view state.
Let's revisit this for 3.0.
+1 for making double click and enter expand nodes which is the default behavior of other tree viewers. Platform uses Alt+enter for opening property pages. The task list currently displays and an error when I try that: "No property page for .".
Steffen, when you do that, please take into the account that default behavior for double click and enter is actually a retargetable "Open" action if it is registered for given selection (e.g. open category editor) and only then expand node.
Thanks Eugene. The context menu of queries and categories does not have an "Open" entry (unlike tasks) but a "Properties" item. Mik, do you have any objections to making this change?
I have a slight preference for double click opening it for editing, but very slight. Either way it should be a very uncommon action, one way leans more towards generic tree viewer behavior, the other towards the Task List's double-click to open behavior. We also need to keep in mind what happens with tasks that have subtasks, since they need to open on double-click. Let's take a poll on making this change: +1 Steffen +1 Shawn -1 Mik Eugene: I couldn't tell if you were +1 or -1?
I am not sure what exactly *this* change is, but there are some inconsistencies with Eclipse and native UI that need to be cleaned up: - double click on task - opens task editor (consistent with other Eclipse views) - double click on category - opens category editor (somewhat weird editor, but generally consistent) - double click on query - opens properties dialog (inconsistent with other Eclipse views) - double click on week bucket and few other nodes does nothing (should expand/collapse nodes because there is no "open" action bound) Alt-Enter doesn't work anywhere in Task List view as Steffen already pointed out and it need to be fixed too (it should either open properties dialog or do nothing).
(In reply to comment #17) > We also need to keep in mind what happens with > tasks that have subtasks, since they need to open on double-click. This is similar to clicking a Java file in the package explorer. The editor is opened although the node can have children, i.e. the class and method nodes. The change I am proposing is the following: - Node that have an Open action (in the context menu) open on double click - Other nodes expand - Nodes that have a property action open the property dialog on Alt+enter - Other nodes ignore Alt+enter I find the category editor slightly awkward and inconsistent with other property / query dialogs. I will create a separate bug to replace the editor with a dialog.
+1. Just complementing: "unmatched" folders actually do nothing.
Let's clean this up early in the 3.0 cycle so that we have enough time for feedback.
Done. Double click/enter now expands/collapses nodes for everything that is not a task. Opening of property dialogs is now done through a handler which ensures the correct enablement and key-binding. Here is the xml for reference for future changes of that sort: <extension point="org.eclipse.ui.handlers"> <handler class="org.eclipse.mylyn.internal.tasks.ui.commands.OpenTaskListElementPropertiesHandler" commandId="org.eclipse.ui.file.properties"> <activeWhen> <with variable="activeContexts"> <iterate operator="or"> <equals value="org.eclipse.mylyn.tasks.ui.views.tasks"/> </iterate> </with> </activeWhen> <enabledWhen> <and> <count value="1"> </count> <iterate> <or> <instanceof value="org.eclipse.mylyn.tasks.core.AbstractRepositoryQuery"> </instanceof> <instanceof value="org.eclipse.mylyn.internal.tasks.core.TaskCategory"> </instanceof> </or> </iterate> </and> </enabledWhen> </handler> </extension> <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="popup:org.eclipse.mylyn.tasks.ui.views.tasks?after=properties"> <command commandId="org.eclipse.ui.file.properties" style="push"> <visibleWhen checkEnabled="true"> </visibleWhen> </command> </menuContribution> </extension>
Created attachment 97897 [details] mylyn/context/zip
