Be the first to post a text review of XOffice. Rate and review a project by clicking thumbs up or thumbs down in the right column.

• More Detailed Project Description

  Hello all. I've received some interest in helping out, so recently wrote up the following to help everyone understand what this project is all about. From a macro perspective, the scope is quite large and there is quite a bit of work to be done. From a micro perspective, there are lots of discrete places to contribute. At the lowest level the objective is to create a cross-platform UI toolkit for constructing MS Office-like applications. Other projects have done similar work, but most consist of creating custom controls that run alongside the controls that are a part of the System.Windows.Forms toolkit. Our approach is somewhat different in that although we will support this model (i.e., use a Ribbon control on a SWF form), we are also providing an interop layer that abstracts the platform-native toolkit away from the developer. For an example of this, look at the references for the XOffice.Studio assembly -- you won't see SWF. This is a tall order -- other projects have tried the interop approach, and failed. The difference is that they were all trying to support the full SWF API. Their goal was to provide the developer with a way to build applications against the SWF API that had a uniform look and feel across all platforms. On the surface this seems like a good idea -- but the implementation is full of problems. In addition, I disagree fundamentally that the goal should be a uniform L&F -- Windows apps should look and feel like Windows apps, and Mac/Linux apps should look and feel like other native apps on those systems. More than that in fact -- I don't just want it to *look* like the other apps on a given platform, I want it to use the *native* controls for that platform. The trick is selecting an appropriate subset of controls that can be fully supported across platforms. For this project, that subset consists of the controls used in MS Office-like apps. The objective for this layer is to provide platform-specific bindings for Windows (SWF/WPF), OSX (Cocoa, some work with Carbon may be required), and Linux (KDE/GTK). If you're interested in this part, take a look at: http://www.mono-project.com/Gui_Toolkits and http://doc.trolltech.com/3.3/activeqt-dotnet.html At the mid-level we are providing an application model that is based on an XML-Object bridge (like an Object-Relational bridge, but for XML documents rather than databases). XO mapping has lots of issues... there's a great whitepaper by some MS researchers on the topic at: http://homepages.cwi.nl/~ralf/xo-impedance-mismatch/ At the moment you must hand-code an object model that conforms to the XO mapping that is supported by XOffice. Most of that mapping is handled in XOffice.Xml. There isn't a great example of this mapping in action available at the moment -- one exists as a part of the OPEL project (search SF.net), and I'm trying to get the admin to post it there. These mappings consist primarily of objects that extend a few key base classes and are marked up extensively with attributes to help guide the mapping process. All of this gets compiled into an assembly. Each assembly provides the objects needed to support a particular XML namespace. What you end up with is a DOM that does the XML reading/parsing/writing for you, and lets you do lots of other secondary types of processing like XML profiling. Finally, at the highest level, I am hoping to produce a version of the XOffice studio application that is fully configuration and XO assembly driven. The current app model is designed to be a starter app that can be extended and customized for scenarios where you are essentially modifying an XML-based document. The long-term vision is to allow for the creation of whole new apps without any coding required. The XO mapping assemblies can be generated/compiled by the studio application, and by adding in some kind of visual programming mechanism we can allow users to express logic that manipulates the DOM and the studio itself. This mechanism could be anything from a full-up hosted UML editor to a simplified editor similar to the one that supports Windows Workflow Foundation. Although there will need to be some support for the UML-level of detail, it will probably be closer to the WWF level as the general idea is to allow regular people to build these apps. Basically what you'll end up with is dynamically loadable assemblies that have support for both the data structures (XO mapping) and logic (the visual programming piece). Think of this as a sort of "Smart XML" -- we allow the XO mapping to handle the XML DOM, and let the user visually design some logic that goes through a code generator and gets compiled into the XO assembly. Effectively, the assembly is acting like an XML schema, except that now you're also supporting logic. XML-based programming languages have the same general idea, just different execution. These assemblies then get dynamically loaded into the studio environment on an as-needed basis whenever the user tries to edit some XML that uses the namespace that is associated with an XO assembly. So, like I said, there's lots to be done. The primary goal for the next year or so is to get the first tier (the cross-platform UI) working. After that, I'll start trying to tackle the studio environment in earnest.

  posted by chrisbray 931 days ago

• Help Wanted

  If anyone is interested in helping out with the project, please let me know.

  posted by chrisbray 937 days ago

• Alpha 3 Released!

  The first release is now available, the Alpha 3 build. Lots of work left to be done, but it's ready for you to take a look.

  posted by chrisbray 937 days ago

• xoffice Alpha 3 file released: XOffice-041707.zip

  Initial release (Alpha 3).

  posted 938 days ago

• File released: /xoffice/Alpha 3/XOffice-041707.zip

  posted 938 days ago