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 150084 - Allow to show in navigator elements from extended class
Summary: Allow to show in navigator elements from extended class
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: CSL (API & infrastructure) (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Svata Dedic
Keywords: API
Depends on:
Reported: 2008-10-14 12:32 UTC by Petr Pisl
Modified: 2015-01-14 14:07 UTC (History)
5 users (show)

See Also:
Exception Reporter:

Patch to be able to add custom filter in navigator (gsf part) (9.57 KB, text/plain)
2008-12-16 17:51 UTC, rmatous

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisl 2008-10-14 12:32:10 UTC
Similar to java. User should be able to see also elements from the extended classes.
Comment 1 rmatous 2008-12-16 17:51:50 UTC
Created attachment 75048 [details]
Patch to be able to add custom filter in navigator (gsf part)
Comment 2 rmatous 2008-12-16 17:53:35 UTC
Filter for inherited members would be needed at least for php.

I provided patch to be able to add custom filter. Please, review my patch && comment.  
Comment 3 David Strupl 2009-01-14 14:35:19 UTC
Moving from ruby/GSF to editor/CSL. Step one: assign to myself ;-)
Comment 4 David Strupl 2009-01-14 14:42:28 UTC
Step 2: trying to make the owner not myself but the owner of the subcomponent.
Comment 5 rmatous 2009-05-29 10:00:21 UTC
I would like to see this issue fixed because we would like to add at least one additional filter for showing inherited
members. The proposed patch was just my proof of concept. 

Someone else supports it?

See also related issue #150413
Comment 6 Erno Mononen 2009-05-29 19:59:33 UTC
This would definitely be useful in Ruby too.
Comment 7 rmatous 2009-08-12 15:18:48 UTC
Could you please implement it for 6.8 
Comment 8 Vitezslav Stejskal 2009-08-12 20:58:21 UTC
IMO this is conceptually wrong. The ability to show/hide various elements in the navigator should not be implemented as
a filter. Instead the task (eg. StructureScanner) provided by languages should be given the set of flags that would
control what elements it should provide. Less elements mean less work. The filters approach means that the task has to
compute everything (all possible elements) and later on many elements will be thrown away when the filters are applied.

Also these flags have to be unique across all languages, because the navigator can show elements from many languages
(eg. embedded in a single file). Therefore each language specific task has to be ready to ignore flags that it does not
understand and apply those that it does. The navigator UI has to show the union of all flags plugged in by all languages
in the current file.

Marku could you please investigate this a little bit. I have no idea how much work this would be and if this is doable
in 6.8 timeframe at all. Thanks
Comment 9 rmatous 2009-08-12 21:57:54 UTC
Agree, flags instead of filters, not compute everything!

We would need our own flags, presented by our own icons, our impl. of structure scanner would behave according to flags
in signaled state. For 6.8 we would add 1. flag for showing inherited class members && 2. flag for showing variables
global/local(inside methods|functions) variables - thus this issue is loosely coupled to #150084.
Comment 10 Petr Pisl 2015-01-14 14:07:23 UTC
This is still not done. We need for json / js also our flags / filters place into navigator.