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.
Summary: | There are two ways of choosing configuration in the main toolbar, in the combobox and from run and debug dropdown buttons. | ||
---|---|---|---|
Product: | projects | Reporter: | Ondrej Langr <olangr> |
Component: | Generic Projects UI | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | issues, jrojcek, rondruska, wadechandler |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 90801 | ||
Attachments: | ambiguous configuration setting |
Description
Ondrej Langr
2007-06-04 22:57:01 UTC
Created attachment 43216 [details]
ambiguous configuration setting
This is not to be solved in debugger. The configurations combobox and run and debug actions are out of scope for debugger modules. Moving to projects for evaluation... Is there any UI Spec for such solution? It seems like a strange union of Eclipse and Idea configurations (but with very limited power). P3 -> P2 until it is clear that this has been reviewed. As designed. The combo box sets the config persistently so you can just click the button (or use KB shortcuts or the menu items); the drop-down allows you to run a particular config in one step, rather than needing to first select it and then run it. Please see http://wiki.netbeans.org/wiki/view/RunConfigurations49636 If I remember correctly during the UI review we decided to disable the drop-down buttons. The reasons were we didn't want 2 ways to switch configurations in the main toolbar. It's really confusing because if I use the drop-down button to run with "myconfig", the next time I click the run button directly it doesn't use "myconfig" but "default" config which is selected in the combo box. The drop-down buttons were enabled again after another discussion which I thought was about general drop-down concept rather than specific usage with configurations. We should not combine both concepts and use either the drop down buttons or combo box. As the combo box is crucial for mobility and C/C++, we should stick to it and disable the drop-down buttons. Bummer. "if I use the drop-down button to run with "myconfig", the next time I click the run button directly it doesn't use "myconfig" but "default" config which is selected in the combo box" - obviously this could be changed easily if that is what you want, but it sounds like you want the drop-down buttons gone anyway? "Obviously this could be changed easily if that is what you want, but it sounds like you want the drop- down buttons gone anyway?" Yes, please remove them. Thanks! Drop-down buttons are candidates for 'Attach Debugger/Profiler' actions, which are now somewhat hidden (after removed from the main toolbar). This is to be discussed... By the way, the comments about Java ME and CND projects are a bit misleading; the drop-down buttons appear only if the main project specifically requests them. Java SE projects do so, but for Java ME projects it might be preferable to omit them, since ME configurations involve source code as well as run args. Reverting issue #90801 as per request. Checking in MainProjectAction.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/actions/MainProjectAction.java,v <-- MainProjectAction.java new revision: 1.18; previous revision: 1.17 done After working with projects which require many changes to the configuration I feel the split/combo button needs to be brought back. All it should do is run the chosen configuration. It isn't confusing either. I would have to see a user study which proved it to be so before I felt it to be confusing. Split buttons are used by many applications including AJAX applications, and I argue they are a known component. See Yahoo Mail, GMail, etc. I have been working on a JSE project which this button and drop down choosing strategy and it is just a pain. If you have to run different configurations more than a few times it really takes away from the user experience not to have them. The drop down menu in my opinion should be understood to be used to set and keep the default configuration for the main project. These are commonly used for such things as it is now. From the attach debugger point of view, as this issue mentions, the split button could reflect more options than it does in multi-configuration scenarios. Something such as Debug "configuration xyz" for each configuration, and attach debugger doesn't really care what the main class is. It is a single option which can be available as it is now, but I will reiterate...it is a single option, so what gain is it to have Debug Main Project and Attach Debugger versus going ahead and having the options on both buttons to run multiple configurations? I strongly feel this needs to be revisited. I base this on real world use of the IDE from the perspective of using it all day and needing to run multiple configurations. Personally I agree with Wade on this one, but this issue is about reported user confusion, and it was fixed as requested by user interface designers, so do not reopen. Can try to argue your case on nbui, or generally see if there is much interest in having the split combo (or something else, for that matter). Looked more like someone deciding it was confusing and thinking we might need to do something different with the debugger buttons down the road versus it really being confusing. When you think about it the debugger button now does the same thing just with less options and could use the ability to jump the debugger straight into a configuration. Is olangr not a developer? I hadn't seen any user confusion over it in the mailing lists. Personally, it seems like one of those UI decisions made with no user study or community feedback though I may be wrong. It would be extremely obvious which option would take precedence in the case one was selected from the split button...the one with the text "Run <configuration XYZ>". I don't see any possible way that could be confusing as to which operation the user wanted to take. It isn't any more confusing than clicking the drop down and deciding on a value other than you expect an immediate action to take place on the run button versus waiting for something to happen. I can't comment on why it was found to be confusing. (Obviously it's not confusing to me, but that means nothing.) I don't know whether the decision was based on user study; probably it was made without soliciting general feedback. Certainly it will not be changed for 6.0 but changes are possible for subsequent releases. Comments about Attach Debugger (or Attach Profiler) are beside the point; that is a completely different action which is not under discussion here. This issue is about Run Main Project and Debug Main Project (perhaps also Profile Main Project) for Java SE, CND, and Java ME projects; and potentially Build Main Project and Clean and Build Main Project for CND and Java ME projects (if these project types decide they wish to have a dropdown combo for these actions). To Wade and Jesse: The main problem is that NB configurations (as designed for NB6) are very limited when working with J2SE projects, e.g. debugging is not covered at all. I also really do not like the UI how they were put into properties dialog; this does not meet NB standard IMHO; see also http://ui.netbeans.org/docs/ui/DDBandConfig/index.html Both direct competitors (Eclipse, IDEA) are on completely different level with this. On the other hand, I do not think that we should adopt both Eclipse and IDEA ways, the UI would be really overloaded IMHO. Anyway, this topic is unfortunately beyond NB 6, it should be reopened for post NB 6 release. Yes, the one point is why I mentioned the debugger. It should be in both places (in both split buttons). Also, I believe configurations being in project properties is the place where we would expect to find them. I mean, that is where we configure the project after all. To have some project configuration outside project properties would seem strange to me. For instance, when I go into project properties I choose my main class, setup web start, configure my Java runtime and source settings, so while I'm doing all of this I don't want to have to jump out and go some where else. I want to take care of it all in one centralized location. It would be OK if under the run menu there was a menu option which jumped straight into the project properties Run section. So, clicking the action would be equivalent to the user clicking Project properties|Run. I did not criticize the fact configurations are a part of properties -- it is to be analyzed, I have no strong opinion about that now. What I do not like is the way *how it was put* into properties ;-) "debugging is not covered at all" - Run, Debug, and Step Into all use the selected run config. Attach Debugger does not make sense to treat as a project configuration because the entire purpose for this action is if your project setup is too complicated for the IDE to know how to start the app in the debugger itself. "[I would like] a menu option which jumped straight into the project properties Run section" - select Customize... from the config dropdown, or the context or main menubar submenus. Integrated into 'main-golden', will be available in build *201203210400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/90cdb5ae8c40 User: Jesse Glick <jglick@netbeans.org> Log: Drop-down menu removed in #105664 makes less sense after #166780 since there will usually not be a main project. (It could display configurations for the selected project, but probably this is too surprising.) A plugin could experiment with UIs for quick mouse-based invocation of (e.g.) Run on various open projects and their configs. |