Re: selected text is PRIMARY?

Hash: SHA1

On 3/9/2006 3:05 PM, Yevgen Muntyan wrote:
> Brian J. Tarricone wrote:
>> It's not really gtk that's in the wrong here - IMHO mozilla/firefox is
>> buggy.
> 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.

> 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.  Adding a pref to accomodate that
sounds like an consistency-breaking kludge[1].

> Some people believe there should be not more than one piece
> of selected text and they know about X selections and stuff, and
> are happy with that; another people believe that they should be
> able to have as many selections as they wish, like they select text
> to highlight it or use Ctrl-C to copy it to clipboard.
> These two points of view are both valid, this is why I am proposing
> a choice.

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.  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?  Sure, sure, it's a pref, and the default behavior
can stay the same.  Whatever.  Yay pref-bloat!

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


[1] Of course, one could (correctly) argue that consistency in this
matter is generally broken already across many apps on the X desktop,
unless you only use applications written using a single toolkit.  Even
then, consistency isn't guaranteed (Firefox, some versions of Anjuta, IIRC).


Version: GnuPG v1.4.1 (MingW32)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]