I partially agree that your top 10 list is different than mine. However I dont
believe in the ultimate truth that the Eclipse Foundation could supply.
I see the EF as an umbrella not really as the someone/something who wants too
or should open feature bugs against a project or come up with a
On 15.07.2013 22:08, Pascal Rapicault wrote:
Unfortunately I don't think that the JDT approach is workable for all
preferences, and asking the user for the scope where he wants to store a
particular preference is going to result in complex UI that will confuse
users.
How about a global change
On 07/16/2013 10:36 AM, zhu kane wrote:
I think Eclipse can offer a feature to synchronize kinds of
configuration, like Chrome and Firefox Sync.
Developers can use their account of eclipse.org http://eclipse.org to
synchronize their installation of plug-ins, preference configuration and
even
I actually did not mean to highlight the reference to Visual Studio per se. I
meant that the comments about Eclipse’s usability in the article and especially
in the comments are useful feedback.
Mike Milinkovich
mike.milinkov...@eclipse.org
+1.613.220.3223
From: Campo, Christian
On 07/17/2013 04:29 PM, Mike Milinkovich wrote:
If we're looking for user feedback, reading the article and comments
here[1] would be helpful.
Gathering the feedback and reacting to it based on end-users request is
not something Eclipse contributors generally excel at doing. The main
You are right. I'm in that same situation. But I'm not sure the Foundation has
the resources either.
That's why we need to grow the contributor community. The more hands we have on
deck the more we can do this kind of analysis and planning and get things done.
Doug.
From: Mickael Istria
Thanks Mike. Spot on. But I do have one comment with all due respect.
I'm not sure why we're always expecting companies to drop bus loads of
developers into projects when we have a pretty healthy individual contributor
community already at Eclipse. In fact, over half of CDT contributions of
+1 to what Doug is saying.
All the discussions that I have seen are either about being more responsive to
the community (faster release train) or better understanding the community.
This is exactly the type of the common good that Eclipse Foundation can and
should help with.
-
Just to be clear, I did not suggest the Foundation should help. They are just
as resource constrained as the rest of us.
And I don't want to the discussion to go in this direction. Let's keep focus on
the types of things we want to see fixed and features added and try to figure
out how to
That seems to be an odd statement, given that the Eclipse Foundation does not
manage the release train, nor do we interact with the community on behalf of
specific projects. At least not in the ways necessary to be responsive to their
needs.
All the discussions that I have seen are
The secret is simple. Manage the project differently, if barely at all.
Let the contributors manage it. Be open, really open.
And automate as much as you can so you aren't relying on individuals so
much. Hell, I've managed to do that with our commercial product builds.
(Jenkins, uh, I mean
Absolutely. Those types of strategy and funding discussions happen at the
Board. I would encourage you to pass along your thoughts to the Committer Reps
and to the Oracle rep on the Eclipse Board.
These type of common good projects should not conflict with Foundation’s
charter, so if
We can definitely do better as mentioned in several comments already. Just
wanted to mention ? though not very user-friendly ? there is a mechanism
that allows to set most preferences (those that appear in the preference
dialog) per install(s):
eclipse[c].exe -pluginCustomization path to
I think Eclipse can offer a feature to synchronize kinds of configuration,
like Chrome and Firefox Sync.
Developers can use their account of eclipse.org to synchronize their
installation of plug-ins, preference configuration and even more.
Kane
On Tue, Jul 16, 2013 at 3:26 PM, Daniel Megert
Sharing prefs between workspaces sounds good. The suggested solution still
sounds a little bit too complicated (for my taste of course). If I open a
workspace, why cant I not directly reference an existing workspace and copy the
preferences from there ? (why the extra export step) And for
Christian,
the refresh issue has been resolved a year ago in the Juno (4.2)
release, but you might not see it in old workspaces yet. Make sure the
General Workspace 'Refresh on access' preference is checked. You can
even go further and enable 'Refresh using native hooks or poling'.
That's what started this discussion. The user shouldn't have to do anything to
get the fix. It should just work. Which led us to the desire to override the
defaults where we disagree with the settings the projects put in.
Doug.
From: Daniel Megert
It may be hard, but it's is one huge item that we've all run into with our
users. It's probably worth the price.
From: Pascal Rapicault
pascal.rapica...@ericsson.commailto:pascal.rapica...@ericsson.com
Reply-To: Cross project issues
I just wanted to say making import/export easier I think is the better
way to address complaints about initial preferences there is no way
that initial preferences will ever satisfy everyone and as for myself,
it is always the first action I take with a new installation or workspace
(to
Am 15.07.2013 18:55, schrieb Pascal Rapicault:
Internally the preferences are already organized in “scopes” that are:
-Project
-Workspace
-Configuration
-(There is no such thing as “system”)
However the user does not have a say as in the scope in which a value should be
stored. This is
Preference import has another major issue. (which I had hoped back in the
days of Eclipse 3.0 would have solved).
Export / Import of preferences is an all or nothing proposition.
If you, as a developer, have a core set of preferences you want to set, but
are happy with the rest being at default,
Hi
Where it works (e.g. the Install New Software Work with box) DND
from an external broswer is really cool. Sadly good file level DND
seems to be the exception rather than the rule in the UI.
I might hope to be able to DND my preferences file onto the
This is a great discussion ! To me it's always seemed odd that the
workspace is where all the ui information is stored. I'd like to always use
the same UI for the same type of task regardless of where the projects /
files reside.
We've already started looking into how we might support a
Unfortunately I don't think that the JDT approach is workable for all
preferences, and asking the user for the scope where he wants to store a
particular preference is going to result in complex UI that will confuse users.
As Eikke mentioned there are prefs that are known to be global, such as
Common sense to one is a reason to swear to another. While one could
conceivable select a certain small set of preferences where the odds of
anyone objecting to user vs. workspace level retention is low, the only way
to have a solution that is both not objectionable to some and applicable to
the
25 matches
Mail list logo
