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 .

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.

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..._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

@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...

PolicyKit looks like a hard dependency. Maybe it can be hacked. I haven't tried that yet.

@jamesbond
yes, I made a script for jwm that is part of my jwm_tools package and later adapted it as an example in "Sit" my simple icon tray here:
http://www.murga-linux.com/puppy/viewtopic.php?t=76431
but the code could just as easily be adapted to work with wbar or whatever (I don't know for sure on the gnome-centric file managers though, specifically because I avoided them after discovering they all had this issue ... eventually pushing me back to gtk1.2) - I could probably make a hacky version of gvfs based on it - enough to work with gio, but every time I have sat down to look for it, I have lost interest before finding the exact code - maybe jemimah's link to the patch will help point me in the right direction. ... I'd really like to get glib/gtk "fixed" before the next major abiword release though - last time I had to build it on Puppy-4.1 with a lot of rebuilt libs just to get it working.

btw scripting with tcc is a good tool for _developing_, but never as fast as precompiled ... but it may also save some size on smaller code <~4kb (elf garbage)_________________Web Programming - Pet Packaging 100 & 101

@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...

PolicyKit looks like a hard dependency. Maybe it can be hacked. I haven't tried that yet.

I just had a look at the code. I was able to get it to compile and run without policykit. I'm not sure it's working, but I will try to get it to work for Saluki-2. It'd would be nice to have native disk handling in thunar.

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.

I am not trying to change the source code of GIO or GTK. Nor gvfs does.

I am writing a GIO module, so that we don't need to install gvfs just for volume monitoring features. Nothing breaks in case of any upgrades unless GIO introduces incompatible API changes (which they must mention in documentation). This is not a hack.

I think there is a lot of confusion regarding this. Let me clarify.

Here's my design of the event management system:

The GIO module that I am writing is a part of this implementation. It will make the programs communicate with the backend. So far I am having a good progress, without those heavy dependencies like gnome-disk-utility, udisks, gudev, PolicyKit, or even dbus.

The reason that you mentioned actually favours the backend to be written in C. The design you mentioned is already present in my volume monitor. It is in fact very easy to implement in C.

The frontend will be completely different process, outside of the event management. It will communicate with the backend just like all other programs.

This seems interesting. I'm definitely looking forward to testing it. I think replacing pup_event_frontend_d with something more flexible and extensible is a big step toward making puppy a "real" distro" (there are a few more places with a lot of ad hoc hard coded stuff that need work as well).

Getting gvfs volume monitoring to work is a separate (but important if you are not using rox) issue.

Ok so I've spent the entire weekend banging my head against getting drives to show up in thunar. ...

Jemimah, as everyone knows I am no developer. But, could the visibility drives problems that have been an issue in Puppies over the past 8 months be related to what you are seeing?

If this yield a clue, to you or any of the developers, it may help._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

jemimah, it may help to make a symlink to /media from /mnt ... but iirc, you already fixed that. aside from that all I can think of to add for dynamic drives would be to use inotify_add_watch for an IN_CREATE in /sys/block/ (i'm pretty sure most recent puppies after 4.3.X have inotify ) ... although I believe glib has a similar function - it may be gvfs based_________________Web Programming - Pet Packaging 100 & 101

all block devices get symlinks in /sys/block/<drive>
if you follow that symlink, the directory contains a directory(ies) representing the partition(s), but don't tell the fs type (however blkid will, along with UUID - or the deprecated guessfstype - no UUID)
/proc/partitions is a good alternative though - gives quite a bit of info

SpaceFM, the fork of PCManFM 0.5.X (not the one used by LXDE), has an implementation if you need some code to borrow - I posted a pet, but it is a bit outdated - the homepage has moved to:
http://ignorantguru.github.com/spacefm/

Quote:

SpaceFM 0.7.5 does not require udisks (only udev). However, in order to mount or unmount devices as a non-root user, you will need pmount or udisks installed, or will need to specify a custom program to be used. A custom mount solution is currently under development. Also, enabling kernel polling ...

... this one is actually pretty nice

Another one that has support for mount/unmount-ing removable drives is rodent file manager (a fork of xffm)
http://xffm.org/
it monitors /proc/partitions, but it must be enabled at compile time with --enable-fstab-plugin ... that may actually make it easier to find the code (by grepping for ifdefs)
I like a lot of the ideas of this project, but the implementation of the ideas didn't seem to be polished yet._________________Web Programming - Pet Packaging 100 & 101

all block devices get symlinks in /sys/block/<drive>
if you follow that symlink, the directory contains a directory(ies) representing the partition(s), but don't tell the fs type (however blkid will, along with UUID - or the deprecated guessfstype - no UUID)
/proc/partitions is a good alternative though - gives quite a bit of info

SpaceFM, the fork of PCManFM 0.5.X (not the one used by LXDE), has an implementation if you need some code to borrow - I posted a pet, but it is a bit outdated - the homepage has moved to:
http://ignorantguru.github.com/spacefm/

Quote:

SpaceFM 0.7.5 does not require udisks (only udev). However, in order to mount or unmount devices as a non-root user, you will need pmount or udisks installed, or will need to specify a custom program to be used. A custom mount solution is currently under development. Also, enabling kernel polling ...

... this one is actually pretty nice

Another one that has support for mount/unmount-ing removable drives is rodent file manager (a fork of xffm)
http://xffm.org/
it monitors /proc/partitions, but it must be enabled at compile time with --enable-fstab-plugin ... that may actually make it easier to find the code (by grepping for ifdefs)
I like a lot of the ideas of this project, but the implementation of the ideas didn't seem to be polished yet.

Any udisks implemntation doesn't help me since udisks doesn't even work from the command line. Can't figure out why.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum