pastie doesn't handle correctly long strings about pastie HOT 3 CLOSED

I've profiled the code and found that the main performance issue for long clipboard contents is in the call to the wait_for_text() method in the GTK clipboard object in the protector instance.

     21957 function calls (21021 primitive calls) in 135.465 CPU seco
     Ordered by: standard name
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    1    0.000    0.000  135.465  135.465 <string>:1(<module>)
    1    0.016    0.016  135.463  135.463 pastie:19(<module>)
    1    0.000    0.000   97.364   97.364 protector.py:30(__init__)
   70    1.412    0.020   99.718    1.425 protector.py:94(check)
   70   98.203    1.403   98.203    1.403 {method 'wait_for_text' of 'gtk.Clipboard' objects}

I've found parcellite works even worse, but that glipper can handle this better. I'm checking glipper's source.

from pastie.

Hm... Glipper's clipboard retrieval method is, simply put, not good enough (someonce could say, "just good enough"). It uses the clipboard Gdk Atom's internal event "owner-change", which sadly won't work with some programs, e.g. Gvim "+y. So: wait_for_text() get's called less (and so glipper has better performance), but it won't catch all clipboard changes.

The problem we are having is due to wait_for_text() being called every 500ms in cases where it takes more than that time (1400ms) to actually retrieve the text.

from pastie.

Doesn't fail as hard now. The menu still updates slowly, but doesn't hang.
I've integrated the "owner-change" procedure into pastie, so that past of the issue should be fixed too.
I'm closing this.

from pastie.