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 137005 - Editor context change events dispatching for debugger implementations
Summary: Editor context change events dispatching for debugger implementations
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Entlicher
Depends on:
Blocks: 133682 137011 137013 137014 137015 137016 137018 137019 137022
  Show dependency tree
Reported: 2008-06-11 15:28 UTC by Martin Entlicher
Modified: 2010-04-29 09:40 UTC (History)
1 user (show)

See Also:
Exception Reporter:

The proposed API change. (27.07 KB, text/plain)
2008-06-11 15:39 UTC, Martin Entlicher
The improved version of EditorContextDispatcher according to comments. (30.22 KB, text/plain)
2008-06-13 10:55 UTC, Martin Entlicher

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Entlicher 2008-06-11 15:28:51 UTC
API for efficient event dispatching is going to be added into debugger core.
It's purpose is:
1) to simplify the access to current active elements in the IDE (like current FileObject and editor pane) and
2) to make the events dispatching more efficient - reduce the number of listeners on context switching.
Comment 1 Martin Entlicher 2008-06-11 15:39:50 UTC
Created attachment 62669 [details]
The proposed API change.
Comment 2 Martin Entlicher 2008-06-11 15:41:27 UTC
Please review this API change. Separate issues will be filled for all debuggers to use this new API in order to improve
Comment 3 Vitezslav Stejskal 2008-06-12 06:12:42 UTC
V1: I wonder why getCurrentEditorCookie() is neccessary? You already have methods that return JEditorPane and even the
line number. What else does EditorCookie give you?

V2: Why is getMostRecentEditor() private, but getMostRecentLineNumber() public? Should not they both either be private
or public? I would assume this to be symmetrical to getCurrentEditor() and getCurrentLineNumber().

V3: removePropertyChangeListener(mimeType, listener) is commented out, why?

V4: Some tests could be useful I think. Also it might be useful to describe a typical usage in javadoc, eg. what does
the class track, when are the events fired, who should be using this, etc.
Comment 4 Martin Entlicher 2008-06-12 13:26:31 UTC
Thanks for your review, Vita.

V1: getCurrentEditorCookie() is used to find org.openide.text.Line and current Documet. I've decided to provide just the
EditorCookie and not these derived objects. getCurrentLineNumber() is there just for convenience, since the line number
is the most typical information that is retrieved by all debuggers.

As I go through the usages, it looks like the second most wanted information is org.openide.text.Line, thus I'll
consider to add "Line getCurrentLine()" method and remove the getCurrentEditorCookie(), since Document can be retrieved
from getCurrentEditor(). It's not so nice, since it needs to be cast to StyledDocument and it's not apparent whether
JEditorPane will always contain StyledDocument or not. But if it's so, it can be documented.

V2: getMostRecentLineNumber() is used together with getMostRecentFile(), it's used by C/C++ debugger. Since we plan to
use that concept in JPDA debugger as well, I've realized now that we'll need also getMostRecentEditor() to be public.
I'll change it now so that it does not have to go through API review again in the future.

V3: I've extended removePropertyChangeListener(listener) to remove the listener also for all MIME types, so that it
works fine with WeakListeners. Therefore removePropertyChangeListener(mimeType, listener) became unnecessary, since
typically you need to unregister the listener completely and not from some specific MIME type only.

V4: I'll enhance the Javadoc with better description and usage. I've thought about tests; they would have to be GUI
tests, since we need the events from TopComponent.Registry.

I'll attach a reworked diff with "Line getCurrentLine()" method and extended Javadoc.
Comment 5 Martin Entlicher 2008-06-13 10:55:51 UTC
Created attachment 62797 [details]
The improved version of EditorContextDispatcher according to comments.
Comment 6 Martin Entlicher 2008-06-13 11:03:03 UTC
I've attached the modified version of EditorContextDispatcher. It contains following public methods now:

FileObject getCurrentFile()
String getCurrentURLAsString()
JEditorPane getCurrentEditor()
int getCurrentLineNumber()
Line getCurrentLine()

FileObject getMostRecentFile()
String getMostRecentURLAsString()
JEditorPane getMostRecentEditor()
int getMostRecentLineNumber()
Line getMostRecentLine()

void addPropertyChangeListener(PropertyChangeListener l)
void addPropertyChangeListener(String MIMEType, PropertyChangeListener l)
void removePropertyChangeListener(PropertyChangeListener l)

Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE? (where
JEditorPane comes from EditorCookie.getOpenedPanes(). Thus JEditorPane.getDocument() should be the same as
EditorCookie.getDocument(), right?). Thanks.
Comment 7 Vitezslav Stejskal 2008-06-18 12:06:53 UTC
> Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE?

Strictly speaking it does not have to, but since everybody is using the same implementation of EditorCookie I think you
can safely assume that this always holds true.

> Thus JEditorPane.getDocument() should be the same as EditorCookie.getDocument(), right?

Yes, even though EditorCookie does not enforce it in any way.
Comment 8 Martin Entlicher 2008-06-25 14:09:16 UTC
Thanks for the review.
Comment 9 Martin Entlicher 2008-06-25 14:10:18 UTC
EditorContextDispatcher integrated:
changeset:   86445:6cd01160d4a9
Comment 10 Quality Engineering 2008-06-27 16:11:21 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #285 build
Log: #137005 - EditorContextDispatcher introduced for efficient handling of context change events.
Comment 11 Quality Engineering 2010-04-29 09:40:14 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.