# Bakery FAQ: Frequently Anticipated Questions

## Contents

- What does Bakery give me that GNOME or gtkmm/gnomemm doesn't?
- Document/View? Why not Model/View/Controller (MVC)?
- Why no Serialization like in MFC?
- How can I use an XML format for my application's documents?
- Multiple Inheritance? That sounds scary.
- You keep mentioning MFC. I've used MFC and it wasn't very pretty at all.
- Enough of your nonsense. How do I use this?
- What is planned for the future?
- Bakery is a stupid name. Why not call it something sensible?

## What does Bakery give me that GNOME or gnomemm doesn't?

GTK+ and GNOME provide some widgets and some desktop and application services. gtkmm and gnomemm wraps these for use in C++. But GNOME doesn't help the developer to put them all together to make an application.

For instance, the developer still has to write code to warn the user when they have unsaved data, and to ask the user where to save that data. This gives the developer a lot of flexibility but for 90% of applications this will lead to a great deal of tedious reinventing-the-wheel and will lead to applications with subtle inconsistencies in their basic functionality.

It would be difficult to provide something like Bakery in GNOME because it needs C++ concepts like Inheritance and Polymorphism. These can be done in the GtkObject system but it's still too difficult to demand it of beginner users. But in C++ this stuff is easy - just inherit from Bakery::App_WithDoc_Gtk (or Bakery::App_WithDoc_GnomeUI), Bakery::Document, and Bakery::View, and override a few methods according to your needs.

## Document/View? Why not Model/View/Controller (MVC)?

Document/View is a specialization of MVC, in which the Model is the Document, and the View and the Controller are combined into the View.

In MVC the Controller takes care of user interaction with the View - how the view is changed. Because most GUI's contain widgets or controls which already take care of user interaction (e.g. You can click on a combo box to change it's contents) I don't see any sense in having a separate controller. If anybody can show me how this might work and be useful then I would be happy to add this architecture to the framework.

## Why no Serialization like in MFC?

Serialization isn't all that great - it's just a way to save data as a stream. Anybody who has used MFC much knows that you still have to think up schemes so that you know what type and amount of data to expect next in the stream when you read it back. I suggest that you avoid this hackery and just use XML. See the question below.

## How can I use an XML format for my application's documents?

The WithXmlDoc example in bakery/examples/ shows how to subclass from Document_XML so that your Document can use an XML format. This document explains how to use Document_XML.

## Multiple Inheritance? That sounds scary.

Don't worry, you don't need to do much of it. And it is very useful in this case. Bakery classes do not need to inherit from classes that share a common base class (Bakery::View is not a Gtk widget) so the situation is not complicated.

One thing that makes Bakery much more flexible than MFC is its limited use of Multiple Inheritance. MFC only allows Single Inheritance so any window that wants to be a View in its Document/View architecture must derive from CView. This prevents developers from using different controls for this purpose, and it means that View classes can not be reused without all that View baggage.

With Bakery you can write a class which inherits from Gtk::VBox and which also inherits from Bakery::View, allowing it to play in the Bakery Document/View architecture. I believe that Java's JFC (Swing) takes a similar approach, using multiple Interfaces instead of Multiple Inheritance.

## You keep mentioning MFC. I've used MFC and it wasn't very pretty at all.

I've tried to make it as easy to create applications with Bakery as it is with MFC, but I haven't tried to copy MFC's architecture. Bakery is much simpler and it's easy to just use the pieces you want. The distribution contains examples that show how you can just use the App class without the Document or View, or just the App and the Document without the View.

Because gnomemm and Bakery were written at a time when we have real C++ compilers it is not necessary to use bizarre macros and placeholders such as are found in MFC. Because the code is so much clearer it is also not necessary to use a Wizard to create your application, view, and document classes. This means that developers will have much more idea of what is happening in their code.

## Enough of your nonsense. How do I use this?

The Bakery distribution contains several examples. You will probably be most interested in the WithDocView and WithXmlDoc examples. There is a README in the examples directory that describes each example.

There is also a standalone example which shows how to use Bakery in your own autoconf/automake projects.

## Can I use Bakery's Document/View framework with other GUI toolkits such as Qt?

Yes, Bakery's classes are already independent of any particular GUI, apart from App_Gtk and App_WithDoc_Gtk which provide a GUI-specific implementation. This concept is already proven by the App_GnomeUI and App_WithDoc_GnomeUI classes in the bakery_gnomeui extension library. It should be perfectly possible to create an App_WithDoc_Qt implementation also.

## What is planned for the future?

The classes have comments in their header files listing functionality that should be added in future. For instance, it should be possible to create a Document base class whose data can be saved as a Bonobo document model, and it should be possible to make Views that can be used in a Bonobo container.

Bakery will try to incorporate the new GNOME technologies as they become available and when they are wrapped in C++, giving developers an easy way to get started with them. However, these new features should probably be optional - maybe in subclasses - so that you don't have to use them if you don't want to.

## Bakery is a stupid name. Why not call it something sensible?

Erm, I can't think of anything better.