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.
|Summary:||Allow to show in navigator elements from extended class|
|Product:||editor||Reporter:||Petr Pisl <ppisl>|
|Component:||CSL (API & infrastructure)||Assignee:||Svata Dedic <sdedic>|
|Severity:||blocker||CC:||emononen, mkrauskopf, phejl, pjiricka, rmatous|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Attachments:||Patch to be able to add custom filter in navigator (gsf part)|
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.