Re: State of the X clipboard, and perhaps a solution

[Jeffrey Stedfast <fejj ximian com>]

On Fri, 2004-04-23 at 19:13 +0200, Murray Cumming wrote:
> On Fri, 2004-04-23 at 19:04, Jeffrey Stedfast wrote:
> > On Fri, 2004-04-23 at 09:36 -0500, Jerry Haltom wrote: 
> > > > You essentially suggested what I have been meaning to suggest for a
> > > > long time, but never gotten around to write up.
> > > > 
> > > > One downside is that the necessary application changesprobably can't
> > > > be done automatically by changing GTK+. Just adding
> > > > gtk_main_quit_after_losing_selection() and have applications call that
> > > > instead of gtk_main_quit() might be enough, though.
> > > 
> > > That's very very good to know. What my proposal does is not break
> > > existing abilities. Copy/paste continues to work in current programs
> > > just as it does right now, without gross workarounds. Adding after-quit
> > > persistence is just an "add-on".
> > 
> > it's a gross workaround for a problem that I don't even agree is a
> > problem.
>
> That's maybe because you are used to it. It's a problem for people
> familiar with Windows and MacOS platforms.
>
> And it's a problem for all users who have no concept of a "running"
> application. Most people are not developers and there is no explanation
> (in terms of their concepts) that justifies the clipboard not working
> anymore just because the original window is no longer on the screen. To
> them it seems perfectly normal to copy, close, paste.

I think it's a problem of presenting Cut/Copy/Paste items in an Edit menu when that really doesn't do what it does on the other platforms (namely copying the buffer to some application-independant location).

If we got rid of those menu items and just forced users to use the X clipboard the way it was meant to be used, I think there'd be less confusion about how it works.

users getting upset at the loss of cut/copy/paste menus is a whole separate issue.

Jeff