Community
Participate
Working Groups
About a week back I finished implementing a system type for a sandbox environment, comprising of file subsystem, shell subsystem and process subsystem. This provides a good enough interface to the environment. But I feel, just as for the Linux and Windows system types, this system type needs a Display Subsystem. The Display Subsystem would allow the user to open up a display of some sort to view desktop/other display types in the target environment. The different display types could probably be contributed through an extension point. The combination of file, process, shell and display subsystems would enable the user to almost fully operate on the target environment from RSE.
I don't understand what you mean, can you elaborate? Are you talking about a "remote desktop" kind of subsystem like VNC? That's being built by the Tools for Mobile Linux (TmL) project already: http://wiki.eclipse.org/DSDP/TML/How_to_configure_TmL_demo
(In reply to comment #1) I am aware of the TML VNC. I was thinking of integrating the VNC viewer into a subsystem and making the integration generic enough to allow addition of new display types (probably through an extension point). For Example, let us say I have an implementation of X server in java .The first thing I’d want to do is to integrate it with eclipse. Once I am done with that, I would open up a VNC view and probably open a few X Displays to suit my development activities. I may be working with two or three (RSE) hosts at the same time, transferring files, running commands and so on. I can imagine a common point for starting/stopping/managing all available displays for a given host –a subsystem for that host. After a while, I may want to use a different VNC viewer. Similarly, an XYZ system type may have xyz display type and may open multiple instances. The display subsystem could serve the above need as well by providing an extension point to add new display types. A new system type can easily reuse such functionality and if need be provide a new display type (for example the system type I referred to in my previous comment). I have been working on a prototype; not quite finished though. I could share a screen capture if required.
(In reply to comment #2) > I am aware of the TML VNC. I was thinking of integrating the VNC viewer into a > subsystem and making the integration generic enough to allow addition of new > display types (probably through an extension point). We don't use extension points for that. Even for Files, Processes and shells the way it works is this: There is one generic e.g. FileServiceSubSystem, which provides the UI. The underlying protocol can be replaced by replacing the Service (IFileService : implemented by SftpFileService / FTPService / DStoreFileService for instance). Registering the various services against system type is done by creating new SubSystemConfiguration instances, all of which instantiate the common FileServiceSubSystem but configure it differently. So, in your case, we'd not have an extension point to plug different viewers into your generic Display Subsystem, but you'd likely provide a DisplayServiceSubSystem, which is instanitated by DisplayServiceSubSystemConfiguration. Variaous variants of that configuration can be created and registered against system types, and they all instantiate and configure the DisplayServiceSubSystem slightly differently. > I can imagine a common point for starting/stopping/managing all available > displays for a given host –a subsystem for that host. This seems to be exactly what the TmL project is doing with their service framework. You can declare multiple services on a device (display, GPS, ...) and start/stop them all at once. > After a while, I may want to use a different VNC viewer. From this point on I don't understand what you are saying. Hopefully my explanations above have shed some light on it for you.
Created attachment 104327 [details] screen capture screen capture demonstrating the use of a display subsystem.
(In reply to comment #3) That is always possible. In my case, I have configuration1 which provides an instance of the DisplayServiceSubSystem, and instantiates an implementation of IDisplayService that operates through an extension point. I was not trying to discus implementation but to put the requirement into light. I don't see the point in extending/configuring/using TML (which I suppose use Instance view) and RSE for the same host, one treating it as a system-type another as a device. The Linux host may use VNC viewer or X server; windows may use a VNC viewer, my system type uses a different one – but they are not TML devices. I have attached a screen capture to make my requirement clearer. You may need a DIVX codec for playback.
I must say this demo is impressive, thanks for sharing it! I like the idea of having Display Subsystem and I think it can turn into something very useful for remote development. I am not familiar with the TmL offerings but I in my opinion the idea of having remote display also fits in the TM scope. Martin, I have seen in one of the TM presentations a screenshot of something called Symbian Phone Browser showing the UI on the phone, isn't that some kind of remote display? As a WinCE developer I can say this will be a killer feature, it will enable to do everything with your device from Eclipse. Hitesh, would you share some more information about your IDisplayService? I think that creating such a generic service for all types of remote viewers will be a challenging task.
Ok, perhaps the right thing to do is move the VNC implementation from TmL into the TM project, since it seems generic enough to be used outside Linux context. I'm pinging the TmL people what they think about it. Regarding the IDisplayService, I'm not so sure how much generic "framework-like" functionality there would be that would warrant such a framework with yet another extension point. Note that both the data transfer protocol as well as the rendering of the remote display would need to be contributed. Why not provide an ISubSystem that does all that right away? Javier, from your experience with the "Symbian Phone Browser", can you give any thoughts or insight on this?
Hi guys, Let me try clarify how VncViewer work in TmL. Today the VNC viewer is totally independent of the rest of the projects. There are three packages there: org.eclipse.tml.protocol - Mechanism to implement generic protocols (RFB is implemented over this) org.eclipse.tml.vncviewer - VNC viewer library, it is a SWT component that implements the frame buffer display using RFB protocol. org.eclipse.tml.vncviews - Contain an eclipse view feeded by the SWT component from VNCViewer. Only these packages are necessary to use the VNC Viewer capability. Even the other TmL components are client of this packages if they are using VNC features. It is not necessary use tml devices, ui or services to use VNC viewer. To integrate it with TM is only necessary encapsulate our SWT Component or use VNC view calling the parameters for the connection. We are working to provide in a couple weeks in an integration between TM and TML. We will share with you some plug-ins making use of the VNC using the TM UI and vice-versa. Please feel free to send us comments and suggestions about this integration. Thanks and Regards Fabio
Scott, this is something ECF has been looking for awhile ;)
(In reply to comment #9) > Scott, this is something ECF has been looking for awhile ;) > Yes, see bug #239854. I would argue that VNC client functionality belongs in ECF and any contributions should go there, and not in TM. As the remarks in comment #8 indicate, the VNC functionality is not dependent upon hardly any of the TM plugins and functionality...and is functionally a separate unit. Also...the title of this bug doesn't seem to bear any obvious relationship to a VNC-based screen sharing functionality.
Created attachment 107491 [details] SWTRemoteDisplay class with scrolling The current viewer does not support scrolling. This is problematic, in that only the region of the shared screen that is within the view can be seen. I added scrolling to the SWTRemoteDisplay class (see specifically the initCanvas() and paint() methods). I was not able to create a patch for this, because a number of changes have been made to the SWTRemoteDisplay class since I started working with the source, and I'm not able to resolve the conflicting changes.
Hey guys! Pretty nice demo! With a little of cooperation we can make a really incredible product :) Sorry for my delay, I will take a look on your scrolling implementation. It seems that users of the SWTRemoteDisplay should implement their own scroll. The SWTRemoteDismplay extends a Composite, so you can add a scroll to it on your Eclipse View implementation. Our VNCView is just an example of usage, you can create your own view adding the SWTRemoteDisplay like a regular widget (and related scrolls, listeners, etc). Anyway, I'm going to analyze it. Meanwhile feel free to give your opinion (all of you :) ). Thanks, Daniel.
(In reply to comment #12) > Hey guys! > > Pretty nice demo! With a little of cooperation we can make a really incredible > product :) > > Sorry for my delay, I will take a look on your scrolling implementation. It > seems that users of the SWTRemoteDisplay should implement their own scroll. I don't agree with you about this. Two reasons: 1) Canvases typically implement their own scrolling (as Canvas class has support for scrolling already); 2) This a very common thing (scrolling of the canvas)...so common that that any SWTRemoteDisplay should have it (e.g. why would you ever *not* have support for scrolling of a client area larger than the client view? > > The SWTRemoteDismplay extends a Composite, so you can add a scroll to it on > your Eclipse View implementation. I don't believe this is correct, as per #2 above...I can't imagine when you would not want scrolling. So putting at a higher level (view) doesn't make sense to me. > > Our VNCView is just an example of usage, you can create your own view adding > the SWTRemoteDisplay like a regular widget (and related scrolls, listeners, > etc). Right...again I think it belongs at the lower level (SWTRemoteDisplay/canvas). > > Anyway, I'm going to analyze it. Meanwhile feel free to give your opinion (all > of you :) ). OK. As I stated previously, I believe this bug is unclearly titled...and that this vnc-based screen sharing capability is misplaced in target management/dsdp. As per bug #239854, it's a broader communications capability needed by our/ECF community for a number of app-level uses (remote devices, to be sure, but also remote desktops, etc).
I'm a little confused, since it looks like several different things are being discussed on this bug: 1. Hitesh, original submitter, seems to be talking about some administrative layer in RSE that provides a tabbed view which can hold arbitrary contributed canvases. That seems to be an RSE-specific proposed contribution which does not necessarily rely on any VNC Viewer code. Hitesh, are you actually planning to contribute any of the code that you used for creating your Demo? Is your code related to the TmL code in any way? 2. Scott is proposing a change (enhancement) to the TmL VNC Viewer. It looks like this should be a separate bug against TmL. 3. Daniel is presenting the TmL VNC Viewer, which consists of a plain viewer without any dependencies, plus some glue code for RSE. May I propose forking off separate bugs for the various separate requests? - If the TmL team is interested in adopting Scott's patch, could they file that separate bug? For the original bug (RSE glue and Hitesh's ideas), I'll leave it to Hitesh whether that should live in TmL or RSE. If you want to collaborate with TmL, I'd propose to file a new bug for working with them.
Daniel, the bug and the demo clearly describe the capability of managing arbitrary canvases from RSE, but not specific to VNC canvas or the TML VNC viewer. I have not worked on ECF, so no comments from me. Martin, I agree with you, different bug(s) be filed for any changes to vncviewer, and suggest that the original bug remain with RSE. My demo code is related to RSE, but is not related in any way to TML code, while the extension point and tabbed view depend on neither. If it helps, I値l be shortly sharing the code used for creating the demo.
Created attachment 109326 [details] The demo code The demo code without the vnc and xserver based implementations.
Created attachment 109329 [details] Example code
Hi all, I'm moving this bug back to TM. Scott, can you please file a new bug for TmL? So you can submit you patch to the right place and we can track the discussion concerning the scrolling issue. Tks, Daniel.
No time for new API in 3.1 - sorry
