Community
Participate
Working Groups
First steps for generalizing the Task Repositories view: * Add categories presentation similar to the Task List: Tasks, Bugs, Other * Rename view to "Team Repositories" Some thought needs to be put into how connectors can specify the repository type and how existing repositories can be migrated.
What if we add a *category* element to the org.eclipse.mylyn.tasks.ui.repositories extension point. We could then add *category* as an additional attribute on *connectorCore* elements. The TaskRepository view would then present all contributed Categories in a tree view. TaskRepositories have a connector kind, Connectors have categories. Thoughts?
I thought the point of the categorized list was to avoid hierarchies at least as long the view is a configuration UI and does not allow interacting with repositories (e.g. browsing of artifacts). If categories are defined through the extension point that would allow connectors to define custom categories. Do we want that?
(In reply to comment #2) > I thought the point of the categorized list was to avoid hierarchies at least as > long the view is a configuration UI and does not allow interacting with > repositories (e.g. browsing of artifacts). My thinking was that new categories would always be top level nodes with only repositories as the children. > If categories are defined through the extension point that would allow > connectors to define custom categories. Do we want that? Good question. There could be existing Mylyn categories (Tasks, Bugs, Other) that extenders would usually set as the category but could also declare others. This could lead confusion if everybody thinks they need their won category though. Perhaps Tasks, Bugs, Other should just be THE options on the extension point.
Created attachment 162480 [details] v1 work in progress
Created attachment 162481 [details] mylyn/context/zip
Created attachment 162482 [details] sample Just to give an idea of what this looks like with the gradients.
That looks good. I guess the open question is how do repositories get categorized? I wonder if there should be a standard set of categories in Mylyn (i.e. tasks, bugs, reviews, builds, scm, etc) that connectors can specify what category(ies) they should/could be in. I would assume that task repository can't be a build repository, meaning that a user should have to choose from task or bug repository. Maybe there should be a check if it can query and can create task to determine if the user should make a selection or not?
Thanks for the screenshot. Does the indentation come from using a tree? Do you see a need to implement specific behavior for categories (repository kinds)? I was thinking of categories as a simple attribute on a repository hence it seems overkill to me to extend AbstractRepositoryKind. Why not use a concrete class and create three instances with different properties (similar to an enum)? Why does AbstractRepositoryKind implement IRepositoryElement?
(In reply to comment #7) > That looks good. I guess the open question is how do repositories get > categorized? I wonder if there should be a standard set of categories in Mylyn > (i.e. tasks, bugs, reviews, builds, scm, etc) that connectors can specify what > category(ies) they should/could be in. I was imagining a category property on TaskRepository objects. I would be careful with calling this kind since kind is already used in various contexts and repository kind vs. connector kind can get very confusing particularly since there are still legacy classes that inconsistently use repository kind. > I would assume that task repository > can't be a build repository, meaning that a user should have to choose from task > or bug repository. Maybe there should be a check if it can query and can create > task to determine if the user should make a selection or not? I would keep the behavior and configuration separate from this. We already have API for determining capabilities and we should consider extending that if capabilities are missing.
(In reply to comment #9) > (In reply to comment #7) > > That looks good. I guess the open question is how do repositories get > > categorized? I wonder if there should be a standard set of categories in > Mylyn > > (i.e. tasks, bugs, reviews, builds, scm, etc) that connectors can specify what > > category(ies) they should/could be in. > > I was imagining a category property on TaskRepository objects. I would be > careful with calling this kind since kind is already used in various contexts > and repository kind vs. connector kind can get very confusing particularly since > there are still legacy classes that inconsistently use repository kind. 'Category' works for me. So it sounds like connector extensions should declare which of a set of pre-defined categories their repositories should be a part of? The indent is likely due to it being a tree, I'll see if it can be avoided.
(In reply to comment #10) > 'Category' works for me. So it sounds like connector extensions should declare > which of a set of pre-defined categories their repositories should be a part of? I don't think this will require any new API since connectors already manage creation of repositories in the settings page. I was just saying that I would not enable/disable any UI elements based on the categorization but use the existing can...(), supports...() methods on the connector classes to control that.
Shawn's comment does raise an important point though in regard to repository presentation in wizards for instance. There is a question whether users should be able to filter by category or if categories should be shown in those views as well.
Created attachment 162541 [details] categories Updated to use a new Category object.
Created attachment 162542 [details] mylyn/context/zip
(In reply to comment #12) > Shawn's comment does raise an important point though in regard to repository > presentation in wizards for instance. There is a question whether users should > be able to filter by category or if categories should be shown in those views as > well. I think that filtering by category should be allowed (and could be done automatically if a user says add a repository from a category). It would probably make some sense to have the categorization in the new* wizards as well since it would help users to find what repository they are looking for.
Created attachment 164447 [details] v3 Incremental improvements. New Task wizard has category decorations. Would be nice to be able to categorize the connector selection page as well but connectors would need to have a category assigned. Just noticed that this patch removes some of the NON-NLS tags, will need to fix this in next patch.
Created attachment 164448 [details] mylyn/context/zip
Created attachment 167360 [details] Screenshot: Categorized Task Repositories View
Created attachment 167361 [details] Screenshot: Categorized New Task Wizard
Rob: Can you proceed with this? Looks like what you're missing is the proper indentation, like we have in the Task List? Please use the Task List style for now (indented, with icons) and we can consider improving on that post Helios, eg, with an iTunes style of bold sections, extra spacing, and no icons.
Can do. Will try to get another iteration done for Thursday.
Created attachment 168302 [details] v4 Repositories nested below Categories
Created attachment 168303 [details] mylyn/context/zip
Created attachment 168304 [details] team repositories screenshot
Created attachment 168305 [details] new task dialog screenshot
That looks pretty good. Can the categories be expanded and collapsed?
(In reply to comment #26) > That looks pretty good. Can the categories be expanded and collapsed? Yes, and currently the code expands them all by default.
Points from UI review: * Will need to take heuristic approach to categorizing existing repositories and those added via extension point (i.e. check for support extension usage) * Category should likely be applied in the Task Repositories view and may need a combo (i.e. a setNeedsCategorization(boolean) method as per usual,if we allow users to adjust categories)
Looking good. We can give it the nice Task List gradients as a polish item later on. Is this Common Navigator based? Ie, will tools like EGit be able to add their repository content into it?
Gradients are there, just didn't come across well in the screenshots. The content model is the same but we can swap it out at a later date.
Created attachment 169716 [details] v5 Includes repositoryMigrator extension. Connectors need to implement AbstractRepositoryMigrator to move their respective repositories to Tasks or Bugs, otherwise they're collected under 'Other'. BugzillaRepositoryMigrator and LocalRepositoryMigrator serve as examples.
Created attachment 169717 [details] mylyn/context/zip
Created attachment 169742 [details] v5 repost
Created attachment 169748 [details] v5 again less x contamination
Some suggestions: * Please add API documentation for AbstractRepositoryMigrator and set the copyright header to 2010. * Add categories for Build and Review and don't show empty categories. * I can select a repository category when creating a new query (the Next button should probably be disabled in that case) I have a concern that it is too late to rename the view considering that this affects almost all documentation such as user guides, FAQs etc. including documentation maintained by integrators. My initial impression was that this change does not provide any value at the moment since there are very few categories and I can't change categorization manually. It would be nice if I could group less frequently used repositories in a category and have that node collapsed by default for instance.
Created attachment 169873 [details] v6 * -Please add API documentation for AbstractRepositoryMigrator and set the copyright header to 2010.- * -Add categories for Build and Review and don't show empty categories.- * -I can select a repository category when creating a new query (the Next button should probably be disabled in that case)- Still work in progress.
I discussed renaming the view briefly with Mik and we decided that it's best to hold off with that for now due to the required documentation changes. Let's create a separate bug for that so we can consider it for later.
Okay, committed. Created bug#314351 to address rename.
It seems that the local and Eclipse.org repository do not get categorized if I start a clean workspace for the first time.
I'm wondering if we should remove the categorization from the "New Task" wizard/dialog. It seems like overkill.
Final nits committed. Marking resolved.
Rob, I just noticed that creating a new repository does not have it properly categorized until a restart. It seems that the bugzilla, trac, web and xplanner connectors should set this in the applyTo method of the repository settings page as well.
Rob, can you confirm that comment 39 has been addressed?
(In reply to comment #42) > Rob, I just noticed that creating a new repository does not have it properly > categorized until a restart. It seems that the bugzilla, trac, web and xplanner > connectors should set this in the applyTo method of the repository settings page > as well. Done. (In reply to comment #43) > Rob, can you confirm that comment 39 has been addressed? It is now.
I find it a bit weird that migrators are invoked each time a repository is added. That should definitely not happen in the synchronized block. Wouldn't it be sufficient to specify categories in the repository templates or run migrators after templates are loaded?
Refactored to apply after template is loaded.
Great, that works! Looks like we are done.
