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
widest set of preferences is to make the choice explicit in
UI.
Note
that I am not suggesting using JDT’s UI pattern for handling
preference override, just the concept of refining
preferences from the broadest scope to the most specific.
There are other UI patterns that can handle the concept of
defaulting quite easily without being bulky or confusing.
Some of these we have implemented in Sapphire. For instance,
for a text box you present the default (the inherited value
in this usecase) as grey text overlay that disappears if you
set focus in the field. I can go into more details into
these patterns if there is interest, of course.
-
Konstantin
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.
>
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
