Find ich auch.
Besser alle Hersteller von Gui Toolkits sollten sich auf möglichst konsistente Usability Guidelines einigen. Besser man fokussiert sich darauf, den Speicherbedarf von Notes on Eclipse zu senken.
In dem Redbook zu Composite Apps ist viel von einbetten von Eclipse SWT/JFace/etc Komponenten die Rede. Da muss dann jedesmal bei eigenen Fenstern der doppelte rechte Mausklick implementiert werden. A) kann das schnell vergessen werden und B) gibts vielleicht Komponenten-Anbieter, die das auch schnell nicht berücksichtigen, da ihr Primärmarkt vielleicht in Eclipse RCP Anwendungen insgesamt liegt und Notes on Eclipse vielleicht nur 5% ihres Gesamtmarkts ausmacht.
In Java Server Faces gibts für Views 2 dominierende Implementierungstechniken: Java Server Pages und Facelets. Facelets setzen haben weniger features, aber auch weniger Fallen für Entwickler. Facelets setzen sich durch.
Man sollte sich bei Notes on Eclipse auf wenige Dinge fokussieren:
1. geringerer Speicherbedarf und nein das ist nicht "wegen Java". Der Speicherbedarf für Sachen wie Netbeans ist nämlich z.B. eher gesunken.
2. Möglichst kompakte Tools für Entwickler. Im Composite Apps Redbook les ich da von dies Plug-in und das Plug-in.
Letzteres hab ich auch mal anders gesehen. Aber aus Erfahrung nehme ich heute auf jeden Fall eine plug-in Sammlung wie myEclipse (für ca. 80 € p.a.) oder in Zukunft sogar Netbeans.
Ist nämlich immer schon so gewesen in diesem Theater: Die wirklichen Projektrisiken liegen in den Schnittstellen. Wenn diese Brücken überraschende Fallgruben bereit halten, dann kannste nur noch den Google-Götzen anbeten, dass da irgendwo dokumentiert ist, wie man aus der Fallgrube wieder herauskommt.
Viel wichtiger, dass sich um Notes on Eclipse eine kompetente Community bildet mit Individuen, die kein Problem haben, ab und an mal in Fallgruben zu stolpern (weil die gibts sowieso) und daraus googlebares Material (oder gute Bücher) erzeugt. Aber mit dem berichteten 2 GB Arbeitsspeicher seh ich da sowieso Probleme. Letztlich gabs bei allen "neuen" Technologie-Hypes, die ich in den letzten Jahren mitgemacht habe, immer eine Phase, in der es darum ging, den Bedarf an Arbeitsspeicher zu verringern und die Reisbrettentwürfe an die wirklichen Bedürfnisse der Projektbeteiligten nach Einfachheit anzupassen. War so bei EJB, Webservices und sogar bei Swing.