Summer of Code Summary: Gtk Sharp Ribbon

26 08 2008


I have recorded a screencast to showcase the lastest version of Gtk Sharp Ribbon. It is available here (edit: this an OGG video, about 500KB)

The objective of this year was to comply to the official “2007 Microsoft(r) Office Fluent(tm) User Interface Design Guidelines”.

I did my best, while taking care of my actuary studies which was more difficult than I thought (the studies, not the project). In addition, the guidelines are of course not designed with Gtk+ in mind. Consequently, the path was rather rocky. But I think that the result is rather fine for now, and could become really great if some actual applications would start using it, giving some real use cases.

You can read more about the current state at

The code is available in the /trunk/gtk-sharp-ribbon directory of Mono’s SVN repository.

Laurent Debacker


Choosing a distro for SoC, Part 1

25 04 2008

Since I have been selected by Mono for the Summer of Code 2008 to continue my work on the Ribbon library, I wanted to setup an up-to-date Linux install to develop with.

Since Ubuntu 8.04 was released a few days ago, I thought it would be a great opportunity. Well… samba mounting still does not work. Indeed, the option is available in the mounting menu of GNOME, but apparently no program is registered to handle smb://. Mmkay.. so I wanted to connect on Internet to search for workarounds, no Internet! By default my network interface was configured in roaming mode, and an IP address was assigned. In addition, all routes seemed to be configured correctly, but nothing. So, I had to make a manual configuration, and configure it to use DHCP. And it worked! I’m happy that it works, but if roaming didn’t, why the hell does the manual mode works?

So, voilà. It is not Microsoft, it is Cannonical. It is not Windows Vista, it is Ubuntu 8.04. But the principle is the same: release on time, no matter what! Just look at and you will notice that the error is old and well known. Of course it is possible that interoperability between Linux and Windows is not that important, despite all lawsuits against Microsoft to obtain documentation over their protocols 😀

EDIT: Except this, the new version is way better than previous ones, but this is well covered by reviews on the web, so I only report about what differ between my experience and such reviews.

Future of the Ribbon library, performance of, and more…

3 02 2008


It has been a long time since my last post, but I have had an exam period of 6 weeks. I will be free monday 😀

Regarding the Ribbon Sharp library, we are trying to distinguih ourself from other vendors. In addition, we would like to find a new name for the project. So if you have a nice idea, post it as a comment!!

Regarding the development, it is now possible to place the title of a group at the left, right, or top in addition to the original bottom position. Personally, I think that the left position is great because it helps make the overall bar thinner (and we tend to have wide screens nowadays). You can see the result below:


As you can see, the expansion button take a lot of space in such a layout. I think we should put it at the opposite side of the group whenever the title is placed at the left or right. I have also tried to understand how key bindings work with Gtk#. As far as I have understood, I had to give a name for the signals that can be activated through a key. Consequently, I did so for most functionalities of the library. But I have not tested that part yet.

The great news is that Paweł ‘X4lldux’ Drygas got the library to work under Windows, and fixed a few bugs. I should get its patch soon.

Of course you may wonder why I have been so long, or why I have not produced more code in such a long period! The answer is that I have also produced 5000 lines of C# for my own, new, object database. I find that project much more challenging and fun to hack. It should be out for the summer. In addition, I will develop for the Android challenge during February.

Finally, I recently quit my hoster due to bad service. I’m now at linode, and had to use Mono to host the web site. Consequently, I did a few benchmark to test performance and stability. The objective of the benchmark is to test the memory leaks, and responsiveness. Consequently, the page is a webhandler (.ashx), that writes back “Hello Word” followed by the Http Host specified by the request object. Here are the results:

In an InnoBox Virtual Machine running on my Intel E6400, using ab -c 100 -n 50000 (100 concurrent connections, 50000 requests) :

  • fastcgi-mono-server2 /socket=unix /multiplex=True, using nginx
    RSS=290MB, 175 req/s, 33 failed requests
  • fastcgi-mono-server2 /socket=tcp /multiplex=True, using nginx
    RSS=274MB, 161 req/s, 296 failed requests
  • xsp2
    RSS=25.5MB, 373 req/s, 0 failed requests

Cleary fastcgi has memory leaks, and performance troubles. Of course, fastcgi is still young.

And now on my Intel Pentium 4 2.7 Ghz:

  • mod_mono2
    372 req/s, 0 failed, 2.242 MiB transfered
  • xsp2
    465 req/s, 0 failed, 1.714 MiB transfered
  • nginx+mod_wsgi (python)
    3610 req/s, 0 failed, 1.7 MiB transfered

Conclusion? We should try to throw the stack out of the window first, and modify the code of mod_wsgi to host mono instead of python, calling a simple method similar to wsgi. If the performance is on par with python, we could then bind that to the, and check performance. mod_wsgi is released under the MIT license, so no trouble there. For now, I use nginx which proxifies requests to asmx, ashx, and aspx files to an xsp2 server.

Wow, I do not blog often, but when do, it is worth a thousand pages.

EDIT: The problem with nginx+mod_wsgi is that it is not multi threaded, but multi process. It is likely due to the fact that nginx is event-based.


Thoughts about Ribbon Sharp, and GNOME.

20 10 2007


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.

Ribbons for MonoDevelop

30 08 2007

Update : This post is now formated correctly.

Wow, it is quite impressing that Miguel proposed to use the ribbon in MonoDevelop in his last post. When I started the project, I looked for ways to test my ribbon. One of my idea was also to redesign MonoDevelop, but I started with a tiny sample because it was much simpler 😀

Redesigning MonoDevelop remained one of my secret target, but it never happened due to lack of time or caffeine…

Below is the content of ribbons I imaginated 2-3 months ago:

+Version Control
Test Units
++Test class
++Test project
++Test solution
++Compability check
++Deploy to
++Configure targets
+Version Control
++Build patch

I did also thought of some contextual ribbons:

Source code
++Print Preview
++Go to Line
++Go to Matching Bracket
++Clear all
++Change namespace
++Move up
++Move down

I am sure that this is not optimal, but I think it is not too bad. The problem is that plugins would also have to use the ribbon. Consequently, there is a lot of code to update.

SoC :: Ribbons :: Summary

25 08 2007


My previous post covered my last week of development and my feeling of the SoC program. Now, I think it would be a good idea to write a summary. The objective of my project was to implement the ribbon paradigm for Gtk# using managed code only. Since this is a GU library, a tiny sample application had to be created to show the implemented features.

During the SoC program, I have implemented the following classes:

  • Ribbon: This is the main ribbon, which displays tabs and pages. This is similar to a notebook, but more using the Ribbon way of doing (drawing) things. Each page has a label widget placed in the corresponding tab, and a widget displayed as the page.
  • RibbonGroup: This is more like a decoration. It draws a frame around its child, and a label. It may also display a special button, next to the label, to ‘expand’ the group. Expanding a group means displaying a window with more options.
  • Gallery: This is used to display a table of tiles. The user has the ability to select a tile. The developer may draw whatever he want in the tile.
  • GalleryPopupWindow: This is a popup window which is really convenient to display more tiles than it would be possible using the Gallery. This popup is opened by clicking on a particular button of the Gallery. The developer does not need to care about this popup.
  • Button: I required a button that could work in three mode: click only, drop down menu only, or click and separate drop down menu. In addition I had to be able to easily change its design (ask it not to draw its background when the mouse is not over).
  • ToggleButton: Its visual appearance is similar to the button described above, except that it is a toggle button.
  • BaseButton: Since Button and ToggleButton share a lot of common behavior, a class had to be created to contain that behavior.
  • ToolPack: This is used to pack several Button’s or ToggleButton’s together in a single (visual) block. It is only used to visual purposes.
  • FlowLayoutContainer: This container layouts its children using a flow layout. It has not be throughly tested, and the code should be optimized to handle cases where the heigh is fixed better.
  • ToolBox: This is similar to FlowLayoutContainer, except that all rows have the same height, and children are scaled to fit the height of the row.
  • Theme: It is used to draw the appearance of all widgets above. The objective is to be able to change the theme used by a widget to customize the appearance of the application.
  • ColorScheme: It is supposed to represents some variants (dark, bright, etc) of a color (bluish, gray, black theme).

The documentation of the classes is included in the classes themselves using the XML syntax because

  1. It is more convenient for me since I can update the documentation whenever I change the API.
  2. There is less files, and consequently, the structures of folders is simpler.
  3. Many developers are used to it since it is the standard way of documenting code.
  4. Newcomer can read the code, and the corresponding documentation in a single window, instead of switching between multiple windows.

In addition, I had to imagine a special mechanism to work with windowless widgets easily. Indeed, next-gen widgets needs to be transparent because they have all kind of shapes, shadows, etc. Gtk windowed widgets can only enable this if the desktop supports compositing. Some may suggests using compositing where available, and using opaque widgets else. However, this is not an option because I would have to design two themes. Consequently, the resulting applications would not have the same style depending on the computer it runs on. It would look rather awkward to the end-user I think. Therefore, I have used windowless widgets. The disadvantages of such widgets is that the only event that is propagated is expose. That event is used to tell the widget to render its content. Thus, I have built a special window which propagates other events to windowless widgets. This mechanism is implemented in the SyntheticWindow class.

In addition to the transparency problem with Gtk, I have also experienced troubles because Gtk does not seem to support size negotiations between a container in its children.

I think that I have implemented most features required to use a ribbon, and using the Gtk phylosophy.  On the other side, I would have liked to provide a more complete sample. Nevertheless, it presents almost all features of my library. It is now up to you to build a usefull application using it.

Remember that the code can be obtained at

SoC :: Ribbons :: Weekly Report #12

19 08 2007


The pencil is down, tomorrow is the official commit date for Summer of Code.

This week has been pretty productive. Since last week, the following stuff have been completed:

  • The gallery is now completed.
  • Popup gallery, a gallery can be expanded in a popup window. On the other side, I could not find a way to detect when the mouse click on another window in order to close the popup. Consequently, the popup is closed as soon as a tile is clicked.
  • I have implemented a toggle button, and created a BaseButton which is used to share methods common to both ToggleButton and Button.
  • ToolBox and FlowLayoutContainer have been completed. The former is used to layout child widgets across several rows, but all widgets receives the same height. This height corresponds to the height of the tallest child. The FlowLayoutContainer does not have that limitation, but is less space efficient when the height of the container is fixed (using HeightRequest).
  • The theme of Button has been greatly improved.
  • Several bug fixes.

I would like to say that the Summer of Code has been a fantastic experience. I would have liked to build a better sample application, but I have experimented more difficulties than expected while developing the library.

For those who worry about the platform compatibility, I have only tested it on two development desktops on Arch Linux, Linux 2.6, GNOME 2.18, One has Beryl, while the other does not.

I hope that I have answered to all questions in a meaningful way during the development. I know that I have not communicated much, except through weekly reports, but from my past experience with open source, I know that the Read The F****** Manual is a really important rule to let developers work instead of answering to dumb questions.

In the screencast below, you may notice flickering in the selected tile. I think it is a bug in Cairo because by replacing the following lines in Ribbon\Theme.cs:

LinearGradient grad = new LinearGradient (bodyAllocation.X, bodyAllocation.Y, bodyAllocation.X, bodyAllocation.Y + bodyAllocation.Height);
grad.AddColorStop (0.00, new Color (0.9922, 0.7373, 0.4353));
grad.AddColorStop (0.27, new Color (0.9961, 0.8039, 0.5569));
grad.AddColorStop (0.33, new Color (0.9961, 0.7255, 0.4078));
grad.AddColorStop (1.00, new Color (0.9843, 0.8980, 0.6313));
cr.Pattern = grad;
cr.Rectangle (bodyAllocation);
cr.Fill ();


cr.Color = new Color (0.99, 0.80, 0.50);
cr.Rectangle (bodyAllocation);
cr.Fill ();

The flickering vanishes.

A screenshot of the latest sample can be found at Ribbons-20070819

A screencast is available at

It is time to relax a little bit now 😀

Laurent Debacker.