Re: selected text is PRIMARY?

[Yevgen Muntyan <muntyan tamu edu>]

Brian J. Tarricone wrote:

> 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.
>  
We can't! This is what I am talking about: I like this, and you like that,
and it's impossible to satisfy both. And this selection stuff is important
enough to add an option.

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

> Why make matters more confusing and inconsistent?
>  
To add valuable functionality.

> > 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.  
They are not supported. gtk supports shortcuts schemes, but
they do not work properly, since all applications use hard-coded
shortcuts instead of signals. Look at bugzilla for problems
arising when people use emacs scheme.

> > 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.
>  
Hm, okay.

> > > 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.
>  
I agree. Can we please get entry in FileChooser?

> > Anyway, I do not totally ignore PRIMARY nor I want to disable
> > it; still, I want to have multiple selections.
> >    
>
> Again, personal opinion.
>  
Yes, it's certainly my personal opinion about what I want :)

> > 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.
>  
This is the most important thing. Of course I am not able to
conduct usability study, and we have what gtk devs did.
The problem is that gtk developers do not use text widget
written by them (please don't tell about some entries in some
applications, I mean real work, like coding).

> > > "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.
>  
If it overrides GtkTextView behavior (I bet it doesn't),
it's its problem. It should know how to do it properly.

> > 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?
>  
You can't passively support clipboards. If you are writing a widget
from scratch, you must deal with clipboard api. If you are
implementing gtk-like behaviour, you must manually unselect
text when PRIMARY is stolen. Getting a setting value in that method
*is* easy.

> 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.
>  
Err, and? It sounds rather like an argument against gtk-menu-images
setting. Or like an example of why people should read api docs ;)

> Anyway, I'm past the point of truly caring either way.  I just enjoy a
> debate sometimes.  ^_^
>  
Well, thanks for this at least.

Regards,
Yevgen