GNOME.org
 

Re: GTK+ Application class

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]