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.
CVS UI spec author requires to HTMLze editor tab name to match explorer HTMLzation of respective file. Editor should setName() of it's top components by taking node.getHTMLDisplayName() and listen on further changes.
It's covered by CloneableEditorSupport ("CES") class. 1. it seems that it's protected void updateTitles () must be called from newly established FileStatusListener 2.and most common implementations of protected abstract String messageName () namely in DataEditorSupport reimplemented to return annotated name (inluding HTML markup). It's transitive from CES.Pane.updateName(). There is only one CES.P.uN() implementation CES itself. It's fishy, please suggest bullet proof approcach if known. 3. TopComponent.setName() and setDisplayName() must accept HTML markup and render it properly. (It works this way. Otherwise one must fill a bug that TopComponent can not be named "<html>test". :-)
I'll provide prototype impl that follows above crude design (me and mmetelka could not figure better).
In reality whole impl goes into CloneableEditor. And it has new dependency on FileSystem API and DataSystems API.
Created attachment 21719 [details] Patch that follows inital design
Jardo, please comment on, possibly indentifing better starting point.
Patch works except deserialization use case. No fileobject can be located.
Created attachment 21726 [details] v2 that eliminates (cyclic compile time) loaders dependency
openide.patch depends on issue #58041 review.
Where is your spec? Without actually trying to build the bits with your patch, there used to be such a TC title rendering and it was removed because of usability. Nobody wants to see "MyUberSuperClass.java [Locally modified]" in the TC title and if your change is about this, I'm going to vote strongly against it. Generally, the simplies way of making the TC titles the same as nodes DN's is a very small change in the DataEditorSupport without all the hassle and API you're doing here. It was there but was removed because of the above mentioned issue.
For spec contact jrojcek or see linked issues above. Regarding inital patch I was looking for most generic place. I know the code was here, but me and mmetelka were not able to find it. Later jtulach speculated it used to be in window system or ... Could you point me to yout patch? Thank you.
Petr, Jano is there any progress? Is is solvable using current APIs (FileSystem.HtmlStatus) or do we need to introduce an EditorTabAnnotator? Plan was to address it till 20th May 2005. Thank you!
Sorry I'm way too busy this week to actually work on this issue. Jano, how often (when) are the nodes going to have some textual attachement (like "[Locally modified]")? What is your view on sharing the same text/visualization between nodes and editor tabs?
Jano could you sketch plans with explorer nodes annotations, please?. Petr needs it to make a decision if new EditorTab annotation API is needed or whether we can reuse Filesystem annotations. Suggested reply: No long textual annotations are planned so far. If HIE changes this decision you can always introduce new API and rewrite all clients.
CVS-light doesn't use textual attachments like [Locally Modified] in Project window. There are no plans yet to introduce them. We might do it if users really want it, though. The UI spec now only mentions that the same colors as in the project window should be used to annotate tabs in the editor. http://ui.netbeans.org/nonav/docs/hi/promoF/vcs-spec.html#Projects_Window Beware that the old VCS module would likely be present in the IDE as well for promoF!
Implemented by using node's HTML display name. openide/loaders/src/org/openide/text/DataEditorSupport.java,v1.23 Note: some modules/editors override the mechanism explicitely because of previous behaviour (e.g. properties). They'll need to be fixed.
It does not work for forms (was catched by original CloneableEditor patch) and properties. I'll fill issues blocking this one.
problem 1: the only annotation display options that seem to work right are 'full' and 'none'. the others seem to just display the same as 'full' (i'm using the subversion plugin so maybe the problem is there). problem 2 (windows): when trying to select a tab from the drop-down menu, mousing over the items in the menu now causes the file names to disappear. only the annotaions are visible. request 1: saving screen real-estate is important everywhere, but in some areas it's even more important. for example, i don't mind the annotations in the project/files/favorites windows, but they simply take up way too much room on the tabs. there needs to be a way to specify where annotations show up or this 'enhancement' is more of a nuisance than a benefit. now i can't use annotations at all. request 2: while the annotion information is useful enough to need a way to display it easily, it is not useful enough to need to see it all the time. how about adding a 'place annotation in tooltip' option where you see the annotation in the tooltip when you mouse over an item? it's a good compromise as it saves the space and makes the info readily available. i reopened this bug because the problems (especially problem 2) are probably related to how this was implemented. if i should instead move this stuff to separate bugs, let me know.
Ad problem 1: Subversion will need to adjust its patterns to work optimally. Ad problem 2: Works for me, anyway it would be a separate problem - a winsys bug unrelated to this change (i.e. it would be broken for other TCs as well). For requests: The annotations will be different, see the UI spec. The request was to "follow data nodes rendering". Anyway, it used to be possible to modify the annotation pattern even for old VCS modules (profile based). Try changing your annotation patterns.