Community
Participate
Working Groups
Mylyn Team preference page could use some cleanup. For instance, remove groups, fix vertical scrollbar on the text area and also remove usage of the deprecated API.
Created attachment 85942 [details] before
Created attachment 85943 [details] after
Created attachment 85944 [details] patch
Created attachment 85945 [details] mylyn/context/zip
+1 Mik, is it okay to merge the patch?
I like the simplification, but after applying the patch the page looks too inconsistent with the other preference pages. In addition, for 3.0 it is possible that we'll either merge this page or end up with additional things on it. How about making this a group called "Change Set Management, leaving the previous label in for the boolean, and moving the template box inside?
(In reply to comment #6) > I like the simplification, but after applying the patch the page looks too > inconsistent with the other preference pages. In addition, for 3.0 it is > possible that we'll either merge this page or end up with additional things on > it. How about making this a group called "Change Set Management, leaving the > previous label in for the boolean, and moving the template box inside? Mik, the proposed UI design been made for the current settings and it can be adjusted in the future in case if new settings will added to this property page. The idea was to incrementally move away from heavy use of the group widget. Having single-widget groups doesn't make much sense and in many cases multiple groups are unnecessary (subjectively dialogs look less crowded without them).
I agree that this would be a first step to remove some of the grouping borders from the preferences pages. Other good candidates would be the Resources and the Task List page. What if some of the borders were removed on those pages as well to make it look more consistent?
Sounds good, let's iterate on the preferences design for 3.0. Pages that don't have a logical grouping can lose the group widget.
Steffen: when removing a milestone from a bug it's a good practice to provide a reason (I realize that this gets abused sometimes, but it's better to do so and not follow up than not to do so). I'll consider applying this once we start the revisions of preference pages for 3.0.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
I'll consider rewriting the patch for 3.1.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
