Re: GTK+ Application class

[Emmanuele Bassi <ebassi gmail com>]

Hi Tristan;

On Mon, 2006-10-23 at 12:05 -0400, Tristan Van Berkom wrote:
> Emmanuele Bassi wrote:
> [...]
> 
> Hi,
>      First, thanks for taking the time to think all this up and writing
> this proposal - I have some questions/opinions to share on the topic,
> while they might be some strong opinions - I'm a hardheaded idealist
> kinda guy (its in our nature ;-D )... so please be open and bear with me.

If I didn't want any opinion, however strong, I would have not sent an
email. ;-)

>      The first point I wanted to raise you already raised (heh) - it is
> a document-based api, and it seems wrong for gtk+ to assume that its a
> document based application - if we are about to go ahead with this,
> I would opt for the document handling stuff to be an interface optionally
> implemented by the GtkApplication derivative.

I had a brief exchange with Paolo Borelli and he too exposed the idea of
a GtkDocument GTypeInterface that could be used by a GtkApplication
class, instead of adding open/save virtual methods to the GtkApplication
class itself.  One of the reason, and I agree with him, is that
applications using asynchronous I/O would need an *_async version of
new_document, open_document and save_document virtual functions.

I designed something like this last year, after looking at what the
Cocoa API offered (NSDocument and NSDocumentController classes, just for
reference):

struct _GtkDocumentModelClass
{
  GTypeInterfaceClass iface;

  GtkDocumentHandle *(*document_open) (GtkDocumentModel         *model,
                                       const gchar              *uri,
                                       gboolean                  read_only,
                                       GtkDocumentOpenCallback   callback,
                                       gpointer                  callback_data,
                                       GError                  **error);
  GtkDocumentHandle *(*document_save) (GtkDocumentModel         *model,
                                       const gchar              *uri,
                                       gboolean                  save_backup,
                                       gboolean                  overwrite,
                                       GtkDocumentSaveCallback   callback
                                       gpointer                  callback_data,
                                       GError                  **error);
  GtkDocumentFlags   (*get_flags)     (GtkDocumentModel         *model);
  void               (*set_flags)     (GtkDocumentModel         *model,
                                       GtkDocumentFlagse         flags);
  void               (*set_mime_type) (GtkDocumentModel         *model,
                                       const gchar              *mime_type);
  const gchar *      (*get_mime_type) (GtkDocumentModel         *model);

  void               (*handle_cancel) (GtkDocumentModel         *model,
                                       GtkDocumentHandle        *handle);

  /* signals */
  void (*changed) (GtkDocumentModel *model);
  void (*error)   (GtkDocumentModel *model,
                   const GError     *error);
};

So a GtkApplication following a document model would have to bind the
document model implementation to a window it watches.

> Secondly - I completely agree that GnomeApp is totally pointless as
> far as I can see (one day it must have been a form of convenience,
> maybe before glade ever existed - I dont know)... my question is - why
> would we want to replace it with something ?

Because we have widgets and we have low/mid level classes but no high
level abstraction for application developers; right now many
applications just cut and paste from other applications that get things
(mostly) right: Evince, Epiphany, Gedit are the first names that come to
mind, but it's plenty of applications that follow this pattern.

> I am wondering what real-life practicle applications the sugested
> new class would have,
> 
>    - maybe it would help to standardize the way application
>      infrastructures/architetures are created/designed ?

>    - a way to deffer some global programming logic back into gtk+ ?
>      (easy way of implementing the unique instance app stuff and
>      maybe session management ?)

Not every application has the same needs; but many of them use the same
logic, or share the same structure.  Bindings for object oriented
programming languages already offer such a base class, abstracting some
of the GTK+ functions like gtk_init(), gtk_main() and gtk_main_quit(),
in order to fit them into an OOP approach.

There has been also a definite movement towards a set of abstractions
for desktop usage: the GtkSession API from Dan Winship, the
GdkScreensaver API from Rodrigo Moya, the network state abstraction I
proposed; all of these makes sense when handled by a single application
class.

Finally, the GtkUniqueApplication class makes little sense if we don't
provide non-unique application class.

After taking a look at what other (more or less successful) toolkits do
offer to developers on different platforms I think that GTK+ should
offer an application abstraction to developers choosing this toolkit;
having a simple wrapper around GtkWindow is not an application
abstraction, though; hence my proposal.

> Maybe I'm just missing the vision - maybe you could post a couple
> of imaginary lines of code that display how practicle/code reducing
> this GtkApplication class would be in use ?

More than "code reducing" I think of removing code replication; 

> Last but definitly not least (ugh - here comes the juice), I am _really_
> worried about GtkUIManager becomming the defacto widget generator for
> toolbars and menus. Currently; it seems that menus and toolbars are
> precieved to be something special and stand-alone - this is somehow
> misleading, menuitems and toolitems are actually GtkWidgets also and can
> be built with the GtkBuilder as well - much more powerfully than they could
> with the ui manager, with the missing link of actions and merging [1].

I added the GtkUIManager hook because it's what we have right now; it's
not perfect but it's what we have.  If GtkBuilder hits HEAD and supports
menu creation too, switching from the UIManager to the Builder object is
just a matter of changing a hook.

> So this point relates to this thread because - including some kind
> of global "application" object in gtk+ and adding uimanager members for
> "toolbar" and "menu" is pretty much saying that "this is the way you
> do menus and toolbars in gtk+"... since I strogly disagree with this
> general approach - I think it would be harmfull to encourage its use.

Personally, I think that GtkUIManager does a terrific job at relieving
me - as a developer - from the burden of caring about the menus and the
toolbars; I used basically everything since GTK+ 1.x for menu building:
manual, ItemFactory, Bonobo, GnomeApp and GtkUIManager, and the latter
is the only way I can keep my sanity when building a menu.  I read your
emails the first time around and while I certainly agree that the
GtkUIManager is not perfect (my biggest grievances are that GtkAction
objects should support the creation of multiple menu items and that
GtkUIManager should allow the building of multiple widgets from the same
path) it's what we have until GtkBuilder gets into GTK+; and even when
GtkBuilder hits HEAD and we mark GtkUIManager as deprecated (or as a
convenience API built on GtkBuilder just for menus and toolbars) - any
API addition to GTK+ will have to deal with it in one way or the other.

Ciao,
 Emmanuele.