This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Impossible to create custom UI delegate for TabbedContainer | ||
---|---|---|---|
Product: | platform | Reporter: | kirillcool <kirillcool> |
Component: | Window System | Assignee: | issues@platform <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dsimonek, mkrauskopf, mmirilovic |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 150393 | ||
Bug Blocks: | |||
Attachments: | Screenshot of tabbed container under Substance LAF |
Description
kirillcool
2005-10-09 15:08:57 UTC
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. 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. |