On Tue, 2005-08-02 at 00:19 +0200, Christian Neumair wrote: > Am Montag, den 01.08.2005, 22:33 +0200 schrieb Martin Wehner: > > This doesn't quite work though: The deep-count request is set to > > REQUEST_DONE on the first pass through (and all values set to 0), so it > > won't try to count again on the second pass (with the known filetype). > > If no MIME type is ready, any_file_was_ready is FALSE and status set to > NAUTILUS_REQUEST_NOT_STARTED. If some of them (but not all) are ready, > the status is set to NAUTILUS_REQUEST_IN_PROGRESS.
Yes, but I was talking about deep_count_start not trash_file_get_deep_counts. Sorry, I probably should have mentioned that :) > There is not just one "the file type", there are multiple ones, one for > each trash directory, some of which can be remote system. The trick is > really that as soon as these attributes are ready for any of our trash > directories, we ask the property window to re-read the trash count (cf. > file_type_is_ready). I understand the intention of the patch and the concept of the trash having multiple backing directories, but it doesn't work - I actually tried it (It shows a deep count in the properties, but the count is off if you have stuff in one of the affected trash directories). deep_count_start will return 0s because the file is marked as no longer being needy for a deep count, so it won't count again. You'd have to invalidate the deep count before re-reading it. > > I'm not sure it's the > > right fix though, it seems to be a systematic problem (it also applies > > to the mime_list and directory_count requests) - There seems to be no > > guarantee that you got the file type at this point, which will make > > these functions bail out. > > Hrm haven't even thought about these. Any other ideas than adding > similar call_when_ready code to the relevant functions? No, not without digging deeper into the code. Martin -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
