Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 20 Dec 2014, 21:56
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
Rewriting pup_event in C
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 7 [99 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
jamesbond

Joined: 26 Feb 2007
Posts: 2232
Location: The Blue Marble

PostPosted: Fri 20 Apr 2012, 20:29    Post subject:  

Quote:
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 Smile 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
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Fri 20 Apr 2012, 22:37    Post subject:  

jamesbond wrote:


@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.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4424

PostPosted: Fri 20 Apr 2012, 23:08    Post subject:  

@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
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Fri 20 Apr 2012, 23:21    Post subject:  

jemimah wrote:
jamesbond wrote:


@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.
Back to top
View user's profile Send private message Visit poster's website 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India

PostPosted: Sat 21 Apr 2012, 03:05    Post subject:  

jamesbond wrote:

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.
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sat 21 Apr 2012, 12:09    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sun 22 Apr 2012, 19:41    Post subject:  

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

I've got no dice with either gvfs/udisks or the simple volume monitor posted here. Sad

Getting errors like "Could not detect the volume corresponding to the device"

Akash_rawal, have you had any success with anything like this so far?
Back to top
View user's profile Send private message Visit poster's website 
gcmartin


Joined: 14 Oct 2005
Posts: 4507
Location: Earth

PostPosted: Sun 22 Apr 2012, 20:26    Post subject:  

jemimah wrote:
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 Engine or use DogPile
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sun 22 Apr 2012, 20:32    Post subject:  

Ok I figured out to set the PUP_VOLUME_MONITOR_USE environment variable and have now progressed to segfaults - yay, finally something that I understand how to debug!

Code:
0  0x00000000 in ?? ()
#1  0xb78ab4d5 in g_drive_is_media_removable () from /usr/lib/libgio-2.0.so.0
#2  0x0808b0b5 in thunar_g_volume_is_removable (volume=0x8221660) at thunar-gio-extensions.c:487
#3  0x080c2c18 in thunar_shortcuts_model_init (model=0x8221240) at thunar-shortcuts-model.c:300
#4  0xb785e35e in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0
#5  0xb784868e in ?? () from /usr/lib/libgobject-2.0.so.0
#6  0xb7847b25 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#7  0xb784795e in g_object_new () from /usr/lib/libgobject-2.0.so.0


I'm guessing this is because the implementation is not complete yet. I'd be really psyched if we could get this working.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4424

PostPosted: Sun 22 Apr 2012, 20:43    Post subject:  

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
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sun 22 Apr 2012, 20:49    Post subject:  

I did fix the /media thing in both glib and in udisks (when I was playing with that - but I've given up on it since the dbus stuff makes debugging it nearly impossible).

I'm pretty sure the problem is that the gio is not returning enough information. Like with udisks, it would get a volume list but it could not figure out the device path names or filesystems.

I think with udisks, either udisks itself, udev, or glib is broken - but I can't figure out which.

I think a simple volume monitor like this one is a far nicer solution - though thunar stills needs gvfs if you want a trashcan.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4424

PostPosted: Sun 22 Apr 2012, 23:41    Post subject:  

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
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 24 Apr 2012, 10:03    Post subject:  

I've tracked the problem to this function:

Code:
GDrive *pup_volume_get_drive(GVolume *volume)
{
   PupVolume *self = PUP_VOLUME(volume);
   PVM_LOCK(self);
   Drive *drive = g_hash_table_lookup(self->monitor->drives, self->data->drv_sysname);
   GDrive *ret =  G_DRIVE(pup_drive_get(self->monitor, drive));
   PVM_UNLOCK(self);
   
   return ret;
}



drive ends up null and causes the segfault. But any fix I make here ends up with a segfault somewhere else.
Back to top
View user's profile Send private message Visit poster's website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 24 Apr 2012, 10:08    Post subject:  

technosaurus wrote:
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.
Back to top
View user's profile Send private message Visit poster's website 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India

PostPosted: Tue 24 Apr 2012, 11:05    Post subject:  

At last! My volume monitor GIO module is almost complete. See first post.

I have tested GTK file chooser and pcmanfm2. pcmanfm2 works fine. GTK shows some assertion failures after unmounting a drive, but it still works.

For the GIO module to work, as jemimah had already figured out, you need to set PUP_VOLUME_MONITOR_USE environment variable. I set up this mechanism to protect 'innocent' programs from crashing.

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 7 [99 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1082s ][ Queries: 13 (0.0087s) ][ GZIP on ]