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.
[This may be a repeat of another issue, but I can not locate it at the moment] The HTTP Monitor is shown as an item at the end of the Debug menu. While it can indeed be used for debugging tasks, it should nevertheless be put in the View menu, because this is the location where new views are found.
Recategorized to a P3 because it is too close to the Nevada freeze to be complaining about this.
The issue of the best location for the HTTP Monitor has been discussed in the past. The solution we then agreed on was a conscious one. So if we are to open the issue again, we should: - remember the arguments we then had for putting it to the Debug menu - decide whether these arguments are still relevant, or whether things has changed so much that they are no longer relevant - collect any new information which may be relevant Does anyone remember what were the main arguments for putting the monitor into the debug menu ?
Petr, That sounds like a good strategy (to find the original reasons and include them here). There are a couple factors on my/the-debugger side: 1) The debugger menu tends to get pretty long and complex once we get multiple debuggers installed. Even the mockups for "FFJ4.0+" at http://ui.netbeans.org/docs/hi/debugger3.4/toolbarmenu/index.html don't adequately convey how complex this menu is likely to become in the future. So, I think it is crucial that anything that gets added to the debug menu *really* has to go there. I'm trying very hard to keep this menu from getting too "messy". 2) There's a style guide being put together by the HIE group (talk to Jano for pointers) and the guidelines there are suggesting that the HTTP Monitor should be listed in the View menu rather than the Debug menu. (I know you list it in both places at the moment, and it also seems undesirable to be listing one thing in two places). I think both of these (well, definitely the second, maybe the first) are "new information". But, I really am interested in knowing what the original reasons for putting it in the Debug menu are, because there may be factors that I haven't thought of that make it a good place. :-)
After a conversation with David John, here's some further clarification: 1) The issue of the menuitem in the Debug menu is for Rainier, but it is unclear if Rainier will even include the web apps module. I'd like to find that out so we can prioritize when a fix should be designed and implemented 2) Whether or not the web app module is in Rainier, this issue needs to be addressed for Dublin. In response to Petr's questions: I looked into our past usability study (back in March 2000!) for the data. It looks like out of the 5 people who accessed the JSP monitoring tool, 2 expected to find the "monitoring tool" in the "Debugging Workspace", one in the debug menu, another in the "View log", another found it in the Tools menu, where it was really situated at the time. So I'm not sure if the argument placing the monitor in the "Debug" menu holds based on this study. though clearly, participants made an association of finding it somewhere debugging related. (The task at hand was to run a jsp, and if it didn't run correctly, to use the "jsp monitoring tool to track what is going on". )
Well, as of today's meeting, this stuff won't show up in Rainier, so the urgency on this issue is much less significant. But, I also don't want this to just vanish again until the day before the next product release. :-) I need to talk with Jano some next week before I say more here, because I want his opinion about what he sees the debugging menu for. So, I'll add more to this issue then.
I'm changing this to a tasks since technically nothing is broken. Note that there are very few high priority tasks or otherwise in this module - I promise this will get attended to. I'm also reassigning this to Ann since we need to decide what the right thing to do is. This is related to the dock the monitor issue, 31046.
I talked with Jano on Wednesday [he is gradually becomming the owner of debugger things, so his opinion is more important than mine here]. He also agrees that it doesn't belong in the Debug menu. He also agrees that it shouldn't be listed twice in the main menus (both view and debug). He also understands the usability motivation that prompted putting it there. I'm glad ann has responsibility for this issue!
CC'ing Chris since this will have docs impact once the change is made. For visibility sake, let's default to showing the monitor in the output window. Another detail that needs to be addressed besides the focus stealing mentioned in issue 31046, is making the output window bigger to accomodate the monitor.
The choices for where the actual HTTP Monitor shows are narrowed down to the Debug Window and the Output Window. Because the HTTP Monitor isn't necessarily tied to debugging (esp now that we have support from the server plugins), and we'd be able to launch it regardless of the context, I recommend putting it in the Output window. This suffers the disadvantage of it being buried/fronted in front of the other server output tabs, but I think it might be more acceptable then if both the Debug and Output windows are showing and one would have to always resize/change focus to see between the two.
Petre, I reassign this temporarily to you as a reminder, since you wanted to raise this issue with somebody (I forget whom). Please reassign it back to me when done. Thanks.
Ok, I think we've resolved the issue of where the tool is placed, now we still need to figure out where in the menu it appears. Based on recent discussions with Jano, the exact role of the View, Tools, Window and even Debug menus is not yet completely fleshed out after the window system change. Also, the View menu currently only contains one item, so its purpose is clearly undefined yet. Since the native tools product does not plan a release on top of the next NB release, and the length of the debug menu in the NetBeans product is reasonable, I suggest not making any change in this until promotion D. For now, it should stay in the Debug menu, and we'll deal with this in promo D.
Currently (Dec 19) the HTTP monitor item is in main menu twice in Debug and in Windows. I guess we should take some action during 3.6 to fix this state.
As Jano wrote the CDP-winsys2 team, this is the placement (Which i don't see in 031221 build) >So, we revisited this issue and decided to put the monitor at the same >place as output window. This change is due to HTTP Monitor contents >which requires more space. This solution isn't perfect but seems the >best we can achieve with current design of HTTP monitor contents. >Thanks, >Jano As for where the menuitem appear. I recommend placing it only in the Windows menu for two reasons - 1) Windows menu seems to have developed a stronger sense of what it is, and HTTP Monitor falls into that category 2) HTTP Monitor isn't just launched via debug anymore.
to be clear, the HTTP Monitor menu item should be removed from Debug and only be shown in the Window menu.
Fixed
Created attachment 12812 [details] Diffs for layer.xml
verified