Bugzilla – Full Text Bug Listing
| Summary: | [RCP] [Plan Item] Enable Eclipse to be used as a rich client platform | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim des Rivieres <jeem> | ||||
| Component: | UI | Assignee: | Nick Edgar <n.a.edgar> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | as, birsan, bogofilter+eclipse.org, bugs_eclipse_org, burner, cagatayk, cgoss, champion, clg-business, codex69, craig, danjou, daveo, david, destberg1, dj.houghton, dmeister, eclipse, ed.burnette, emorning, ian.leslie, jasc, jeatmon, jeffmcaffer, jinli, justink, jwillans, kehn, kevin, konradk, Konstantin.Scheglov, konstantinos_sakellis, marcus.dobrinkat, Matthew_Hatem, matthias.luebken, mdulisch, mike.dickson, n.a.edgar, pascal, patmc, rgurupackiam, Richard_Wilson, roman, stelu, swoolley, thatnitind, trashedout, victor, wayne | ||||
| Version: | 2.1 | Keywords: | plan | ||||
| Target Milestone: | 3.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 48416 | ||||||
| Attachments: |
|
||||||
|
Description
Jim des Rivieres
One of the things we would like to see is the ability to download a build that contains a "raw" workbench. Our application (using R2.1-M3) doesn't require Editors, Update, Help, Project or Resource views. Removing the plugins and their associated xml was resonably easy. The complexity is increased when one has to "hack" existing classes in order to remove the addition of actions and preference pages. We had to change the following classes: NewWizardMenu PerspectivesPreferencePage ViewsPreferencePage WorkbenchPreferencePage WorkbenchActionBuilder Our version of these classes are put in a seperate jar that is defined as a part of the Workbench Plugin and is loaded before workbench.jar. Despite the complexity, it took a junior level person with a year of experience just two days to get it working the way we wanted. I'd be happy to provide the source for our "hacks" should you be interested... Jim Jim, having the source for your changes would be good thanks. Could you please attach them to this PR, along with a point form summary of the changes that were made? Created attachment 4762 [details]
Attachment per your request...
I attached a zip with our version of the classes. Sorry, I'm unable to comment point by point as I didn't make the changes. Perhaps you could do a diff against the R2.1-M3 source to discover exactly what was done... I reviewed the other bug you referenced, and we are already on the interested list. We ignored much of what was done through that bug as it seemed to focus on the enablement/disablement of things, where our prefered approach is to completely remove all references to unnecessary plugins, preferences and menus. In addition we saw subclassing vs hacking as a non-issue. It's just as much trouble to subclass as it is to change the original class. Again, what we would like is a configurable workbench where, if I remove a plugin directory and any references to that plugin in other plugins, then all preferences, menus and views for that plugin would disapear from the workbench. One approach for implementing this would be for a development-type plugin to add it's preferences and menu items upon the opening of a perspective. This is what our code does and it seems to work fine. Another approach would be to define these things through xml. Jim Agree with the last comment, and not just for non-IDE applications. Eclipse would be improved if all plugins followed the same rules with respect to defining actions and menus. Reminder to check out the patch posted by Matthew Hatem in bug 29179 (I've closed that PR). An intial proposal of the work involved for this plan item has been released on the Eclipse UI team web site - this was one of our 3.0 M1 objectives. Please see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/rcp-proposal/rich_client_platform_facilities.html Looks good so far. One possible ambiguity I noticed was if the text editor support will be in the IDE plug-in or if it will be in a third plug-in separate from both the IDE plug-in and the rich client plug-in. Otherwise, I like it so far. We have not decided yet where the text editor will end up... If it's easy to do, a separate plug-in from both IDE and thin-client platform (TCP) would be preferred. Some TCP apps could definitely benefit from having a text editor plug-in already written and available to them. The text editor component is already implemented as separate plug-ins, although for backwards compatibility with R2.0, the extensions and extension points for it are currently defined in the org.eclipse.ui plugin. We are planning on cleaning this up. The text editor plug-ins will not be part of the "workbench proper" layer but will be an optional add-on. They may be required by the "workbench ide tooling" layer, although there are currently no direct dependencies on them in the current workbench code. A deeper question is whether the "workbench proper" should have any notion of editors at all. Independent of the text editors, the workbench currently has a notion of editor parts. Editors get pride-of-place in a perspective, and have several dedicated actions (File>Save, Save As..., Save All), dialogs (Save Resources, Switch to Editor), and other semantics (e.g. the editor switching mechanism, the recently used file list). We're debating whether it makes sense to include even this level of support in the workbench proper, or whether this should be layered on as well. Even if the support is built-in, the Save actions etc. will not appear unless the application adds them. David, I can understand not wanting text editors in the "workbench proper" layer. But why would you want to exclude them from the "workbench ide tooling" layer? >>David, I can understand not wanting text editors in the "workbench proper"
layer. But why would you want to exclude them from the "workbench ide tooling"
layer?<<
Because there are RCP apps that aren't IDE apps that could benefit from having
an integrated text editor.
A few examples:
Mail/news client
E-Book reader (for creating/editing annotations)
File manager / explorer
Ok, we're aligned then. The text editors should be a separate component which can be added on to the "workbench proper" if neeeded. The "workbench ide tooling" layer may require them, but applications do not need to include the entire tooling layer just to get editors. My understanding is you are splitting the current workbench into a generic workbench and that part of the workbench that depends on core.resources, which you tentatively call ui.resources. You also talk about a IDE workbench atop the generic workbench. So it seems there are two possibilities: (1) this IDE workbench depends on the generic workbench and ui.resources, or (2) this IDE workbench is what you are calling ui.resources. Why wouldn't Eclipse want to supply a startup class that could be used with the generic workbench? Some clients may be able to use it as is, and other clients could use it as a starting point before modifing it for their own needs. I'm not sure I understand drawing the line between the two pieces at resources. It'll be nice to get supported editing of arbitrary paths, but I could see many non-IDE type applications that want the concept of resources. These resources could be remote files, servers, database tables, video streams, rss news feeds, and other objects, real or virtual. The way I see it, there's a continuum of programs based on Eclipse technologies: Extended Eclipse --> Standard Eclipse --> RCP --> JFace app --> SWT app (e.g., WSAD) "RCP" is the target of the Rich Client Platform initiative. RCP programs are being built today but require various degrees of kludging to customize. For example as your doc says to take out certain menus. The break at resources seems arbitrary though. The question about where to put editors is typical of the kind of questions that will arise. Will every piece of functionality need to migrate out to its own little plugin? Another example is the confusion of whether to call the new plugin "ide" or "resource", and trouble with the terminology of the "ide workspace" vs. the workspace "proper". It seems like a correct refactoring would feel more natural and elegant. How about if you left the basic functionality in the ui piece pretty much as it is now but provided extensions to customize it, and remove all the default menus and perspectives. A very small optional plugin might be needed to activate features like the File action set and the Resource perspective. The focus should be on adding fine grained customizability that people really need. I have questions surrounding action contributions. Currently action contributions are presented in the UI via hard wired contribution managers. Namely the Workbench menu bar, toolbar and possibly View toolbars. Has there been any investigation into the possibility of allowing non-ide applications to have more control over this or making the Workbench action contribution model more generic? Being able to add additional or custom contribution managers would be nice. Additionally, the status bar in the Workbench has hard wired controls, e.g. the progress bar, cancel button, message area. Would a generic workbench/RCP benefit from having a bare bones status bar? How would non-ide applications add their functionality to this status bar or add it's own status bar implementation. -m@ I have been working on something like this on my own. I understand that much of this bug will be part of the Eclipse3.0 release. Here is what I am working towards: A plugin-driven tool integration system that will allow for data sharing between tools. What this amounts to is a "workbench" which is a small window and shows which tools can be launched, which tools are running and some stats. The perspective idea is not an option for me since I have people who will not use SWT and want to use Swing. I don't see this as a problem since every tool will be in its own window. What I have right now, and maybe people can help me with this, is a Integrator class that is the main feature and creates a SWT Shell and a Swing JFrame. What I am unable to do is use my mini-workbench to launch another Plugin. So if anyone can point me to the place where I would initialize a Plugin ( Platform maybe? ), that would be swell. I have posted all of my code in the eclipse.platfrom newsgroup for those interested. I would much rather do as people have suggested and use the provided workbench, but only if it comes "raw". --rowan I wanted to capture these postings from the platform-swt-dev mailing list, with one additional comment at the end: Ed Burnette wrote: > Would it make sense to bundle JFace more tighly with SWT and less > tightly with the Platform UI in both a physical and logical sense? Nick Edgar wrote: > We have no plans to bundle JFace with SWT or to support JFace as a > separate component from the Eclipse UI. Ed Burnette wrote: > I understand there are no plans to do that right now, but the > question is would it make sense, or would it be feasible, or > technically sound, to make such plans. If not, why. Some > (most?) of the code seems to be pretty generic, such as Jface > tables and content providers, and add significant value to SWT. Nick Edgar wrote: > Yes, a separate JFace is technically feasible and sound. The only > sticking point currently is its dependencies on the utility > classes in > org.eclipse.core.runtime. We've been careful since R1.0 to avoid > introducing dependencies from JFace to > org.eclipse.core.resources, or to > the rest of the UI (other than SWT, of course). > > However, we cannot currently commit to a separate JFace > component. We're > still debating whether to keep JFace as a separate component, > or to fold > it into the lower level of the Rich Client Platform (bugzilla 36967). > Since people have already built apps on top of SWT+JFace (and > excluding > the rest of the Eclipse runtime), we're tending towards > leaving it pretty > much as is, but cleaning up the dependencies, e.g. by moving > the utility > classes in org.eclipse.core.runtime into a separate jar. The > exact shape > of this has not yet been decided, but the design will be firmed up by > Milestone 2 (July 18). Even if we do make JFace a separable > plugin, e.g. > by moving the utility classes in org.eclipse.core.runtime > into a separate > jar, the emphasis of the Eclipse platform will still be as a tooling > platform, so there may be a limit to how much support we can > extend to > those using JFace separately from the rest of the platform. > Again, these > details will be sorted out by Milestone 2. > > If you have any further thoughts on this matter, please > append to bugzilla > 36967. Additional comment: +1 to keeping it as a separate component and cleaning up the dependencies. In addition to swt.jar, here is the list of jar files currently needed for a JFace app (from Eclipse in Action Appendix E): - <eclipse-root>\plugins\org.eclipse.jface_2.1.0\jface.jar - <eclipse-root>\plugins\org.eclipse.core.runtime_2.1.0\runtime.jar - <eclipse-root>\plugins\org.eclipse.ui.workbench_2.1.0\workbench.jar - <eclipse-root>\plugins\org.eclipse.core.boot_2.1.0\boot.jar If you can get it down to jface.jar and maybe one utility jar file that would be ideal. JFace apps should not currently require workbench.jar. There are no dependencies from org.eclipse.jface.* classes to org.eclipse.ui.* classes. You're right, the dependencies are currently (in 2.1): - <eclipse-root>\plugins\org.eclipse.jface_2.1.0\jface.jar - <eclipse-root>\plugins\org.eclipse.core.runtime_2.1.0\runtime.jar - <eclipse-root>\plugins\org.eclipse.core.boot_2.1.0\boot.jar In comment 18, Matthew asks: > I have questions surrounding action contributions. Currently action > contributions are presented in the UI via hard wired contribution managers. > Namely the Workbench menu bar, toolbar and possibly View toolbars. > Has there been any investigation into the possibility of allowing non-ide > applications to have more control over this or making the Workbench action > contribution model more generic? Being able to add additional or custom > contribution managers would be nice. The application will be able to configure which of the current bars are visible, on a per-window basis. Are you asking for the ability to add other bars? I notice that your RCP M7 has its own action bar. How does this differ from those in Eclipse? How are you currently adding it (i.e. subclassing WorkbenchWindow)? If I want to write a plug-in that targets both Lotus applications and other Eclipse-based applications, will I have to populate the action bars differently? I would like to understand what you're doing here, and see if we can make the current Eclipse action bars more flexible, to support your use cases, rather than replacing them (similar to the approach you took with tweaking perspective layout). > Additionally, the status bar in the Workbench has hard wired controls, > e.g. the progress bar, cancel button, message area. Would a generic > workbench/RCP benefit from having a bare bones status bar? How would > non-ide applications add their functionality to this status bar or add > it's own status bar implementation. We haven't considered this yet, but it sounds like you'd like us to <g>. Can you summarize your use cases? I notice that your RCP M7 has added API to IStatusLineManager to control alignment of the message, and exposed it on IWorkbenchWindow. Until now we've tried to restrict who gets to manipulate the action bars, by presenting "virtualized" action bars to views and editors. That way, if view A sets a message then view B gets activated, when you switch back to view A it still has the original message. If anybody can gain access to the "real" status line or menu bar, then the workbench loses the ability to manage contributions. Likewise, if anybody gets to control alignment of the message, it could lead to it jumping around unpredictably. If these are merely things that the primary application configures once, and regular plugins are not allowed to tweak, then that is important for us to know, and is something we can consider. I also have been working on this sort of thing for a while now and have my own "patched" version of the Eclipse source. One issue I would like to bring forward is about update.ui.forms a.k.a. Manifest Editors. I use these a lot for viewing and editing the properties objects. The first point I have is why is this in the update.ui package? Shouldn't it be moved into a eclipse.ui.forms package? Also, I needed to patch this stuff a bit to make it work out side of a fully initialised WorkBench (wrote my own AbstractForm class and moved the eclipse code onto that). So maybe that work should be done as part of this Bug? Just to quickly elobarate on previous comments:
The modifications I have made made it possible to launch a Workbench/Workbench
window without the BootLoader/Platform being initialised. I programatically
open a perspective.
Therefore, are you going to, in your design, be able to just create a
Workbench/Workbech Window with perspectives, etc without the need for the
plugin engine? A lot of the code looks for the
WorkbenchPlugin/ResourcesPlugin/etc.
I.e. The code I imagine to launch a workspace with a defined perspective would
look like this (simplistic):
Workbench bench = new Workbench(...);
WorkbenchWindow window = new WorkbenchWindow(...);
Perspective perspective = MyPerspectiveFactory().create();
bench.addPerspective(perspective);
bench.activePerspective(perspective);
window.setBlockOnOpen(true);
window.open();
--
(Less Important) I also have modified the Workbench so that instead of the
close ('X') button in the corner of a ViewPart so that instead of closing it
would Toggle back to fast view (also added a pin icon to Pin the viewpart and
make it always open). This functionality is similar to Outlook 98/2000. So
basically I needed the Close button able to be toggled so that I can add my
own close button to add this functionality. Can this be added as well? I can
get involved and help doing some of the coding, just advise me if you would
like me to do so.
For comment 25 - The rich client platform will contain the "plugin engine", that is it will require org.eclipse.core.runtime. It will *not* be dependent on the workspace or resources (that is, org.eclipse.core.resources). There will be API to create a new workbench with an adviser that will be allowed to customize the workbench and windows. There will be support for perspectives, views, and editors - but no implementation of these will be in the rich client platform. So if you want for example the text editor, you'll need to include that plugin. We feel that the key points of the eclipse rich client platform is the plugin engine that allows it to be an integration platform. We will be posting an updated document on what we are proposing to do for this RCP - check the ui team's web page and mailing list for the announcement. As for the close button on a view... we still need to investigate that area. We are aware that some application want a different look and behavior for views/editors. This is part of the workbench branding story (bug 37693). For comment 24 - you may want to post a message to the pde or update development mailing list for an answer to your question(s). I'm not familiar enough with that area of Eclipse. Will it be possible to share the 'base plugins' like RCP with other products? IIRC up to now extention like perpectives will show up in the menus. This can surely not be desired if one will, for example, build a mailclient and the whole eclipse SDK framework is also installed. It would be really nice if that could be achieved without symlinks (*ix) and that like. What I'd like to see is this: - You have the RCP and you have "RCP applications" where an RCP application is just a logical collection of Features. - RCP and RCP applications are separate things, and there should be no need to customize the RCP itself to support some particular RCP application. By analogy, the RCP is to Eclipse plug-ins as a web browser is to HTML pages. - Eclipse just happens to be the first RCP application. - The update manager should be included in the RCP but be easy to remove for those who want to customize the RCP for their own purposes. Then my installer could just test to see if the RCP is on someone's machine already. If so, it just adds my plug-ins as a feature in their existing RCP. Then I get the functionality installed by all their other plug-ins for free. Then customers get exactly the integration platform they want. If they only want/need a PHP IDE, for example, they could have just that and not need the JDT, PDE, etc. This also helps improve the scalability story. I agree with your first comments, but IMO update should not be part of RCP: On unix update can't be used when the base is installed via the package tools (rpm, I can only talk about dpkg). The same goes probably for all tools who will check if RPC is already installed (OOo for example installs almost all used libs, even if they are available on the system.). I wouldn't mind if update is split into a seperate feature, though... Testing if RCP is installed will also only be done if RCP will register themself in the registry (windows) or be integrated in the right FHS dir (*ix). Getting functionality for free is exactly what I don't want: I don't think any tool builder or user wants to have a complete IDE waiting in the background (even not using memory at all) when the app which was started was a graphics tool or mailclient. And that will happen if this tool used for example the same RCP as the IDE which was installed by another user in that maschine. Your analogy with html page and browser isn't good IMO: It's more like a library which is used by other clients. The problem is, that ATM the lib is started and then needs to choose the right parts of the available 'clients' to show them to the user. BTW: You can already now use a 'only PHP-IDE'. Just install eclipse-platform and the PHP Features. >>I agree with your first comments, but IMO update should not be part of RCP: On unix update can't be used when the base is installed via the package tools (rpm, I can only talk about dpkg). The same goes probably for all tools who will check if RPC is already installed (OOo for example installs almost all used libs, even if they are available on the system.).<< I guess I don't care that much if update is or is not included by default so long as it's either easy to remove or easy to add if desired. >>Getting functionality for free is exactly what I don't want: I don't think any tool builder or user wants to have a complete IDE waiting in the background (even not using memory at all) when the app which was started was a graphics tool or mailclient.<< Wait a minute--what IS an *application* in the context of Eclipse or the RCP? Eclipse is a tool integration platform. There really is no such thing as an application in this context. The closest analogue to an application in Eclipse is a perspective (or maybe a group of perspectives) that let you do something. So far, we've been talking about RCP as just the Eclipse platform minus the resources framework and a few menu choices that are IDE-specific, so all of the above still applies to the RCP as well. In my understanding, not much else of significance about Eclipse has changed (at least as far as the discussion has gone so far) in order to factor the RCP out of Eclipse proper. There is no need (and I believe quite a few sysadmins would not want) to have multiple copies of the RCP running around on the same machine in order to provide an RCP-based Java IDE and an RCP-based mail client. Therefore, I think that the question you legitimately raise isn't about what code is shared by what applications, but rather how can we improve the UI scalability story so that when someone launches the RCP with a mail client as the main Feature being displayed, they don't see menus/buttons contributed by the Java IDE unless they switch to a Java IDE perspective (oversimplifying the UI scalability problem somewhat for the purposes of discussion). In summary: * RCP == tool integration platform because we haven't removed those features from Eclipse that provide this. * Eclipse Features ~= applications * We need a better UI scalability story so that the user sees only menus / tool bar buttons that are relevent to the current perspective or something. I would agree that in some environments (Debian, Red Hat, etc.) that update manager probably should be omitted, therefore it must be optional. I still think I would prefer it to be included by default but be easy to remove rather than the reverse but I won't lose any sleep if it's not included but easy to add. :-) >>And that will happen if this tool used for example the same RCP as the IDE which was installed by another user in that maschine.<< I'm confused about this question. Generally you have users and you have the sysadmin on a machine. If the sysadmin installs something for everybody, everybody sees it. This is true regardless of if the "something" is an Eclipse plug-in in a shared RCP or if the "something" is a new XScreensaver module. In a multiuser environment, if I were the sysadmin, I would want to install the RCP once and let users customize the default Eclipse Feature that would be displayed. But I wouldn't want multiple copies of the RCP running around on the machine just so that joe can have his RCP start up with the JDT by default and jane can have hers start up with a mail client by default. (If somebody just wants to build Eclipse-lookalike applications using Eclipse source code, they are still free to hack the plug-in manager out of the RCP and build true standalone applications in the classic sense of that term.) >>Your analogy with html page and browser isn't good IMO: It's more like a library which is used by other clients. The problem is, that ATM the lib is started and then needs to choose the right parts of the available 'clients' to show them to the user.<< As I explained above, I think the RCP is more like an empty application that lets tool plug-ins integrate with each other as a seamless whole. This is much more than the services normally provided by a library. The problem we have right now is that there is an assumption in the scalability story that all tools want to integrate into the same set of tasks (ie: currently Java programming) even when some tools may have nothing to do with that set of tasks (ie: email client). RCP needs to somehow eliminate that assumption. This is already being addressed in the 3.0 plan through the "improved UI scalability story" task item. I have some thoughts/ideas about that but I'll post them in a separate comment. >>BTW: You can already now use a 'only PHP-IDE'. Just install eclipse-platform and the PHP Features.<< True. That was a bad example. A better example would be the email client; installing an email client on top of the current eclipse-platform gives you a UI with some IDE artifacts remaining. The UI scalability story can be found in bug 36967. Suggestions relevent to UI scalability an RCP can also be found in bug 36968 (Improve action contributions). Oops, UI scalability is really found in bug 37929. Can one use mailclients to answer this mails? > Wait a minute--what IS an *application* in the context of Eclipse or the RCP? > Eclipse is a tool integration platform. There really is no such thing as an > application in this context. The closest analogue to an application in > Eclipse is a perspective (or maybe a group of perspectives) that let you do > something. I agree with that, but still I don't want that another application can show of in the UI of my application. Today I can specify the 'applicyation' which should be started (See 'Running Eclipse' in the Help), which means that a whole bunch of contribution cannot be activated if 'workbench' isn't choosen as default app. I want the same functionality with RCP. > So far, we've been talking about RCP as just the Eclipse platform minus the > resources framework and a few menu choices that are IDE-specific, so all of > the above still applies to the RCP as well. AFAIK the RCP should fill the gap between 'Apps based on plugins but *without* UI'(core and -application switch) and 'Apps with IDE features' (complete eclipse-platform). So I think that the RCP will include * Plugin Framework * SWT and JFace * UI Framework without any contributions > There is no need (and I believe quite a few sysadmins would not want) to have > multiple copies of the RCP running around on the same machine in order to > provide an RCP-based Java IDE and an RCP-based mail client. No, this should not happen. But both of the apps should be as seperate as a mailclient should be from a differnt app. I can't see that any tool builder wants to have his programm started (with showing splash screen, welcome page and specific 'About' menu) and then the users starts using the rival product, becasue it is available, too, under this RCP start. > I would agree that in some environments (Debian, Red Hat, etc.) that update > manager probably should be omitted, therefore it must be optional. I don't mid if it is included or not as long as it is a seperate feature, which can package as a seperat package. And as long as the update manager can be used with 'package manager managed RCP/eclipse plugins' (should NOT be updated, see Bug:#36101) and 'user only plugins' (should show up and should be updateable, see Bug:#39890) >If the sysadmin installs something for everybody, everybody sees it. NO: I can prevent a user from starting some tools. I also think that it isn't a good idea that I can use fdisk by starting my wordprozessor or having mplayer waiting in the UI of my IDE. IMO you can't compare RCP to a desktop system like KDE or a linux distribution. What I miss is to specify a 'scope', which of the available 'Perspective Contribution' are 'activateable' by the user. Normaly a program is started from a desktop system and is then the "root" of all avavilable 'things' which can happen in this program. In the RCP case my started app will not be the root but a small 'contribution' to RCP. It will not matter if I start /usr/bin/mailclient or /usr/bin/eclipse or /usr/bin/fdisk, I will always have the same choices. As long as Eclipse RCP isn't trying to replace my desktop manager this isn't acceptable to me. The last client who tried that was StarOffice. This 'feature' (called StarDesktop) was removed before it became OpenSource... > As I explained above, I think the RCP is more like an empty application that > lets tool plug-ins integrate with each other as a seamless whole. This is > much more than the services normally provided by a library. KDE brings UI libs which have similar functions like eclipse (at least from first look at them). Nevertheless you can't have kpilot starting *in* your kopete window or even starting it from kpilots UI. If I want my tools integrated in application of someone else, then I will use the extentiuon point of this app. Jan The update plugin will not be a required plugin for the RCP. Applications who want this service can include the update plugin and call the appropriate API method. More details is coming soon about our plan for RCP. This bug report will be annotated when the document becomes available. >> Wait a minute--what IS an *application* in the context of Eclipse or the RCP? >> Eclipse is a tool integration platform. There really is no such thing as an >> application in this context. The closest analogue to an application in >> Eclipse is a perspective (or maybe a group of perspectives) that let you do >> something. > >I agree with that, but still I don't want that another application can show of >in the UI of my application. I didn't disagree with this. I just think that this is a separate problem--a UI scalability one. > Today I can specify the 'application' which should > be started (See 'Running Eclipse' in the Help), which means that a whole bunch >of contribution cannot be activated if 'workbench' isn't choosen as default app. >I want the same functionality with RCP. I don't disagree with this either. ><snip/> >> There is no need (and I believe quite a few sysadmins would not want) to have >> multiple copies of the RCP running around on the same machine in order to >> provide an RCP-based Java IDE and an RCP-based mail client. > >No, this should not happen. But both of the apps should be as seperate as a >mailclient should be from a differnt app. I think that this is a matter of taste and application requirements. As you said below, sysadmin tools like fdisk certainly don't belong inside Eclipse. But I could see companies basing their application infrastructure on the RCP. In this case, they very well could *want* to have the whole thing start at once, end at once, and have all of their internal "applications" available at once. >I can't see that any tool builder wants to have his programm started (with >showing splash screen, welcome page and specific 'About' menu) and then the >users starts using the rival product, becasue it is available, too, under this >RCP start. Probably correct, although I think another way to view the RCP is as an enhancement that Java-enables the underlying platform windowing/applications environment. That doesn't mean that you won't be able to use it as a standalone application framework. I'm just saying that I see additional use-cases to the ones you're describing. >>If the sysadmin installs something for everybody, everybody sees it. > >NO: I can prevent a user from starting some tools. Sure, and if plug-ins are properly architected, you can do the same with plug-ins using proper file and directory permissions. >I also think that it isn't a good idea that I can use fdisk by starting my >wordprozessor or having mplayer waiting in the UI of my IDE. IMO you can't >compare RCP to a desktop system like KDE or a linux distribution. I agree that there are certainly combinations of applications that don't make sense living together inside the RCP. But I think that there are combinations of "applications" that *do* make sense living together inside the RCP. * Billing * Order entry/fulfillment * Accounts receivable etc... >What I miss is to specify a 'scope', which of the available 'Perspective >Contribution' are 'activateable' by the user. Normaly a program is started from >a desktop system and is then the "root" of all avavilable 'things' which can >happen in this program. In the RCP case my started app will not be the root but >a small 'contribution' to RCP. >It will not matter if I start /usr/bin/mailclient >or /usr/bin/eclipse or /usr/bin/fdisk, I will always have the same choices. Not sure I totally understand you here. If you're talking about limiting the scope of action visibility like we've been discussing in bug 36968, I totally agree. > As long as Eclipse RCP isn't trying to replace my desktop manager this isn't > acceptable to me. The last client who tried that was StarOffice. This 'feature' > (called StarDesktop) was removed before it became OpenSource... I remember StarDesktop and didn't like it either. But I think that there's a middle ground here of data-oriented applications that can be useful to integrate and/or group within a UI like the RCP, especially within the context of an enterprise's data center. So while I agree with you that many things make no sense to integrate, I also think that the concept of a "tool integration platform" can usefully span things that used to be thought of as separate applications. I also agree that trying to replace the entire desktop is going way too far. I feel no need to replace Konqueror or Windows Explorer as my file manager, for example. But I think that IDEs are not the only work environments that can benefit from being integrated using a tool integration platform. >>I agree with that, but still I don't want that another application can show of >>in the UI of my application. >I didn't disagree with this. I just think that this is a separate problem >--a UI scalability one. I think it is more. Curently the -application <app> is the 'root of all things'. With the new RCP this will not anymore true, as I have RCP (started by "-aplication RCP-ID") and building on top of that the RCP-Apps. So if one 'Application' (in the old sense) is a perspective, all other contributed perspectives are still visible somwhere, as they are contributed to RCP. IMO the 'UI scalability' is trying to solve a much higher level problem (that there are too much actions/...) in a given app. >Probably correct, although I think another way to view the RCP is as an >enhancement that Java-enables the underlying platform windowing/applications >environment. That doesn't mean that you won't be able to use it as a >standalone application framework. I'm just saying that I see additional >use-cases to the ones you're describing. If the RCP is installed in a common place and no mechanism is introduced to reduce the 'contribution tree', it wont be possible to craft a completely standalone (in the way the users sees it) application. >I agree that there are certainly combinations of applications that don't make >sense living together inside the RCP. But I think that there are combinations >of "applications" that *do* make sense living together inside the RCP. Yes, this makes sense. So contribute them to a base application, which fits the overall goal of this 'parts'. You still wouldn't want to have a mplayer in this 'managment'-application. >>It will not matter if I start /usr/bin/mailclient >>or /usr/bin/eclipse or /usr/bin/fdisk, I will always have the same choices. >Not sure I totally understand you here. If you're talking about limiting the >scope of action visibility like we've been discussing in bug 36968, I totally >agree. No, I think that my scope is 'bigger' than bug 36968: this bug just talks about 'not showing actions to the user in some situations'. I'm talking about excluding (!=not showing) parts of *any* contribution based on the started RCP-App. >I also agree that trying to replace the entire desktop is going way too far. >I feel no need to replace Konqueror or Windows Explorer as my file manager, >for example. But I think that IDEs are not the only work environments that >can benefit from being integrated using a tool integration platform. I feel the same. But it should be done by someone who knows why it is done with a specified releationship and not by the fact that someone has put some files in the right dir. Since there is no "official" list or group dedicated to this I'd like to offer the mailing list at http://lists.sourceforge.net/lists/listinfo/eclipsepowered- discussion for general discussions about the Rich Client Platform. (This is part of the www.eclipsepowered.org site which is "dedicated to the development of Eclipse Powered applications, rich clients built on top of Eclipse". Both are hosted on SourceForge.) >I think it is more. Curently the -application <app> is the 'root of all
>things'.
>With the new RCP this will not anymore true, as I have RCP (started by
>"-aplication RCP-ID") and building on top of that the RCP-Apps. So if one
>'Application' (in the old sense) is a perspective, all other contributed
>perspectives are still visible somwhere, as they are contributed to RCP.
This is not actually true. The application tells the runtime "what code to
execute". In the context of Eclipse that is only part of the story. The
PlatformConfiguration defines "what plugins the runtime sees" and thus, "what
code *can* be run" as well as the default perspective. Obviously the
application must be in a configured plugin. Currently the UI is the standard
application. It comes up, opens the default perspective, notices contributions
by various configured features/plugins and makes them available to the user
(menu entries, ...). The code that is actually running is just the UI event
read/dispatch loop.
Changing the application is really only interesting for people doing non-UI
things or supplying their own UI.
With respect to shared installs, the story has always been that there could be
thousands of plugins installed and available to be used by any given Eclipse
but each Eclipse instance can choose (or be told) which of the available
plugins to consider running.
[Ok, sending by mail didn't work. Is that activated?] >>I think it is more. Curently the -application <app> is the 'root of all >>things'. >PlatformConfiguration defines "what plugins the runtime sees" and thus, "what >code *can* be run" as well as the default perspective. Obviously the Yes, I know this class... The problem with it is, that this class depends on .metadata/.config/platform.cfg*, which makes it not really usefull to 'disable' parts, when I start /usr/bin/RCP_based0, when this is not wanted when I start /usr/bin/RCP_based1 >application must be in a configured plugin. Currently the UI is the standard >application. It comes up, opens the default perspective, notices contributions >by various configured features/plugins and makes them available to the user >(menu entries, ...). Yes and her I have some problems: UI makes *everything* available, what is contributed to its extention points. I can't say that I only want contributions which are "based on"/"contributed to"/"depend on" some other plugin/aspect (like debug perspective contributed to the 'IDE' parts). >Changing the application is really only interesting for people doing non-UI >things or supplying their own UI. Yes, but with RCP you will get a higher level application: one with UI, but which has nothing to do with any of the stuff, which is currently contributed to the extention points of UI (like the whole java IDE) To describe it as a picture: Curently you have a tree with extention points and extentions: when I activate one plugin, extentions defined by this plugin are activated. And this plugins activates it defined extention-points with all the extention. And so on... You can select a part of the tree at the very beginning by giving the -application option. With RCP you will always select the UI part. But then I have the complete UI 'available' and can't select parts of this subtree. eclipse application E.-P. / | \ / | \ ant-runner workspace-repairer | / | \ UI ---------------- { ... } Perspective E.-P. \ / ... \ \ Perspective_1 Pespective_n Other E.-P. of UI /...\ /|\ /|\ many other extentions (and {a...p} {q...z} other extention points with Extentions to this E.-P. extentions) which are enabled due to activating this perspective How can I only enable the group 'perspective_1 *together* with the "other extentions" a, b and x', which are together 'A Mailclient' and at some other time activate 'perspective_3 to perspective_n together with "other extentions" p and q to v', which are together "A IDE". (Where activate means that I don't see anything else than this parts, not even in "Window|Open Perspective". Simple 'not there'.) So I don't mean that one can select a complete subtree, but parts of different subtress. Jan We've just posted a significant revision of the proposal for this plan item (this was one of our 3.0 M2 objectives - only a couple of days late). Please see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/rcp- proposal/rich_client_platform_facilities.html From here on in, we'll be evolving this proposal on a continuous basis as we work through the proposed solution in a CVS branch. Comments are critiques are most welcome; please add to bug 36967 I think most of the above discussion is adressing the TBD in "What aspects of
the workbench must the application configure?".
Anyway: Will the above usecase ("hiding parts of the contribution, if they don't
fit into the current 'theme' (IDE, maiclient, wordprocesor)") be adressed or is
it planed to use the RCP as 'one App, one RCP plugin set', if the tool builder
don't want some contribution show up (bad in case of a system wide instlation of
RCP).
Or is that already adressed in the last two points (menu items/toolbar items
with associated actions) and how will it be possible to split contributions into
themes? Means that somehow the advisor needs to know whether the contribution
should enchance the current 'theme' or if this item goes into a completly
different direction.
So, apart from that: please split help and updatemanager into seperate features
(so that I can install them like a new feature), much like it should be done
with editors. My reasoning is, that this parts can be used independently and
will enchance the RCP, much like the 'generic editor' framework does.
eclipse-platform is currently a debian package of 25MB and it would really be
nice of that could be split in much smaller portions (RCP, Editors, Help,
Updatemanger, IDE) with as less as possible dependents on each other...
Jan
About the IWorkbenchPage.openInEditor API's: I think something along the lines of what I proposed in bug 5687 may help in making a smooth transition. The basic idea is to have a IWorkbenchPage.openEditor(IAdaptable, ...) API. There would be an IEditorInputProvider interface: public interface IEditorInputProvider { IEditorInput createEditorInput(Object obj); } The workbench can lookup the input provider for a given IAdaptable and open an editor based on this. Otherwise, this approach has the advantage of easy porting and providing a generic way of associating model elements with their editor inputs. Coupled with a way for the input providers to define default editor id's, you would not have to use plugin-specific API's to open editors (as in JavaUI.openInEditor(IJavaElement)) and write generic code to invoke editors on any kind of workbench selection that adapts to IEditorInputProvider. I forgot to mention in my previous post: org.eclipse.ui.ide can add adapters for IFile and IMarker and implement resource specific editor API's in terms of the generic one provided from org.eclipse.ui. Comments on the generic workspace structure proposal: 1. Question on two dependencies: in the 3.0 proposed dependencies chart, o.e.jface depends on o.e.core.runtime, and o.e.ui.editors depends on o.e.core.resources. Both of these seem a little suspicious so I was wondering if you could comment on why they're there. 2. Input on o.e.text: You ask for input on declaring o.e.text's api in the o.e.text plugin instead of the o.e.jface.text plugin. This makes sense to me. Editors are already going to be impacted by other changes (mainly extension points moving out of o.e.ui) so might as well get it out of the way. In general I think you're going to have to eliminate the package extensions, as you point out based on the OSGI plans. 3. Input on renaming o.e.ui.workbench.texteditor to just o.e.ui.texteditor - I think that's a tremendously long and inconsistent name and it doesn't break anything to change it so that sounds reasonable to me. 4. Input on renaming o.e.ui.editors to o.e.ui.ide.editors - I don't think that one is a good idea, but for a different reason than you specify. My reason is that editors don't seem like a particularly "IDE" concept to me; for example if you're using RCP to write an OLAP client you might very well want to have an XML editor in there, and even a Java editor for stored procedures called by calculated members. The plugin org.eclipse.ui.editors contains the IDE specific code for text editor support to deal with resources. Really, the plugin should be call org.eclipse.ui.ide.texteditor to make it clear this is code for text editors to deal with resources. That is why o.e.ui.editors dependents on o.e.core.resources. I'm not clear on what you mean by "code for text editors to deal with resources". Does mean that some editors are special "IDE editors" that are resource-aware and some editors are generic editors that are not resource-aware? This goes against my impression that all editors in the new design would support editing anything whether it was an arbitrary file out somewhere in the file system, a file under control of an IDE project, a remote file that came from an odd place like a database BLOB or CVS, or a stream that was generated out of thin air by some Java code. See also bug 37935 and bug 2869 . Please clarify. Along the lines of Ed's comments, I have a concern that an IResource which I currently understand to refer to something within the workspace could be more generally defined to refer to anything accessible through a stream. Ed's example of an OLAP application is an excellent use-case supporting this interpretation. The continued lack of a "File/Open" menu choice as expected by many users and discussed to death on the newsgroup is another one. I don't know if 3.0 is the right time to fix this, but I suspect that the longer we wait to fix this, the more costly it will be to do. On the other hand, fixing this seems to fit well with the whole notion of modularizing the Eclipse plug-ins so that they can be incorporated into RCP applications, which appears to be a recurring theme in the RCP plan document. Let's discuss support for RCP Applications that need leverage "desktop features" such as the SWT.ON_TOP style for the main application shell. Below is sample code that modifies the existing workbench code to allow this style to be applied via a preference. Applications will also need to apply this style dynamically or at runtime. Currently there is no API to do this. We see this feature to be an important part of what we call the "desktop integration" strategy for the RCP. Other features include systemtray access, minimizing to the systemtray, non- rectangular shells and support for OS skins. We have made a lot of progress on the systemtray front, with a prototype for Gnome 2.2 and KDE 3.x in the works. Without these kinds features, applications based on Eclipse RCP/SWT cannot compete with native applications. WorkbenchWindow.java import org.eclipse.ui.IWorkbenchPreferenceConstants; ......at the end of the WorkbenchWindow constructor...... // Determine always on top behavior IPreferenceStore store = WorkbenchPlugin.getDefault().getPreferenceStore(); boolean alwaysOnTop = store.getBoolean (IWorkbenchPreferenceConstants.WINDOW_ALWAYS_ON_TOP); if (alwaysOnTop) setShellStyle(getShellStyle() | SWT.ON_TOP); IWorkbenchPreferenceConstants.java /** * A preference value indicating that the workbench window should * remain on top of the z-axis. */ public static final String WINDOW_ALWAYS_ON_TOP = "WINDOW_ALWAYS_ON_TOP"; // $NON-NLS-1$ -m@ Recent versions of the porting guide say: "The 'adaptable' attribute means roughly adaptable to an IResource. Although resources are not part of the generic workbench, the attribute was left in place. Non-IDE applications should not specify it. If specified, it is simply ignored when the resources plug-in is not present." How about if you change it to mean that the object is adaptable to whatever is listed in the objectClass attribute. If false, then the object must be a subclass of or implement the class or interface listed in objectClass. Thus specifying adaptable=true and objectClass=IResource would be the same thing as just specifying adaptable=true in 2.1. This would remove any special cases for resources here. Yes, we did (and are still) considering that option. But for now, given the little time we have, we just wanted to do what is needed to provide the same support as before. I am very interested in using Eclipse as a rich client platform, for which I have some comments: What I think is Critical: 1) Some users of eclipse based apps will not be developers. Need to be able to remove all potentianally confusing functionallity (as already planned I think). Also VERY IMPORTANTLY WE NEED HELP BUTTONS/ICONS for all eclipse components (F1 is not good enough). While help buttons/icons will only help usability of eclipse in general (a lot in fact), it is absolutely required for friendly client apps targeted towards non-developers. If eclipse GUI components does not have HELP BUTTONS/ICON they may be unusable and eclipse will be a less interesting platform.... BTW: Just look at just about every windows product for inspiration about how to provide such help features. What I think is important: 2) The platform would benefit from a "standard" but extensible scheme for doing simple platform-specific stuff like monitoring for changes in the file system (already planned for eclipse 3.0 I think) and system tray integration etc. Maybe a special project needs to be created for this, so that client applications that need the same kind of stuff can share libraries. As a minimum, I would like to be able to use the same kind of platform-specific stuff as eclipse 3.0. 3) Need to be able to assemble and use all/any eclipse platform components at will. Need not only obvious stuff like editors and update-mangers but also components like WebDav, CVS, Compare. In addition it would be nice also to be able to build on projects like EMF or XSD. 4) Some applications may need to integrate with Swing components that are not available as SWT. 5) Plans and published guidelines for "early adapters": What can developers do know if they want to base a future app on the eclipse client platform ? When will the first direct support in eclipse arrive (M4?) What I think is less important at this stage: 6) The size of the eclipse 3.0 rich client platform distributable. 7) API changes. I noticed some updates were published to the generic workbench overview document (<http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/rcp-proposal/generic_workbench_overview.html>) and other related RCP documents. If it's not too much trouble, would it be possible for a quick note to be posted here when those change? One of the things that was added a few days ago was instructions on how to run RCP by mixing M2, M3, branched, and HEAD stuff. I followed the instructions and I'm running Eclipse as a test application. When I go through the Perferences dialog I got a few errors; are these expected at this point? Thx. 1. When I click on Workbench > Compare/Patch I get an error: "The currently displayed page contains invalid values." 2. In Workbench > File Associations, *.txt is associated with "%% Editors.DefaultTextEditor (default)" [sic] 3. Workbench > XML Compare reports "Unable to create the selected preference page. Plugin org.eclipse.compare.examples.xml was unable to load class org.eclispe.compare.examples.xml.XMLComparePreferencePage". 4. Selecting Install/Update gives: "Unable to create the selected preference page. Plug-in org.eclipse.update.ui was unable to load class org.eclispe.update.internal.ui.preferences.MainPreferencePage." 5. Team > CVS gives: "Unable to create the selected preference page. Plug- in "org.eclispe.team.cvs.ui" was unable to instantiate class "org.eclipse.team.internal.ccvs.ui.CVSPreferencesPage". 6. Submenus of CVS gave a similar error. 7. When exiting the workbench I always get two "are you sure" dialogs. These documents are changing a few times a day so posting a note to this bug report would generate too much traffic. But when things settle down a bit more, it may make more sense then. None of the other plugins build on top of the workbench have been ported yet, so you will get errors when accessing their preference pages, actions, etc. Not all *.properties is up-to-date with the move so there will be some missing entries. The double dialog prompt on exit is a known problem which we will look into soon. According to the 3.0 milestone plan, 3.0M4 will have a frozen API which implies that the RCP branch will be merged into HEAD. For planning purposes, is this still on track to be done by October 3? I was thinking about future compability between general plugins written for the normal eclipse IDE 3.0 (for software developers) and new applications based on the eclipse "Rich Client Platform". I imagine that some (but definitely not all) general plugins for the "normal" eclipse IDE may also be useful for some applications based on the "Rich Client Platform". For example a "XML editor" plugin may be useful for both the "normal" eclipse IDE AND for a number of rich clients based on the eclipse platform. Not easy, but maybe something can be done to promote 3rd party compatiblity when appropiate ? To be most useful for RCP, the plugins would have to avoid any references to IDE objects like resources. Otherwise the IDE plugins will get pulled in unintentionally. Perhaps the PDE could provide some extra support for verifying and enforcing that. Re: comment #54 The RCP changes will not be merged into HEAD until shortly after M4, and will therefore miss the initial API freeze planned for M4. When I was writing part 2 of the RCP tutorial (draft is at www.eclipsepowered.org), I noticed that in 3.0M6, these functions are in the WorkbenchAdvisor class but are not actually called by anyone: postRestore preShutdown This one is documented to be called after the window is closed but it is actually called before the close event is fired: postWindowClose Also, I haven't played with fillActionBars too much but it looks pretty complex because of its flags parameter. Perhaps it should be broken up into more than one method or something. The flags have 16 possible combinations but only two are used: all action bars, and proxy + menu + toolbar. (and shouldn't toolbar be coolbar?) See bug 51282 for changes to postRestore and preShutdown done. |