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.

Bug 32484 - org.openide.awt.Toolbar is not initialized when not visible
Summary: org.openide.awt.Toolbar is not initialized when not visible
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Strupl
Depends on:
Blocks: 32488
  Show dependency tree
Reported: 2003-03-29 00:19 UTC by David Strupl
Modified: 2008-12-22 15:46 UTC (History)
5 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2003-03-29 00:19:49 UTC
private static final boolean FORCE_INIT =
    private void doInitialize() {
	if(processor == null && (isVisible() || FORCE_INIT)) {
	    processor = new Folder(); // It will start
tracki ...

I suggest to add the FORCE_INIT part to the
doInitialize to be able to force the
initialization even in case the Toolbar is not
visible. The ratianale behind this is when I
construct the contents of toolbar equivalent based
on the original toolbar (the normal toolbar not
being visible) I need to have the toolbars up and

Would there be any objections against such a change?
Comment 1 Peter Zavadsky 2003-03-30 09:27:35 UTC
In fact, I would expect toolbar content creation isn't dependent on
whether it is visible or not. Thus the switch wouldn't be needed.

Passing to correct subcomponent.
Comment 2 David Strupl 2003-03-30 16:34:17 UTC
Do you mean just to delete the isVisible() ?

If so that is even simpler change than my change. Can I go ahead and
do it in the trunk?

I suspect the isVisible being some sort of performance optimalization
(for example when there are no toolbars at all). Cc-ing also pnejedly.
Are there any other suggestions what can be done if the system
property approach is too ugly? 
Comment 3 Peter Zavadsky 2003-03-31 08:56:39 UTC
I wasn't looking into code.
 I just talked generally, that the creation of those components
shoudn't be dependent on whether some another one (their parent) is
visible on screen or not). 
The control over it should be more powerfull, I considere the current
state as accidental one (=not good).
Comment 4 David Strupl 2003-04-02 20:21:43 UTC
On branch platform_32247:

Checking in;
/cvs/openide/src/org/openide/awt/Attic/,v  <--
new revision:; previous revision: 1.76
Comment 5 Petr Nejedly 2003-04-03 15:52:35 UTC
NO! The behaviour is intentional.
If the toolbar is not used, why it should be parsed/created?
User can have tons of toolbars preconfigured and while he's not
using them, why waste memory?
It is not based on the status of the parent, it is based on the status
of the Toolbar instance itself.

Examples in current IDE: DebuggerFull, Memory

You're creating another visualization of toolbars, right?
Do you think creating visualization over visualization is reasonable?
Why don't you just use your own FolderInstance over the defining
folder? Actions will be the same (they are singletons), DOs below them
will be the same, and you'll get your *own* presenters immediatelly.

Comment 6 David Strupl 2003-04-03 20:34:54 UTC
You are of course right - I could write the whole thing myself. But
when there is code constructing contents of toolbars (JButtons or
whatever they are) I can use directly those objects in another
visualization. No need to copy the code that creates the components
from the content of SFS. This is one line change that turns off the
optimalization instead of supplying anything between 100 and 5000
lines of code as you suggest. I might resort to writing (copying) the
code but that will take a while.
Comment 7 Peter Zavadsky 2003-04-07 08:42:51 UTC
What does it mean toolbar isn't used?

If somebodye wants it then she should get it, she probably wants to
use it, whatever thing she needs to do with.
 It doesn't have to do anything with lazy init. It doesn't beak it.

I don't think that it is tied up to persistence so much is a good thing.
Comment 8 Petr Nejedly 2003-04-07 15:25:14 UTC
Look, one side of the problem is this:
You can have several workspaces, and each can have different *set* of
the toolbars, but the toolbars themselves are shared.
There is only one memory toolbar, and it can be independently enabled
on each workspace.
Now, if I have 20 toolbars but at most 3-4 enabled on each workspace
(some products based on nb are made this way), I really don't want
all 20 of them to paprsed/prepared during displaying the first
workspace although I need all of them modeled.

Now, it can be rewritten to compute the content (parse the folder) on
demand, but it is currently implemented inside-out - the
FolderInstance just maintains existing instance of Toolbar.

I don't think it is optimal, but removing the toolbars optimalization
is unacceptable as well.
If you wish, you can rewrite the toolbar code to be e.g. yielding List
of components on demand.
Comment 9 Peter Zavadsky 2003-04-10 12:31:48 UTC
I'm not talking about removing optimization, it has sense what you are
talking about that of course.

But I have something different in mind. It is a better control over
the components creation/manipulation for client programmer.

I.e. if she wants the components and requests them, she has to get
them, even not shown yet. 
(To get idea that it doesn't break optimization, there could be a
method which will parse & create only enabled components).

In my case:
What I want to get is that I (as a client) could get components, then
I could manipulate them as I want, put them into AWT hierarchy where I
want, and also adjust them (e.g. sizes) in an typical Swing manner as
I need. And just then to show them whenever I decide.

I don't need such a components that do all those things out of my
Comment 10 Jaroslav Tulach 2003-06-11 08:48:15 UTC
David, I guess you should also update arch-*.xml to document this
property, before marking this as fixed...
Comment 11 David Strupl 2004-02-07 22:28:06 UTC
We have written our own toolbar - no need for this change to go to the
NB codebase. It is probably invalid since as Peter pointed out we
should not misuse the components of the original toolbar.