RE: [mylar-dev] issues with task context management

["Mik Kersten" <beatmik@xxxxxxx>]

Thanks Eugene, this is a very useful list and I also find each of those a
sore spot.  For the past few months we have been focusing our efforts on the
Tasks Framework, to the point where we have starved the Focused UI.  I think
that each of these problems needs to be addressed somehow for 1.0, and will
mark the bugs with that as the target milestone.  After that we should take
a look at the full list of improvements in this area and triage accordingly
(e.g. whereas most are not much work in terms of coding, the last one might
need a work-around solution along the lines of what you propose since the
full solution, detecting interaction patterns, may be too involved for 1.0).
I will plan on following up on this email once we have made more progress on
marking bugs for 0.7 and 1.0, and make sure that's done before the time that
we schedule our conference call (in a couple of weeks).

Mik 

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
> Sent: Sunday, August 27, 2006 6:38 PM
> To: Mylar developer discussions
> Subject: [mylar-dev] issues with task context management
> 
> Hi,
> 
>   I think that the number of issues around task context management is
> accumulated above acceptable level and in many cases made usefulness of
> Mylar is way less then it could be. Some of those issues probably
> already logged in bugzilla, but as promised, I want to summarize my
> field experience and frustration.
> 
> -- fail to unfilter elements in package explorer when project has
> multiple source folders. This one is particularly painful, especially
> for Maven and WTP projects.
> 
> -- temporary unfiltering is screwed in a number of ways: clicked element
> does not gain interest and not stick (get filtered out again after
> releasing alt), can't select two elements from temporarily unfiltered
> folder, can't use popup menu on those elements... That is leaving
> keyboard-only navigation alone.
> 
> -- "lower interest" propagation to parents (especially in package
> explorer). E.g. when closing editor, its interest is lowered, but parent
> folder/package/project still have interest and clutter the view. So, if
> user just open several random classes using Ctrl-Shift-T or Ctrl-Click
> navigation and then close those opened editors, he'll end up with bunch
> of unfiltered projects/folders that will stay after editors been closed
> 
> -- Mylar fail to restore/save custom filters when enable/disable "Mylar"
> mode for package explorer and outline views. For instance I see closed
> projects when Closed projects filter is checked in the view settings.
> So, have to disable/enable filter to clean that.
> 
> -- The defaults for disabling filters should be adjusted. For example,
> filters for closed projects, empty packages, import and package
> declarations should not be disabled.
> 
> -- unfiltering of the same jar (e.g. in plugin dependencies) several
> times when there is an interesting class opened from one of those jars.
> Note that link with editor actually able to figure out content of what
> jar need to be expanded, but Mylar somehow loose uniqueness of the
> context for this interesting class.
> 
> -- picking up interest on externally changed resources (e.g. after vcs
> checkout or build). This been discussed many times and we don't have
> acceptable solution yet. If user not intentionally run background
> checkout when task is active, he may literally loose his context because
> of those incoming changes and the worst part that because context may
> grow very big, whole IDE became unusable.
>   I think that it would be much better to do not include changed
> resources (at least on checkout/refresh) unless they are within one of
> the projects that already have interest. Though, in my understanding,
> current problem is that Mylar does not know in context of what operation
> resource has gain its interest...
> 
>   ...I am sure I missed some more, but it is already gone bigger then I
> thought it will be. So, I am going to stop here for now.
> 
>   regards,
>   Eugene
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev