public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Harold L Hunt II <huntharo@msu.edu>
To: cygwin-xfree@cygwin.com
Subject: Re: Clipboard configuration
Date: Thu, 08 Jan 2004 17:00:00 -0000	[thread overview]
Message-ID: <3FFD8C8B.4080408@msu.edu> (raw)
In-Reply-To: <f41rvvomb2h5mbb87h2g19pt2795vjdjd7@4ax.com>

Sam,

Sam Edge wrote:
> Harold L Hunt II <huntharo@msu.edu> wrote in
> <3FFD70AB.4080100@msu.edu>
> in gmane.os.cygwin.xfree on Thu, 08 Jan 2004 10:00:59 -0500:
> 
> 
>>Øyvind Harboe wrote:
>>
>>>A good configuration option is no configuration option :-)
>>>Is there any reason not to make -clipboard default for XWin once the 
>>>current round of changes are out of the door?
>>>In the past xwinclip crashed intermittantly and it clobbered the clipboard, so -clipboard 
>>>not being default made sense.
>>
>>I have already been thinking about it.
>>I'll eventually make -clipboard the default and add a -noclipboard 
>>option to disable it.
>>That is what we have typically done for all features that newly reach 
>>stabililty.
> 
> 
> It could be argued that if the -query or -broadcast option is also
> being used the default should remain -noclipboard.
> 
> Most (remote) display managers turn on X authentication and prevent
> the internal clipboard client from connecting to its own Cygwin/X
> server. This results in the client wasting its time doing it's
> start-up retries. This isn't a huge waste - more a niggle.

Really... huh... I guess that's why I call GenerateAuthorization within 
the server to create an MIT MAGIC COOKIE, then I call XSetAuthorization 
in the clipboard thread to pass that cookie to the server when using 
Xdmcp?  :)  You must not have been reading the change logs too closely :)

> If the inter-clipboard functionality is eventually re-coded into the
> server end instead of being an X-client it will avoid the
> authentication problem and the default can be changed to 'enabled' in
> all cases.

No, the clipboard functionality will always need a client connection to 
perform conversions of text with Xlib.  I talked to Keith Packard about 
this... he has frequently used internal clients running in separate 
threads to perform such tasks... it is essentially an accepted practice. 
  You do, however, have to go one step further than we had gone before 
and handle authorization issues if you want to use it with Xdmcp.  That 
has now been done.

Harold


  parent reply	other threads:[~2004-01-08 17:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-08 13:48 Øyvind Harboe
2004-01-08 15:00 ` Harold L Hunt II
2004-01-08 16:39   ` Sam Edge
2004-01-08 16:54     ` Alexander Gottwald
2004-01-08 17:00     ` Harold L Hunt II [this message]
2004-01-09  9:00       ` Sam Edge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FFD8C8B.4080408@msu.edu \
    --to=huntharo@msu.edu \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).