GNOME Bugzilla – Bug 139145
Approach to HIGify File Types and Programs + cleanups
Last modified: 2004-12-22 21:47:04 UTC
Glade is horrible when it comes to diffs, no matter how you try to split up your patches. Therefore I decided to put all of this into one huge patch - as always, maintainers try to kill me, but continuously fail :). What it does: - Remove #ifdef SUPPORT_CHECK_CONTENT code, nobody knows what it does (according to Jody's ChangeLog entry) - Use macro G_CALLBACK format for signal connection calls, add some G_OBJECT macros. - Directly use glade for GtkDialogs and their properties (model, transient, etc.) - Heavily HIGify the beast regs, Chris
Created attachment 26355 [details] [review] Proposed Patch.
Created attachment 26356 [details] Simple Sample Screenshot
Would it perhaps be a good idea to display the file type icon in the main file type list? When looking for a file type, it could make finding the right one a lot easier, especially when Nautilus accustoms you to using the icon.
Isn't the 'Add Filename Extension' dialog a bit too much? Wouldn't it be nicer to offer editing the extension in place in the list? Much like gconf-editor does?
Sean: Should be doable very easy. I coded a treeview sample app some weeks ago that used GNOME-VFS and did it like a charm. (=> #139152) Tommi: Yes, nice idea. The problem is that in-place editing inside the list would require an editable cell renderer - as far as I know - we currently haven't, at least not for the control-center. (=> #139151) regs, Chris
Created attachment 26361 [details] [review] Proposed Patch #2. The last one contained one G_OBJECT macro too much :P. When launching gnome-file-types-properties with args, it crashed. Doesn't happen now.
I'd like to see an option to define a default application for a whole group of document-types. Eg. A default bitmap editor, a default media-player, a default vector graphic editor, and so on. Yes, there would arise a problem when an application cannot open a certain file type, but that could be handlet through the applications .desktop file. And it would easier to correct the few not supported file types than changing all file types in a category.
Raphael: #139232. Please stop adding random improvement comments to this bug report that haven't got anything to do with this patch. Instead, file new bug reports. Thanks. regs, Chris
Why are you adding G_OBJECT casts where they are not needed? No need to cast the last argument to g_signal_connect (incidentally not needed for the first argument either).
Indeed, there is no need to cast them. I'm just used to it because I've seen it in many places. Sorry. regs, Chris
encapsulating the first argument using a G_OBJECT macro seems to be pretty common. Is it bad style? Google lists > 4000 matches. regs, Chris
I think lots of people do that because the old gtk_signal stuff needed a GtkObject . The g_signal stuff just takes a gpointer since it's not specific to GObjects but can be used for any instantiable type.
Created attachment 26726 [details] [review] Third patch. Hopefully the last one :).
the "File types and programs" capplet has been removed in 2.8, no reason to keep this bug open, I'm closing it.