Bug 66335

Well, but it is as designed. The code is not designed for extensibility to other
UI delegates (which is btw complicated task, believe me) and I doubt it will
ever be, currently we have no plan to support it, simply because this library
was intented primarily as private use-only-in-IDE library and we can't afford to
maintain it as public extensible library with nice API. Too little effect for
too much work for us, sorry.

I guess you'll have to extend BasicTabDisplayer and copy the code you want to reuse.

Created attachment 25756 [details]
Screenshot of tabbed container under Substance LAF

I've attached a screenshot of how it looks like under Substance LAF. Eventually,
i had to go the path you suggested, taking Metal implementation and copying it.
I strongly disagree that it's too little effect since NetBeans *is* a Swing
application, and custom components should have clean API for external LAFs (the
code is such a mess really).

What about the licensing issues on copied code?

I meant too little effect purely from IDE viewpoint, we must concentrate on
standard LFs, we generally don't support custom LFs.

Licencing - all code is under SPL licence, so please refer to it. But it is
fairly open licence, so I expect you'll have no problems.

I'm not saying that you must provide support for all LAFs out there, but the UI
delegates should be flexible enough to provide custom extension points for
relevant graphics tasks. For example, when i wrote TabbedPaneUI, i inherited
from MetalTabbedPaneUI and overrode paintTabBackground() function - that's all i
needed, not layout, not tab cell renderer.

I would expect the same from NetBeans components. Provide clean extension points
and hide the plumbing inside. I guess it's not of high priority to you :(

Reopening

For starters, all the UI delegates for tabbed container should derive from the
same base class that contains all the common code. There's a lot of code
duplication in WinClassic / WinXP / Metal / Aqua delegates. In addition, nothing
that can be used by custom delegate should be left package protected (such as
controller).

The base class should contain all the painting logic as protected functions. The
functions should be:
1. Paint tab.
2. Paint left-clipped tab.
3. Paint right-clipped tab.
(the above shouldn't be delegated to the tab cell renderer. They aren't in Swing
JTabbedPane, so why should they be here).
4. Paint close button on tab.
5. Paint all tabs (JGoodies paints the selected tab last as they use overlapping
tab polygons).

The current state of things (a lot of duplicated code and a very misleading
implementation of tab cell renderer) creates a very high-maintenance code. I
only wanted to implement custom background painting. It took me a lot of time,
and a lot of code-copying to do this. In addition, since i've copied SPL code, I
can't use BSD anymore. It doesn't matter to me, but it can to other LAF developers.

And assigning to myself.

If Kirill can let us know the *minimal* set of changes to do what he needs to do
(it sounds like just making the Controller class public would do it), there's no
reason to completely shut the door to other look and feels being usable with
NetBeans.

Yes, the stuff in org.netbeans.swing.plaf should be cleaned up (I think it is
only listed as a public package to avoid classloader problems with instantiating
the UI delegates) - and there should be a way to just provide a background
painter object or such.  In the meantime, if someone creating a look and feel
wants to develop a custom UI delegate, well, it won't be easy but we shouldn't
make it impossible.

Agreed that it would be nicer if the code was common between view and editor
tabs, in fact, I agree with everything you're saying.  What you're looking at is
more artifacts of the history of how the stuff in this package was developed
under a lot of deadline pressure, rather than any really planned API.

Re the cell renderer approach, what I'd like to do long term is have some kind
of "painter" class that is the only thing different across different look and
feels.   

The question is where to trade off flexibility for simplicity:  It would be easy
to just drop in a painter - but in the case that, for example, you want to
provide a different layout (like stacked rows of tabs), that should be possible
independent of the "painter", but some communication is needed so that the
painter can know which row it is painting.  Then there is the question of
wanting to be able to add ad-hoc buttons or regions to a tab.

Re JTabbedPane not using the cell renderer approach, IMO, that's a bug. 
JTabbedPane is kind of a disaster area - that's the reason this class exists. 
JTabbedPane is fine for what it does, but there were a whole bunch of
requirements we had that would have been required massive amounts of hackery
that would have probably broken across JDK revisions, such as:
 - Support for close and other buttons (now more doable in 1.6 if you use
labels, but we can't use 1.6)
 - Scalability - the ability to potentially have a huge number of tabs (i.e. you
don't necessarily want to have any instantiated content for a tab until the
first time it is displayed)
 - Atomic discontiguous updates to the model - the ability to
change/rearrange/add/remove a whole pile of tabs without doing huge amounts of
calculations until the first subsequent repaint
 - Separation of the control with the tabs and the displayer, so it's possible
to have a control that just shows tabs by themselves (the property sheet uses
this when used in the form editor)

I think what we should do for now is to do the minimum necessary to make
substance and other L&Fs able to effectively do delegates using what's there now
- if we try to save the world and redesign the whole thing, it will take a very
long time.

The bare minimum for the view tabbed container would be to make the Controller
class in AbstractViewTabDisplayerUI protected (instead of package private).
Currently, the only way to circumvent this is to copy the
AbstractViewTabDisplayerUI and few other classes to a custom LAF package and use
them there. The suggestion of extending the BasicTabDisplayer is not a trivial
task to do - see the amount of code in AbstractViewTabDisplayerUI.

Can this be reassigned back to an active developer so that we can get a decisive
and conclusive answer on NetBeans support for third-party look-and-feels?

Putting this back into an active queue for the component owner decision

Friendly reminder to Netbeans developers: while Netbeans the IDE may do fine without supporting for 3rd party LAFs,
Netbeans the Rich Client Platform should IMHO have that support. We have a 5.0-based Platform application and are
currently using Substance. Whatever makes additional LAFs easier to integrate is a plus for the platform.

Friendly reminder to Netbeans developers: while Netbeans the IDE may do fine without supporting for 3rd party LAFs,
Netbeans the Rich Client Platform should IMHO have that support. We have a 5.0-based Platform application and are
currently using Substance. Whatever makes additional LAFs easier to integrate is a plus for the platform.

FYI: http://www.pushing-pixels.org/?p=429

A comment not related to this Issue.

I think Swing and custom look and feel is a BIG reason why I choose NetBeans instead of Eclipse. Eclipse is much fast
and stable than NetBeans except for some out of box features such as J2EE/EJB (EJB3) application developement (but J2EE
applciation is not so popular these days, isn't it?), but I don't like SWT, the same looking on any platforms, and I
can't change the look and feel.

SUN CEO always talks about Open source and community, if NetBeans as a Swing application (it's a designed badly, most of
Swing applications such as JEdit and Squirrel SQL can use a third party LnF library just by adding it to class path and
set a UI class) and it can't support third party LnF, when where is the community?

SUN has a good tradition to save a horse when it is dead. For example, if Solaris is open sourced in 90's, then where is
Linux? Sun has made many conflict decision from not support X86 Solaris to X86 Solaris as primary at present. Now
Solaris is open sourced finally but every body used Linux who cares about Solaris?

Now there is two camp of open source Java(and other language) IDE, NetBeans and Eclipse, I reckon NetBeans had done a
good job since 5.0/6.0, but it is still not as popular as Eclipse in Enterprise. (For me, I have to use Eclipse at work
because our Department has standardized Eclipse as IDE, I only used NetBeans at home) Please don't save NetBeans when it
is dead, save it now.

For me, as a Netbeans and Substance user, I am very sad that Substance NetBeans Plugin will discontinued because
NetBeans don't give good support for third party look and feels. 

waynezhang, while I agree with most of what you had to say, situation is difficult for us. Turning TabbedContainer into
real reusable Swing component with small easy API for extending to 3rd party L&Fs is not an option because of resources
and less importantly also priorities.

However, maybe that implementing 150393 enhancement which I filed is the way to go.

issue #150393 is fixed so it's possible to switch the whole IDE (or platform app) to plain Swing JTabbedPane implementation of tabs which uses the default look and feel.