Home » Eclipse Projects » Oomph » Feedback on using Oomph(Trying to share preferences is painful)
| Feedback on using Oomph [message #1705809] |
Wed, 19 August 2015 10:44  |
 Stephen Colebourne
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
As I use multiple Eclipse workspaces, Oomph sounded great to allow me to share settings between them. Previously, I have carefully extracted out epf files and filtered them down to just the settings I want to manually change in a new workspace. Unfortunately, I've found using Oomph to share preferences to be a bit of a nightmare. I'd happily turn it off if only there was an obvious way.
Specifically, I have two main types of workspace, work and open source, both on the same machine. While the two workspaces need to share some settings, they also need to have differences.
Currently I'm in the position where every day, I change a setting (favorite static imports, although otehr settings are affected too). The setting lasts until I restart Eclipse, and I have to change the setting again! As might be imagined, I find this far far worse than what I had before I turned Oomph on. And there is no obvious way to get rid of this behaviour.
I get what the idea is - to have a set of standard preferences that can be shared. But I'm finding the mode where it always resets everything back to the shared set on every startup to be the problem. It seems that this should be an option - a notification or popup when Eclipse starts saying "do you want to reset your preferences". Or alternatively, as a checkbox in the Oomph preferences section. (You can turn the recorder on and off, but you can't turn the thing that applies them on startup on or off AFAICT)
There is also no obvious way to remove preferences from the shared set. I assume that the "preferences recorder" page in the Oomph preferences section is meant to be the way, but doing a search and unselecting any item in there causes everything to be unselected (a bug I presume).
Version 1.1.0.v20150610-1559 in Eclipse Mars
Finally, because Oomph seems primarily about setting up complete environments, the sharing preferences feature seems difficult to find documentation on. The documents I've seen talk about concepts that are of interest to expert Eclipse developers, not a regular IDE user like me. Perhaps shared preferences should be branded separately from Oomph?
I do think there is some potential here, but it is currently at the point of real annoyance.
|
|
| |
| Re: Feedback on using Oomph [message #1705874 is a reply to message #1705871] |
Wed, 19 August 2015 17:11  |
Stephen Colebourne
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
"Navigate -> Open Setup"
Given that I didn't find that, it suggests a UI problem. The main preferences should have some text to point users at that menu.
Unfortunately, those setup editors have no search (or if they do it is well hidden again).
Looking at the raw xml, I can find the setting that I was looking for, but it is in the disabled section. And the installation/workspace setup files are empty. So, where is the current actual setting?
Again, while I appreciate this may be a step forward, you really need to be a guru to understand how this hangs together. A sensible UI would be a table of preferences, with columns for user/installation/workspace, showing the value that is set or inherited in each cell.
Concrete suggestions:
- provide a link/text locating "Navigate -> Open Setup"
- provide search in setup view
- include the file location of user.setup in the setup tree view (like installation.setup and workspace.setup)
- provide an API to allow the preferences recorder to target installation.setup instead of user.setup (would have been much better for me)
- consider a better UI
|
|
|
| Re: Feedback on using Oomph [message #1705913 is a reply to message #1705809] |
Thu, 20 August 2015 04:55 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
On 19/08/2015 5:39 PM, Stephen Colebourne wrote:
> As I use multiple Eclipse workspaces, Oomph sounded great to allow me
> to share settings between them. Previously, I have carefully extracted
> out epf files and filtered them down to just the settings I want to
> manually change in a new workspace.
I expect you'll agree that *.epf files are basically a form of vomit.
You basically ask the IDE to disgorge a belly full of preferences and
hope to goodness this doesn't make the next IDE to consume it sick. Of
course it generally does, so you have to pick through this stuck to
extract the more appetizing bits.
> Unfortunately, I've found using Oomph to share preferences to be a bit
> of a nightmare. I'd happily turn it off if only there was an obvious way.
The new red button in the dialog clearly isn't obvious enough. Nor is
the check mark "Recorder enabled" in the confirmation dialog obvious
enough. Hmmmm.....
In any case, just this week I added support to covert a *.epf file to
preference tasks... Of course one must "carefully extract" from the
vomit dump, but if you've already done that before, that should work nicely.
>
> Specifically, I have two main types of workspace, work and open
> source, both on the same machine. While the two workspaces need to
> share some settings, they also need to have differences.
No doubt the workspaces contain a bunch of projects that make them
different as well... This sounds like a job for project setups...
>
> Currently I'm in the position where every day, I change a setting
> (favorite static imports, although otehr settings are affected too).
> The setting lasts until I restart Eclipse, and I have to change the
> setting again!
This is a general observation about Eclipse ? Are you recording them?
Or you've recorded them but now you no longer record them so the
recorded ones are applying?
> As might be imagined, I find this far far worse than what I had before
> I turned Oomph on. And there is no obvious way to get rid of this
> behaviour.
Recording preferences is about your general personal preferences. I.e.,
do I want line numbers in editors or not. Compiler settings (and JDT
settings in in general) are more project specific things. They vary
depending on which projects you work on. Technically they should mostly
be managed as project-specific preferences but if you have 100 projects
it's impossible to keep such things consistent as well.
In any case, the problem of obviousness seems to be a general problem
for you. There are of course preferences for the preferences recorder,
but the fact you could find no way to turn it off despite the red button
in the preference dialog toolbar, the checkbox in the confirmation
dialog, and the Preference Recorder preferences themselves begs the
question what would be obvious enough?
>
> I get what the idea is - to have a set of standard preferences that
> can be shared. But I'm finding the mode where it always resets
> everything back to the shared set on every startup to be the problem.
Yes, not all preference are sensibly globally the same everywhere. Given
there are 1000s of preferences, which of them should be the same
everywhere and which others should be a different way when and where?
> It seems that this should be an option - a notification or popup when
> Eclipse starts saying "do you want to reset your preferences".
Like anyone would want to do that... And of course any notification or
popup sends users into a tizzy about interruptions of the workflow and
confusing, annoying dialogs bothering them...
> Or alternatively, as a checkbox in the Oomph preferences section. (You
> can turn the recorder on and off, but you can't turn the thing that
> applies them on startup on or off AFAICT)
Preferences -> Oomph -> Setup Tasks -> Skip automatic task execution at
startup
>
> There is also no obvious way to remove preferences from the shared
> set. I assume that the "preferences recorder" page in the Oomph
> preferences section is meant to be the way, but doing a search and
> unselecting any item in there causes everything to be unselected (a
> bug I presume).
It's worse than that, anything that's filtered becomes unselected.
Definitely a bug.
>
> Version 1.1.0.v20150610-1559 in Eclipse Mars
>
> Finally, because Oomph seems primarily about setting up complete
> environments,
What are you implying by "complete"?
> the sharing preferences feature seems difficult to find documentation on.
There generally isn't much documentation. That's definitely a huge problem.
> The documents I've seen talk about concepts that are of interest to
> expert Eclipse developers, not a regular IDE user like me.
There's certainly a lack of documentation. But the general problem
you've describe sounds to me more like you should be defining project
setups. In each project you define the preferences you want in that
case (and likely other things, like tasks for how to clone the open
source projects you work on). Then you would set up your
IDEs/workspaces so that those projects (preference tasks) are chosen
using File -> Import -> Oomph -> Projects into Workspace. When you want
to modify those things in a project-specific way, you open your project
setup (Navigate -> Open Setup) and record your preference changes into
that; recording into any setup is working properly again for the
upcoming 1.2 (Mars.1) release.
But what can I say, you'd have to learn a fair bit, but somehow you
pawed through *.epf files and got that to serve your purpose.
> Perhaps shared preferences should be branded separately from Oomph?
I doubt "branding" is an issue. Documentation is certainly a major problem.
>
> I do think there is some potential here, but it is currently at the
> point of real annoyance.
Yes, I can't disagree. It's not easy to know how best to solve the
problem you're trying to solve, but the pieces you need are there...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Feedback on using Oomph [message #1705914 is a reply to message #1705871] |
Thu, 20 August 2015 05:00 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Abel,
Comments below.
On 19/08/2015 6:18 PM, Abel Hegedus wrote:
> All your recorded preferences are collected in a nicely structured and
> semi-clear way in your user.setup that you can open through Navigate
> -> Open Setup -> Open User. In the editor that opened, simply go to
> User Preferences and do the following:
> - delete preference settings that you don't want to set in any of your
> installations
Yes, it's no so different from the *.epf except there is a structured
editor (and an Open in text editor in the context menu if you want to
see the raw XML).
> - cut and paste the preferences specific to a given workspace to the
> workspace.setup of a given installation (also opened through Navigate
> -> Open Setup -> Open Workspace). - if you already have some project
> setup files, you can also move project specific preferences to those
Note that as of this week's updates, all the setup editors support the
preference recording toolbar button again, so you can record preferences
directly into any setup. In addition, there are two new actions.
Capture Preferences will allow you to record any existing preference,
without having to change it; unfortunately there are a great many
preferences..
>
> Basically, when you start a given Eclipse, the preferences stored in
> your user.setup, the installation.setup for the started Eclipse, the
> workspace.setup of the used workspace and the project.setup files of
> all selected Oomph projects will be automatically applied.
>
> I agree that a bit of work is needed to clean them up at first, but
> after a while you should have all your preferences nicely organized to
> the scope you want them to be applied.
Yes, definitely a problem that there are so darned many preferences, but
once you get it right, it feels good...
>
> Cheers
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Feedback on using Oomph [message #1705915 is a reply to message #1705874] |
Thu, 20 August 2015 05:23 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
On 19/08/2015 7:11 PM, Stephen Colebourne wrote:
> "Navigate -> Open Setup"
>
> Given that I didn't find that, it suggests a UI problem.
Do you suggest a solution too? I could imagine an Edit... button in
the Preference Recorder preference package to open the resource in which
the preferences have been recorded, i.e., the user.setup.
But given you could find no way to disable the recorder despite there
being 3 ways, one of which one might have hoped would have been obvious
enough, I'm not sure...
> The main preferences should have some text to point users at that menu.
Which main preferences?
> Unfortunately, those setup editors have no search (or if they do it is
> well hidden again).
Yes, search would be nice!
>
> Looking at the raw xml, I can find the setting that I was looking for,
> but it is in the disabled section.
What is "the disabled section"?
> And the installation/workspace setup files are empty. So, where is the
> current actual setting?
>
> Again, while I appreciate this may be a step forward, you really need
> to be a guru to understand how this hangs together.
Certainly it needs understanding some new concepts, and without
sufficient documentation, that's a problem.
I wonder though why you never looked at the help on the Oomph
Preference Recorder dialog? This seems to be such a common problem.
One writes documentation, makes it available, but even the sentence at
the top of a wizard is something users fail to notice. You can lead a
horse to water...
Preference Recording)
> A sensible UI would be a table of preferences, with columns for
> user/installation/workspace, showing the value that is set or
> inherited in each cell.
With the latest build, you can open such a resource, and use the record
button to record preferences there. Let's face it, what you describe
would not make the user interface any simpler. It would require more
concepts and more documentation, which users clearly don't read anyway,
so to me further complicating this to make it a table is not a great idea...
>
> Concrete suggestions:
> - provide a link/text locating "Navigate -> Open Setup"
In the confirmation dialog. Given it's modal, would it be okay that it
opens an editor you can access until after the dialog is dismissed.
Should clicking it dismiss the dialog (as if one hits cancel)?
> - provide search in setup view
Yes, that's a good idea. It is often annoying to look for things.
> - include the file location of user.setup in the setup tree view (like
> installation.setup and workspace.setup)
I hesitate to point out that the "Show all resources toolbar button"
would do that, or, more glaringly, the fact that the hover on the tab
provides this information.
> - provide an API to allow the preferences recorder to target
> installation.setup instead of user.setup (would have been much better
> for me)
As of yesterday's build you can open any setup, and record into that,
capture preferences into that, or import *.epf files into that.
> - consider a better UI
Beauty is in the eye of the beholder. We have this entire preference
disaster area precisely because each user likes things their own way, so
we provide preferences to make them happy, then they complain about the
defaults, about too many choices, about not being able to find where the
choices are, until we end up with Eclipse with 10,000 choices with no
reasonable way to manage them. Compound that with the fact that there is
no metadata for the preferences and they're open ended, so what can one
do other than dump messy crap in from of a user?
And to make it all even more fun, any attempt to provide a solution is
immediately met by critique, much of it not terribly constructive, and
often loudest from precisely the people who currently complain the
loudest about how bad the current situation already is. What's the
expression? No good deed goes unpunished...
I do appreciate your feedback and especially the constructive
suggestions in this second post.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Feedback on using Oomph [message #1705978 is a reply to message #1705927] |
Thu, 20 August 2015 16:00 |
Stephen Colebourne
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Thanks for engaging, I'll try to keep things as constructive as I can.
> But given you could find no way to disable the recorder despite there
being 3 ways, one of which one might have hoped would have been obvious
enough, I'm not sure...
I was able to disable the recorder (perfectly visible and understable UI), but that did not stop the problem I was seeing. My problem was that I was changing a preference, yet it was being reset every time I restarted Eclipse. I can see *now* that the user.setup file is "golden". Once something is in there, Oomph ensures that it gets reset on every restart. Problem is that is not what I wanted/expected.
What I wanted/expected was for the shared preferences in Oomph to set the *default* values for each new workspace. Once set, I then expected all my subsequent changes to be retained. ie. my expected workflow was
- record once in the first instance of Mars using the recorder
- turn the recorder off
- start a second instance/workspace
- configure whatever I want there based on the new defaults (with the recorder off)
- retain those new values locally in the workspace (as per normal Eclipse behaviour)
Clearly, this isn't how the Oomph team intends it to work, but I hope you can understand that the above was my assumption, and was not IMO an unreasonable mental model. It is the "reset on every restart" that was the most painful part for me.
The above should explain why I think being able to choose *when* the preferences are applied is key.
Concrete suggestion - add to the Oomph preferences page an option with three choices:
- always reset shared preferences on restart
- never reset shared preferences on restart
- reset shared preferences on next restart only
(maybe the last is more of a button than a radio button...)
Or is this what the "skip automatic task execution at startup time" is for? (If it is, then consider that despite seeing that many times, I had no idea what it meant or might do. The notion of "startup tasks" did not connect to "shared preferences" for me.)
> Recording preferences is about your general personal preferences. I.e., do I want line numbers in editors or not.
I think this is a key part of where I struggled. The preferences recorder offers to record *everything*. This seems prone to cause problems as not everything should be accross all installations. That UI should be changed to actively discourage users from setting too much into user.setup.
Concrete suggestion - instead of a checkbox next to each preference in the preferences recorder, have a drop down list. The list would have the values "user", "installation", "workspace", "do not record".
This suggestion would put Oomph's "mental model" right in the user's face. The user would have to think about where the setting will be stored and how much it will affect.
This is also why I suggested a table (or tree table) for editing the preferences. While larger, I believe it would actually be simpler. For me, the problem with preferences is the multiple locations they can be set, and the implied hierarchy. Capturing that in one UI is important. The current editor UI is file based, and as such doesn't manage to express the hierarchy and underlying data model. IMO, it should be easy to push a setting from one level to another within a single UI.
> I wonder though why you never looked at the help on the Oomph Preference Recorder dialog?
I looked for help in the Oomph preferences page. For me, the Preference Recorder dialog is the kind of dialog that I've never opened help from before. The actual help text there is quite reasonable.
To summarize, there is goodness here, but it left me feeling like there was a troll somewhere in Eclipse randomly reseting preferences!
|
|
|
| Re: Feedback on using Oomph [message #1706007 is a reply to message #1705978] |
Fri, 21 August 2015 05:12 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
On 20/08/2015 6:00 PM, Stephen Colebourne wrote:
> Thanks for engaging, I'll try to keep things as constructive as I can.
:-)
>
>> But given you could find no way to disable the recorder despite there
> being 3 ways, one of which one might have hoped would have been obvious
> enough, I'm not sure...
>
> I was able to disable the recorder (perfectly visible and understable
> UI), but that did not stop the problem I was seeing. My problem was
> that I was changing a preference, yet it was being reset every time I
> restarted Eclipse. I can see *now* that the user.setup file is
> "golden". Once something is in there, Oomph ensures that it gets reset
> on every restart. Problem is that is not what I wanted/expected.
Yes, I mentioned to Eike that I suspected you weren't expressing
yourself clearly. That what you couldn't figure out how to turn off is
the application of already-recorded preferences. We discussed an
approach for dealing with that, i.e., if you disable the recorder and
you have already recorded preferences to have the option of deleting
them all so that nothing is automatically done, if you don't want that...
>
> What I wanted/expected was for the shared preferences in Oomph to set
> the *default* values for each new workspace.
Eclipse has a bunch of scope concepts, including defaults and bundle
default; they do this. We can only set values, not change defaults...
> Once set, I then expected all my subsequent changes to be retained.
> ie. my expected workflow was
That's not what the documentation says. We're trying an approach where
the documentation will be shown the first time you are shown the
confirmation dialog to record a preference. Reading this would have
answered many of your questions and set your expectations correctly.
> - record once in the first instance of Mars using the recorder
> - turn the recorder off
> - start a second instance/workspace
> - configure whatever I want there based on the new defaults (with the
> recorder off)
> - retain those new values locally in the workspace (as per normal
> Eclipse behaviour)
Yes, unfortunately you're mixing up two different aspects. One related
to recording, and the other related to performing tasks.
> Clearly, this isn't how the Oomph team intends it to work, but I hope
> you can understand that the above was my assumption, and was not IMO
> an unreasonable mental model.
No, so we have to make more sure that if someone turns the recorder off
and expects that this will stop applying their preferences that we make
it clear that will only happen if they remove them.
> It is the "reset on every restart" that was the most painful part for me.
Yes, although when it sets things the way you want, it's totally
convenient.
>
> The above should explain why I think being able to choose *when* the
> preferences are applied is key.
>
> Concrete suggestion - add to the Oomph preferences page an option with
> three choices:
> - always reset shared preferences on restart
> - never reset shared preferences on restart
> - reset shared preferences on next restart only
> (maybe the last is more of a button than a radio button...)
You can already turn off performing tasks on startup, so likely some
kind of link to that preference would be good...
>
> Or is this what the "skip automatic task execution at startup time" is
> for?
Yes.
> (If it is, then consider that despite seeing that many times, I had no
> idea what it meant or might do. The notion of "startup tasks" did not
> connect to "shared preferences" for me.)
Yes, it would be good if the relation is made more clear...
>
>
>> Recording preferences is about your general personal preferences.
>> I.e., do I want line numbers in editors or not.
>
> I think this is a key part of where I struggled. The preferences
> recorder offers to record *everything*. This seems prone to cause
> problems as not everything should be accross all installations.
Exactly, but without metadata and with all this being open ended (each
plugin can have additional preferences), it's hard to know for sure.
And some things, like compiler preferences, are not even clear if they
should or shouldn't be the same across all installations. That's mostly
the user's choice...
> That UI should be changed to actively discourage users from setting
> too much into user.setup.
Of course the user should take responsibility as well, because who
decides what's appropriate and what's too much?
>
> Concrete suggestion - instead of a checkbox next to each preference in
> the preferences recorder, have a drop down list. The list would have
> the values "user", "installation", "workspace", "do not record".
With the ability to record into these resources, it would seem simpler
to open the installation, or workspace, in the case you want to make
specific changes for those...
>
> This suggestion would put Oomph's "mental model" right in the user's
> face. The user would have to think about where the setting will be
> stored and how much it will affect.
I think we at least need to get users to read the documentation.
Otherwise, nothing will work, because as you suggest, there needs to be
a mental model...
>
> This is also why I suggested a table (or tree table) for editing the
> preferences. While larger, I believe it would actually be simpler. For
> me, the problem with preferences is the multiple locations they can be
> set, and the implied hierarchy. Capturing that in one UI is important.
> The current editor UI is file based, and as such doesn't manage to
> express the hierarchy and underlying data model. IMO, it should be
> easy to push a setting from one level to another within a single UI.
>
>> I wonder though why you never looked at the help on the Oomph
>> Preference Recorder dialog?
>
> I looked for help in the Oomph preferences page. For me, the
> Preference Recorder dialog is the kind of dialog that I've never
> opened help from before. The actual help text there is quite reasonable.
We're making changes so that the first time that dialog is opened on
your machine, the help will be showing. We hope that helps.
>
> To summarize, there is goodness here, but it left me feeling like
> there was a troll somewhere in Eclipse randomly reseting preferences!
Yes, so we're actively looking at ways to ensure that when someone turns
the recorder off, that they understand the implications of the fact that
there are already-recorded preference and that those will continue to be
applied. That they can easily remove all those preferences or easily
turn off the automatic application of those preferences. And of course
to make it easy to record preferences such that they're specific to an
installation or even to just one workspace, so that they can override
the "default" preferences the user generally wants everywhere except in
the one specific installation or the one specific workspace...
Overtime we also expect to collect more data to learn about those
preferences that never make sense to set the same across all workspaces,
e.g., the workspace name!
BTW, we're also working in a "find" support so that Ctrl-F works in the
editors. :-)
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Feedback on using Oomph [message #1706055 is a reply to message #1706007] |
Fri, 21 August 2015 12:44 |
|
Hi,
The new capability of recording preferences directly into a setup file
means that it should be easier to do what I have configured for myself,
having (I think) a similar use case to Stephen's.
I have two "kinds" of workspaces: Papyrus workspaces and
everything-else workspaces. I need the same preferences for all of my
Papyrus workspaces, and the same preferences for all of the others, but
these are different preferences in the two classes of workspace.
The way I have this working is that I keep, locally, two setup models
that only have preference settings: one setup model for Papyrus
preferences and one for the rest. Whenever I create a new Papyrus
workspace, I import my "Papyrus Prefs" project from the one local setup
model. Likewise when I create a new non-Papyrus workspace, using the
other setup model. The Oomph wizard makes it easy to add such local
setup models by just dragging and dropping them into the <User> area.
The end result is that, whatever the workspace, it always automatically
applies my preferences when I start it up. Or when I explicitly run
the setup tasks (for Papyrus, I don't auto-run the setup because I
would end up downloading a new Papyrus nightly build every time I start
the workbench).
Hoping this might help others that are having challenges with
preference management.
Cheers,
Christian
On 2015-08-21 05:12:22 +0000, Ed Merks said:
> Stephen,
>
> Comments below.
>
> On 20/08/2015 6:00 PM, Stephen Colebourne wrote:
>> Thanks for engaging, I'll try to keep things as constructive as I can.
> :-)
>>
>>> But given you could find no way to disable the recorder despite there
>> being 3 ways, one of which one might have hoped would have been obvious
>> enough, I'm not sure...
>>
>> I was able to disable the recorder (perfectly visible and understable
>> UI), but that did not stop the problem I was seeing. My problem was
>> that I was changing a preference, yet it was being reset every time I
>> restarted Eclipse. I can see *now* that the user.setup file is
>> "golden". Once something is in there, Oomph ensures that it gets reset
>> on every restart. Problem is that is not what I wanted/expected.
> Yes, I mentioned to Eike that I suspected you weren't expressing
> yourself clearly. That what you couldn't figure out how to turn off is
> the application of already-recorded preferences. We discussed an
> approach for dealing with that, i.e., if you disable the recorder and
> you have already recorded preferences to have the option of deleting
> them all so that nothing is automatically done, if you don't want
> that...
>>
>> What I wanted/expected was for the shared preferences in Oomph to set
>> the *default* values for each new workspace.
> Eclipse has a bunch of scope concepts, including defaults and bundle
> default; they do this. We can only set values, not change defaults...
>> Once set, I then expected all my subsequent changes to be retained. ie.
>> my expected workflow was
> That's not what the documentation says. We're trying an approach where
> the documentation will be shown the first time you are shown the
> confirmation dialog to record a preference. Reading this would have
> answered many of your questions and set your expectations correctly.
>> - record once in the first instance of Mars using the recorder
>> - turn the recorder off
>> - start a second instance/workspace
>> - configure whatever I want there based on the new defaults (with the
>> recorder off)
>> - retain those new values locally in the workspace (as per normal
>> Eclipse behaviour)
> Yes, unfortunately you're mixing up two different aspects. One related
> to recording, and the other related to performing tasks.
>> Clearly, this isn't how the Oomph team intends it to work, but I hope
>> you can understand that the above was my assumption, and was not IMO an
>> unreasonable mental model.
> No, so we have to make more sure that if someone turns the recorder off
> and expects that this will stop applying their preferences that we make
> it clear that will only happen if they remove them.
>> It is the "reset on every restart" that was the most painful part for me.
> Yes, although when it sets things the way you want, it's totally convenient.
>>
>> The above should explain why I think being able to choose *when* the
>> preferences are applied is key.
>>
>> Concrete suggestion - add to the Oomph preferences page an option with
>> three choices:
>> - always reset shared preferences on restart
>> - never reset shared preferences on restart
>> - reset shared preferences on next restart only
>> (maybe the last is more of a button than a radio button...)
> You can already turn off performing tasks on startup, so likely some
> kind of link to that preference would be good...
>>
>> Or is this what the "skip automatic task execution at startup time" is for?
> Yes.
>> (If it is, then consider that despite seeing that many times, I had no
>> idea what it meant or might do. The notion of "startup tasks" did not
>> connect to "shared preferences" for me.)
> Yes, it would be good if the relation is made more clear...
>>
>>
>>> Recording preferences is about your general personal preferences. I.e.,
>>> do I want line numbers in editors or not.
>>
>> I think this is a key part of where I struggled. The preferences
>> recorder offers to record *everything*. This seems prone to cause
>> problems as not everything should be accross all installations.
> Exactly, but without metadata and with all this being open ended (each
> plugin can have additional preferences), it's hard to know for sure.
> And some things, like compiler preferences, are not even clear if they
> should or shouldn't be the same across all installations. That's
> mostly the user's choice...
>> That UI should be changed to actively discourage users from setting too
>> much into user.setup.
> Of course the user should take responsibility as well, because who
> decides what's appropriate and what's too much?
>>
>> Concrete suggestion - instead of a checkbox next to each preference in
>> the preferences recorder, have a drop down list. The list would have
>> the values "user", "installation", "workspace", "do not record".
> With the ability to record into these resources, it would seem simpler
> to open the installation, or workspace, in the case you want to make
> specific changes for those...
>>
>> This suggestion would put Oomph's "mental model" right in the user's
>> face. The user would have to think about where the setting will be
>> stored and how much it will affect.
> I think we at least need to get users to read the documentation.
> Otherwise, nothing will work, because as you suggest, there needs to be
> a mental model...
>>
>> This is also why I suggested a table (or tree table) for editing the
>> preferences. While larger, I believe it would actually be simpler. For
>> me, the problem with preferences is the multiple locations they can be
>> set, and the implied hierarchy. Capturing that in one UI is important.
>> The current editor UI is file based, and as such doesn't manage to
>> express the hierarchy and underlying data model. IMO, it should be easy
>> to push a setting from one level to another within a single UI.
>>
>>> I wonder though why you never looked at the help on the Oomph
>>> Preference Recorder dialog?
>>
>> I looked for help in the Oomph preferences page. For me, the Preference
>> Recorder dialog is the kind of dialog that I've never opened help from
>> before. The actual help text there is quite reasonable.
> We're making changes so that the first time that dialog is opened on
> your machine, the help will be showing. We hope that helps.
>>
>> To summarize, there is goodness here, but it left me feeling like there
>> was a troll somewhere in Eclipse randomly reseting preferences!
> Yes, so we're actively looking at ways to ensure that when someone
> turns the recorder off, that they understand the implications of the
> fact that there are already-recorded preference and that those will
> continue to be applied. That they can easily remove all those
> preferences or easily turn off the automatic application of those
> preferences. And of course to make it easy to record preferences such
> that they're specific to an installation or even to just one workspace,
> so that they can override the "default" preferences the user generally
> wants everywhere except in the one specific installation or the one
> specific workspace...
>
> Overtime we also expect to collect more data to learn about those
> preferences that never make sense to set the same across all
> workspaces, e.g., the workspace name!
>
> BTW, we're also working in a "find" support so that Ctrl-F works in the
> editors. :-)
|
|
|
| Re: Feedback on using Oomph [message #1706058 is a reply to message #1706055] |
Fri, 21 August 2015 12:56 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Christian,
Note that the p2 and targlet tasks have different behavior of isNeeded
for startup trigger verses manual trigger. In the case of the p2 tasks,
it only makes sure that the units required by the task are actually
installed; it does not check if there are update available. Similarly
for the targlet task, it checks if the definition hasn't changed and
that the expected target platform is active; it does not check if there
are remote updates available for the TP. So in both cases, I generally
don't expect these tasks to perform on startup (and the certainly don't
for our Oomph workspace).
On 21/08/2015 2:44 PM, Christian W. Damus wrote:
> Hi,
>
> The new capability of recording preferences directly into a setup file
> means that it should be easier to do what I have configured for
> myself, having (I think) a similar use case to Stephen's.
>
> I have two "kinds" of workspaces: Papyrus workspaces and
> everything-else workspaces. I need the same preferences for all of my
> Papyrus workspaces, and the same preferences for all of the others,
> but these are different preferences in the two classes of workspace.
>
> The way I have this working is that I keep, locally, two setup models
> that only have preference settings: one setup model for Papyrus
> preferences and one for the rest. Whenever I create a new Papyrus
> workspace, I import my "Papyrus Prefs" project from the one local
> setup model. Likewise when I create a new non-Papyrus workspace,
> using the other setup model. The Oomph wizard makes it easy to add
> such local setup models by just dragging and dropping them into the
> <User> area.
>
> The end result is that, whatever the workspace, it always
> automatically applies my preferences when I start it up. Or when I
> explicitly run the setup tasks (for Papyrus, I don't auto-run the
> setup because I would end up downloading a new Papyrus nightly build
> every time I start the workbench).
>
> Hoping this might help others that are having challenges with
> preference management.
>
> Cheers,
>
> Christian
>
>
> On 2015-08-21 05:12:22 +0000, Ed Merks said:
>
>> Stephen,
>>
>> Comments below.
>>
>> On 20/08/2015 6:00 PM, Stephen Colebourne wrote:
>>> Thanks for engaging, I'll try to keep things as constructive as I can.
>> :-)
>>>
>>>> But given you could find no way to disable the recorder despite there
>>> being 3 ways, one of which one might have hoped would have been obvious
>>> enough, I'm not sure...
>>>
>>> I was able to disable the recorder (perfectly visible and
>>> understable UI), but that did not stop the problem I was seeing. My
>>> problem was that I was changing a preference, yet it was being reset
>>> every time I restarted Eclipse. I can see *now* that the user.setup
>>> file is "golden". Once something is in there, Oomph ensures that it
>>> gets reset on every restart. Problem is that is not what I
>>> wanted/expected.
>> Yes, I mentioned to Eike that I suspected you weren't expressing
>> yourself clearly. That what you couldn't figure out how to turn off
>> is the application of already-recorded preferences. We discussed an
>> approach for dealing with that, i.e., if you disable the recorder and
>> you have already recorded preferences to have the option of deleting
>> them all so that nothing is automatically done, if you don't want
>> that...
>>>
>>> What I wanted/expected was for the shared preferences in Oomph to
>>> set the *default* values for each new workspace.
>> Eclipse has a bunch of scope concepts, including defaults and bundle
>> default; they do this. We can only set values, not change defaults...
>>> Once set, I then expected all my subsequent changes to be retained.
>>> ie. my expected workflow was
>> That's not what the documentation says. We're trying an approach
>> where the documentation will be shown the first time you are shown
>> the confirmation dialog to record a preference. Reading this would
>> have answered many of your questions and set your expectations
>> correctly.
>>> - record once in the first instance of Mars using the recorder
>>> - turn the recorder off
>>> - start a second instance/workspace
>>> - configure whatever I want there based on the new defaults (with
>>> the recorder off)
>>> - retain those new values locally in the workspace (as per normal
>>> Eclipse behaviour)
>> Yes, unfortunately you're mixing up two different aspects. One
>> related to recording, and the other related to performing tasks.
>>> Clearly, this isn't how the Oomph team intends it to work, but I
>>> hope you can understand that the above was my assumption, and was
>>> not IMO an unreasonable mental model.
>> No, so we have to make more sure that if someone turns the recorder
>> off and expects that this will stop applying their preferences that
>> we make it clear that will only happen if they remove them.
>>> It is the "reset on every restart" that was the most painful part
>>> for me.
>> Yes, although when it sets things the way you want, it's totally
>> convenient.
>>>
>>> The above should explain why I think being able to choose *when* the
>>> preferences are applied is key.
>>>
>>> Concrete suggestion - add to the Oomph preferences page an option
>>> with three choices:
>>> - always reset shared preferences on restart
>>> - never reset shared preferences on restart
>>> - reset shared preferences on next restart only
>>> (maybe the last is more of a button than a radio button...)
>> You can already turn off performing tasks on startup, so likely some
>> kind of link to that preference would be good...
>>>
>>> Or is this what the "skip automatic task execution at startup time"
>>> is for?
>> Yes.
>>> (If it is, then consider that despite seeing that many times, I had
>>> no idea what it meant or might do. The notion of "startup tasks" did
>>> not connect to "shared preferences" for me.)
>> Yes, it would be good if the relation is made more clear...
>>>
>>>
>>>> Recording preferences is about your general personal preferences.
>>>> I.e., do I want line numbers in editors or not.
>>>
>>> I think this is a key part of where I struggled. The preferences
>>> recorder offers to record *everything*. This seems prone to cause
>>> problems as not everything should be accross all installations.
>> Exactly, but without metadata and with all this being open ended
>> (each plugin can have additional preferences), it's hard to know for
>> sure. And some things, like compiler preferences, are not even
>> clear if they should or shouldn't be the same across all
>> installations. That's mostly the user's choice...
>>> That UI should be changed to actively discourage users from setting
>>> too much into user.setup.
>> Of course the user should take responsibility as well, because who
>> decides what's appropriate and what's too much?
>>>
>>> Concrete suggestion - instead of a checkbox next to each preference
>>> in the preferences recorder, have a drop down list. The list would
>>> have the values "user", "installation", "workspace", "do not record".
>> With the ability to record into these resources, it would seem
>> simpler to open the installation, or workspace, in the case you want
>> to make specific changes for those...
>>>
>>> This suggestion would put Oomph's "mental model" right in the user's
>>> face. The user would have to think about where the setting will be
>>> stored and how much it will affect.
>> I think we at least need to get users to read the documentation.
>> Otherwise, nothing will work, because as you suggest, there needs to
>> be a mental model...
>>>
>>> This is also why I suggested a table (or tree table) for editing the
>>> preferences. While larger, I believe it would actually be simpler.
>>> For me, the problem with preferences is the multiple locations they
>>> can be set, and the implied hierarchy. Capturing that in one UI is
>>> important. The current editor UI is file based, and as such doesn't
>>> manage to express the hierarchy and underlying data model. IMO, it
>>> should be easy to push a setting from one level to another within a
>>> single UI.
>>>
>>>> I wonder though why you never looked at the help on the Oomph
>>>> Preference Recorder dialog?
>>>
>>> I looked for help in the Oomph preferences page. For me, the
>>> Preference Recorder dialog is the kind of dialog that I've never
>>> opened help from before. The actual help text there is quite
>>> reasonable.
>> We're making changes so that the first time that dialog is opened on
>> your machine, the help will be showing. We hope that helps.
>>>
>>> To summarize, there is goodness here, but it left me feeling like
>>> there was a troll somewhere in Eclipse randomly reseting preferences!
>> Yes, so we're actively looking at ways to ensure that when someone
>> turns the recorder off, that they understand the implications of the
>> fact that there are already-recorded preference and that those will
>> continue to be applied. That they can easily remove all those
>> preferences or easily turn off the automatic application of those
>> preferences. And of course to make it easy to record preferences
>> such that they're specific to an installation or even to just one
>> workspace, so that they can override the "default" preferences the
>> user generally wants everywhere except in the one specific
>> installation or the one specific workspace...
>>
>> Overtime we also expect to collect more data to learn about those
>> preferences that never make sense to set the same across all
>> workspaces, e.g., the workspace name!
>>
>> BTW, we're also working in a "find" support so that Ctrl-F works in
>> the editors. :-)
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Feedback on using Oomph [message #1706062 is a reply to message #1706058] |
Fri, 21 August 2015 14:00 |
|
Hi, Ed,
Oh, that's good to hear. Have I been labouring under a silly wrong
assumption all this time? Or has something changed? Either way, I
shall now return to auto-running the setup tasks on all of my workspace.
Thanks!
Christian
On 2015-08-21 12:56:58 +0000, Ed Merks said:
> Christian,
>
> Note that the p2 and targlet tasks have different behavior of isNeeded
> for startup trigger verses manual trigger. In the case of the p2
> tasks, it only makes sure that the units required by the task are
> actually installed; it does not check if there are update available.
> Similarly for the targlet task, it checks if the definition hasn't
> changed and that the expected target platform is active; it does not
> check if there are remote updates available for the TP. So in both
> cases, I generally don't expect these tasks to perform on startup (and
> the certainly don't for our Oomph workspace).
>
>
> On 21/08/2015 2:44 PM, Christian W. Damus wrote:
>> Hi,
>>
>> The new capability of recording preferences directly into a setup file
>> means that it should be easier to do what I have configured for myself,
>> having (I think) a similar use case to Stephen's.
>>
>> I have two "kinds" of workspaces: Papyrus workspaces and
>> everything-else workspaces. I need the same preferences for all of my
>> Papyrus workspaces, and the same preferences for all of the others, but
>> these are different preferences in the two classes of workspace.
>>
>> The way I have this working is that I keep, locally, two setup models
>> that only have preference settings: one setup model for Papyrus
>> preferences and one for the rest. Whenever I create a new Papyrus
>> workspace, I import my "Papyrus Prefs" project from the one local setup
>> model. Likewise when I create a new non-Papyrus workspace, using the
>> other setup model. The Oomph wizard makes it easy to add such local
>> setup models by just dragging and dropping them into the <User> area.
>>
>> The end result is that, whatever the workspace, it always automatically
>> applies my preferences when I start it up. Or when I explicitly run
>> the setup tasks (for Papyrus, I don't auto-run the setup because I
>> would end up downloading a new Papyrus nightly build every time I start
>> the workbench).
>>
>> Hoping this might help others that are having challenges with
>> preference management.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> On 2015-08-21 05:12:22 +0000, Ed Merks said:
>>
>>> Stephen,
>>>
>>> Comments below.
>>>
>>> On 20/08/2015 6:00 PM, Stephen Colebourne wrote:
>>>> Thanks for engaging, I'll try to keep things as constructive as I can.
>>> :-)
>>>>
>>>>> But given you could find no way to disable the recorder despite there
>>>> being 3 ways, one of which one might have hoped would have been obvious
>>>> enough, I'm not sure...
>>>>
>>>> I was able to disable the recorder (perfectly visible and understable
>>>> UI), but that did not stop the problem I was seeing. My problem was
>>>> that I was changing a preference, yet it was being reset every time I
>>>> restarted Eclipse. I can see *now* that the user.setup file is
>>>> "golden". Once something is in there, Oomph ensures that it gets reset
>>>> on every restart. Problem is that is not what I wanted/expected.
>>> Yes, I mentioned to Eike that I suspected you weren't expressing
>>> yourself clearly. That what you couldn't figure out how to turn off is
>>> the application of already-recorded preferences. We discussed an
>>> approach for dealing with that, i.e., if you disable the recorder and
>>> you have already recorded preferences to have the option of deleting
>>> them all so that nothing is automatically done, if you don't want
>>> that...
>>>>
>>>> What I wanted/expected was for the shared preferences in Oomph to set
>>>> the *default* values for each new workspace.
>>> Eclipse has a bunch of scope concepts, including defaults and bundle
>>> default; they do this. We can only set values, not change defaults...
>>>> Once set, I then expected all my subsequent changes to be retained. ie.
>>>> my expected workflow was
>>> That's not what the documentation says. We're trying an approach where
>>> the documentation will be shown the first time you are shown the
>>> confirmation dialog to record a preference. Reading this would have
>>> answered many of your questions and set your expectations correctly.
>>>> - record once in the first instance of Mars using the recorder
>>>> - turn the recorder off
>>>> - start a second instance/workspace
>>>> - configure whatever I want there based on the new defaults (with the
>>>> recorder off)
>>>> - retain those new values locally in the workspace (as per normal
>>>> Eclipse behaviour)
>>> Yes, unfortunately you're mixing up two different aspects. One related
>>> to recording, and the other related to performing tasks.
>>>> Clearly, this isn't how the Oomph team intends it to work, but I hope
>>>> you can understand that the above was my assumption, and was not IMO an
>>>> unreasonable mental model.
>>> No, so we have to make more sure that if someone turns the recorder off
>>> and expects that this will stop applying their preferences that we make
>>> it clear that will only happen if they remove them.
>>>> It is the "reset on every restart" that was the most painful part for me.
>>> Yes, although when it sets things the way you want, it's totally convenient.
>>>>
>>>> The above should explain why I think being able to choose *when* the
>>>> preferences are applied is key.
>>>>
>>>> Concrete suggestion - add to the Oomph preferences page an option with
>>>> three choices:
>>>> - always reset shared preferences on restart
>>>> - never reset shared preferences on restart
>>>> - reset shared preferences on next restart only
>>>> (maybe the last is more of a button than a radio button...)
>>> You can already turn off performing tasks on startup, so likely some
>>> kind of link to that preference would be good...
>>>>
>>>> Or is this what the "skip automatic task execution at startup time" is for?
>>> Yes.
>>>> (If it is, then consider that despite seeing that many times, I had no
>>>> idea what it meant or might do. The notion of "startup tasks" did not
>>>> connect to "shared preferences" for me.)
>>> Yes, it would be good if the relation is made more clear...
>>>>
>>>>
>>>>> Recording preferences is about your general personal preferences. I.e.,
>>>>> do I want line numbers in editors or not.
>>>>
>>>> I think this is a key part of where I struggled. The preferences
>>>> recorder offers to record *everything*. This seems prone to cause
>>>> problems as not everything should be accross all installations.
>>> Exactly, but without metadata and with all this being open ended (each
>>> plugin can have additional preferences), it's hard to know for sure.
>>> And some things, like compiler preferences, are not even clear if they
>>> should or shouldn't be the same across all installations. That's
>>> mostly the user's choice...
>>>> That UI should be changed to actively discourage users from setting too
>>>> much into user.setup.
>>> Of course the user should take responsibility as well, because who
>>> decides what's appropriate and what's too much?
>>>>
>>>> Concrete suggestion - instead of a checkbox next to each preference in
>>>> the preferences recorder, have a drop down list. The list would have
>>>> the values "user", "installation", "workspace", "do not record".
>>> With the ability to record into these resources, it would seem simpler
>>> to open the installation, or workspace, in the case you want to make
>>> specific changes for those...
>>>>
>>>> This suggestion would put Oomph's "mental model" right in the user's
>>>> face. The user would have to think about where the setting will be
>>>> stored and how much it will affect.
>>> I think we at least need to get users to read the documentation.
>>> Otherwise, nothing will work, because as you suggest, there needs to be
>>> a mental model...
>>>>
>>>> This is also why I suggested a table (or tree table) for editing the
>>>> preferences. While larger, I believe it would actually be simpler. For
>>>> me, the problem with preferences is the multiple locations they can be
>>>> set, and the implied hierarchy. Capturing that in one UI is important.
>>>> The current editor UI is file based, and as such doesn't manage to
>>>> express the hierarchy and underlying data model. IMO, it should be easy
>>>> to push a setting from one level to another within a single UI.
>>>>
>>>>> I wonder though why you never looked at the help on the Oomph
>>>>> Preference Recorder dialog?
>>>>
>>>> I looked for help in the Oomph preferences page. For me, the Preference
>>>> Recorder dialog is the kind of dialog that I've never opened help from
>>>> before. The actual help text there is quite reasonable.
>>> We're making changes so that the first time that dialog is opened on
>>> your machine, the help will be showing. We hope that helps.
>>>>
>>>> To summarize, there is goodness here, but it left me feeling like there
>>>> was a troll somewhere in Eclipse randomly reseting preferences!
>>> Yes, so we're actively looking at ways to ensure that when someone
>>> turns the recorder off, that they understand the implications of the
>>> fact that there are already-recorded preference and that those will
>>> continue to be applied. That they can easily remove all those
>>> preferences or easily turn off the automatic application of those
>>> preferences. And of course to make it easy to record preferences such
>>> that they're specific to an installation or even to just one workspace,
>>> so that they can override the "default" preferences the user generally
>>> wants everywhere except in the one specific installation or the one
>>> specific workspace...
>>>
>>> Overtime we also expect to collect more data to learn about those
>>> preferences that never make sense to set the same across all
>>> workspaces, e.g., the workspace name!
>>>
>>> BTW, we're also working in a "find" support so that Ctrl-F works in the
>>> editors. :-)
|
|
|
| Re: Feedback on using Oomph [message #1706063 is a reply to message #1706062] |
Fri, 21 August 2015 14:10 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Christian,
I think it's always been this way.
On 21/08/2015 4:00 PM, Christian W. Damus wrote:
> Hi, Ed,
>
> Oh, that's good to hear. Have I been labouring under a silly wrong
> assumption all this time? Or has something changed? Either way, I
> shall now return to auto-running the setup tasks on all of my workspace.
>
> Thanks!
>
> Christian
>
>
> On 2015-08-21 12:56:58 +0000, Ed Merks said:
>
>> Christian,
>>
>> Note that the p2 and targlet tasks have different behavior of
>> isNeeded for startup trigger verses manual trigger. In the case of
>> the p2 tasks, it only makes sure that the units required by the task
>> are actually installed; it does not check if there are update
>> available. Similarly for the targlet task, it checks if the
>> definition hasn't changed and that the expected target platform is
>> active; it does not check if there are remote updates available for
>> the TP. So in both cases, I generally don't expect these tasks to
>> perform on startup (and the certainly don't for our Oomph workspace).
>>
>>
>> On 21/08/2015 2:44 PM, Christian W. Damus wrote:
>>> Hi,
>>>
>>> The new capability of recording preferences directly into a setup
>>> file means that it should be easier to do what I have configured for
>>> myself, having (I think) a similar use case to Stephen's.
>>>
>>> I have two "kinds" of workspaces: Papyrus workspaces and
>>> everything-else workspaces. I need the same preferences for all of
>>> my Papyrus workspaces, and the same preferences for all of the
>>> others, but these are different preferences in the two classes of
>>> workspace.
>>>
>>> The way I have this working is that I keep, locally, two setup
>>> models that only have preference settings: one setup model for
>>> Papyrus preferences and one for the rest. Whenever I create a new
>>> Papyrus workspace, I import my "Papyrus Prefs" project from the one
>>> local setup model. Likewise when I create a new non-Papyrus
>>> workspace, using the other setup model. The Oomph wizard makes it
>>> easy to add such local setup models by just dragging and dropping
>>> them into the <User> area.
>>>
>>> The end result is that, whatever the workspace, it always
>>> automatically applies my preferences when I start it up. Or when I
>>> explicitly run the setup tasks (for Papyrus, I don't auto-run the
>>> setup because I would end up downloading a new Papyrus nightly build
>>> every time I start the workbench).
>>>
>>> Hoping this might help others that are having challenges with
>>> preference management.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> On 2015-08-21 05:12:22 +0000, Ed Merks said:
>>>
>>>> Stephen,
>>>>
>>>> Comments below.
>>>>
>>>> On 20/08/2015 6:00 PM, Stephen Colebourne wrote:
>>>>> Thanks for engaging, I'll try to keep things as constructive as I
>>>>> can.
>>>> :-)
>>>>>
>>>>>> But given you could find no way to disable the recorder despite
>>>>>> there
>>>>> being 3 ways, one of which one might have hoped would have been
>>>>> obvious
>>>>> enough, I'm not sure...
>>>>>
>>>>> I was able to disable the recorder (perfectly visible and
>>>>> understable UI), but that did not stop the problem I was seeing.
>>>>> My problem was that I was changing a preference, yet it was being
>>>>> reset every time I restarted Eclipse. I can see *now* that the
>>>>> user.setup file is "golden". Once something is in there, Oomph
>>>>> ensures that it gets reset on every restart. Problem is that is
>>>>> not what I wanted/expected.
>>>> Yes, I mentioned to Eike that I suspected you weren't expressing
>>>> yourself clearly. That what you couldn't figure out how to turn
>>>> off is the application of already-recorded preferences. We
>>>> discussed an approach for dealing with that, i.e., if you disable
>>>> the recorder and you have already recorded preferences to have the
>>>> option of deleting them all so that nothing is automatically done,
>>>> if you don't want that...
>>>>>
>>>>> What I wanted/expected was for the shared preferences in Oomph to
>>>>> set the *default* values for each new workspace.
>>>> Eclipse has a bunch of scope concepts, including defaults and
>>>> bundle default; they do this. We can only set values, not change
>>>> defaults...
>>>>> Once set, I then expected all my subsequent changes to be
>>>>> retained. ie. my expected workflow was
>>>> That's not what the documentation says. We're trying an approach
>>>> where the documentation will be shown the first time you are shown
>>>> the confirmation dialog to record a preference. Reading this would
>>>> have answered many of your questions and set your expectations
>>>> correctly.
>>>>> - record once in the first instance of Mars using the recorder
>>>>> - turn the recorder off
>>>>> - start a second instance/workspace
>>>>> - configure whatever I want there based on the new defaults (with
>>>>> the recorder off)
>>>>> - retain those new values locally in the workspace (as per normal
>>>>> Eclipse behaviour)
>>>> Yes, unfortunately you're mixing up two different aspects. One
>>>> related to recording, and the other related to performing tasks.
>>>>> Clearly, this isn't how the Oomph team intends it to work, but I
>>>>> hope you can understand that the above was my assumption, and was
>>>>> not IMO an unreasonable mental model.
>>>> No, so we have to make more sure that if someone turns the recorder
>>>> off and expects that this will stop applying their preferences that
>>>> we make it clear that will only happen if they remove them.
>>>>> It is the "reset on every restart" that was the most painful part
>>>>> for me.
>>>> Yes, although when it sets things the way you want, it's totally
>>>> convenient.
>>>>>
>>>>> The above should explain why I think being able to choose *when*
>>>>> the preferences are applied is key.
>>>>>
>>>>> Concrete suggestion - add to the Oomph preferences page an option
>>>>> with three choices:
>>>>> - always reset shared preferences on restart
>>>>> - never reset shared preferences on restart
>>>>> - reset shared preferences on next restart only
>>>>> (maybe the last is more of a button than a radio button...)
>>>> You can already turn off performing tasks on startup, so likely
>>>> some kind of link to that preference would be good...
>>>>>
>>>>> Or is this what the "skip automatic task execution at startup
>>>>> time" is for?
>>>> Yes.
>>>>> (If it is, then consider that despite seeing that many times, I
>>>>> had no idea what it meant or might do. The notion of "startup
>>>>> tasks" did not connect to "shared preferences" for me.)
>>>> Yes, it would be good if the relation is made more clear...
>>>>>
>>>>>
>>>>>> Recording preferences is about your general personal preferences.
>>>>>> I.e., do I want line numbers in editors or not.
>>>>>
>>>>> I think this is a key part of where I struggled. The preferences
>>>>> recorder offers to record *everything*. This seems prone to cause
>>>>> problems as not everything should be accross all installations.
>>>> Exactly, but without metadata and with all this being open ended
>>>> (each plugin can have additional preferences), it's hard to know
>>>> for sure. And some things, like compiler preferences, are not
>>>> even clear if they should or shouldn't be the same across all
>>>> installations. That's mostly the user's choice...
>>>>> That UI should be changed to actively discourage users from
>>>>> setting too much into user.setup.
>>>> Of course the user should take responsibility as well, because who
>>>> decides what's appropriate and what's too much?
>>>>>
>>>>> Concrete suggestion - instead of a checkbox next to each
>>>>> preference in the preferences recorder, have a drop down list. The
>>>>> list would have the values "user", "installation", "workspace",
>>>>> "do not record".
>>>> With the ability to record into these resources, it would seem
>>>> simpler to open the installation, or workspace, in the case you
>>>> want to make specific changes for those...
>>>>>
>>>>> This suggestion would put Oomph's "mental model" right in the
>>>>> user's face. The user would have to think about where the setting
>>>>> will be stored and how much it will affect.
>>>> I think we at least need to get users to read the documentation.
>>>> Otherwise, nothing will work, because as you suggest, there needs
>>>> to be a mental model...
>>>>>
>>>>> This is also why I suggested a table (or tree table) for editing
>>>>> the preferences. While larger, I believe it would actually be
>>>>> simpler. For me, the problem with preferences is the multiple
>>>>> locations they can be set, and the implied hierarchy. Capturing
>>>>> that in one UI is important. The current editor UI is file based,
>>>>> and as such doesn't manage to express the hierarchy and underlying
>>>>> data model. IMO, it should be easy to push a setting from one
>>>>> level to another within a single UI.
>>>>>
>>>>>> I wonder though why you never looked at the help on the Oomph
>>>>>> Preference Recorder dialog?
>>>>>
>>>>> I looked for help in the Oomph preferences page. For me, the
>>>>> Preference Recorder dialog is the kind of dialog that I've never
>>>>> opened help from before. The actual help text there is quite
>>>>> reasonable.
>>>> We're making changes so that the first time that dialog is opened
>>>> on your machine, the help will be showing. We hope that helps.
>>>>>
>>>>> To summarize, there is goodness here, but it left me feeling like
>>>>> there was a troll somewhere in Eclipse randomly reseting preferences!
>>>> Yes, so we're actively looking at ways to ensure that when someone
>>>> turns the recorder off, that they understand the implications of
>>>> the fact that there are already-recorded preference and that those
>>>> will continue to be applied. That they can easily remove all those
>>>> preferences or easily turn off the automatic application of those
>>>> preferences. And of course to make it easy to record preferences
>>>> such that they're specific to an installation or even to just one
>>>> workspace, so that they can override the "default" preferences the
>>>> user generally wants everywhere except in the one specific
>>>> installation or the one specific workspace...
>>>>
>>>> Overtime we also expect to collect more data to learn about those
>>>> preferences that never make sense to set the same across all
>>>> workspaces, e.g., the workspace name!
>>>>
>>>> BTW, we're also working in a "find" support so that Ctrl-F works in
>>>> the editors. :-)
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Feedback on using Oomph [message #1706729 is a reply to message #1706007] |
Sat, 29 August 2015 09:36 |
Stephen Colebourne
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Ed Merks wrote on Fri, 21 August 2015 01:12
We discussed an approach for dealing with that, i.e., if you disable the recorder and you have already recorded preferences to have the option of deleting them all so that nothing is automatically done, if you don't want that...
That sounds like it would be useful
Ed Merks wrote on Fri, 21 August 2015 01:12
We're trying an approach where the documentation will be shown the first time you are shown the confirmation dialog to record a preference.
Yep, I can see that would help. I'd love to see a picture of the Eclipse/preferences hierarchy - user/installation/workspace, as that would solidify the meaning of each word.
Ed Merks wrote on Fri, 21 August 2015 01:12
> It is the "reset on every restart" that was the most painful part for me.
Yes, although when it sets things the way you want, it's totally convenient.
Maybe. It gets problematic if I have a personal preference, but a particular project needs it to be different. While Oomph can manage this (through project level setup files IIUC), that relies on all projects being configured using Oomph. A defaulting mechanism, or apply setup on demand via a button would IMO be more generally useful.
Ed Merks wrote on Fri, 21 August 2015 01:12
> Concrete suggestion - instead of a checkbox next to each preference in
> the preferences recorder, have a drop down list. The list would have
> the values "user", "installation", "workspace", "do not record".
With the ability to record into these resources, it would seem simpler to open the installation, or workspace, in the case you want to make specific changes for those...
Without preference metadata things are tricky. That is why the preferences recorder save dialog is important. It is why I suggest it is the only place that is close enough to the user's experience for the user to be able to identify whether the preference should be shared and where.
I basically agree with Eike's most recent reply on this, although I'd put the combo box against each row
Thanks again for engaging.
|
|
|
| Re: Feedback on using Oomph [message #1706977 is a reply to message #1706729] |
Tue, 01 September 2015 09:19 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephen,
We've made a few improvements already but further improvements would
definitely help. We'll consider your suggestions.
BTW, one feature that I've added last week is general support for
Find/Replace in Oomph's structured editors. This makes it much easier
to find a preference in your user.setup, or to find anything interesting
for that matter... It's fully integrated with the text edtor's
Find/Replace dialog, with some nice enhancements, e.g., to search only
labels, or search labels and the values of attributes...
On 29/08/2015 11:36 AM, Stephen Colebourne wrote:
> Ed Merks wrote on Fri, 21 August 2015 01:12
>> We discussed an approach for dealing with that, i.e., if you disable
>> the recorder and you have already recorded preferences to have the
>> option of deleting them all so that nothing is automatically done, if
>> you don't want that...
>
> That sounds like it would be useful
>
> Ed Merks wrote on Fri, 21 August 2015 01:12
>> We're trying an approach where the documentation will be shown the
>> first time you are shown the confirmation dialog to record a preference.
>
> Yep, I can see that would help. I'd love to see a picture of the
> Eclipse/preferences hierarchy - user/installation/workspace, as that
> would solidify the meaning of each word.
>
> Ed Merks wrote on Fri, 21 August 2015 01:12
>> > It is the "reset on every restart" that was the most painful part
>> for me.
>> Yes, although when it sets things the way you want, it's totally
>> convenient.
>
> Maybe. It gets problematic if I have a personal preference, but a
> particular project needs it to be different. While Oomph can manage
> this (through project level setup files IIUC), that relies on all
> projects being configured using Oomph. A defaulting mechanism, or
> apply setup on demand via a button would IMO be more generally useful.
>
> Ed Merks wrote on Fri, 21 August 2015 01:12
>> > Concrete suggestion - instead of a checkbox next to each preference
>> in > the preferences recorder, have a drop down list. The list would
>> have > the values "user", "installation", "workspace", "do not record".
>> With the ability to record into these resources, it would seem
>> simpler to open the installation, or workspace, in the case you want
>> to make specific changes for those...
>
> Without preference metadata things are tricky. That is why the
> preferences recorder save dialog is important. It is why I suggest it
> is the only place that is close enough to the user's experience for
> the user to be able to identify whether the preference should be
> shared and where.
>
> I basically agree with Eike's most recent reply on this, although I'd
> put the combo box against each row
> Thanks again for engaging.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 23:10:01 GMT 2024
Powered by FUDForum. Page generated in 0.54994 seconds |
] 
Search
Help
Register
Login
Home
