« Happy birthday! | Main | Bind them all! »

The first vala browser.

Vala is a C# like language compiler that translate the source code into C. It's intended to provide a higher level language to GLib/GObject/Gtk+ and friends.

Today, in more or less one hour, I've been able to write a GtkMozEmbed binding for vala. Note that I haven't write a binding ever in my life before and despite that, it's been pretty straightforward.

I've also wrote a small app to show the browser, and there we go:

Vala goes online!

To get the source code of what I did, take a look at #463438's attachments.

My conclusion here is that vala is really close to become a serious option to write platform libraries and applications instead of C within the Desktop, you get the best of both worlds, a high level language, and the C (non VM) performance, portability and easy of bind from other languages, and since vala adds some explicit object semantic, write bindings from vala code could be even more straightforward.

Another problem that it potentially solves is the pain of reuse code from others, most people tend to no inherit in GObject since it involves lots of annoying copypaste, which drive us to better integration and a better reutilization of the code.

Congrats to Jürg Billeter for such a bold and simplified approach.

Oh, by the way, did I say that this approach is binding friendly already? ;-)

Comments

Very nice arc! I'm trilled to see people actually adopting Vala.

Hey!, I keep hearing vala is so great i want to learn it =)... problem is I don't really know/understand anything about gobject and gtk class names and such, still neat stuff.
btw, I wanted to write this comment in case somebody that can do it... does it, it would the the greatest thing ever to have vala bindings for clutter.

@pvanhoof:

Yes, let's kick some VM out of our desktop X-)

@Phrodo_00:

That's the beauty of vala, it makes GObject very natural because vala tries to wrap all the gobject api into the language. Just go to the wiki page and try to build an example.

About the clutter binding... I can give it a try.

Hi,

Thanks Alberto for this yet another Gnome bleeding edge technology test. The first link is wrong, it point to live.gnome.org instead of http://live.gnome.org/Vala .

I'm waiting for debian packaging of vala and Anjuta integration !

Regards,
Étienne.

Great work Alberto, Vala is really a great idea. I'm also working on a Hildon binding (in my spare time :-\) the Vala file is already done, but the generator files need some work.

@bersace:
A hot Debian package for you:
http://www.cin.ufpe.br/~mls/vala_0.1.2-1_i386.deb
:D

And I put some more (simple) Vala examples here:
http://setanta-labs.googlecode.com/svn/trunk/vala-demo/

So Vala is the new Cfront?

I don't really get the point of this thing: I've been writing fast high level Gtk+ code for months without the need of creating an entire new language. There is a simple standard way: C++.

@Giacomo:

That's exactly why I said two times binding friendly.

C++ is not portable across different compilers, as an example, porting inkscape to Solaris is a pain because Inkscape use gcc specific code.

Just look at how many stable and maintained bindings for Gtk+ are and how many stable and maintained bindings for Qt are. With C is just easier.

On the other hand, Vala is using GLib and GObject to create its standard library, which more make a more natural way to write GObject code, in C++ you would always choose the STL because is what everyone uses in C++.

There are some other advantages too, and also, the Vala language is quite more modern and simpler than C++.

Cc++ lacks the RAD and elegance of modern languages like vala. C++ may be powerful stuff but its quite difficult to wield that power too.

Im not slating c++ here - if you know it and are comfortable with it then carry on using it.

If you dont know it, c++ has a pretty steep learning curve and modern languages are by and large much easier to learn and wield effectively

For platform stuff, c++ would have to manually create gobject interfaces for all exposed classes so it would be more work too than something like vala which uses gobject natively.

@Jamie:

You have nailed the spot here. C++ is too complex for most of the task that we want to achieve in the gnome platform. It's not because it's a bad language/platform, it just doesn't feet with our needs.

At first I really did not understand what is the point of Vala. Then I thought of the options for developing many things.
- Banging your head to a wall using C (not productive enough)
- Using Language bindings for some Python etc (performance issues, being 3rd party citizens)
- Using Mono/C# (some zealots hate it a lot just because Microsoft is the source of all evil)
- ...

Then there's Vala. I hope it really picks up and people will start heavily developing it and using it because it has got a promise to make developing Gnome applications a magnitude more efficient and pleasant.

Btw, webkit support would rock even more.

Hmm... you don't suppose you could make bindings so that Epiphany extensions could be written in Vala? :)

@Giacomo:
All the higher languages (C++, C#, python...) have a couple of disadvantages:
* Runtime (execution) overhead.
* Extra libraries/runtimes which are only needed for the sake of the language.
And yes, when you take into account that gnome is also used on embedded platforms, the runtime overhead and extra space taken by those libraries/runtimes *does* matter, especially when you're developping a library.
Also, with direct relation to C++, there is the extra issue of ABI instability. Look at ubuntu for example (but this goes for every distro out there):
root@Vertex:~# apt-cache search libstdc++ | grep '^libstdc++' | sort
libstdc++2.10-dbg - The GNU stdc++ library (debugging files)
libstdc++2.10-dev - The GNU stdc++ library (development files)
libstdc++2.10-glibc2.2 - The GNU stdc++ library
libstdc++5 - The GNU Standard C++ Library v3
libstdc++5-3.3-dbg - The GNU Standard C++ Library v3 (debugging files)
libstdc++5-3.3-dev - The GNU Standard C++ Library v3 (development files)
libstdc++5-3.3-doc - The GNU Standard C++ Library v3 (documentation files)
libstdc++5-3.3-pic - The GNU Standard C++ Library v3 (shared library subset kit)
libstdc++6 - The GNU Standard C++ Library v3
libstdc++6-4.1-dbg - The GNU Standard C++ Library v3 (debugging files)
libstdc++6-4.1-dev - The GNU Standard C++ Library v3 (development files)
libstdc++6-4.1-doc - The GNU Standard C++ Library v3 (documentation files)
libstdc++6-4.1-pic - The GNU Standard C++ Library v3 (shared library subset kit)
libstdc++6-4.2-dbg - The GNU Standard C++ Library v3 (debugging files)
libstdc++6-4.2-dev - The GNU Standard C++ Library v3 (development files)
libstdc++6-4.2-doc - The GNU Standard C++ Library v3 (documentation files)
libstdc++6-4.2-pic - The GNU Standard C++ Library v3 (shared library subset kit)
libstdc++6-dbg - The GNU Standard C++ Library v3 (debugging files)
libstdc++6-dev - The GNU Standard C++ Library v3 (development files)
libstdc++6-doc - The GNU Standard C++ Library v3 (documentation files)
libstdc++6-pic - The GNU Standard C++ Library v3 (shared library subset kit)
Which basically means that with every new release of gcc you have to recompile every single c++ library and program in the distro.
@ReinoutS:
Vala gets preprocessed to C, which gets compiled. Ergo bindings are not necessary.

Hrmm that last point came across the wrong way :)
What I meant is: applications like gedit and epiphany don't need special support for extensions written in Vala, since Vala gets preprocessed to C, but you do of course need to bind the gedit and epiphany API's in Vala.

Having the extra layer C++-wrapping-GObject, like for example gtkmm, might even be less efficient than Vala's approach.

Having the extra layer C++-wrapping-GObject, like for example gtkmm, might even be less efficient than Vala's approach.

lol, this shows up on p.g.o every once in a time :)

anyway, good ad for the great vala!

OK, Vala's just great - there's just no downsides, only upsides.

Well, there's one: toolchain maturity.
- the language is still a bit in flux
- integration in existing build systems
- bugfixes I'm sure
- etc

I really hope the Gnome community really puts its shoulders under this one, asap. I'll be rejoicing as soon as some Vala source becomes part of Gnome. Maybe Vala should even distributed as a companion to the GLib project?

Anyway, great stuff.

Surely you mean the third or fourth Vala web browser :D

Just kidding but you should investigate and find out why it's been aggregated like three or four times on Planets already.

Toolchain maturity is one downside, but I can think of many others:
- documentation (how many Vala books are there? uh, and the online Vala reference is mostly empty :-)
- support (how many people in my town know Vala?)
- power (does Vala offer any high-level features other than GC? what will I be giving up compared to my other HLLs?)
- performance (everybody "knows" C is fast, but if I really need speed, would I rather spend my day optimizing 2 independent layers of compilers, or one? if the manual isn't even done, I suspect the performance implications of specific Vala features aren't well-understood yet)

The compile-to-C method is great if you're prototyping a new language and need it to be simple and portable, but through experience with this approach on other platforms, it doesn't scale well. You end up with the worst of both worlds: it's hard to support high-level features, and also compile to C that looks sane (e.g., for debugging) and/or performs well.

Sorry, didn't mean to sound so negative there. I think it's a neat little project, and I wish the Vala people luck. I just don't quite see what niche it aims to fill, and experience tells me this is not a long-term solution.

Alberto,
Thanks for the little app. I also found a WebKit example, and wrote a little html viewer with toolbar buttons. I wrote it in Genie, the alternative Python-like syntax that the valac compiler supports.

My blog posts:
http://puppylinux.com/blog/?viewDetailed=00596
http://puppylinux.com/blog/?viewDetailed=00595

One thing I'm stuck on is how to grey-out the forward/back buttons as-appropriate -- I made a method for it but don't know how to call it when the window changes.

I get error in Ubuntu 8.10: gtkembedmoz/gtkmozembed.h: No such file or directory

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment