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

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 ;)

Doug.



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

Hi

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

    Regards

        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.

Doug.


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.

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223

EclipseCon 2014


_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev


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



Back to the top