Bugzilla – Full Text Bug Listing
| Summary: | [logview] It's hard to flip between event stack trace and classes listed there. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Jacek Pospychala <jacek.pospychala> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Boris Bokowski <bokowski> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | bokowski, caniszczyk, curtis.windatt.public, darin.eclipse, tonny.madsen | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 217646 | ||||||
| Attachments: |
|
||||||
|
Description
Jacek Pospychala
Editor pros: - shiny forms editor would make even most serious errors look better :) - Event details dialog looks quite sophisticated with all it's buttons. - given we're going to add even more functionality to Event Details, it'd make sense to use editor, as it has more space than crumped dialog. Editor cons: - opening any event details would hide your current work. - what if RCP has editor area disabled - History view is something you do work with, whereas event details dialog is imo just a midpoint to go to problem cause. So I see two ways to go: 1. satisfy developers needs and bring real log behemoth 2. keep RCP integrators happy with small and handy log view. what do you think? My two cents... An editor for the error log feels heavy. We've had similar discussions about the launch configuration dialog, and the end result was always that launch configs stay in the dialog. As well, error logs are *not* intended to be edited - they are a result, not a work in progress. It feels like the wrong metaphor/use of an editor. Navigating stack trace hyperlinks from an editor is not as useable as navigating from a console, as the editors are thrashing with eachother (as you move up/down the trace). It would make more sense to me (and be simpler), to have a way to open an error log stack trace in the existing strack trace console. Less code duplication, and promotes one way of navigating stack traces. (In reply to comment #2) > My two cents... An editor for the error log feels heavy. We've had similar > discussions about the launch configuration dialog, and the end result was > always that launch configs stay in the dialog. As well, error logs are *not* > intended to be edited - they are a result, not a work in progress. It feels > like the wrong metaphor/use of an editor. It doesn't have to be special editor, and simple text editor would work. I think read-only editor is more convenient comparing to modal dialog. In my experience I often have to open stack trace few times to see what is happening down the stack, so switching back to editor would been faster. I've been initially thinking that Log View should have an action to copy stack trace into the Stack Trace Console, but on a second thought it is not optimal interaction, it will require more clicks. With editor it would be 2 clicks to the position in the code (doubleclick on log entry and then click on stack trace). Also, Stack Trace Console don't work too well with multiple stack traces, so you could accidentally lose something important. Besides, number of build tools can generate text files with stack traces (i.e. junit plugins for Ant and Maven) and it convenient to have stacktrace hyperlinking working in those. Actually it is already working really nice if you have Mylyn installed, which provides Platform hyperlink detector for stacktraces in any text editor, but it would make sense to promote it out of Mylyn to JDT or Debug component. BTW, if I am not mistaken, WTP is using editors to work with launch configurations for the web app servers. (In reply to comment #3) > It doesn't have to be special editor, and simple text editor would work. I > think read-only editor is more convenient comparing to modal dialog. In my > experience I often have to open stack trace few times to see what is happening > down the stack, so switching back to editor would been faster. this dialog is actually non-modal. and follows logview current selection. > Besides, number of build tools can generate text files with stack traces (i.e. > junit plugins for Ant and Maven) and it convenient to have stacktrace > hyperlinking working in those. Actually it is already working really nice if > you have Mylyn installed, which provides Platform hyperlink detector for > stacktraces in any text editor, but it would make sense to promote it out of > Mylyn to JDT or Debug component. it doesn't work that well in sourceviewer in a dialog (like in this bug), because hyperlink would also have to close the dialog after himself. Created attachment 88796 [details]
Add open in stack trace console action
This patch demonstrates how easy and effective an action to open the stack trace in the console view could be. By having an action in the view (contributed by PDE, as jdt.debug is needed), it takes only two clicks to get what most developers want.
The developer can just click the action with an error selected to open up the console. Now they can browse the stack trace with ease. If they need to move between multiple bugs, they can leave both the console and log views open beside each other.
Adding a new editor is ridiculously heavy for something as simple as looking at an error. The user isn't going to be editing the error, they just want to get to the root cause.
Warning: The patch is very small, but has changes in jdt.debug, pde.ui and views.log.
Curtis for president! The change seems reasonable and effective. (In reply to comment #4) > it doesn't work that well in sourceviewer in a dialog (like in this bug), > because hyperlink would also have to close the dialog after himself. That won't be an issue when editor will be used instead of the dialog. (In reply to comment #5) > Adding a new editor is ridiculously heavy for something as simple as looking at > an error. The user isn't going to be editing the error, they just want to get > to the root cause. I am not sure why read-only editor would be heavy. I think it is rather opposite. The idea was to open a plain text editor using virtual editor source without creating any files. I can create such patch if you interested to see how it would work. See my comment #3 for reasons why opening stack trace in stack trace console is somewhat limited and more restricting comparing to the lightweight editor. (In reply to comment #7) > (In reply to comment #4) > > it doesn't work that well in sourceviewer in a dialog (like in this bug), > > because hyperlink would also have to close the dialog after himself. > > That won't be an issue when editor will be used instead of the dialog. This will still be a problem with the editor. If you open an editor to display an event, that editor will have to be closed. Hyperlinking will open up the file in an editor. Now I have a stack trace editor sitting there that I will have to close that is little or no use to me. If I want to go through multiple parts of the stack trace, I will have to switch back to the stack trace editor every time. > I am not sure why read-only editor would be heavy. I think it is rather > opposite. The idea was to open a plain text editor using virtual editor source > without creating any files. I can create such patch if you interested to see > how it would work. Creating a new type of editor using the PDE forms UI is heavy. If you are talking about opening the stack trace in a text editor with hyperlinking, it isn't heavy, but then there is little benefit to having it. It wouldn't be as easy to read as the current dialog, it wouldn't have the buttons that make it easy to move between events, copy the event, etc. > See my comment #3 for reasons why opening stack trace in stack trace console is > somewhat limited and more restricting comparing to the lightweight editor. > I don't see any reason in comment #3 why the stack trace console is limited or restricting. It provides a simple solution to a common use case (hyperlinking stack traces when doing Eclipse development). Ok, so let's recap what we agreed upon so far. The real problem here turns to be: "It's hard to flip between event stack trace and classes listed there." it's hard because: A. current dialog is modal, B. user has to open it multiple times (I don't see any other arguments besides those in comment 3) We've worked out following solutions for that arguments: 1. create a lightweight editor to open entries. - It would fix A - problems: C. user still would have to jump between stack traces and source editors (#8). breaks B D. opening any event details would hide user current work (#1) E. RCP with logview migh have editor area disabled (#1) F. log entry is not a primary content to work with (#1, #2, #5) G. editor would be "heavy" (no clear def. what's "heavyness") 2. make current dialog support hyperlinks. - A don't really applies as dialog is not modal + stays on top, - problems: H. given hyperlink closes dialog, it breaks B 3. provide action for LogView to open entry stack trace in console - would fix A and B undoubtely, as we wouldn't have to use dialog - problems: I. requires more clicks than option 1. (#3) Given all that worthy input: opt. 3. fixes all our problems with least consequences opt. 2. will work as well if we solve H. opt. 1. doesn't really solve our problem If there are no any other reasons (except A and B) why it's hard to flip between event stack trace and classes, it sounds reasonable to continue with 3., rework 2. (bug 205561). Even if editor won't be heavy, opt. 1. still has other drawbacks, so leave 1. and close this as FIXED. Do you agree? A wise man once said, "Simplicity is the glory of expression" This is the case where we have a simple solution for a common action. My fear hear is that PDE is over-stepping the boundary as a plug-in development tool to something where TPTP would be useful in, ie., log analysis (ie., bug 217646). And it looks like Jacek beat me to it... when I was writing this reply... fo' shizzle Jacek! Option 1 is outside the scope of PDE. Curtis' patch is a step in the right direction as the console already has support for throwing stack traces in there. (In reply to comment #8) > > That won't be an issue when editor will be used instead of the dialog. > > This will still be a problem with the editor. If you open an editor to display > an event, that editor will have to be closed. Naturally. Same as for current dialog. But unlike current dialog, editor won't be covering most part of the screen. It is also possible to reuse same editor when browsing/scrolling trough the log view. > Hyperlinking will open up the > file in an editor. Now I have a stack trace editor sitting there that I will > have to close that is little or no use to me. If I want to go through multiple > parts of the stack trace, I will have to switch back to the stack trace editor > every time. You see, editor is actually provides better navigation, you can Ctrl-F6 (or Ctrl-Tab) back to it. > If you are talking about opening the stack trace in a text editor with hyperlinking, > it isn't heavy, but then there is little benefit to having it. It wouldn't be as > easy to read as the current dialog, it wouldn't have the buttons that make it > easy to move between events, copy the event, etc. Arguably. Editor usually provides better keyboard navigation, and we could use standard search and copy/paste actions without using dialogs that overlapping workbench window and still have number of issues after. I.e. message area can't be resized, and if I am not mistaken, read-only text areas don't support copy/paste on OSX. > I don't see any reason in comment #3 why the stack trace console is limited or > restricting. It provides a simple solution to a common use case (hyperlinking > stack traces when doing Eclipse development). In my experience Stack Trace console view don't work too well with multiple stack traces pasted out there. That is probably a bug and it need to be fixed separately, and perhaps it should be allowed to have more then one stack trace console, otherwise it will be really easy to lose stack trace that been manually pasted to console view. He he. You guys beat me with the summary, but just in case here are my notes: - Hyperlinking from the current event dialog require custom hyperlink detector and can't use platform hyperlinking support, i.e. because of the optional dependencies and special need to close dialog when clicking on hyperlink) - Opening stack trace in Java Stack Trace console require action to be invoked from popup menu (arguably less convenient), then previous content of that view will be lost. Though this is probably the less intrusive middle ground. - Opening stack trace in editor could replace opening current event dialog (i.e. using double-click). The issue is that editor need to be closed manually when it is not needed (though that is also the case for the event dialog), but the advantage is that editor can be more convenient do deal with then popup dialog. I can submit a patch to jdt.debug, similar to one Curtis created, but to open stack trace in the text editor. Darin, would you be able to consider such patch? (In reply to comment #12) Thanks Eugene, it's all extremely worth input. I'll split console and dialog related comments to bug 217752 and bug 205561. comments split. (In reply to comment #12) > - Opening stack trace in Java Stack Trace console require action to be invoked > from popup menu (arguably less convenient), then previous content of that view > will be lost. Though this is probably the less intrusive middle ground. Note that we can link right from the log view to the stack trace console. There's no need to open the error dialog first. I think the patch from Curtis had a toolbar button to do so - so it's one click to get the stack trace (two, if you count selecting the log entry). > - Opening stack trace in editor could replace opening current event dialog > (i.e. using double-click). The issue is that editor need to be closed manually > when it is not needed (though that is also the case for the event dialog), but > the advantage is that editor can be more convenient do deal with then popup > dialog. One could also imagine a "link with stack trace console option". This way, as you select log entries, they populate the stack trace view automatically. It would take some experimentation (but this means less clicks). > I can submit a patch to jdt.debug, similar to one Curtis created, but to open > stack trace in the text editor. Darin, would you be able to consider such > patch? I thought we all agreed that an editor was not necessary. (In reply to comment #15) > One could also imagine a "link with stack trace console option". This way, as > you select log entries, they populate the stack trace view automatically. It > would take some experimentation (but this means less clicks). Sure, especially if it would be stack trace console dedicated for the Log View. While ago I've been suggesting to use stack trace console to show junit stack traces instead of using proprietary panel. Maybe it can be generalized now (or at least provide an option). > > I can submit a patch to jdt.debug, similar to one Curtis created, but to open > > stack trace in the text editor. Darin, would you be able to consider such > > patch? > I thought we all agreed that an editor was not necessary. I did't, and Chris said that is is out of scope for PDE. :-) Are you concerned that it won't be useful or you just against of having both "open in stack trace console" and "open in editor" actions? Just to clarify, there won't be new editor contribution, but just new action contribution to the log view which would provide virtual editor source and open the plain text editor. There already is an "Open Log" action that opens the entire log in a text editor. Having an "open entry" option wouldn't be much different. My main concern here is feature creep/bloat, growing menus, and different ways to do the same thing (without understanding what the majority users would find more useful). Once a feature is in, taking it out is impossible. It makes me thing we should consider the "Show In >" metaphor with choices like "Stack Trace Console" and "Text Editor". It would be handy if the "Link with" feature was locked to either the console or editor. I don't want to have a button for each. (In reply to comment #17) > There already is an "Open Log" action that opens the entire log in a text > editor. Having an "open entry" option wouldn't be much different. The major difference is navigation trough log entries. If "open log" editor would follow selection in the error log view that would do the trick. > My main concern here is feature creep/bloat, growing menus, and different ways > to do the same thing (without understanding what the majority users would find > more useful). Once a feature is in, taking it out is impossible. That is what I thought and it does make sense. > It makes me thing we should consider the "Show In >" metaphor with choices like > "Stack Trace Console" and "Text Editor". It would be handy if the "Link with" > feature was locked to either the console or editor. I don't want to have a > button for each. "Show In..." is a great idea and "link with..." actions perhaps can be placed into the view menu. |