Emmanuele Bassi wrote: >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. > > It's not clear what and how can be implemented later, so there is no point to limit that later implementation by api which is not useful now anyway. The idea indeed sounds nice, like "what file types are handled by this application"; but until it makes certain sense, there is no point in creating api for it.
> > >>>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 it's "abstractionitis", then it shouldn't be in GTK api :) Seriously, what caller code? In your example there is a callback, and code inside the callback. It's not like some third-party(ish) code calls do_something(), and do_something() implementation may or may not change. Point is, there is no difference between types = gtk_application_get_mime_types (application, &types_len); and types = my_foo_application_get_mime_types (); if I am writing all this code. A generic method in GTK that opens FileChooser and asks for filename could use this though. > > >>>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. :-) > > Well, mime types do not exist on windows. Something better is needed (if needed at all), like GtkFileType (real ugly). To me, all this mime type stuff looks too much gnomeish. (Yes, f.d.o. and so on, but for some reason KDE seems to do what it always did) By the way, what does MacOSX do? Does it have win32-like thing, "type == bunch of globs and an icon", or does it have something different, like in MacOS9? >>>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. > > And here's the real problem: GTK has no idea about "documents", and it has no clue about "windows with documents". It's a problem which needs solution, but the proposed api does not solve this problem at all. On the other hand, a generic application class which would handle main loop, which would know what "start" and "quit" mean, which would handle single-instance stuff and whatnot is useful, is needed, and can be implemented right now; without philosophical discussions about what Right MDI is. In short, GtkApplication is one problem, and MDI is a different problem, and there is no point in adding api which attempts but doesn't succeed in solving the latter. > > >>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. > > API can't be as simple as that, this is the point. I need bunch of methods like "open_this" and "open_that", so single "open" present in builtin class does no good at all. Now, the "a way to move most of the code that it's being currently duplicated in endless applications back into GTK+" part is good, but proposed api is not that: it doesn't *handle* multiple windows and multiple documents, it merely keeps a list of windows and documents around. I guess the right way to do it would be to take gedit (epiphany, whatever else from the endless list), and start from there, extract what is actually needed and what is actually done in real applications. Or something like that, what books say. Best regards, Yevgen _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
