Re: Crashes & selection bug in split view

Le 21/10/2018 à 09:18, Andrew Parsloe a écrit : Since updating to 2.3.1-1 (on windows 7) I am getting sporadic but recurrent crashes -- about 4 now. The message is always I do not see the crash, but I can confirm that when the workarea is split (horizontally or vertically) and one is

Re: Weird Selection Bug

Le 06/09/2016 à 10:33, Helge Hafting a écrit : Den 05. sep. 2016 14:59, skrev Jean-Marc Lasgouttes: Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor

Re: Weird Selection Bug

Den 05. sep. 2016 14:59, skrev Jean-Marc Lasgouttes: Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the

Re: Weird Selection Bug

Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the position of "the previous mouseclick" to the current

Re: Weird Selection Bug

Den 31. aug. 2016 16:33, skrev Jean-Marc Lasgouttes: Le 31/08/2016 à 11:51, Helge Hafting a écrit : Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Are you sure? I do not see that. I now look at a light blue highlighted selection that goes from the second line to the third. The first

Re: Weird Selection Bug

Le 31/08/2016 à 11:51, Helge Hafting a écrit : Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Are you sure? I do not see that. I now look at a light blue highlighted selection that goes from the second line to the third. The first line mentioned is not an endpoint - it is forgotten by

Re: Weird Selection Bug

Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Le 23/08/2016 à 11:25, Helge Hafting a écrit : No! Fortunately, LyX 2.2 on linux behave the way I expect: When I shift-click somewhere, I get a selection from the current text cursor point to the shift-click point. No matter how the text

Re: Weird Selection Bug

Le 23/08/2016 à 18:27, Richard Heck a écrit : If it works, I can backport it, of course. Works here. Fine to backport. Done, thanks. JMarc

Re: Weird Selection Bug

On 08/23/2016 09:54 AM, Jean-Marc Lasgouttes wrote: > Le 23/08/2016 à 12:23, Jean-Marc Lasgouttes a écrit : >> Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : >>> This is indeed a bug. The selection anchor is not reset when moving the >>> cursor with the keyboard. It should be reset just

Re: Weird Selection Bug

Le 23/08/2016 à 12:23, Jean-Marc Lasgouttes a écrit : Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : This is indeed a bug. The selection anchor is not reset when moving the cursor with the keyboard. It should be reset just before honoring the Shift-Click, but I am not sure how to do

Re: Weird Selection Bug

Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : This is indeed a bug. The selection anchor is not reset when moving the cursor with the keyboard. It should be reset just before honoring the Shift-Click, but I am not sure how to do that. I think it is fixed in master now. Please test.

Re: Weird Selection Bug

Le 23/08/2016 à 11:25, Helge Hafting a écrit : No! Fortunately, LyX 2.2 on linux behave the way I expect: When I shift-click somewhere, I get a selection from the current text cursor point to the shift-click point. No matter how the text cursor got there. Are you sure? I do not see that.

Re: Weird Selection Bug

Den 02. aug. 2016 08:11, skrev Kornel Benko: Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: Click somewhere with the mouse. Now move the cursor with the keyboard. Then shift-click to select.

Re: Weird Selection Bug

Le 02/08/2016 à 07:39, Stephan Witt a écrit : OTOH starting the selection at the current cursor position after moving the input focus with keyboard is the way it works on Mac - with LyX and with other text editors. +1, not just on Mac

Re: Weird Selection Bug

Am 02.08.2016 um 08:11 schrieb Kornel Benko : > > Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak > >> On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: >>> Click somewhere with the mouse. Now move the cursor with the keyboard. >>>

Re: Weird Selection Bug

Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak > On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: > > Click somewhere with the mouse. Now move the cursor with the keyboard. > > Then shift-click to select. The selection will begin (or end) where

Re: Weird Selection Bug

On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: > Click somewhere with the mouse. Now move the cursor with the keyboard. > Then shift-click to select. The selection will begin (or end) where you > had previously clicked with the mouse, not where you had moved the > cursor with the

Weird Selection Bug

Click somewhere with the mouse. Now move the cursor with the keyboard. Then shift-click to select. The selection will begin (or end) where you had previously clicked with the mouse, not where you had moved the cursor with the keyboard. Richard

Viewer Selection Bug

In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. Richard

Re: Viewer Selection Bug

rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. *Sigh*. Seems I repeat my faults:

Re: Viewer Selection Bug

On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time

Re: Viewer Selection Bug

On 10/16/2009 12:18 PM, rgheck wrote: On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is

Viewer Selection Bug

In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. Richard

Re: Viewer Selection Bug

rgheck wrote: > In trunk, I seem to have a billion converters listed for DVI. The > billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort > of thing for PDF. I think what's likely happening is that things are > being added each time I reconfigure. *Sigh*. Seems I repeat my

Re: Viewer Selection Bug

On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time

Re: Viewer Selection Bug

On 10/16/2009 12:18 PM, rgheck wrote: On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is

Re: Selection without a selection [Bug 5162]

JMarc already mentioned it and I already apologized for disrespecting the style. Do not worry, I do not think André is expecting an apoolgy, although one never knows what he might be up to... JMarc

Re: Selection without a selection [Bug 5162]

JMarc already mentioned it and I already apologized for disrespecting the style. Do not worry, I do not think André is expecting an apoolgy, although one never knows what he might be up to... JMarc

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: Enter some text and insert a Note (without a space in between). When you select text in front of and adjacent to the Note, right-clicking the button of the Note won't clear the selection. This means that when the cursor is not immediately

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: What is the wanted behaviour for right-clicking inside the insets. Right-clicking inside a Float will open the edit context menu, while right-clicking inside a Note, ERT, Box, ... will open the context menu of the inset. I think that

RE: Selection without a selection [Bug 5162]

Try again. Now, when there is a selection, the context menu is always the one of the inset containing the selection. //If there is a selection, return the containing inset menu 537 if (d-cursor_.selection()) 538 return d-cursor_.inset().contextMenu(*this, x,

RE: Selection without a selection [Bug 5162]

-- Ignore the previous mail, send by accident --

RE: Selection without a selection [Bug 5162]

//If there is a selection, return the containing inset menu 537 if (d-cursor_.selection()) 538 return d-cursor_.inset().contextMenu(*this, x, y); Is it now ensured that you click on the selection and not outside the selection ? The folowing patch will solve

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: //If there is a selection, return the containing inset menu 537 if (d-cursor_.selection()) 538 return d-cursor_.inset().contextMenu(*this, x, y); Is it now ensured that you click on the selection and not

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: The folowing patch will solve the problem of bug 5156 discussed before. Selecting the character at position 6 gives a selectionEnd at pos 7 and a selectionBegin at pos 6. Checking for the current selection using = and = always results in

Re: Selection without a selection [Bug 5162]

[still replying separately to the different chunks...] Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: Last, Jmarc: you changed the code below, but I think you should only update the cursor position when the current cursor position is outside the Inset. Otherwise when you are editing

Re: Selection without a selection [Bug 5162]

[and now try to answer the annoying one :)] Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: About the dissolve inset items and stuff. I added this to the code and it solves the problem (a bit), but I have to try and figure out what the exact behaviour is. It is more or less copied from

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: Then, I altered the InsetNote code to give a context-edit menu when you right-click the text-part and a context-note menu when you right-click the button. This code is probably useful for all InsetCollapsables, so this code has to be moved

RE: Selection without a selection [Bug 5162]

The behaviour of these inset-related functions (toggle, dissolve, settings) is supposed to be: 1/ if there is a inset at cursor, try the function on it 2/ if there is no inset or the function failed try on the enclosing inset. Does it make sense? It is one reason why the cursor

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: Sorry for the style, I wasn't too sure about that piece of code, so I lacked being precise. Normally I'm careful to adjust to the rest of the code. That is OK, I am just preparing to be able to directly apply your patches in the future :)

Re: Selection without a selection [Bug 5162]

On Thu, Aug 14, 2008 at 12:09:39PM +0200, Vincent van Ravesteijn - TNW wrote: Index: src/insets/InsetCollapsable.cpp === --- src/insets/InsetCollapsable.cpp (revision 26147) +++ src/insets/InsetCollapsable.cpp (working copy)

RE: Selection without a selection [Bug 5162]

Incidentally, if you want to have your patches easy to apply please stick to the LyX coding conventions as outlined in development/coding/{Rules,Recommendations} Andre' JMarc already mentioned it and I already apologized for disrespecting the style. The patches within that e-mail weren't

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Enter some text and insert a Note (without a space in between). When you > select text in front of and adjacent to the Note, right-clicking the > button of the Note won't clear the selection. This means that when the > cursor is not

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > What is the wanted behaviour for right-clicking inside the insets. > Right-clicking inside a Float will open the edit context menu, while > right-clicking inside a Note, ERT, Box, ... will open the context > menu of the inset. > > I

RE: Selection without a selection [Bug 5162]

> Try again. Now, when there is a selection, the context menu is always > the one of the inset containing the selection. //If there is a selection, return the containing inset menu 537 if (d->cursor_.selection()) 538 return d->cursor_.inset().contextMenu(*this,

RE: Selection without a selection [Bug 5162]

-- Ignore the previous mail, send by accident --

RE: Selection without a selection [Bug 5162]

> //If there is a selection, return the containing inset menu > 537 if (d->cursor_.selection()) > 538 return d->cursor_.inset().contextMenu(*this, x, y); Is it now ensured that you click on the selection and not outside the selection ? The folowing patch will

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: >> //If there is a selection, return the containing inset menu >> 537 if (d->cursor_.selection()) >> 538 return d->cursor_.inset().contextMenu(*this, x, > y); > > Is it now ensured that you click on the

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > The folowing patch will solve the problem of bug 5156 discussed before. > Selecting the character at position 6 gives a selectionEnd at pos 7 and > a selectionBegin at pos 6. Checking for the current selection using <= > and >= always

Re: Selection without a selection [Bug 5162]

[still replying separately to the different chunks...] "Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Last, Jmarc: you changed the code below, but I think you should only > update the cursor position when the current cursor position is outside > the Inset. Otherwise when you are

Re: Selection without a selection [Bug 5162]

[and now try to answer the annoying one :)] "Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > About the dissolve inset items and stuff. I added this to the code and > it solves the problem (a bit), but I have to try and figure out what the > exact behaviour is. It is more or less

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Then, I altered the InsetNote code to give a context-edit menu when you > right-click the text-part and a context-note menu when you right-click > the button. This code is probably useful for all InsetCollapsables, so > this code has to

RE: Selection without a selection [Bug 5162]

> The behaviour of these inset-related functions (toggle, dissolve, > settings) is supposed to be: > > 1/ if there is a inset at cursor, try the function on it > > 2/ if there is no inset or the function failed try on the enclosing inset. > > Does it make sense? > > It is one reason why the

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Sorry for the style, I wasn't too sure about that piece of code, so I > lacked being precise. Normally I'm careful to adjust to the rest of the > code. That is OK, I am just preparing to be able to directly apply your patches in the

Re: Selection without a selection [Bug 5162]

On Thu, Aug 14, 2008 at 12:09:39PM +0200, Vincent van Ravesteijn - TNW wrote: > Index: src/insets/InsetCollapsable.cpp > === > --- src/insets/InsetCollapsable.cpp (revision 26147) > +++ src/insets/InsetCollapsable.cpp (working

RE: Selection without a selection [Bug 5162]

> Incidentally, if you want to have your patches easy to apply please > stick to the LyX coding conventions as outlined in > development/coding/{Rules,Recommendations} > > Andre' JMarc already mentioned it and I already apologized for disrespecting the style. The patches within that e-mail

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW wrote: I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance.

Re: Selection without a selection [Bug 5162]

rgheck [EMAIL PROTECTED] writes: Vincent van Ravesteijn - TNW wrote: I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX

RE: Selection without a selection [Bug 5162]

choose this on the context menu. Vincent -Original Message- From: rgheck [mailto:[EMAIL PROTECTED] Sent: woensdag 13 augustus 2008 16:34 To: Vincent van Ravesteijn - TNW Cc: lyx-devel@lists.lyx.org Subject: Re: Selection without a selection [Bug 5162] Vincent van Ravesteijn - TNW wrote

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: I already added a sort of a 'patch' to the bug in bugzilla, which looks like to solve the problem. It calls the function Cursor::setSelection(). The patch makes sense actually. You should even remove the 'selection() = true' statement

Re: Selection without a selection [Bug 5162]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: For example: right-clicking on a Note while the cursor is inside another Note. Without knowing about this bug, you never know which Note will be changed into 'Greyed Out' if you choose this on the context menu. But this is a completely different

RE: Selection without a selection [Bug 5162]

For example: right-clicking on a Note while the cursor is inside another Note. Without knowing about this bug, you never know which Note will be changed into 'Greyed Out' if you choose this on the context menu. But this is a completely different bug, right? Probably introduced by me, BTW.

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: I already added a sort of a 'patch' to the bug in bugzilla, which looks like to solve the problem. It calls the function Cursor::setSelection(). Although the name is not really describing what it does, a comment inside this function

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW [EMAIL PROTECTED] writes: So, - There is a bug which causes that when filling the context-menu it looks at the cursor position in stead of the position of the right-click. I think it is fixed now. - and a bug that when right-clicking outside a selection, the

RE: Selection without a selection [Bug 5162]

Could you try again and tell me what problems remain? Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a space in between). When you select text in front

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW wrote: Could you try again and tell me what problems remain? Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a

RE: Selection without a selection [Bug 5162]

Hi, What is the wanted behaviour for right-clicking inside the insets. Right-clicking inside a Float will open the edit context menu, while right-clicking inside a Note, ERT, Box, ... will open the context menu of the inset. I think that you'd expect an edit context menu if you

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW wrote: I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance.

Re: Selection without a selection [Bug 5162]

rgheck <[EMAIL PROTECTED]> writes: > Vincent van Ravesteijn - TNW wrote: >> I was trying to figure out why it is *always* a surprise whether LyX >> moves the cursor when right-clicking somewhere or not. It seems to be >> that if you click somewhere and you hold the mouse down and you move >> your

RE: Selection without a selection [Bug 5162]

choose this on the context menu. Vincent -Original Message- From: rgheck [mailto:[EMAIL PROTECTED] Sent: woensdag 13 augustus 2008 16:34 To: Vincent van Ravesteijn - TNW Cc: lyx-devel@lists.lyx.org Subject: Re: Selection without a selection [Bug 5162] Vincent van Ravesteijn - TNW wrote

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > I already added a sort of a 'patch' to the bug in bugzilla, which looks > like to solve the problem. It calls the function Cursor::setSelection(). The patch makes sense actually. You should even remove the 'selection() = true'

Re: Selection without a selection [Bug 5162]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> For example: right-clicking on a Note while the cursor is inside another >> Note. Without knowing about this bug, you never know which Note will be >> changed into 'Greyed Out' if you choose this on the context menu. > > But this is a completely

RE: Selection without a selection [Bug 5162]

>> For example: right-clicking on a Note while the cursor is inside >> another Note. Without knowing about this bug, you never know which >> Note will be changed into 'Greyed Out' if you choose this on the context menu. > >But this is a completely different bug, right? Probably introduced by

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > I already added a sort of a 'patch' to the bug in bugzilla, which looks > like to solve the problem. It calls the function Cursor::setSelection(). > > Although the name is not really describing what it does, a comment > inside this

Re: Selection without a selection [Bug 5162]

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > So, > - There is a bug which causes that when filling the context-menu it > looks at the cursor position in stead of the position of the > right-click. I think it is fixed now. > - and a bug that when right-clicking outside a

RE: Selection without a selection [Bug 5162]

>Could you try again and tell me what problems remain? > >Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a space in between). When you select text in

Re: Selection without a selection [Bug 5162]

Vincent van Ravesteijn - TNW wrote: Could you try again and tell me what problems remain? Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a

RE: Selection without a selection [Bug 5162]

Hi, What is the wanted behaviour for right-clicking inside the insets. Right-clicking inside a Float will open the edit context menu, while right-clicking inside a Note, ERT, Box, ... will open the context menu of the inset. I think that you'd expect an edit context menu if you

Selection without a selection [Bug 5162]

I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance. However, if you move the mouse just a

Selection without a selection [Bug 5162]

I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance. However, if you move the mouse just a

Re: Mouse Selection Bug Again

I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway? Who's the X expert around here? Here's the patch for reference:

Re: Mouse Selection Bug Again

Richard Heck [EMAIL PROTECTED] writes: I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway? Who's the X expert around here?

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck [EMAIL PROTECTED] writes: I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway?

Re: Mouse Selection Bug Again

Richard Heck [EMAIL PROTECTED] writes: This depends. Selecting in Firefox clears the selection in Konsole, but not vice versa. Firefox has obviously chosen to ignore the SelectionClear event, and I'd propose we should do the same. Why should selecting in Firefox clear my carefully made

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck [EMAIL PROTECTED] writes: This depends. Selecting in Firefox clears the selection in Konsole, but not vice versa. Firefox has obviously chosen to ignore the SelectionClear event, and I'd propose we should do the same. Why should selecting in Firefox

Re: Mouse Selection Bug Again

Richard Heck [EMAIL PROTECTED] writes: Here's what I think is happening. Selecting some text in one konsole app is clearing the selected text in the other, so a SelectionClear event is being triggered. Presumably, this is going to ALL aware applications, and that would include the konsole app

Re: Mouse Selection Bug Again

I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway? Who's the X expert around here? Here's the patch for reference:

Re: Mouse Selection Bug Again

Richard Heck <[EMAIL PROTECTED]> writes: > I've just locally disabled any reaction to SelectionClear events in > GuiApplication::x11EventFilter(). I don't see any ill effects, and it > obviously makes the bug go away. Do we want X clearing the selection > for us, anyway? Who's the X expert around

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway?

Re: Mouse Selection Bug Again

Richard Heck <[EMAIL PROTECTED]> writes: > This depends. Selecting in Firefox clears the selection in Konsole, > but not vice versa. Firefox has obviously chosen to ignore the > SelectionClear event, and I'd propose we should do the same. Why > should selecting in Firefox clear my carefully made

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: This depends. Selecting in Firefox clears the selection in Konsole, but not vice versa. Firefox has obviously chosen to ignore the SelectionClear event, and I'd propose we should do the same. Why should selecting in Firefox

Re: Mouse Selection Bug Again

Richard Heck <[EMAIL PROTECTED]> writes: > Here's what I think is happening. Selecting some text in one konsole > app is clearing the selected text in the other, so a SelectionClear > event is being triggered. Presumably, this is going to ALL aware > applications, and that would include the

Re: Mouse Selection Bug Again

Richard Heck [EMAIL PROTECTED] writes: Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? JMarc

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck [EMAIL PROTECTED] writes: Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? No, just a slew of X requested

Re: Mouse Selection Bug Again

Richard Heck <[EMAIL PROTECTED]> writes: > Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? JMarc

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? No, just a slew of "X requested

Re: Mouse Selection Bug Again

Richard Heck [EMAIL PROTECTED] writes: Well, I don't understand what's going on here really, but I do know roughly why the selection is occasionally being cleared (and I am seeing this with 1.6svn as well as with 1.5.2svn): Movement of the mouse is occasionally causing a SelectionClear even

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck [EMAIL PROTECTED] writes: Well, I don't understand what's going on here really, but I do know roughly why the selection is occasionally being cleared (and I am seeing this with 1.6svn as well as with 1.5.2svn): Movement of the mouse is occasionally

Re: Mouse Selection Bug Again

Richard Heck <[EMAIL PROTECTED]> writes: > Well, I don't understand what's going on here really, but I do know > roughly why the selection is occasionally being cleared (and I am > seeing this with 1.6svn as well as with 1.5.2svn): Movement of the > mouse is occasionally causing a SelectionClear

Re: Mouse Selection Bug Again

Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: Well, I don't understand what's going on here really, but I do know roughly why the selection is occasionally being cleared (and I am seeing this with 1.6svn as well as with 1.5.2svn): Movement of the mouse is occasionally

  1   2   >