Community
Participate
Working Groups
It's too hard to tell if a task is scheduled or not. Dynamicall updating the image of the button could address that.
+1
Steffen: I went ahead and did this. Try it out, and let me know if it should wait for 3.3 instead, but it seems like a minor polish item.
Created attachment 142459 [details] mylyn/context/zip
Created attachment 142460 [details] patch
Updated to support one-click unscheduling.
Created attachment 142493 [details] reverted patch
I think this is a good idea but I don't agree with the proposed approach. The action should register a listener and update it's own state as the tasks may get re-scheduled through other means than the menu associated with the button. Also the patch adds a new field to a provisional class which we treat as API so this should not go into a minor release.
+1 on the suggested listener approach. In case my knowledge here is stale, where do I register the listener? I'm not sure I agree that we can't add a new field to a class in an internal package in a service release, if that provides user value. We may need to have a better definition of what we consider acceptable for a service release, since I'm not yet comfortable following the exact convention of Platform and only doing bug fixes, without consider UI fixes. Also, are we treating some classes, like AttributePart, as "provisional" even though they are in "internal" packages? If so we need a convention for communicating that to contributors, even if it's only Javadoc that not all will notice.
(In reply to comment #8) > +1 on the suggested listener approach. In case my knowledge here is stale, > where do I register the listener? I couldn't find any good place to register a listener for that. Rob? > I'm not sure I agree that we can't add a new field to a class in an internal > package in a service release, if that provides user value. We may need to have > a better definition of what we consider acceptable for a service release, since > I'm not yet comfortable following the exact convention of Platform and only > doing bug fixes, without consider UI fixes. Let's discuss that on an upcoming weekly call. I think we have to be very careful about UI enhancements and need to establish a process that ensures proper testing to avoid regressions. My sense is that we get a lot less usage of the service streams prior to a release particularly if the weekly site already serves builds for the next major release. > Also, are we treating some classes, > like AttributePart, as "provisional" even though they are in "internal" > packages? If so we need a convention for communicating that to contributors, > even if it's only Javadoc that not all will notice. No, I was only referring to classes that are actually in provisional packages, specifically CommonImages. The main problem is that if an integrator uses a newly added field there is no indication when it was added, i.e. in this case a connector using the field would fail with 3.2.0 which is not obvious. It is somewhat of a grey zone since the provisional classes are internal but it makes the commons plug-ins more difficult to consume for integrators if we don't provisional packages do not provide additional guarantees. It's probably best if we bring that up on a call as well.
Now that HEAD is the Mylyn 3.3 stream I have re-committed the patch so that we get some usage on it. We can still add the listener approach, although I've never seen an Eclipse tool item change its icon based on edits done in an editor or view. I didn't put an @since tag on CommonImages.SCHEDULE since I'm assuming there's no need, but let me know if we should have a policy of adding those to ..internal.provisional classes.
Shawn has pointed out that we can use a task list listener to detect changes to the scheduling.
I have made the following changes: * The action listens to scheduling changes to ensure that the icon always accurately reflects the scheduling state. * The action is now disposed on editor close to avoid leaking the popup menu. * The action is disabled if a task is completed.
