Community
Participate
Working Groups
Here are my thoughts on this: * When a query is closed, it does not participate in the automatic sychronization process - it doesn't need to * Manual synchronization is disabled for closed queries * When a query opened, it is *not* synchronized immediately; instead, it is added to the queries that will be automatically synchronized in the next synch interval (actually, i'm maybe some people would want to synch upon opening, so maybe this could be a configurable option in "window > prefs > mylar"...but we would want to make sure that if someone were to open/close/open some query too quickly, that it only gets synchronized once within a given interval) * You can filter the task list to only show open queries (just like "Filter Completed Tasks" and "Filter Archive Category" today) - this helps to focus the information overload when working on multiple projects in multiple workspaces and using a globally shared .mylar data folder * Closed queries do not participate in the search when something is typed into the find box in task list What do others think?
I don't get what you mean by closed and how it is actually different from open queries. At some point I've been suggesting to have per-query setting how often it should be synchronized. This way you can make certain queries act as offline unless synchronized manually. Though that does not address synchronizing individual tasks, including those in Archive category. However that most likely can be adhressed if we'll have aggregated categories. Sort of mix of query folder that also allow to stick individual tasks in it. This would also resolve issue with closing tasks jumping out of query folder.
I was thinking along the same lines as the Eclipse notion of opening and closing projects, which affects what the built-in "search", "open resource", "open type", etc function on. When a query is closed it still exists, but is effectively remove from all operations that would normally interact with a query. I think fine-grained synchronization properties are a neat idea too, and this feature is a nice complement to that, and vice versa.
(In reply to comment #1) > I don't get what you mean by closed and how it is actually different from open > queries. I think he means something like when you explicitly close a eclipse project and it goes "inactive".
As Eugene points out we actually synchronize all tasks that have changed since the last sync, and have tried hard to stay away from a model where the user needs to manually control what gets synchronized. This enables the flexibility of doing things like dragging a task into a category, and ensuring that the task will get an Incoming indicator if the repository info changes. What I have considered to address the don't synch use case is allowing a repository to be put into an "offline/disconnected" mode via the Task Repositories view. It seems that this might actually address your use case?
Putting an entire repository into an offline mode might be a little bit too much. For instance, I might want to keep my connection open to the repo, but instead of trying to synchronize on the dozens (or the few hundred) open issues that my various queries pull down, I might want to close all but one or two queries that relate to, say, bugs that need to be fixed for an upcoming release. Aside from any performance gains (those due to the less required synchronization), the other half of my issue focused on aspects of usability. Having the option to filter out closed/inactive queries cleans up the task list quite a bit, especially when people start to have dozens of queries (I'm pushing 20 right now). Also, the find box becomes more relevant too, allowing users to search on only the subset of queries they've decided to keep open. Mmm...but I guess as I start to think this through more and more, what I'm looking could be thought of as very similar to working sets - but I still there is one considerable difference. I see working sets more like active view filters. They don't change the semantics of how most things work, they just hide certain things from the view. What I'm asking for would actually change how the find functionality works in the task list.
Joseph, even if we'll add support for closed queries, all their tasks will automatically appear in Archive category, so it won't buy you that much, except that some queries won't be synchronized. Note that there is a "Go into" action that would make quick search to work only on one category/query.
I was looking to make search and synchronization work against an arbitrary subset of queries/categories. OK, I'm willing to ditch the idea of opening/closing altogether if, when working sets are implemented, their effects are thoroughly pervasive. What I mean to imply is that when you select a working set, the find and synchronization functions operation against the elements in that working set alone. If the notion of working sets can be coaxed into doing this, then what I was looking to achieve with the opened/closed query suggestion would essentially be satisfied.
This will be closely related to bug 153573, but let's use this bug for exploring how to incorporate finer-grained settings into that model, and if not consider doing it per repository (bug 165089 is related).
The only part of this that we will be able to do for 2.0 is at the repository level (bug 165809). Any additional enhancements will have to wait on further progress with bug 153573.
I do not know if this bug can be closed or not, but I did notice in the New and Noteworthy for Mylyn 3.2 that you can now turn off automatic synchronization for a query.
Thanks for pointing that out Mark. Yes, after considerable design discussion we settled on only supporting disabling or enabling synchronization on a per-query basis. Allowing finer-grained control, such as custom schedules, would result in a very complicated UI. The discussion and rationale are on bug 211441. As such, I'm resolving this as WONTFIX.
