GUI XUL editor
Open standards cannot effectively compete with Microsoft XAML and other closed technologies for large market share without a good set of developer tools that make authoring and developing easy (or at least easier). Visual Basic 5-6 were limited and inefficient programming platforms, but were wildly popular simply because developers could drag/drop/insert UI and it would just work. Microsoft Access data applications have much the same appeal. If XUL is to compete with these closed technologies, it needs to have a good GUI editor. The mozilla2.0 team is acutely aware of the problem, but nobody has yet stepped forward to lead the charge.
I spoke briefly with Daniel Glazman about possible UI ideas for a GUI XUL editor, and how it might relate to the fantastic work that he is doing on NVU, the next-generation HTML editor. After a little bit of playing, it is obvious that the editing model for XUL would have to be very different from HTML.
One of the primary factors involves the selection model. In HTML, you select text in a mostly-linear fashion to edit it. Even floats and other out-of-line objects have their own little “flow”. This is simply not the case for XUL, where you must think in terms of boxes and flex, fitting to the available/desired space. In XUL editing, your “cursor” may be vertical or horizontal, and has a limited scope in the current containing box. Once you escape the immediate containing box, your cursor switches orientation from horizontal to vertical (and vice-versa).
I did a basic playground stylesheet with a simple XUL file, and created a special element <edit:cursor> which would act as a “heavy” cursor. What I want to do is steal large parts of DOM inspector code, so that there is a tree sidebar which matches the GUI view.
I found a few places where I need/would really love additions to core gecko… somebody please tell me how hard these are:
1) parse entity names with a special DOM element, instead of expanding them to text. This is pretty much a requirement to do large-scale apps that localize appropriately using the chrome registry
2) a :-top-hover selector. I need a selector that only matches the topmost hovered element, not every hovered element.
3) a -moz-min-margin rule… I can work around this if necessary, but in order to give space between boxes for drag-n-drop and other activities, I would like a -moz-min-margin: 4px rule applied to *.
Did I just volunteer for something? I hope not ;)
August 14th, 2004 at 8:02 pm
You might want to check out the work Darin’s doing on XULRunner. Currently there’s no tracker bug, but there’s information on his blog and the xul wiki.
August 14th, 2004 at 8:10 pm
Oops, accidentally copied in the trackback url instead of the actual url for Darin’s post – it’s here
Sorry for the commentspam
August 14th, 2004 at 8:17 pm
R.J. Keller is working on a XUL IDE called MozCreator. It is written in Java and he’s investigating how to integrate Gecko so that he can show the actual rendering by Gecko.
August 15th, 2004 at 2:02 am
> 1) parse entity names with a special DOM element, instead of expanding them to text. This is pretty much a requirement to do large-scale apps that localize appropriately using the chrome registry
sounds good, I’ve always wondered how a XUL IDE would be able to handle entities…
August 15th, 2004 at 1:04 pm
Another project you may want to look at is Vixen. I can’t seem to find any code for it, though…
August 17th, 2004 at 10:14 am
Benjamin, I have actually no idea what 1) is supposed to be, could you elaborate? Or, maybe I have an idea. Are you talking about generating a some-odd-impl-of-nsIDOMNode-and-nsIContent?
That would be way hard, as you had to kick expat for this. And I’m not sure how this should be displayed, with anonymous content if we want? That is, should we be able to see what the entity expands to?
July 26th, 2005 at 12:45 am
Most of what you need.
Tree + View with D&D onto/between both views.
Still work in progress. Currently stalled for lack of a good JS editor. That work stalled due to changes in XSLT processor.
I am working towards a full IDE with all the bells and whistles.
July 27th, 2005 at 1:40 am
While it’s a commercial IDE, and yes, I’m the tech lead for it, Komodo is developed on top of mozilla, runs on all platforms (osx VERY soon), and supports many languages. I do all my xul/js work in Komodo. We do not however, have any features specific to developing xul apps. But like firefox, you could write extensions…if only I had more hours in the day.
BTW, I wanted to email you a couple questions about xulrunner on osx, but your contact page is broken.
Regards.
August 20th, 2005 at 12:07 am
Coming back on this old post: so basically your :-top-hover selector is a non-hierarchical :hover, right ? If the pointer hovers over a span in a paragraph, the span will be top-hovered but not the paragraph, correct? Hmmmm. Seems like you need a functional pseudo to say your element is the original target of the event…
:explicit-target(:hover) or something
July 16th, 2007 at 1:57 am
Is the idea of a Visual XUL editor dead?
November 15th, 2007 at 1:13 am
Just checking in again to see if there’s any update on a Visual XUL editor. I am becoming very tempted to just write one myself now that I’ve had experience in writing XUL apps to begin with. It’s a huge task, though.
I was hoping that there’d be some way to extend an existing platform, such as the Visual IDE project at eclipse. They were aiming to make a visual ide editor that could build a GUI for any language (not just java/awt, for instance). I’m not sure if it’d be easier to use that project (which means that the GUI editor would be written in Java….) or to write a native XUL application running in XULRunner, I presume. Ideas?