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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list