Thanks for your suggestions with the new functions. I've updated my patch (and the bugzilla ticket) with the new functionality. I also changed the behavior of the add_emblem function to not allow adding an emblem that is already present. Does this seem like the correct behavior?
Adam On Mon, Dec 7, 2009 at 8:38 AM, Benedikt Meurer < [email protected]> wrote: > > On Dec 7, 2009, at 08:11 , Brian J. Tarricone wrote: > > > One little thing because it's an obvious problem: > > > >> gchar *(*get_mime_type) (ThunarxFileInfo *file_info); > >> gboolean (*has_mime_type) (ThunarxFileInfo *file_info, > >> const gchar *mime_type); > >> - > >> + void (*set_emblem) (ThunarxFileInfo *file_info, > >> + const gchar *emblem_name); > >> gboolean (*is_directory) (ThunarxFileInfo *file_info); > > I'd suggest to use > > thunarx_file_info_add_emblem(file_info, emblem_name) > thunarx_file_info_remove_emblem(file_info, emblem_name) > thunarx_file_info_remove_emblems(file_info) > > instead. > > Thunar will have to take care of updating the display items (i.e. via a > signal, tho that could cause too much noise in certain situations) whenever > emblems are added/removed (this should not schedule a relayout, just a > redraw on the views). Plugins like the VCS plugins would then determine the > appropriate emblems in an asynchronous fashion (i.e. separate > process/thread) and attach the emblems via a main thread idle callback. > > > -brian > > Benedikt > _______________________________________________ > Thunar-dev mailing list > [email protected] > http://foo-projects.org/mailman/listinfo/thunar-dev >
_______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
