MozillaZine

ViXEn: The Visual XUL Environment

Thursday September 7th, 2000

From the mozilla.org website: "Vixen is designed to be a Visual XUL IDE similar to Visual Basic, Delphi, Macromedia Dreamweaver and Glade, but for the XPToolkit technology developed by the Mozilla project. The initial goal of Vixen is to allow developers to quickly develop professional quality dialogs and windows without having to write any (or at least much) XUL or CSS by hand. The long term goal is to create a comprehensive development environment for rapid development of XUL applications."


#1 Damnit Ben! Get back to work!

by jelwell

Thursday September 7th, 2000 8:31 PM

Reply to this message

What are you doing? Pet projects contribute to the stagnation of Mozilla.

Joseph Elwell.

#9 Re: Damnit Ben! Get back to work!

by Ben_Goodger

Friday September 8th, 2000 5:43 PM

Reply to this message

what am I, your bitch?

#13 Re: Re: Damnit Ben! Get back to work!

by Tanyel <tanyel@straightblack.com>

Wednesday September 13th, 2000 12:11 PM

Reply to this message

Maybe you are his flunky.

#2 change name

by madass

Friday September 8th, 2000 7:12 AM

Reply to this message

i would IMMEDIATELY change the name, if you don't want others to laugh their asses off on it...

#14 Re: change name

by gwalla <gwalla@despammed.com>

Monday September 25th, 2000 6:23 PM

Reply to this message

Right. I mean, ViXEn sounds like it has something to do with Vi, the most ridiculous editor in existence. Nobody will be able to take this project seriously until the name is changed to avoid associations with that program. ;)

#3 "Obvious?" suggestion...

by sab39

Friday September 8th, 2000 9:09 AM

Reply to this message

... would be to work on getting Ender to reliably and effectively edit XUL documents.

Second would be a visual CSS editor that lets you edit stylesheets - and by extension, skins.

Both of these, but especially the second, would be extremely useful outside the context of ViXEn. In addition, they would be at least the two single biggest tasks in any such project. I'd suggest tackling these first...

#4 Re: "Obvious?" suggestion...

by sdm

Friday September 8th, 2000 9:17 AM

Reply to this message

If you read the web page, it relies on some of Ender's functionality (undo/redo). I'm sure it will integrate further. Do you have any ideas?

#5 Re: "Obvious?" suggestion...

by sab39

Friday September 8th, 2000 9:56 AM

Reply to this message

Well, my thought was to simply extend Ender rather than reuse parts of its functionality. Ender is already modifying DOM trees under the hood, and I can't believe it makes *that* much difference whether the DOM trees in question are XML or XUL or HTML. You would need a different set of editing rules and some new toolbars with the XUL elements available rather than the HTML ones, but that sounds like it would be about all that was needed. Sounds easier than writing a XUL editor from scratch, even if you do borrow the undo/redo.

However, all I know about ender is from reading the newsgroups, and I haven't even been subscribed to .editor for some time now (reading every mozilla newsgroup I was interested in was just taking too much time). So I don't really know how feasible this is. Just throwing it out there as a suggestion that *seems* obvious, to see whether it really is feasible.

#6 Please change the name!

by StupidDog

Friday September 8th, 2000 11:23 AM

Reply to this message

Vixen sounds like "wichsen" in German - and that is the word for having sex with yourself. So If I should convince my boss to use your tool, PLEASE get a new name for it ;)

#8 Re: Please change the name!

by beastie

Friday September 8th, 2000 4:15 PM

Reply to this message

Oh man, that's beautiful!

#7 no user requirements

by strauss

Friday September 8th, 2000 3:01 PM

Reply to this message

I read the requirements page and saw nothing that would indicate that an actual user experfience design process is being applied. there's not a word about who the users are, what tasks they want to perform, what environment they will be working in, what their workflow for their tasks is or will be, what the end result they want out of their tasks will be, and so on.

Needless to say, at least for anyone with a ue design background, all these questions are critical for good design decisions to be made. The idea that you'd be placing widgets and windows before having a well-developed idea of users, tasks and environments is beyond retro, and this approach can only result in software that is useless or highly problematic under real-world conditions.

#10 Re: no user requirements

by asa <asa@mozilla.org>

Friday September 8th, 2000 11:03 PM

Reply to this message

yeah, and what were they thinking when they invented that damn wheel contraption.... They should have been focused on the bucket seats and the automatic transmission.

#11 Re: no user requirements

by Ben_Goodger

Friday September 8th, 2000 11:11 PM

Reply to this message

This project is merely in the ideas stage at the moment. The first goal is a tool that allows engineers to put together dialogs based on solid UE specs in a short timeframe, using the correct shared styles and whatnot.

The reason Mozilla is so pitiful from a polish perspective is that many dialogs are not utilising the code in communicator. Even a simple visual tool (like the MSVC dialog editor) would help a great deal.

#12 Re: Re: no user requirements

by strauss

Tuesday September 12th, 2000 3:12 PM

Reply to this message

That does clarify the user requirements significantly. I wonder why it would be too difficult to put in a few paragraphs explaining this in the requirements. I think you have given a mistaken impression that the tool is for the use of user interface designers building general-purpose application code, not Mozilla engineers implementing specs from UE designers.