Re: selected text is PRIMARY?

["Brian J. Tarricone" <bjt23 cornell edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/9/2006 3:51 PM, Yevgen Muntyan wrote:
> 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.)

Well, we're arguing over what boils down to a personal
opinion/aesthetics, which is useless.  No agreement can be made here, so
let's just drop it.

>>> 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.

Again, personal opinion.

>> Adding a pref to accomodate that
>> sounds like an consistency-breaking kludge[1].
>>  
>>
> Well, see your footnote :)

Why make matters more confusing and inconsistent?

> About consistency, should we use bash/tcsh/eamcs/vi shortcuts
> in GtkEntry? I believe it's same kind of question.

I disagree.  The issue at hand is text selection behavior regarding
copy/paste across GUI applications of different toolkits (and sometimes
the same toolkit).  You're bringing up specific features of certain
applications.  (On a side note, emacs keyboard shortcuts are supported
in gtk if you use a different keytheme.  I imagine you could support vi
as well.)

>> 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"?

No, you just misquoted me.  Re-read it.  I'm actually for some reason
not talking about text-selection at all here.  Just that if you want to
get the most out of X copy/paste (i.e., being able to intelligently use
*both* the CLIPBOARD and PRIMARY selections), there's a slight learning
curve involved.  It's a tangent topic, so feel free to ignore it.

>> 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?

Terrible, terrible justification.

> Anyway, I do not totally ignore PRIMARY nor I want to disable
> it; still, I want to have multiple selections.

Again, personal opinion.

>>  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?

Who said half of people like it your way?  Who said half of people like
it my way?  In lieu of a real usability study, you go with what the
developers prefer.

>> "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?

Just because it derives from GtkTextView doesn't mean it behaves the
same way.  I haven't checked it in a while, though.

>>  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.

Yes, but it's something that everyone who has a custom widget has to do.
  As in, you can't passively support it.  While it's not strictly "hard"
to do it, you have to know that the particular option is there to be
able to support it.  How many people can rattle off the list of all the
registered GtkSettings from memory?

As a random example, a piece of software I maintain had an option for
whether or not to show application icons in a menu for over a year
before I discovered the global gtk-menu-images setting.

I'll repeat something I said above, since it's really the only important
point to this email (assuming there actually is one): no one knows what
the mix is between people who prefer the current behavior or the
behavior you're advocating.  Unless someone does an actual usability
study, the general OSS practice is for the developers to decide the
behavior they like best.  So I guess your job is to convince enough
developers that your way is better, or at least find some way to prove
that the people who like your way is more than just a minority.

Anyway, I'm past the point of truly caring either way.  I just enjoy a
debate sometimes.  ^_^

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFEEM656XyW6VEeAnsRArOBAKDpDI0qdoCuw3d9HA9C59E+Nwrf0QCg4fsB
oC3KV5hhBIMdUhP9NNmwOu8=
=8BDc
-----END PGP SIGNATURE-----