Community
Participate
Working Groups
In order to reuse/modify task editor summary part, it would be nice to have access to the addAttribute calls. I think that there are also opportunities to simplify the implementation a bit.
https://git.eclipse.org/r/9769
The task editor summary part is internal and not intended to be extended. Can you elaborate on your use case please?
Yes. I'd like to easily implement a Summary Page that has support for additional fields. That seems impossible with the current design. Same rationale as with bug 385235. The only alternative right now is to reimplement or copy a lot of this code into a new class. It would be nice to have a simple capability for quickly building these in a semi-declarative way. Actually, after looking at the very similar changes that Sam proposes there, perhaps what is needed is adding these features to AbstractTaskEditorPart or a new GenericTaskEditorPart and have these parts extend it.
What kind of fields? The reason I'm asking is because it's an important UI paradigm that we keep the design of task editors as consistent as possible. Just curious if we are missing anything in the default design.
Well, in this case I'm thinking of Due Date (for R4E), but could also be other such key things as say Review Kind (Basic, Informal, Formal), etc.. I'm not saying that these all actually *belong* here, but that it should be a little easier to customize. I actually like the idea of pushing some of this down better, because it seems more important for other sections. Only tangentially related, I've found that a major UX issues that I have with the current editors is precisely that key information is buried within a common attributes section. I'd like to be able to see things like Product, Component, and priority displayed where I can easily see them. But I do see the value in uniformity as well.
One of the key values of task editors is that they provide a consistent look and feel across connectors. We have been very careful with customizations of this kind. If there is potential to improve information density or a lack of information visible we should discuss that and consider improving this on a framework level so all connectors can benefit. Particularly with due dates we have to be careful since there is a split between private and shared due dates which are displayed in separate areas of the editor. In any case I would prefer to do this through API on a model level and not by extending internal UI classes. I'm a bit surprised that you mention product and component since these are already always visible in the section header of the task editor for the exact reason you outlined. Miles, we usually keep tasks assigned to the inbox until there is consensus to pursue a change or feature request.
(In reply to comment #6) > Particularly with due dates we > have to be careful since there is a split between private and shared due dates > which are displayed in separate areas of the editor. Seperate issue, since this is for usage, but it seems natural to have creaed, modified and due dates appear in one place. Since this information isn't shared in Bugzilla and some other common connectors it seemed reasonable to add it. > In any case I would prefer to do this through API on a model level and not by > extending internal UI classes. I'm a bit surprised that you mention product and > component since these are already always visible in the section header of the > task editor for the exact reason you outlined. I've never noticed that until you just mentioned, which means that either I'm completely oblivious or that it's not an effective place for it. I would just never think of looking on a section header for editor specific information. > Miles, we usually keep tasks assigned to the inbox until there is consensus to > pursue a change or feature request. Okay, I assigned it to myself so since I've offered a candidate proposal. In general, since this is marked as internal anyway, I can't see much harm in making the code cleaner and more extensible. It's an interesting question whether UI policy should trump generic class design. Again, in general I'm really more interested in having all of these sections be more flexible for consumers who may want to implement them as there seem to be shared concerns across a number of them. But have a look and see if the improvements seem worthwhile.
(In reply to comment #7) > (In reply to comment #6) > Seperate issue, since this is for usage, but it seems natural to have creaed, > modified and due dates appear in one place. Seems okay as long as it's a shared due date. It could really make sense to generalize that and show it for all connectors. > Since this information isn't shared > in Bugzilla and some other common connectors it seemed reasonable to add it. In Bugzilla it depends on the configuration of the repository whether it's shared or not. > In general, since this is marked as internal anyway, I can't see much harm in > making the code cleaner and more extensible. The potential harm is if clients extend it and customize the header and it makes it more expensive to change the internal class later since it breaks clients. > It's an interesting question > whether UI policy should trump generic class design. I'm convinced we should always make an effort to find consistent and generic solutions rather than implementing custom UI for each connector. It also enables improvements in the framework to benefit connectors across the board. > Again, in general I'm > really more interested in having all of these sections be more flexible for > consumers who may want to implement them as there seem to be shared concerns > across a number of them. I disagree when it comes to making the concrete UI implementations extensible. There are certainly editors such as review editors that need to display information that's not covered by the current framework and that type of extensibility is already supported through API. Other bits of the presentation can be controlled through the meta-data in attributes which is something that we can extend. I realize that this is limited in terms of functionality and I'd be happy to consider a proposal for a more extensive presentation model but I wouldn't want to encourage more custom UI code. > But have a look and see if the improvements seem worthwhile. Seems reasonable. Please be aware that there is no guarantee for backwards compatibility of internals when the minor release version changes. We only make a best effort to maintain compatibility when only the service revision changes.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > Seperate issue, since this is for usage, but it seems natural to have creaed, > > modified and due dates appear in one place. > > Seems okay as long as it's a shared due date. It could really make sense to > generalize that and show it for all connectors. Yeah, it is shared, but some other issues became apparent and I'm actually not sure now how we're going to handle it. :) > > Since this information isn't shared > > in Bugzilla and some other common connectors it seemed reasonable to add it. > > In Bugzilla it depends on the configuration of the repository whether it's > shared or not. Thanks, clears up some confusion I had about that. > > It's an interesting question > > whether UI policy should trump generic class design. > > I'm convinced we should always make an effort to find consistent and generic > solutions rather than implementing custom UI for each connector. It also enables > improvements in the framework to benefit connectors across the board. +1, that's exactly what I was getting at. > I disagree when it comes to making the concrete UI implementations extensible. > There are certainly editors such as review editors that need to display > information that's not covered by the current framework and that type of > extensibility is already supported through API. Other bits of the presentation > can be controlled through the meta-data in attributes which is something that we > can extend. I realize that this is limited in terms of functionality and I'd be > happy to consider a proposal for a more extensive presentation model but I > wouldn't want to encourage more custom UI code. Yes, I would really love to see more and more of this driven to meta-data. For example, perhaps an attribute could indicate what it's preferred section is. There is so much custom SWT code in Mylyn that is really very declarative -- and there is no reason that we shouldn't be able to assemble most of this without any coding. But paradoxically, I do find that going through the excercise of generifying the code makes it much more obvious where those opportunities to make these things configurable are. Also, if you can make the API generic and extensible enough then I think it can actually encourage users to use the meta-data approach as they can extend it when they have to for those edge cases. One approach I'd really like to see is to build out the attribute editor factories approach so that editor assembly strategies could be made really pluggable. To some extent there is already stuff like this in EEF and other Model tools and it might be worth looking into whether we could put together a similar approach that wouldn't have any model dependencies. That would be similar to the way GEF works where the API supports more modeled/meta-data driven approaches but you still have a relatively spare clean API. > > But have a look and see if the improvements seem worthwhile. > > Seems reasonable. Please be aware that there is no guarantee for backwards > compatibility of internals when the minor release version changes. We only make > a best effort to maintain compatibility when only the service revision changes. Right.
(In reply to comment #9) > Yes, I would really love to see more and more of this driven to meta-data. For > example, perhaps an attribute could indicate what it's preferred section is. That's already supported through setting the kind attribute. I merged the change. Thanks!
(In reply to comment #10) > (In reply to comment #9) > > Yes, I would really love to see more and more of this driven to meta-data. For > > example, perhaps an attribute could indicate what it's preferred section is. > > That's already supported through setting the kind attribute. Ah, that's what that was for! :) thanks
