That delay is a design choice to avoid frequent UI updates when many files are changed at the same time. Besides, it's also caused by delay of file alteration monitor. The old pcmanfm can do it immediately because when you try to remove the file, it remove the item in the UI immediately even before it gets the file deleted notification from the system. It's not a performance issue. Hacking on this is possible, but it requires some changes in API to make things elegant and not hard-coded.
If he's going to hack for LXDE, I'd suggest that he can help fix bugs of the file manager or we can start a new branch to work on new features for the next release. Since we're now in a feature-freeze state, no new features will be added to current master, but I actually got a lot of new ideas to experiment in branches, such as native udisks support without relying on gvfs. On Thu, May 27, 2010 at 9:37 PM, Martin Bagge / brother <[email protected]> wrote: > On 2010-05-27 14:22, Andrea Florio wrote: >> ok guys... what can i tell him to hack? > > from IRC > <Dessous> Oh, I know one: pcmanfm1 & 2 doesn't refresh the view > immediately after you've deleted or added file(s) but it takes like a > second or so. Although I don't know if that's a design choice or a > performance issue or what > > Sounds like a libfm thingie. if possible. I do not know =) > > -- > brother > http://sis.bthstudent.se > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lxde-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
