Community
Participate
Working Groups
When dealing with text editor color, the enablement of the color picker when system color checkbox is on is confusing: it's hard to figure out the widget is disabled, and when disabled, the color is altered (at least on Linux) so we don't get a clear preview of what it is. Instead of disabling the widget, we could have it always enabled and clickable (to get proper preview and save one click). When changing the color, the system color checkbox would be disabled. It would break the master-slave hierarchy between both widgets without any loss.
(In reply to Mickael Istria - away until July 15th from comment #0) > When dealing with text editor color, the enablement of the color picker when > system color checkbox is on is confusing: it's hard to figure out the widget > is disabled, and when disabled, the color is altered (at least on Linux) so > we don't get a clear preview of what it is. Same on Windows but imo the disablement state is easy to spot precisely because you cannot clearly see the preview. Regardless I think your proposal would be better.
Actually, there is no way to get the "native" color easily for those value, so we cannot have the preview in any case, but still, we can improve the enablement.
New Gerrit change created: https://git.eclipse.org/r/146348
Gerrit change https://git.eclipse.org/r/146348 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=c9f6f539682c664d3584670c3450d7aee9ece04b
Causes compile warnings in the build: https://download.eclipse.org/eclipse/downloads/drops4/I20190723-1800/compilelogs/plugins/org.eclipse.ui.editors_3.11.600.v20190723-1417/@dot.html
(In reply to Dani Megert from comment #5) > Causes compile warnings in the build: > https://download.eclipse.org/eclipse/downloads/drops4/I20190723-1800/ > compilelogs/plugins/org.eclipse.ui.editors_3.11.600.v20190723-1417/@dot.html Ok, I'll fix it. Shouldn't we configure prohects so that those warnings are reported as errors in IDE and build? That would decrease theur probability of being submitted and merged.
New Gerrit change created: https://git.eclipse.org/r/146554
Gerrit change https://git.eclipse.org/r/146554 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=dddf4f29b8a5d889d41e8e89d6aeadb0fdf9d6f3
(In reply to Mickael Istria from comment #6) > Shouldn't we configure prohects so that those warnings are reported as > errors in IDE and build? That would decrease theur probability of being > submitted and merged. It's a warning in both cases. We won't make every warning an error just that one can better see it.
(In reply to Dani Megert from comment #9) > We won't make every warning an error just that > one can better see it. Too bad. It would actually be quite profitable for everyone.
(In reply to Mickael Istria from comment #10) > (In reply to Dani Megert from comment #9) > > We won't make every warning an error just that > > one can better see it. > > Too bad. It would actually be quite profitable for everyone. A more general approach would be if Gerrit gives a -1 if the number of warnings went up, but for that it would also have to compile the code on which the change is based.
(In reply to Dani Megert from comment #11) > A more general approach would be if Gerrit gives a -1 if the number of > warnings went up, but for that it would also have to compile the code on > which the change is based. Are the current report about warning making a differential analysis? Or do they basically report a warning in a way that makes some other committers report them as errors afterwards? If the later, what would be so wrong as reporting them as errors directly in the IDE at dev-time already?
(In reply to Mickael Istria from comment #12) > what would be so wrong as reporting them as errors directly in > the IDE at dev-time already? For me it could be annoying when launching a project with not yet used variables. Btw. one of the most annoying settings for one of the platform projects is 'remove unused variables' as save action.
(In reply to Paul Pazderski from comment #13) > For me it could be annoying when launching a project with not yet used > variables. Note that I'm not discussing the idea of changing the default in the IDE overall, but more changing this in the project-specific settings of individual Eclipse Platform projects (in the .settings).
(In reply to Paul Pazderski from comment #13) > (In reply to Mickael Istria from comment #12) > > what would be so wrong as reporting them as errors directly in > > the IDE at dev-time already? > > For me it could be annoying when launching a project with not yet used > variables. +2
(In reply to Mickael Istria from comment #14) > (In reply to Paul Pazderski from comment #13) > > For me it could be annoying when launching a project with not yet used > > variables. > > Note that I'm not discussing the idea of changing the default in the IDE > overall, but more changing this in the project-specific settings of > individual Eclipse Platform projects (in the .settings).
(In reply to Mickael Istria from comment #14) > Note that I'm not discussing the idea of changing the default in the IDE > overall, but more changing this in the project-specific settings of > individual Eclipse Platform projects (in the .settings). How would the experience be different for Paul an me working on those projects?
