Re: GTK+ Application class

[Emmanuele Bassi <ebassi gmail com>]

hy Yevgen;

On Wed, 2006-10-25 at 15:34 -0500, Yevgen Muntyan wrote:

> >>What's the purpose of this?
> >>    
> >>
> >
> >These vfuncs have been moved too to the GtkDocumentModel interface,
> >inside a more complex GtkDocumentInfo boxed type. The rationale between
> >setting and getting the document's MIME type is to advertise
> >
> But it can't "advertise" it to anyone but itself. Maximum useful
> thing can be here is if gtk uses mime types for something,
> but it's not going to.

it advertises to itself, yes; it can also offer a way for others to know
if it has a way to export this data to other processes - which can be
done inside the bindings or if GTK+ will have a dependency on an IPC
mechanism like D-Bus.  it's also useful for IDEs or UI builders, to
provide an object for starting an application project.

the fact that *right now* it's useful only for the GtkApplication itself
should not limit what it can be transparently implemented later.

> >Let's assume that you have a GtkWindow with a 'Open...' menu item bound
> >to a yourapp_file_open_cb callback;  inside the callback you'll create a
> >FileChooserDialog widget and set the GtkFileFilter on the MIME types -
> >by getting them from the GtkApplication (or the GtkDocumentModel
> >provided by the application and bound to the window):
> >
> >  gchar *types;
> >  gsize types_len, i;
> >
> >  types = gtk_application_get_mime_types (application, &types_len);
> >  for (i = 0; i < len; i++)
> >    gtk_file_filter_add_mime (filter, types[i]);
> >  
> >
> If *I* create that dialog, then I don't need GtkApplication api.

why?  it's called abstraction (or even "abstractionitis" :-)) for a
reason - so you don't have to change the caller code but just the
implementation.

> >If you application supports plugins for input/output operations, which
> >allow you to read or write new MIME types, you'll have to add the MIME
> >types to the application and keep them there.
> >
> >Probably, though, the alternative design (GdkMimeEntry, working like
> >GdkTargetEntry) with an integer id and a flag (_READ/_WRITE/_BOTH) is
> >better and more flexible.
> >  
> >
> This is not going to work on windows; then, even on linux
> it's often impossible to use mime only - e.g. missing mime types,
> like "*.g,*.gd,*.gi" files.

why it's not going to work on win32, and what it should take to make it
work there?  you are the win32 programmer: I'd like to know how to make
this work on win32. :-)

> >No; "add window" means adding a GtkWindow to the list of windows
> >belonging to the application; a window is bound to a document (hence the
> >document id) so that multiple windows can show the same document.
> >  

> So one window may contain no more than one document? And,
> what does this api buy if it still has no idea about documents?
> Keeping a GSList of documents is not very useful, since you might
> need more stuff. Then, what about moving documents between
> windows?

mmh, so we'd need a more generic widget - for MDI applications; instead
of using GtkWindow and keeping a list of windows the application should
keep a list of widgets and bind them to the document they hold.

> I mean, it's not bad that application object is going to be aware
> of documents; but it's useless if there's not enough intelligence
> inside the application object. The only good thing I can see here
> is some ATK stuff - gtk can find a window which contains certain
> document (though this is questionable too, since "document" is
> nothing more than id, or is it not?)

a document is an interface, so it can be implemented as a proxy for a
GtkTextBuffer or to whatever object you use to store your data.

[...]

> E.g. I have bunch of open methods - "open in this window", "just open",
> "open these ten documents" (so there's *one* error dialog for all ten 
> documents),
> "open this document and go to this line", and so on (it's not the exact api,
> of course, but api is still more complex than "just_open_it()").

the API itself can be just as simple as open_something(); it's the
implementation that makes it more or less complicated.  GtkApplication,
far from being the end of all application API, is a way to move most of
the code that it's being currently duplicated in endless applications
back into GTK+: handling multiple windows, handling multiple documents
and having a single API for the common operations.

ciao,
 Emmanuele.