<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta http-equiv="Content-Language" content="en-gb">
<title>Bakery FAQ</title></head>
<body bgcolor="#ffffff">
<h1 align="center">Bakery FAQ: Frequently Anticipated Questions</h1>
<p> </p>
<h2>Contents</h2>
<ul>
<li><a href="#WhatDoesBakeryGiveMe">What does Bakery give me that GNOME or
gtkmm/gnomemm doesn't?</a></li>
<li><a href="#DocumentView">Document/View? Why not Model/View/Controller
(MVC)?</a></li>
<li><a href="#WhyNoSerialization">Why no Serialization like in MFC?</a></li>
<li><a href="#HowCanIUseXML">How can I use an XML format for my application's
documents?</a></li>
<li><a href="#MultipleInheritance">Multiple Inheritance? That sounds scary.</a></li>
<li><a href="#YouKeepMentioningMFC">You keep mentioning MFC. I've used MFC and
it wasn't very pretty at all.</a></li>
<li><a href="#HowDoIUseThis">Enough of your nonsense. How do I use this?</a></li>
<li><a href="#Future">What is planned for the future?</a></li>
<li><a href="#StupidName">Bakery is a stupid name. Why not call it something
sensible?</a></li>
</ul>
<h2><a name="WhatDoesBakeryGiveMe"></a>What does Bakery give me that GNOME or
gnomemm doesn't?</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="DocumentView"></a>Document/View? Why not Model/View/Controller
(MVC)?</h2>
<p>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.</p>
<p>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.</p>
<h2><a name="WhyNoSerialization"></a>Why no Serialization like in MFC?</h2>
<p>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. </p>
<h2><a name="HowCanIUseXML"></a>How can I use an XML format for my application's
documents?</h2>
<p>The WithXmlDoc example in bakery/examples/ shows how to subclass from Document_XML
so that your Document can use an XML format. <a href="bakery_document_xml.html">This</a> document explains how to use Document_XML.</p>
<h2><a name="MultipleInheritance"></a>Multiple Inheritance? That sounds scary.</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="YouKeepMentioningMFC"></a>You keep mentioning MFC. I've used MFC
and it wasn't very pretty at all.</h2>
<p>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.</p>
<p>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.</p>
<h2><a name="HowDoIUseThis"></a>Enough of your nonsense. How do I use this?</h2>
<p>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.</p>
<p>There is also a standalone example which shows how to use Bakery in your own
autoconf/automake projects.</p>
<h2>Can I use Bakery's Document/View framework with other GUI toolkits such as Qt?</h2>
<p>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.</p>
<h2><a name="Future"></a>What is planned for the future?</h2>
<p>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.</p>
<p>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.</p>
<h2><a name="StupidName"></a>Bakery is a stupid name. Why not call it something
sensible?</h2>
<p>Erm, I can't think of anything better.</p>
</body></html>
