GNOME.org
 

Re: GTK+ Application class

Emmanuele Bassi wrote:


Hi Yevgen;

On Wed, 2006-10-25 at 12:24 -0500, Yevgen Muntyan wrote:

Emmanuele Bassi wrote:
... gchar * (*new_document) (GtkApplication *application); 
gboolean      (*save_document)     (GtkApplication       *application,
                                    const gchar          *document_name,
                                    const gchar          *document_uri,
                                    gboolean              save_backup,
                                    gboolean              overwrite,
                                    GError              **error);
gboolean      (*open_document)     (GtkApplication       *application,
                                    const gchar          *document_uri,
                                    gboolean              read_only,
                                    GError              **error);
gboolean      (*close_document)    (GtkApplication       *application,
                                    const gchar          *document_name,
                                    GError              **error);



What are these going to do and who is going to call them?


Those vfuncs have been changed to be asynchronous, and moved to the
GtkDocumentModel interface.  In any case, vfuncs are supposed to be
implemented by the sub-classes of GtkApplication - which should be an
abstract type.  You can then use the GtkApplication API (which I did not
include in the email for sake of brevity) inside your application's
code.

See below.


[snip]


Each GtkApplication should declare which MIME types it supports:

void          (*set_mime_types)    (GtkApplication       *application,
                                    const gchar * const   mime_types[],
                                    gint                  n_mime_types);
GSList       *(*get_mime_types)    (GtkApplication       *application);



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.


which
documents can be read/written by the application.  It's a "declaration
of intent", if you want.

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.
But see below anyway.


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.


[snip]


void          (*add_window)        (GtkApplication       *application,
                                    const gchar          *document_name,
                                    GtkWindow            *window);
void          (*remove_window)     (GtkApplication       *application,
                                    const gchar          *document_name,
                                    GtkWindow            *window);



What does it mean to "add window"? And is this one-window-one-document
setup?


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?
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?)


[snip]


I'd like to hear from developers using an "application" abstraction in
their code (like Gedit, Evince and Epiphany) what they think about this
API and what they think an application API should provide for their
needs.  For instance, this API is designed for document-based
applications; 
All in all, it's really not clear what this api is doing. The document
stuff looks like it's a desktop file taken to the next level, but what for?


Where did you get the "desktop file" part from? :-)
Well, from the api. I still don't get how I (as a developer of an application 
which has an application class) use it. E.g. open-document, close-document
would be useful if someone else could call them - via dbus or if desktop
could launch my application and invoke those methods to "open a document",
or something like that, *third-party* calling these methods. But I, in my private application code, will not benefit a single bit from the fact that GtkApplication 
has these methods.
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 GtkApplication is a controller object: it controls the lifetime of
documents and windows, and binds them in a <document>::[<window>, *]
relation.  It's a bit of high-level object orientated design for
document-oriented applications


To me it seems a thing for itself - does no good but is there
because it looks nice, I mean the documents part.
The application object would certainly be good. Here's what
I baked for my needs:
http://mooedit.sourceforge.net/hg/moo/?f=-1;file=moo/mooapp/mooapp.h
Note that it doesn't know about documents even though
it's a text editor. It does know about Editor object though :)

Regards,
Yevgen
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]