Closed Bug 338981 Opened 20 years ago Closed 19 years ago

SoC Tracking - XUL editor plugin for Eclipse

Categories

(Other Applications :: CCK, defect, P4)

Product:
Other Applications
Component:
CCK
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: chofmann, Assigned: benjamin)

References

(
URL
)

Details

XUL editor plugin for Eclipse Lian Liming Benjamin Smedberg Not really the right component but didn't see anything that was any closer..
My basic principle is to extends current existed project than start from scratch, at the time I was writing my proposal, I only found one: Orangevolt EclipseXUL(http://sourceforge.net/projects/eclipsexul/). But some days later, I find another one at mozdev: Solid(http://solid.mozdev.org/index.html). I am now comparing those two projects and trying to find which one is more worthy to contribute to. I am also willing to hear others' idea on those two.
Regarding the editor, you might also want to be aware of the SSE (Structured Something Editor... not sure what the Something is :) It's part of the Eclipse WebTools project (http://www.eclipse.org/webtools/) and basically lets you partition an editor such that control is given off to different components. This way, you can have JavaScript embedded inside HTML, for example, and the appropriate visuals and commands are available in each context. I figure XUL, being mixed content, might find this concept useful, and a modular approach may mean less duplication of effort with other projects. In theory, it's the "Eclipse way" of doing mixed content in editors. That said, the WebTools support for JavaScript today is minimal, not many other grammars are supported, and the SSE itself is pretty hard to understand and I don't know how well baked it is for external consumption, so you may not end up using it. Just an FYI. I figure interacting with mixed XUL/HTML/JS is going to be fairly common in XUL development and perhaps a requirement for a XUL editor, but I really haven't done much XUL lately.
Adam, I think SSE is well beyond the initial scope... integrating Eclipse and the XUL context-sensitive editor that you showed me in CA sounds like enough work as it is. Where was the code for the XUL context-sensitive editor located in Eclipse CVS?
The following set of plugins can be used to create a XUL editor: (from cvs location dev.eclipse.org/cvsroot/technology) org.eclipse.laszlo/source/org.eclipse.laszlo.rct.builder org.eclipse.laszlo/source/org.eclipse.laszlo.rct.editor org.eclipse.laszlo/source/org.eclipse.laszlo.rct.model org.eclipse.laszlo/source/org.eclipse.laszlo.rct.script org.eclipse.laszlo/source/org.eclipse.laszlo.rct.script.ui org.eclipse.laszlo/source/org.eclipse.laszlo.rct.ui org.eclipse.laszlo/source/org.eclipse.laszlo.rct.util org.eclipse.laszlo/extentions/org.eclipse.laszlo.xul.core org.eclipse.laszlo/extentions/org.eclipse.laszlo.xul.ui Debug support can be had by getting the following from the eclipse atf project (from cvs location dev.eclipse.org/cvsroot/webtools) org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.swt.browser org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.ide.core org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.ide.debug org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.ide.debug.ui org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.ide.ui These set of plugins depend on the eclipse webtools (and all it's prereqs)
Re commment 1: I believe the two projects were planned to be merged at one point, and they're both pretty basic (though I think eclipseXUL had a bit more work put into it).
I agree with you, Nickolay. EclipseXUL provides only basic features such as wizard, outline view. It is far from a mature xul editor plugin for eclipse. (In reply to comment #5) > Re commment 1: I believe the two projects were planned to be merged at one > point, and they're both pretty basic (though I think eclipseXUL had a bit more > work put into it). >
So far as I know, there are mainly two kinds of XUL applications. One is standalone xul application based on XULRunner, and the other is the extensions to Mozilla applications. Those two kinds have very different working mechanisms so there are a lot of different requirements. To standalone XUL applications, the debug environment is easily setup since they depend only xulrunner which have been used very well in AJAX Toolkit Framework to integrate into Eclipse. While to XUL extensions to Mozilla application, it seems hard to integrate their debug environment into eclipse. They highly depend on their target applications. Till now, I still have no idea how to fully support extension development in the XUL editor plugin for Eclipse. Any suggestions?
Firefox 3 will be based on XULRunner as well (with test builds appearing soon), so debugging an extension shouldn't be very different from debugging a custom XULRunner-based application. Is there a scope document for this project somewhere?
Hi, Nickolay Sorry to say, there is no scope document for this project right now. Actually the project comes from the idea by Mike Beltzner: "Build a XUL editor plugin for Eclipse that leverages the XULRunner component and JS debugger from the Eclipse Ajax Toolkit Framework to create a XUL UI development tool." from the mozilla SoC wiki page(http://wiki.mozilla.org/Community:SummerOfCode06). Efforts will be made into merging existed XUL tools for eclipse to create a more powerful XUL plugin editor for Eclipse. Right now, I am considering the following existed tool projects: 1) EclipseXUL 2) Ajax Toolkit Framework 3) IDE4Laszlo None of them provides a full functionality for a XUL editor plugin for Eclipse. But merging their useful features together may be right choice.
Javier has proposed running the XPCOM-to-Java bridge over RMI with the Java Component loader attached be able to do remote invocations from Eclipse to a standalone Mozilla. This would allow for debugging extensions and chrome, I believe.
How to use the embedded mozilla browser shipped with ATF to display the XUL file? I am trying to find the solution to above question, but haven't found any workaround solution. By reading the code, we can open the embedded mozilla browser with a parameter: an url address. To a xul file, what kind of url address should we pass to the embedded mozilla browser? The embedded browser doesn't recognize the "Chrome" url, while using "file" protocol with absolutely address to the "xul" file aslo doesn't work. Browser tries to parse the xul file if you specify the absolutely address to xul file, this should lead to parse error just like we browse directly the "xul" file in firefox. The JS debugger provided by ATF tightly works with the embedded mozilla browser.If we can't use this embedded browser to display xul file, I don't know if there are other ways to leverage the JS debug support provided by ATF. So I am eager to find the answer to the question in my comment's beginning. Any suggestions are warmly welcome!
The embedded browser is based on xulrunner and thus has limited function. It does not have any chrome itself, and doesn't seem to know what chrome: URLs are. Simple xul pages should work, however, as they would in FF. To get a full Mozilla browser to talk to Eclipse, you'd need to pursue the XPCOM-over-RMI path described above. I suggest we take any ATF-specific questions and address them in the listserv instead of this forum. http://www.eclipse.org/atf/listserv/index.php
> does not have any chrome itself, and doesn't seem to know what chrome: URLs It does have the default chrome that ships with XULRunner, which includes the base XUL bindings as well as other chrome such as the extension manager. It is possible, using a directoryserviceprovider, to specify additional filesystem locations to search for .manifest files. But I agree the RMI approach is the long-term way to go. Not sure whether you want to make it within the scope of this project, though.
SoC Project Mid-term Report According to SoC's schedule, it is time for mid-term evaluation. Here I will make a brief mid-term report about current status of my project. In the last one month, I focused on hacking related projects and communicating with other developers, which IMO are prerequisites to the further project development. My initial idea in project proposal is to integrate existed XUL development tools together. EclipseXUL( http://sourceforge.net/projects/eclipsexul/) provides "XUL project wizard" and "XUL application launcher", while it lacks a mutipaged xul editor and an xul JS debugger. AJAX Toolkit Framework( http://www.eclipse.org/atf/) provides tools such as "DOM inspector", "JS debugger", "JS console" and so on. Those tools are the right things EclipseXUL needs. But the integration work isn't as simple as what I could imagine in the proposal. To extend and configure the EclipseXUL to leverage ATF's tools, after some hackings and discussions with other developers, I find the following facts can't be ignored: 1) The ATF's runtime tools(DOM inspector, JS debugger, JS console, etc.) are tied to the ATF's own instance of the embedded Mozilla browser. If we want to use those tools directly in EclipseXUL, we should configure EclipseXUL to use this embeded Mozilla browser editor; 2) It is simple to configure the EclipseXUL to load XUL pages into ATF's embedded Mozilla browser editor. But those XUL pages should run as standard web pages. This is why I don't it is suitable to use embedded web browser. As we know, single XUL page normally couldn't run as standard web page. The browser should be chrome awared and can display the layouts and widgets specified by XUL. I don't think the ATF's embedded browser has those abilities; 3) Now in EclipseXUL, it uses external system command "xulrunner" to launch the xul application that means EclipseXUL launch Mozilla as a separate process. And ATF uses XPCOM to talk to the browser and underlying JSD API. XPCOM only allows the communication within one process. This makes it impossible to hook up JSD service provided by ATF when using external XULRunner to launch XUL applications. Through these facts, we can learn that it is not that easy to integrate the runtime tools provided by ATF directly into XUL development environment. The followings are two possible approaches for the further development: 1) Javier Pedemonte has proposed using a Java component loader such that the external instance of Mozilla would launch a small Java process within it, and then we could talk to it over RMI. If this works, we don't need rewrite the codes of the EclipseXUL's xul application launcher. We can use RMI for interprocess communication. But the problem is that the RMI approach is only a prototype and may not work very well. So maybe we can use this approach in the future when it has become mature, but not in this summer. 2) The other approach is to rewrite the EclipseXUL's xul application launcher which uses external xulrunner command to launch xul application. If we can manage to use JavaXPCOM to create and run an xul window, we could avoid considering the implementation of interprocess communication mechanism. There is an online article( http://rayh.co.uk/blog/?p=13) introducing how to use JavaXPCOM to start XUL window. But this article is too brief and I contact the author but he said he couldn't provide any runnable example. I am now really confused about how to implement this. It is easy to embedded a web browser into eclipse since the layout and widgets for web browser are static and fixed. While to an xul application, I wonder how we could dynamically generate the SWT windows according to the different layouts and widgets specified by different XUL pages. So to me, this may be possibly workable approach while I am still not clear how to implement it in details. The above are 2 approaches I can think out so far. Maybe I have just missed some knowledge, so any suggestions are really appreciated. I am sorry if I don't explain things clear, please think free to point it out if there is any.
Now I can successfully load a xul file into ATF's embedded mozilla browser though it only works on Eclipse 3.1 with old ATF installation. I don't know why eclipse crashes when loading a xul file in embedded mozilla browser on the latest ATF installation for Eclispe3.2. I have increased my box's RAM to 1G so I think my hardware meets the requirement. I will continue my works on Eclipse 3.1. First make it work, then fix it. Anyway, my focus has turned to the following question: How could we register xul application's own chrome directory into xulrunner environment? By default, the Chrome: URLs only map to the "chrome" directory under xulrunner's installation directory. Since in XUL files, the link references are all in Chrome: URLs format. So in the xul editor plugin for eclipse, we hope to load the xul page by their Chrome: URLs instead of their absolutely OS path. Take the following case as the example, In my box, the xulrunner is installed in the folder "/home/program/xulrunner" and the xul application is located in the folder "/home/project/testxulproject". By default, the Chrome: URL recognized by embedded mozilla browser based on xulrunner maps to the folder "/home/program/xulrunner/chrome". If we can register the "/home/project/testxulproject/chrome" directory to the xulrunner, we can open the xul file "/home/project/testxulproject/chrome/content/test.xul" by the Chrome URL: "chrome://testxulproject/content/test.xul" with the proper configuration in application's chrome manifest. Now the problem is how to register the xul application's chrome directory. When the embedded mozilla browser startup, there should be some approach to add the chrome register procedure. I wonder if there are any XPCOM components or services which handles the Chrome registry, and through these components or services we can easily register our own chrome directory to the xulrunner environment. Any suggestions?
First, you should ask this in an appropriate newsgroup, where more people can help you. Second, I think you misunderstand how chrome:// URIs work. They are mapped on resources by the chrome registry (http://lxr.mozilla.org/seamonkey/source/chrome/src/nsChromeRegistry.cpp), which does so based on the chrome manifests of the XUL application, extensions, and XULRunner itself (http://developer.mozilla.org/en/docs/Chrome_Registration). The list of folders/files to read the chrome manifests from is obtained from the directory service, "ChromeML" key, the default XULRunner provider implementation is here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/xre/nsXREDirProvider.cpp&rev=1.47#578 You could register your own provider that returns the list of chrome manifests for the application being edited, then call nsIChromeRegistry::checkForNewChrome - and the chrome URIs of the application should start working. Pseudo-code for the provider (in JS): var prov = { getFiles: function(prop) { if(prop == "ChromeML") { Components.returnCode = Components.results.NS_SUCCESS_AGGREGATE_RESULT; return { // your nsISimpleEnumerator with a list of dirs to look // in for application manifests, e.g.: stop: false, hasMoreElements: function() { return !this.stop }, getNext: function() { this.stop = true; var file = Components.classes["@mozilla.org/file/local;1"] .createInstance(Components.interfaces.nsILocalFile); file.initWithPath(/* xxx */); return file }, //QueryInterface impl }; } throw Components.results.NS_ERROR_FAILURE }, //QueryInterface impl } var file = Components.classes["@mozilla.org/file/directory_service;1"] .getService(Components.interfaces.nsIDirectoryService) .registerProvider(prov); On a similar note, you'll have to implement a protocol resolver for WTP to understand the chrome:// URIs. Solid has some code for that.
Lian, if you're seeing a crash in ATF, please file a bug with ATF with steps to reproduce, a core dump if available, version info, etc. No promises we can fix it, but we can't try unless we know about it.
(In reply to comment #16) Thanks for the comment. I got the answer for how to register my own provider. In the ATF's embedded mozilla browser, the class org.eclipse.atf.mozilla.ide.core.LocationProvider(http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.atf/components/plugins/org.eclipse.atf.mozilla.ide.core/src/org/eclipse/atf/mozilla/ide/core/LocationProvider.java?rev=1.1&cvsroot=WebTools_Project&content-type=text/vnd.viewcvs-markup) is responsible for providing paths and files that XPCOM needs. To make embedded browser aware of my own provider, we can simply add the codes for returning the list of Chrome directory location for the key "ChromeML" to the class LocationProvider mentioned above . The list contains the file paths pointing to both my own application chrome folder and the system xulrunner's own chrome folder. Following is the code snippet: <snippet> ..... else if (aProp.equals("ChromeML")) { files = new File[2]; files[0] = new File(PathToMyOwnApplicationChromeDirecotry); files[1] = new File(libXULPath, "chrome"); } ........... </snippet> The first file points to my own application's chrome folder, and the second points to the system xulrunner's chrome folder. After test, this works.
(In reply to comment #17) A new bug "Eclipse crashes when opening a xul page in ATF's embedded mozilla browser" has been filed on eclipse's bugzilla, the address is http://bugs.eclipse.org/bugs/show_bug.cgi?id=150211 .
Project Build 20060714 Released This build is only a test version release, it is still buggy and missing some major features. In this build, the EclipseXUL(http://www.sf.net/projects/eclipsexul) has integrated with part feature of the eclipse Laszlo project's xul plugin. The xul page can be loaded into ATF's embedded mozilla browser so that we can leverage ATF's runtime tools(DOM inspector, JS debugger, JS console, etc). This build contains following main features: 1) XUL project wizard 2) XUL perspective 3) XUL nature 4) XUL application launch shortcut 5) XUL application launch 6) XUL application debug shortcut 7) XUL application debug Features 3) and 4) use external xulrunner command to launch the xul application. And features 5) and 6) load the xul page into ATF's embedded mozilla browser so that we can leverage ATF's runtime tools. To install this build, you have to install Eclipse AJAX Toolkit Framework(http://www.eclispe.org/atf) and prerequisites(Eclipse 3.2, WTP1.5). The major bug right now for this build is that eclipse always crashes when loading an xul page into ATF's embedded mozilla browser. I have filed the bug "Eclipse crashes when opening a xul page in ATF's embedded mozilla browser" (http://bugs.eclipse.org/bugs/show_bug.cgi?id=150211) on the ATF project's bugzilla. But fixing this bug is out of my SoC project's scope. My following work will focus on implementing feature of multipage editor for XUL . To download the binary or source of this build and see some screenshots, please visit the page: http://lianliming.name/wiki/index.php/MySummerOfCode2006:ProjectRelease20060714
Lian, do you have a sense of how much of this (admittedly open-ended) project you will actually have done by the end of summer? Do we have a repository to put this code in when you're done?
Priority: -- → P1
(In reply to comment #21) Hi, Benjamin For the first question, I think I can finish the integration of related XUL features from EclipseXUL, ATF, IDE4Laszlo. The integration is not that difficult, the hard point is that I have to fight with some original bugs of EclipseXUL, ATF and IDE4Laszlo. This work is really time-consuming. And I will continue my works on this project after SoC programme ends, there are still lots of bugs to fix. And I still have no answer to your second question. I am now using a local CVS repository to manage my codes. It will also need further discussion for which repository to be used.
Lian, I would like for the code from this project to live under mozilla/tools/<something> in our CVS repository. mozilla/tools/eclipse-xul is good, unless you have a better suggestion. If you file a CVS Account bug I can probably get you special access for that location (typically you'd have to have contributed regular mozilla code and have three sr's, but this is a special case). Thanks for the update, your work looks great!
(In reply to comment #23) Hi, Benjamin This project doesn't start a new Eclipse XUL editor from scratch. It is to extend EclipseXUL by leveraging ATF, IDE4Laszlo's xul related features. From my personal point of view, I'd prefer to use cvs repository located on Mozilla project. There we can attract more developers to contribute. But you know, project EclipseXUL has its own project website(http://www.sf.net/projects/eclipsexul) and cvs repository(http://sourceforge.net/cvs/?group_id=145903). To migrate the project to a new cvs repository, I have to contact the project EclipseXUL's owner Lars ,who is also the only one developer of this project. His opinion is also very important.
Project Build 20060803 Released This is only another test version release, it is still buggy and missing some major features. Compared with the Last build (20060714) which contains following main features: 1)XUL project wizard 2)XUL perspective 3)XUL nature 4)XUL application launch shortcut 5)XUL application launch 6)XUL application debug shortcut 7)XUL application debug The major improvement is that, this build adds a XUL perspective. This perspective is based on IDE4Laszlo's Rich Client Tools. In this xul perspective, it provides following features for XUL editing environment: 1)A XUL source editor. This editor is a SSE editor, and is the central part of the perspective. 2)A XUL component Palette. You can drag and drop xul node from the palette to the XUL editor. 3)A XUL source outline view. It presents the xul document as a tree allowing user to make changes to the document's structure. 4)A attributes view. It displays valid properties fro the currently selected XUL node, and edit them in forms. 5)Code completion which can be used to fix errors in xul source. The major problem of this build is that the xul source editor is only a single page SSE editor. The ideal editor should be a multipage editor with preview functionality. But this preview functionality should leverage ATF's embedded mozilla browser which has some problem under test for xul preview. Fixing this problem is my next task for this project. To download the binary or source of this build and see some screenshots, please visit the page: http://lianliming.name/wiki/index.php/MySummerOfCode2006:ProjectRelease20060803
This looks very nice, but the binary download link doesn't work: http://lianliming.name/release/soc2006/EclipseXUL-20060803-1.zip As for multipage editor, I'd prefer the preview to be in a separate tab, so that I could easily dock it below the source editor.
(In reply to comment #26) > This looks very nice, but the binary download link doesn't work: > http://lianliming.name/release/soc2006/EclipseXUL-20060803-1.zip > There is something wrong with that link, please try another one: http://www.wangpenghui.name/download/lianliming/EclipseXUL-20060803-1.zip
Lian: This is a fine piece of work. Any plans to carry that forward?
Hi, Philippe I am really sorry the project doesn't have too much progress after SoC, I am now back to school and a little busy with the school works. I will make it move forward when I get time, and thanks for watching on this project.
Priority: P1 → P4
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.