'Read Man Pages' plugin makes Gnome-Do unresponsive
Bug #325935 reported by
Parthiban Balasubramanian
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Do Plugins |
Fix Released
|
Low
|
Chris S. | ||
Bug Description
Summon up Do and start typing man.... and Do becomes unresponsive (with the 'Read Manual Pages' action highlighted), and CPU usage spikes up. OTOH if you type out say 'perl' and tab over to select the 'Read Manual Pages' action, it works just fine.
BTW this kind of behavior is also seen with the Window Management Plugin (https:/
| Changed in do-plugins: | |
| importance: | Undecided → Low |
| status: | New → Confirmed |
Revision history for this message
| Chris S. (cszikszoy) wrote | #1 |
| Changed in do-plugins: | |
| assignee: | nobody → cszikszoy |
| Changed in do-plugins: | |
| status: | Confirmed → Fix Committed |
| Changed in do-plugins: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
The problem here is that the manlookup function has a _very_ hungry method for SupportsItem.
When you type man in the first pane, do has to run this function on every type of SupportedItem in the universe, which in this case is an ApplicationItem, ManualPageItem, or TextItem.
I think the logical thing to do here is move this function and don't check every supported item in the universe right away. This method could be moved to Perform, so that when the man page action runs, it will have to check if that application has a supported manual.
Worst case scenario: the plugin will try to find a man page for an application that doesn't have one. Here we could just politely inform the user that the is no man page for that application.
I'll mess around with it a little later.