Community
Participate
Working Groups
We are creating a very customized UI for an RCP app. We have views that we need to allow to be moved around, but they cannot be placed in some specific areas. For example, a view should not be allowed to be docked on top of the editor area. We would like an API or some way to get into the view/editor DnD process.
You can't mix up views and editors now, but there is probably some other situations as well. PW
Sorry I didn't mean you could drop a view into the editor area, but rather drop it above the editor area.
Chris, I take it that you want Users to be able to drag the views, just not 'above' the EditorArea correct? Why is it -necessary- to prevent a User from doing this if that's what they want? I can see why you may consider it undesirable but I'm still unclear as to how allowing the operation would be catastrophic. I'm trying to get a handle on what a generalized form of the enhancement might be since we prefer a general solution/feature rather than a specific one. For example, if you have a stack already 'above' the editor area that you won't want 'messed up' then the approach is different as I might start looking at a mechanism to disable dropping views into a specific stack...
Yes we want to allow the user to be able to drag views around, but just limit them in certain ways. This is primarily a visual design concern. Our user experience guys have spent alot of time creating a specific design that only allows users to dock views on the left or the right of the editor area. We have a lot of specialized trim that we also want placed directly against the editor area for usability reasons. I can send you a screenshot internally if you'd like a look. Essentially we want to avoid a new stack from even being created in certain places.
Got it. Do you have control over the views or do you allow view contributions? I'm thinking that it might be possible to wire off he 'drop' handling for certain areas but that enforcing this across contributed views may be more problematic...
Yes we do have control over the views. We allow for contributions but not directly to the view extension point. We have our own extension point that internally creates a view. So all our views should be one class.
Chris, would an option that disabled the ability to create a new stack through dragging be sufficient. In this mode users would be able to drag views around but only between (or within) existing stacks. If not can you provide another suggestion? The generic API isn't likely to happen (in 3.3 anyway) because coming up with a generic way to describe the desired behaviour will require a propert design pass (which elements are 'constrainable'?; what's the proper way to define the 'constraint'?).
I don't think that would be enough. I've gone back to my UE guys to see if we can eliminate the need for this completely. This would require some redesign of the current interface and would likely have to be signed off by multiple people. I will ping back when I know more.
Thanks...we're looking into various options but the more complex the requirements the longer it takes to formalize them into API... Let me know what you come up with. If it turns out that you still need platform support try to scope out what you need here and we'll take another look.
Are we doing this for 3.3 ?
Philippe, the short answer is no. It's well past API freeze and this is definitely non-trivial to get correct (which API -must- be). I suspect that we don't want to start down this path now...
In a component world this becomes even more important (since the presentation won't have code constraints limiting where things go we -will- need a mechanism to control DnD targets...
Removing outdated target milestone.
There are some good ideas here...maybe we can find a pattern to use for 'veto'...
