Thoughts about Ribbon Sharp, and GNOME.

20 10 2007

Hi,

It has been a while since I last blogged. I think that I should first answer to a few obvious question:

What need to be completed in Ribbon Sharp?

  1. Support for keyboard shortcuts.
  2. Right-to-left support.
  3. Windows support (it has never been tested).

When will I do that?

Now that I have a Master in Computer Science, I have just began a Master in Actuary. Consequently, I have been studying mathematics a lot for the last month to catch my lateness. (One may wonder why I started this. In fact, software development is an art for me. The architecture, algorithms, and visual appearance, are all important stuff. I don’t want to support some COBOL, C++, or badly designed Java program. With Actuary I hope to make a mix with my computer skills that I will enjoy.)

I will try to complete Ribbon Sharp as soon as possible. But I have no idea when that will happen.

I would also like to give my impression and my feeling about my experience regarding the GNOME desktop as an experienced developer making its first steps in the GNOME world. I think that the main problem with GNOME for a new developer, is that programming in OO in C using Gtk+, is a bit like programming in COBOL. I love C, and I’m impressed that people managed to bring an OO framework for it. But compared to real OO languages, it has a little smell. I consider C/Gtk+ more as an intermediate language, which make it possible to bring many computer languages together (through bindings). That’s why I really appreciate the work of hackers behind Vala.

Also, it would be damn interesting to make a statistical analysis of contributions made to GNOME and KDE. Both communities seem to be (more or less) on par regarding their workmanship. But I suspect that GNOME gets more corporate developers, while KDE gets more “garage” developers. Indeed, Qt offers X11, Windows, Mac OS X support (and even more!), and a “true” OO environment (even if C++ has a strong “smell”). But forces developers to use the GPL to develop applications (or to pay a license). Seriously, even on a proprietary platform such a Windows I have the freedom to choose the license I like! On the other side, Gtk+ offers the license freedom which is more important for corporate users, but lacks Mac OS X support, (and nice programming language as previously mentioned).

My hope for GNOME 3, would be to base it on Windows Presentation Foundation and Mono. C and C++ guys could jump in the C# wagon, Python guys to IronPython, and Ruby guys to IronRuby. Just, remember the work done by the Moonlight team to build some desktop widgets. They did a beautiful work in a fast and efficient way! However, this will likely never happen because:

  1. Free developers will not be too happy to use a framework whose API is controlled by a proprietary company. On the other side, I do not know if Qt/Trolltech is much different.
  2. Mono may too heavy for use on some handled devices, but I’m sure that with some optimizations it should be possible, look at the Compact .NET Framework (but instead of shipping a diet framework, individual classes should be loaded on demand).
  3. There will always be some developers and customers who will fear the lawyers of big brother. (but in the end, after much fear about the kernel and Mono, recent strikes target the GUI of GNU/Linux).
  4. Active Python contributors may not be too pleased to using a third-party Python to develop GUIs.

Well, another possibility would be to base it on the excellent D programming language. But D has a serious problem regarding its class library. The official once (phobos) is old-school, while the unofficial (tango) can only be installed using a hack (replacing the original phobos library file).
My objective is to blame or hurt anyone, every community cited in this post does a fantastic job! I know how hard it can be to develop and make evolve large software projects. I think that constructive critics are always a good thing.
Laurent Debacker.


Actions

Information

6 responses

22 10 2007
Paul

just a note… I assume you know all this… but for those that don’t.

The reason that compact framework has fewer classes (amoungst other things) is to reduce the size of the image that is stored in flash.

.NET currently loads assemblies on demand not individual classes. There are many good (design) reasons why individual classes arn’t loaded on demand. As far as I understand Java loades individual classes on demand.

22 10 2007
knocte

Wonderful post!

And I agree with you on most terms.

I have added a link to your post in my blog, if you don’t mind.

22 10 2007
debackerl

> just a note… I assume you know all this… but for those that don’t.
Indeed, I did :p

> The reason that compact framework has fewer classes (amoungst other things) is to reduce the size of the image that is stored in flash.
Yes. One problem arise when most applications tends to reinvent the wheel (or copy and paste the code of the complete framework) to use all features they require. If you have a dozen applications in this case, you will actualy waste space because each application will have its “local copy” of the required features. It is easy to see how important it is to judge whether a given class will be often used on a mobile platform or not.

> .NET currently loads assemblies on demand not individual classes. There are many good (design) reasons why individual classes arn’t loaded on demand. As far as I understand Java loades individual classes on demand.
Yes. I refered to this method as a trade off for (handleld) devices with few memory, but sufficient disk space. Loading the complete framework on a device with only 32MB is questionable, but the performance penalty on a desktop is maybe not worth the memory it will save.

> Wonderful post!
> And I agree with you on most terms.
Thanks :)

22 10 2007
I don't do the foxtrot, I'm just foxxtrot

GTK+ and Object Oriented Programming in C – Not worthwhile?

I was reading the Monologue this morning, and a blog post from Laurent Debacker came across the wire. He was writing about the Ribbon Sharp library he’s been working on, and his own feelings about the GNOME project from a…

23 10 2007
Rodrigoimplementations

I’m wondering why you didn’t implement ribbons in gtk instead of doing it in gtk#. By implementing ribbons in gtk, all the projects and bindings based on gtk would benefit for it. Let’s think that gtk# ribbons become extremely popular and all the future gtk# applications will be based on a ribbons interface. Eventually some guy will implement ribbons in gtk and the C / C++ / Python / Ruby, etc. bindings will benefit, and the C# implementation will also benefit, even if the original implementation is replaced with the upstream implementation.

That’s all, just a question. By the way, it looks great (sadly, I’m a Python programmer)

Thanks

23 10 2007
debackerl

I did it in Mono because the Mono project was interested in the development of a Gtk# ribbon for the Summer of Code. In addition, we were not allowed to code in C (except if constrained to do so).

Your question is also interesting in the case of my post. Currently, ‘only’ libraries coded in C, can be used in all languages used by Mono. If I’m right a Python GNOME library could not be used by Mono, and a Mono GNOME library could not be used by ‘standard’ Python. This is indeed sad, because only a part of the GNOME community (C lovers) can build libraries to be used by the whole community. Now let’s enter a Mono-based GNOME (all languages are executed in Mono). The only constraint is that statically-typed languages can only used libraries coded in a statically-typed language, while dynamically-typed languages could use any library. The former constraint is even not entirely true, because you can use a dynamically-typed language to implement a static (abstract) API, and use the library in a statically-typed language through the static API.

By the way, I think honestly that my library could be implemented twice as fast using the Windows Presentation Foundation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow

Get every new post delivered to your Inbox.

%d bloggers like this: