Home » Eclipse Projects » Eclipse Scout » Scout .war not working correctly
| Scout .war not working correctly [message #1179667] |
Sun, 10 November 2013 12:53  |
 Uli B
Messages: 36
Registered: January 2012 |
Member |
|
|
I have a small single form Scout 3.9 application, which works fine when executing the Server and the Swing client from the "Scout Object Properties" in eclipse.
However, when I export the scout project as .war files and deploy them in Tomcat 7, the view and behaviour in the browser (Firefox 25 or Chrome) look disastrous (the attached images show the difference after opening the client):
A lot of things are totally odd, like
1. The Group Box on the left "Selection" does not show the full content (too small).
2. The two SVG Fields are not shown in their programmed size (much smaller).
3. execHyperlink is used when clicking on the bar. This works with the swing client and the server in eclipse, but in the browser, the svg is removed, the text "null" is shown instead, and the intended action is not performed.
4. execRowAction is used when clicking on the table. This works with the swing client and the server in eclipse, but in the browser, no action is performed at all.
5. When expanding/collapsing sections, the behaviour is more or less unpredictable. The size of the section when expanded, changes with each expand action, ...
7. The light blue menu bar is shown in the browser, even though I removed it and it is not shown in the Swing client.
7. The Label Field text "Headline" does not use the configured font.
What am I doing wrong? Does anybody have an idea where I can look at to fix it?
Attachment: swinggood.jpg
(Size: 153.13KB, Downloaded 184 times)-
Attachment: rapbad.jpg
(Size: 117.03KB, Downloaded 184 times)
|
|
|
| Re: Scout .war not working correctly [message #1219107 is a reply to message #1179667] |
Mon, 02 December 2013 00:59  |
Lukas Huser
Messages: 42
Registered: March 2010 |
Member |
|
|
Hi Uli
Wow, that are a lot of questions 
First, I think the differences you notice are not related to exporting and deploying the application to Tomcat. These are rather differences between the Swing client and the RAP client. (You will notice the same differences when starting the RAP client from the Eclipse IDE.) While Scout tries hard to give the same user experience on the different platforms, it is quite possible that some behavior and/or layouting will differ. And some of the odd behavior might simply be bugs...
Are you ultimately deploying both the Swing and RAP client? If not, simply stick to the platform you will deploy in the end, or in other words: if you are going to deploy the RAP client, don't develop and test with the Swing client
If you are targeting both platforms simultaneously, it is most often possible to get good results with both of them, but sometimes it includes some additional effort...
1) It seems that the Swing client creates a horizontal scroll bar, while the RAP client does not, but instead squeezes the GUI components. Maybe you can force the RAP client to create a scroll bar too? Or try to reduce the size of the middle section such that all the content fits into a reasonable screen size?
2) Hm, I tried a quick example based on the SVG tutorial. I did not notice a big difference in the size of the rendered SVG between the RAP and the Swing client. Could you share a bit more on your implementation details?
3) This is a known bug, see Bugzilla Ticket 421822.
4) I cannot reproduce this behavior. Note that execRowAction is triggered by a double-click while execRowClick is triggered by a single click. Both methods worked in my tests as expected in the Swing client as well as the RAP client.
5) Could you describe the current - as well as the desired - behavior in more detail? I put a small example together with a few expandable sections. I noticed that when collapsing a section, the free space is not necessarily filled by following GUI elements. But I guess you have something different in mind?...
6) How did you remove this toolbar/views area for the Swing client? I don't think that Scout offers the possibility to completely remove this blue area on the model level. This might be a reasonable feature request, though. I could imagine that removing this blue area requires some tweaks to the UI-specific bundles...
For the RAP client I managed to remove the blue area by overriding createUiDesktop() in class StandaloneRwtEnvironment. But maybe there is a better way to achieve this?
public class StandaloneRwtEnvironment extends AbstractStandaloneRwtEnvironment {
public StandaloneRwtEnvironment() {
super(Activator.getDefault().getBundle(), ClientSession.class);
}
@Override
protected RwtScoutDesktop createUiDesktop() {
return new RwtScoutDesktop() {
@Override
protected Control createToolBar(Composite parent) {
return null;
}
};
}
}
7) What font name did you configure here? When doing some testing, I realized that it is quite awkward to define a reasonable font which works on all clients (Swing/SWT/RAP). AWT/Swing knows logical fonts (see [1]), such as "Serif", "SansSerif", "Monospaced" or "Dialog", which is great because it lets the jvm pick a reasonable font from the actually installed fonts on any given system. However, SWT (and therefore RAP) seems not to recognize these logical fonts (or it might have different names for it).
On my Ubuntu system SWT knows the names "serif", "sans" and "monospace", I'm not sure whether this is true for SWT in general, though.
Defining a physical font name, such as "Arial" or "Ubuntu" works with all clients (Swing/SWT/RAP), but requires that you know exactly what fonts are installed on your users machines...
[1] http://docs.oracle.com/javase/tutorial/2d/text/fonts.html
Hope this helps
Lukas
|
|
|
| Re: Scout .war not working correctly [message #1221058 is a reply to message #1219107] |
Mon, 16 December 2013 19:44 |
Uli B
Messages: 36
Registered: January 2012 |
Member |
|
|
Hello Lukas,
First of all, many thanks for answering.
Seems it was too naive to believe that the UI can be developed independently from the target ...
Main target is to have a web frontend. The reason for using a Swing desktop client is just because this is the only one that works reasonably. Yes, the RAP from Eclipse shows the same strange behaviour (and also does the SWT for the tiny svg).
1) Hm, the .jpg is possibly a bit misleading. For Swing, in a maximized window everything fits on the page, and the dimensions of all the items are as expected. So the scroll bar is created "if needed", which is perfect. Yes, unfortunately, the RAP client never shows a horizontal scroll bar, I have no idea how to change that.
2) I'm creating the svg with
SVGDocument doc = SVGUtility.readSVGDocument(new ByteArrayInputStream(xml.getBytes()));
setSvgDocument(doc);
where xml is a String like
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<svg width='1000px' height='200px' viewBox='0 0 1000 200' version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
<line x1='30' y1='180' x2='960' y2='180' style='stroke:#808080;stroke-width:1'/>
<line x1='30' y1='176' x2='960' y2='176' style='stroke:#E0E0E0;stroke-width:1'/>
...
<polyline points='30,176 495,176 960,176' style='fill:none;stroke:#EDEF00;stroke-width:3'/>
</svg>
I had a look at the source of the result in the browser:
<html><body width="100%" height="100%" onload="var iframes = parent.document.getElementsByTagName('iframe');for(var i=0;i<iframes.length;i++) { var field=iframes[i].parentNode; var color=field.style.backgroundColor; if(color && color.toLowerCase() === 'rgb(255, 255, 255)') field.style.backgroundColor='';}" onclick="parent.parent.org.eclipse.rwt.MenuManager.getInstance().update(null, 'mousedown');">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" contentScriptType="text/ecmascript" width="1480px"
zoomAndPan="disable" contentStyleType="text/css" viewBox="0 0 1000 200" height="64px" preserveAspectRatio="xMidYMid meet" version="1.1">
<line y2="180" style="stroke:#808080;stroke-width:1" x1="30" x2="960" y1="180"/>
<line y2="176" style="stroke:#E0E0E0;stroke-width:1" x1="30" x2="960" y1="176"/>
...
<polyline style="fill:none;stroke:#EDEF00;stroke-width:3" points="30,176 495,176 960,176"/>
</svg></body></html>
Strange: Where and why are width and height of the svg changed?
3) This may be killing. Drilling down from a graph/diagramme is a major feature of the app. Hopefully this can be worked around by using the pos of a click ...
4) You're right. At least for the RAP from Eclipse it works.
5) When expanding/collapsing a section, I would expect only the verical arrangement in the respective column changes. Instead, currently this also effects the width of all columns (again, with RAP, not Swing). I played around with the several setting for width, height of cells, without success.
6) As far as I can remember, I did this by simply removing all the menu stuff from the Desktop(?). Thanks for the code snippet. Yes, that works for RAP.
7) Understood. I'm using "Arial" now. That is ok.
For reference I have attached the Desktop Form .java.
[Updated on: Mon, 16 December 2013 19:49] Report message to a moderator |
|
|
| Re: Scout .war not working correctly [message #1230428 is a reply to message #1221058] |
Sun, 12 January 2014 00:40 |
Lukas Huser
Messages: 42
Registered: March 2010 |
Member |
|
|
Hi Uli
"Uli B"
1) For Swing, in a maximized window everything fits on the page, and the dimensions of all the items are as expected. So the scroll bar is created "if needed", which is perfect. Yes, unfortunately, the RAP client never shows a horizontal scroll bar, I have no idea how to change that.
I have tried this myself and also had a look at the source code. You are right: If a GroupBox is "scrollable" it will add vertical scroll bars in SWT and RAP, but not horizontal scroll bars. In Swing, both vertical and horizontal scroll bars are added if needed. I agree that the same behavior as in Swing would be desireable in SWT and RAP as well. Would you mind opening a Bugzilla ticket for this issue? Thank you.
"Uli B"
3) Strange: Where and why are width and height of the svg changed?
Scout will set the width and height of the SVG document according to the effective size of the UI component containing the document. This allows the SVG content to be scaled to the effective size of the canvas by specifying the viewBox and preserveAspectRatio attributes (as you have done in your example). If you don't specify the viewBox and preserveAspectRatio attributes, the SVG drawing will always have a fixed size. See also http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute for further reference.
I'm not quite sure what caused the downscaling in your example, you have lots of white space on the left and right side of the SVG image. Maybe the SVG field does not properly fit into the containing GroupBox (Scout property GridW)?
"Uli B"
3) This may be killing. Drilling down from a graph/diagramme is a major feature of the app.
Finally some good news: This bug has been fixed with the latest milestone release.
"Uli B"
5) When expanding/collapsing a section, I would expect only the verical arrangement in the respective column changes. Instead, currently this also effects the width of all columns (again, with RAP, not Swing). I played around with the several setting for width, height of cells, without success.
With your attached example I also experienced this strange behavior. If you like, you can open a Bugzilla ticket, such that someone else can have a deeper look at this issue.
Alternatively I can offer you my own sample code where I tried to mimic your example. I have a somewhat different layout of the expandable sections with some additional group boxes for structuring the different components, but the result looks quite similar. In my example I didn't experience changing of the column widths, so it might help you workaround this issue.
Lukas
|
|
|
Goto Forum:
Current Time: Sat Apr 20 01:13:44 GMT 2024
Powered by FUDForum. Page generated in 0.03014 seconds |
] 
Search
Help
Register
Login
Home
