Re: selected text is PRIMARY?

[Yevgen Muntyan <muntyan tamu edu>]

Brian J. Tarricone wrote:

> > mozilla allows user having multiple selections, and it doesn't
> > clear selection when you select something else. It's not buggy,
> > it's correct (not for everyone, of course).
> >    
>
> Not according to accepted practice.  At the very least (not even talking
> about any kind of spec), one could argue that, since moz/ffx uses gtk,
> it should emulate gtk's behavior.
>  
"Accepted" here is what we currently have. I claim that mozilla
is right, and it correctly does not emulate wrong gtk behavior.
(right and wrong for many people, not for everybody, etc., etc.)

> > The document you posted link to tells about what X selection is
> > and what happens when you select text/do whatever. Question
> > is not what gtk does, we know that.
> > Question is "why am I not allowed to have multiple selections?"
> > "Because of X" is not the right answer.
> >    
>
> Unfortunately it *is* the answer, regardless of whether it's "right" or
> not.  You can only have one PRIMARY selection at one time.  De-selecting
> all other selected text serves as visual indication of which text will
> get pasted from PRIMARY.  It's of course a matter of opinion as to
> whether or not that visual indication is useful and necessary, or
> counter-productive and annoying.  
Exactly. In my opinion it is wrong that I have this indicator.
I care more about selection in the editor more than about fact
that if I see selected text, then middle button click will paste
this text.

> Adding a pref to accomodate that
> sounds like an consistency-breaking kludge[1].
>  
Well, see your footnote :)
About consistency, should we use bash/tcsh/eamcs/vi shortcuts
in GtkEntry? I believe it's same kind of question.

> Maybe some people don't care about the PRIMARY selection.  Fine.  But in
> a sense, you kinda have to if you want to get the most out of X's
> somewhat unique (and IMHO very useful) copy/paste semantics.  
Err, what exactly? Middle-button-click would still work. Do I miss
something or you mean that seeing not more than one selection
is "most of X copy/paste semantics"?

> For people
> who are content to do the Windows-like CLIPBOARD method and totally
> ignore PRIMARY, I can understand why losing selected text would be
> annoying.  But why should we dumb down the interface for the lowest
> common denominator?
Because we are doing it all the time maybe?
Anyway, I do not totally ignore PRIMARY nor I want to disable
it; still, I want to have multiple selections.

>  Sure, sure, it's a pref, and the default behavior
> can stay the same.  Whatever.  Yay pref-bloat!
>  
No option and half of people happy is better than letting
them choose?

> "Fixing" gtk in this sense is not a magic bullet, either.  What about
> custom text-entry implementations?  The GtkIMHtml WYSIWYG entry widget
> in Gaim comes to mind.
Made of GtkTextView?

>  They'd have to implement support for your pref.
> What about custom icon view cell-editing widgets (I believe Thunar[1]
> has or will have one)?  That would have to support your pref as well.
> I'd bet there are others.
>  
Sure, I have two. One is textview-derived widget where I
intentionally hack-around this GTK thing, because otherwise
"search in selected" is simply impossible.
About implementation, it's a matter of checking one gtk setting
before calling unselect() or whatever.

Best regards,
Yevgen