Hello,
allow me to forward an email by Vexi project lead
Charles Goodwin posted to the uuu-devel mailinglist
that answers the question why use Vexi in detail.
Here we go:
Unununium is one of these really interesting projects
that I like to monitor (I guess I'm just one of those
web junkies) periodically, checking up on mail list
discussion etc.
One thread perked my interest: GUI approach [0]
A quick bit of background on me so that you understand
where I'm coming from... I work on the Vexi project
[1] which basically provides a platform for creating
UIs using just XML and JS that are automagically
distributed. It's like, say, XUL but not tied into
Mozilla.
The conversation about how to approach the UUU GUI
struck a chord or two with me. Enough to make me
subscribe to the list and lay down a form proposition
on how UUU could use Vexi and why.
In the 'GUI approach' thread, the following were
mentioned / discarded:
1. PicoGUI - www.picogui.org
- too large
- not actively developed
2. Nanosistemas - www.nanosistemas.com
- in tasm
- confusing code
- portugese documentation only
3. MGL
- requires wxWindows (presumably too big)
So, the conclusion seems to be "there is nothing
suitable" which would mean creating your own from
scratch. Well, I'd like to make the case for Vexi.
"An XUL motor!?" Bear with me, please, it'll be an
good read if nothing else. ;)
My understanding of the critical issues so far cited
for an ideal GUI candidate are:
1. Portability
2. Perfomance
3. Size
4. An understanding of the interals
Well, Vexi is all about portability. We have build
targets for Linux, Windows, MacOS, and Solaris. We
could have more if anybody wrote them (a single file
that implements the local hooks necessary for the core
to perform.)
We are also about performance. The goal of the Vexi
project is to provide an environment for creating
applications that behave / feel like native
applications, only are launchable over the Internet.
Size is also a big issue. The core weighs in at
around 700k or so, and that includes a fair bit of
stuff you guys wouldn't really want (or perhaps you
would but for other reasons).
Finally, the internals of Vexi are pretty basic. The
Vexi platform consists of 3 major parts: the core, the
widgets, and the launcher (which is of no interest to
you).
The core implements a box layout model and an API for
manipulating it. This provides an environment where
you can construct widgets and applications using a bit
of XML and JS. The Vexi widgets are just a bunch of
templates utilising the core API. The XML/JS code for
the widgets weighs in at less than 300k. So, for a
megabyte, you have a GUI and a GUI library that
supports freetype fonts, pngs, jpgs, transparency, and
comes with a ton or pre-prepared widgets that are as
simple to use as this:
<button margin="10" padding-left="20" text="Push me!"
/>
<tabpane maring="10">
<ui:box tabtext="Start" text="Select a tab for
some fun" />
<lazyload src=".org.vexi.chess.main" />
<lazyload src=".org.vexi.irc.main" />
</tabpane>
Vexi widgets are 100% themable and 100% customisable.
Since they're all written in the core API, you could
literally pull the code out of any widget to use in
your own widget. As templates are defined in an
object-oriented manner, it's very easy to share common
behaviour and to create a well-engineered codebase.
(As the main widget author, I like to think the
widgets are well engineered!)
Hopefully you've got a raised eyebrow or two at the
moment, so now I'd best move on to the more technical
matters that could make or break this proposition.
Vexi is written in Java. (Shock, horror!) Yes, Java,
that "slow" language. But it doesn't need Java.
Using GCJ and some platform- specific .c files that
can tie the core into a native environemnt, we can
port Vexi to just about anything. There will be an
OpenGL accelerated version of the core in the nearish
future (before the end of the year) for Windows,
Linux, and MacOS X. Then we'll have a GUI that not
only looks / feels like a native GUI, but is _faster_
too.
Vexi applications commonly communicate using XMLRPC or
SOAP. Obviously that is way less than ideal for an OS
GUI library, but that is something I personally am
looking to address anyway. Given the flexibility of
Vexi, personally I'm looking to make Vexi a UI tool
for OpenGL applicaitons so that would need rectifying
regardless.
One little puzzler that you might be thinking about
is, "How does a Java-based application support a
C-based library like Freetype?" The answer is
surprising but effective. We have something called
'nestedvm' which is a dynamic MIPS-to-Java-bytecode
translator. It's fast. Very, very fast. We can
compile a C app into MIPS and then run it anywhere,
giving us leverage over an extreme number of existing
libraries. We actually only use it for Freetype and
libjpeg. But, as an aspiring OS, this could be a very
useful tool as it would give UUU access to literally
thousands of existing codebases without the need to
port them at all. Anything that compiles to MIPS and
isn't hardcoded to a particular platform would be
available to you. I hope that raises an eyebrow or
two!!! ;)
Vexi is actively developed. In fact, 5 of us are
getting together to start a support company as we are
starting to perk some interest.
Licensing... the Vexi core is GPL. We can't change
that. The original author released it as XWT [2] (we
had to fork [3] reluctantly) and has no intention of
releasing it under any other license. But that's not
a bad thing necessarily. The Vexi widgets are LGPL
and we _can_ relicense those if you _really_ didn't
like that. ;) Because any UI written on the Vexi
platform is interpreted (ie XML/JS are only
interpreted) they can be of any license.
So, to quickly summarise, Vexi and UUU could work
because:
1. Vexi is portable; a small UUU-specific class and
Vexi is yours
2. Using XML/JS to define a GUI is simple and fast,
and as it's dynamic you could develop your GUIs live -
no compiling needed
3. Vexi brings a lot to the table that you might have
to otherwise port such as freetype fonts.
4. You get nestedvm in the bundle - C apps are all
yours
5. The core can be OpenGL accelerated - fast GFX
anybody?
6. Vexi is pretty small and very flexible. Define
your own widgets, create your own themes, it's all
easy.
7. You don't have to write your own GUI system!
8. We are working on eventually getting SVG support
into Vexi. SVG support that could be OpenGL
accelerated. Niiice. :)
So, if you want Vexi, the million dollar question is
"how much would need to be done for Vexi to be in
UUU?" Well, I can think of 3 major tasks:
1. A UUU-specific GCC/GCJ output so you can compile a
UUU binary.
I have no idea what work this entails. I know
nothing about compilers. Considering the XWT author
and 1 of our development team are GCJ hackers, this
isn't 'out of reach' so to speak.
2. A UUU-specific .c file implementing Vexi for UUU.
This wouldn't be hard. The platform specific
files are no more than a few hundred lines of code
each. For somebody who knows what they are doing, it
would be acheivable in a day.
3. Establishing and implementing how Vexi and UUU
would communicate.
Again this wouldn't be hard. The Vexi project
would implement it's side of the problem once the
details are established.
Ok, before I promise you a golden egg, I'd better go
over the caveats:
1. Native binaries don't work at the moment.
Not as bad as you think. When we forked we had a
lot of ground to make up to get the project back on
track, and we have only just gotten around to
reimplementing the native binaries. They return in
the next Vexi release (Vexi Beta 3) in 2-3 weeks time.
2. Vexi doesn't seem fast when resizing frames.
In order to get over some dirtying issues, some
optimizations were temporarily disabled. This will be
reimplemented in Beta 3.
3. Vexi doesn't seem that fast.
Actually, the only demoable version at the moment
is in Java. When Beta 3 comes around, the difference
will be immense. Because Vexi uses a simple box-based
layout, the rendering process is very, very efficient.
4. Vexi is only at Beta stage. / "I've not heard of
Vexi."
Version numbering is subjective. Vexi is a
codebase with a lot of history. Because we are a fork
of a project that was renamed, and the project was (at
the time) floundering due to bad management, we are
not exactly a recognised brand. Expect that to change
in a big, big way in the coming months now that we
have gotten Vexi back to a respectable level.
5. Where's the documentation?
In the fork, the documentation was unlicensed
which implies it is under sole copyright of the author
of the XWT project. We have to write all the docs
from scratch. We valued a working platform over a
well documented one. Now the platform is approaching
a decent level, we are now looking to bring the
documentation up to a similar level in the coming
months.
So, if you're still with me - apologies for the long
read - then I'll finish up with a demo link and an
idea of how you could follow up any interest in a
Vexi-UUU union.
Vexi Beta 3 debuts in 2-3 weeks time. It will be
faster, better, and nicer than previous releases and
start to see the project documentation emerging so
people can start using Vexi. I would ask you not to
judge Vexi on the following demo but on Beta 3 (join
the news list [4] to get the announcement) before
deciding against Vexi. Here is a quick demo of Vexi,
again something that will be much improved by the next
release:
http://www.addedspace.co.uk/vexi/applet.cgi?build=test9&url=http://download.vexi.org/chess-test3.vexi&url=http://download.vexi.org/widgets-test10.vexi
Given the progress we have been making, the advantages
of the platform, and that we will be a stable,
documented project in roughly 2 months time, Vexi
could be the ideal GUI candidate for UUU. Could be.
I've invested a lot of time composing this email, so I
obviously believe. I hope I've also given you reason
to. :)
I'm always available through email, will happily
answer any questions, and can usually be found in
#vexi on irc.freenode.net if that is your preferred
pigeon.
Regards,
--
- Charlie
Charles Goodwin <charlie at vexi.org>
Online @ www.charlietech.com
[0]
http://unununium.org/pipermail/uuu-devel/2004-June/000155.html
[1] www.vexi.org - remote UIs in XML / JS
[2] www.xwt.org
[3] http://wiki.vexi.org/InfoFAQ
[4] news at vexi.org - subscribe using
http://lists.vexi.org
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk
