RE: xwinclip comment

["Harold Hunt" <huntharo at msu dot edu>]

I think it goes without saying that the primary goal is to avoid all polling
solutions until any other feasible solution has been ruled out.  We're still
in the stages of ruling out other possibilities.

Harold

> -----Original Message-----
> From: Brian Genisio [mailto:briangenisio@yahoo.com]
> Sent: Wednesday, January 23, 2002 7:34 AM
> To: Harold Hunt; Josh Baudhuin
> Cc: cygx
> Subject: RE: xwinclip comment
>
>
> 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/