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 completeness wouldnt it be call if all my Eclipse installations share the same list of know workspace locations :-) so that I dont have to add them again when I unpack a new Eclipse IDE.
I also think the "IHateEclipse" page is not only about preferences. I can think
of a list of top 10 items that every newcomer to Eclipse hates and we since we
use it so long got used to it. We accept although deep in us we dont think that
it has to be that way right ?
* line numbers
* the reoccuring refresh option (eclipse detects a change on disk, but you
need to press F5, no option (default=true) to always refresh)
* software update: couldnt Eclipse auto check for updates like any current
other tool I use and say "there are updates, do you want to install them"
* software update: when I select a software update site, it checks the P2
data, yet the progress of this is shown at the bottom of the shell window and
not in the dialog where I am currently working, maybe a thing that people dont
even notice and get the impression of slowliness
* and yes I have also seen myself "An error occurred, details: cant display
details: an error occurred"
* which leads too: could it be interesting to give users the option to
send exceptions in the IDE to eclipse.org and then the individual plugin
providers can pick them up or query them. (What exceptions in real life have
happened in the EMF model editor ?) <I am making that up, of course the EMF
model editor does have exceptions :-)>
* easier or standard shortcuts. I like the point about CTRL-TAB for editor
switching. And I hate shortcuts like ALT-CTRL + G + I (does anyone seriously
use that)
* I also dont get it why Eclipse recompiles my whole workspace when I start
the Eclipse IDE, although it was compiled and running when I stopped the IDE
* why is the Maven default to update the dependencies from all remote
repositories (takes ages)
* startup time ("preparing JDT tooling" etc.) also a complain.
What I really want to say is the pain points that are articulated on that
website, I believe are larger than fixing the preferences.
So next to that existing technical discussion of preferences I think it would
be also cool if there where a thread about what kind of others improvments we
see. Does anyone agree with my personal list above ? Do you have your own list
of things that got used too but dont really like ? What are the pain points of
your customers ?
christian
Von: Eric Moffatt <[email protected]<mailto:[email protected]>>
Antworten an: Cross issues
<[email protected]<mailto:[email protected]>>
Datum: Montag, 15. Juli 2013 20:39
An: Cross issues
<[email protected]<mailto:[email protected]>>
Betreff: 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 ru]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
From:
Doug Schaefer <[email protected]<mailto:[email protected]>>
To:
Cross project issues
<[email protected]<mailto:[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]<mailto:[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
<[email protected]<mailto:[email protected]>>
Reply-To: Cross project issues
<[email protected]<mailto:[email protected]>>
Date: Monday, 15 July, 2013 6:55 PM
To: Cross project issues
<[email protected]<mailto:[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:
[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]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
<<attachment: graycol.gif>>
<<attachment: ecblank.gif>>
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
