Bugzilla – Full Text Bug Listing
| Summary: | [LML] Nodedisplay with Images | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Claudia Knobloch <cla.knobloch> | ||||||||
| Component: | RM | Assignee: | Greg Watson <g.watson> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | c.karbach | ||||||||
| Version: | 5.0.4 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
I think only two need be supported, selected via the XML configuration file: 1. Image located in the plugin for the RM. This would be a URI pointing to the image location in the plugin. 2. Image located on a web server. This would be a URL. The image could be cached locally to avoid repeated lookups. (In reply to comment #1) > I think only two need be supported, selected via the XML configuration file: > > 1. Image located in the plugin for the RM. This would be a URI pointing to the > image location in the plugin. > 2. Image located on a web server. This would be a URL. The image could be > cached locally to avoid repeated lookups. Both ways will be supported in this nodedisplay extension. For an image within the plug-in bundle the URI would look like this: bundleentry:/images/example.png The nodedisplay will currently search this file within its own plugin "org.eclipse.ptp.rm.lml.ui". Is this solution acceptable? Is there another plugin, from which the pictures should be fetched? To include an image from a web server the URI would be e.g.: http://server/img1.png The images are cached during one eclipse run. Created attachment 210038 [details]
Nodedisplay implementation with images
In addition to showing images within a nodedisplay, there are further improvements of the nodedisplay's implementation. The painting of the nodedisplay is more strictly separated from modifications of the displayed LML-model. The nodedisplay shows for each physical element a colored rectangle. However the LML-tree does not contain an XML-tag for each physical element, but tries to compress the system's status by generating a partly collapsed tree. In this new version of the nodedisplay implementation the functions for expanding this partly collapsed tree from the LML-file are separated from the UI-classes displaying the expanded tree. Moreover, the new nodedisplay is able of painting the whole system with PaintListeners, while the older version only painted the last level of the nodedisplay directly. This optimizes the display of very large systems, because less composites are created and nested. Instead of creating heavy-weight composites the PaintListeners paint nested rectangles directly. This leads to faster painting, but less comfortable and flexible implementation, because all functionality provided by the composites has to be implemented by using explicit drawing functions. Both display solutions (nesting composites and painting rectangles directly) can be combined. The nodedisplay allows to nest composites for the first levels of the nodedisplay's hierarchy and paint lower levels with PaintListeners. Another implemented feature is the improved support for creating views with different levels of detail. It is possible to cut the LML-tree on an arbitrary level (e.g. cpu, node, rack). Cutting the tree on a level means, that in the old implementation for each physical element on the last level one colored rectangle was painted. The color indicates, which job is running on this element. By cutting the tree on a higher level, it is possible that more than one job is running on one physical element (e.g. on a rack). In order to give an appropriate overview for these cases, a usagebar can be shown for these physical elements. This bar collects the amount of CPU used by all jobs running on the specific physical element and depicts these amounts in a diagram. The diagram consists of colored rectangles again. Their size is proportional to the amount of used CPU of one job among all available CPU in this physical element. To sum up, this new implementation contains four major improvements: - images can be included into the nodedisplay - separation of LML-tree expansion and its displaying - optimization of painting nodedisplays with PaintListeners - support for showing views with different level of detail Carsten, please confirm the following: (a) You wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others. (b) You have the right to contribute the code to Eclipse. (c) You have included the EPL license header in all source files. Thanks! I confirm the following: (a) I wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others. (b) I have the right to contribute the code to Eclipse. (c) I have included the EPL license header in all source files. This contribution has now been approved, however I tried applying this to master, but I'm seeing errors in some files (e.g. RectPaintListener.java). Can you please update to the latest version of master and generate another patch? Thanks! Created attachment 211318 [details]
Updated version of Nodedisplay implementation with images
I tested applying this patch to master and it ran successfully. The patch should remove the class RectPaintListener from the "providers"-package. A new class RectanglePaintListener should be created in the "providers.support"-package.
I was still unable to apply this patch from Eclipse. Are you using Eclipse or the command line to generate the patch? I ended up patching via command line. This has been committed to master. (In reply to comment #9) > I was still unable to apply this patch from Eclipse. Are you using Eclipse or > the command line to generate the patch? > > I ended up patching via command line. This has been committed to master. I created the patch via command line. I had problems to create a patch with Eclipse, because changes were made in two projects. The patch created by Eclipse contained changes not only in the two projects, but also in my whole workspace. That is why I decided to use the command line. |
Created attachment 208385 [details] Example for a nodedisplay with images The implementation of the nodedisplay was extended, so that it is now possible to load images in the background of the nodedisplay view. In the attached picture you see an example from the current Perl/Tk-version. Before we push the changes into the Eclipse git repository we would like to discuss where those images (png-files) should be saved. Should they be part of the Eclipse PTP build? Or should they be stored on a external web server? When yes, which one, e.g. the Eclipse PTP wiki? Or should it be possible to store the images in the preferences or workspace of the user, so that the images only have to be downloaded once ?