[Q] Ruby and XUL?

[Daniel Carrera]

Hi all,

I just read a neat article at IBM DeveloperWorks:

http://www-106.ibm.com/developerworks/web/library/wa-appmozx/?ca=dgr-lnxw02MozillaXMLApplets

It's about writing GUIs with Mozilla's XUL. I must say I'm very
impressed. XUL looks like a great idea. Writing GUIs is traditionally a
long and tedious process. XUL is an XML-based way of writing GUIs very
easily. For example, here is a menu bar:

<menubar id="menubar">
<menu id="File" accesskey="F" label="File">
<menupopup>
<menuitem id="f1" label="New" accesskey="L" oncommand="new()"/>
<menuitem id="f2" label="Open" accesskey="O" oncommand="open()"/>
<menuitem id="f3" label="Save" accesskey="S" oncommand="save()"/>
<menuitem id="f4" label="Print" accesskey="P" oncommand="print()"/>
</menupopup>
</menu>
</menubar>

So, defining the GUI structure is easy and clear. All the programning
logic is left for an actual programming language.

Unfortunately, it seems that the only language supported is JavaScript. =(
I don't particularly like JavaScript.

I was just wondering what it would take to be able to use Ruby for the
programming logic. I guess that one way is to convince the Mozilla
project to ship Ruby with Mozilla. But I wouldn't count on that.

Re-implementing XUL would be very difficult, I imagine.

But over-all, I think I like the idea of using XML for the GUI structure
and a programming language for the behaviour. This strikes me as a good
combination (but then again, I am not a very experienced programmer).

Cheers,

 

[Pablo Lorenzzoni]

Hello!

Em Qua, 29 Out 2003, Daniel Carrera escreveu:
| I was just wondering what it would take to be able to use Ruby for the
| programming logic. I guess that one way is to convince the Mozilla
| project to ship Ruby with Mozilla. But I wouldn't count on that.

Hm... implementing XUL in Ruby would be very easy. The problem have,
actually, two sides:

(1) Either we want Mozilla to use Ruby to draw their GUI - and I think
they'd never do that since JavaScript is the "de facto" language for
client-side applications

(2) Or we want to use XUL's scheme in our Ruby programs - which can be
more interesting... writing our GUIs using XML is, surely, much easier
than the traditional method. The problem is that Ruby doesn't have a
"standard" Graphical Toolkit... So, "our XUL" either have to be bound to
some existing Toolkit and act as "yet another layer" for the GUI
programming, or (which I think is more interesting) act as an agnostic
layer, working with just any Toolkit.

| But over-all, I think I like the idea of using XML for the GUI structure
| and a programming language for the behaviour. This strikes me as a good
| combination (but then again, I am not a very experienced programmer).

The idea is not new. I think Glade, for the Gtk, can save it's
structures in an XML format to be loaded inside the program. If we could
imagine an "agnostic" Glade that outputs XML in the XUL format, and make
it work with any toolkit Ruby support... that sounds as a good idea.

[]s

Pablo

 

[Daniel Carrera]

| I was just wondering what it would take to be able to use Ruby for the
| programming logic. [snip]
(2) Or we want to use XUL's scheme in our Ruby programs - which can be
more interesting... writing our GUIs using XML is, surely, much easier
than the traditional method. The problem is that Ruby doesn't have a
"standard" Graphical Toolkit... So, "our XUL" either have to be bound to
some existing Toolkit and act as "yet another layer" for the GUI
programming, or (which I think is more interesting) act as an agnostic
layer, working with just any Toolkit.

That's a very interesting idea. I hadn't thought of that. I could write
a GUI program with Ruby and (let's call it) RubyXUL. I can run it with
one toolkit and you can run it with another (because they both have a
wrapper for RubyXUL).

That would be a neat way to meet differences in platforms and personal
taste. I don't have to worry about the fact that my GtkRuby application
won't run under Mac. Or that Fox doesn't look good under KDE.

Also, we don't have to exactly copy Mozilla's XUL. If there's any place
where we feel that the Mozilla team went wrong, we can change it in ours.

Okay, XUL is XML. Ruby comes with an XML parser, so that's not a
problem.

If we could imagine an "agnostic" Glade that outputs XML in the XUL
format, and make it work with any toolkit Ruby support... that sounds
as a good idea.

Indeed.

So I guess that for each toolkit we'd need a library that can interpret
read XUL and produce the GUI.

There can be an environment variable which specifies which toolkit the
user wants.

I had never thought of designing toolkit-agnostic GUIs. That's a very
neat idea.

Cheers,

 

[Raphael Bauduin]

It's funny, I just wondered yesterday what it would take to integrate
ruby to mozilla so I could use ruby in place of javascript.

Maybe it could be done (if the whole idea is realistic of course ;-) as
a module/extension to install so it wouldn't have to be shipped with
mozilla.

There's already an xpcom binding for ruby (not sure it's still active
though : http://rbxpcom.mozdev.org/ ).

Raph

 

[gabriele renzi]

il Wed, 29 Oct 2003 17:56:24 +0900, Pablo Lorenzzoni

Hello!

The idea is not new. I think Glade, for the Gtk, can save it's
structures in an XML format to be loaded inside the program. If we could
imagine an "agnostic" Glade that outputs XML in the XUL format, and make
it work with any toolkit Ruby support... that sounds as a good idea.

may I point you to QTDesigner?
It outputs a .ui file wich is XML and very well documented.

The UI file is then 'compiled' in actual code (from 'uic' or Pyuic o
rbuic that I saw somewhere in the kde cvs

Actually, it should be quite toolkit-agnostic, cause there is a ui
compiler that outputs java AWT/Swing code..

 

[Phil Tomson]

Hello!

Em Qua, 29 Out 2003, Daniel Carrera escreveu:
| I was just wondering what it would take to be able to use Ruby for the
| programming logic. I guess that one way is to convince the Mozilla
| project to ship Ruby with Mozilla. But I wouldn't count on that.

Hm... implementing XUL in Ruby would be very easy. The problem have,
actually, two sides:

(1) Either we want Mozilla to use Ruby to draw their GUI - and I think
they'd never do that since JavaScript is the "de facto" language for
client-side applications

Well, Mozilla is open source and it does have a plug-in architecture
(doesn't it?). Would it be possible to create a plug-in that allows you
to use Ruby for XUL as an alternative to JavaScript?

Alternatively, what if Ruby was used to generate the required JavaScript
code? That way you wouldn't have to touch (or even know JavaScript) to
use XUL, and it's probably a lot easier than the plug-in suggestion above.
....well, on second thought, maybe it wouldn't be that easy.

Phil

 

[Robert Klemme]

Hi all,

I just read a neat article at IBM DeveloperWorks:

http://www-106.ibm.com/developerworks/web/library/wa-appmozx/?ca=dgr-lnxw02MozillaXMLApplets

It's about writing GUIs with Mozilla's XUL. I must say I'm very
impressed. XUL looks like a great idea. Writing GUIs is traditionally a
long and tedious process. XUL is an XML-based way of writing GUIs very
easily. For example, here is a menu bar:

<menubar id="menubar">
<menu id="File" accesskey="F" label="File">
<menupopup>
<menuitem id="f1" label="New" accesskey="L" oncommand="new()"/>
<menuitem id="f2" label="Open" accesskey="O" oncommand="open()"/>
<menuitem id="f3" label="Save" accesskey="S" oncommand="save()"/>
<menuitem id="f4" label="Print" accesskey="P" oncommand="print()"/>
</menupopup>
</menu>
</menubar>

So, defining the GUI structure is easy and clear. All the programning
logic is left for an actual programming language.

BUT: the "long and tedious" of the process does not come from setting up
the structure IOW doing the layout. That's easily done with current UI
designers.

The hard part is to connect the GUI elements with each other AND with the
model via signals. That's where most logic resides and as far as I can
see a UI structure defined in XML doesn't help you there. Interactions in
the UI can get very complex if you are trying to make things usable.

My EUR 0.02...

robert

 

[Erik Terpstra]

Well, Mozilla is open source and it does have a plug-in architecture
(doesn't it?). Would it be possible to create a plug-in that allows you
to use Ruby for XUL as an alternative to JavaScript?

Alternatively, what if Ruby was used to generate the required JavaScript
code? That way you wouldn't have to touch (or even know JavaScript) to
use XUL, and it's probably a lot easier than the plug-in suggestion above.
...well, on second thought, maybe it wouldn't be that easy.

I usually make server side generated XUL interfaces (with Ruby) and
avoid client-side scripting as much as possible.

It's exactly the same as writing CGI programs in Ruby, except that you
are generating XUL markup instead of HTML markup.

The only difference in this case is that HTML generating CGI programs
have the look and feel of a website, whereas XUL generating CGI
program's have the look and feel of a native application.

Sending form data, and dynamically refreshing trees/lists can be done
with a couple of JavaScript one-liners.

Server-side scripts are also much easier for testing and debugging.

Erik.

 

[Eric Hodel]

Hi all,
=20
I just read a neat article at IBM DeveloperWorks:
=2E..

So, defining the GUI structure is easy and clear. All the programning=20
logic is left for an actual programming language.

Yes, XUL is great

Unfortunately, it seems that the only language supported is JavaScript. = =3D(
I don't particularly like JavaScript.
=20
I was just wondering what it would take to be able to use Ruby for the=20
programming logic. I guess that one way is to convince the Mozilla=20
project to ship Ruby with Mozilla. But I wouldn't count on that.

In order to script XUL, you need to plug into Mozilla's XPCOM layer,
Mozilla ships with Javascript and C++ support built in, but all the
popular scripting languages are also supported:

http://rbxpcom.mozdev.org/ -- Ruby
http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXPCOM/ -- Python
http://plxpcom.mozdev.org/ -- Perl
http://www.mozilla.org/projects/blackwood/connect/ -- Java

Of course, you'll need to compile the component and plug it into
Mozilla.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/n+6KMypVHHlsnwQRAo16AJ9X9PjnF0HeAvftJOrAeRdW+MvJFgCfQFAD
RzdcUzcG9LLBWN5sj38LRkU=
=Bz+s
-----END PGP SIGNATURE-----

 

[Pierre Baillet]

Hi,

sorry to sound like a bad boy, but XPCOM bindings only allows you to
call mozilla XPComp components from your favortie scriting langage. So
you can, for instance, create a mqil component, make it connacts and
fetch mail via ruby but you'll never be able to ask it to draw an
alert on the user's screen.

XPCOM is the equivalent of windows' COM while XUL is the equivalent of a
higher level GDI. They only share javascript in common and the *XPCOM
bridges allows you to connect to the XPCOM world, not the xul one.

Plus the rbxpcom is, IIRC, a bit outdated thoug I don't think i've
managed to build it back when mozilla 1.0 went out.

hth,

In order to script XUL, you need to plug into Mozilla's XPCOM layer,
Mozilla ships with Javascript and C++ support built in, but all the
popular scripting languages are also supported:

http://rbxpcom.mozdev.org/ -- Ruby
http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXPCOM/ -- Python
http://plxpcom.mozdev.org/ -- Perl
http://www.mozilla.org/projects/blackwood/connect/ -- Java

Of course, you'll need to compile the component and plug it into
Mozilla.

Pierre.

 

[Robert Feldt]

I just read a neat article at IBM DeveloperWorks:

http://www-106.ibm.com/developerworks/web/library/wa-appmozx/?ca=dgr-lnxw02MozillaXMLApplets

It's about writing GUIs with Mozilla's XUL. I must say I'm very
impressed. XUL looks like a great idea.

I've also looked at XUL and think its promising (especially since I
found that both Firebird and Thunderbird's GUI's are done in XUL). My
idea on making it kind-of-work with Ruby would be to simply serve XUL
xml etc from a Ruby app. Could it work as long as you stay with the
default components? I understand that to make new components/widgets
you'd need to use rbxpcom or revert to javascript for the wdiget code.

I guess instead of writing it in XML we could do a YAML layer and output
the XUL XML from the objects created by the YAML loader.

Regards,

Robert

 

[Pablo Lorenzzoni]

Hello Daniel!

Em Qua, 29 Out 2003, Daniel Carrera escreveu:
| > If we could imagine an "agnostic" Glade that outputs XML in the XUL
| > format, and make it work with any toolkit Ruby support... that sounds
| > as a good idea.
|
| Indeed.
|
| So I guess that for each toolkit we'd need a library that can interpret
| read XUL and produce the GUI.

Exactly. Something like (sorry about the metaphor) DBI/DBDs. Could we
call that Ruby/TIS (Toolkit Independent System) and Ruby/TID (Toolkit
Independent Driver). We could have TIDs for, virtually, any toolkit,
including the ones that are not written yet.

| There can be an environment variable which specifies which toolkit the
| user wants.

Or a class-variable settable via command-line options.

We could have, also, default toolkits, and a fallback order. Something
like "Try with $TOOLKIT. If it's not there, try with FOX. If it's not
there, try with Gtk. If it's not there, try Qt....."

| I had never thought of designing toolkit-agnostic GUIs. That's a very
| neat idea.

Yes... it's neat. It's also difficult to implement. Toolkits have a lot of
widgets in common... And we'd have no problem with them. The real ugly
thing is to deal with widgets that are just supported by one or two of
the toolkits... There're two possible solutions for that:

(1) Deal only with common widgets
(2) Build the missing widgets in the particular TID

The advantage of thinking about these two options is that we can choose
(1), for easyness and for a quick bootstrap, and then, gradually, change
it to (2).

Anyway... the most important thing that comes before all that is the
specification of the TIS. We have only a handful of widgets we really
use (and most of them are already described in XUL's specification).
With that in hands, we can leave for the TIDs the task of rendering what
the TIS is asking for.

Well.. now comes the problems of a Ruby/TIS/TID's project: manpower. We
have to gather a good group of Toolkit's wizards with deep knowledge of
one particular toolkit, and another good group with (not necessarily as
deep) knowledge to understand the requirements each toolkit have
regarding each widget the TIS is going to support. The first ones have
to work in the TIDs, the last ones have to write the specification for
the TIS (AKA "our XUL").

I don't think there are many guys willing to work in such a project.
Maybe I am wrong... let's see...

[]s

Pablo

 

[gabriele renzi]

il Thu, 30 Oct 2003 07:44:32 +0900, Pablo Lorenzzoni

Exactly. Something like (sorry about the metaphor) DBI/DBDs. Could we
call that Ruby/TIS (Toolkit Independent System) and Ruby/TID (Toolkit
Independent Driver). We could have TIDs for, virtually, any toolkit,
including the ones that are not written yet.

may I point you to the gutopia project? look up in google, it was
something like this for ruby... never went reallt far I'm afraid..

Even the python folks have a thing called anygui that should fall in
this area..

Yes... it's neat. It's also difficult to implement. Toolkits have a lot of
widgets in common... And we'd have no problem with them. The real ugly
thing is to deal with widgets that are just supported by one or two of
the toolkits... There're two possible solutions for that:

(1) Deal only with common widgets
(2) Build the missing widgets in the particular TID

Well, you also have to handle different programming approaches, i.e.
AWT programming is really different from Qt or visual basic forms
programming..

 

[Richard Dale]

il Wed, 29 Oct 2003 17:56:24 +0900, Pablo Lorenzzoni



may I point you to QTDesigner?
It outputs a .ui file wich is XML and very well documented.

The UI file is then 'compiled' in actual code (from 'uic' or Pyuic o
rbuic that I saw somewhere in the kde cvs

Yes, it's in kdebindings/qtruby/qtruby/rubylib/designer/rbuic. You can
either compile the .ui file to ruby code, or you can load it at runtime
(although I haven't actually tried that).

Actually, it should be quite toolkit-agnostic, cause there is a ui
compiler that outputs java AWT/Swing code..

And there's a juic compiler in kdebindings/qtjava/designer/juic that outputs
code for the QtJava bindings. But the way you define slots/signals code in
Qt Designer is language specific, but you can write plugins for it, with
syntax highlighting etc. I'm working on one of those to go with the rbuic
tool.

-- Richard

 

[gabriele renzi]

il Thu, 30 Oct 2003 04:03:23 +0000, Richard Dale

Yes, it's in kdebindings/qtruby/qtruby/rubylib/designer/rbuic. You can
either compile the .ui file to ruby code, or you can load it at runtime
(although I haven't actually tried that).

I wonder: does this bindings works in any environment supported from
Qt?
I mean: can I write cross platform stuff with it?

and, how this relates with the Ruby/qt bindings that are on RAA, from
Nobuyuki Horie?

Oh, and WTHI SMOKE ?

 

[Richard Dale]

il Thu, 30 Oct 2003 04:03:23 +0000, Richard Dale


I wonder: does this bindings works in any environment supported from
Qt?
I mean: can I write cross platform stuff with it?

Yes it should be possible, although I've only tried it on Linux so far.

and, how this relates with the Ruby/qt bindings that are on RAA, from
Nobuyuki Horie?

It's a completely different project - so I called mine QtRuby rather than
Ruby/Qt so there wouldn't be confusion between them. I don't know if that
project is still active - I couldn't find anything recent when I searched
Google.

Oh, and WTHI SMOKE ?

Indeed! It shares that same runtime with the PerlQt bindings project in the
library 'libsmokeqt.so'. If you configure kdebindings with a
'--with-smoke=kde' option it will build 'libsmokekde.so' to include the
classes from both the Qt and KDE headers.

There will be a another extension for KDE ruby programming, which will be a
superset of QtRuby api to include over 400 kde classes too. Meanwhile, if
you want to try kde ruby programming, you can just link the Qt extension to
the KDE Smoke library rather than the Qt one.

-- Richard

 

[James Britt]

Hi all,

I just read a neat article at IBM DeveloperWorks:

http://www-106.ibm.com/developerworks/web/library/wa-appmozx/?ca=dgr-lnxw02MozillaXMLApplets

But over-all, I think I like the idea of using XML for the GUI structure
and a programming language for the behaviour. This strikes me as a good
combination (but then again, I am not a very experienced programmer).

You may want to scope out the discussion about XUL and XAML (Microsoft's
XML-GUI language) on the xml-dev mailing list [0].

I found these comments particularly interesting:

"Hmm. To me it looks like XAML is considerably better designed than XUL.
This is very much like the difference between SVG and XSL-FO that I
wrote about in Item 11 of Effective XML, Make structure explicit through
markup. XUL is using a double syntax with embedded CSS. The syntax
should be XML, even if the semantics come from CSS. XAML and XSL-FO get
this right. XUL and SVG get this wrong. I've now put that chapter
online: http://www.cafeconleche.org/books/effectivexml/chapters/11.html"
-- Elliotte Rusty Harold


"I expect to see XML based languages like perhaps XUL to
be included in gnome or KDE. However, if Gnome and KDE use the same
language as Microsoft, the impact would even be greater and would
probably put some W3C technologies out of the picture. Strategically,
both KDE and Gnome should also 'embrace and expand' to gain some market
share. I doubt they will do it since the will to win is less strong than
the will to 'be against the devil empire'. Nonetheless, if by some luck,
leaders of these communities learned some strategic tricks and want to
win some market share, the 'embrace and expand' strategy can potentially
transform the web as we know it. "
-- Didier PH Martin


James Britt


[0] http://lists.xml.org/archives/xml-dev/200310/msg00801.html

 

[Zachary P. Landau]

But that's not really a big deal. What I find less exciting about=20
GLADE/libglade is that the XML is big and ugly compared to the amount of= =20
information contained therein (for instance, Mutoh's simple editor exampl= e=20
at ruby-GNOME2: the XML for his GUI is 824 lines long, but only describes= =20
one small application with three menus, ~20 menu items, one toolbar, a=20
text buffer, and a status bar-- his Ruby script to support the GUI is onl= y=20
279 lines long and includes some very nice undo/redo and find/replace=20
functionality). I want an XML/GUI language that I can read and write=20
without a tool like GLADE. I certainly don't want to wade through 800+=20
lines of XML to edit a very small application.

Probably the bigger problem with libglade XML is that it is for GTK
specifically. It references GTK widget names and attributes, and uses
GTK layouts. It'd take a lot of weird converting to get it to be more
universal.

--=20
Zachary P. Landau <[email protected]>
GPG: gpg --recv-key 0x24E5AD99 | http://kapheine.hypa.net/kapheine.asc



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/oohTCwWyMCTlrZkRAqt8AJ9rDI/EkNXtHU3ODsEcoVqsTdHDBgCeM3Wg
hZ4jPhqceiApeGAXrgXQtCY=
=a1qR
-----END PGP SIGNATURE-----

 

[Eric Hodel]

You may want to scope out the discussion about XUL and XAML (Microsoft's= =20
XML-GUI language) on the xml-dev mailing list [0].
=20
I found these comments particularly interesting:
=20
"Hmm. To me it looks like XAML is considerably better designed than XUL.= =20
This is very much like the difference between SVG and XSL-FO that I=20
wrote about in Item 11 of Effective XML, Make structure explicit through= =20
markup. XUL is using a double syntax with embedded CSS. The syntax=20
should be XML, even if the semantics come from CSS. XAML and XSL-FO get= =20
this right. XUL and SVG get this wrong. I've now put that chapter=20
online: http://www.cafeconleche.org/books/effectivexml/chapters/11.html"
-- Elliotte Rusty Harold

A benefit of XUL is that it is similar enough to HTML that anybody who
has written a web page can probably understand a XUL page.

XAML isn't XML as a user interface, it is a definition for a UI that
is then compiled. This requires the web-savvy to learn new ways of
thinking.

XAML isn't targetting the web-savvy, its targetting the .NET-savvy.
XUL is targetting the web-savvy, with XML, DOM, and CSS all available
at runtime. XAML will have its own implementation of the same
functionality that will be easily digestible by someone familiar with
=2ENET.

"I expect to see XML based languages like perhaps XUL to
be included in gnome or KDE. However, if Gnome and KDE use the same
language as Microsoft, the impact would even be greater and would
probably put some W3C technologies out of the picture. Strategically,
both KDE and Gnome should also 'embrace and expand' to gain some market
share. I doubt they will do it since the will to win is less strong than
the will to 'be against the devil empire'. Nonetheless, if by some luck,
leaders of these communities learned some strategic tricks and want to
win some market share, the 'embrace and expand' strategy can potentially
transform the web as we know it. "
-- Didier PH Martin

If you want to capture programmers who are web app writers, it would
make more sense to use XUL, because it uses many technologies that
web app writers are familiar with. In either case, building a UI out of
XML makes sense, because so many people are familiar with HTML, but XAML
may find itself much harder to sell if it isn't familar to the
web-centric.

http://www.xulplanet.com/ndeakin/archive/2003/10/29/ was a basis for
this email.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/oqx1MypVHHlsnwQRAvclAKDnfqhQD9cWDdZ7sxdcxKL5pU5yGwCfdT+8
kVlcTvsHcUdoF+LYCrLtlbI=
=lijN
-----END PGP SIGNATURE-----

 

[James Britt]

A benefit of XUL is that it is similar enough to HTML that anybody who
has written a web page can probably understand a XUL page.

XAML isn't XML as a user interface, it is a definition for a UI that
is then compiled. This requires the web-savvy to learn new ways of
thinking.

XAML isn't targetting the web-savvy, its targetting the .NET-savvy.
XUL is targetting the web-savvy, with XML, DOM, and CSS all available
at runtime. XAML will have its own implementation of the same
functionality that will be easily digestible by someone familiar with
=2ENET.

I'm not so familiar with either to say which would be the better choice
for any set of problems, but I'm skeptical of picking a technology
because it's easier for a class of potential users to get started.
(Some cursory review of XAML suggests that those familar with more
traditonal application GUI design may find it fairly easy, as the
elements appear to map to abstract widgets.)

Better to see which GUI markup offers the best design and "bang for the
buck" for the long run, after the learning curve is forgotten.

Whether such a tool for Ruby should be selected for its appeal to the
"web savvy" is a different matter.


James Britt