The Python GUI Builder

Introduction

I have this terrible ongoing developer's itch to create a highly usable GTK+ GUI builder for Python. Let me describe this initiative by going over the following items:

What a GUI builder is and why it is needed

A good GUI builder allows programmers to quickly develop desktop applications with a graphical user interface.

Technically, a GUI is created by programming a special framework, API or a GUI toolkit. Without a GUI builder, GUI programming needs to be done manually by programming the GUI API directly.

What this tool can do for GNU/Linux and Python

To understand what a good GUI builder can do for GNU/Linux and Python you should consider the most notable example of a usable GUI builder which is that of Microsoft's Visual Studio.

Combined with good editor-auto-completion functionality, excellent help system and free-of-charge availability, the result is a major attraction for occasional developers, students and children as well as a natural choice for teachers and instructors of computer classes.

I regularly fail to convince teachers and children to choose Python over VB as a first language because of the availability of Visual Studio and the usability of its GUI builder.

My opinion is that a usable GTK+ GUI builder for Python will:

Usability of existing tools

Unfortunately, except for Visual Studio I do not know of usable GUI builders. Netbeans comes far behind in second place with an innovative layout system but its interface is confusing and it produces code that looks like a mess.

Most other GUI builders that I know of for GNU/Linux use the incomprehensible layout model of VBoxes and HBoxes which was originally conceived for manual GUI programming where it makes some sense, but in the context of a usable WYSIWYG editor it is completely useless. If you don't believe me grab an intelligent person who has never done GUI programming and sit him in front of Glade and ask that person to do something useful with it. It would be just as useful to ask the same of a finite group of wild monkeys attached to keyboards.

Speaking of Glade, which is the official GUI builder of Gnome. My current theory is that it is possibly used by some professional developers who are already expert GTK+ developers and tired or bored of writing interfaces by hand. I can not imagine anyone else finding it remotely usable. It is easier to learn to program GTK+ by hand than to learn to use Glade.

All GUI builders obstruct the natural work-flow with tons of raw properties, infinite cryptic signal lists, and generally useless context menus.

I asked many Python desktop developers and they all confirmed: A usable GUI builder is both required and unavailable.

My plan for this tool

Foundations

In my view a good GUI builder has 3 necessary foundations:

  1. Good designer - As usable as possible please.

  2. Good code-completion - Eventually some code needs to be written by hand. Code completion is absolutely necessary to help newcomers build confidence and feel at home as soon as possible.

  3. Good help system - Both GTK+ and PyGTK have excellent documentation and reference.

Basic Design Decisions

The basic design decisions:

  1. Python - Python is powerful, easy and fun. It is an excellent choice for children and students as first programming language as well as for professional developers writing complex applications. If GUI builders are a corner stone of RAD, I say the R(apid) in RAD stands for Python. It is the best of free software.

  2. GTK+ - The base of Gnome, the face of Ubuntu. The Python bindings (PyGTK) of this toolkit are elegant and both GTK+ and PyGTK have excellent documentation.

Some Design Goals

Here are some other design goals:

  1. New layout algorithm - HBoxes and VBoxes are for aliens from Mars, not for human beings. Away with them. A new guides-based algorithm will make layout simple, natural and yet powerful. In addition, the layout in the designer will look exactly like that of the running program.

  2. Emit design as Python code - The tool will read and write the UI design as Python code. This model works very well in Visual Studio. In my view storing the design in a special resource file or in a XML file as glade does is wrong.

  3. Emitting the design as Python code has the following benefits:
    • The user has one less format/technology he/she does not care about to learn.
    • As long as the emitted code is elegant it serves as demonstration code to the way GTK+ works.

  4. Streamline expected work flow - When a user layouts a button he/she probably want to set its label and define its click function. Most GUI builders obstruct these operations with a gazillion of widget properties and infinite signal lists. In the new tool such expected operations will be made possible in an intuitive and simple way even for users who try it for the first time.

  5. Use abstractions instead of raw information - Where possible let the user control the appearance and behavior of widgets with abstractions like tool bar icons and meaningful options, instead of having to tweak raw properties.

  6. Sub classing - It will be easy and natural to reuse designs as widgets (sub-classes / sub-designs) in other designs.

  7. Design and run - Designed code can be instantly run. This kind of feedback is essential to build confidence in newcomers and is fun.

  8. Code completion and contextual help - The tool will provide code completion and contextual help functionality, also in library form to IDEs which wish to integrate it.

  9. Deployment - The tool will be easy to deploy and use.

More Considerations

And a final set of considerations related to the development process:

  1. Focus development energy - I wish to create the best GUI builder I can, not the best IDE. Therefore this tool will work well both as a stand alone tool and as a building block for IDE developers.

  2. Quality - Prefer quality of features over quantity of features.

  3. Promote collaboration - Promote collaboration of free-software developers with a well designed website, wiki, mailing lists, source code repository, etc. Promote collaboration through good documentation, careful modular design and quality code.

  4. Eat own dog food - The tool will be good enough to build itself.

  5. Modularity - Design will allow extending to other target languages and other GUI toolkits.

GuiBuilder (last edited 2008-11-18 09:01:45 by Nir)