Community
Participate
Working Groups
Created attachment 267187 [details] Current state of the "Run" menu I've noticed that our Run top level menu contains many entries which do not "Run" or "Start" or "Execute", but "Do something related to debug". 27 entries from 44 has nothing in common with "Run", only 17 are really matching, see attached picture. This is ridiculous! I have a nice 1920x1200 resolution on my 24 monitor but even with this resolution the "Run" menu barely fits. On my notebook with 900 pixels height I always have to scroll. Sure, I have two extra tools installed: profiler and coverage, but this is true for many developers. I think the main problem is that we do not have a dedicated "Debug" top level menu. All those 27 entries make sense only in debug context. They have no sense for coverage/profile/run scenarios at all. Also this is kind of inconsistent regarding the toolbars: there we have two dedicated "Launch" and "Debug" toolbars. The proposal is also to create a top level Debug menu and let all debug related Debug/JDT contributions to use it.
+1 Great idea.
+1 I like the idea :)
+1. Debugging is one of the main activity of a developer and one of the key features in an IDE, it deserves its own menu to better integrate in the flow of a developer.
I like the idea and I think this has to be addressed IDE wide. If it's just JDT changing then the end result will be somewhat disorganized. At least the Java package should be consistent. I know it sounds like a lot of additional work but I really think that the JDT only focus is not helpful for the IDE as a whole. Would you be willing to review that and/or coordinate with other popular packages (CDT, PHP, Webtools)? What do you think about profiling and test coverage entries? Would they go into Launch/Run or Debug?
(In reply to Gunnar Wagenknecht from comment #4) > I know it sounds like a lot of additional > work but I really think that the JDT only focus is not helpful for the IDE > as a whole. Would you be willing to review that and/or coordinate with other > popular packages (CDT, PHP, Webtools)? I completely agree. Other projects that contribute debug related entries have to agree to make the move. Having a mix would be worse than what we have now. The Planning Council could make the adoption of a new Debug menu a mandatory item for Photon.
+1
+1. I also voted for it next to the "importance" section.
I'll be a bit of a contrarian. Debug is a form of Run, so is Profile, Coverage, etc. Be careful not to to think Run menu item as the launch mode Run. Maybe we should rename it to Launch. So if you go the planned route here, are you suggesting we should have top level menu items for all launch modes, or is Debug special?
(In reply to Doug Schaefer from comment #8) > So if you go the planned route here, are you suggesting we should have top > level menu items for all launch modes, or is Debug special? I think Debug is special as user interact with the debugger while application is running, from the IDE; and debug commands are "traversal" in the IDE - they can be placed and used in many contexts with or without debugger started. Other Launch types (Run, Coverage, Profile...) typically let the application run without changing the state of the workbench, and user usually see reports after the fact in the dedicated context (view or editor) that contain the necessary pieces of UI for this activity. Moreover, Debug is an activity almost all developers use (I guess), coverage and profiler are less common.
(In reply to Gunnar Wagenknecht from comment #4) > I like the idea and I think this has to be addressed IDE wide. If it's just > JDT changing then the end result will be somewhat disorganized. At least the > Java package should be consistent. I know it sounds like a lot of additional > work but I really think that the JDT only focus is not helpful for the IDE > as a whole. Sure, I just mentioned what I saw in the screenshot, of course CDT/PDT/you name it all should use the new top level Debug menu. > Would you be willing to review that and/or coordinate with other > popular packages (CDT, PHP, Webtools)? I think Dani made already a good proposal. > What do you think about profiling and test coverage entries? Would they go > into Launch/Run or Debug? The entries which "Start" something still should be under "Run" I think. Entries related to "Inspect state" of something (debug/profile/coverage) go to the "Debug". May be even "Profile" menu would make sense for a profiler tool - but we do not need to make it visible by default? So all the launch configurations related / similar things should stay where they are today. All the "object" related menus should use the new menu. Does it make sense? (In reply to Dani Megert from comment #5) > (In reply to Gunnar Wagenknecht from comment #4) > > I know it sounds like a lot of additional > > work but I really think that the JDT only focus is not helpful for the IDE > > as a whole. Would you be willing to review that and/or coordinate with other > > popular packages (CDT, PHP, Webtools)? > > I completely agree. Other projects that contribute debug related entries > have to agree to make the move. Having a mix would be worse than what we > have now. The Planning Council could make the adoption of a new Debug menu a > mandatory item for Photon. Very nice idea. Dani, two questions: 1) How do I start such proposal for the Planning Council? 2) do you think I should post the note on the cross-project list? How do we collect the project votes?
I'm just worried about consistency. And from my experience, few users actually use the Run menu anyway. They use the tool bar which has Run and Debug and anything else plug-ins contribute. My underlying concern is the sanctity of the top menu. I can't remember the last time we added something to it. It would have to have been in the Eclipse 2.0 days with the Refactor menu (and even that one is questionable). It is a great responsibility to keep it clean and protect it from the tragedy of the commons. Make sure you have a consensus to add it before you do.
(In reply to Andrey Loskutov from comment #10) > Dani, two questions: > 1) How do I start such proposal for the Planning Council? > 2) do you think I should post the note on the cross-project list? How do we > collect the project votes? I suggest to wait a week or two to see how the discussion in this bug goes. After that, we can bring it onto the agenda for the next planning council call in April.
(In reply to Andrey Loskutov from comment #10) > (In reply to Gunnar Wagenknecht from comment #4) > > What do you think about profiling and test coverage entries? Would they go > > into Launch/Run or Debug? > > The entries which "Start" something still should be under "Run" I think. > Entries related to "Inspect state" of something (debug/profile/coverage) go > to the "Debug". May be even "Profile" menu would make sense for a profiler > tool - but we do not need to make it visible by default? So all the launch > configurations related / similar things should stay where they are today. > All the "object" related menus should use the new menu. Does it make sense? I believe this is a very good distinction: (1) Run menu is only about starting / launching (incl. "Debug as"). (2) Debug menu is about interacting with a running debug target Manipulating breakpoints is a bit border-line (nothing needs to be running already for that), but still closer to (2) than to (1). In addition to the sheer size of the menu, it would be great to see, e.g., stepping actions and breakpoint actions closer together. Similar for "External Tools ..." which is ridiculously far away from "Run as" and friends. Disclaimer: I mostly use toolbar buttons for launching and keyboard shortcuts for most debug actions - but then part of this might be because the Run menu isn't very attractive, currently.
After reading the bug description I was wondering what magical 44 items I missed so far in eclipse. I have to admit that I never use the Run menu at all. It might make sense to use these items when you hide the main toolbar, otherwise I see lots of redundancy. I guess when users are debugging they typically might use their own flavour of the debug perspective. So do I really need main menu items for breakpoint handling or would I do it from the breakpoints view? Or is anyone using the menu item to step over/step into? Possibly it is worth the discussion to either move these items to submenus or eventually get rid of some at all. I would not mind having a new Debug menu, so for me then it would be 2 useless menus. But I am not sure if it would make life easier for users if they start to wonder where to find profiling and coverage runs. On the main topic I fully agree, the current run menu contains too many entries on the root level and should be cleaned up.
From my personal experience: I never use the Run menu so I also will never use the new Debug menu. I do all debugging, running and run config from the toolbar and context menus.
Do we not use the menu because it is bad, or is it bad because nobody cares? Same difference, I'd say. So, experts tend to have faster ways to invoke these actions. Still two reasons to have a usable debug menu: - with consistent use of accelerators all functions can be invoked from the keyboard without having to remember all shortcuts - if there's a menu with 80% stuff that I regularly use, this also invites me to look at the other options. Few developers know, e.g., about Force Return. Maybe because it's hardly visible in the UI. Maybe.
When explaining, especially remotely, to new users (or users of new functionality) how to do something it is difficult to tell them to use context menus or toolbars. It is deterministic and easy to explain to get someone to the right action by sending them via the menu. By having consistency in icons between menu and toolbars users find the faster toolbar and learn the shortcuts. The Run menu is undoubtedly too long as it is, and I certainly think considering how to simplify it is important. As others have said, I personally rarely use the Run menu, and having it split up would do little to help my daily use. But the simplification would help whenever I have to help someone else remotely.
I am ok for Run menu being split into Launch and Debug Menu. Another point is as going by comments, I see people use more toolbar and shortcuts, if the aim is to reduce the length of Run Menu, we can create sub menus also.
(In reply to Sarika Sinha from comment #18) > I am ok for Run menu being split into Launch and Debug Menu. > > Another point is as going by comments, I see people use more toolbar and > shortcuts, if the aim is to reduce the length of Run Menu, we can create sub > menus also. Good idea, what about this proposal: For 4.7 release, move those 3 highlighted groups (see the screenshot) to a new sub menu "Run -> Debug". So platform will define a new sub menu there and everyone (like JDT) can decide to move some "debug related" menus under this one. This should not harm anyone and will improve current menu state a lot. Those who never used "Run" would be not affected, those who use "Run" will see reduced menu and a new "Debug" entry. For someone used to see those entries in the first level menu there will be one mouse hover more to reach the moved debug menu entries. I think this is something we can still do in 4.7 M7 (last chance for features). Introducing a new sub-level menu is "kind of" API, but this should be still doable in M7. For 4.8 release, start discussion of the introduction of the new "Debug" top level menu on cross-project. WDYT?
For me personally this (the sub-menu) would be OK. BUT ;) we have a lot of new developers here that really still use the menu while debugging (stepping, etc.). I know this is only while they are bloody beginners, but still, while forcing them to learn things faster (they have a lot other things to learn), it will slow them down at first.
(In reply to Markus Duft from comment #20) > For me personally this (the sub-menu) would be OK. BUT ;) we have a lot of > new developers here that really still use the menu while debugging > (stepping, etc.). I know this is only while they are bloody beginners, but > still, while forcing them to learn things faster (they have a lot other > things to learn), it will slow them down at first. It will be very painful if people use the menu for stepping, imagine using a sub-menu. It would be nice if a hint about the toolbar was shown when people use stepping from the menu. Technically, a parameter can be supplied to the command when the menu item is attached to the main menu. Subsequently a "did you know.. / don't show me again" dialog can be presented.
(In reply to Andrey Loskutov from comment #19) > > I think this is something we can still do in 4.7 M7 (last chance for > features). Introducing a new sub-level menu is "kind of" API, but this > should be still doable in M7. > > For 4.8 release, start discussion of the introduction of the new "Debug" top > level menu on cross-project. > > WDYT? Let's not change it many times, it will be confusing.
Although I fully support the idea of a dedicated top-level menu for "Debug", I'm -1 about the idea of introducing a sub-menu. Sub-menus don't really make things simpler, it makes browsing and discovering features more complicated. Menu separators are doing a better job at grouping actions without reducing the accessibility (number of clicks and menus to expand). I don't think the goal is only to reduce the size of the run menu, but to better map the top-level menus with user needs and flows. For that "Debug" is a top-level activity, even more important than "Run" actually from an IDE. Still, ${comment 3}
I agree with Sarika and Mickael on the following topics: We should not change something in 4.7 that we plan to rework in 4.8. A new top-level menu item is more appropriate than adding sub-menus. Stay tuned! ;-)
Dani, Sarika, we schould start to work on this one for M2, or it will be too late. Anything I can help with? Was there any feedback on the planning council?
(In reply to Andrey Loskutov from comment #25) > Dani, Sarika, we schould start to work on this one for M2, or it will be too > late. Anything I can help with? Was there any feedback on the planning > council? Yes Dani we should start this early and may be along with Bug 464898.
(In reply to Sarika Sinha from comment #26) > (In reply to Andrey Loskutov from comment #25) > > Dani, Sarika, we schould start to work on this one for M2, or it will be too > > late. Anything I can help with? Was there any feedback on the planning > > council? > > Yes Dani we should start this early and may be along with Bug 464898. Let's not tie those two items together. The Planning Council had no objections to add a new Debug menu. Only restriction is that it must not break anything. Please send a note with the proposed change and expected work that clients have to do to the cross-project mailing list.
Not sure, When will I be able to look at it. @Andrey, Do you want to take it up?
(In reply to Sarika Sinha from comment #28) > Not sure, When will I be able to look at it. Me too :-( > @Andrey, Do you want to take it up? I should and I want, but I'm currently totally under water with another work. It is on my radar, but I can't guarantee anything right now.
Created attachment 271417 [details] Default "Run" menu does not fit to 1920x1080 screen I think I have a viable technical proposal, and I will submit two patches in few minutes. I will also attach pictures showing the state of the "run" and "debug" menus after the patches are applied.
New Gerrit change created: https://git.eclipse.org/r/111425
New Gerrit change created: https://git.eclipse.org/r/111426
Created attachment 271418 [details] "Debug" part of the "Run" menu after patches (In reply to Eclipse Genie from comment #31) > New Gerrit change created: https://git.eclipse.org/r/111425 (In reply to Eclipse Genie from comment #32) > New Gerrit change created: https://git.eclipse.org/r/111426 Attached picture shows the new "Debug" menu after both patches (on platform.debug and jdt.debug projects) are applied. The patch on platform.debug is backwards compatible to existing clients, because it only adds new top level menu and lets all previously existing menus and separators in place. I would not remove any of the old "org.eclipse.ui.run/*" group definitions, because the risk to break existing clients is too high. The patch on jdt.debug *moves* "org.eclipse.ui.run/jdtGroup" group to "org.eclipse.ui.debug/jdtGroup", so it has a risk that some clients could be affected. At least google can't find *any* open source contribution which were using "org.eclipse.ui.run/jdtGroup" group, so I guess this should be not a problem. We can also keep the existing "org.eclipse.ui.run/jdtGroup" menu contribution, but I think this is not worth the effort.
Created attachment 271420 [details] "Run" part of the "Run" menu after patches Last attachment shows the new "Run" menu without "Debug" contributions. @Dani, Sarika: if you have no objections, and because the change should be backwards compatible, I will post a mail on cross-project mailing list describing the change and merge both patches next week.
New Gerrit change created: https://git.eclipse.org/r/111427
(In reply to Eclipse Genie from comment #35) > New Gerrit change created: https://git.eclipse.org/r/111427 This one is for CDT, but I have no pictures to share because I can't get CDT running on Windows in my environment. Should be same as others, because CDT basically contributes the menu in the same way as JDT does.
(In reply to Andrey Loskutov from comment #36) > (In reply to Eclipse Genie from comment #35) > > New Gerrit change created: https://git.eclipse.org/r/111427 > > This one is for CDT, but I have no pictures to share because I can't get CDT > running on Windows in my environment. Should be same as others, because CDT > basically contributes the menu in the same way as JDT does. Thanks for the patch to bring CDT up to the new Debug menu standard. As mentioned in gerrit, we will have to hold the gerrit in a pending state until after we have Oxygen.3. However, if we (CDT) stick to our plan of having only a patch release of CDT in Oxygen.3 we could potentially apply this after Oxygen.2 to master. Please let me know what is failing for CDT on Windows and I can help resolve (feel free to do that conversation in cdt-dev mailing list or in mattermost https://mattermost.eclipse.org/eclipse/channels/cdt-developers)
Run and Debug looks better after the change. Good thing is that it is backward compatible. Only thing is that Debug Menu is still quite long :) I was going through the Customize Perspective and saw we have two groups, Launch and Debug in Toolbar. This made me think that can it help at Menu level as well? Now after the changes, Run menu is very small so one option can be to have Launch and Debug menu at the top level. Launch can have Run and the Debug Launch related options to it and Debug menu can have all the Debug options minus the launch related ones.
(In reply to Sarika Sinha from comment #38) > Run and Debug looks better after the change. Good thing is that it is > backward compatible. > > Only thing is that Debug Menu is still quite long :) > ... > Now after the changes, Run menu is very small so one option can be to have > Launch and Debug menu at the top level. Launch can have Run and the Debug > Launch related options to it and Debug menu can have all the Debug options > minus the launch related ones. Do you propose not only to let "Debug, Debug As, Debug History and Debug Configurations" menus in the old "Run" top menu, but also to rename the "Run" to "Launch"? Later can be confusing for an unexpected reason: many tools "re-define" "Run" menu structure to make sure their action contributions will find the right menu, and they all use the "Run" label for it. So it may happen that depending on weird startup timing order we will sometimes see "Run" and sometimes "Launch". I would propose to have a different bug for the renaming the "Run" to "Launch" and check there if this is something we should do and if, how. Regarding the former proposal - yes, makes sense, and I will push the updated patch shortly, along with screenshots.
Created attachment 271488 [details] "Debug" part of the "Run" menu after patches, take 2
Created attachment 271489 [details] "Run" part of the "Run" menu after patches, take 2
I am ok with the name "Run". A mail to cross-dev and platform-dev with Menu and perspective changes will help the users understand it better.
(In reply to Sarika Sinha from comment #42) > I am ok with the name "Run". > > A mail to cross-dev and platform-dev with Menu and perspective changes will > help the users understand it better. OK, what would be next steps? Merge & mail to cross-project and platform lists? Are you OK if I will do that? I'm missing something?
Let us wait till today to see if any one has any objection, otherwise you can merge and send the mail. You will need to update N&N for both both the changes as well.
Having still debug entries in the Run looks very wrong to me. I'm aware of similar "silly" entries in Android Studio and use them on a regular basis to ridicule AS in front of my training audience. Typically this leads to the audience laughing very loud and us agreeing that AS has a very bad UIX. We should avoid such silliness in Eclipse.
(In reply to Andrey Loskutov from comment #41) > Created attachment 271489 [details] > "Run" part of the "Run" menu after patches, take 2 Comment 45 related to that screenshot.
(In reply to Lars Vogel from comment #45) > Having still debug entries in the Run looks very wrong to me. > > I'm aware of similar "silly" entries in Android Studio and use them on a > regular basis to ridicule AS in front of my training audience. Typically > this leads to the audience laughing very loud and us agreeing that AS has a > very bad UIX. > > We should avoid such silliness in Eclipse. See comment 38 for reasoning. Think about "Run" as the place to *start* something and "Debug" as the place to "what can I do if I debug something". So "Run" contains configurations/history for all kinds of "Profile, Debug, External Launches" executions.
Andrey, Sarika, you have to see this from the perspective of a user: ------------- The user is presented with two top-level menus: "Run" and "Debug". Now he wants to debug his application. What is the logical choice to pick from the top-level menu? Answer: It is NOT "Run". ------------- Arguing that the Run menu is too small is IMHO not a valid argument. Following this, we could also move entries from the File or Help menu to the Run menu. -2 for any change that leaves "Debug" entries in the "Run" menu. Such a change would make user experience in Eclipse IMHO much worse. If you disagree, please escalate this to the PMC, so that the PMC can decide on this.
I've opened bug 527330 about the following parts of discussion. (In reply to Doug Schaefer from comment #8) > I'll be a bit of a contrarian. Debug is a form of Run, so is Profile, > Coverage, etc. Be careful not to to think Run menu item as the launch mode > Run. Maybe we should rename it to Launch. (In reply to Sarika Sinha from comment #18) > I am ok for Run menu being split into Launch and Debug Menu. (In reply to Sarika Sinha from comment #38) > one option can be to have Launch and Debug menu at the top level. (In reply to Andrey Loskutov from comment #39) > I would propose to have a different bug for the renaming the "Run" to > "Launch" and check there if this is something we should do and if, how. (In reply to Lars Vogel from comment #45) > Having still debug entries in the Run looks very wrong to me. (In reply to Andrey Loskutov from comment #47) > Think about "Run" as the place to *start* something. s/start/launch/ as we say more frequently ;)
(In reply to Lars Vogel from comment #48) > -2 for any change that leaves "Debug" entries in the "Run" menu. Such a > change would make user experience in Eclipse IMHO much worse. Can't we have the menu entries in both menus? I think it would actually be very consistent and map most "discovery" scenarios.
(In reply to Mickael Istria from comment #50) > Can't we have the menu entries in both menus? I think it would actually be > very consistent and map most "discovery" scenarios. -1, I don't see why anyone would search for a debug menu entry in the launch menu, if we have a debug menu. And we should avoid "polluting" the menu.
(In reply to Lars Vogel from comment #51) > -1, I don't see why anyone would search for a debug menu entry in the launch > menu, if we have a debug menu. And we should avoid "polluting" the menu. If there happens to be the Profiling or Coverage launch type in this menu, it would be inconsistent to not show the debug ones IMO. But I see that it's now -1 when you voted -2 earlier; so it means it wouldn't be a blocker for you any more if those entries are in both menus, doesn't it?
(In reply to Sarika Sinha from comment #44) > Let us wait till today to see if any one has any objection, otherwise you > can merge and send the mail. (In reply to Lars Vogel from comment #48) > Andrey, Sarika, you have to see this from the perspective of a user: > > ------------- > The user is presented with two top-level menus: "Run" and "Debug". Now he > wants to debug his application. What is the logical choice to pick from the > top-level menu? > > Answer: It is NOT "Run". > ------------- > > Arguing that the Run menu is too small is IMHO not a valid argument. > Following this, we could also move entries from the File or Help menu to the > Run menu. > > -2 for any change that leaves "Debug" entries in the "Run" menu. Such a > change would make user experience in Eclipse IMHO much worse. > > If you disagree, please escalate this to the PMC, so that the PMC can decide > on this. Sarika, I think the last change request from you found some strong objections. Looking at this from Lars point of view I also agree that it is a bit obscure not to put "Debug that thing now" menu under the "Debug" group. I also agree that putting menus two times into the menus would be rather confusing (why they are there, are "Debug/Debug" abd "Run/Debug" different?). So I will revert the last change set and return to the first proposal version, shown as attachment 271418 [details] and attachment 271420 [details].
(In reply to Mickael Istria from comment #52) > (In reply to Lars Vogel from comment #51) > > -1, I don't see why anyone would search for a debug menu entry in the launch > > menu, if we have a debug menu. And we should avoid "polluting" the menu. > > If there happens to be the Profiling or Coverage launch type in this menu, > it would be inconsistent to not show the debug ones IMO. > But I see that it's now -1 when you voted -2 earlier; so it means it > wouldn't be a blocker for you any more if those entries are in both menus, > doesn't it? Yes, unnecessary redundancy is IMHO not as bad as a wrong position of certain menu entries. But the ideal solution would to place the entries only in the correct top-level window.
(In reply to Andrey Loskutov from comment #53) > So I will revert the last change set and return to the first proposal > version, shown as attachment 271418 [details] and attachment 271420 [details] > [details]. +1, once done, I remove my minus vote for this change.
(In reply to Lars Vogel from comment #55) > (In reply to Andrey Loskutov from comment #53) > > So I will revert the last change set and return to the first proposal > > version, shown as attachment 271418 [details] and attachment 271420 [details] > > [details]. > > +1, once done, I remove my minus vote for this change. See https://git.eclipse.org/r/#/c/111425/4
I see attachment 271418 [details] and attachment 271420 [details] as a good compromise and definitely better then the current state. Trying to understand the remaining contention, I feel that we have a conflict between: (1) emphasizing debug so it should deserve its own toplevel menu (2) finding a logically convincing structure, which would more likely be served by a sub-menu (which would IMHO avoid all of the confusion in recent comments). Picking attachment 271418 [details] and attachment 271420 [details] would indicate: we rank (1) higher than (2) (and then we shouldn't be surprised that the UI structure is sub-optimal from a logical/structural p.o.v.). Do you see this as a fair description of the compromise reached? One more thing comes to mind, not sure if mentioned before: many debugging commands are active only after a debug session has been started. Could this be used as a criterion for structuring? Rough sketch: - keep breakpoint-related commands in the "Run" menu - create a toplevel "Debugging" menu - menu appears only when a debug session is active - contains only commands for stepping and inspecting runtime values
+1 for the solution which moves all debug menu items to the new "Debug" menu. I'm currently away from my computer so I cannot test the latest patch, but of course, I trust Andrey.
My arguments have been concern over polluting the top level menu with Debug. But I agree with Lars, if we're doing the Debug top level menu, the launch items need to be there too.
(In reply to Stephan Herrmann from comment #57) Rough sketch: > - keep breakpoint-related commands in the "Run" menu -2 to all suggestions which keep "Debug" related menu entries in the "Run" menu.
(In reply to Lars Vogel from comment #60) > (In reply to Stephan Herrmann from comment #57) > Rough sketch: > > - keep breakpoint-related commands in the "Run" menu > > -2 to all suggestions which keep "Debug" related menu entries in the "Run" > menu. If you say so, then it seems time for open discussion is over (and obviously nobody noticed the subtle difference between "Debug" and "Debugging" in comment 57 - reflecting also comment 47 and similar). In that light the current _compromise_ is obviously the best we can agree on (and of course some users will still regard it as silly). Thanks, Andrey, btw.
(In reply to Sarika Sinha from comment #44) > Let us wait till today to see if any one has any objection, otherwise you > can merge and send the mail. > You will need to update N&N for both both the changes as well. Now that we got some feedback and I would say reached some kind of agreement on the first proposal ("all debug into debug"), I will try to merge all bits tomorrow and after that write a mail to the cross-project list. N&N is on my list too.
Gerrit change https://git.eclipse.org/r/111425 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=eee1fdca463a9e904fcc4ab5cbb22a9ceb3450ac
Gerrit change https://git.eclipse.org/r/111426 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=0e23aa1bd12eaf56823e387da94636dae16cbf8c
New Gerrit change created: https://git.eclipse.org/r/111860
Gerrit change https://git.eclipse.org/r/111860 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f1ce688a7078c65378c70e462a040d5b9867c1d8
I still need to look at all the details but I already noticed one issue: it can happen that other contributed menus are placed between 'Run' and 'Debug' which is bad. See attached screenshot.
Created attachment 271593 [details] Run/Debug not beneath each other
(In reply to Dani Megert from comment #67) > I still need to look at all the details but I already noticed one issue: it > can happen that other contributed menus are placed between 'Run' and 'Debug' > which is bad. See attached screenshot. Both menus are contributed to the "addons" main manu. Looks like our menu builder/processing machinery adds contributed menus in a (more or less) random order. I guess somewhere it iterates over HashMap or HashSet of contributions or has "off by one" bug by inserting addition contributions. If someone knows exact place where it happens, do not hesitate to post it here.
(In reply to Dani Megert from comment #67) > I still need to look at all the details but I already noticed one issue: it > can happen that other contributed menus are placed between 'Run' and 'Debug' > which is bad. See attached screenshot. Can we handle this by a new bug, or schould I move the target for this one to M5? I see currently no solution.
(In reply to Andrey Loskutov from comment #70) > (In reply to Dani Megert from comment #67) > > I still need to look at all the details but I already noticed one issue: it > > can happen that other contributed menus are placed between 'Run' and 'Debug' > > which is bad. See attached screenshot. > > Can we handle this by a new bug, or schould I move the target for this one > to M5? I see currently no solution. We can create a new bug.
(In reply to Sarika Sinha from comment #71) > We can create a new bug. I don't think we can should prevent this. If a customer wants an additional meny entry between Run and Debug in his custom IDE, we should not prevent that.
(In reply to Lars Vogel from comment #72) > (In reply to Sarika Sinha from comment #71) > > We can create a new bug. > > I don't think we can should prevent this. If a customer wants an additional > meny entry between Run and Debug in his custom IDE, we should not prevent > that. So far there was no 'Debug' menu and all actions were available close by each other in the 'Run' menu. With the change those might no longer be close to each other. So, since the 'Debug' menu is new and logically belongs to 'Run' they must appear together. Whether we add more logic, so that people can deliberately destroy that sequence that's another question/feature.
(In reply to Andrey Loskutov from comment #70) > (In reply to Dani Megert from comment #67) > > I still need to look at all the details but I already noticed one issue: it > > can happen that other contributed menus are placed between 'Run' and 'Debug' > > which is bad. See attached screenshot. > > I see currently no solution. Then maybe this is not ready for M4 and should be removed again.
Created attachment 271675 [details] Picture showing big distance between Run and Debug This is just the SDK + tests. Imagine how it looks when many other projects are installed.
(In reply to Dani Megert from comment #74) > (In reply to Andrey Loskutov from comment #70) > > (In reply to Dani Megert from comment #67) > > > I still need to look at all the details but I already noticed one issue: it > > > can happen that other contributed menus are placed between 'Run' and 'Debug' > > > which is bad. See attached screenshot. > > > > I see currently no solution. > > Then maybe this is not ready for M4 and should be removed again. I fear this would mean we will *never* see the "Debug" menu. The problem as far as I can see is that everyone can add menus to any menu path, and there is no API to make sure two contributions ALWAYS appear next to each other if contributed to the *same* menu path with twenty other contributions. In our case "Run" added to "additions", also I've added "Debug" to additions too. I was unable to identify the single place in the code responsible to reading the menu contributions and rendering them, there are at least two ways to contribute (old action sets and new popups extensions), they all are somehow mixed and rendered together and it is a pain to debug it. I see however that it looks like there is NO GUARANTEED order at all for the extension points API implementation, and with two additional test menus contributed by tests to the same "additions" menu path I see different menu positions every second time I start IDE. Funny enough, the *relative* order of Run/Debug to each other remains stable (?why?), but they may or may not have different other menus placed between. To avoid "mixed" contributions to the "additions" path, the possible different implementation would be to create two new global menu paths (anyone knows how? I guess some e4 magic somewhere in some model?) and contribute "Run" to "run" path and "Debug" to new "debug" path. However, this will cause the problem with ALL not adopted contributors which usually (like CDT) repeated the "Run" menu contribution to the "additions" path, which would probably mean we will see two "Run" menus or that the one contributed to "additions" could win (need to check which way it can go wrong). Again, in this case any 3rd party contribution can again contribute to the "run" menu path and so appear between "Run" and "Debug" menus. So it ends again in the problem that we need a declarative way to define "this menu appears *always* next to that one on the right side, and no one can be placed between". May be someone knows already a way to do so, I have no idea how it can be done, especially if we want to consume same API as any other 3rd party contribution. Assume there will be two "Good Debug" and "Bad Debug" menus which would both want to be placed next to "Run". How this should be ever solved, which one should win? I can't really spend time anymore on debugging this, so if no one helps till Friday, I need a clear answer if the "Debug" menu should be removed or not from M4.
(In reply to Andrey Loskutov from comment #76) > So it ends again in the problem that we need a declarative way to define > "this menu appears *always* next to that one on the right side, and no one > can be placed between". Correct. > I can't really spend time anymore on debugging this, so if no one helps till > Friday, I need a clear answer if the "Debug" menu should be removed or not > from M4. For me the decision factor is how the most prominent EPPs look, e.g. Java, Java EE, Committer and CDT. If 'Run' and 'Debug' aren't separated there, we can leave it in M4 and look for a fix during M5. Otherwise I tend to revert the changes. Not sure whether you can just install the M3 EPPs and update the Platform to the latest I-build with the new Debug menu.
(In reply to Dani Megert from comment #77) > For me the decision factor is how the most prominent EPPs look, e.g. Java, > Java EE, Committer and CDT. +1 --- Thought: most likely the test contributions specify their position after the "Run" menu. If we could switch the order of the "Run" and "Debug" entries, I believe they would be together, as no one could have targeted the new Debug menu so far.
(In reply to Dani Megert from comment #77) > > > I can't really spend time anymore on debugging this, so if no one helps till > > Friday, I need a clear answer if the "Debug" menu should be removed or not > > from M4. > > For me the decision factor is how the most prominent EPPs look, e.g. Java, > Java EE, Committer and CDT. If 'Run' and 'Debug' aren't separated there, we > can leave it in M4 and look for a fix during M5. Otherwise I tend to revert > the changes. Not sure whether you can just install the M3 EPPs and update > the Platform to the latest I-build with the new Debug menu. Can someone from CC please validate this? I'm under water with my other daily work.
I will try out.
I tried installing WTP, C++, Maven and Xtext and nothing comes between Run and Debug. Installing "Eclipse SDK Tests" Introduces 2 menus after Run and before Debug. I tried reordering Run and Debug - 1. Putting the logic that place Debug before Run or placing Run after Debug did not produce consistent result ( May be I am missing something and someone can help out) 2. Putting the Logic that placing logic after Project works ok.
(In reply to Sarika Sinha from comment #81) > I tried installing WTP, C++, Maven and Xtext and nothing comes between Run > and Debug. Sounds good to me. > Installing "Eclipse SDK Tests" Introduces 2 menus after Run and > before Debug. Can you open a bug for the tests so that we can fix their placement?
In the SDK + EGit, I have the "Git" Menu between "Run" and "Debug" in the "Git" perspective (where I actually often launch tests) My opinion would be too revert it, but I'm biased as I was actually more happy with the single "Run"-Menu (of with I only ever really used the "Run/Debug configurations..."-entry, everything else I do through the toolbar or keyboard)
(In reply to Sarika Sinha from comment #81) > I tried reordering Run and Debug - > 2. Putting the Logic that placing logic after Project works ok. I am sorry but I do not understand what you try to say here.
@Till I don't see any Git Menu in Git perspective. Have you installed any thing else as well? But there is a problem in the ordering with Run and Debug menu. 1. I start with fresh Workspace in Java perspective and see Run and then Debug menu 2. Switch to Debug perspective and see same Run and then Debug menu 3. Switch to Git/CVS perspective and see only Run menu 4. Switch back to Java and Debug Perspective -> Order is changed to Debug and then Run So If we are going to a perspective which does not contribute to Debug and then come back to Java/Debug the order is changed.
(In reply to Dani Megert from comment #84) > (In reply to Sarika Sinha from comment #81) > > I tried reordering Run and Debug - > > 2. Putting the Logic that placing logic after Project works ok. > > I am sorry but I do not understand what you try to say here. I was trying to use after and before for menu location URI to position Debug menu before Run.
(In reply to Sarika Sinha from comment #85) > @Till > I don't see any Git Menu in Git perspective. Have you installed any thing > else as well? I have reset the perspective (I thought I had done that, but I guess I've reset it in the wrong running Eclipse instance), and the git menu is gone. This happens only, if you enable git action set in "Customize Perspective". Sorry for the confusion.
Reverting this fix and moving the bug to M5. The order needs to be consistent for Run and Debug Menu. Git menu also comes in between Run and Debug after enabling it through action set availability. Will have to update the N&N and send a mail to cross-dev mailing list.
New Gerrit change created: https://git.eclipse.org/r/112694
New Gerrit change created: https://git.eclipse.org/r/112695
Need help in reverting CDT Changes.
(In reply to Sarika Sinha from comment #91) > Need help in reverting CDT Changes. They were not merged.
Gerrit change https://git.eclipse.org/r/112694 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=f06c28d1f9e8be37aa0f45c5a79eb22c0ef9c04f
Gerrit change https://git.eclipse.org/r/112695 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3c1e3362f4a8861519f28418ffe5e5aa08c8ab27
New Gerrit change created: https://git.eclipse.org/r/112698
Gerrit change https://git.eclipse.org/r/112698 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5944438e214946432cb920ba3e72b9dd49d1f428
Hoping to see some solution in M6.
I don't have time to look at it, returning back to the team pool.
No one working at it, so removing the target for now.
Please reopen if you plan to work on this.
(In reply to Dani Megert from comment #77) > (In reply to Andrey Loskutov from comment #76) > > So it ends again in the problem that we need a declarative way to define > > "this menu appears *always* next to that one on the right side, and no one > > can be placed between". > > Correct. > > > > I can't really spend time anymore on debugging this I still don't have time, but I have resources now :-) I will add this to our internal tracker, either Simeon or Mykola will work on this (but of course targeting 4.11+).
