Author Topic: DefaultJListRenderer sizing  (Read 16987 times)

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
DefaultJListRenderer sizing
« on: September 25, 2007, 06:15:03 PM »
I have a JList in a JScrollPane.

I'm having trouble with the size of the rendered list, depending on the number of list items and the length of each list item.  If there are no scrollbars necessary, the list renders correctly.  But if my list has enough items to require a vertical scrollbar, there's extra whitespace at the bottom of the list the size of which is dependent on the number of items.  And if my list has an item whose long enough to require a horizontal scrollbar, there's extra whitespace to the right of the list again the size of which is dependent on the length of the item.

I tried having a JScrollPane with just a horizontal scrollbar policy enabled, but it seems to still act the same as when I have a vertical scrollbar policy enabled.

I tried not having the JList in a JScrollPane.  This actually fixed the vertical scrollbar issue, but unfortunately a horizontal scrollbar isn't displayed when it's needed.  This seems the most promising, but there is a side effect.  My JList is in a JSplitPane, and when the splitter is moved in the browser, the list shrinks from the bottom.

Is there something I'm doing that's causing this not to work or is there something I can do to make this work.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #1 on: September 26, 2007, 04:37:25 PM »
Can you save the generated HTML page and attach it to this post? It's hard to understand if it's a bug with rendering or not. I think you wouldn't need the scroll pane because HTML list has a vertical scrollbar, and I think the horizontal scrollbar is added (or not) by the browser as well.

It would be really helpful to see this behavior live - is there a URL can can share?

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #2 on: September 28, 2007, 11:00:26 AM »
Okay, saved page is attached.  I'm not sure though if you'll be able to see the problem through this saved page, so I'll email you an URL you can get to.

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #3 on: October 01, 2007, 11:04:01 AM »
It's great that we can look at your app - makes it a lot easier. Here is what's going on.

The problem is that HTML <select> does not support horizontal scrolling. So if you don't use a JScrollPane you won't be able to get it.

With JScrollPane what is probably happening is that the font height of Swing application is not the same as the font height in the browser window. The height of the JList in Swing is probably calculated based on the font height and the number of items. I suspect that the font height is smaller in the browser so you end up with some unused whitespace at the bottom.

If you want a 100% match between element sizes and fonts then you should use pixel sizes everywhere (both Swing and CSS). The css is already in pixels but default Swing font sizes are in points. So the best thing to do is to set the default fonts to be in pixels as well. We should probably do it at the product level actually to save you the effort.

I'll create an enhancement request on this.

zissis

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #4 on: January 25, 2008, 03:28:48 AM »
I am having similar issues with a difrent layout within a scroll pane. Why can't AjaxSwing do the point to pixel conversion in real time using the FontMetrics class. Esentially you get the FontMetrics for the font and ask it what the pixel width and hight should be for the string. You can also re-adjust Java's view of the screen resolution by asking the browser what its system resolution is at startup and that should always render things corectly no? This way we should not have to change our swing code in any way, and the back end swing app, and FontMetrics class will calculate everything based on the user's resolution not the screen resolution that the back end server thinks it is in. Specifying pixel font size instead of point font size is always a dangerous thing to do. For example, I explicitly create a string that will be rendered with a hight of ten pixels instead of 10 point. On my 1024 x 768 resolution screen I can read it just fine. I now have a Mac user that has a monitor that is the same physical size as mine, say 17" monitor, but their resolution is set to 1920 x 1200 ... all of a suden, my 10 pixel font is unreadable to them. If we used point, on their monitor, with their resolution, the string will be rendered larger than say, my 10 pixel height. The physical size of the text will always be relativaly fixed regardless of resolution.

Zissis
« Last Edit: January 25, 2008, 03:31:11 AM by zissis »

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Font sizes - pixles, points, DPI
« Reply #5 on: January 25, 2008, 12:19:03 PM »
I'm going to do a little more researching on the subject and check with the developers but here's my understanding so far. Specifying font sizes in points is a better way to ensure that all users have readable text. Images and most of explicit element sizes in Java are all pixel-based. So other then fonts, the rest of the generated HTML sizes have to be in pixels.

The font point sizes are converted to pixel sizes using the current DPI of the screen (not screen resolution). Screen resolution will make everything appear smaller or larger but that's the way it's supposed to be. If you want the font to appear the "same" meaning that it's physical dimensions in inches will be the same, you would have to increase DPI for higher resolution. Below is an excellent explanation of what's going on with fonts

http://www.rfwilmut.clara.net/about/fonts.html

Now, what does it mean to us? I think it means that if we want the screen to appear 100% the same in the browser as it does in the Swing app, we have to ensure that the font typeface, font size, screen resolution and DPI are all the same. Let's look at them one at a time.

Font Typeface: AjaxSwing CSS themes are using different typefaces then default Swing fonts to be more appealing (blame our web designers).
Font Sizes: Swing font sizes are specified in points, AjaxSwing in pixels
Resolution: AjaxSwing determines the browser window size and gives it for Swing app that as screen resolution
DPI: Browser uses client OS DPI, AjaxSwing has it set to fixed value of 96 (default on most Windows)

So, there are quite a few differences which is why things are not going to look exactly the same right now. However, it should look very close because our default theme font sizes match the Swing default fonts in 96 DPI AND we don't use points. If there are discrepancies, they may be due to other things or the fact that our CSS uses different font typefaces. I have just bumped up this issue to high priority and if you can attach screenshots of Swing app and AjaxSwing version that would help greatly for us to be sure that the issue is indeed related to fonts.

One way or another, we will certainly resolve it once we understand exactly what the problem is.


aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #6 on: May 27, 2008, 05:01:55 PM »
Has any further work/research been done in this area since January?

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #7 on: May 27, 2008, 11:05:08 PM »
Checking on the status, will get back once I get it

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #8 on: July 30, 2008, 01:42:13 PM »
Is there any status on this?

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #9 on: July 30, 2008, 02:21:59 PM »
The status is that it is still an open issue. It turns out that browsers do not treat the pixel size as literal display pixels, which was an assumption we made in this post. On higher resolution they actually scale those sizes up. So at the time we haven't come up with a clean solution that would match the Swing application font size in pixels to the browser-rendered HTML size that depends on fonts.

That does not mean that there is no solution - we just have to do more research. Since this is not identified as a show stopper and there is no quick fix, it didn't get included into the project plan yet. But it is in the plan for the next release so it should get addressed.

What is the priority of fixing this for you?

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #10 on: July 31, 2008, 11:28:26 AM »
I think we can live with it for a while, but not too long.  What is the expected timeframe for the next release?

Let me explain a little bit why the rendered size of the JList is important to us.  We use JList to scroll our product's event messages, and we show the last 200 messages in the JList pane.  With the rendered HTML size problem, there is quite a bit of extra whitespace at the end of the list.

But we also want to take this a step further.  In our native swing interface, we automatically scroll the list to the end so that the user is always seeing the most recent messages (the user can turn off the automatic scrolling if/when they want).  We'd also like to support this in the web interface.  With the sizing problem, this isn't a possibility.  Once the sizing problem is fixed, will we be able to customize AjaxSwing such that our list pane is auto-refreshed to the bottom, while leaving other panes in the same window unaffected?

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #11 on: July 31, 2008, 01:46:56 PM »
List sizing problem is on the list of high priority features for the next release. We estimate about 2-3 weeks to fix all reported high and medium priority bugs on 2.2.0 and release a GA version. After that we'll immediately start working on 2.2.1 which will contain bug fixes. There are no significant features planned for 2.2.1 so I my expectation would be 1-2 months time frame. However, to get a better idea or a commitment you should probably contact product management.

When we fix the scrolling issues, couldn't you use JTable inside JScrollPane for event list? And presetting JScrollPane's scroll position should give you that "last message at the bottom" functionality. We are still going to come up with a solution for JList but switching to JTable should eliminate the extra space at the bottom problem, shouldn't it?

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #12 on: July 31, 2008, 03:23:49 PM »
Yes, I could try using a JTable rather than JList when rendering HTML.  My first hurdle might be that I don't want grid lines to be displayed for this JTable, but would for all others.  Is this possible?

But I would only want/need to pursue this if our next goal is possible - being able to have our messages pane auto-refreshed to the bottom, while leaving the other panes in the same window unaffected.  (And when I say unaffected, any edits currently in progress (w/o listeners) are not lost and any dialog windows layered on top of the main JFrame containing the messages pane are still intact.)  Will this be possible?

Support Team

  • Administrator
  • Hero Member
  • *****
  • Posts: 1074
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #13 on: July 31, 2008, 03:41:54 PM »
Gridlines - it should be possible to specify different CSS for that table if you give it a  known ID. To do this you'd have to set Swing component name to something like MessagesPane, and AjaxSwing will generate HTML div with that ID. Then, using CSS syntax you should be able to specify different properties for that DIV in Windows_docs/css/custom.css. BTW, it's better to keep your customizations in that file so that you can upgrade base stylesheets without loosing your changes.

Auto-update. The easiest option is to enable server push by setting updateInterval to non-zero value. See this thread http://creamtec.com/forums/index.php?topic=92.0. The only issue with that is that it's intrusive - it would submit the entire page to get the updates. The user wouldn't loose his/her changes, but if you issue frequent updates it would probably result in an odd user experience.

If you want smooth user experience then your best bet is a custom renderer that would do it's own polling of the server and update only the message panel. It would function outside of AjaxSwing request/response model because it would only look for updates to 1 component - your message pane. You can use jQuery for AJAX because AjaxSwing already includes it. If you want, you can contact our professional services and have them develop it for you.

Finally, you can also discuss with the professional services the possibility of enhancing the current server-push implementation to suite your needs better. I think you should first try it to see how it works out for you and then go from there.

aevett

  • Customer
  • Sr. Member
  • *
  • Posts: 482
    • View Profile
Re: DefaultJListRenderer sizing
« Reply #14 on: July 31, 2008, 05:03:50 PM »
The more I think about, the less I want to change our JList to a JTable.  I think I'll wait until the JList size rendering is resolved.  And then at that point we would be very much interested in making use of CreamTec's professional services to develop a custom renderer that auto-updates just this message list.