From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Megert
Sent: July-16-13 4:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)
Christian,
the "refresh" issue has been resolved a year ago in the Juno (4.2) release, but you might not see it in old workspaces yet. Make sure the General > Workspace > 'Refresh on access' preference is checked. You can even go further and enable 'Refresh using native hooks or poling'.
Regarding recompiling the whole workspace: definitely a big bug. Please file a bug report (if not done already) and we will investigate.
The line number preference discussion currently happens in https://bugs.eclipse.org/191154.
Dani
From: "Campo, Christian" <Christian.Campo@xxxxxxxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 16.07.2013 09:54
Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <emoffatt@xxxxxxxxxx>
Antworten an: Cross issues <cross-project-issues-dev@xxxxxxxxxxx>
Datum: Montag, 15. Juli 2013 20:39
An: Cross issues <cross-project-issues-dev@xxxxxxxxxxx>
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
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
-------------------------------------------------------------
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
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------[attachment "graycol.gif" deleted by Daniel Megert/Zurich/IBM] [attachment "ecblank.gif" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
