Charles de Miramon <[EMAIL PROTECTED]> writes:
> I tend to think that users like the clipboard to behave in a consistent way
> across the desktop.
That mail was a good read. Thanks ;-)
Angus
Angus Leeming wrote:
> Last time I looked, emacs was still widely used. For some reason, it
> hasn't died even after 10 years of KDE and Gnome. Maybe people use it
> because they like it? Shock horror!
Indeed, all the secretaries I know were using Emacs but since I showed them
that vim could sea
Bo Peng wrote:
> 1. open two instances of lyx, open tutorial
> 2. copy two lines (with new line) from one instance
> 3. paste external -> as lines in another lyx instance. lyx crashes.
Can't reproduce.
Georg
Charles de Miramon <[EMAIL PROTECTED]> writes:
> Well I know that you are an Emacs user and that you are accustomed to have
> an application that behaves differently than any other application.
Last time I looked, emacs was still widely used. For some reason, it hasn't died
even after 10 years of
Lars Gullik Bjønnes wrote:
> I am not so sure... it is very convenient to work with, and it takes
> minimal time to learn...
>
Well I know that you are an Emacs user and that you are accustomed to have
an application that behaves differently than any other application.
But LyX target market is
Georg Baum wrote:
Charles de Miramon wrote:
Does LyX manage the clipboard as a mime data object ?
http://doc.trolltech.com/4.2/qmimedata.html
Not yet, but that should come: http://bugzilla.lyx.org/show_bug.cgi?id=2138
It would be nice at some point to paste an image or to have some simple
c
Charles de Miramon wrote:
> Does LyX manage the clipboard as a mime data object ?
> http://doc.trolltech.com/4.2/qmimedata.html
Not yet, but that should come: http://bugzilla.lyx.org/show_bug.cgi?id=2138
> It would be nice at some point to paste an image or to have some simple
> converters on th
Bo Peng wrote:
> I meant selection followed by middle button in the same lyx window.
> lyx does not paste selection in this case. (This is kind of strange
> and there may be some problem with my installation.)
This works for me (note that the text must still be selected when you press
the middle
Charles de Miramon <[EMAIL PROTECTED]> writes:
| In a usability point of view, I think the selection clipboard should not be
| accessible from the menu. It is more something for power users.
I am not so sure... it is very convenient to work with, and it takes
minimal time to learn...
| I'm als
Georg Baum wrote:
> I think we should modify 2:
> 2. paste -> paste from external clipboard. If the external clipboard
> contains plain text this would be equivalent to the current "Clipboard as
> Lines". Only in that case we would also have "Clipboard as Paragraphs" as
> an extra menu option (th
I do not object to an edit->paste special -> as
line/paragraph/whatever. Other applications also have such things. I
just want edit->paste to paste external clipboard in a reasonable
default format. That is to say, if I copy formula (or graphics) from
one lyx instance, I should be able to paste it
> Selection (middle button):
> 1. can paste external selection. (right)
> 2. do not paste internal selection (need improvement)
What is "internal selection"? I think we have none,
I meant selection followed by middle button in the same lyx window.
lyx does not paste selection in this case. (Thi
Bo Peng wrote:
> As far as I can see, lyx behave like this:
>
> Selection (middle button):
> 1. can paste external selection. (right)
> 2. do not paste internal selection (need improvement)
What is "internal selection"? I think we have none, and we should not have
one. Selection is always global
If you want to develop a patch to integrate the internal clipboard with the
external clipboard: Great, but I think we should first discuss how it
should work.
As far as I can see, lyx behave like this:
Selection (middle button):
1. can paste external selection. (right)
2. do not paste internal
Bo Peng wrote:
> I think the reason is that recent applications like Kate conform to
> the standard better than emacs etc I should have tried Kate.
I tested it with some kde programs when developing the patch, and that
works.
> Anyway, if you open two lyx sessions, selection, copy, you can n
Strange. Here, I can copy some text in Oowriter with ctrl-C and paste it
with ctrl-v in Kate, the other clipboard pasted with the middle button is
independent from the first one.
Maybe, you have a broken Windows Manager.
I think the reason is that recent applications like Kate conform to
the st
Bo Peng wrote:
>> Copy/paste via clipboard or selection should be functionally
> BTW, I just played a bit under linux, using ooffice, firefox, emacs. I
> notice that the primary inter-application cut/paste has to be done
> with SELECTION, not CLIPBOARD. It looks like that the menu item
> copy/cut
Copy/paste via clipboard or selection should be functionally
equivalent. What I am trying to convey is a *standard*, *system* (no
internal/external differences) copy/paste mechanism that allows lyx to
communicate with other applications efficiently. And then, under some
platforms, allow the conven
And does selection catters for copy-pasting complex lyx objects, or
only ascii text? As a linux user, the latter would really annoy me.
Doing copy/paste with mouse only is great.
Copy/paste via clipboard or selection should be functionally
equivalent. What I am trying to convey is a *standard*,
Am Sonntag, 9. Juli 2006 19:22 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > This patch does not simplify cut-and-paste on windows. AFAIK it simply
> > makes it possible, but it is still not really integrated.
>
> Well Cut&Paste have always worked on windows. I think you mean pasting
> LyX
Georg Baum wrote:
Am Sonntag, 9. Juli 2006 18:40 schrieb Michael Gerz:
I didn't have the time to follow the complete thread in depth. However,
I wonder whether there is really a need to add another LFUN.
There is a need (but it will probably be only temporary). Please read the
other messages
Am Sonntag, 9. Juli 2006 18:40 schrieb Michael Gerz:
> I didn't have the time to follow the complete thread in depth. However,
> I wonder whether there is really a need to add another LFUN.
There is a need (but it will probably be only temporary). Please read the
other messages if you want to kn
Georg Baum wrote:
Index: src/LyXAction.C
===
--- src/LyXAction.C (Revision 14378)
+++ src/LyXAction.C (Arbeitskopie)
@@ -134,6 +134,7 @@ void LyXAction::init()
{ LFUN_CHAR_DELETE_FORWARD, "delete-forward", Si
Dear all,
Regarding the C-y pasting both from clipboard and selection, here is
the webpage Georg refers to says:
The current consensus is that interpretation b) is correct. Qt 3 and
GNU Emacs 21 will use interpretation b), changing the behavior of
previous versions.
So, even emacs changes. I th
Am Sonntag, 9. Juli 2006 12:13 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Index: src/frontends/gtk/GuiSelection.C
> | ===
> | --- src/frontends/gtk/GuiSelection.C(Revision 14378)
> | +++ src/fr
Georg Baum <[EMAIL PROTECTED]> writes:
| Index: src/frontends/gtk/GuiSelection.C
| ===
| --- src/frontends/gtk/GuiSelection.C (Revision 14378)
| +++ src/frontends/gtk/GuiSelection.C (Arbeitskopie)
| +// ENCODING: Gtk::Clipboard retu
Georg Baum <[EMAIL PROTECTED]> writes:
| > I do not really like the external/internal clipboard. Is there any
| > technique reason why can not they be merged?
|
| They should be merged in the future, but I don't know how exactly. There
| are two problems:
| 1) The internal clipboard is actually
Am Sonntag, 9. Juli 2006 01:41 schrieb Lars Gullik Bjønnes:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> + case LFUN_CLIPBOARD_PASTE:
> | case LFUN_PRIMARY_SELECTION_PASTE: {
> | cur.clearSelection();
> | - string const clip = bv->owner()->gui().clipboard().get();
> |
Georg Baum wrote:
Am Samstag, 8. Juli 2006 21:02 schrieb Bo Peng:
Do you mean the shortcuts for cut/copy/paste?
I meant the shortcut for paste.
Then C-x, C-c, and C-v.
This windows standard is accepted also by recent *nix applications
like ooffice. We have no reason to choose something spe
Am Sonntag, 9. Juli 2006 02:53 schrieb Bo Peng:
> > | Why don't we handle these two actions separately? My understanding
> > | is that the first should be triggered by C-v, the second by
> > | middle-button.
> >
> > Only on windows... on linux (with emacs bindings) C-y will yank from
> > selection.
Am Samstag, 8. Juli 2006 21:02 schrieb Bo Peng:
> Do you mean the shortcuts for cut/copy/paste?
I meant the shortcut for paste.
> Then C-x, C-c, and C-v.
> This windows standard is accepted also by recent *nix applications
> like ooffice. We have no reason to choose something special.
Indeed n
Am Samstag, 8. Juli 2006 22:17 schrieb Bo Peng:
> { LFUN_CHAR_FORWARD_SELECT, "forward-select", ReadOnly |
SingleParUpdate },
> + { LFUN_CLIPBOARD_PASTE, "clipboard-paste", Noop },
>
> For C-v or menu paste only, right?
Not C-v, only menu paste. C-v is bound to LFUN_PAS
Hello,
This looks good to me Georg. I did not reviewed the patch in detail yet
but I think I share Bo's concerns.
Thanks for doing this,
Abdel.
On Sunday 09 July 2006 01:53, Bo Peng wrote:
> I vote against this behavior. Users should be given a clear idea what
> C-y (or C-v) do. The webpage Georg refers to also recommends clear
> separation of CLIPBOARD and SELECTION.
OTOH if you use emacs keybindings you expect emacs behaviour...
--
| Why don't we handle these two actions separately? My understanding
| is that the first should be triggered by C-v, the second by
| middle-button.
Only on windows... on linux (with emacs bindings) C-y will yank from
selection., but also from clipboard... depends really...
I vote against this b
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > What is missing: Keyboard shortcuts for the new lfun, and a mechanism to
| > disable the selection lfun on systems that do not support a selection. We
| > also need to integrate the external clipboard with our internal
| > clipboard, but I don't know how.
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Sorry Georg, it is too complicated to apply your patch. I guess you
| can simply commit.
|
| { LFUN_CHAR_FORWARD_SELECT, "forward-select", ReadOnly |
SingleParUpdate },
| + { LFUN_CLIPBOARD_PASTE, "clipboard-paste", Noop },
|
| F
Sorry Georg, it is too complicated to apply your patch. I guess you
can simply commit.
{ LFUN_CHAR_FORWARD_SELECT, "forward-select", ReadOnly |
SingleParUpdate },
+ { LFUN_CLIPBOARD_PASTE, "clipboard-paste", Noop },
For C-v or menu paste only, right?
+ case
What is missing: Keyboard shortcuts for the new lfun, and a mechanism to
disable the selection lfun on systems that do not support a selection. We
also need to integrate the external clipboard with our internal
clipboard, but I don't know how. Does anybody have an idea for shortcuts?
Do you mean
The attached patch implements this behaviour.
I will try it out today. Clipboard has always been a problem with lyx
and I am really happy that you are working on it. Anything else I can
do for you?
Bo
LyX does currently only support the X selection. The clipboard is
unsupported, which is a problem especially on windows, since windows has
no selection.
The selection should be filled whenever a text is highlighted. The
selection contents should be pasted when the middle mouse button is
presse
41 matches
Mail list logo
