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.
The NetBeans IDE has for a long time been called "the only IDE you ever need" due to its support for rich set of various technologies. This remains true, however the NetBeans IDE 7.0 is first NetBeans IDE release which is ergonomic to user needs. The IDE does not throw all the technologies to all its users as soon as it is started. Instead of over-bloating its users with various offerings it lets the users to express their desires and it adjust itself to best suite each individual user needs. As a result the NetBeans IDE is better suited to deliver on its "the only IDE you ever need". We can continue to expand the functionality available in the IDE forever and yet, the IDE still continues to feel and react appropriately to the needs of its individual users. The running IDE process enables only the needed functionality, eliminating bugs and ineffectiveness dragged down from the parts that are supposed to be unused, yet they are activated. We are proud to optimize this all and proud to deliver the first and true ergonomic IDE that fit its user needs forever. See http://wiki.netbeans.org/FitnessForever for more info.
Jesse, Tomáš, Marting and Maroš please be my reviewers. The review will happen on Thursday, Dec 4, 5.30pm-7pm CET as part or after technical counsil. Prague meets in Olympia.
JT, I was looking at Visual Studio and it gave me an idea as well. In Visual Studio .NET 2008 when it starts up no projects are opened. Maybe this could be a default setting which can be changed under options. This makes the IDE start up much faster as it is. The startup page is open in VS.NET and then one can quickly click on a recently opened project. NB works and acts similar when I close all the projects before I close the IDE and restart it. Anyways, that will just help with startup. Is this the correct place for such comments, or is there a better place?
Review result: Approved with TCR and TCAs. Integrate and fix TCR then. Notes: http://wiki.netbeans.org/NB70PerfTCMeeting2 Integrated: 43b54429a0c9
That was very strange. The email that came with the marking of FIXED showed up as WONTFIX in the email. I had to look as I was confused. Now I see it is actually marked as FIXED. Funny.
I meant to come back and add some comments to this and almost forgot. The modules stay activated at all times once activated. Seems it would be better if those things only activated when the user actually wanted to use them. That was what I was expecting it to do when I began testing it out. That keeps the IDE running fast all the time even if the user has just been experimenting and may not ever reuse the PHP, Python, or maybe even the Java or EE support. Too, it seems another step in another release would be to allow the user to easily disable some functionality if it would be possible without a restart. Say they have enabled PHP or Python support to see how it was, and then they wanted to use only Java. Maybe if particular clusters could be linked into some quick pick window that could pop up for things to turn off that might be good, or even if things had a time out. Say the user doesn't use PHP or Python for so many minutes or an hour then it would disable automatically and only re-enable when used. That would be harder I suppose because of data in this or that place, but if Lookup were used well then maybe that would work OK. I don't know, but seems it could do something along those lines to keep it snappy instead of keeping the bloat once it is setup. Perhaps having it startup now with things always disabled would be OK? What happens if a project type is opened when restarted? Then the project support for those particular things could be enabled automatically. Is that possible?
PhantomReferences could be used to track when parts of the IDE are no longer referenced and allow other things to be unloaded. I.e. if you use a particular bit of the system through a proxy object, when that proxy object is released, you'd know that the piece is nolonger needed, and it could be removed from lookups, or otherwise unloaded. I have a simple to use class that makes this pretty easy. I'll attach it to this issue for reference.
Created attachment 75758 [details] ReferenceTracker class
The use of this class is straight forward as long as you understand inner class references to outer classes. The delegate object that is tracked must not be referenced by another object that is outside of the train of references you want to track. class PieceTracker extends ReferenceTracker<IDEObject,IDEPieceToRelease> { public void released( IDEPieceToRelease ref ) { ref.unload(); } } use of this would then be something like the following ... private PieceTracker tracker = new PieceTracker(); ... public IDEObject someFactoryMethod() { IDEPieceToRelease rel = ... init with no reference path to 'o' ... IDEObject o = new IDEObject( rel, ... ); ... put rel into a lookup, or other globally visible place ... tracker.track( o, rel ); return o; } When o is nolonger referenced, released() will be called with rel as the argument, allowing it to be cleaned up.
We're building a standalone debugger, dbxtool. We disable many modules. This was ostensibly done to speed up startup and "cognitive load" on people who just want to debug. The idea of Ergonomics IDE seems like it might help but the set of modules turned off, and the trigger points which are hard-coded in the ergonomics module are not neccessarily suitable for our application. For example we need some but not all modules from CND. I'd just like to confirm that for dbxtool ... 0) we can just not include the ergonomics1 cluster and manage our modules as before. 1) replace or augment the ergonomics module with one suitable for our application. From (1) it almost seems like the declarative scaffolding used by the ergonomics module belongs to branding or some other per-RCP entity and not to the ergonomics module itself.
Hello Ivan, the ergonomics IDE, as is does not separate its API and implementation. Should that be a problem, we join our efforts and fix that. But as that is independent from this issue, I'll reply with more details via email.