Community
Participate
Working Groups
It has been discussed several time on various lists (e.g. [1]) that Eclipse should offer a "registry of plugins" that contribute editors for given file extensions. With such a registry, a user who wants to edit a file she has no matching editor installed for, Eclipse could open a dialog with recommended plugins/features to install which can edit such files. Many ideas are floating around how to implement that, which have been omitted here for brevity. [1] https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00844.html
(In reply to Marcel Bruch from comment #0) > a user who wants to edit a file she has no > matching editor installed for, Eclipse could open a dialog with recommended > plugins/features to install which can edit such files. +1
(renaming to give a user focus to the request)
Marcel, I wonder if that would be a feature that could use some of the code recommender capabilities? If we look into the file types, the directory structure, stuff inside the files etc. Then a recommendation system similar using some statistics based recommendation could assist users in a spectacular way....
Here is a video description of a draft implementation of the client-side of that feature (with horrible audio, don't put high volume!): https://vid.me/HMCv The change in Platform to modify handling of unknown file types is bug 90292. The code of the strategy I'm using is in the branch "suggestInstallationForUnknownTypes" of the "jbosstools-playground" repo, under "bundles/org.jboss.tools.playground.refreshment": https://github.com/jbosstools/jbosstools-playground/tree/suggestInstallationForUnknownTypes/plugins/org.jboss.tools.playground.refreshment . The dummy JSon registry is in the plugin. The issue that prevent Dockerfile and hprof editors to open right after installation: bug 485227 ; and more generally the dynamic handling of extensions (bug 485229).
I just wanted to add a note on this saying that plugins should actually register in the eclipse marketplace to say which are the extensions they support (so, this should probably be a joint venture on the Eclipse IDE side and Eclipse Marketplace).
(In reply to Fabio Zadrozny from comment #5) > plugins should actually register in the eclipse marketplace to say which are > the extensions they support Assuming there are numerous plugins on marketplace supporting a file-type, with very different features and very different level of quality, would the best solution be to propose all plugins to the user and let them pick one? I believe it would work, since the MPC client shows the number of installs/stars.
Yes, I think this is the best option (we may show which ones are more popular, but in the end, it should be up to the user to select which one he wants to use -- eclipse itself should probably be careful not to take sides here... just let the community speak through installs/stars).
How about we crate a new field called Compatible file extensions? Listing owners will be responsible for adding all the file extensions in this field. This could be a free-form tag field or a predefined list of file extensions. We can then add this data to our Marketplace REST api calls and then we can create a new call that allows us to search Marketplace for a listing with a specific file extension.
(In reply to Christopher Guindon from comment #8) > How about we crate a new field called Compatible file extensions? > Listing owners will be responsible for adding all the file extensions in > this field. This could be a free-form tag field or a predefined list of file > extensions. > We can then add this data to our Marketplace REST api calls and then we can > create a new call that allows us to search Marketplace for a listing with a > specific file extension. That sounds like the perfect solution.
New Gerrit change created: https://git.eclipse.org/r/67224
(In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/67224 This Gerrit change simply looks up for a fileExtension_${extension} query on marketplace for given files. It requires a nightly build of Platform M6. For testing purpose, I tweaked the SWTBot marketplace entry to add the fileExtension_dummy tag. So if you have this strategy enabled via preferences and create a file called "test.dummy", then it suggests to install SWTBot.
(In reply to Mickael Istria from comment #11) > This Gerrit change simply looks up for a fileExtension_${extension} query on > marketplace for given files. I asked some projects to add that tag. So you can use them to test the suggested patch (require Platform nightly as target platform). Supported files ATM are python, ceylon, xtend, xtext, scala, hprof. More to come, but that's already good for testing. Concretely, I would like it to be part of Neon. Any help is welcome.
Hello All I came here invited by Mickael Istria email > Could you please add the tag 'fileExtension_xxx' for the entries that support type xxx? And I just did so for https://marketplace.eclipse.org/content/markdown-text-editor and https://marketplace.eclipse.org/content/minimalist-gradle-editor , that should be enough for testing. Can do more, when bug is closed. Note some plugins have multiple extentions, e.g. Markdown Editor has extensions="txt,md,mdown,markdown,mdwn" https://github.com/winterstein/Eclipse-Markdown-Editor-Plugin/blob/master/plugin/plugin.xml#L9
(In reply to Paul Verest from comment #13) > Note some plugins have multiple extentions, e.g. Markdown Editor has > extensions="txt,md,mdown,markdown,mdwn" You can specify multiple fileExtension_md fileExtensions_mdown... on a single marketplace entry.
I believe this contribution is in a good enough state to be part of M6. Do you think it's a realistic goal? What could I do to help making this happen?
Gerrit change https://git.eclipse.org/r/67224 was merged to [master]. Commit: http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=515bb87b4229de948af1beb0d6fb009185b0825c
Awesome, thanks Carsten! This feature will be available as part of the Neon M6 release. I suggest we leave the current strategy by default, try extensively this one against M6, and if it's acceptable make the MPC strategy the default way to handle unassociated files.
Now that the change in merged in MPC, you can try it more easily: 1. Download a I-Build of Eclipse Platform 2. Install MPC from https://hudson.eclipse.org/mpc/job/epp-mpc-ci/lastSuccessfulBuild/artifact/org.eclipse.epp.mpc.site/target/repository/ 3. Get to the File/Editors associations preference page, change default strategy to "Search marketplace" 4. open an unassociated file.
With current EPP staging build at https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/230/artifact/org.eclipse.epp.packages/archive/ , one can simply download a package, get to Preferences > File Association and use "Seach marketplace" strategy for unassociated files to take advantage of this discovery. There are still some relatively small things to improve in this strategy (such as bug 490418 ), and some help with that would be really welcome. However, I believe that the functionality is already good enough to consider making it the default for Neon. Does it require some more approval to change this in EPP packages or just having package maintainers ok with that is enough?
(In reply to Paul Verest from comment #13) > ... Hey Paul, I see several tags that you could add to MP entries you created: * fileExtension_c fileExtension_cpp fileExtension_cxx fileExtension_h ... to CDT * fileExtension_sql to DTP * fileExtension_dart * fileExtension_coffee
(In reply to Mickael Istria from comment #20) > (In reply to Paul Verest from comment #13) > > ... > > Hey Paul, I see several tags that you could add to MP entries you created: > * fileExtension_c fileExtension_cpp fileExtension_cxx fileExtension_h ... to > CDT > * fileExtension_sql to DTP > * fileExtension_dart > * fileExtension_coffee DONE, except for .coffee that is dead.
Video showing current status with Neon M6: https://sendvid.com/6rrytez5 The only remaining thing is to set the preference to use Marketplace by default on EPP packages.
It is a nice proof of concept. I think the workflow needs to be refined to not directly take the user to the market place because there are cases where I'm just happy to see the files in plain text (for example I'm not sure what I'm looking for, I just need to look at the text, etc.). As such I see two possible improvements: - prompt to give a choice "do you want to search for a specific editor" - open the editor and search for an appropriate editor in the background On a similar topic, I think that it may worth prompting the user to install support for other file extensions that are available in the workspace and are not covered. In the context of your video, this would mean that in addition of prompting the user for dart file, you would also prompt him for the python files.
> It is a nice proof of concept. Thanks. But to be clear it's not meant to be only a proof of concept: it's already in the IDE and since it can be a major boost for the community and users, I consider it as something that needs to be on by default in Neon. We have 1 month to complete that so help is highly welcome and patches can be provided to MPC. (In reply to Pascal Rapicault from comment #23) > I think the workflow needs to be refined to not directly take the user to > the market place because there are cases where I'm just happy to see the > files in plain text (for example I'm not sure what I'm looking for, I just > need to look at the text, etc.). > As such I see two possible improvements: > - prompt to give a choice "do you want to search for a specific editor" > - open the editor and search for an appropriate editor in the background IMO, the discovery of the best editor is more important than the user-story you mention here because it "enables" user to do things that they could have missed earlier. So having it popping up directly seems fair. There are already several ways to achieve this user story here with MPC: * User who knows a best editor for a file can go to the preferences and associate it * User who wants a specific editor for the file can use Right-click > Open With * If a user cancels MPC proposals, they're prompted with the editor selection dialog that allows 1-time or persisted association with an existing editor. > On a similar topic, I think that it may worth prompting the user to install > support for other file extensions that are available in the workspace and > are not covered. In the context of your video, this would mean that in > addition of prompting the user for dart file, you would also prompt him for > the python files. Although I agree it's a nice to have, I don't think it would provide a lot of value or even be nice for users. This example project I used is a good example: it is by far mainly dart files, and there are very few Python file, it can be quite probably that a user simply will never open the Python file and wouldn't like to be annoyed by PyDev popups. The clear advantage with current approach is that the editor is suggested when user needs it, when user requests to edit the file. It's easy to control and understand for the user, and integrated well in their desired workflow without introducing new UI; compared to a background job that would suggest to install half a dozen solutions on each project import.
As per Mickael Istria's email request, I'm adding the fileExtension_* tags for the RustDT, DDT, and Goclipse Marketplace entries. However, note, I think this will be of limited use to the respective languages. Unlike XML, yaml, json, dockerfiles, etc., they are very unlikely to appear on a project where they are not the primary language. *But more importantly*, those IDEs (to different degrees), require the user to download and configure external tools for most of the IDE functionality. For example, although DDT can provide an editor outline and code completion on its own, Goclipse and RustDT require external tools for that functionality. So installing them from the Marketplace doesn't make everything work out-of-the-box. I'll leave it up to you to decide if that's ok or not for the goals of this FEEP issue.
(In reply to Bruno Medeiros from comment #25) > As per Mickael Istria's email request, I'm adding the fileExtension_* tags > for the RustDT, DDT, and Goclipse Marketplace entries. Thanks Bruno. I believe this will be highly appreciated by users that will immediately see that Eclipse IDE can support Rust, D or Go. > However, note, I > think this will be of limited use to the respective languages. Unlike XML, > yaml, json, dockerfiles, etc., they are very unlikely to appear on a project > where they are not the primary language. I have a friend who is a D developer and who wanted to try out Eclipse. First thing he did was opening the .d file and saw a basic text editor. He was disappointed. I had to explain him to get to Marketplace and install DDT. If I were not there to explain him marketplace, he may have missed it. > *But more importantly*, those IDEs (to different degrees), require the user > to download and configure external tools for most of the IDE functionality. > For example, although DDT can provide an editor outline and code completion > on its own, Goclipse and RustDT require external tools for that > functionality. So installing them from the Marketplace doesn't make > everything work out-of-the-box. Since Eclipse doesn't have a mechanism to define dependencies on other non-Eclipse tools, I believe it's still the responsibility of the editor to suggest installation of necessary tools. IIRC, it was ADT was going: installing ADT Eclipse plugins was running fine; but on first generation of an Android project, the nature was checking for availability of the SDK and suggesting configuration/installation. > I'll leave it up to you to decide if that's ok or not for the goals of this > FEEP issue. Dependency on external tools is another story IMO, but indeed a more and more important one.
(In reply to Mickael Istria from comment #26) > I have a friend who is a D developer and who wanted to try out Eclipse. > First thing he did was opening the .d file and saw a basic text editor. He > was disappointed. I had to explain him to get to Marketplace and install DDT. > If I were not there to explain him marketplace, he may have missed it. > Really? Was he expecting it because IntelliJ does something similar? AFAIK, I don't know of any other IDEs that do such a thing, other than perhaps web or cloud based IDEs (which are a fairly different beast). > > I'll leave it up to you to decide if that's ok or not for the goals of this > > FEEP issue. > > Dependency on external tools is another story IMO, but indeed a more and > more important one. I didn't mean to imply this is a story Eclipse can realistically tackle. There would need to be some sort of universal, meta, cross-platform package manager for this to work.... one can only wish...
(In reply to Bruno Medeiros from comment #27) > Really? Was he expecting it because IntelliJ does something similar? AFAIK, > I don't know of any other IDEs that do such a thing, other than perhaps web > or cloud based IDEs (which are a fairly different beast). Yes, IntelliJ does something similar. But he's not an IntelliJ user. He was simply just curious about Eclipse IDE, but doesn't know anything at all about it. So he wasn't aware of the marketplace, and not much aware of the community tools actually (except DDT he's read about on forums or so). IMO, we should never expect from users any knowledge about how Eclipse works, and we should consider the average user as someone with a "relatively low curiosity for the IDE". So we have to offer them the features in their workflow more than relying on their curiosity to find appropriate extensions.
This looks very cool but I agree the workflow and UI could be improved. It seems odd to me that a user tries to open a file and we automatically show the MPC. The MPC is also not shown in an context of explaining what the user needs to think about doing. It would seem to me we need a new UI wizard that is specific to installed a new editor for this file type.
(In reply to Pascal Rapicault from comment #23) > I think the workflow needs to be refined to not directly take the user to > the market place because there are cases where I'm just happy to see the > files in plain text 1) I second Pascal for that, there has to be non intrusive question, without distracting developer from what he has on his mind. 2) Also not in some location it take 20 seconds/1 minute and more before MPC opens and shows something meaningful. (And all this time developer can't even see the Editor for file he/she was clicking!) I bet my hat your have not tested this functionality on really slow and unstable connection (imagine Eclipse on a notebook with 3G modem connection in Africa) 3) Also non intrusive question should have a link to open Preference page where new configuration to use MPC can be changed. A big thank to Mickaelfor video, it really helps to feel as if we are near https://sendvid.com/6rrytez5
4) Also (thinking about example of starting from importing project) would it be nice, when after importing a project IDE would look inside .project and find what natures are there, e.g. <nature>org.eclipse.jdt.core.javanature</nature> could prompt to install JDT. This way some project owners will be encouraged to submit .project files into version control system, so anyone getting code would get Eclipse with needed plugins with Editor (and builders!) before a developer starts clicking though different file types. Should be new issue ticket?
(In reply to Paul Verest from comment #30) > 1) > I second Pascal for that, there has to be non intrusive question, without > distracting developer from what he has on his mind. A pop-up question is distracting as well ;) > 2) > Also not in some location it take 20 seconds/1 minute and more before MPC > opens and shows something meaningful. (And all this time developer can't > even see the Editor for file he/she was clicking!) > I bet my hat your have not tested this functionality on really slow and > unstable connection (imagine Eclipse on a notebook with 3G modem connection > in Africa) OK. The wizard does have a Stop button if it takes too long. However, it doesn't seem to work that well. Can you please submit a separate bug for that? (In reply to Paul Verest from comment #31) > 4) Also (thinking about example of starting from importing project) > would it be nice, when after importing a project IDE would look inside > .project and find what natures are there, e.g. > <nature>org.eclipse.jdt.core.javanature</nature> could prompt to install JDT. > Should be new issue ticket? There is a prerequisite on bug 489540 . You can try the suggested patch and put a comment on the patch.
(In reply to Mickael Istria from comment #32) > (In reply to Paul Verest from comment #30) > > 1) > > I second Pascal for that, there has to be non intrusive question, without > > distracting developer from what he has on his mind. > > A pop-up question is distracting as well ;) The point is not the distraction but the existing workflow is not in context. You are starting the MPC when someone is just trying to open a file. > > > 2) > > Also not in some location it take 20 seconds/1 minute and more before MPC > > opens and shows something meaningful. (And all this time developer can't > > even see the Editor for file he/she was clicking!) > > I bet my hat your have not tested this functionality on really slow and > > unstable connection (imagine Eclipse on a notebook with 3G modem connection > > in Africa) > > OK. The wizard does have a Stop button if it takes too long. However, it > doesn't seem to work that well. Can you please submit a separate bug for > that? Using the Stop button is not the solution. We need a better workflow.
This is an awesome first step but we can definitely not enable this kind of blocking behavior as the default for Neon. Getting a blocking wizard for unknown files is worse than getting the system default editor. I see that we have two options: 1) on open on a file no matter if known or unknown it should immediately do its best to show the editor for it (even if that is just plain text or system default editor), then it should in the *background* do a search on marketplace or wherever and then if and only if a match is found it could use a mylyn style notification (like eclipse aeri is doing) to tell the user it has found one or more options for installing. 2) keep as is for Neon.0, but do not have this be the default in any EPP package and work on #1 for Neon.1 I would definitely prefer #1 if doable.
(In reply to Max Rydahl Andersen from comment #34) > This is an awesome first step but we can definitely not enable this kind of > blocking behavior as the default for Neon. > > Getting a blocking wizard for unknown files is worse than getting the system > default editor. > > I see that we have two options: > > 1) on open on a file no matter if known or unknown it should immediately do > its best to show the editor for it (even if that is just plain text or > system default editor), then it should in the *background* do a search on > marketplace or wherever and then if and only if a match is found it could > use a mylyn style notification (like eclipse aeri is doing) to tell the user > it has found one or more options for installing. > > 2) keep as is for Neon.0, but do not have this be the default in any EPP > package and work on #1 for Neon.1 > > I would definitely prefer #1 if doable. +1 I really like #1
(In reply to Max Rydahl Andersen from comment #34) > 1) on open on a file no matter if known or unknown it should immediately do > its best to show the editor for it (even if that is just plain text or > system default editor), then it should in the *background* do a search on > marketplace or wherever and then if and only if a match is found it could > use a mylyn style notification (like eclipse aeri is doing) to tell the user > it has found one or more options for installing. +1 It might also be good to add something to the Welcome screen to remind the user that the functionality is available in case they miss the tray notification.
(In reply to Max Rydahl Andersen from comment #34) > This is an awesome first step but we can definitely not enable this kind of > blocking behavior as the default for Neon. > > Getting a blocking wizard for unknown files is worse than getting the system > default editor. I agree with regard to just popping up MPC. I have to admit though that I'm a bit sad about the decision on bug 486647 to not ask the user to choose an editor. My personal preference would have been to have similar behavior as most OS strategies: If we don't know the association, present the user with available editor choices, including one to "Find new editors..." or similar that could then trigger the MPC discovery. That would have the upside that it would also make it easy to add a file association/content type config for existing editors to new file extensions (XML is a typical case here). > 1) on open on a file no matter if known or unknown it should immediately do > its best to show the editor for it (even if that is just plain text or > system default editor), then it should in the *background* do a search on > marketplace or wherever and then if and only if a match is found it could > use a mylyn style notification (like eclipse aeri is doing) to tell the user > it has found one or more options for installing. Given the above, I like this workflow as well. As another part of the user experience discussion, after deciding if/when to pop up a discovery wizard, Ian brought up the question on bug 490418 what that should actually look like: (https://bugs.eclipse.org/bugs/show_bug.cgi?id=490418#c5) > Why don't we create a new wizard that is specific to discovery for file > association? It seems like a much better approach than force fitting the > existing MPC wizard. I think this is a typical scenario where we would usually show a discovery wizard, like the one for SVN or Mylyn connectors. MPC is a variation of that discovery wizard, but I agree that the additional UI (tabs, search area) don't add to this scenario and might even cause confusion. Nevertheless, both from a community and a technical perspective, I think that Marketplace is best equipped to handle this particular discovery case. And some of the richer UI in MPC, like the presentation of install numbers and favorite count in entry listings, do add value when making a choice between competing editors for the same file type. So I would suggest to show MPC with a stripped down first wizard page in line with "plain" discovery wizards, without the tabs and search widgets.
(In reply to Carsten Reckord from comment #37) > My personal preference would have been to have similar behavior as most OS > strategies: If we don't know the association, present the user with > available editor choices, including one to "Find new editors..." or similar > that could then trigger the MPC discovery. That would have the upside that > it would also make it easy to add a file association/content type config for > existing editors to new file extensions (XML is a typical case here). Ok, why not. However, there are many XML-based file formats that have better editors on marketplace than the embedded one. In such case, user can very easily miss the availability of more appropriate tools. Would others also like it better? I can try to extend the EditorSelectionDialog to add a "Search Marketplace for other editors" option.
Mickael, can you update this bug on what approach you are taking for this bug?
I submitted a few weeks ago a patch about bug 491703 to run most of editor discovery in background and avoid blocking users in the meantime. IMO, this patch is ready to be merged but the review is still pending. Let's continue the discussion on bug 491703 if you have some specific questions or concerns.
(In reply to Mickael Istria from comment #40) > I submitted a few weeks ago a patch about bug 491703 to run most of editor > discovery in background and avoid blocking users in the meantime. IMO, this > patch is ready to be merged but the review is still pending. > Let's continue the discussion on bug 491703 if you have some specific > questions or concerns. Would this work better if we implemented Carsten suggestion instead of using the "tags" field? https://bugs.eclipse.org/bugs/show_bug.cgi?id=491530#c12 I have no doubt that your implementation works but it doesn't feels like the right solution for this new feature. We also need to consider the listing owner here. At the very least, we need to update the marketplace website with some information regarding how to update their listing to use this feature. The description of the "tags" field on marketplace is the following: A comma-separated list of terms describing this content. Example: funny, bungee jumping, "Company, Inc."
(In reply to Christopher Guindon from comment #41) > Would this work better if we implemented Carsten suggestion instead of using > the "tags" field? > https://bugs.eclipse.org/bugs/show_bug.cgi?id=491530#c12 Yes, it would work better. But in the meantime, using tags is currently the only ready-to-use solution I'm aware of. The change about the UI workflow (requested by Ian and others) is independent from the change on server-side/Rest API. As soon as the rest API allows it, we can consider looking for "capabilities" rather than tags.
(In reply to Mickael Istria from comment #40) > I submitted a few weeks ago a patch about bug 491703 to run most of editor > discovery in background and avoid blocking users in the meantime. IMO, this > patch is ready to be merged but the review is still pending. > Let's continue the discussion on bug 491703 if you have some specific > questions or concerns. I'm sorry, I didn't get around to it before M7. I'll try it out tomorrow and expect to be able to merge it as-is. (In reply to Mickael Istria from comment #42) > (In reply to Christopher Guindon from comment #41) > > Would this work better if we implemented Carsten suggestion instead of using > > the "tags" field? > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=491530#c12 > > Yes, it would work better. But in the meantime, using tags is currently the > only ready-to-use solution I'm aware of. > The change about the UI workflow (requested by Ian and others) is > independent from the change on server-side/Rest API. As soon as the rest API > allows it, we can consider looking for "capabilities" rather than tags. I agree, as long as the limit on the listed tags per entry isn't a blocker (bug 491530 and bug 492881). The specialized fields would be cleaner, but given the time frame, let's use what is there and known to work right now. Moving to the capabilities API afterwards should be pretty straight-forward, both in MPC and on the server.
(In reply to Carsten Reckord from comment #43) > (In reply to Mickael Istria from comment #40) > > I submitted a few weeks ago a patch about bug 491703 to run most of editor > > discovery in background and avoid blocking users in the meantime. IMO, this > > patch is ready to be merged but the review is still pending. > > Let's continue the discussion on bug 491703 if you have some specific > > questions or concerns. > > I'm sorry, I didn't get around to it before M7. I'll try it out tomorrow and > expect to be able to merge it as-is. > > (In reply to Mickael Istria from comment #42) > > (In reply to Christopher Guindon from comment #41) > > > Would this work better if we implemented Carsten suggestion instead of using > > > the "tags" field? > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=491530#c12 > > > > Yes, it would work better. But in the meantime, using tags is currently the > > only ready-to-use solution I'm aware of. > > The change about the UI workflow (requested by Ian and others) is > > independent from the change on server-side/Rest API. As soon as the rest API > > allows it, we can consider looking for "capabilities" rather than tags. > > I agree, as long as the limit on the listed tags per entry isn't a blocker > (bug 491530 and bug 492881). I got a +1 from Mickael to go live with my patch, are you o.k with this? If so, I will push this live tomorrow. > > The specialized fields would be cleaner, but given the time frame, let's use > what is there and known to work right now. Moving to the capabilities API > afterwards should be pretty straight-forward, both in MPC and on the server. The webdev team is swamped until the release of Neon. We can commit to work on this for Q3.
First time I encountered the new workflow was when I double clicked on a .launch file. This really makes Eclipse look confused, i.e., not knowing about the meaning of some if its own file formats. Compare this to a .jardesc file, where double click opens the export wizard. So before GA can we make sure all own file formats of "Eclipse" suitably react to double click *without* the detour to market place? I assume in many situations like this, opening a text editor is better than the MPC (where we should know upfront that we won't find a suitable plugin).
I just tested this (by accident) in Neon M7 EPP committers package. The committers package uses the org.eclipse.epp.internal.mpc.ui.askMarketPlace strategy. Here is my honest experience: - new workspace - Open "New Wizard" (cmd+N) - General -> File -> Next - filename: newfile.ini123 - click: finish --> file has been created (can be observed in Package Explorer) --> I get an empty MPC dialog (WTF #1) - click: cancel --> back in the "New File Wizard" (WTF #2) - click: finish --> I get an empty MPC dialog (WTF #3) - click: cancel --> back in the "New File Wizard" (OMG #1) - click: cancel --> I get an empty MPC dialog (FML #1) - click: cancel --> Editor Selection dialog pops up (OMG #2) - click: cancel --> finally :) That's three WTF, two OMG and one FML. I'm sorry folks but this should not go live this way in the Neon release. The UX is terrible and will cause frustration. A few things to consider: - don't bring up the MPC dialog if there is "0" (zero) results - don't bring up the MPC dialog at all if a users clicks "finish" in "new file wizard" instead of "next"; there is always an expectation that finish really means finish - instead of throwing the MPC dialog at users, at least tell them why ("there is no editor for XYZ") and ask if they want to do this ("do you want to search the marketplace"); the dialog can have checkboxes for "always search" - instead of cluttered dialogs integrate the flow as pages this into the "new file wizard"
@Stephan @Gunnar: your use-cases are covered by the bug 491703 and associated patch. Feel free to give it a try and comment on the review.
(In reply to Mickael Istria from comment #47) > @Stephan @Gunnar: your use-cases are covered by the bug 491703 and > associated patch. Feel free to give it a try and comment on the review. Perfect!
(In reply to Mickael Istria from comment #47) > @Stephan @Gunnar: your use-cases are covered by the bug 491703 and > associated patch. Feel free to give it a try and comment on the review. Assuming that bug 491703 will provide the promised relief, can that one please be considered a blocker? Currently, bug 491703 has very little attention (no Cc:, no progress for one month and it just missed RC1).
(In reply to comment #49) > Currently, bug 491703 has very little attention (no Cc:, no progress for one month and it just missed RC1). It didn't. MPC's RC1 deadline is next Wednesday...(In reply to comment #46) > - instead of cluttered dialogs integrate the flow as pages this into the "new > file wizard" That could be an additional way to support this, but doesn't solve the problem for people getting an existing project from SCM or elsewhere...
I'd like to also comment a bit more on the "Open in system editor by default" user experience. Right now, the workflow on bug 491703 is to open a default editor (i.e. the system editor if there is one, or otherwise a plain text editor) and then search for a better one in the background. In principle I agree with all the arguments made for going with the system editor from earlier comments. But only if that actually does open an editor. Since the code for opening the system editor currently essentially does a Program.launch(fileToEdit), this isn't necessarily the case: For example, I have Python for Windows installed on my machine. That does bring an editor for .py files, but the default file association is for the Python interpreter to run the file. So "Open with system editor" really means "Execute the script" in this case. The effect is that most of the time, a shell window will flicker up for a split-second, and that's it. Feels pretty broken. I guess for shell scripts, Windows .bat files and similar, it could cause some even nastier surprises if they are run instead of opened for editing. I'm not sure if this is technically feasible, but at least in Windows, many files actually have these context menu contributions in the Explorer of the form "Edit with <editor>". I'm not sure if there is any way to access those to act as "system editors" - probably not across platforms. In any case, I'd feel more comfortable with opening a plain text editor if we can't check for the "safety" of the system editor. But I wouldn't consider that a blocker for this bug, since the system editor has been the default for a long time now.
@Carsten: interesting note. I believe it's not that related to the current issue about discovery, but it's definitely something that should be reported against Platform if not already (distinguish editors and runtimes).
Adding dependency to 493600 about notifying marketplace contributors, It's not a blocking or technical dependency, but something critical to fully take advantage of that feature.
Does this feature provide a way to match full file names rather than just file extensions? It's common for files bearing set names, but a generic file extension to be associated with a specific editor. For instance, "web.xml", "weblogic.xml", etc.
(In reply to Konstantin Komissarchik from comment #55) > Does this feature provide a way to match full file names rather than just > file extensions? It's common for files bearing set names, but a generic file > extension to be associated with a specific editor. For instance, "web.xml", > "weblogic.xml", etc. Not at the moment. Since Eclipse does have an editor for *.xml file, then it will assume that those files are already supported (as XML files, by XML editor) and won't even trigger a discovery.
Thanks. I have opened Bug 494050 to track extending this awesome feature to cover full file name binding.
I have tried out this feature with Sapphire and *.sdef files. It seems to work well. Thanks! Here are some UI polish feedback items: 1. The dialog is missing a title. 2. The body margin needs to be fatter to match the standard used elsewhere in Eclipse. 3. Radio button labels should not end with a period. 4. Apostrophe should not be used as a quoting method for end-user facing text. I don't think there is really a need to quote the references to the extension. 5. References to the marketplace should be "the Eclipse Marketplace". The "Eclipse" part is important as that's how it's referenced under the Help menu. 6. I would recommend not using the banner dialog in this context. It just forces unnecessary text repetition and doesn't add anything to UX. Thanks for reading.
On functional level, it would be good to close the text editor if user decided to proceed with marketplace option. Otherwise, post install and restart, it looks like something went wrong since the file is still opened in the text editor. You have to close/reopen to see the installed editor.
(In reply to Konstantin Komissarchik from comment #58) > (various UI suggestions) tracked in bug 494363
There are no more blocker and the functionality works fine. New improvements or issues can now be tracked as regular issues against Marketplace or MPC.
(In reply to Mickael Istria from comment #61) > There are no more blocker and the functionality works fine. > New improvements or issues can now be tracked as regular issues against > Marketplace or MPC. Hi Mickael, I have one issue there -- although this may be very particular to LiClipse and LiClipseText -- the tags field limit doesn't allow entering all the supported languages. As this seems to be an issue on the marketplace homepage side, where should it be reported?
(In reply to Fabio Zadrozny from comment #62) > As this seems to be an issue on the marketplace homepage side, where should > it be reported? In Eclipse Foundation > Marketplace: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Marketplace Cheers
Thanks, just reported https://bugs.eclipse.org/bugs/show_bug.cgi?id=494649 As a note, are there plans to create a separate field for that? The visualization of https://marketplace.eclipse.org/content/liclipsetext seems a bit strange because the tags are being used for this purpose.
(In reply to Fabio Zadrozny from comment #64) > Thanks, just reported https://bugs.eclipse.org/bugs/show_bug.cgi?id=494649 > > As a note, are there plans to create a separate field for that? The > visualization of https://marketplace.eclipse.org/content/liclipsetext seems > a bit strange because the tags are being used for this purpose. Yes, there a plans to create a new field to manage file extensions/genral capabilities. We will need to migrate all the existing fileextention_* tags to this new field. This is a temporary solution. It was the quickest way to get something done without making any major changes to the website before Neon. I would like to create something close to what Carsten is suggesting here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=491530#c12
(In reply to Fabio Zadrozny from comment #64) > Thanks, just reported https://bugs.eclipse.org/bugs/show_bug.cgi?id=494649 > > As a note, are there plans to create a separate field for that? The > visualization of https://marketplace.eclipse.org/content/liclipsetext seems > a bit strange because the tags are being used for this purpose. It's important to note that if your listing has a commercial license and you are not an Eclipse member, it will not show in MPC. Web Request: https://marketplace.eclipse.org/category/free-tagging/fileextension_mako/api/p Request made by MPC: https://marketplace.eclipse.org/category/free-tagging/fileextension_mako/api/p?client=org.eclipse.epp.mpc.core As you can see LiClipseText (EPL) is included BUT LiClipse (Commercial) is missing from the MPC call.
