Jan,

Jan Jancura wrote:

>
> Dirk Ruiz wrote:

> > If most of the extra windows really do come from debugging runs, then we could
> > minimize window growth by being a bit clever about how the debugger handles the
> > windows it uses.  Here's an idea, inspired by Lea's recent post
> > (http://www.netbeans.org/servlets/ReadMsg?msgId=154995&listName=nbui).  What if
> > the debugger recycled the Editor window it uses to display source files?  So,
> > when you start a debugging run, the debugger uses the same Editor window to
> > display files as you jump around.  That way, even the longest debugging run
> > would use up only one window.  The only exception to that might be if you do an
> > edit in the window and don't save the edit; then the debugger would have to
> > start using a new window.
> >
> > As for hotkey Editor window switching, Alt-<right arrow> and Alt-<left arrow> do
> > cycle through the set of tabs.  True, they don't give you a nice list that you
> > can choose from, but it is pretty quick to skip around from the keyboard.
> > Ultimately, we need to provide better shortcut editing facilities, so that this
> > kind of functionality is more properly exposed.
> >

>
> Nice idea!


Thanks!


> I have some questions:
> 1) What should be a name of this window?
> - "Debugger [source name]"
> - The same like in editor: Source Editor [source name]"
> - ...


I was assuming that it would be just another tab in the Source Editor.  I hadn't
thought about labeling it, but that sounds like a good idea.  Perhaps the tab
could have some sort of special label, e.g., "[Debug]" appended or prepended to
the file name.  So, if you are debugging foo.java, the tab might read: "foo.java
[Debug]".  When you edit the file, then the tab switches to a regular Source
Editor tab, and gets labeled as usual: "foo.java*".  Hmmm, so here's a question.
When you save the changes, should the file return to being labeled "foo.java
[Debug]", or should it stay as a regular source editor window?  In the latter
scenario, when the user restarts the debugging session she would get a new
"foo.java [Debug]" window; the old foo.java window would be left behind.  It
would have the regular title, "foo.java", and with the cursor would be where the
user left it.  That might be handy if the user wanted to revisit a bugfix later
on.  On the other hand, the latter scenario (returning the file to being the
Debug window) would minimize window proliferation.  I'm not sure...


> 2) Should it be docked in default Source Editor window?


Yeah.  I was hoping to maximize continuity, so that the user would feel that
this window was just another Source Editor window, and that it therefore would
integrate in well with her workflow.


> 3) Should it be closed on Finish Debugging?


It could be closed.  Or the window could revert to a regular Source Editor
window.  I feel a bit leery about automatically closing windows on users (which
is one of the reasons I came up with this counterproposal) so I lean towards
reverting the window to a Source Editor window.  If we wanted to be strict about
window proliferation, we could keep a pointer to that window and reuse it for
the next debugging session.


> 4) What about Clone Action. Should it clone "Debugging" window or open
> the current source in Source Editor window?


I think we'll want to have only one Debug window per debugging session.  Also,
the user might want to clone the window in order to have a static view of the
file it contains.  I think she would be distressed if it changed!


> 5) Should a text in this window be editable?


Definitely.  As I said, I'd like the window to fit in nicely with the user's
workflow.  It would be unnatural for the user to have to jump out of the window
and go to another window to do editing.


> I like this idea especially because we can "customize" this editor
> window for debugging:
> - Special pop-up with debugger actions.
> - Special annotations (current line, call stack lines, ...).


Hmmm.  Sounds interesting.  Would we also remove any actions from the context
menu?  It could get pretty cluttered if we didn't.


> - May be some call stack view docked into it. Or it can be completely
> integrated with current Debugging Window.
>
> Other ideas?
>
> Jan


By the way, I'm assuming that this work will be done in a later release, not in
3.3?

Thanks!

Dirk
----
Dirk Ruiz
NetBeans Human Interface Engineer
Dirk.Ruiz@Eng.Sun.COM