Community
Participate
Working Groups
Plug-in Spy has recently been "Simon Archer" approved. This is a good time to consider moving Plug-in Spy to its rightful home within PDE proper. Plug-in Spy currently lives in the incubator (http://www.eclipse.org/pde/incubator/spy/) and I'm proposing that we consider moving it to org.eclipse.pde.runtime What are people's thoughts?
I think it is really cool and we can continue to evolve it inside PDE. However, do we want to do something about the sickly yellow before we do?
anything Simon approved gets my vote... (yellow or not)
ok, I'll make it white, just your eyes. Check out the latest version Dejan: http://www.mea-culpa.net/pdespy/ Base your comments of that. I added some enhanced functionality.
I updated the copy on the update site it was bad. Adding other interested parties to cc.
+1 to move it inside PDE proper.
+1 (if community vote counts ;-) This plug-in will certainly become an important tool for developers and probably reduce the amount of support Eclipse committers have to provide. Delivering it as part of PDE will accelerate its adoption.
+1. I wonder if it should get a slightly less prominent shortcut in order to leave that one for tools building on the SDK.
+1. I was thinking exactly the same thing regarding the F9 shortcut. I can think of at least one application that uses F9 for its own purposes. While a Ctrl+, Shift+, or Alt+, combination is more cumbersome, it is also less likely to collide. Maybe we need a way of configuring this via the preferences, although I realize how much some people hate to add another preference.
Are people cool with the org.eclipse.ui.forms dependency? If so, I'm going to prepare a patch for all the stuff around your active selection. I'm going to hold off on the menu support post M3 as that's a lot more work. Also, what do people want the shortcut to be? I'm thinking Ctrl+Shift+? seems reasonable. That seems fair and not used anywhere. Or does anyone have a more prominent idea? Shift+F9?
(In reply to comment #9) > Are people cool with the org.eclipse.ui.forms dependency? Fine with me, in part because I can't imagine shipping an RCP app without forms, and in part because I see this used mostly as a tool by people who already have PDE installed. > Also, what do people want the shortcut to be? I'm thinking Ctrl+Shift+? seems > reasonable. That seems fair and not used anywhere. Or does anyone have a more > prominent idea? Shift+F9? I like Ctrl+Shift+? because it is easy to remember. I don't think it's taken by anything in the SDK but am not sure about other extensions. Mylyn uses Ctrl+Shift+Alt+? for it's UI Legend, but that's just for consistency with our other Ctrl+Shift+Alt+<arrow> shortcuts and I'm not sure there is much utility to having a keybinding for that, should you want to use that one in case you find a conflict for Ctrl+Shift+?
I dropped the preliminary version of Plug-in Spy in org.eclipse.pde.runtime. It will appear in the next I-build. To invoke it, simply press Alt+Shift+F1 (M3+M2+F1). I'll be doing some refactoring and taking care of bugs as they come in. The spy is still in need of love, but is ready for testing.
Chris, I suspect the pde.runtime plug-in is a temporary location for it, not permanent? It really does not belong there and will not be welcomed by people who include this plug-in into their standalone app.
(In reply to comment #12) > Chris, I suspect the pde.runtime plug-in is a temporary location for it, not > permanent? Negative, it's a permanent location. > It really does not belong there and will not be welcomed by people who include > this plug-in into their standalone app. Why not? Forms was only added as a dependency (with other optional dependencies). And for a minor amount of code, people now get inspection of their RCP application for free. I not only think people will welcome it, but roll out the red carpet once they realize the benefits of having it there. The only case I can envision where people wouldn't welcome it if they just used the error log and nothing else. The problem with that is, that we don't ship the error log by itself, it comes with the plug-in registry. Are you advocating I create a org.eclipse.pde.runtime.spy plug-in to house the goodies?
That is exactly my use case. I only want the log view in my application. I already get the plug-in registry view and I can live with that. Adding more "cool" functionality that I don't need, particularly ones related to plug-in development internals like figuring out the type of my selected object into any RCP application is IMHO a mistake. I don't need it. I don't want it. Dumping stuff in this lightweight plug-in would be one more reason to use XSLT to take out the extra undesired function. I suggest you take a look at one of the responses on your 'product bastardization' blog which supports my case.
(In reply to comment #14) > That is exactly my use case. > > I only want the log view in my application. I already get the plug-in registry > view and I can live with that. If you only want to get the logview in your application, shouldn't you be advocating to create another plug-in/feature for that :)? Having the two views intertwined anyway is weird... people usually just want the log view and don't care about the plug-in registry view. I can see your point here. In M3, I'll work on separating out the Plug-in Spy in another plug-in then in your honor, see bug 202878.
I'd be very content if the log view was in its own plug-in, but it's not high priority for me. Although I am sure it is for others. As for having it outside the PDE feature as a separate feature, this idea was shot down by the Eclipse Supreme Court every time it came up at a council meeting. You will have to wait for enough new people on the Supreme Court to overturn that decision. (bug 50517)
If the help system can get a new feature (bug 202160), I'm sure we can too :)
Interesting, I figured refactoring out the Log View came up before, but I didn't know there was a specific bug for it. It seems that this request has come up again (bug 202044). Personally, I tend to agree with Chris. To me, the log view seems to be something that is helpful to all users (end users, developers, system admins). I don't believe end users will care much for which extensions they have installed. This view has always been more of a development tool in my mind. I see PDE Spy being in a similar category of development tooling. Maybe it is time we try to bring this up again to the Eclipse Supreme Court :)
I think PDE Spy is noteworthy, don't you? :) Chris, nice job getting this from conception into PDE in a matter of weeks. It looks really nice
reopening to assign to me, and closing again.
Plug-in Spy is dropped for M2. It will spy: - selections - wizards - preference pages - dialogs
