I agree with this, but I think this has been solved in other ways before. I remember seeing floating drive tray icons in the days of puppy4. Not sure where what's the state of that now, and what was used to implement it.The problem discussed here is not just performance issues. The problem is also to 'unlock' drive management features present in many programs which were unused because of absence of backends in GIO. Till now, the ROX desktop was the only way to access the drives. If user uses another DE, (s)he is helpless unless (s)he can hack /sbin/pup_event_frontend_d .
But doing it in C, especially tying to GTK/GIO - hmmm ... upgrade GTK and stuff breaks. Well not always, but sometimes they do. I would rather we have a non-X daemon that communicates with a GUI tool. The GUI tool can change time to time (GTK/Qt/Xlib/whatever), but the daemon stays the same, so I prefer that daemon to be in script instead of C.
As jemimah said before, though (welcome back Jemimah, glad to see you back from hibernation), pup_event_frontend_d is doing much more than just icons. I'm also considering to replace it - but before I can do that I must understand every aspects of it Needless to say, there are many hooks beyond that file everywhere in the system (to name a few: save2flash, mount, umount ...)
If you still insist in C, like technosaurus said in another thread, there is always tcc and you can make a C script (yes, a C script - the real thing, not an oxymoron).
@Jemimah - I was considering udisk, but now you tell me it depends on a lot of other stuff that I don't want, I think I'd stay away. I thought freedesktop.org would implement lightweight stuff and let the DE takes care of the full functionality? Hmmm...