Community
Participate
Working Groups
Created attachment 171032 [details] Patch to enable view dragging/movement. We need to have moveable/draggable views...very important eclipse feature. So I decided to try a quick and dirty attempt to get it working. Obviously from the newsgroup discussions, the Tracker widget is the blocker: http://www.eclipse.org/forums/index.php?t=rview&goto=515434&th=162885#msg_515434 And we have some ideas how this can be implemented properly. But while we are getting our hands dirty, here is a patch for the 1.3M7 target platform that will enable views to be dragged, obviously with no feedback. But most eclipse users in general will know what happens when you drag a view to the top, left, right, or bottom of another view. Again, this is a quick and dirty hack to get it working so we can work on a client-side tracker implementation.
I would like to open the discussion on tracker implementation with brainstorming some approaches: 1. Since we don't have mouse move yet, send the perspective layout (dragging hotspots) to the client side and have a div with a border represent the feedback. When the mouse moves into the hotspots, a request is sent back to the server, which would update the server side implementation of the Tracker. 2. Send the perspective layout (Set of rectangles), and instead of using a client or server-side tracker, have the mouse cursor change to an appropriate directional arrow when encountering the borders of the workbench parts. This would imply that any feedback for cases beyond just sitting beside a view on whatever side would need to be considered on the client-side.
It is amazing what an hour of hacking..."cough"...prototyping can do... ;-) http://www.youtube.com/watch?v=zkW27ZqAL3k
(In reply to comment #2) > It is amazing what an hour of hacking..."cough"...prototyping can do... ;-) > > http://www.youtube.com/watch?v=zkW27ZqAL3k I should have given this video a bit more commentary here in the ticket. Again, what has been done thus far is a proof of concept, and I have made no attempt at making this worthy of checkin. But people may find this work useful anyway, and it may be food for thought to the team by investigating various ways of implementing a tracker. In regards to feedback, I have implemented a tracker-like functionality by opening a semi-transparent shell. In RCP, the tracker is a widget that is visible itself and whose dimensions are changed according to mouse location. However, in RAP since the tracker does not have a client side implementation yet, I decided to just use a semi-transparent shell to mimic the tracker's behavior. So when the tracker is opened, the shell is shown and is updated when the tracker rectangles are asked to be rendered. Also a drop target is created for the shell, which allows the mouse cursor to be changed from "no drop" to "move" when over the shell. The shell is closed when the tracker is closed. The real hack here is that since there are no mouse moves in RAP yet, I had to "trick" the tracker listener in DragUtils to think that a move is occuring. This is done by running a separate thread that artificially pushes a move event at an interval. Since the cursor coordinates come from the client during a drag, the listener just pulled the current cursor location from the display, and performed it's normal job. The original patch attachment doesn't include the feedback functionality. I will update the patch soon.
Created attachment 172543 [details] Patch to enable view dragging/movement including feedback Here is a patch updated to today's CVS HEAD / 1.3 official release that includes feedback.
Created attachment 173318 [details] Patch to enable view dragging/movement including feedback and bug fixes This new patch adds a conditional to ControlLCAUtil:checkAndProcessMouseEvent() to include the view tab as an area to receive mouse down events from. Previously the mouse down events were not being processed from the tab because it was only checking the client area of the view. The previous patch would only allow views to be dragged if they were just activated. Because I can now receive mouse down events for the view tab, this patch allows all views to be dragged regardless of their presence in a stack. Not sure if it is worth filing a separate bug on this.
I hope this can be addressed soon - I am surprised that RAP workbench use hasn't made this a huge requirement...
Having this in RAP would be useful for my current project.
This will be great for my project as well, especially in a dashboard perspective that users can move the views around freely.
Is there any plan to address this feature soon ? I think it should be P2 enhancement.
(In reply to comment #9) > Is there any plan to address this feature soon ? I think it should be P2 > enhancement. Sorry, it does not look like it. A solid implementation with tests, client feedback and code reviews would be very time consuming, and there are a lot of issues with higher priority right now. I also think that, compared to the effort required to implement it, this is a feature of limited usefulness for the type of applications usually built with RAP - but that's just my own personal opinion. We recognize that this enhancement has a lot of votes, and we value the input of the RAP community. However, unless someone is willing to invest a significant amount of resources, this is not likely to happen very soon.
(In reply to comment #10) > We recognize that this enhancement has a lot of votes, and we value the > input of the RAP community. However, unless someone is willing to invest a > significant amount of resources, this is not likely to happen very soon. It may be hard to find a single entity willing and capable to stem the amount to have you build this enhancement. However there seems a large interest, so why don't you start a Kickstarter project for it? This way people can pledge even small amounts and they won't be charged until the project get's funded with enough funds for you to implement it.
(In reply to comment #10) > (In reply to comment #9) > > Is there any plan to address this feature soon ? I think it should be P2 > > enhancement. > > Sorry, it does not look like it. > A solid implementation with tests, client feedback and code reviews would be > very time consuming, and there are a lot of issues with higher priority > right now. I also think that, compared to the effort required to implement > it, this is a feature of limited usefulness for the type of applications > usually built with RAP - but that's just my own personal opinion. In my opinion it is a very important feature for RAP. One of the main purposes and usage cases of RAP is to port existing rich client to web and possibly to maintain the two with very similar user experience. Inability to rearrange views is very big drawback in user experience when switching between rich and web UIs. Can it be done as a separate plugin or fragment? Those who wants carefully tested code will not include it in the builds, and those to whom this functionality is critical will use it.
A kickstarter project is a good idea. If someone feels like doing that, please go ahead. RAP is mirrored on github, so it's easy to create a fork, rework and apply Austin's patch or create your own solution. The fork would also include the releng part, so you can easily build your own version of the workbench bundle. We encourage the community to work on additions like this one, but we cannot do it ourselves. The core team has to focus on the important issues and improvements in the RAP core.
(In reply to comment #13) > A kickstarter project is a good idea. If someone feels like doing that, > please go ahead. > > RAP is mirrored on github, so it's easy to create a fork, rework and apply > Austin's patch or create your own solution. The fork would also include the > releng part, so you can easily build your own version of the workbench > bundle. > > We encourage the community to work on additions like this one, but we cannot > do it ourselves. The core team has to focus on the important issues and > improvements in the RAP core. I humbly disagree. I think Victor is right saying in Comment 12 that users of RAP expect a very similar user experience between RCP and RAP applications, especially single sourced ones. I also disagree that every user who needs that feature should run their own workbench bundle. This feature should be owned an maintained by RAP proper. It seems to me that the community has expressed more than an interest by already providing patches. As I know even patches don't integrate themselves into the mainline, that's why I suggested that the RAP team should set up a Kickstarter project. And again, it does not make sense for anyone else than a the RAP team or at least a RAP committer to set up that project, as the project owner needs to do the deed to build and integrate it into REAP proper once the project is successfully funded.
I agree with what has been said about this feature being an essential part of a RAP application. The patch in itself is big and complex enough to discourage even motivated users to try an apply it to the current source...
I discussed this with Ralf at EclipseCon. I agree that many users expect this functionality in RAP when using the workbench. What we discussed for 2.1 is to try to get all necessary changes in RAP to be able to support draggable views as an add-on module. This add-on could be developed in the RAP Incubator or on GitHub, outside of the normal RAP release cycle.
(In reply to comment #16) > I discussed this with Ralf at EclipseCon. I agree that many users expect > this functionality in RAP when using the workbench. What we discussed for > 2.1 is to try to get all necessary changes in RAP to be able to support > draggable views as an add-on module. This add-on could be developed in the > RAP Incubator or on GitHub, outside of the normal RAP release cycle. I agree with this approach. I think that we can also use this as a pattern for future workbench bolt-ons. The difficult part is actually determining the list of changes that are necessary to be in RAP and how they should properly be implemented. And then of course we are doing this for an obsolete branch of the workbench.
any news about this feature?
With the recently announced E4 support[1][2] RAP incubator this may be easier to implement. Drag and drop is an addon in E4, so modifying it to be RAP compatible only requires changing that addon and should not require modifying other code in RAP. It's possible that it already works, but unlikely due to missing support for the Tracker widget. Additionally, the E4 application model contains dimensions and locations of each view, therefore it would be possible to send this information to the client and do the drag & drop feedback completely in JavaScript. This would eliminate round trips and make the performance very smooth. [1]http://eclipsesource.com/blogs/2014/04/10/introducing-eclipse-4-on-rap/ [2]http://eclipsesource.com/blogs/2014/04/10/getting-started-with-eclipse4-applications-on-rap/
(In reply to Cole Markham from comment #19) > With the recently announced E4 support[1][2] RAP incubator this may be > easier to implement. Of course, that would only apply to E4 apps, not 3.x workbench apps.
