Making a GTK widget in monodevelop

While designing the UI interface for ilias-sharp, I’m thinking how to make specific tiny widgets to inform about an object that the user has clicked on. The main problem when designing a widget i’ve found (using monodevelop) is the small possibilities that we have to change the visual appearance of the existent widgets, specifically containers.

The good news about using monodevelop to develop new widgets is that, once you’ve done it, you automagically can see it at the widget’s palette of the integrated Stetic UI designer. That’s really cool, cause you can drag it to your interface, and go on with your UI design.

owner widget

owner widget

Firstly I though about designing something like the beagle interface:

The information is clear, and the background is white. I think that a clear interface (speaking of color) is less heavy for the user, and more attractive that an all-grey user interface. That’s a common problem in GTK UI designers (Stetic, Glade and Gazpacho), you can’t change the background of a widget from the UI editor. What’s more, I’m not sure that you can use widget.modify_bg in every widget you want.

The second thing I like about beagle interface is those tiny borderless actions buttons using microns (accordingly to tripu’s dictionary!). They are again clear and direct.


4 comentarios en “Making a GTK widget in monodevelop

  1. About the background color: beagle is using a TreeView custom cell renderer and that’s how he can choose the background color. Nevertheless in a regular TreeView the background color is white.

    The widgets that won’t change their background color if you use widget.modify_bg are those without a gdk window (i.e. most of them 🙂 ). This is something GTK+ does for performance reasons and if you really want to change the background color you can always use a GtkEventBox as a container for the widget you want to change the color.

    I have a question about Monodevelop and custom widgets: do it allows you to design only composite widgets or you can also design a widget that redefines the behaviour of his ancestors? A composite widget is a widget that is composed by several other widgets (e.g. the FileChooser). The other kind of widget is that one where you can write custom draw, resize, click, keys and, in general, all kind of events, behavior.

  2. I think that it allows you to define anything you need. If you want to develop your ‘custom widget’, then you can, and you can also do everything you need inside it. When you define a “new widget”, both a “designer view” and a “source view” are displayed, so you can attach event management for your widget, or draw what you need in a specific moment, just as you would do for a window or any other ‘composite widget’. So you can add a OnSizeRequest handler, or something like that, if that is what you meant.

    Thank you for your comments! :-D.

  3. The main problem when designing a widget i’ve found is the small possibilities that we have to change the visual appearance of the existent widgets

    I believe that is in fact a good thing: developers are forced to stick to a common appearence, making more predictable, consistent interfaces.

    Well, I must admit I don’t know exactly what you are talking about and if principles of interaction design apply (I guess so).

    Eat more apples: they increase interface design proficiency 😉

    Say hi to everybody at Cevug!


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )


Conectando a %s