The MadButterfly is absolute not another GUI toolkit. It's a revolution of embedded GUI design. The hardware of embedded system evolve dramatically in the past 10 years. However, most of the embedded programmer is still use DOS-like environment to composer their user interface. Acoording to the rising power the the embedded platform, people start to use standard desktop tool, such as Gtk or QT to write their embedded GUI. These tools simplify the life of the programmer a lot. However, the GUI created by these tools are vey "desktop". This is not a surprise. These tools are designed for the desktop in mind. How can we expect it to write the embedded UI?

The MadButterfly is designed for the embedded system from scratch. You can use it for the desktop as well. However, its best usage is for embedded. You will see why in the rest of this document. If you are embedded GUI programmer, please keep your eye on this project because it may change your life in the next few years.

Why GTK is not for embedded?

The state-of-the-art embedded hardware provides tremendous power, which is not available ten years ago. Today's embedded system has the power of the desktop 10 years ago. No matter why more and more people start to use GTK and QT to write their own embedded UI. The peocessing power is not an issue. The memeory is not an issue, too. So, what's the issues?

First of all, the widgets provided by the GTK/QT is an issue. The size of the widgets take more than 80% of codes of GTK and QT. However, these widgets, such as listbox, menu, text field and etc are designed for the desktop. They do not looks right in the small screen or lower resolution or color depth. Even they looks good because your screen is big(e.g. TV). The style is not right. Most embedded UI are for CE devices. A computer-like GUI looks nothing but ugly.

Secondly, the operation model of these widgets are not right. Most widgets are designed for mouse users. Not all embedded device has mouse support. Even they have mouse like operation, such as touch screen. The usage is still not 100% the same. Programmers will definitely forced to overwrite a lot of behaviours of teh widgets for their purpose. This work smell like the job of Applo 13 team mebers. They need to use the filter of the main cabin to fit into the ait filter of the moon lander cabin. A lot of workaorunds whose purpose are just to disable the original design.

Finally, ever CE devices want to have styled UI design. This completely violated the rules of the concept of the widget set. The purpose of teh widget set is to make the look and feel as consistent as possible across applications. You can easily tell a program is written in QT or GTK or MFC because of their fixed style. This style will not vanish even with theme support. However, each CE device need their own style. Therefore, widget set is complete useless.

If you use GTK or QT to write a embedded UI, there are two results. Firstly, you send out an ugly and unaceptable result. You are pushing your pure Mon to use computer UI in the TV. For people who know the embedded UI, they are pur engineers because they need to skip all widgets and use the graphic primitive to compose their UI. The only useful widgets are label and image. Others are all useless. So, why do they want to choice GTK or QT?

The MadButterfly

The MadButterfly will save the world. At least, it will save the pure engineers. For those who is satisfied with the computer-like UI, they can still live in their funky world. For those who want a styled embedded UI, the MadButterfly will help them.

Instead of using widgets, the MadButterfly do not provide any widgets at all. Instead, MadButterfly allows the art designer to use their familiar tools to draw the UI and export them in SVG format. The inkscape and illustrator are graet tools which can generate SVG file. This is a true WYSIWYG GUI environment. The SVG file can be a great communication tools between programmers and art designers.

In addition, the MadButterfly made the theme is not just a theme. A new SVG file will make the UI completely different. There is no rule or limit. It can vsae the pure engineer from the UI hell. The customization will become the job of the PM and art designer, who are tarditionally blam engineer for the UI quality.

How?

• Widget-less framework.
• Script-binding.
• Fixed point renderer.
• pre-generated bitmap.