Re: [Bug 108951] Re: Gnome drawer applet delays and unresponsiveness
Hi Daniel, Yes, that's what he means. I'm not sure if I can add an attachment, but I'll try: If you can see the attachment, here's how you go about it: 1. Right-click on the Gnome Application menu 2. Select Edit Menus 3. Edit to taste 4. Now, from the Gnome Panel, right-click and select Add to Panel 5. Select the Application Launcher option 6. You'll now see the menu item as one of the options you can add to the panel Regards, Allen On Jan 7, 2010, at 6:47 AM, Daniel Castro wrote: Jason - can you elaborate more? What do you mean under Gnome menu? Under applications? When you say 'put that folder into my toolbar', do you mean into the panel? Thanks! -- Gnome drawer applet delays and unresponsiveness https://bugs.launchpad.net/bugs/108951 You received this bug notification because you are a direct subscriber of the bug. Status in Desktop panel for GNOME: New Status in One Hundred Paper Cuts: Invalid Status in “compiz” package in Ubuntu: Invalid Status in “gnome-panel” package in Ubuntu: Triaged Bug description: The drawer applet in the panel behaves weirdly. When first added to a panel (either the panel in the top of the screen or the one in the bottom of the screen), everything looks good. But after adding to the drawer a link to a simple text file (so that, when clicked, gedit opens with this textfile), opening the drawer requires up to three clicks in the applet (the applet wont open until the third click). And even then, the drawer opens just a bit and then some three seconds later it fully opens showing its contents. I have a feisty fresh install. Exactly the same thing happened to me with Edgy and Dapper before. Hopefully it can get fixed for the next release :) thanks To unsubscribe from this bug, go to: https://bugs.launchpad.net/gnome-panel/+bug/108951/+subscribe ** Attachment added: screenshot_09.jpg http://launchpadlibrarian.net/37599742/screenshot_09.jpg -- Gnome drawer applet delays and unresponsiveness https://bugs.launchpad.net/bugs/108951 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 108951] Re: Gnome drawer applet delays and unresponsiveness
Yes, this is a particularly irksome bug. One clue: 1. Add the System Monitor applet to your panel and configure it to display disk usage in a graph. 2. Reboot (to clear out disk cache) 3. Make sure disk usage is low (wait for bootup to settle down, have a lot of memory :-) 4. Click on a Drawer and a distinct spike is seen in the Disk graph After several clicks on the same Drawer you won't see the bump since the icon is cached by (guessing) the disk cache, file sytem driver or OS or ??? Anyway, try that and see if you get the same results. I could be imagining it... Thanks, qo -- Gnome drawer applet delays and unresponsiveness https://bugs.launchpad.net/bugs/108951 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 108951] Re: Gnome drawer applet delays and unresponsiveness
Naw, nevermind. I think I was imaging it or it was just coincidence :-/ Sorry! qo -- Gnome drawer applet delays and unresponsiveness https://bugs.launchpad.net/bugs/108951 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 211372] Re: gnome panel drawer animation wierdness
Happens on i386, X86_64, multiple different machines with Intel/AMD, nVidia, Sony Vaio laptop, Fedora 8, Fedora 9. Only thing I see in common is Compiz. And, even with MetaCity, Drawer isn't exactly a speed demon (though it's much faster with MetaCity). I've worked around this by removing all Drawers and adding new menus to the Gnome Panel Menubar (right-click and select Edit Menus). qo -- gnome panel drawer animation wierdness https://bugs.launchpad.net/bugs/211372 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 152978] Re: fuse: mountpoint is not empty syncing over ssh
Thanks, Sanford, for all your great work on Tomboy, and for the mini- tutorial on XML :-) regards, qo -- fuse: mountpoint is not empty syncing over ssh https://bugs.launchpad.net/bugs/152978 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 152978] Re: fuse: mountpoint is not empty syncing over ssh
Opps. Sorry. I spoke too soon. Using -s seemed to help in the case where Tomboy is able to sync successfully. But, in cases where the sync fails, the lock is still left behind. In my case, sync is not completing on the first try when many notes need to be synced. This results in the lock remaining. So, steps are: 1. Start a sync 2. Sync partially completes 3. Manually delete the remote lock on the WebDAV server 4. Start another sync 5. This adds more notes from the server that didn't sync the first time 6. Manually delete the remote lock 7. Repeat steps 4-6 as many times as it takes for all notes to be synced Now, add ONE new note. Start a sync. It succeeds and the lock is properly removed afterward. Specifically, if you can get to the point where Tomboy reports: Synchronization is complete 8 notes updated. Your notes are now up to date. Then the lock will likely have been successfully removed. Also, if Tomboy starts to sync automatically (before you start a manual sync) the lock is not cleaned up. Perhaps this was addressed -proposed (?). Again, my apologies if anyone's hopes were raised. qo -- fuse: mountpoint is not empty syncing over ssh https://bugs.launchpad.net/bugs/152978 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 152978] Re: fuse: mountpoint is not empty syncing over ssh
Not sure if anyone is still reading this, but I have a question regarding the lock file format: Below, what is the client-id / tag for? I'm asking since is doesn't seem balanced by a client-id tag (I'm no XML wiz...). What is this used for? Maybe I'm way off base but could imagine that if client-id = us, then we could safely remove the lock and proceed with the transaction. But, this tag doesn't seem to have a value associated with it, so I can't understand what use it has(?). ?xml version=1.0 encoding=utf-8? lock transaction-id46738997-c2b7-4838-b4d9-eb4da537432f/transaction-id client-id / renew-count9/renew-count lock-expiration-duration00:02:00/lock-expiration-duration revision10/revision /lock Thanks, qo -- fuse: mountpoint is not empty syncing over ssh https://bugs.launchpad.net/bugs/152978 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 152978] Re: fuse: mountpoint is not empty syncing over ssh
Sanford wrote: ^^^In the mean time, if you are affected by this, manually mount your desired share, and then use Tomboy's Local Folder sync service and point to the place you mounted it.^^^ Hmm, I manually mount using wdfs and point Tomboy to the mounted directory, and am seeing this same issue i.e. lock file remaining from the previous sync. Tomboy 0.10.1, wdfs 1.4.2, Fedora 9. Mounting using the following: /usr/bin/wdfs https://myserver.com:2078 /home/me/webdisk -o username=myuser -o password=mypass -o accept_sslcert I've stumbled upon a workaround though. If you tell FUSE to disable multi-threading ( -s) , Tomboy is able to remove the lock: /usr/bin/wdfs https://myserver.com:2078 /home/me/webdisk -o username=myuser -o password=mypass -o accept_sslcert -s Could others give this a try?sshfs also provides a -s option. Thanks, qo -- fuse: mountpoint is not empty syncing over ssh https://bugs.launchpad.net/bugs/152978 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
