This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: xwinclip comment


Yeah, my comment was meant more for brainstorming, than a "best" solution...

Is the lastest xwinclip source (the one with threads) available?  I've got some
pretty good X programmers at my office (including myself).  I might be able to
look at it, and talk it over with my peeps :)  

Brian 


--- Harold Hunt <huntharo@msu.edu> wrote:
> 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/
> 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]