Re: selected text is PRIMARY?

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.

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.


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