“Implement a Gtk# widget that brings the Office-like ribbons to Gtk#. Focus is on managed widgets, not in C-based widgets.” — Miguel de Icaza, Mono Summer of Code ideas (emphasis mine).
Go team. 
It’s also pretty sad that they’re pursuing data binding at the Gtk# level, rather than helping deliver it to all users of GTK+. Let’s strengthen our platform message, dudes, not splinter it.
17 Comments
It really sucks to see Summer of Code being abused for playing politics to split the community.
That would so be a great project if it was in C, although I bet Microsoft have some pesky patents on various bits of that UI in the USA which would have to be avoided.
I think the goal is to finish it before summer is over. I’d imagine doing that in crusty old C would be a bit difficult.
I doubt that it is intended to splinter the community. I’m not the most experienced in regards to the GTK# bindings but I’m willing to bet that they don’t support automatic garbage collection (a similar problem which is shared with Java’s SWT). Thus, if this is correct, one could argue that the entire purpose of using C# is rendered moot.
While it would be nice to have any work that is done in regards to GTK+ available to the entire development community, I can understand why they would want to go this route.
Hello,
I feel that a C# based API for a Ribbons API would give us a lot of flexibilty in its design and implementation and allow us to exploit a lot of what C#/CLR has to offer and after all it is part of the Mono Summer of Code effort.
As for data binding, it is something that every .NET developer expects and we not have. This is also a case where the databinding in C# is probably simpler and would integrate better with the language than a lower-level binding (for example, we can do LINQ with System.Data).
Miguel
We need higher level languages that can expose C bindings, desperately.
C, as a language, is holding back our productivity.
Miguel, the main problem is that the ribbon will likely be implemented in Gtk+ eventually.
So it’s likely that Mono will either have to ignore the Gtk+ ribbon or implement both or re-implement the Gtk# ribbon in terms of the Gtk+ ribbon. In the first case, Gtk# loses out and reduces the portability of Gtk+ code to Gtk#. In the second case, you end up with API confusion. And in the last case, you end up doing the work twice and end up trying to force-fit the Gtk+ version to be semantically equivalent to the Gtk# version which as you know from your previous WinForms port, might not yield the best results.
OTOH, if the Gtk+ version is created first, Mono (being the first user) could ensure that it allows easy porting to Gtk# and contain the features and semantics you want.
It’s about the technology. Why write new widgets in C when you can do it in C#? If I were doing it I know what I’d choose.
For the databinding part I fully agree with Miguel: It is something .NET programmers expect being able to do, so Gtk# should offer this. But this doesn’t mean we cannot do something similiar for plain GTK+: GObject introspection is near from being complete, but at least we can list all properties of a class. So it should be possible to implement tree models based on property introspection…
Maybe it doesn’t have to be C (though that’s a good ABI standard), but it’d definitely rock to have a communications standard, so that you could implement confoming widgets in any language, not just C#.
Something more like a component communications protocol.
Well, maybe something like this will end up being part of the proposed stuff.
Can someone explain what on earth is Office-like ribbon ?
Screenshot please
@Nil: http://en.wikipedia.org/wiki/Ribbon_%28computing%29
Perhaps Vala (http://live.gnome.org/Vala) is the answer. Write it with C#-like syntax, but compile it to plain C (thus exposing a C-API). I’m not sure if Vala is stable/complete/robust enough for this yet, but it seems like it has the potential to become on of the most important and central Gnome/Gobject technologies.
I see… and how is this so different than using GTK Notebook and placing all sorts of widgets inside ?
It’s worth noting that Microsoft has applied for a patent on the ribbon and that Microsoft is only allowing royalty-free use of the ribbon paradigm in cases specifically approved by the company.
It’s sweet, the Wikipedia page doesn’t tell it all. The way it affects Office 2007 is that it steers subtly people more away from trying to do things the hard way. Like, running in menus, making tiny manual adjustments to the formatting and such. It contains less stuff and encourages the use of styles everywhere etc. Furthermore it actually is most usually correct about the guesses on what you are trying to accomplish. It feels very intuitive and great to work with and that feature alone is a good enough reason to throw away OOo and use the Microsoft Office…
Has anyone actually demonstrated a *need* for ribbons in gtk anyway, sharp or otherwise?
We don’t have to do everything Microsoft does– they backtrack often enough on UI ideas themselves that they thought were a great idea at the time, but turn out to be less than stellar in practice. Do we want to have to keep tying ourselves in knots along with them?
IIRC even the OSX version of Office 2007 isn’t going to have ribbons, it’s going to have something that fits with the Apple UI Guidelines, because that’s what Mac users demanded. That’s the approach we should be taking: what’s going to work best for *our* users?
5 Trackbacks
QoTD: Miguel de Icaza March 27th, 2007 by jdub
QoTD: Miguel de Icaza March 27th, 2007 by jdub
Melissa Draper: Why groups like LinuxChix and $distro-Women are relevant Debian Package of the Day: unclutter: hide the mouse cursor after a period of inactivity Christer Edwards: Quick Update Toby Smithe: Feisty Beta Jeff Waugh: QoTD: Miguel de Icaza
March 26, 2007 09:14 PM
March 26, 2007 09:14 PM