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 line numbers, font, etc. and I’m sure we could go a long way by just using some common
sense on preferences rather than asking the user where he wants a specific pref to be stored.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Konstantin Komissarchik
Sent: July-15-13 2:53 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)
> The main issue is to determine *which* metadata is common vs workspace oriented.
This is bound to fail as there is no one answer even when you are asking the question setting by setting. The most flexible solution is preference inheritance,
like what JDT is doing with compiler settings at workspace and project level, but that’s definitely going to take as significant amount of UI work.
- Konstantin
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 'common' UI setup in Luna. Basically it would try to separate the UI from the workspace as well as allowing different
setups based on the type of work you are doing. The current approach would effectively override the current mechanism(s) to gain access to the '.metadata' to allow a choice between using the workspace's location or the 'common' one.
The main issue is to determine *which* metadata is common vs workspace oriented. The best approach I can think of would be an 'opt in' one where a component would declare which
of its 'plugins' directories can be 'common'. The platform would then use this info when providing the path to store the information for a particular bundle...
Do you think that this can work ? For the UI certainly but without capturing things like dialog settings and ui preferences it's not likely to be seen as a huge gain. My guess
is that of all the information we save in '.metadata' most is not really specific to a particular workspace.
I realize after talking to McQ that how to split up preferences has proven in the past to be a very difficult problem. How about if the user just exports whatever prefs they're
interested in to the 'common' area and we auto-import these whenever we're working against a new workspace ?
Onwards,
Eric
Doug
Schaefer ---07/15/2013 01:23:51 PM---It may be hard, but it's is one huge item that we've all run into with our users. It's probably wort
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.rapicault@xxxxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: Monday, 15 July, 2013 6:55 PM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)
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 mostly because creating a UI for this is hard (we explored some
things back in the 3.0 days when we introduced the scope mechanism).
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Henrik
Sent: July-15-13 12:45 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)
Hi all,
I know that preferences can be imported/exported.
Yet I find it a bit cumbersome to care about that every time I create a new workspace.
Wouldn't it make sense to have preferences arranged in several layers similar to git: system/user/workspace?
Also I could imagine to offer a web page with collections of preference settings.
They could be ordered in categories (maybe aligned to the packaged Eclipse installations).
And we could offer a possibility for users to cast their vote to be able to rank the settings.
-Henrik_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
