[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Contributing parts to the workbench
|
| I too would like to keep things simple while maximizing flexibility. I have to say my initial reaction to the "tagging" concept is that it would be fairly complex. And coming up with a set of tags that would work for everyone seems like a difficult task.
My hope is that e4 will expand our options for contributing parts without taking our old options away (e.g. perspectives), but we need a declarative way to do this other than perspectiveExtensions. One approach, as I alluded to earlier, would be to copy the locationURI mechanism we use for menus. This would allow us to contribute parts to an addressable location in the hierarchy. Here's a first pass at what it would look like:
part:<parent id>?<relationship>=<relative id>
So say you had a window with an id of "mainwindow" and there was already a part there with an id of "outline". You could specify:
part:mainwindow?leftof=outline
You'd still obviously need to specify a ratio and other elements, but you get the idea. What do people think about this?
--- Patrick
On Sep 21, 2009, at 3:41 PM, Elias Volanakis wrote: I quite liked perspectives -- with one exception: the idea that editors are visible in all perspectives has been a pain-point in many of my RCP applications. <personal pov> Looking at the big picture: I like that one of e4's goals is simplicity.
Historically eclipse has been emphasizing flexibility much more than simplicity, to the point where its scaring developers away. Especially in the context of web applications, where other technologies are more straightforward, less flexible and have limited scope. Keep in mind that the learning curve for newbies is already high (bundles / extension points / workbench model).
From my POV, it would be good to keep the essential e4 extension points as simple as possible. More like the actions-EP -- less like the commands-EP. This is not to say that we could not have a layered approach with less complicated EPs build on top of the super flexible EPs.
My biggest fear is that e4 will not be simpler than 3.x and developers will end picking another technology, that offers less but is simpler to work with (at your next java user group meeting, ask how many Eclipse users have written a plugin -- I'm always surprised that the results are not higher)
</personal pov>
With this in mind I propose keeping perspectives, but stop treating some parts different that other parts.
Just my 2c, Elias.
On Mon, Sep 21, 2009 at 7:10 AM, Eric Moffatt <emoffatt@xxxxxxxxxx> wrote:
Patrick, we really haven't had a lot
of discussion on this, thanks for bringing it up...the following info is
just 'pie in the sky' ideas, not a proposal as to what we're planning on
doing. What would you like to see in place of Perspectives??
The most promising idea we've had seemed
to be based around trying to tie a 'part' to both its likely 'need' for
a particular work flow (a la Activities) and also to its 'function'
using a tagging mechanism to provide the UI with 'hints'. For example the
Project Explorer might be tagged 'Resource Management' as its work flow
and 'primary navigation' as its function.
With a suitable set of tags we were
hoping to get to a point where when you changed work flows (i.e. from 'development'
to 'debugging') the UI would automagically switch to showing the appropriate
set of views... The naive version had some 'permanent' stacks:
Primary Navigation: How you get to the
things you need to work on in a particular flow...Project/Package Explorer,
Debug View... (this is our usual 'left' stack)
Secondary Navigation: How to get around
*within* an object of interest in the current flow...Outline view (this
is our usual 'right' stack)
Support: views used to augment the work
flow that aren't navigation oriented...Search, Properties...(this is our
usual 'bottom' stack)
User Assistance: view used to help the
user use the tooling...Welcome, Help, Cheat Sheets...(this is our usual
'sticky right' stack)
In essence the current perspective gets
replaced with a 'work flow' and some code to filter views (and editors?)
into/out of the users attention at the appropriate time
The down side to this is that in order
to be really effective we'd need a defined set of 'work flow' & 'function'
tags that would be used by *everybody*...
Now that perspectives will be optional and the internal
structure of
the workbench is much more flexible, has there been work done on an
alternative to declarative perspective layouts? I know you can
structure things however you like in the workbench model, but what
about declarative contributions from other bundles?
My guess is that this would look something like the locationURI
mechanism for declaratively contributing menu items. So has this been
discussed already and if so where are we at?
Regards,
--- Patrick
Patrick Paulin
Eclipse RCP/OSGi Trainer and Consultant
Modular Mind, Ltd.
patrick at modumind dot com
www.modumind.com
twitter.com/pjpaulin
linkedin.com/in/pjpaulin
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
-- Elias Volanakis | Technical Lead | EclipseSource Portland elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
Patrick Paulin Eclipse RCP/OSGi Trainer and Consultant Modular Mind, Ltd.
608.213.4169
|
BEGIN:VCARD
VERSION:3.0
N:Paulin;Patrick;;;
FN:Patrick Paulin
ORG:Modular Mind;
TITLE:Eclipse RCP/OSGi Trainer and Consultant
EMAIL;type=INTERNET;type=WORK;type=pref:patrick@xxxxxxxxxxxx
EMAIL;type=INTERNET;type=HOME:pjpaulin@xxxxxxxxx
item1.EMAIL;type=INTERNET:pjpaulin@xxxxxxx
item1.X-ABLabel:_$!<Other>!$_
TEL;type=CELL:608 2134169
item2.TEL;type=pref:608-554-2160
item2.X-ABLabel:skypein
TEL;type=WORK;type=FAX:206-338-6092
item3.ADR;type=HOME;type=pref:;;2120 Chamberlain Avenue;Madison;WI;53726;USA
item3.X-ABADR:us
item4.URL;type=pref:www.modumind.com
item4.X-ABLabel:_$!<HomePage>!$_
item5.X-AIM;type=pref:pjpaulin
item5.X-ABLabel:skype
X-ABUID:BA10BB4F-4845-484C-9A1A-D7F854A29ABD\:ABPerson
END:VCARD
