Re: Remaining selection/clipboard problems: How to proceed
I am not going to do further changes, so if anybody wants fake selection on windows, persistent selection or something else please take care of that yourself. Thank you very much. I get the persistent selection patch and will try it later. I can not work on it soon because I will be extremely busy in the next two weeks. Cheers, Bo
Re: Remaining selection/clipboard problems: How to proceed
Now that the clipboard works again on all platforms I give here a summary of the current status. Am Freitag, 5. Januar 2007 17:05 schrieb Georg Baum: > Let's start with our internal clipboard stack: This is advertised to the > user in the "paste recent" menu. If you know this it suddenly makes sense > that a middle mouse button press pushes the current selection to the > internal clipboard. So this is not a hack, but done on purpose. This is > only done for middle mouse button paste and not for C-v, since in the > latter case the stuff is already in the clipboard (at least if it comes > >from within LyX). Unfortunately this is only done in text, not in math nor > in tables. The attached patch x.diff implements the same mechanism for > tables and math and should go in IMO. Any objections? This has been applied. > The next question: The clipboard stack is not really a "paste recent" > stack: If you copy something in LyX without pasting it is nevertheless > added, and anything that is pasted but comes from outside (selection or > clipboard) is not added. That means that it is a bit inconsistent. To make > it consistent, we could decouple the stack from the clipboard and always > fill it on paste. The only disadvantage I see in doing so is that items > that you only copy do not appear anymore in the stack. Opinions? Nothing has been changed here, since there were too many opinions. > Then we need to decide how the selection should work. The current > implementation is almost what I want: No difference between "internal" > and "external" selection, only one application global selection exists: > Everything you select in LyX is advertised to the X server and can be > requested by other applications. If you select something in another > application LyX receives a SelectionClear event and clears the internal > selection. What is missing for this to be fully implemented are some calls > to theSelection().haveSelection() if the selection was modified by the > keyboard. No haveSelection call is missing AFAIK for selection changes by > the mouse. > > Question: Do we want to advertise keyboard and mouse selections differently > to X? IMO we should not, and because we do our own selection handling and > don't use qApp->clipboard()->setText() for this there is no performance > penalty. Unless there are some very good reasons not to advertise > selection changes by keyboard to X I am going to add the missing > haveSelection calls. This has been done, but only where we got a selection, not where we cleared it (for consistency reasons: This is the same as mouse selections are currently handled) > Fake X selection for windows and Mac: The patch I originally sent is not > needed anymore if the patch x.diff in this message is applied, since then > the internal selection is always used if available. If we want to paste > the clipboard with the middle mouse button on systems that don't have a > selection then we should do it like the patch fake-selection.diff. This is > against the "simple mental model" of the selection, so I don't like it, > but if windows users agree that this is useful I won't object. This is not in. AFAIK it is now as simple as the attached patch fake-selection2.diff. > Persistent selection: Some people want that a selection is still available > for middle mouse button paste after it is not visible on screen anymore, > and several applications implement that. This is against the "simple > mental model": The equation "selection == highlighted text on screen" > would not be true anymore. It is not needed either: It makes sense for > applications that don't have a clipboard, but since we have one we can as > well use C-c and C-v for copy/paste. > If a majority does not agree with me and somebody volunteers to implement > persistent selections I can outline how it can be done, but I won't > implement it myself. This is not very difficult to do, but would require > some code reorganizations. The attached patch is the forward ported version of a patch I sent some time ago. It is not complete (see FIXMEs), and not tested at all. Bo, if you want to finish this you have to look for missing calls of cap::finishSelection (they are need whenever the current selections is modified). I believe that I found almost all places where that is needed, but I might have missed some. > Related to persistent selections: Should a recieved SelectionClear event > clear the LyX selection or not? Again, some apps do this and others don't. > http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this > request, and this is currently done in LyX. Nothing has been changed here. I am not going to do further changes, so if anybody wants fake selection on windows, persistent selection or something else please take care of that yourself. IMHO both fake selection and persistent would be candidates for 1.5, all other stuff (extend the external clipboard to a
Re: Remaining selection/clipboard problems: How to proceed
Am Montag, 8. Januar 2007 10:03 schrieb Jean-Marc Lasgouttes: > I am OK with the fact that the list only contains (contained?) stuff > copied from within LyX, since this is coherent. That is still the case. > Concerning tables and maths, I would prefer them to be added, of > course. I did that. Georg
Re: Remaining selection/clipboard problems: How to proceed
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Am Freitag, 5. Januar 2007 18:00 schrieb Jean-Marc Lasgouttes: >> I like the current behaviour personally. It may need a rename, but >> I do not think it is wrong. Georg> Just to be clear: You mean the fact that copied-only stuff also Georg> appears in the stack, or the fact that only contents coming Georg> from LyX, not from external applications is considered? And do Georg> you also like the fact that math and tables are not considered Georg> for the stack, or should that be unified (the patch Georg> paste-recent.diff I sent)? I am OK with the fact that the list only contains (contained?) stuff copied from within LyX, since this is coherent. Concerning tables and maths, I would prefer them to be added, of course. JMarc
Re: Remaining selection/clipboard problems: How to proceed
On Sat, Jan 06, 2007 at 12:25:55PM +0100, Georg Baum wrote: > If you are not talking about X11 applications on X11, but about X11 > applications displayed on windows, using an X server that copies the > selection to the clipboard: Then you simply see that the selection can't > be completely emulated using the clipboard. Actually, I would like to be able to do what I already can do with LyX 1.4. The way Bo wants implementing it is changed behaviour in this regard. -- Enrico
Re: Remaining selection/clipboard problems: How to proceed
Am Samstag, 6. Januar 2007 01:17 schrieb Enrico Forestieri: > If I understand correctly, you would like to treat the selection as a > sort of internal clipboard which is allowed to be filled by a simple > selection and whose contents can be pasted with middle-button. That is how I understood it, too. > All of this would be internal, and would only be possible in the same > instance of lyx. Well, you will be able to do that if you will survive > the duel ;-) > > No, now seriously, don't you think that to allow this facility you are > sacrificing the interoperability of lyx with the other X11 applications? > I think so, and also believe that this is not worth. That depends on the implementation. If this feature will be implemented, it must be implemented in such a way that the internal selection buffer gets cleared if another applications requests selection ownership. This is AFAIK also how all other applications that have this feature implement it. If you are not talking about X11 applications on X11, but about X11 applications displayed on windows, using an X server that copies the selection to the clipboard: Then you simply see that the selection can't be completely emulated using the clipboard. Georg
Re: Remaining selection/clipboard problems: How to proceed
Am Freitag, 5. Januar 2007 21:25 schrieb Bo Peng: > > Sure you are welcome to implement it as a configurable option ;-) > > The problem I have with this is that > > OK. If this will make both of us happy. Of course I have the right to > set the default if I am writing the code. :-) I don't think this should be configurable, that would only add confusion. Bo is right when he says that his behaviour is an extension to the current one and that everybody who does not want it can simply pretend that it is not available. Georg
Re: Remaining selection/clipboard problems: How to proceed
Am Freitag, 5. Januar 2007 18:00 schrieb Jean-Marc Lasgouttes: > I like the current behaviour personally. It may need a rename, but I > do not think it is wrong. Just to be clear: You mean the fact that copied-only stuff also appears in the stack, or the fact that only contents coming from LyX, not from external applications is considered? And do you also like the fact that math and tables are not considered for the stack, or should that be unified (the patch paste-recent.diff I sent)? Georg
Re: Remaining selection/clipboard problems: How to proceed
On Fri, Jan 05, 2007 at 02:25:28PM -0600, Bo Peng wrote: > > Sure you are welcome to implement it as a configurable option ;-) > > The problem I have with this is that > > OK. If this will make both of us happy. Of course I have the right to > set the default if I am writing the code. :-) > > Anyway, I will have to wait for Georg to finish his selection cleanup, > and for his instructions. You'll also have to wait for the duel outcome ;-) -- Enrico
Re: Remaining selection/clipboard problems: How to proceed
On Fri, Jan 05, 2007 at 11:23:10AM -0600, Bo Peng wrote: > > Fake X selection for windows and Mac: The patch I originally sent is not > > needed anymore if the patch x.diff in this message is applied, since then > > the internal selection is always used if available. If we want to paste > > the clipboard with the middle mouse button on systems that don't have a > > selection then we should do it like the patch fake-selection.diff. This is > > against the "simple mental model" of the selection, so I don't like it, > > but if windows users agree that this is useful I won't object. > > I do not like 'middle-button paste clipboard at all' because I want > consistent behaviors across platforms. If there is no selection buffer > for some platforms, lyx should behave identically, just that there is > no inter-application selection and middle-button paste. Actually, there are a lot of applications on Windows for which inter-application selection and middle-button paste would work: All the X11 applications running either locally or remotely but with a local display would benefit of this. Actually, I run a lot of them and I am able to select text in them and paste by middle-button in lyx. Even with your cygwin port of lyx I can select text and paste by middle-button in a native instance of lyx in 1.4.x, but not in 1.5.0. Suddenly, I (and all other users of these applications) would not be able to do that, and I think that the buzzing in your ears will become unbearable ;-) Thinking about that, I am ready to fight a duel with you. I'll leave the choice about the weapon to you ;-) > > Persistent selection is against the "simple > > mental model": The equation "selection == highlighted text on screen" > > would not be true anymore. > > There is another simple mental model: selection, copy to selection > buffer. middle-button paste, paste from selection buffer. This model > may be easier to understand since it is what clipboard does. If I understand correctly, you would like to treat the selection as a sort of internal clipboard which is allowed to be filled by a simple selection and whose contents can be pasted with middle-button. All of this would be internal, and would only be possible in the same instance of lyx. Well, you will be able to do that if you will survive the duel ;-) No, now seriously, don't you think that to allow this facility you are sacrificing the interoperability of lyx with the other X11 applications? I think so, and also believe that this is not worth. -- Enrico
Re: Remaining selection/clipboard problems: How to proceed
On Fri, Jan 05, 2007 at 06:00:55PM +0100, Jean-Marc Lasgouttes wrote: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > >> Fake X selection for windows and Mac: The patch I originally sent > >> is not needed anymore if the patch x.diff in this message is > >> applied, since then the internal selection is always used if > >> available. If we want to paste the clipboard with the middle mouse > >> button on systems that don't have a selection then we should do it > >> like the patch fake-selection.diff. This is against the "simple > >> mental model" of the selection, so I don't like it, but if windows > >> users agree that this is useful I won't object. > > Abdelrazak> I personally like it and I am sure others will (and Enrico > Abdelrazak> will be the first ;-)). But I could live without and just > Abdelrazak> using mouse-click plus Ctrl-v. > > The real native method is selection drag-and-drop on windows, isn't it? That would be for cut&paste, not copy&paste. -- Enrico
Re: Remaining selection/clipboard problems: How to proceed
Sure you are welcome to implement it as a configurable option ;-) The problem I have with this is that OK. If this will make both of us happy. Of course I have the right to set the default if I am writing the code. :-) Anyway, I will have to wait for Georg to finish his selection cleanup, and for his instructions. Cheers, Bo
Re: Remaining selection/clipboard problems: How to proceed
Bo Peng wrote: Please note that the X selection protocol is supposed to be asynchronous i.e. copy should happen at paste time. The X selection is not an additional clipboard. I agree with you completely here, but again, you are talking about tech details, and I am talking about user experience. We (users) do not know what is asynchronous and have all the rights to believe that selection is a without-C-c clipboard, especially when firefox, gvim, nedit, emacs all appear so. Then, lacking such a feature in lyx will somehow become lyx' fault. OK, but please note that the x selection is a feature for pretty advanced users. But hey, the first time you paste your selection, it is recorded so I agree that we can reuse it if you want. So, you are free to only paste highlighted selection, and I will implement and enjoy this extension. Sure you are welcome to implement it as a configurable option ;-) The problem I have with this is that Abdel. Bo
Re: Remaining selection/clipboard problems: How to proceed
Bo Peng wrote: > There is another simple mental model: selection, copy to selection > buffer. middle-button paste, paste from selection buffer. This model > may be easier to understand since it is what clipboard does. I don't like that, but I can live with that, leT's see what other think. it worth pointing out that this behavior is an extension of yours so people are free to think and use middle-button paste in either way. I like this behavior because I get used to locate (by left click) and then paste with middle button. Without a blinking cursor, I am not quite sure where my selection will be pasted. :-) Just add a Ctrl-C in your recipe and you are done ;-) Context menu would help here if you don't want to touch the keyboard... but that's another story. Abdel.
Re: Remaining selection/clipboard problems: How to proceed
Please note that the X selection protocol is supposed to be asynchronous i.e. copy should happen at paste time. The X selection is not an additional clipboard. I agree with you completely here, but again, you are talking about tech details, and I am talking about user experience. We (users) do not know what is asynchronous and have all the rights to believe that selection is a without-C-c clipboard, especially when firefox, gvim, nedit, emacs all appear so. Then, lacking such a feature in lyx will somehow become lyx' fault. So, you are free to only paste highlighted selection, and I will implement and enjoy this extension. Bo
Re: Remaining selection/clipboard problems: How to proceed
Georg Baum wrote: Am Freitag, 5. Januar 2007 18:23 schrieb Bo Peng: Persistent selection is against the "simple mental model": The equation "selection == highlighted text on screen" would not be true anymore. There is another simple mental model: selection, copy to selection buffer. middle-button paste, paste from selection buffer. This model may be easier to understand since it is what clipboard does. I don't like that, but I can live with that, leT's see what other think. Me neither. And please note that the X selection protocol is supposed to be asynchronous i.e. copy should happen at paste time. The X selection is not an additional clipboard. Abdel.
Re: Remaining selection/clipboard problems: How to proceed
> There is another simple mental model: selection, copy to selection > buffer. middle-button paste, paste from selection buffer. This model > may be easier to understand since it is what clipboard does. I don't like that, but I can live with that, leT's see what other think. it worth pointing out that this behavior is an extension of yours so people are free to think and use middle-button paste in either way. I like this behavior because I get used to locate (by left click) and then paste with middle button. Without a blinking cursor, I am not quite sure where my selection will be pasted. :-) Bo
Re: Remaining selection/clipboard problems: How to proceed
> 2. if this is going to be implemented, do so also under X11. What do you mean by 2? Pasting the clipboard if the selection is empty? That would destroy the simple selection model. Enrico's argument was that this model does not apply to windows. Although I don't agree I could live with that, but on X11 pasting the clipboard is clearly wrong. Then it is wrong, it should not be implemented under windows for consistency reasons. 'The model does not apply to windows' is not completely correct since we are emulating selection under windows. Bo
Re: Remaining selection/clipboard problems: How to proceed
Am Freitag, 5. Januar 2007 18:27 schrieb Bo Peng: > > I personally like it and I am sure others will (and Enrico will be the > > first ;-)). But I could live without and just using mouse-click plus Ctrl-v. > > OK. I can step back a little bit: > > 1. if this behavior is undefined in freedesktop.org, it is ok to me. > 2. if this is going to be implemented, do so also under X11. What do you mean by 2? Pasting the clipboard if the selection is empty? That would destroy the simple selection model. Enrico's argument was that this model does not apply to windows. Although I don't agree I could live with that, but on X11 pasting the clipboard is clearly wrong. Georg
Re: Remaining selection/clipboard problems: How to proceed
Am Freitag, 5. Januar 2007 18:23 schrieb Bo Peng: > For MS Word, > > 1. consecutive identical copies is put to clipboard stack only once > (clipboard content is compared against the top item) > 2. copy from external application is copied to this stack > 3. no paste is necessary, of course word has no concept of selection buffer > 4. the most useful feature is actually 'paste all' in that people > gather pieces of texts here and there, and paste them altogether. > > Depending how you want this feature be, it can be > > 1. removed > 2. be paste recent (what you suggested) > 3. be clipboard stack (maybe called clipboards) that store all > clipboard copy (from lyx and other application), and middle-button > paste if you wish. > > I personally prefer 1. :-) That is no option as I learned from old discussions in summer ;-( > I do not like 'middle-button paste clipboard at all' because I want > consistent behaviors across platforms. If there is no selection buffer > for some platforms, lyx should behave identically, just that there is > no inter-application selection and middle-button paste. That is the case already (except for tables, see patch in the previous mail). > > Persistent selection is against the "simple > > mental model": The equation "selection == highlighted text on screen" > > would not be true anymore. > > There is another simple mental model: selection, copy to selection > buffer. middle-button paste, paste from selection buffer. This model > may be easier to understand since it is what clipboard does. I don't like that, but I can live with that, leT's see what other think. > Please do so if I have to follow the 'you want it, you implement it rule'. :-) I'll do so after I finished the pending stuff. > I prefer clearing the selection with a redraw, but Abdel disagree. :-) > I do not have strong belief in this though. > > The actually problem is consistency. Right now, left button click > clears selection, but not if I select some text from another > application and click back. I think I know why. Some haveSelection(false) calls are missing (I will address that when I add the needed calls for keyboard selection). And I believe that the comment // We don't need to do anything if own = false, as this case is // handled by QT. in haveSelection() is wrong. Georg
Re: Remaining selection/clipboard problems: How to proceed
Am Freitag, 5. Januar 2007 17:35 schrieb Abdelrazak Younes: > Internally, when using multiple views, I am strongly against > un-selecting a selected text when this selected text is pasted onto the > other view. Externally (when a SelectionClear event is received) I could > live with a deselection but that would be inconsistent with the internal > behaviour. So I'd prefer that we don't. We should of course be consistent. Either dselect the text also if something is selected in a different view, or not honor the SelectionClear event. Georg
Re: Remaining selection/clipboard problems: How to proceed
I personally like it and I am sure others will (and Enrico will be the first ;-)). But I could live without and just using mouse-click plus Ctrl-v. OK. I can step back a little bit: 1. if this behavior is undefined in freedesktop.org, it is ok to me. 2. if this is going to be implemented, do so also under X11. Bo
Re: Remaining selection/clipboard problems: How to proceed
Let's start with our internal clipboard stack: This is advertised to the user in the "paste recent" menu. If you know this it suddenly makes sense that a middle mouse button press pushes the current selection to the internal clipboard. So this is not a hack, but done on purpose. This is only done for middle mouse button paste and not for C-v, since in the latter case the stuff is already in the clipboard (at least if it comes from within LyX). Unfortunately this is only done in text, not in math nor in tables. The attached patch x.diff implements the same mechanism for tables and math and should go in IMO. Any objections? You mean this stack is actually a clipboard-selection stack, right? I have no objection on the change. The next question: The clipboard stack is not really a "paste recent" stack: If you copy something in LyX without pasting it is nevertheless added, and anything that is pasted but comes from outside (selection or clipboard) is not added. That means that it is a bit inconsistent. To make it consistent, we could decouple the stack from the clipboard and always fill it on paste. The only disadvantage I see in doing so is that items that you only copy do not appear anymore in the stack. Opinions? For MS Word, 1. consecutive identical copies is put to clipboard stack only once (clipboard content is compared against the top item) 2. copy from external application is copied to this stack 3. no paste is necessary, of course word has no concept of selection buffer 4. the most useful feature is actually 'paste all' in that people gather pieces of texts here and there, and paste them altogether. Depending how you want this feature be, it can be 1. removed 2. be paste recent (what you suggested) 3. be clipboard stack (maybe called clipboards) that store all clipboard copy (from lyx and other application), and middle-button paste if you wish. I personally prefer 1. :-) Then we need to decide how the selection should work. The current implementation is almost what I want: No difference between "internal" and "external" selection, only one application global selection exists: Everything you select in LyX is advertised to the X server and can be requested by other applications. If you select something in another application LyX receives a SelectionClear event and clears the internal selection. What is missing for this to be fully implemented are some calls to theSelection().haveSelection() if the selection was modified by the keyboard. No haveSelection call is missing AFAIK for selection changes by the mouse. Unless there are some very good reasons not to advertise selection changes by keyboard to X I am going to add the missing haveSelection calls. I agree with you that selection, by mouse or keyboard should be treated equally. Fake X selection for windows and Mac: The patch I originally sent is not needed anymore if the patch x.diff in this message is applied, since then the internal selection is always used if available. If we want to paste the clipboard with the middle mouse button on systems that don't have a selection then we should do it like the patch fake-selection.diff. This is against the "simple mental model" of the selection, so I don't like it, but if windows users agree that this is useful I won't object. I do not like 'middle-button paste clipboard at all' because I want consistent behaviors across platforms. If there is no selection buffer for some platforms, lyx should behave identically, just that there is no inter-application selection and middle-button paste. Persistent selection is against the "simple mental model": The equation "selection == highlighted text on screen" would not be true anymore. There is another simple mental model: selection, copy to selection buffer. middle-button paste, paste from selection buffer. This model may be easier to understand since it is what clipboard does. I can outline how it can be done, but I won't implement it myself. This is not very difficult to do, but would require some code reorganizations. Please do so if I have to follow the 'you want it, you implement it rule'. :-) Related to persistent selections: Should a recieved SelectionClear event clear the LyX selection or not? Again, some apps do this and others don't. http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this request, and this is currently done in LyX. I prefer clearing the selection with a redraw, but Abdel disagree. :-) I do not have strong belief in this though. The actually problem is consistency. Right now, left button click clears selection, but not if I select some text from another application and click back. Good job! Bo
Re: Remaining selection/clipboard problems: How to proceed
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> The next question: The clipboard stack is not really a "paste >> recent" stack: If you copy something in LyX without pasting it is >> nevertheless added, and anything that is pasted but comes from >> outside (selection or clipboard) is not added. That means that it >> is a bit inconsistent. To make it consistent, we could decouple the >> stack from the clipboard and always fill it on paste. The only >> disadvantage I see in doing so is that items that you only copy do >> not appear anymore in the stack. Opinions? Abdelrazak> IMHO, what is important is what you paste not what you Abdelrazak> copy. So I think "paste recent" should only present what Abdelrazak> have been pasted recently regardless of what has been Abdelrazak> copied. I often change my mind when I hit C-c and I don't Abdelrazak> want all those tentative to show up in the menu. So I'd Abdelrazak> say decouple. I like the current behaviour personally. It may need a rename, but I do not think it is wrong. >> Fake X selection for windows and Mac: The patch I originally sent >> is not needed anymore if the patch x.diff in this message is >> applied, since then the internal selection is always used if >> available. If we want to paste the clipboard with the middle mouse >> button on systems that don't have a selection then we should do it >> like the patch fake-selection.diff. This is against the "simple >> mental model" of the selection, so I don't like it, but if windows >> users agree that this is useful I won't object. Abdelrazak> I personally like it and I am sure others will (and Enrico Abdelrazak> will be the first ;-)). But I could live without and just Abdelrazak> using mouse-click plus Ctrl-v. The real native method is selection drag-and-drop on windows, isn't it? JMarc
Re: Remaining selection/clipboard problems: How to proceed
Georg Baum wrote: I think that I now fully understand how the selection is handled in LyX. /me too ;-) I have now documented the current code, and fixed some bugs, see the cvslog postings or read the code for details. Since there have been several opinions how selection should work I'll outline here the possible options. Let's start with our internal clipboard stack: This is advertised to the user in the "paste recent" menu. If you know this it suddenly makes sense that a middle mouse button press pushes the current selection to the internal clipboard. So this is not a hack, but done on purpose. This is only done for middle mouse button paste and not for C-v, since in the latter case the stuff is already in the clipboard (at least if it comes from within LyX). Unfortunately this is only done in text, not in math nor in tables. The attached patch x.diff implements the same mechanism for tables and math and should go in IMO. Any objections? Fine with me. The next question: The clipboard stack is not really a "paste recent" stack: If you copy something in LyX without pasting it is nevertheless added, and anything that is pasted but comes from outside (selection or clipboard) is not added. That means that it is a bit inconsistent. To make it consistent, we could decouple the stack from the clipboard and always fill it on paste. The only disadvantage I see in doing so is that items that you only copy do not appear anymore in the stack. Opinions? IMHO, what is important is what you paste not what you copy. So I think "paste recent" should only present what have been pasted recently regardless of what has been copied. I often change my mind when I hit C-c and I don't want all those tentative to show up in the menu. So I'd say decouple. [...] Question: Do we want to advertise keyboard and mouse selections differently to X? IMO we should not, and because we do our own selection handling and don't use qApp->clipboard()->setText() for this there is no performance penalty. Unless there are some very good reasons not to advertise selection changes by keyboard to X I am going to add the missing haveSelection calls. I've changed my mind on this point after reading the freedesktop document so I'd say go for it. Fake X selection for windows and Mac: The patch I originally sent is not needed anymore if the patch x.diff in this message is applied, since then the internal selection is always used if available. If we want to paste the clipboard with the middle mouse button on systems that don't have a selection then we should do it like the patch fake-selection.diff. This is against the "simple mental model" of the selection, so I don't like it, but if windows users agree that this is useful I won't object. I personally like it and I am sure others will (and Enrico will be the first ;-)). But I could live without and just using mouse-click plus Ctrl-v. Persistent selection: Some people want that a selection is still available for middle mouse button paste after it is not visible on screen anymore, and several applications implement that. This is against the "simple mental model": The equation "selection == highlighted text on screen" would not be true anymore. It is not needed either: It makes sense for applications that don't have a clipboard, but since we have one we can as well use C-c and C-v for copy/paste. If a majority does not agree with me and somebody volunteers to implement persistent selections I can outline how it can be done, but I won't implement it myself. This is not very difficult to do, but would require some code reorganizations. I don't care for persistent selection and I agree that the Clipboard is here for that. Related to persistent selections: Should a recieved SelectionClear event clear the LyX selection or not? Again, some apps do this and others don't. http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this request, and this is currently done in LyX. Internally, when using multiple views, I am strongly against un-selecting a selected text when this selected text is pasted onto the other view. Externally (when a SelectionClear event is received) I could live with a deselection but that would be inconsistent with the internal behaviour. So I'd prefer that we don't. Abdel.
Remaining selection/clipboard problems: How to proceed
I think that I now fully understand how the selection is handled in LyX. I have now documented the current code, and fixed some bugs, see the cvslog postings or read the code for details. Since there have been several opinions how selection should work I'll outline here the possible options. Let's start with our internal clipboard stack: This is advertised to the user in the "paste recent" menu. If you know this it suddenly makes sense that a middle mouse button press pushes the current selection to the internal clipboard. So this is not a hack, but done on purpose. This is only done for middle mouse button paste and not for C-v, since in the latter case the stuff is already in the clipboard (at least if it comes from within LyX). Unfortunately this is only done in text, not in math nor in tables. The attached patch x.diff implements the same mechanism for tables and math and should go in IMO. Any objections? The next question: The clipboard stack is not really a "paste recent" stack: If you copy something in LyX without pasting it is nevertheless added, and anything that is pasted but comes from outside (selection or clipboard) is not added. That means that it is a bit inconsistent. To make it consistent, we could decouple the stack from the clipboard and always fill it on paste. The only disadvantage I see in doing so is that items that you only copy do not appear anymore in the stack. Opinions? Please, if you comment on anything below read http://freedesktop.org/wiki/Standards_2fClipboardsWiki (and the references given therein if necessary) if you did not do so already. The discussion will be a lot easier if everybody knows how the X selection works. Then we need to decide how the selection should work. The current implementation is almost what I want: No difference between "internal" and "external" selection, only one application global selection exists: Everything you select in LyX is advertised to the X server and can be requested by other applications. If you select something in another application LyX receives a SelectionClear event and clears the internal selection. What is missing for this to be fully implemented are some calls to theSelection().haveSelection() if the selection was modified by the keyboard. No haveSelection call is missing AFAIK for selection changes by the mouse. Question: Do we want to advertise keyboard and mouse selections differently to X? IMO we should not, and because we do our own selection handling and don't use qApp->clipboard()->setText() for this there is no performance penalty. Unless there are some very good reasons not to advertise selection changes by keyboard to X I am going to add the missing haveSelection calls. Fake X selection for windows and Mac: The patch I originally sent is not needed anymore if the patch x.diff in this message is applied, since then the internal selection is always used if available. If we want to paste the clipboard with the middle mouse button on systems that don't have a selection then we should do it like the patch fake-selection.diff. This is against the "simple mental model" of the selection, so I don't like it, but if windows users agree that this is useful I won't object. Persistent selection: Some people want that a selection is still available for middle mouse button paste after it is not visible on screen anymore, and several applications implement that. This is against the "simple mental model": The equation "selection == highlighted text on screen" would not be true anymore. It is not needed either: It makes sense for applications that don't have a clipboard, but since we have one we can as well use C-c and C-v for copy/paste. If a majority does not agree with me and somebody volunteers to implement persistent selections I can outline how it can be done, but I won't implement it myself. This is not very difficult to do, but would require some code reorganizations. Related to persistent selections: Should a recieved SelectionClear event clear the LyX selection or not? Again, some apps do this and others don't. http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this request, and this is currently done in LyX. I hope I have not forgotten anything. I know that the behaviour I want and what is recommended by http://freedesktop.org/wiki/Standards_2fClipboardsWiki and http://www.jwz.org/doc/x-cut-and-paste.html is not what many applications implement. I want it nevertheless because of two reasons: - The simple mental model of selection - Most of the fancy stuff that some applications implement with selections is not needed if you have proper clipboard support. BTW, I will ignore every argument for a certain behaviour that has the word "klipper" in it. klipper is a big mistake (you can even find workarounds for it in the qt source), and clearly violates the quasi standard described in http://freedesktop.org/wiki/Standards_2fClipboardsWiki. Georg In
