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