[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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