RE: xwinclip comment

[Brian Genisio <briangenisio at yahoo dot com>]

Well, I havent seen the code in a while, but I assume that you you use a
standard X event loop...

while(!done)
{
  wait_for_events()
  if(is_property_notify)
    read_and_handle_property()
  send_event_to_x()
}

Might you, instead, change this from event driven to polling?

while(!done)
{
  read_property()
  if(new_property != known_property)
    copy_property()
  sleep
}

This way, you dont need to register for events on the property.

You could sleep for 250 ms for instance, which, in worst case, is probably long
enough. (warning : usleep() is not thread safe, so you could probably use
signals to handle a timeout).  OR, you could throw this into xt, and use the
timout capability, but that seems like too much for too little.  Also, dont
forget to use semaphores when copying (and reading from the windows thread) the
known_property.


I hope this helps in the brainstorming process, at least,
Brian



--- Harold Hunt <huntharo@msu.edu> wrote:
> Josh,
> 
> Originally, I was going to answer your suggestion of using separate threads
> with the boilerplate response that, "threads don't fix anything, and they
> usually just complicate things".  However, I started thinking about the
> problem, and it turns out that threads are pretty useful in this
> circumstance.
> 
> The reason that xwinclip steals the XA_PRIMARY selection as soon as a client
> (xterm) modifies that selection is that xwinclip needs to be the owner of
> the XA_PRIMARY selection in order to receive notification when the selection
> is updated.  If xwinclip doesn't receive notification of a selection update,
> then xwinclip can't copy the new selection data to the Windows clipboard.
> The end result would be that you would select data in an X client, but that
> data would not be available in Windows.  Actually, the first time that you
> select data in an X client it would be available in Windows (as xwinclip
> would receive notification upon losing ownership of XA_PRIMARY), however,
> subsequent modifications of XA_PRIMARY by either the same X client or
> another X client would not cause xwinclip to be notified, thus preventing
> the subsequent selections from being available in Windows.
> 
> I went ahead and rewrote xwinclip using threads.  Threads make xwinclip a
> little less kludgy, but, unfortunately, they don't solve the problem
> described above.  That is, we still need a way for xwinclip to be notified
> when *any* X client modifies XA_PRIMARY, not just when xwinclip loses
> ownership of XA_PRIMARY because an X client has modified it.  Only then will
> xwinclip be able to stop stealing ownership of the XA_PRIMARY selection.
> 
> It is possible that a simple solution exists... but I haven't yet come
> across it.  I'm sure Alan H. will email me immediately afterwards with a
> suggestion :)
> 
> Hope that helps to explain the undesired behavior,
> 
> Harold
> 
> > -----Original Message-----
> > From: Josh Baudhuin [mailto:joshb@cadence.com]
> > Sent: Thursday, January 17, 2002 6:48 PM
> > To: huntharo@msu.edu
> > Subject: xwinclip comment
> >
> >
> > Hi, Harold
> >
> >    Thanks for the xwinclip--I just came across it yesterday and am
> > (mostly!) lovin' it. The sole complaint I have is that it seems to
> > hijack the selection immediately after it's established in another X
> > app. Thus, for example, if I select something in an XTerm, the highlight
> > vanishes after I let go of the mouse button.
> >    Is this something that requires integration w/ the X server app? Or
> > is the problem that you need to avoid having two event loops (one for X
> > and one for Windoze)? You might try putting them in separate threads, in
> > case of the latter...
> >
> > --Josh
> 


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/