Ok Glipper fans one thing I have seen discussed here as a means of
finding out what is wrong with Glipper is the posting of the history file
and looking at the history file.. So, why would the history file have
anything to do with Glipper crashing on boot to desktop? The history file is
rea
This worked for me as well on Ubuntu 9.04
Toshiba A100-OFH
Intel 945 integrated graphics
1) chapp...@codefu:/usr/lib/googleearth$ sudo mv libssl.so.0.9.8
tmp-libssl.so.0.9.8
2) chapp...@codefu:/usr/lib/googleearth$ sudo ln -s /lib/libssl.so.0.9.8
libssl.so.0.9.8
Applications > Internet > G
ipboard. Please let us know if
you find any other solution to this as it is an indespensable tool.
Jake
On Sun, Oct 5, 2008 at 3:55 AM, marco.pallotta <[EMAIL PROTECTED]>wrote:
> @chappejw, I tried your workaround but it doesn't run for me.
>
> - I made the soft link
> - I
I tried the sugguested workaround and it did not work. As soon as I copy
something to the clipboard Glipper begins Glipping out and eating about 85%
of my CPU bogging down everything else on the system. I also start Glipper
from the command line to see any output that can help trace down the issue
using Fusion-Icon disable 'loose binding' and you will not have any
flicker with your compositing enabled.
--
screen flickers when compositing enabled in metacity
https://bugs.launchpad.net/bugs/247565
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Public bug reported:
Binary package hint: gvfs
1) Description: Ubuntu 8.04.1
Release:8.04
2) gvfs:
Installed: 0.2.5-0ubuntu2
Candidate: 0.2.5-0ubuntu2
Version table:
*** 0.2.5-0ubuntu2 0
500 http://ca.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg
** Attachment added: "screenshot showing 'system monitor' at top and system
resource indicators just after boot boot"
http://launchpadlibrarian.net/17180024/gvfsd-trash.png
--
on boot with Hardy 8.04 'gvfsd-trash' eats CPU and causes high disk access
https://bugs.launchpad.net/bugs/263085
Yo
I believe this is some sort of a race condition. Originally I thought... oh,
this looks like a simple bug to find, it's written in Python, how hard can
it be?. well Nearly everyone watching this bug has tried one thing
or another and the bug persists... For all we know the bug is caused by
I have fixed the glipper start up problem with an easier solution.
First of all after installing 'glipper' with 'sudo apt-get install
glipper' when we do a 'which glipper' we see that it is not found in the
PATH. Hmm interesting... When I do a 'whereis glipper' it shows...
glipper: /usr/lib/glipp
Simone: You are right, if it is supposed to be a panel applet we don't
need it to be in /usr/bin/. Actually that soft link I sugguested is
irrelavent. However, I was not presenting that fix as a path only issue.
>From reading all the posts here it appears that glipper starts before
some arbitrary r
But why does that work? If it sleeps for 8, 30, 90 seconds and then starts
reliably? what was it that caused it to crash in the first place?
Jacob
On Thu, Jul 30, 2009 at 8:15 AM, Shane Rice wrote:
> This fix:
>
> sudo gedit /usr/lib/glipper/glipper
>
> Make sure the code in the beginning loo
It's up to the owner of the active selection to copy it from the PRIMARY
buffer to the CLIPBOARD buffer upon closing or the selection dies with
the window which is closed. This is not an Ubuntu bug or an X bug just
to be clear, but a lack of adherence to the X Windows protocol. Xserver
negotiates n
12 matches
Mail list logo
