Friday, January 26, 2007

I'm looking for persons who are experienced in C++ to work with me to flesh out the Trixul cross-platform GUI toolkit. GUIs in Trixul are crafted from JavaScript and XML, just like Mozilla's XUL. JavaScript can call C++ objects. This is all provided in a very lightweight codebase that is easy to read, and comes in under 10,000 lines of C++ source.

Trixul natively supports Gtk+, Windows .NET Forms, and Cocoa. So, Gtk+ programmers, Windows .NET Forms programs, and Objective C programmers who know Cocoa are valuable to this project. If you know JavaScript, or XUL, you can help by crafting tests. If you know all of the above, well, I definitely want you on my team!

If you are interested, or have questions, please sign up (if not already a member) at and contact me at slogan621 at users dot sourceforge dot net



Blogger David said...

Hi Syd, I am interested, but confused a bit by the role of .NET. Since the mono project is implementing it on Linux (and I suppose Apple's BSD-like OS may not be far behind?), then does the platform independence come for free in a sense? i.e. If written using .NET, it (will) already be cross platform? And Trixul is only on .NET platform (for Windows) so it doesn't work without the CLR in place, right? i.e. It won't be backward compatible to computers that lag behind adoption of the CLR runtime. -Dave Topham

9:06 PM, January 28, 2008  
Blogger Syd said...

Short answer: Trixul is concerned with supporting the dominant, native GUI toolkit on a given platform, so .NET only matters on Windows.

Long answer: The strategy behind Trixul is to abstract above native platform GUI toolkits, and do so in a way that allows Trixul to be portable to new platforms and toolkits without too much pain. My selection of Gtk+ on Linux, .NET on Windows, and Cocoa on Mac OS X was based on their being the dominant native GUI toolkits for their respective platforms. (One could argue that Qt would have been a good choice for Linux. In fact, if someone wants, they can, in a very straightforward manner, add support for Qt in Trixul.)

This is basically the same strategy used by wxWidgets, in fact.

A key benefit is that Trixul applications, based at the bottom layer on platform native toolkits, have platform native UIs that users are more likely to accept.

Let's say some new OS comes along with its own GUI toolkit (or some older OS becomes the focus of someone who is interested in experimenting with Trixul), and a decision is made to port. As long as the native toolkit chosen is like most modern toolkits (window-based, widgets that consist of containers and controls, event-driven architecture controlled by a main loop of some sort -- the dominant (only?) paradigm we have seen since the introduction of Mac Toolbox back in 1984), and as long as the platform supports C++, Trixul should port there.

Now, let's say Mono is everywhere, and we want it to be the platform toolkit. Well, as long as the libraries are ported, and the APIs don't vary, Trixul's factory class that picks a platform GUI toolkit could be made to use .NET everywhere. But we would not want to architect Trixul to preclude the selection of other GUI toolkits, or be dependent on .NET. That would be a mistake in my view.

9:45 PM, January 28, 2008  
Blogger David said...

Thanks for your explanation. But I don't consider .NET a native platform. That is my point, Trixul is only going to work on the CLR virtual machine if you choose .NET. It cannot be used with a native windows application. Perhaps you choose to only look forward and not back. But you are making it depend on .NET which is a virtual machine. There is no native support for windows, right?

2:59 PM, February 07, 2008  

Post a Comment

<< Home