Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Inconsistent Eclipse user experience

Hi Doug,

I'm mostly lurking around on the thread, but, being the PyDev main developer I can comment on PyDev...

Well, the major issue I have is that Eclipse seems to be done in a way that you have to build before you run something which is far away from how PyDev works, where the build is mostly just a way to index my sources -- which should never *ever* stop what the user is doing (which for me is what makes Eclipse *feel* heavier than it actually is).

So, at this point when PyDev is run the first I ask the user if I should change those assumptions (basically launch without building and launch without waiting for any build -- I had some people asking me how did I do PyDev run *so* faster after that change -- although it's still not perfect as other things as *save* are still blocked by build jobs:

Note that if Python is the main thing I probably shouldn't even ask and just apply it... but if I do that and it's not the case I can mess the env for CDT/JDT, so, the better option for me was asking the user on startup (burying it in the preferences simply doesn't work as most users won't know they should change that when using PyDev)... but if you have a better way to ask the user such a thing I'm open to it (yes, making lots of plugins with such different requirements talk to each other properly can be hard).



On Mon, Mar 17, 2014 at 2:04 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
That depends. How confused does this make the user, especially if they're new. 

But yours is just one example, not to pick on you. There are many things that end up in the UI that have no relevance to what the user is doing at the time. Dialogs on startup are the most evil. I'm looking at you Android and Pydev ;)

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Ed Willink
Sent: Sunday, March 16, 2014 12:08 PM
To: Discussions about the IDE
Reply To: Discussions about the IDE
Subject: Re: [ide-dev] Inconsistent Eclipse user experience

Hi Doug

But what is the non-OCL context?

e.g. in CDT if the cursor selects something that is adaptable to an EObject an OCL query can be used to query/validate the underlying EMF model.

OCL has a can-I-find-an-EObject filter.

As a non-hypothetical example, OCL can enhance an Xtext editor with corporate style checking. Is that good or bad?


        Ed Willink

On 16/03/2014 14:38, Doug Schaefer wrote:
Well, no, in the non OCL context, OCL should be invisible. Imagine if the user had 20 such environments installed. Don't you think it would be overwhelming? Shared menus and the global toolbar are not places where you should be allowed to freely add items in any context. Keep them focused and only enable them when the user is using your plug-in or about to (and they're not always about to, BTW).

I encourage people to take a look at our most recent Momentics for BlackBerry IDE, and I'll be happy to show previews of our upcoming one at EclipseCon. We've pretty much done away with the global toolbar. We were able to do that using e4 and overriding the trimbar renderer to replace the layout with ours which is very picky about what goes there. I'd like to see if we can figure out the same for menus, possibly even going down to putting hooks in the SWT layer. Or at least see what we can do with the Project Navigator which is the biggest problem at the moment.

As Mike mentioned, we don't have resources to add a whole new API layer and get all the plug-ins to adopt it. We need to be clever and use what we have.

This is becoming a conversation we should be having over beers ;)


From: ide-dev-bounces@xxxxxxxxxxx [ide-dev-bounces@xxxxxxxxxxx] on behalf of Ed Willink [ed@xxxxxxxxxxxxx]
Sent: Sunday, March 16, 2014 8:23 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Inconsistent Eclipse user experience


Influenced by earlier rounds of this discussion, I have been moving my contributions to the global UI from e.g. "Load Complete OCL Resource" to "OCL->Load Document" so that the OCL added value in non-OCL-specific contexts is clearly identifiable as an OCL add-on.

This reduces menu growth by grouping all OCL add-ons under one heading
This enables users to look for extra OCL functionality when they want it
This reduces the OCL impact when not wanted
This increases the perception of OCL bugs as OCL bugs rather than  Eclipse bugs

This seems like a relatively easy policy to enforce once there is general agreement that it is a good idea.

Contributions to your own UI may use top level menu entries.
Contributions to someone else's UI should have a top level scoping of sub-level entries unless the relevant someone else endorses the top level usage.

So no one should contribute

Add XXX Nature

rather they could contribute

XXX->Add Nature

but since there is a dedicated top level entry they should contribute

Configure->Add XXX Nature


        Ed Willink

On 15/03/2014 22:55, Doug Schaefer wrote:
These are all solutions that are hard to pull off and I'm not sure they really address the root of the problem. We are at the mercy of the plug-in developers and how well they implement their solutions. I love Eclipse and want to bring it to my customers because of the feature richness of the ecosystem. No one else has a great C++ IDE that also does Python and HTML5 and Java and ...

But at the same time we don't really have guidelines or an API that enforces consistency in the user experience. It's almost a crime that we let any plug-in contribute anything to the UI. And they do. Does that PyDev and V8 Debugging menu really make sense on my Eclipse plug-in project? How do we get all these plug-ins to play nice when installed with each other and all at the same time? That's the hard question.


From: ide-dev-bounces@xxxxxxxxxxx [ide-dev-bounces@xxxxxxxxxxx] on behalf of Mike Milinkovich [mike.milinkovich@xxxxxxxxxxx]
Sent: Saturday, March 15, 2014 4:19 PM
To: Pascal Rapicault; Discussions about the IDE
Subject: Re: [ide-dev] Inconsistent Eclipse user experience

On 15/03/2014 3:45 PM, Pascal Rapicault wrote:
Sadly the outcome of the process back then was rather protective.

Ya, I know. We are incredibly cautious about data privacy and the like.

ide-dev mailing list

No virus found in this message.
Checked by AVG -
Version: 2014.0.4336 / Virus Database: 3722/7199 - Release Date: 03/15/14

ide-dev mailing list

No virus found in this message.
Checked by AVG -
Version: 2014.0.4336 / Virus Database: 3722/7200 - Release Date: 03/15/14

ide-dev mailing list

Back to the top