Community
Participate
Working Groups
I know Anton did work to click on a service link name and see the properties dump in the console. I thought this was a pretty cool solution for seeing the properties without cluttering the more user oriented plugins page. However, I can't seem to make it work. I clicked on the name, nothing happens in Chrome or FF, or at least I don't see stuff in my console. I think that either I didn't understand how to invoke the feature, or maybe it was not released yet. I think we need some way to see the properties or else we really are going to have to leave a link to the old plugins page handy. That is why I'm marking this RC1...so we can decide what to do
When you see a 'JavaScript Object' as a value for an item in a service table in the carousel, you can click on that to see a live dump of the object in the console. That string will change color when hovered over, and offers a tooltip. This is a backdoor way for now - taking advantage of the object traversal in the console, as opposed to building our own ui - ultimately, I think if you have to start digging into the object itself it is the land of debug, and this plugins user interface is arguably not the place for that data. I even have qualms about including what I did, but figure it is discreet and doesn't impact users that don't want to know more. The old plugins page only offered a print of the object [object][object] etc. I've tested this on what was committed and it seems to work for me - not on IE though, since its console doesn't offer the capability that the others do.
Sorry, I just misunderstood the feature when we were talking about it ST. I thought that clicking on the service name "orion.page.link" etc. would cause a dump of all the service properties (vs. just a dump when you click the object one). Since the bug is open (ha!) I'll retarget it to the longer term issue. As we've discussed before, the plugins page perhaps is the wrong place completely to work with service properties. Maybe the best thing to do long term is a link to a page for service properties. The thins I could imagine wanting: - see and edit service properties live. - see all declarations of a service (such as "orion.page.link") in an aggregated list from all plugins
I have a short term problem in bug 373407.
I've been doing a fair bit of work lately where I have to see various properties and long URI's on the service declarations. I have to say that I find the carousel pattern pretty cumbersome for working with service properties. The crux of the problem as I see it is that services aren't visually distinctive. There's no image thumbnail or other visually distinctive aspect of a particular service definition that makes it worth browsing visually in a carousel. They all look the same really, it's just text and properties. So I'm left to click one by one until I find what I need, and then if the data is complex, it might clip (bug 373407). If I were browsing music albums, or movie posters, or app icons, or anything visually distinctive, a carousel makes more sense. Another issue is that I'm rarely "browsing" the services in a plugin to see what it has implemented. I'm usually wanting to get at something specific. I think we discussed awhile back that the plugins page user wasn't expected to care deeply about the service properties. They are just trying to browse what they have installed, etc. So maybe the service properties don't need to be shown at all, or just an overview of the names of the services. Maybe a carousel makes sense here (what does this plugin do?), if you had icons for each kind of service contribution, you could use a carousel to look at images representing "editor commands" or "banner links" or whatever. (I'm kind of working backwards here, making the data fit the carousel...) For plugin developers that need to see what the service properties are, it's a frustrating view of the world.
I've been thinking about this some more and think I have a pretty simple proposal to solve some of the current pain points with working with plugin service properties without cluttering the end user/plugin catalog view of the world. The "a-ha" I had this weekend is that the service extension data is best navigated via an editor outliner. So it would work like this: * get rid of the service carousel and instead provide a link to something like "plugin services" or "developer info"... * we implement a services.html page that can hash on the plugin (non-hash means all services) * the service page groups the info by service extension point (with an optional plugin filter based on the hash). You can see all services and which plugins contribute them. The plugin info next to the service can show the developer related info. The ones important to me: ** plugin URL (what is installed) ** link to the plugin source. If the user has specified a workspace location, we can edit it. If the user has not, we can open the editor read only * implement an editor outliner for plugins that shows service declarations and editor properties. * you can also filter by service on the page..."show me all orion.page.link extensions". I think this would address the current issues in bug 374604, 373560, 373407, 376540, and 371544 and the implementation is pretty simple: - a tabular list of services - a preference for tying a plugin to its source code - a simple plugin metadata outliner What do you all think? If we think this is the way to go, I can take this bug...
(In reply to comment #5) > The plugin info next to the service can show the developer > related info. The ones important to me: > ** plugin URL (what is installed) > ** link to the plugin source. If the user has specified a workspace location, > we can edit it. If the user has not, we can open the editor read only Implied but not mentioned explicitly, the third thing here ** current metadata values and properties of the plugins. We wouldn't edit them here, but it's important to know what the system thinks the value is vs. what the editor or read only view would show you. This is for the "I pushed to github but gh-pages is taking way too long" scenario, where your source has one thing but the deployed plugin has not caught up yet.
this also means we need a way to open the read only editor on a non-workspace file (at its install location). Not sure we can do that yet. At that point you would never need to link the plugin itself, just to the editor opened on its source.
If this seems the best user interface for services, then I support it, and I'd be grateful if you took the bug, Susan. The only input I have about it is that I spoke with Mark a week or so ago about the problems with the carousel. I agree that the carousel in this case is not appropriate. We looked at the UI Eclipse offers for extensions which is a split list of services on the left hand side and a table entry on the right hand side when each is selected. I had intended to replace the carousel with a similar interface. I could make them appear in the same way from the plugin page in a measured layout. That's my only alternative, but if you think that moving to this new proposed solution is preferable, then let's do that. (In reply to comment #7) > this also means we need a way to open the read only editor on a non-workspace > file (at its install location). Not sure we can do that yet. At that point > you would never need to link the plugin itself, just to the editor opened on > its source.
(In reply to comment #8) > The only input I have about it is that I spoke with Mark a week or so ago about > the problems with the carousel. I agree that the carousel in this case is not > appropriate. We looked at the UI Eclipse offers for extensions which is a split > list of services on the left hand side and a table entry on the right hand side > when each is selected. > > I had intended to replace the carousel with a similar interface. I could make > them appear in the same way from the plugin page in a measured layout. > > That's my only alternative, but if you think that moving to this new proposed > solution is preferable, then let's do that. I don't think these ideas are conflicting at all. I think what you are proposing is a particular way of navigating the services once you get to the new page. I haven't drawn a picture yet of the presentation, I was trying to imagine the workflow at a page level: >* the service page groups the info by service extension point (with an optional >plugin filter based on the hash). You can see all services and which plugins >contribute them. The plugin info next to the >service can show the developer related info. "You can see all services" didn't literally mean they all appear there, though they could. Eclipse PDE has that master/details service list, and the LHS is constructed in different ways. You can see declarations/implementors/or grouped by plugin. So the master-details could work here. To me what's key is that the left and side (whether it's master-details or an outliner) has a switch box/filter that lets you control what appears in the left hand side. Which services? From which plugins? For example I might want to see all the implementations of orion.page.link, or I might want to see all services declared by plugin X. So I think we need some swithc boxes (and URL hashes) to control what's on the left hand side (services per plugin, services of a particular type, etc.) The alternative is the section outliner where you see the same list on the left but can scroll through all of them. I think it depends on how much data is there. (this is going back to bug 368848). We can iterate this. I think the main thing I wanted to point out here is that rather than implementing some kind of form UI for editing the properties, we could use the editor/outliner model to quickly take the user to the implementation. And also that a link to the source is more useful than linking to the plugin itself.
(In reply to comment #8) > If this seems the best user interface for services, then I support it, and I'd > be grateful if you took the bug, Susan. I'll mark it 0.5 with a caveat that I might not get to it. I'll attach sketches when the time comes and hopefully you and Mark can comment...
removing milestone.
moving milestone to 2.0 M1 for future triage.
Simon, did you have plans here?
I can own it for now but will likely delegate at some point.
*** Bug 373407 has been marked as a duplicate of this bug. ***
*** Bug 374604 has been marked as a duplicate of this bug. ***
Created attachment 248925 [details] Display services as resizable scrollable div
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=10006d34287fd55922a83b7df39ed3b75298d7cd Provides more useful text than 'JavaScript Object' for the vast majority of cases.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html
