Bugzilla – Full Text Bug Listing
| Summary: | "Full_template" attribute list in launch configuration does not scroll | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> | ||||||||||||
| Component: | RM.PBS | Assignee: | Project Inbox <ptp-inbox> | ||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | P3 | CC: | arossi, dieter.krachtus, drwootton, roland | ||||||||||||
| Version: | 4.0.2 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | Macintosh | ||||||||||||||
| OS: | Mac OS X | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Greg Watson
Greg, I mentioned this problem a long time ago and asked for suggestions as to how to solve it. Nobody seemed to have any ideas at that point. You can get the scrolling function if you click on another tab and then return to Resources. This bug is truly exasperating and I just gave up on it. I'm sure there must be someone out there who knows how to fix it ... I've encountered this scrolling issue elsewhere. The only way I can think of to fix this is to abandon trying to build the launch tab from its widget parts and just throw everything into a table. I don't like that solution for a number of reasons, but if there is no other solution to this ... Suggestions? Al Can you try and attach listeners (Focuslistener etc.) to monitor basic widget functionality and monitor scrolling function? Are the listeners triggered by your unsuccessful attempt to scroll? I have discovered part of the problem, I think, though I'm not sure what to do about it.
The code for udpateLaunchAttributeControls in the ResourcesTab class has this:
rmDynamicTab.createControl(launchAttrsScrollComp, rm, queue);
final Control dynControl = rmDynamicTab.getControl();
launchAttrsScrollComp.setContent(dynControl);
Point size = dynControl.computeSize(SWT.DEFAULT, SWT.DEFAULT);
launchAttrsScrollComp.setMinSize(size);
Now, putting a print statement after this, I see the following behavior:
1. Initial load of the tab:
SIZE IS Point {345, 121}
2. Click the Applications tab, then back to Resource. Note: no resizing is done.
SIZE IS Point {852, 957}
3. Repeat step 2.
SIZE IS Point {852, 957}
etc.
The scroll bar only appears after step 2.
I believe I have found the fix. There are two ways to set the scrolling. ResourcesTab currently uses the setMinSize method, but with my dynamically built composite this fails until it gets updated. If, however, I switch the method to have the ResourcesTab set the size on the control itself (from the computed size of the control), PBS is happy. The only other thing the PBS tab needs to do is turn off the ScrolledComposite expansion (left on because the other RMs seem to need it). I've checked the look of the current RM tabs and they seem to be unchanged with this modification. It looks like this has changed the behavior of the Open MPI launch configuration. If I create a launch configuration using Open MPI, the launch attributes panel no longer expands to fill the whole space when the size of the launch configuration is changed. This needs to be fixed. Created attachment 178548 [details]
Screen shot of OpenMPI on initial load of tab
The attachment is what I see running from HEAD. Is this not correct?
Created attachment 178549 [details]
Screen shot of OpenMPI after resizing down
Created attachment 178550 [details]
Screen shot of OpenMPI after resizing up
two more screen shots. The panels expand and contract for me.
Greg, what is the platform of your laptop? Is this a Windows thing? Al Created attachment 178551 [details]
pe resource manager screen capture
Argh. Explanation of my attachment above: It looks like scrolling in the PE resource manager resource tab of the run configuration is not working correctly. If I shrink the run configuration window small enough, i expect horizontal and vertical scroll bars to appear. In the attached image, there are more widgets in the tab that what appears and I should be able to scroll in both directions. This is on Windows XP OK, the only way then to preserve earlier behavior without constraining the RM implementations to do something they aren't currently doing is, to my thinking, going to necessitate an API addition to the the ResourcesTab knows what the LaunchConfigTab wants done with the parent, I think. I tried a few schemes where PBS just tries to override what is going on in the ResourcesTab but they didn't seem to work. I can try that one last time, but I'm not hopeful. Created attachment 178559 [details]
openmpi launch config
Here's what I see. This is on a Mac.
Why do the other RM's work differently to the PBS RM? This time I think I've nailed it. Silly I didn't see it before. I've restored the old way of doing things to the ResourcesTab; I just found the correct place in the code for the PBS Launch Tab to override this (earlier attempts placed the override in a method which is called once, but which relies for the UI construction on an auxiliary which may be called multiple times; moving the fix into the subroutine seems to do the trick without mucking with the ptp.launch layer). Dave, Greg, could you check to make sure the correct behavior has been restored? I won't close the bug or update 4_0 until you give me the go ahead. I've committed changes to HEAD only. Yes, fixed for Open MPI. I think it's also fixed for PE, Dave to confirm. Please commit to 4.0. Thanks! Answering comment 16. The PBS launch tab allows for the UI to be rebuilt when the template is changed. The sequence on initial load ends up calling a skeletal build of the control and then again with the full template; the point of entry for the second time is not from the ResourcesTab method where the ScrolledComposite is sized; if I don't preserve that setting or reset it in the second instance, it gets clobbered. The other RMs don't have anything like this going on. Committed to 4_0 as well. Will close when Dave confirms. Scrolling in the PE RM run configuration resource tab works correctly now. Thanks, Dave. |