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.
Having usage data for QuickSearch from gesture collector would significantly help with future evolution of this feature towards being user friendly and efficient to use. Useful data would be: 1) statistics on typical position in the list for selected item and length of typed string at the time of selecting one item 2) statistics on how much each category of results is used 3) Information about ratio of successful/unsuccessful searches (successful search ends with user choosing an item from the list, unsuccessful search ends with ESC (switching focus without invoking any item from the list). Statistics on unsuccessful searches would help to find out what people frequently search for and provide them these results. 4) how many users do use the feature 5) how often - ideally median and other statistics indicators (1/4, 3/4, 1/10, 9/10)
I've just realized that this is yet another way to invoke actions, and that we log all action invocations. That is why it is sort of bug that this new way is not using logging. Please look at org.openide.awt.Actions to see how the logging is done and into appropriate arch.xml to see how it is documented. Add new key to distinguish the invocation style, document it here, please: http://wiki.netbeans.org/UILoggingInPlatform Then it would be also nice to get main/misc logger/uihandlerserver and update Gestures and Actions statistics to recognize and handle this new LogRecord.
this one a bug? :(
Sorry, but IMHO this is not a bug, changing back to enhancement.
Well .. i would say it is a bug, but in relation to Gesture collector, which is not part of standard distribution of NetBeans IDE. So hard to say how to classify. Anyway, I have a question. Will at least invocation of QuickSearch be tracked as a invocation of standard action, i.e. will quicksearch invocations (i don't mean invocations of other actions through quicksearch now) be available in the action statistics?
My understanding: If action is invoked through gesture collector and it throws exception, this exception does not get reported through the logger module. If my understanding is correct, I do think this is a bug.
Both exceptions and actions invoked via QuickSearch are not reported and skewing the statistics ... raising priority, in order to base UI and shortcut decisions on solid basis, we need complete data.
Hello, can I kindly ask what am i supposed to do? This issue is now mixture of original enhancement and current findings which you marked as P2 bug, so I'm pretty confused. a) Should I add logging of action invocation like jtulach described? I guess yes... b) What does it mean to log exceptions from action invocations? We actually don't want to show these exceptions, we want action just silently fail in such case instead of throwing an exception on the user. The reason is that actions were not designed to be invoked in "QuickSearch" way and they can fail anytime, anyone - but for vast majority it's luckily not the case. c) Original enh request is unfortunately out of my abilities, am I'm getting older I'm losing ability to understand complex systems.
Well .. this issue become sort of a mess ... let me split this into three cases for clarification (3 separate issues). a) [Issue #161062] Actions invoked via quicksearch (including the invocation of quicksearch action itself) are not included in the logs from gesture collector. From my viewpoint, this is a serious problem skewing the statistics (which are used for UI decisions regarding shortcuts, menus, etc .. ). b) [Issue #161063] When actions invoked through quicksearch fail, the exception is not reported. To me this seems like a bug too, but I'm not sure what to do with the actions failing just BECAUSE they are invoked by quicksearch. c) [This issue] Some additional statistics would be helpful (this is the original plan of this issue). Just an enhancement which would allow us to provide better Quicksearch experience through knowing what our users typically use QuickSearch for.
OK, thanks.