On Sun, 2003-02-16 at 15:52, Owen Taylor wrote: > The idea of having the application augment the list of mime types > for the non-MIME-system case is reasonable, though: > > - It might seem clunky on systems where extensions do define > file type (Windows, and apparently now MacOS) When you add a type, you would of course have to specify that through the extension and (possibly) the magic binary sniffing. On those systems that always use extensions exclusively [1], GTK could avoid using the binary sniffing completely when getting the MIME type, for consistency with the rest of the system. > - People may want to use other patterns in some cases ... > e.g. *~ to show only backup files or something. And I don't think the second case is common enough to make it necessary in the API. The *~ case doesn't even happen at all with standard-behaving desktop apps (i.e. no backup files). > Yeah, it is pretty much a UI decision. If we don't add filter selection > people will doubtless ask for it, but doesn't mean that it is right. My point exactly. :-) > As long applications allow you to export as a filetype, we aren't > going to be able to hide the idea of filetypes from the user, though > that may make sense on theoretical grounds. If I have a directory > full of .xcf files and also .png files that I've exported from them, > viewing only the .xcf files may make sense. Or if you have been smart enough, the XCF files go into a different folder. :-) > Is "Open Read Only" really that generally useful? I brought it up > as an example because it was mentioned before, but it's not something > I've seen very often, and certainly not something that I've wanted > to do very often. This is not something I do very often either. Actually, if it boils down to it, I wouldn't add that widget to the API either. :-) For the "extensions" to the dialog, they really are a UI decision, so every addition should be evaluated as "sane" UI-wise before hooks are added for it. That's why I am opposed to a generic add-wacky-custom-widget API. It might give us a theoretically less versatile API, but in practice, it doesn't matter; after all, programmers worldwide have been surviving with the "limited" APIs of Windows and MacOS all these years... > > Besides, for a such a common feature it makes sense to have an API > > shortcut that doesn't involve creating the widget manually > > Hmm, I'd be interested to see what your API proposal for this is. > It seems to me that if we have 4-5 things of the type: > > gtk_file_chooser_set_show_open_read_only() > gtk_file_chooser_get_show_open_read_only() > gtk_file_chooser_get_open_read_only() > gtk_file_chooser_set_open_read_only() > > Plus corresponding properties it's going to make for a big > messy API. If an optional element is considered to be important for the UI, I think that's a price worth paying. Still, I really think we should have a very limited set of those optional items (if at all), so that wouldn't make for a big API in the end anyways. [1] Which BTW is far better from what we do on Linux, where we respect the extension on odd days and do binary sniffing on even days. :-) -- Ettore
Attachment:
signature.asc
Description: This is a digitally signed message part