Created EclipseEditors1
Unreadable JSON file after plug-in install
Dear all,
this is an old problem that has pretty much lingered ever since the Marketplace was introduced. It has become rather acute with Photon and I believe it should be addressed once and for all.
When opening a number of file types, Eclipse offers to install a specific plug-in from the Marketplace, promising better features (see figure attached). If the user is unfortunate enough to install one of the plug-ins suggested, it will invariably end up with those files associated with an editor that renders them unreadable (figure attached). The files in EclipseEditors1report to JSON files, but the same issue exists for SQL files, Dockerfiles, R files, HTML files. YAML files and many more.
Some sort of quality control must be set in place to avoid broken or poorly designed plug-ins to be inadvertently offered to users.
The Eclipse Platform team does not control the quality of the entries placed on marketplace. As Dani said, it's up to users to report bugs to the right projects, the Foundation nor the community is not here to quality-check every specific extension. Just like Google Play, Steam, Apploe Store... are not doing a strong quality check for everything they enable (except Steam maybe a bit but they're somehow paid for it).
You can still uninstall the plugins you don't want, and in the preferences or with right-click > Open With..., associate the given file-types with other editors if you prefer.
I understand if there are not enough resources to quality control all plug-ins added to the Marketplace, or if it is somehow unpractical. However, that being the case, then Eclipse should simply stop advertising such plug-ins. Every time I open a JSON, HTML, SQL file, etc Eclipse is advertising these plug-ins.
I use Android, Lineage and Ubuntu, none of those systems constantly advertises programmes from its repository like Eclipse does. Conversely, other IDEs based on plug-in systems like GEdit or Atom do not advertise plug-ins like Eclipse, and those that they make available invariable work out of the box and integrate seamlessly with the IDE.
Please do not dismiss this issue, it is a real problem. Eclipse deserves a more careful integration with the Marketplace.
Please provide a concrete proposal of how this can be improved technically or in term of process and clarify whether you're ready to offer the resources necessary for this to happen.
Unless we get a clear and sustainable improvement proposal, this ticket is hardly actionable and would better be closed.
then Eclipse should simply stop advertising such plug-ins
Define "those" ;) I think you mean "those with insufficient quality" which so far, we agreed is something that shouldn't be the responsibility of the Foundation nor community of developers to do. So we don't have criteria to decide what to advertise or not so far. Once we have criteria defined and affordable process to ensure a given marketplace solution matches those criteria or not, then we can try to only advertize "good enough" solutions.
I'm personally pessimistic about ability to find a good solution to those 2 problems about.
In the meantime, it's either we advertize them all or none; and according to wider community feedback about marketplace suggestions for unsupported file types or other things, it seems like the vast majority of users do prefer Eclipse IDE to advertize all solutions.
Also, I'd like to repeat again what Dani said earlier: the best way to improve quality is not to prevent bad quality entries from being advertize, but to report any bugs you find to any plugin to its author.
IMHO, the energy you're spending in this discussion would have a more efficient and positive impact if you identify which marketplace plugin is erroneous, and report a bug to this specific plugin.
I already provided a proposal, it is in the title of this report. If you wish to continue advertising plug-ins then some alternative should be devised. Every time I open a PHP file, a SQL file or an HTML file, my interaction with Eclipse is interrupted and I need to close the advertising dialogue. Take for instance the panel that appears on the lower left with the news: useful and non intrusive. Something alike could be shown, perhaps when Eclipse starts, with a message like: "You edit PHP files, check out these PHP plug-ins at the Marketplace".
Interesting comment regarding energy spent. If I were to report this issue to all the plug-ins affected it would certainly be more time consuming. In fact, it is easier to list those plug-ins I use that are not affected, they are only two: TexLipse and PyDev. This means that about 90% of the plug-ins I have installed have the foreground colours issue. Even staples like StatET or DBeaver are affected. Which again leads me to wonder if there isn't something more fundamental with the workbench at play here. I have a hard time believing that so many good developers purposely ship plug-ins that do not function out-of-the-box.
And mind again the comparison with other IDEs. Even for a simple tool like GEdit there are dozens of plug-ins that integrate seamlessly. Why isn't it the case with Eclipse?
I already provided a proposal, it is in the title of this report.
As we've already discussed. The proposal in the title in not doable because in the current form it requires quality checks, which are not affordable for our community.
If you
wish to continue advertising plug-ins then some alternative should be
devised. Every time I open a PHP file, a SQL file or an HTML file, my
interaction with Eclipse is interrupted and I need to close the advertising
dialogue. Take for instance the panel that appears on the lower left with
the news: useful and non intrusive. Something alike could be shown, perhaps
when Eclipse starts, with a message like: "You edit PHP files, check out
these PHP plug-ins at the Marketplace".
Ok, that's an interesting proposal but it's different from your initial one.
Please open another ticket to Technology > MPC to suggest a way to switch from a pop-up to a notification.
Interesting comment regarding energy spent. If I were to report this issue
to all the plug-ins affected it would certainly be more time consuming.
Maybe, but it would fix issues and make the world much better; while your approach currently leads to keep issues and implement elsewhere strategies to hide them.
This means that about 90% of the plug-ins
I have installed have the foreground colours issue. Even staples like StatET
or DBeaver are affected. Which again leads me to wonder if there isn't
something more fundamental with the workbench at play here. I have a hard
time believing that so many good developers purposely ship plug-ins that do
not function out-of-the-box.
Might be true that Platform can improve something. But it needs to start from the issue in the right plugin and then move down to the right layer upon investigation.
Or maybe open a bug against Platform to specifically talk about this color issue. But please keep your ticket specific to one issue or another, it's impossible to properly discuss, track and plan progress with tickets talking about 4 or 5 different issues and unrelated proposals. Multiple tickets FTW.
this ticket has been developing in multiple directions, for which I apologise, but it appeared as a single issue at the beginning. Below is a short digest of the different issues uncovered and how they can be followed upon.
Many (most?) of the plug-ins provided at the Marketplace are buggy
--------------------------------------------------------------------
I am now convinced this is not the case, the foreground colours issue appears to be a consequence of the core architecture itself (more about this in point 3.). Moreover, as Mickael Istria comments above, there is no thorough way to address plug-in quality issues, apart from letting the community sorting it out by itself. There is thus no practical action to take on this point.
Intrusiveness of the Marketplace advertising dialogue
--------------------------------------------------------
Here there is an actual problem to consider, since this dialogue constantly interrupts interaction with the workbench. However, it is not an issue if the plug-ins it promises function seamlessly (in such case it only needs to show once). As long as point 3 is addressed, the advertising dialogue is not worrying. However, it might be worthy to study alternatives as the one I proposed earlier. To be followed with a new feature request.
Integration of plug-in text colour schemes
---------------------------------------------
Here resides the real issue. Testing the waters, I reported the foreground colour issue in the Json-Eclipse-Plugin bug tracker [0]. The discussion that ensued confirmed my suspicions that this is an issue with the architecture of the Workbench itself and not with the plug-in. Eclipse provides three different themes: Dark, Light and Classical, each with different default text editor backgrounds. The plug-in developer has no way of knowing which of these the user has set and simply targets one at random. It is left to users of the other two themes to figure out by themselves how to integrate the plug-in colour-wise. It would be preferable for plug-in developers to create colour-agnostic text schemes, i.e. tagging specific text elements, instead of explicitly defining colours. E.g., in a SQL plug-in the developer would specify "CREATE" as a keyword, instead of explicitly associating it with colour #FF00FF. From what I could gather, this how GEdit functions. I feel this to be a relevant issue that should be treated as a bug.
Any further feedback welcome, particularly on how to best proceed with points 2 and 3.
The plug-in developer has no way of knowing which
of these the user has set
That's wrong. There is all necessary API (ColorRegistry, ThemeManager) to have a plugin listening to the theme (and more specifically to the background color of the editors) to take decisions. Extenders can also inspect the actual widgets they're using for the actual color they're using instead of assuming things.
The issue is that many developers hardcode and duplicate color definitions instead of asking the right API for hints.
and simply targets one at random.
That's a bug in 3rd party plugins then, as mentioned above, there are already ways to do things better.
could you please leave here reference(s) to the documentation of that API? As you can see from the exercise above, developers seem unaware of its existence. This bug report will likely be an important reference to solve these issues in the future.