Bug 112130 - [preferences] Unable to share Syntax Coloring across multiple workspaces
Summary: [preferences] Unable to share Syntax Coloring across multiple workspaces
Status: CLOSED DUPLICATE of bug 103096
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 70683
Blocks:
  Show dependency tree
 
Reported: 2005-10-10 14:41 EDT by Randy Hudson CLA
Modified: 2010-02-02 07:35 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Randy Hudson CLA 2005-10-10 14:41:15 EDT
I would like syntax coloring and fonts to be the same across all of my
workspaces. There seems to be no way to export just this setting, and even if
there were, this preference should be in Eclipse's config area so that it is
automatically shared.
Comment 1 Martin Aeschlimann CLA 2005-10-11 03:24:00 EDT
An export/import of all setings is not an option?

You want this just for Java or all fonts and colors?
Comment 2 Randy Hudson CLA 2005-10-11 10:15:13 EDT
Ideally, I don't want to have to export and import anything because this is a 
preference that should be shared across workspaces. But short of that, I should 
be able to export only the settings that affect the java editor's appearance.
Comment 3 David Williams CLA 2005-10-11 12:24:32 EDT
While we should *also* have ability to import/export more fine grained
prefrences, I too would like to see a "direction" where editor related
preferences on scoped per configuration. This will be more and more important as
more and more editors are added "to the stack". 

[Of course, I'm not sure *when* we in WTP could do this :) .... but I think it
would be good to have a stated direction of what should be the solution]. 
 
Perhaps too someone "from usability" should evaluate in general if there's
others that should be configuration scoped? So, "whole effort" could be sized? 
Comment 4 Randy Hudson CLA 2005-10-11 16:34:01 EDT
David, see also bug 70683.

The end result of the current situation is that users don't bother customizing 
anything because its going to get lost once they move workspaces.
Comment 5 Dani Megert CLA 2005-10-12 03:49:08 EDT
As Randy already pointed out, saving across workspaces is bug 70683 i.e. unless
we do not have support from Platform UI, we won't start this. See also my
comments in bug 70683.

Import/export for syntax coloring is covered in bug 107508.

Do you think it would help to offer the (syntax coloring) preferences as
settings per project and hence sharable?

Randy, if it's OK for you I either rename this PR to "Project specific syntax
coloring" or mark as duplicate of bug 70683.
Comment 6 David Williams CLA 2005-10-12 04:02:52 EDT
Well .. even though you asked Randy and not me I'll chime in anyway. :) 

1. doesn't seem like a project/sharable property to me (at all). 
2. what support from platform UI is needed? I thought it was provided by 
OSGI services? [Hardest part would be "migrating" prefernces, maintaining
compatibilitiy.]
3. your comments in bug 70683 are rather sparse :) [I suspect you meant some 
other bug number.]
Comment 7 Dani Megert CLA 2005-10-12 04:22:31 EDT
>Well .. even though you asked Randy and not me I'll chime in anyway. :) 
Mmh, when reading comment 5 again it seems to me I asked generally for comment
and Randy what to do with the bug ;-)

>2. what support from platform UI is needed? I thought it was provided by 
>OSGI services? [Hardest part would be "migrating" prefernces, maintaining
>compatibilitiy.]
With "support" I meant that the guidance how this will look in the UI (and
eventually more API to handle this cleanly) has to come from Platform UI:
- imagine that every project starts to add some sort of shared preference
  support using the fully flexible OSGi support. Each UI will be different,
  some will allow changing the shared preference, some will allow overriding 
  single preference and so on.
- IPreferenceStore and ScopedPreferenceStore are UI classes

>3. your comments in bug 70683 are rather sparse :) [I suspect you meant some 
>other bug number.]
I was in the middle of adding the comments. Simply grab the bug again.
Comment 8 Randy Hudson CLA 2005-10-12 10:06:02 EDT
UI preferences are not project specific, but user-specific. And I definitely 
don't think you would find agreement among teammembers as to which font to use, 
etc. I already find it annoying that I when I make a change to team project 
compiler settings, I have to do it N times. (But that's a separate issue). So, -
1 for the summary change.

Preferences are a core issue and there are examples in 3.1 of the configuration 
area being used to store "stuff". For example, help caches its indexes there. 
IDE stores MRU workspace and a few settings there. If core doesn't allow 
general preferences to be stored there, I would be surprised. Jeff?
Comment 9 Dani Megert CLA 2005-10-12 10:12:48 EDT
Comments from David and Randy regarding project-specific settings are what I
would say as well.

Marking as LATER (waiting on bug 70683).

Please post comments regarding how the preference should be shared among
workspaces into bug 70683.
Comment 10 Dani Megert CLA 2007-06-22 09:59:27 EDT
Get rid of deprecated state.
Comment 11 Dani Megert CLA 2009-10-01 09:41:08 EDT
Marking as duplicate of bug 103096. For the workspace sharing we have bug 70683.

*** This bug has been marked as a duplicate of bug 103096 ***