SoC :: Ribbons :: Weekly Report #7

15 07 2007


This week has been a bug hunting week. Indeed, the following bugs have been found and fixed:

  1. ToolPack does not correctly display multiple buttons. Fixed!
  2. The expand button is displayed on top of the label. Fixed!
  3. Could not change the image or label of a button. Fixed!
  4. The visible property of widgets is ignored in Button, RibbonGroup, ToolPack. Fixed!
  5. The SyntheticWindow sends bad synthetic events to window-less widgets. Fixed!
  6. The padding was not handled correctly by the layout routine. Fixed!
  7. The expand button does not fire the right event. Fixed!

In addition, several enhancements have been commited:

  1. Better button design, but could be enhanced further.
  2. Updated sample to expose functionalities of the expand button.

Finally, I have documented the public API.

Thanks to this work, the code base is now a lot more solid (shall I dare, rock solid?). Next week, I plan to add the ability to add a drop down menu to buttons; and to get multiple rows of buttons in a single RibbonGroup. The last one will required some effort to find the right API to implement this in Gtk.

After this, the project will be ready to get support for Galleries. I hope to start the development of this in 1 to 1.5 week.





3 responses

17 07 2007

Hi, just found out about your project, and looks very promising. Just a few questions.

Can we expect your implementations to run interfaces defined by the XML language spec that also runs the original RibbonX ?

Also is there any chance that I can run the ribbon on windows right now ? Should I try and/or do you think I can help/feedback with that ?

17 07 2007

I do not think that supporting RibbonX would be a good idea for two reasons:

1) If you want to set the content of the ribbon in this project, you should do that using glade or something like that. Indeed, it would be strange to have a language X for ribbon, language Y for blabla, and language Z for blablabla.
2) The objective of this project is not to copycat the API of Microsoft. I think that Microsoft has used several common concepts such as tabs, tool bars, drop down menus, and frames, to create a new way to organize available options. The combination is nice enough to be used. On the other end, I do not see the point at stealing the API of Microsoft.

Finally, I’m afraid that the project is still in early stage. The short-term objective is to get features implemented. Afterwards, the support of Windows could be checked.

17 07 2007

Actually, I’ve been following the Ribbon quite closely and can certify that the reason why a language was introduced was not just the fun of it but rather a great deal of research that went into describing user interfaces based on intentions and letting the UI figure out how to display them. This in contrast to figuring out that sth should be presented into a drop down yourself. We can expect new interfaces to live off the ribbon’s language spec.

I understand your concern about implementing the native Ribbon api but it’s not really valid. Take for example the implementation of libraries in the .net framework that are not submitted to the ECMA such as winforms or the moonlight project.

Keep up the good work 🙂 You have a great load to handle.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: