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 From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Rapicault Sent: Monday, July 15, 2013 1:09 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread) 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: [email protected] [mailto:[email protected]] 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 From: [email protected] [mailto:[email protected]] On Behalf Of Eric Moffatt Sent: Monday, July 15, 2013 11:40 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread) 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 Inactive hide details for Doug Schaefer ---07/15/2013 01:23:51 PM---It may be hard, but it's is one huge item that we've all ruDoug 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 From: Doug Schaefer <[email protected]> To: Cross project issues <[email protected]>, Date: 07/15/2013 01:23 PM Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread) Sent by: [email protected] _____ 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 < <mailto:[email protected]> [email protected]> Reply-To: Cross project issues < <mailto:[email protected]> [email protected]> Date: Monday, 15 July, 2013 6:55 PM To: Cross project issues < <mailto:[email protected]> [email protected]> 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: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<<image001.gif>>
<<image002.png>>
<<image003.png>>
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
