|
Along the same line, another solution
would be to split all the contributions done through XML into
their separate bundle. For example if I have a UI plugin with a
view and one menu contribution, then I would have 3 bundles. One
with the code, one for the XML of the view and another one for the
menu contribution (this could probably be automated at build
time).
Then someone trying to compose an IDE would just have to pick and
chose the right bundles to include.
There would be a runtime overhead because of the number of bundles
that would result from this split but I'm pretty sure that this
becomes irrelevant pasted the first run because of the caching .
lazy loading mechanism in Equinox.
Now these mechanisms are fine but they are means to achieve
Integration but they don't do it automatically and it is unclear
if real users would be willing to do it.
Pascal
On 11/03/2014 4:10 PM, Eric Moffatt wrote:
OK...here's my take on an
approach that tries to live in the reality of our current
state. Take everything below with a grain of salt and bear
with me if I'm off the mark on some of the packaging
details...
Right now we define an EPP by
aggregating a set of Features, each specifying the bundles
required to support it. Each bundle may contain any number of
contributions to the UI *all* of which get picked up with the
bundle (the key issue with our bloat IMO). The XSLT approach
was an attempt to help here but I don't think it had the
necessary tooling support to succeed (see below).
Bundle structures are pretty
well fixed in place, nobody's got the time to go over them all
and there's really no 'proper' way to split them up based on
their contributions anyway. We need a fine grained mechanism
to deal with this without directly having to modify the
existing bundles.
What we need is a way to
uniquely identify and filter out any given contribution (be it
Menu[Item], KeyBinding, View, Editor, Perspective...). Let's
say we have a file defining the filters (could even be an XLST
file if appropriate) for a particular bundle. This means that
we can now re-package the *same* bundle with different subsets
of functionality, giving far greater flexibility to anyone
wanting to package up certain capabilities but not others even
when using the same bundle(s). A bundle's 'install' is now a
tuple, the bundle itself and the file defining which UI
contributions are to be exposed to the application when
reading the registry.
The sticking point here may
well be that we need a way to uniquely identify those
contributions we want from a particular bundle. Maybe it's
better if the file identifies the ones that we *want* rather
than the ones to filter out. The advantage of this approach is
that any work needed to add ids to contributions would only
have to be done for contributions that are 'in'
EasyEclipse...for the tooling below I'm going to take some way
to do this as a given (otherwise I think the exercise is
doomed due to the amount of actual effort / coordination
required)
As far as the tooling goes what
I see is something akin to the current Plug-in Registry view
except that the tree being shown for a given bundle would be a
'checkbox' tree, allowing the product packager to directly
select the contributions they want. Conversely a tree that
given a 'product' (list of Features) could show all extensions
for a given extension point. This has the added advantage that
it would be able to show all the handlers / key bindings for a
given Command under the command in the tree (meaning that if
you uncheck the Command then all its handlers and bindings
also get filtered (similarly for other related contributions
such as EditorActions/ViewActions...).
This is of course not a
complete solution. It doesn't help much with preferences but
surely each 'install' could also come with a pre-defined
default preference definition. Note that we while it'd be
great to also be able to filter out unwanted prefs we'd have
to address the problems associated with the separately defined
PreferencePages (which will still have UI for the preference).
It also doesn't solve cases where some contributions are
related in non-obvious ways (i.e. an editor whose
implementation requires a particular view to be available...).
A final thought (YAY!)....early
on there was some discussion about providing an 'all in'
install since download speeds have gone up and disk space is
cheap. This approach could be extended upwards to include
which features are to be included. Think of an update site
called 'local' which simply removes the filter from the
desired feature ( / bundle... ) from the filter, exposing the
code that's already on your drive...
Back to slides,
Eric
 Eric
Moffatt---03/11/2014 02:50:01 PM---Miles, I think you've
pretty well nailed the base issue; our UI is an aggregation of
many different
Miles, I think you've pretty well
nailed the base issue; our UI is an aggregation of many
different bundles, each with their own extensions but with no
finer-grained control over what is 'important' to a particular
role. I'm very glad that 'bloat control' has finally reached the
level where the community is *actively* looking for a mechanism
to get a handle on this...
We've actually implemented a number of approaches to mitigate
this over the years:
Perspectives:
Tries to 'bundle' the views appropriate to a work flow within
that perspective. The problem here is that it's not enforced
(i.e. you see *all* views in the ShowView dialog), can't prevent
other bundles from 'polluting' a given perspective with their
own views (including adding them to the 'shortcuts', making them
'first class' citizens of the perspective. This also lead to the
'progressive discovery' approach..."Would you like to open the
Debug Perspective ?" which is OK but represents a single
hard-coded path to a particular perspective.
ActionSets: An
attempt to limit the number of visible command elements (mostly
menu items / TB's) by 'chunking' them into groups to which
common visibility behaviors are applied. Aside from being the
bane of our existence these also suffer from the lack of fine
grained support.
Activities:
Another attempt to limit the visibility of various UI
elements...apparently not used much due to complexities in
defining the 'Activity' definition.
There's also been some work on a lower level approach, removing
extensions 'on the fly'; see
'https://wiki.eclipse.org/Product_Customization' and 'https://wiki.eclipse.org/Equinox_Transforms'. Aside from the issues of having to
hand-craft the XSLT I think that this is near to the correct
approach (i.e. removing the complexity in the UI *before* the
application starts). Again this also suffers from being less
than flexible after defined (how do I as a user get something
back if it's been 'filtered' ?).
Finally, of course, there are the EPP packages...
In short....even with all these abilities in place we're still
where we're at...perhaps a new approach is needed ?
I'll outline some ideas for a possible approach in a separate
email...;-),
Eric
Miles Parker
---03/10/2014 02:00:40 PM---Right. This is what I think of as
the “right-click” problem. Supposedly the Eclipse context menu
is
Right. This is what I think of as the “right-click” problem.
Supposedly the Eclipse context menu is “contextualized”, but
that when you right click on an editor and there are 37 items
on the menu, it’s clear the context isn’t refined enough! When
“Paste” is the 15th item on that list, it’s evidence for even
the most casual user noone is in a position to force a
disciplined high-level design for the overall product. That’s
why efforts like EasyEclipse are important. You need someone
who cares about the typical end user — (and who makes money --
maybe not 1% money, but *some* money -- by caring) — to be
able to make the hard choices about what get’s in by default
and what doesn’t. But even with that effort, without providing
tools to support deeper contextualization, we lose the
advantage as soon as people start using plugin-ins, which is
after all one of the strongest features of the Eclipse
ecosystem.
The basic dilemma of Ux design is the same design conundrum as
with all technologies from babylon on — how to give maximum
information and control with minimum effort and cognitive
load? One answer is to contextualize (the most extreme example
being the original iPod scroll wheel). Mylyn has gone a long
way toward addressing the issue of content-based
contextualization, but the community hasn't effectively
addressed the issue of role or activity-based
contextualization. The closest thing we have for that in
Eclipse-land is Perspectives and that’s far too coarse grained
and cognitively disruptive. But the great thing about Eclipse
is that all of the underlying technologies to make a truly
contextualized experience are all there. It’s “just” a matter
of developing some approaches (and metaphors?) that support
transparent, fluid and user-guided role contextualization and
filtering UI and execution elements based on that.
On Mar 9, 2014, at 8:58 PM, Andrew Eisenberg
<andrew@xxxxxxxxxxxx> wrote:
> I wouldn't be surprised if uninstalling Groovy-Eclipse
could address some of his problems, but the post shows a
larger problem with the IDE work we are (or at least I am)
doing. Too often features are implemented so that a handful
of vocal users are happy, but the silent 99% don't have their
needs fully met.
>
> As a simple example, consider this statement: "Sometimes,
selecting a launch configuration with arrow keys and hitting
enter twice to run it works. Sometimes, it runs a previous
launch configuration. Using the mouse is fully reliable but
less efficient." I'm pretty sure it's because sometimes he has
the editor active and the expected thing runs, but sometimes
some other view is active. This makes sense to power users and
the behavior is consistent with the rest of Eclipse, but it is
probably non-intuitive for new users.
>
> The problem is that determining and implementing the most
intuitive workflow for new users that doesn't annoy power
users is not a cheap or easy process. It involves something
like user studies and active engagement with all of the
community (not just the 1% (no, not *that* 1%)). I admit that
this is something that I have failed to do enough of.
>
>
>
> On Sat, Mar 8, 2014 at 11:32 PM, Max Rydahl Andersen
<manderse@xxxxxxxxxx> wrote:
> I think it's worth noticing he mentions groovy eclipse
which to make it work "hot patches" the JDT.
>
> Pretty sure he should try uninstall groovy eclipse and
see if that doesn't improve his eclipse experience.
>
> This shows how great it would be if jdt could be better
at allowing other javavm based languages to integrate better
so tricks like hot patching aren't needed.
>
> /max (sent from my phone)
>
>
> > On 09/03/2014, at 06.02, Doug Schaefer
<dschaefer@xxxxxxx> wrote:
> >
> > Interesting post. I'd love if we could find some way
to enforce consistency in the IDE. There's lots of things we
can override. I wonder if it's enough. Food for thought.
> >
> > I love the comparison with netbeans and intellij.
Eclipse has so much to offer. We just need to find a way to
manage the product as a whole to make it great.
> >
> > Thanks for this Stephan.
> >
> > Sent from my BlackBerry 10 smartphone on the Rogers
network.
> > Original Message
> > From: Stephan Herrmann
> > Sent: Saturday, March 8, 2014 8:35 PM
> > To: ide-dev@xxxxxxxxxxx
> > Reply To: Discussions about the IDE
> > Subject: Re: [ide-dev] Inconsistent Eclipse user
experience
> >
> >
> > Have you guys seen this:
> >
> > http://www.eclipse.org/forums/index.php/mv/msg/668948/1267143/#msg_1267143
> >
> > Sounds like another client for this group :)
> >
> > best,
> > Stephan
> > _______________________________________________
> > ide-dev mailing list
> > ide-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ide-dev
> > _______________________________________________
> > ide-dev mailing list
> > ide-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ide-dev
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
>
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
|
