Skip to main content

Comment from Swing team about Windows L&F?

43 replies [Last post]
keithkml
Offline
Joined: 2003-06-10

Hi, I want to ask the Swing team for comments on the Windows (XP) L&F. I have a few questions, I hope they don't seem like attacks, but I want to hear what's going on in the Swing team:

1. Do you think the Windows L&F makes an application look truly native, compared to native applications or SWT?

2. Are you aware of the dozens (if not hundreds) of bugs with the way the Windows L&F looks and feels, ranging from text alignment, to colors, to fonts, to drop shadows? (Many of these are reported in the Sun bug database, some (even simple ones) have been there since JDK 1.4.2 beta, when XP L&F was first released.)

3. Do you think lack of major improvement in the Windows L&F is drawing users to SWT and/or C# for desktop development?

4. Do you know about the WinLAF project on java.net?

5. Why weren't the WinLAF fixes integrated into Tiger?

6a. What percentage of development for Tiger has gone into improving Windows L&F fidelity?
6b. What percentage does the team plan for 5.0 Update 1?
6c. What percentage for Mustang?
6d. If not, what is the Swing team working on that prevents more development going to the Windows L&F?

7. Do you plan to make the Windows L&F look and feel just as native as a C# or SWT program, for Mustang? (This would require addressing those dozens or hundreds of bugs.)

8. Do you plan to release the source code for Windows L&F, so people like Brian Duff (of WinLAF project) and myself can improve it ourselves, and bundle our improved version with our applications?

This is all, I hope someone from the Swing team can take the time to answer these questions. I think they are questions that many people in the Swing developer community wonder about, and I hope the answers will clear things up.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
coxcu
Offline
Joined: 2003-06-11

[i]"In general, we don't use the bug parade interface."[/i]

I think we found a large part of the problem.

Let's say you think you found a bug. Your first difficulty is determining if it is really a bug. At Sun, you have access to definitive resources (people) to help decide this. On the outside, we don't. If the community was given acess to the bug queue, they could help the uncertain submitter decide if it is really a bug.

Now comes the big problem. You're convinced that it is a bug. Is it a dupe? If you read this very thread, you can see that determining duplicate bugs is seriously error prone.

So, I submit the bug, [b]and a few months later[/b] I can vote for it. Why can't I fund bug fixes short of buying a support contract? There are millions of Java developers. Why limit each one to three votes? I would like to be able to spend real money on bounties for bug fixes.

Finally, there needs to be an issue tracking system for Bug Parade.

cowwoc
Offline
Joined: 2003-08-24

I second that. I semi-seriously think I would dish out money in the form of bounties against bug fixes.

jeff
Offline
Joined: 2003-06-10

Doh! I forgot to log out of the admin account before posting!

So the above post is from me. :)

shan-man
Offline
Joined: 2006-02-17

Hi Zander,

Got your second submission - but I encourage you to use a valid e-mail address in the future so that you can be notified of status or contacted when necessary.

In any case, from the information in your second submission I managed to search our databases more thoroughly and I found your original submission. It's been in a Swing team member's queue since October 18th. And I apologize - I DID see the bug already. When I couldn't find it the first time I must have assumed that I had only ever seen e-mail on it and not an official bug.

Here's the bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6180258

I'll close the new incident - not that your e-mail address would be notified anyway...

Thanks!
Shannon

zander
Offline
Joined: 2003-06-13

> Hi Jeanette!
>
> The system isn't perfect (yes, that's an
> understatement) but it's what we have and it's how we
> track bugs. I'm sorry about your experience(s), but
> it's far better to tell us about problems with the
> system so we can try to fix them, rather than give
> up

The worrying thing is that I hear that reactions a bit too often, the reaction of Kleopatra, that is.

I'm still at a success rate lower then 0% with quite some bugs being filed and either not fixed or fixed incorrectly (hence the negative score).

I, personally, have given up on both bug-reporting and reporting bugs in the bugreporting process.

Jeff, just for fun; find out what happened with the bug coming from http://www.javadesktop.org/forums/thread.jspa?threadID=5650&tstart=10
I did not put my real email in there (no proof of failure keeps my hope alive), but I'm willing to bet some beers that this one did not end up in the swing engineers queue. For some reason, none of my bugreports ever do.

Thomas.

shan-man
Offline
Joined: 2006-02-17

Hi zander,

zander wrote:
> Jeff, just for fun; find out what happened with the
> bug coming from
> http://www.javadesktop.org/forums/thread.jspa?threadID
> =5650&tstart=10
> I did not put my real email in there (no proof of
> failure keeps my hope alive), but I'm willing to bet
> some beers that this one did not end up in the swing
> engineers queue. For some reason, none of my
> bugreports ever do.

When you mentioned this bug a while ago, I immediately took a look at the problem - and figured out where it was introduced. Then we asked for you to file a bug on it. Did you do so? Would you mind sending me the incident number or any information you received back when you submitted. I'll check the status.

Thanks!
Shannon

zander
Offline
Joined: 2003-06-13

> When you mentioned this bug a while ago, I
> immediately took a look at the problem - and figured
> out where it was introduced. Then we asked for you to
> file a bug on it.

Ok, thats good to hear ;)

> Did you do so?

I filed the bug, yes. As you requested, and as I answered in the other thread.

> Would you mind
> sending me the incident number or any information you
> received back when you submitted. I'll check the
> status.

I did not write down the incident number, so I don't know.

shan-man
Offline
Joined: 2006-02-17

Hi Zander,

I see all bugs as they enter the Swing Team's queue and I haven't seen this bug yet. So you're correct that it's not in our queue yet. However, I've also looked through all pending "incidents" and there's no trace of it there either.

Since you a) didn't use your own e-mail and b) don't have the incident number - I'm not able to track it down. Do you perhaps remember the synopsis you used?

BTW: When you file a bug you should get an e-mail response with the details and incident number. Did you not receive this?

Thanks!
Shannon

mgrev
Offline
Joined: 2003-08-12

Hi Shannon,
just to get an oppinion from you guys. Do you think that the bug parade is good?

Cheers,
Mikael

cmsadmin
Offline
Administrator
Joined: 2009-04-13

> Hi Shannon,
> just to get an oppinion from you guys. Do you think
> that the bug parade is good?
>
> Cheers,
> Mikael

Hi Mikael, I'm not Shannon, but I think I can *mostly* speak for the whole team :)

In general, we don't use the bug parade interface. Bugs from that are entered into our internal bugtraq tool, which for the most part works well (it has it's own quirks, but that's not relevant to this conversation).

So, most of our impression of bug parade on the JDC comes from your comments.

Speaking of which, the posts here from Jeanette, Zander, yourself, and others have prompted us to do an internal review of our process. Currently the discussion is in email, but Scott and I willl be meeting face to face with the bug parade folks later this week.

thanks! and please do keep the feedback coming...

jeff

zander
Offline
Joined: 2003-06-13

due to the 'lost' report I tried reporting again; here are my complaints.

[b]product/category[/b] should be a list, selecting from a combobox is annoying.
There should be a 'search' to quickly locate the correct one, since 'searching' in 3 comboboxes and their hierarchy is nearly impossible if you are not very well aware of what the bug is about.
There should be a 'general' entry at the top of the 'subcategory' so a Sun employee can move it to the right spot if the poster does not know.
Follow the wizard here to get several nice ideas: http://bugs.kde.org/wizard.cgi

[b]OS[/b]There should be a 'unspecified' one. One I can select if I know that the bug is net relevant to the OS. This is probably true for the majority of the bugs; but I was very unpleasantly surprised that selecting 'generic/other' lead to an error message saying that suns bugsystem was not for me :(
ps. I find it a bug that I can continue while the 'OS' combobox is still set to 'SELECT ONE'. Javascript is not _that_ new...

[b]Synopsis[/b]
Would be nice if you used 'summary' or something here. I had to grab a dictionary to find out what that word means.. (I'm not native english).

Using the wizard link above I think its a _very_ good idea to search the database using these words to make sure similar bug-reports are ruled out.

[b]company name[/b]
This is obligated, why? I don't have one!

[b]feedback[/b]
It says this:
We will review your report. Depending upon the completeness of the report and our ability to reproduce the problem, either a new bug will be posted, or we will contact you for further information. You will be notified by email in either case.

Why is there no review-id?
Why can't I access and modify the report after I posted it? I might want to attach a file or post more details. Both are impossible now.

shan-man
Offline
Joined: 2006-02-17

Zander,

As Jeff mentioned, an internal review of the JDC tool is coming based on the suggestions of this community. However, I'd like to make one suggestion:

You complain that there is no review id when you submit a bug. Perhaps if you used the tool with your REAL e-mail address you'd have a better experience. ;)

Regards,
Shannon

cowwoc
Offline
Joined: 2003-08-24

Shannon,

Invalid email aside, Zander brings up very good points. I'd bring up more issues but I think we better handle them one at a time. On a related note, I waited a full *six months* before Sun fixed a bug in BugParade whereby my "Bug Watch List" wasn't showing up. So for six months, I couldn't add bugs I've submitted to my list and as a result I lost track of them. Fortunately that component of the webpage was recently fixed.

On a closing note, I am encouraged by the changes I've seen in Sun over the past 3 months. If things continue at the current rate, I'll run out of reasons to complain within a few months. Keep up the good work :)

Gili

mgrev
Offline
Joined: 2003-08-12

Jeff, Shannon and gang,

I must agree with Gili, something has changed, for the better.
I however won't run out of ideas on how to perfect Java for atleast a year! ;)

Cheers,
Mikael

mgrev
Offline
Joined: 2003-08-12

+1, Well said Jeanette!

As much as I respect the engineers at Sun I dislike the ancient bug-thingy-crap that also tries to double as some kind of RFE-drop-in.

As I have said ealier: Scott and gang, go over to the bug-report group (ok the 10% partial time guy that is sick most of the time) and give them wedges until they fix it! This IS you face towards the community. Btw, give wedges to the whole web-design team and hire some fab-five guys that can make the sites look non-ugly to look at. No offence. Just look at that shadow on the toolbar at the top, my mother would do better in Paint!

:)

Cheers,
Mikael Grev

mthornton
Offline
Joined: 2003-06-10

> Let me first state where I stand. I have never used
> SWT but one thing is clear to me: we should not be
> trying to play catch-up and emulating the Windows L&F
> using lightweight components. Not only is this a huge
> waste of resources but also you will not be able to

Heavyweight components are fine until you need to modify their behaviour (something that is much easier with lightweight components). Unfortunately there are lots of complications in mixing light and heavy components. Thus we probably save resources by going for a completely lightweight approach. A completely heavyweight approach would leave us stuck with the common set of controls available on all (or most) platforms.

cowwoc
Offline
Joined: 2003-08-24

Regarding SWT, Swing, "native L&F", etc...

I understanding "native L&F" is more than just native-looking widgets, but that is a very big part. Not having to play catch-up in that domain is a very big deal.

Secondly, I am not argueing we should use native widgets for all L&Fs. I am simply saying: if the user selects the "native L&F" whatever "native" is be it win32 or linux, then you fallback on native widgets. If, however, the user selects a non-native L&F, we Swing as usual.

I'm really not going to get offended with a debate in this domain, I promise :) I'm just curious why, aside from design and backwards compatibility issues, one would not benefit from going this route?

Gili

davetuma
Offline
Joined: 2006-02-17

> Secondly, I am not argueing we should use native
> widgets for all L&Fs. I am simply saying: if the user
> selects the "native L&F" whatever "native" is be it
> win32 or linux, then you fallback on native widgets.
> If, however, the user selects a non-native L&F, we
> Swing as usual.
>
> I'm really not going to get offended with a debate in
> this domain, I promise :) I'm just curious why, aside
> from design and backwards compatibility issues, one
> would not benefit from going this route?
>
> Gili

I've been using Java and Swing for the past six years to write rich client applications, and I can contribute my thoughts in answer to this question.

The use of lightweight components in Swing provides a HUGE benefit in terms of customizability and configurability. By extending Swing classes and overriding certain methods, I've been able to make Swing do some pretty amazing, out-of-the-box things. The end result is that, through my customizations, I've created widgets that have a new appearance or new behavior, that precisely match my customer's needs. At the same time, I've saved a lot of work by reusing a ton of Swing code (through inheritance).

One project I'm currently on is a great example of this. We're porting an existing native windows application to Java and Swing. For years, customers have been asking, "Could the user interface do XYZ?" and we've had to tell them no because the native components couldn't support the requested behavior. Suddenly, in Java/Swing, a whole lot of customer requests are now becoming possible.

Some people may want their components to look exactly like a native app. If that is important to you, feel free to use a library like SWT that wraps native coponents. But for me, looking exactly like a native app isn't nearly as important as being able to arbitrarily customize the behavior and appearance of the widgets, and for my customizations to port seamlessly from Windows to Unix/Linux/Mac OS X. If Swing were to switch to use native components, I'd lose that capability.

A phrase in the above post seems key: "...aside from design and backwards compatibility issues..." Backward compatibility is crucially important - I don't want my customers to install Java 1.5 and see all my applications break. And the customizability feature above is just one of the implications of the "design issues" of Swing vs native components. At least in my opinion, "design and backwards compatibility issues" are hundreds of times more important than an exact match with native widgets. But that's just me. :-)

gfx
Offline
Joined: 2003-06-14

> About the rendering pipeline, I think most users
> would prefer slight performance decrease (by drawing
> text through WinAPI to temporary in-memory bitmap, in
> the worst case, then rendering that bitmap to the
> screen), over the sort of ugly non-antialiased font
> rendering we have now. What do you think about this?

I tried to achieve this during this summer but I ran into annoying problems. If you ever manage to find a way to do it, please tell me !

mthornton
Offline
Joined: 2003-06-10

>
> About the rendering pipeline, I think most users
> would prefer slight performance decrease (by drawing
> text through WinAPI to temporary in-memory bitmap, in
> the worst case, then rendering that bitmap to the
> screen), over the sort of ugly non-antialiased font
> rendering we have now. What do you think about this?
>

You would either have to abandon accelerated rendering or try to retrieve the 'background' that the text was to be drawn on. Getting image data back from an accelerated surface is expensive. All this suggests doing it only for special cases such as labels and buttons where the background is known.

Personally I would prefer consistent anti-aliased text rendering everywhere even if it wasn't quite identical to ClearType. Provided the quality is good I don't think many users will be bothered by the occasional pixel being different to the native appearance.

keithkml
Offline
Joined: 2003-06-10

> > > Sure thing. The Longhorn work I referred to
> > > previously required
> > > native changes in AWT that Windows will call
> into.
> > > This means you can
> > > only compile the windows look and feel on the
> latest
> > > J2SE builds.
> > > Other changes happen too, like adding methods to
> > > Swing proper that
> > > require support in the plaf classes.
> > >
> > > It's more than that. It's that to build the
> current
> > > windows look and
> > > feel you need to have the latest JDK, which isn't
> > > generally
> > > available.
> >
> > I think I misunderstand something, why couldn't I
> compile Windows
> > L&F for J2se 5.0 against the JDK 5.0?
>
> I assumed you were asking for us to open source the
> windows look and
> feel. If we did that it would mean either the
> windows look and feel
> couldn't use new APIs in the JDK until the JDK ships,
> or you couldn't
> compile it because it depends upon APIs not yet
> public.

I think I see what you're saying. When I say I'd like Swing to be open-sourced, I mean I'd like to see Swing source code released under BSD-style license, so developers could work on our own L&F based on it, and distribute that with our applications. Then, if the Swing team wanted, it could merge our changes with Swing's tree for each release. (We could also merge changes done by Swing team with our L&F.) This would allow bugfixes and new features to get to clients way faster than the J2SE release cycle, without doing messy things like WinLAF's "patches."

-Keith

Scott Violet

On Thu, Nov 04, 2004 at 07:26:53PM -0500, swing-feedback@javadesktop.org wrote:
> > > > Sure thing. The Longhorn work I referred to
> > > > previously required
> > > > native changes in AWT that Windows will call
> > into.
> > > > This means you can
> > > > only compile the windows look and feel on the
> > latest
> > > > J2SE builds.
> > > > Other changes happen too, like adding methods to
> > > > Swing proper that
> > > > require support in the plaf classes.
> > > >
> > > > It's more than that. It's that to build the
> > current
> > > > windows look and
> > > > feel you need to have the latest JDK, which isn't
> > > > generally
> > > > available.
> > >
> > > I think I misunderstand something, why couldn't I
> > compile Windows
> > > L&F for J2se 5.0 against the JDK 5.0?
> >
> > I assumed you were asking for us to open source the
> > windows look and
> > feel. If we did that it would mean either the
> > windows look and feel
> > couldn't use new APIs in the JDK until the JDK ships,
> > or you couldn't
> > compile it because it depends upon APIs not yet
> > public.
>
> I think I see what you're saying. When I say I'd like Swing to be
> open-sourced, I mean I'd like to see Swing source code released
> under BSD-style license, so developers could work on our own L&F
> based on it, and distribute that with our applications. Then, if the
> Swing team wanted, it could merge our changes with Swing's tree for
> each release. (We could also merge changes done by Swing team with
> our L&F.) This would allow bugfixes and new features to get to
> clients way faster than the J2SE release cycle, without doing messy
> things like WinLAF's "patches."

I think you're arguing for forking Swing, and that is out of my
hands;)

-Scott

keithkml
Offline
Joined: 2003-06-10

> > I think I see what you're saying. When I say I'd
> like Swing to be
> > open-sourced, I mean I'd like to see Swing source
> code released
> > under BSD-style license, so developers could work
> on our own L&F
> > based on it, and distribute that with our
> applications. Then, if the
> > Swing team wanted, it could merge our changes with
> Swing's tree for
> > each release. (We could also merge changes done by
> Swing team with
> > our L&F.) This would allow bugfixes and new
> features to get to
> > clients way faster than the J2SE release cycle,
> without doing messy
> > things like WinLAF's "patches."
>
> I think you're arguing for forking Swing, and that is
> out of my
> hands;)
>
> -Scott

Forking is just a word, I'm asking for the Swing source code under a free license, so that people who care about their applications' L&F can distribute a better Windows L&F with their applications, instead of using the default Swing Windows L&F. I don't care how it's done, if you want to call it forking then that's what you will call it.

-Keith

cowwoc
Offline
Joined: 2003-08-24

I agree with Keith that keeping the L&F up to date is not something Sun should waste their time on (as I already mentioned before). Let the community do it right and Sun could fold in changes back into the official JDK on a regular basis. Everyone would benefit.

The fact of the matter is there is *a lot* of interest in an up-to-date Windows L&F and Sun simply does not have the resources to deliver this in time. There are just too many issues. The open-source community can deliver a better product faster (see WinLAF for example) and this should be encouraged. Sun can still keep control of Swing and decide which changes to fold back into the official distribution. The only thing you guys would have to do differently is merge changes from WinLAF back into Swing faster than has been done in the past. We'll do the work, you code/design-review and fold back the changes. Wouldn't this be better/faster for everybody?

Gili

kleopatra
Offline
Joined: 2003-06-11

>
> . Make sure bugs are filed with suggested fixs! This
> is a tremendous
> help to us. Various people have commented this is
> is currently too
> hard. We're looking to streamline this process.

HAR, HAR, HAR...

Sorry, Scott - but I did hear that once too often. You are trying to get that f*** bug report system to work smoothly for a decade (okay I'm exaggerating :-) without the slightest success. Whatever you do is for the trash bin if you don't put qualified and reasonably motivated personel into the first row to handle incoming reports.

My latest experience: a very simple not overly important omission in radio buttons' action listening code - it took 10 months to get evaluated and then the *** dared to send me the following

[quote]
We recently released J2SE 1.5.0 Beta 2 with many bug fixes and enhancements. Consider downloading a free copy at http://java.sun.com/j2se/1.5.0/.

If upgrading to 1.5.0 Beta 2 is not possible, a free download of J2SE 1.4.2_05 is at http://java.sun.com/j2se/1.4.2/.

Please test on the above versions to determine if these versions may have fixed this problem and let me know what happens?
[/quote]

Looks like he can't or isn't willing to even fire up his favourite IDE to let the test code run. I'm totally fed up with this utter disrespect of MY time and MY effort.

As you well know these or similar reactions are no singletons - and this one resurrected an old decision (the bug parade was on parole only) to never again waste my time with the usual bug reporting - I either go for the engineer directly or do nothing.

That said: reading in the bug parade can be fun, revealing some unexpected strategies.

Wait until the bug evaporates (#4133566):
"the code was sufficiently rewritten since this problem was declared."

Look away (#4765357):
"Still reproducible in 1.5.0. There is an easy workaround for this rare case, so it has been determined better not to try to fix it."

Never read the API (#4906060):
"These bindings work by calling scrollRectToVisible which
only does something for JScrollPanes"

One riddle I never could solve: why are the evaluators anonymous? If they can stand for their decisions they could do so by name (or nickname, don't care) the same as I stand with my identity for whatever I write - which always can be subjectively or objectively right or wrong or arguable. It's simply more motivating to discusss an issue with a person than with an xxxx.

Speaking about motivation: those long-standing thoroughly ignored bugs don't help in that respect. My oldest unresolved dates from 1998 (#4199578)!

Okay, 'nough ranted for today - work's waiting :-)
Jeanette

jeff
Offline
Joined: 2003-06-10

Hi Jeanette!

The system isn't perfect (yes, that's an understatement) but it's what we have and it's how we track bugs. I'm sorry about your experience(s), but it's far better to tell us about problems with the system so we can try to fix them, rather than give up

Yes, you've had frustrating experiences, and I apologize on Sun's behalf for that - but try and remember that Sun isn't "one person". There are thousands of engineers here, and the vast majority are working very, very hard. Don't let a few bad experiences put you off from providing feedback through bug reports, for I can promise you one thing - not submitting bug reports only ensures that we don't hear about them.

And please believe me - I've looked at the numbers, the vast majority of bugs make it through bug parade and into the swing engineer's queue. Yes, it's not perfect but it's what we have. And please DO feel free to email me if/when you have a problem with the system - I'm more than happy to escalate internally to see if we can fix it.

jeff

kleopatra
Offline
Joined: 2003-06-11

Hi Jeff,

> The system isn't perfect (yes, that's an
> understatement)

indeed :-)

>
> Yes, you've had frustrating experiences, and I
> apologize on Sun's behalf for that - but try and
> remember that Sun isn't "one person".

_you_ don't have to apologize - and yes, I know that perfectly well.

> There are
> thousands of engineers here, and the vast majority
> are working very, very hard. Don't let a few bad
> experiences put you off from providing feedback
> through bug reports, for I can promise you one thing
> - not submitting bug reports only ensures that we
> don't hear about them.
>

Yeah, we all are hard-working, many of us even like it. No, it's not a "few" bad experiences - it's community experience that bug reporting is a pain ... And I disagree with your conclusion: you still can hear about bugs if you care (I know you do, don't get me wrong, please) - read an arbitrary java technology forum - but it's harder.

Last time I triggered an internal escalation was more or less exactly 3 years ago, history repeats itself, after all :-) And I'm pretty sure that I'm not the only one who explodes occasionally - how many complaints do you get? Fundamentally there was no change at all, at least nothing visible from the outside.

Jeanette

jeff
Offline
Joined: 2003-06-10

> And I disagree with your conclusion: you still can hear
> about bugs if you care (I know you do, don't get me wrong,
> please) - read an arbitrary java technology forum - but
> it's harder.

Alas, it's not just harder, it's not doable. There are 13 Swing engineers and another dozen AWT engineers. But there are millions of Java developers. We cannot rely on the development engineering teams to get their bugs via discussion forums. We'd spend all day just typing in bug reports, and get no coding done.

jeff

kleopatra
Offline
Joined: 2003-06-11

Hi Jeff,

>
> Alas, it's not just harder, it's not doable. There
> are 13 Swing engineers and another dozen AWT
> engineers. But there are millions of Java developers.
> We cannot rely on the development engineering teams
> to get their bugs via discussion forums. We'd spend
> all day just typing in bug reports, and get no coding
> done.

a day has 24 hours and if that's not enough you can take the night as well. SCNR ;-).

You have a very valid point - but then we are back to step 1: how to motivate developers to invest into quality bug reports? How to make it a pleasant task to report? How to enhance the flow of bug-related information to the engineering team and transform it into fixes to the code base in a timely manner?

From my experience (my own and from reading public discussion forums regularly ) many programmers are willing and eager to contribute but are flabbergasted after receiving the first, second or n-th response - which often feels as if the receiving end did not read the input or did not understand what s/he was reading. Something - don't know how or what, thanks Goddess I'm not a manager - in the receiving procedure has to be changed. My opionion, of course biased, it's so easy to point fingers ;).

Jeanette

cowwoc
Offline
Joined: 2003-08-24

Jeanette,

Take a look at the Netbeans project. Their issue-tracker and the people on the team are amazing. I hold them up as an example of how Sun could rework BugParade to be less formal and allow for more two-way communication between users and developers.

Gili

karsten
Offline
Joined: 2003-06-11

Hi,

I try to handle platform style differences with the layout, an action manager, and some convenience code for accessing the platform modes.

The JGoodies Forms layout system uses a LayoutStyle to describe style guide gaps, margins, minimum widths, and the button bar order. Forms ships with a WindowsLayoutStyle and a MacLayoutStyle.

To meet the platform style w.r.t. default texts and keyboard shortcuts I'm using multiple sets of action resources. When reading these resources the platform is checked and either a default resource is used, or the platform-specific one. For example the "Back" action in a help browser uses an "alt LEFT" accellerator on non-Mac, and "meta OPEN_BRACKET" on the Mac.

Thirdly I'm using a Mode class that can describe platform and look&feel modes like "Windows platform", "Mac", "non-Windows", "Windows L&F", "non-Aqua-L&F", etc. Some components and the application code use these Modes to better meet the current platform and look&feel. For example extended menu items show mnemonics only in "non-Aqua-L&F" Mode and hide them if Aqua is active.

- Karsten

osbald
Offline
Joined: 2003-06-13

Whoa got a strange case of deja-vu (http://www.jroller.com/page/osbald/20041103#j2se_5_0_and_windows ) going on here, wished I'd known about this conversation earlier.. thanks to Scott for his diligent link blogging.

Also having problems with XP L&F, and asking many of the same question. Although I'd had an XP workstation at work for several months - I switched it into Classic mode and missed out on a lot of these issues until now (previous link).

I'd be one pushing for some fixes in the next update, the wretched default font bug and the ghostly extra spaces in drop down menus, popups, context menus need fixing ASAP.

Anybody know what state WinLAF is in? Hasn't been much action on the project for several months and I havnt had any luck from posting to the forums https://winlaf.dev.java.net/servlets/ForumMessageList?forumID=187 or emails to Brian Duff recently (although he seems to have relocated to the US recently? still working on JDeveloper UI?). I'm working through several issues with the current version and j2se 5.0 l&f at the moment..

- Richard

keithkml
Offline
Joined: 2003-06-10

The Java Research License was announced today at http://www.java.net/jrl.csp. I believe it would allow the source code for the Windows L&F to be taken, modified, and redistributed without hassle in binary form. I believe distributing the source code would require a click-through license agreement.

I think anyone interested should look into converting WinLAF to a fork of the Swing Windows L&F (or maybe starting a new project with this goal); I plan to look into it soon.

mgrev
Offline
Joined: 2003-08-12

I have started a thread at JavaLobby on how to imporove the bug parade. Go over to

http://www.javalobby.org/forums/thread.jspa?threadID=15419&tstart=0

and post what needs to be done. Sun folks included.

Cheers,
Mikael Grev

Scott Violet

On Thu, Nov 04, 2004 at 04:32:33PM -0500, swing-feedback@javadesktop.org wrote:
> Hi, I want to ask the Swing team for comments on the Windows (XP)
> L&F. I have a few questions, I hope they don't seem like attacks,
> but I want to hear what's going on in the Swing team:

These are excellent questions, and very far from being attacks.

> 1. Do you think the Windows L&F makes an application look truly
> native, compared to native applications or SWT?

Neither SWT nor Swing's windows l&f will make an application look
truly native. Each of the platforms: windows, Gnome, OS X, have their
own visual design guidelines that are often times very different. As
such, just using the platform look and feel will in no way make your
app look truly native. You have to honor the spacing dictated by the
platform, use the appropriate widgets, icons ... Even simple things,
like mnemonics, are typically discouraged on OS X.

> 2. Are you aware of the dozens (if not hundreds) of bugs with the
> way the Windows L&F looks and feels, ranging from text alignment, to
> colors, to fonts, to drop shadows? (Many of these are reported in
> the Sun bug database, some (even simple ones) have been there since
> JDK 1.4.2 beta, when XP L&F was first released.)

Sadly, we are. As with any project of this size we have to balance
out features vs bug fixs for any particular release. That said, we
realize how important Windows bug fixs are to the community and are
doing are best to stay on top.

> 3. Do you think lack of major improvement in the Windows L&F is
> drawing users to SWT and/or C# for desktop development?

It's a tough question, and I've heard varying response from different
people. End users use an application to solve a particular problem,
that is the important thing. Some users, and many developers, notice
differences between Swing and the platform, but I don't think this by
itself is enough to cause people to leave Swing or the java platform.

That said, what is your, and the communities, perspective on this.
Are the bugs enough to cause developers to leave Swing? Do you know
of any developers that have done this?

> 4. Do you know about the WinLAF project on java.net?

Yes, we do, and we are going to try and work more closely with you
guys going forward.

> 5. Why weren't the WinLAF fixes integrated into Tiger?

Primarily because of timing and resources, but also because of
compatability. For example, if we automatically started showing
popups we would conflict with existing popups (like yours).

> 6a. What percentage of development for Tiger has gone into improving Windows L&F fidelity?

Not enough! Seriously though, it was likely around 20%.

> 6b. What percentage does the team plan for 5.0 Update 1?

The update releases are not normal releases, in that the update
releases are driven almost entirely by customer escalations. As we
typically see very few customer escalations against look and feels
there are only a handful of windows targeted for update 1 (it's
important I say targeted, update 1 isn't done and may change).

> 6c. What percentage for Mustang?

More than tiger! We've already done a significant amount of work to
better position ourselves for Longhorn.

> 6d. If not, what is the Swing team working on that prevents more development going to the Windows L&F?

Hopefully my previous answer will appease you to some degree. But we
are doing more, and realize how important this is to the community.

> 7. Do you plan to make the Windows L&F look and feel just as native as a C# or SWT program, for Mustang? (This would require addressing those dozens or hundreds of bugs.)

We are striving to be better and better our look and feel fidelity.
Should I write that 100 times on the chalk board? ;)

> 8. Do you plan to release the source code for Windows L&F, so people
> like Brian Duff (of WinLAF project) and myself can improve it
> ourselves, and bundle our improved version with our applications?

We've kicked this idea around, but because of dependancies you would
only be able to build it on the latest J2SE. In other words it
wouldn't be of much benefit.

-Scott

keithkml
Offline
Joined: 2003-06-10

Thank you very much for you response, it clears up a lot of things I was wondering about Swing's development.

> Neither SWT nor Swing's windows l&f will make an
> application look
> truly native. Each of the platforms: windows, Gnome,
> OS X, have their
> own visual design guidelines that are often times
> very different. As

This is true. Are there plans for Swing to address this, even for later releases like 7.0 or 8.0? Maybe it's outside Swing's scope; do you think there will be additions to the JDK to support this kind of thing? (By "this kind of thing" I mean the developer specifies abstractly how the UI should be laid out, and which components it should include, and at runtime a UI is generated which conforms to UI guidelines. I think it would be very hard, and possibly the only of its kind, but I don't think it would be impossible.)

Another simpler solution to this would be implementing a framework for UI guidelines, so I could say
[i]if (UIGuidelinesManager.getCurrentGuidelines() == UIGuidelines.OSX) {...}[/i]
Swing could also provide a way for me to easily load different classes based on current UI guidelines settings. (Note, all of this can be done right now by checking OS version system property and current L&F, but that's clunky and I don't feel that it's reliable.)

> > 3. Do you think lack of major improvement in the
> Windows L&F is
> > drawing users to SWT and/or C# for desktop
> development?
>
> That said, what is your, and the communities,
> perspective on this.
> Are the bugs enough to cause developers to leave
> Swing? Do you know
> of any developers that have done this?

I believe if the Windows L&F appeared more native (including font smoothing and menu drop shadows and table sorting & AUTO_RESIZE_OFF and everything SWT and the WinAPI does automatically), and if the JDK provided the native-integration functionality SWT provides (such as a web browser and file types and icons information), far fewer people would use SWT. JDIC helps with these things, and JDNC too, but these projects are young and I don't think JDIC is stable enough, nor do a few of its subparts have enough working features, to justify using it in my projects.

I think the two other main reasons to use SWT are a cleaner API (through JFace I believe), and apparent visual performance.

> > 5. Why weren't the WinLAF fixes integrated into
> Tiger?
>
> Primarily because of timing and resources, but also
> because of
> compatability. For example, if we automatically
> started showing
> popups we would conflict with existing popups (like
> yours).

I understand the compatibility issues. For the text field popup menu issue, though, I don't think it would hurt anyone's code if a client property were added which allowed this menu to be shown.

It seems that backwards compatibility is a big issue for Swing. It was also cited as the reason for making the new Ocean L&F still have those big clunky buttons, for example. Has the Swing team ever considered adding a means of setting a property which specifies which behavior the application wants? For example, my application could say UIManager.put(SwingUtilities.KEY_COMPLIANCE_MODE, SwingUtilities.VALUE_COMPLIANCE_MODE_5_0), and it on Windows it would show text popup menus, and use AUTO_RESIZE_OFF on tables, and things like that.

I'm curious what timing and resources issues came up dealing with WinLAF. The code is all there, and under the SPL or BSD license, so I believe you could've simply copied and pasted it. Was there more to it?

> > 6a. What percentage of development for Tiger has
> gone into improving Windows L&F fidelity?
>
> Not enough! Seriously though, it was likely around
> 20%.

I say that's not bad, and Tiger shows some nice improvements, like tab rollovers.

> > 6c. What percentage for Mustang?
>
> More than tiger! We've already done a significant
> amount of work to
> better position ourselves for Longhorn.

I'm curious, what changes does Longhorn bring to XP styling? It uses the same theme engine, right?

> > 6d. If not, what is the Swing team working on that
> prevents more development going to the Windows L&F?
>
> Hopefully my previous answer will appease you to some
> degree. But we
> are doing more, and realize how important this is to
> the community.

I'm glad the team feels this way but it doesn't answer my question. I am curious about what the Swing team works on, since it appears that aside from Ocean and Synth & GTK LF, not much in Swing has changed since 1.4. I am also curious, how many developers work on Swing? How many does Sun employ directly as full time Swing developers? (I do not include JDNC, which I understand has taken some Swing developers.)

> > 8. Do you plan to release the source code for
> Windows L&F, so people
> > like Brian Duff (of WinLAF project) and myself can
> improve it
> > ourselves, and bundle our improved version with our
> applications?
>
> We've kicked this idea around, but because of
> dependancies you would
> only be able to build it on the latest J2SE. In
> other words it
> wouldn't be of much benefit.

Can you describe these dependencies briefly? What do you mean, you could only build it on the latest J2SE? If you mean there would need to be a different version for each J2SE release, I think that would be acceptable, considering there have been only six releases of 1.4.2, and one release of 5.0, in the past year or two.

I have another question: What can I and other members of the Swing users community, do to help Swing? The WinLAF project is a start, but is there anything else that you think could be done?

Thanks again for responding and answering these questions.
-Keith

Scott Violet

On Thu, Nov 04, 2004 at 06:27:33PM -0500, swing-feedback@javadesktop.org wrote:
> Thank you very much for you response, it clears up a lot of things I was wondering about Swing's development.
>
> > Neither SWT nor Swing's windows l&f will make an
> > application look
> > truly native. Each of the platforms: windows, Gnome,
> > OS X, have their
> > own visual design guidelines that are often times
> > very different. As
>
> This is true. Are there plans for Swing to address this, even for
> later releases like 7.0 or 8.0? Maybe it's outside Swing's scope; do
> you think there will be additions to the JDK to support this kind of
> thing? (By "this kind of thing" I mean the developer specifies
> abstractly how the UI should be laid out, and which components it
> should include, and at runtime a UI is generated which conforms to
> UI guidelines. I think it would be very hard, and possibly the only
> of its kind, but I don't think it would be impossible.)

We're definately doing some work in this area. I don't know that
it'll be at the level of abstractly specifying a UI, but we are trying
to ease this problem.

> Another simpler solution to this would be implementing a framework for UI guidelines, so I could say
> [i]if (UIGuidelinesManager.getCurrentGuidelines() == UIGuidelines.OSX) {...}[/i]
> Swing could also provide a way for me to easily load different
> classes based on current UI guidelines settings. (Note, all of this
> can be done right now by checking OS version system property and
> current L&F, but that's clunky and I don't feel that it's reliable.)

You could also use ResourceBundles for this. Which begs the question
of a resource format for Swing. That too is something we're
investigating.

> > > 3. Do you think lack of major improvement in the
> > Windows L&F is
> > > drawing users to SWT and/or C# for desktop
> > development?
> >
> > That said, what is your, and the communities,
> > perspective on this.
> > Are the bugs enough to cause developers to leave
> > Swing? Do you know
> > of any developers that have done this?
>
> I believe if the Windows L&F appeared more native (including font
> smoothing and menu drop shadows and table sorting & AUTO_RESIZE_OFF
> and everything SWT and the WinAPI does automatically), and if the
> JDK provided the native-integration functionality SWT provides (such
> as a web browser and file types and icons information), far fewer
> people would use SWT. JDIC helps with these things, and JDNC too,
> but these projects are young and I don't think JDIC is stable
> enough, nor do a few of its subparts have enough working features,
> to justify using it in my projects.
>
> I think the two other main reasons to use SWT are a cleaner API
> (through JFace I believe), and apparent visual performance.

So, are you aware of people leaving Swing for SWT? Have they actually
deployed SWT applications?

> > > 5. Why weren't the WinLAF fixes integrated into
> > Tiger?
> >
> > Primarily because of timing and resources, but also
> > because of
> > compatability. For example, if we automatically
> > started showing
> > popups we would conflict with existing popups (like
> > yours).
>
> I understand the compatibility issues. For the text field popup menu
> issue, though, I don't think it would hurt anyone's code if a client
> property were added which allowed this menu to be shown.

We are looking at ways to give backward compatability, while moving
forward for developers that want the new functionality but can stomach
the potential incompatabilities.

> It seems that backwards compatibility is a big issue for Swing.

Definately! It's the number one issue we here from customers.

> It
> was also cited as the reason for making the new Ocean L&F still have
> those big clunky buttons, for example. Has the Swing team ever
> considered adding a means of setting a property which specifies
> which behavior the application wants? For example, my application
> could say UIManager.put(SwingUtilities.KEY_COMPLIANCE_MODE,
> SwingUtilities.VALUE_COMPLIANCE_MODE_5_0), and it on Windows it
> would show text popup menus, and use AUTO_RESIZE_OFF on tables, and
> things like that.

Something very close to this is on the table for 6.0.

> I'm curious what timing and resources issues came up dealing with
> WinLAF. The code is all there, and under the SPL or BSD license, so
> I believe you could've simply copied and pasted it. Was there more
> to it?

Resources issues on our side, and timing in finding the project.
Additionally the code is against 1.4.2.

> > > 6a. What percentage of development for Tiger has
> > gone into improving Windows L&F fidelity?
> >
> > Not enough! Seriously though, it was likely around
> > 20%.
>
> I say that's not bad, and Tiger shows some nice improvements, like tab rollovers.
>
> > > 6c. What percentage for Mustang?
> >
> > More than tiger! We've already done a significant
> > amount of work to
> > better position ourselves for Longhorn.
>
> I'm curious, what changes does Longhorn bring to XP styling? It uses
> the same theme engine, right?

We've completely rewritten how we do XP stying to take advantage of
native APIs. In theory this should mean we'll look real good on
Longhorn.

> > > 6d. If not, what is the Swing team working on that
> > prevents more development going to the Windows L&F?
> >
> > Hopefully my previous answer will appease you to some
> > degree. But we
> > are doing more, and realize how important this is to
> > the community.
>
> I'm glad the team feels this way but it doesn't answer my
> question. I am curious about what the Swing team works on, since it
> appears that aside from Ocean and Synth & GTK LF, not much in Swing
> has changed since 1.4. I am also curious, how many developers work
> on Swing? How many does Sun employ directly as full time Swing
> developers? (I do not include JDNC, which I understand has taken
> some Swing developers.)

Ocean, Synth and GTK were huge projects that soaked quite a bit of the
team. We also did text printing, some performance work and a whole
slew of bug fixs. Engineering wise we're around 13 people.

> > > 8. Do you plan to release the source code for
> > Windows L&F, so people
> > > like Brian Duff (of WinLAF project) and myself can
> > improve it
> > > ourselves, and bundle our improved version with our
> > applications?
> >
> > We've kicked this idea around, but because of
> > dependancies you would
> > only be able to build it on the latest J2SE. In
> > other words it
> > wouldn't be of much benefit.
>
> Can you describe these dependencies briefly? What do you mean, you
> could only build it on the latest J2SE?

Sure thing. The Longhorn work I referred to previously required
native changes in AWT that Windows will call into. This means you can
only compile the windows look and feel on the latest J2SE builds.
Other changes happen too, like adding methods to Swing proper that
require support in the plaf classes.

> If you mean there would need
> to be a different version for each J2SE release, I think that would
> be acceptable, considering there have been only six releases of
> 1.4.2, and one release of 5.0, in the past year or two.

It's more than that. It's that to build the current windows look and
feel you need to have the latest JDK, which isn't generally
available.

> I have another question: What can I and other members of the Swing
> users community, do to help Swing? The WinLAF project is a start,
> but is there anything else that you think could be done?

Glad you asked! There are a number of things, depending upon your
goals:

. Make sure bugs are filed with suggested fixs! This is a tremendous
help to us. Various people have commented this is currently too
hard. We're looking to streamline this process.
. Advocate, including blogs, and support Swing on the forums and
newgroups!
. Join the various open source projects that have spun up like JDIC
and JDNC. Parts of these will roll back into J2SE.
. Write articles. We are more than happy to post good articles on
java.net.

-Scott

keithkml
Offline
Joined: 2003-06-10

> So, are you aware of people leaving Swing for SWT?
> Have they actually
> deployed SWT applications?

You and I live in different worlds, I don't write code for a living, so if you're asking if Sun customers are switching to SWT, I don't know. I do know that popular programs like RSSOwl (Newsreader) and Azureus (File sharing client) use SWT exclusively.

> We've completely rewritten how we do XP stying to
> take advantage of
> native APIs. In theory this should mean we'll look
> real good on
> Longhorn.

It's interesting that XP L&F will use native API's. I wonder, are there plans to, similarly, use the native Windows font rasterizer to render text to be painted on buttons, labels, etc.?

> Sure thing. The Longhorn work I referred to
> previously required
> native changes in AWT that Windows will call into.
> This means you can
> only compile the windows look and feel on the latest
> J2SE builds.
> Other changes happen too, like adding methods to
> Swing proper that
> require support in the plaf classes.
>
> It's more than that. It's that to build the current
> windows look and
> feel you need to have the latest JDK, which isn't
> generally
> available.

I think I misunderstand something, why couldn't I compile Windows L&F for J2se 5.0 against the JDK 5.0?

These native hooks and modifications to Swing could not be opened as public API's?

Thanks,
-Keith

Scott Violet

On Thu, Nov 04, 2004 at 07:02:33PM -0500, swing-feedback@javadesktop.org wrote:
> > We've completely rewritten how we do XP stying to
> > take advantage of
> > native APIs. In theory this should mean we'll look
> > real good on
> > Longhorn.
>
> It's interesting that XP L&F will use native API's. I wonder, are
> there plans to, similarly, use the native Windows font rasterizer to
> render text to be painted on buttons, labels, etc.?

It's being talked about, but that is a question the 2D would be better
at answering.

> > Sure thing. The Longhorn work I referred to
> > previously required
> > native changes in AWT that Windows will call into.
> > This means you can
> > only compile the windows look and feel on the latest
> > J2SE builds.
> > Other changes happen too, like adding methods to
> > Swing proper that
> > require support in the plaf classes.
> >
> > It's more than that. It's that to build the current
> > windows look and
> > feel you need to have the latest JDK, which isn't
> > generally
> > available.
>
> I think I misunderstand something, why couldn't I compile Windows
> L&F for J2se 5.0 against the JDK 5.0?

I assumed you were asking for us to open source the windows look and
feel. If we did that it would mean either the windows look and feel
couldn't use new APIs in the JDK until the JDK ships, or you couldn't
compile it because it depends upon APIs not yet public.

> These native hooks and modifications to Swing could not be opened as public API's?

Certainly, but we typically only do this for parts of the platform we
think aren't generally useful.

-Scott

Phil Race

Scott Violet wrote:
> On Thu, Nov 04, 2004 at 07:02:33PM -0500, swing-feedback@javadesktop.org wrote:
>
>>>We've completely rewritten how we do XP stying to
>>>take advantage of
>>>native APIs. In theory this should mean we'll look
>>>real good on
>>>Longhorn.
>>
>>It's interesting that XP L&F will use native API's. I wonder, are
>>there plans to, similarly, use the native Windows font rasterizer to
>>render text to be painted on buttons, labels, etc.?
>
>
> It's being talked about, but that is a question the 2D would be better
> at answering.

It has been talked about where buttons, labels are probably the extent
of it (the etc can't as easily include editable text). But we are also
looking at generally making rendering improvements and fixes that may
bring us close enough to windows that its moot. That's to be seen.
One other issue is the surface swing draws on has to be one the GDI
text APIs can access without slowing things down (ie stalling graphics
acceleration).

-phil.

keithkml
Offline
Joined: 2003-06-10

> >>I wonder, are
> >>there plans to, similarly, use the native Windows
> >>font rasterizer to
> >>render text to be painted on buttons, labels, etc.?
>
> > It's being talked about, but that is a question the
> > 2D would be better
> > at answering.
>
> It has been talked about where buttons, labels are
> probably the extent
> of it (the etc can't as easily include editable
> text). But we are also
> looking at generally making rendering improvements
> and fixes that may
> bring us close enough to windows that its moot.
> That's to be seen.
> One other issue is the surface swing draws on has to
> be one the GDI
> text APIs can access without slowing things down (ie
> stalling graphics
> acceleration).
>
> -phil.

I don't think rendering improvements could ever correctly emulate Microsoft's ClearType algorithm, without violating patents and reverse engineering clauses in license agreements. There are settings which allow you to fine-tune the algorithm, optimizing for different displays and things like that. These would be difficult to emulate.

About the rendering pipeline, I think most users would prefer slight performance decrease (by drawing text through WinAPI to temporary in-memory bitmap, in the worst case, then rendering that bitmap to the screen), over the sort of ugly non-antialiased font rendering we have now. What do you think about this?

I would like, at some point when I have enough time, to write a Graphics wrapper which uses native Windows text functions for drawString, and possibly for TextLayout operations, and things like that. Do you have ideas for how I could implement this?

cowwoc
Offline
Joined: 2003-08-24

Time for me to put in my 2 cents...

First, Scott you mentioned neither AWT nor SWT will ever look truely native. I am wondering how you could make such a statement for SWT.

Let me first state where I stand. I have never used SWT but one thing is clear to me: we should not be trying to play catch-up and emulating the Windows L&F using lightweight components. Not only is this a huge waste of resources but also you will not be able to support plug-ins that people might install into Windows. For example, ClearCase installs context-menus to the file browser so when you right-click on a folder you get a ClearCase option for it. This is something that you will never be able to emulate/handle using the current architecture.

I think, for the sake of everybody, we need to consider taking the best out of SWT and the best out of Swing and making some compromises. You guys obviously know more about this topic than I, but my bottom line is: stop emulating, start using native components when they are available. I don't care how you do it, but do it.

Honestly, I am more concerned with the amount of human resources that will be freed up (to do more important things) than any specific L&F bug this would fix. There are just too many other more important L&F fixes I'd love for you guys to look at :)

What do you think?

Gili

Scott Violet

On Fri, Nov 05, 2004 at 01:27:32AM -0500, swing-feedback@javadesktop.org wrote:
> Time for me to put in my 2 cents...
>
> First, Scott you mentioned neither AWT nor SWT will ever look truely
> native. I am wondering how you could make such a statement for SWT.

My point is that there is a lot more to an application looking truely
native that just the widgets. To make a truely native app you need to
use icon sizes and icons that match the platform and follow the visual
design guidelines for the platform. So that by just using SWT, or
Swing's windows look and feel your application will not necessarily
look truely native.

> Honestly, I am more concerned with the amount of human resources
> that will be freed up (to do more important things) than any
> specific L&F bug this would fix. There are just too many other more
> important L&F fixes I'd love for you guys to look at :)

I'm not going to wade into an SWT vs Swing debate. Those typically end
up in mud slinging with no one feeling good.

-Scott