Re: Clipboard

[Scott Kostyshak]

On Wed, May 05, 2021 at 04:51:07PM +0200, JP wrote:
> Le 5 mai 2021 16:10:24 Scott Kostyshak  a écrit :
> 
> > On Wed, May 05, 2021 at 10:16:27AM +0200, Jean-Pierre Chrétien wrote:
> > > Le 04/05/2021 à 18:36, Scott Kostyshak a écrit :
> > > > On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:
> > > > > Le 04/05/2021 à 15:17, Kornel Benko a écrit :
> > > > > > Am Tue, 4 May 2021 14:14:47 +0200
> > > > > > schrieb Jean-Pierre Chrétien :
> > > > > >
> > > > > > > Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :
> > > > > > >
> > > > > > > >
> > > > > > > > In that case, it could be that the fix referenced above 
> > > > > > > > actually made
> > > > > > > > things worse for you. You could try to revert the commit
> > > 7a158055 on the
> > > > > > > > 2.3.x branch and see if that makes the terminal message go
> > > away for you.
> > > > > > > > If you do that, please let me know if it helps things
> > > because that means
> > > > > > > > we should fix something.
> > > 
> > > [...]
> > > > >
> > > > > However, it turns out that I reverted globally instead of locally, 
> > > > > sorry.
> > > >
> > > > No problem, we've all done that before.
> > > 
> > > I guess I should have simply patched the local files, right? Or is there a
> > > git command to revert locally only?
> > 
> > I'm no sure what the best practice is. One way might be to create a
> > separate branch and apply the patches there. And then perhaps there's a
> > way to disable pushing a new branch?
> > 
> > > The clipboard message is still there, but I got this message when 
> > > starting LyX:
> > > 
> > > $ invoking IsSupported() failed for remote volume monitor with dbus name
> > > org.gtk.vfs.UDisks2VolumeMonitor:: Le délai d’attente est dépassé
> > > (g-io-error-quark, 24)
> > > 
> 
> I'm not sure that this error has something to do with LyX, but Open File
> takes 30s...

I can't reproduce. It opens within a second for me.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[JP]

Le 5 mai 2021 16:10:24 Scott Kostyshak  a écrit :


On Wed, May 05, 2021 at 10:16:27AM +0200, Jean-Pierre Chrétien wrote:

Le 04/05/2021 à 18:36, Scott Kostyshak a écrit :
> On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:
> > Le 04/05/2021 à 15:17, Kornel Benko a écrit :
> > > Am Tue, 4 May 2021 14:14:47 +0200
> > > schrieb Jean-Pierre Chrétien :
> > >
> > > > Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :
> > > >
> > > > >
> > > > > In that case, it could be that the fix referenced above actually made
> > > > > things worse for you. You could try to revert the commit 7a158055 
on the
> > > > > 2.3.x branch and see if that makes the terminal message go away 
for you.
> > > > > If you do that, please let me know if it helps things because 
that means

> > > > > we should fix something.

[...]
> >
> > However, it turns out that I reverted globally instead of locally, sorry.
>
> No problem, we've all done that before.

I guess I should have simply patched the local files, right? Or is there a
git command to revert locally only?


I'm no sure what the best practice is. One way might be to create a 
separate branch and apply the patches there. And then perhaps there's a way 
to disable pushing a new branch?



The clipboard message is still there, but I got this message when starting LyX:

$ invoking IsSupported() failed for remote volume monitor with dbus name
org.gtk.vfs.UDisks2VolumeMonitor:: Le délai d’attente est dépassé
(g-io-error-quark, 24)



I'm not sure that this error has something to do with LyX, but Open File 
takes 30s...


--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Scott Kostyshak]

On Wed, May 05, 2021 at 10:16:27AM +0200, Jean-Pierre Chrétien wrote:
> Le 04/05/2021 à 18:36, Scott Kostyshak a écrit :
> > On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:
> > > Le 04/05/2021 à 15:17, Kornel Benko a écrit :
> > > > Am Tue, 4 May 2021 14:14:47 +0200
> > > > schrieb Jean-Pierre Chrétien :
> > > > 
> > > > > Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :
> > > > > 
> > > > > > 
> > > > > > In that case, it could be that the fix referenced above actually 
> > > > > > made
> > > > > > things worse for you. You could try to revert the commit 7a158055 
> > > > > > on the
> > > > > > 2.3.x branch and see if that makes the terminal message go away for 
> > > > > > you.
> > > > > > If you do that, please let me know if it helps things because that 
> > > > > > means
> > > > > > we should fix something.
> 
> [...]
> > > 
> > > However, it turns out that I reverted globally instead of locally, sorry.
> > 
> > No problem, we've all done that before.
> 
> I guess I should have simply patched the local files, right? Or is there a
> git command to revert locally only?

I'm no sure what the best practice is. One way might be to create a separate 
branch and apply the patches there. And then perhaps there's a way to disable 
pushing a new branch?

> The clipboard message is still there, but I got this message when starting 
> LyX:
> 
> $ invoking IsSupported() failed for remote volume monitor with dbus name
> org.gtk.vfs.UDisks2VolumeMonitor:: Le délai d’attente est dépassé
> (g-io-error-quark, 24)
> 
> So I will come back to lyx-2.4.0 with your patches...

Good to know, thanks for testing.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Jean-Pierre Chrétien]

Le 04/05/2021 à 18:36, Scott Kostyshak a écrit :

On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:

Le 04/05/2021 à 15:17, Kornel Benko a écrit :

Am Tue, 4 May 2021 14:14:47 +0200
schrieb Jean-Pierre Chrétien :


Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


[...]


However, it turns out that I reverted globally instead of locally, sorry.


No problem, we've all done that before.


I guess I should have simply patched the local files, right? Or is there a git 
command to revert locally only?


The clipboard message is still there, but I got this message when starting LyX:

$ invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.UDisks2VolumeMonitor:: Le délai d’attente est dépassé 
(g-io-error-quark, 24)


So I will come back to lyx-2.4.0 with your patches...

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Scott Kostyshak]

On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:
> Le 04/05/2021 à 15:17, Kornel Benko a écrit :
> > Am Tue, 4 May 2021 14:14:47 +0200
> > schrieb Jean-Pierre Chrétien :
> > 
> > > Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :
> > > 
> > > > 
> > > > In that case, it could be that the fix referenced above actually made
> > > > things worse for you. You could try to revert the commit 7a158055 on the
> > > > 2.3.x branch and see if that makes the terminal message go away for you.
> > > > If you do that, please let me know if it helps things because that means
> > > > we should fix something.
> > > 
> > > Hello SCott
> > > 
> > > In fact, I get the message also with master while working on the French 
> > > docs:
> > > .
> > > frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, 
> > > perhaps
> > > process holding clipboard is frozen?
> > > 
> > > What is the commit to revert on master ?
> > > 
> > 
> > commit 7a158055fe6c05763f88ddb61a9c02b42614091d
> > Author: Scott Kostyshak 
> > Date:   Fri Mar 27 21:23:08 2020 -0400
> > ...
> >  (cherry picked from commit af4ee1a487c4d899b71df02ba57c2f024fea6786)
> >  (cherry picked from commit 23abb5aaa36af07aadfa5e565869104778ba0d6d)
> > 
> > Got this by 'git show 7a158055'.
> 
> Thanks for the info and the hint, Kornel.
> 
> However, it turns out that I reverted globaélly instead of locally, sorry.

No problem, we've all done that before.

> What shoulsd I do to restore the commits in the master repo?

I took care of it so I don't think there's anything you need to do. I just 
reverted to reversions.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Jean-Pierre Chrétien]

Le 04/05/2021 à 15:17, Kornel Benko a écrit :

Am Tue, 4 May 2021 14:14:47 +0200
schrieb Jean-Pierre Chrétien :


Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


Hello SCott

In fact, I get the message also with master while working on the French docs:
.
frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, perhaps
process holding clipboard is frozen?

What is the commit to revert on master ?



commit 7a158055fe6c05763f88ddb61a9c02b42614091d
Author: Scott Kostyshak 
Date:   Fri Mar 27 21:23:08 2020 -0400
...
 (cherry picked from commit af4ee1a487c4d899b71df02ba57c2f024fea6786)
 (cherry picked from commit 23abb5aaa36af07aadfa5e565869104778ba0d6d)

Got this by 'git show 7a158055'.


Thanks for the info and the hint, Kornel.

However, it turns out that I reverted globaélly instead of locally, sorry.

What shoulsd I do to restore the commits in the master repo?

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Kornel Benko]

Am Tue, 4 May 2021 14:14:47 +0200
schrieb Jean-Pierre Chrétien :

> Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :
> 
> > 
> > In that case, it could be that the fix referenced above actually made
> > things worse for you. You could try to revert the commit 7a158055 on the
> > 2.3.x branch and see if that makes the terminal message go away for you.
> > If you do that, please let me know if it helps things because that means
> > we should fix something.  
> 
> Hello SCott
> 
> In fact, I get the message also with master while working on the French docs:
> .
> frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, 
> perhaps 
> process holding clipboard is frozen?
> 
> What is the commit to revert on master ?
> 

commit 7a158055fe6c05763f88ddb61a9c02b42614091d
Author: Scott Kostyshak 
Date:   Fri Mar 27 21:23:08 2020 -0400
...
(cherry picked from commit af4ee1a487c4d899b71df02ba57c2f024fea6786)
(cherry picked from commit 23abb5aaa36af07aadfa5e565869104778ba0d6d)

Got this by 'git show 7a158055'.

Kornel


pgp0mqT73nmt3.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Jean-Pierre Chrétien]

Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


Hello SCott

In fact, I get the message also with master while working on the French docs:
.
frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, perhaps 
process holding clipboard is frozen?


What is the commit to revert on master ?

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Scott Kostyshak]

On Wed, Apr 14, 2021 at 11:01:55AM +0200, Jean-Pierre Chrétien wrote:
> Le 13/04/2021 à 19:58, Scott Kostyshak a écrit :
> > On Tue, Apr 13, 2021 at 06:35:22PM +0200, Jean-Pierre Chrétien wrote:
> > > Dear Developers
> > > 
> > > While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
> > > terminal :
> > > 
> > > $ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard,
> > > perhaps process holding clipboard is frozen?
> > > 
> > > I see it when I come back to the terminal window, so I do not know when 
> > > it happens.
> > > 
> > > Any clue?
> > 
> > Do you use a clipboard manager? If so, which one? I use CopyQ and I
> > often see that message in the terminal. I think it's also related that
> > sometimes I select something in LyX and the selection is broken. Does
> > this ever happen to you? It is much better in my experience after the
> > fix for #11715 (which is in the version of LyX you're using) but I still
> > see it sometimes.
> 
> Hello SCott,
> 
> No I don't use a clipboard manager.

Good to know.

> What puzzles me is that the message mentions Qt4...

You mean the path frontends/qt4? This is indeed confusing, but it is
just the path of the files. It does not actually mean anything about Qt4
and in 2.4.0dev we've renamed the directory to just "qt" so the path
will now be "frontends/qt".

> > If you don't use a clipboard manager, then I'm not sure. LyX does some
> > tricks regarding the clipboard because it does not want to constantly
> > export code whenever the selection changes (that would be expensive), so
> > it tries to wait until an application requests the selection.
> 
> Sure, but it is the first time I see this message. Of course, I do not use
> any more LyX to produce documents as I used to do before I retired.
> I'll keep an aye on my terminal.

In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Jean-Pierre Chrétien]

Le 13/04/2021 à 19:58, Scott Kostyshak a écrit :

On Tue, Apr 13, 2021 at 06:35:22PM +0200, Jean-Pierre Chrétien wrote:

Dear Developers

While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
terminal :

$ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard,
perhaps process holding clipboard is frozen?

I see it when I come back to the terminal window, so I do not know when it 
happens.

Any clue?


Do you use a clipboard manager? If so, which one? I use CopyQ and I
often see that message in the terminal. I think it's also related that
sometimes I select something in LyX and the selection is broken. Does
this ever happen to you? It is much better in my experience after the
fix for #11715 (which is in the version of LyX you're using) but I still
see it sometimes.


Hello SCott,

No I don't use a clipboard manager.
What puzzles me is that the message mentions Qt4...



If you don't use a clipboard manager, then I'm not sure. LyX does some
tricks regarding the clipboard because it does not want to constantly
export code whenever the selection changes (that would be expensive), so
it tries to wait until an application requests the selection.


Sure, but it is the first time I see this message. Of course, I do not use any 
more LyX to produce documents as I used to do before I retired.

I'll keep an aye on my terminal.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clipboard

[Scott Kostyshak]

On Tue, Apr 13, 2021 at 06:35:22PM +0200, Jean-Pierre Chrétien wrote:
> Dear Developers
> 
> While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
> terminal :
> 
> $ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard,
> perhaps process holding clipboard is frozen?
> 
> I see it when I come back to the terminal window, so I do not know when it 
> happens.
> 
> Any clue?

Do you use a clipboard manager? If so, which one? I use CopyQ and I
often see that message in the terminal. I think it's also related that
sometimes I select something in LyX and the selection is broken. Does
this ever happen to you? It is much better in my experience after the
fix for #11715 (which is in the version of LyX you're using) but I still
see it sometimes.

If you don't use a clipboard manager, then I'm not sure. LyX does some
tricks regarding the clipboard because it does not want to constantly
export code whenever the selection changes (that would be expensive), so
it tries to wait until an application requests the selection.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Clipboard

[Jean-Pierre Chrétien]

Dear Developers

While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
terminal :

$ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard, 
perhaps process holding clipboard is frozen?


I see it when I come back to the terminal window, so I do not know when it 
happens.

Any clue?

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: #9772: Crash when copying to clipboard

[Gilles Moyse]

I have this bug on a computer I do not manage, i.e. administrators do it
for us and we do not have any root access, so I'm afraid I won't be able to
add much here.
For now they have downgraded our version to 2.1.2 and they will install
2.1.5 which will contain the fix I guess.
So I think this ticket can be closed.

Thanks a lot for your help!

___
Gilles Moyse
LinkedIn : fr.linkedin.com/in/gillesmoyse
Twitter : @GillesMoyse <https://twitter.com/GillesMoyse>
Mobile : +33 6 38 03 71 63

On 18 October 2015 at 17:31, LyX Ticket Tracker <t...@lyx.org> wrote:

> #9772: Crash when copying to clipboard
> --+-
>  Reporter:  gilles.moyse  |   Owner:  lasgouttes
>  Type:  defect|  Status:  new
>  Priority:  normal|   Milestone:
> Component:  general   | Version:  2.1.4
>  Severity:  major |  Resolution:
>  Keywords:  infoneeded|
> --+-
>
> Comment (by baum):
>
>  Replying to [comment:3 gilles.moyse]:
>  > I haven't compiled it so I don't know which version has been used.
>  However, it's very likely the same problem than #9771.
>
>  If you tell us where you got the binary from then we can probably find out
>  which compiler was used.
>
>  > I've seen it has been fixed. How can I fix it too? Do I need to download
>  the latest sources? Are there some specific command line options to be
>  passed to gcc?
>
>  No commandline options, we changed the source code to avoid the compiler
>  bug. The fix is not in any released LyX version yet, so you can either get
>  the latest git sources (see http://www.lyx.org/HowToUseGIT, use the 2.1.x
>  branch), or you can download the 2.1.4 source package and then apply the
>  change [12ab5dd81/lyxgit].
>
> --
> Ticket URL: <http://www.lyx.org/trac/ticket/9772#comment:4>
> The LyX Project <http://www.lyx.org/>
> LyX -- The Document Processor
>

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

I'm not sure if the following is LyX's problem or not. If I open LyX
from the terminal (on Ubuntu 12.04) and copy the User Guide and exit,
the LyX window closes but LyX still hasn't exited (the terminal is
still busy). After about 5 seconds I get the following message on the
terminal QClipboard: Unable to receive an event from the clipboard manager in
a reasonable time and then LyX exits.

Now if I start LyX again and exit (without doing anything) I again get
the pause and the QClipboard message. The only way I can get rid of
this is to restart the computer or running the following command:
killall gnome-settings-daemon

Note that the copy also issued this message to the terminal:
Warning: latex had problems compiling 0lyxpreview.tex


This is due to LyX's trying to export various math things as images when 
doing the copy. We need to stop it from trying to do that.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

I'm not sure if the following is LyX's problem or not. If I open LyX
from the terminal (on Ubuntu 12.04) and copy the User Guide and exit,
the LyX window closes but LyX still hasn't exited (the terminal is
still busy). After about 5 seconds I get the following message on the
terminal "QClipboard: Unable to receive an event from the clipboard manager in
a reasonable time" and then LyX exits.

Now if I start LyX again and exit (without doing anything) I again get
the pause and the QClipboard message. The only way I can get rid of
this is to restart the computer or running the following command:
killall gnome-settings-daemon

Note that the copy also issued this message to the terminal:
Warning: latex had problems compiling 0lyxpreview.tex


This is due to LyX's trying to export various math things as images when 
doing the copy. We need to stop it from trying to do that.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Mon, Apr 29, 2013 at 5:36 PM, Richard Heck rgh...@lyx.org wrote:
 On 04/29/2013 04:03 PM, Georg Baum wrote:

 - When selecting all and copying UserGuide.lyx, I get the dialogs
 mentioned before.

 This is known. I asked whether these branches should just be created, but
 got no reply so far. If the answer is yes, this problem is easy to fix.


 I would say yes, as well. Though we need, as I said before, some kind of
 flag to signal that we are copying, not exporting. We actually need the same
 flag, I think, for generation of ViewSource code. So it may be a more
 general issue. Or else maybe we already have some such flag we can use. I'm
 not sure.

After your recent comment, this issue seems to have been solved.

I'm not sure if the following is LyX's problem or not. If I open LyX
from the terminal (on Ubuntu 12.04) and copy the User Guide and exit,
the LyX window closes but LyX still hasn't exited (the terminal is
still busy). After about 5 seconds I get the following message on the
terminal
QClipboard: Unable to receive an event from the clipboard manager in
a reasonable time
and then LyX exits.

Now if I start LyX again and exit (without doing anything) I again get
the pause and the QClipboard message. The only way I can get rid of
this is to restart the computer or running the following command:
killall gnome-settings-daemon

Note that the copy also issued this message to the terminal:
Warning: latex had problems compiling 0lyxpreview.tex

Can anyone reproduce this?
Is this a Qt bug? An Ubuntu bug?

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Mon, Apr 29, 2013 at 5:36 PM, Richard Heck <rgh...@lyx.org> wrote:
> On 04/29/2013 04:03 PM, Georg Baum wrote:
>>>>>
>>>>> - When selecting all and copying UserGuide.lyx, I get the dialogs
>>>>> mentioned before.
>>
>> This is known. I asked whether these branches should just be created, but
>> got no reply so far. If the answer is yes, this problem is easy to fix.
>
>
> I would say "yes", as well. Though we need, as I said before, some kind of
> flag to signal that we are copying, not exporting. We actually need the same
> flag, I think, for generation of View>Source code. So it may be a more
> general issue. Or else maybe we already have some such flag we can use. I'm
> not sure.

After your recent comment, this issue seems to have been solved.

I'm not sure if the following is LyX's problem or not. If I open LyX
from the terminal (on Ubuntu 12.04) and copy the User Guide and exit,
the LyX window closes but LyX still hasn't exited (the terminal is
still busy). After about 5 seconds I get the following message on the
terminal
"QClipboard: Unable to receive an event from the clipboard manager in
a reasonable time"
and then LyX exits.

Now if I start LyX again and exit (without doing anything) I again get
the pause and the QClipboard message. The only way I can get rid of
this is to restart the computer or running the following command:
killall gnome-settings-daemon

Note that the copy also issued this message to the terminal:
Warning: latex had problems compiling 0lyxpreview.tex

Can anyone reproduce this?
Is this a Qt bug? An Ubuntu bug?

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Vincent van Ravesteijn]

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):


I'm not too enthusiastic about opening tickets just because code has 
been committed which hasn't been tested beforehand.



- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!


Maybe I will even request to revert this and readd this after LyX2.1 has 
been released. I'm afraid that this will have too many problems in practice.


Vincent

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/29/2013 01:32 AM, Scott Kostyshak wrote:

On Sun, Apr 28, 2013 at 4:26 PM, Vincent van Ravesteijn v...@lyx.org wrote:

Op 28-4-2013 0:32, Scott Kostyshak schreef:


On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:

Richard Heck wrote:


There are a couple issues here. One is the problem of branches.
Previously, we'd have pasted the copied paragraphs into the temporary
Buffer, and with it whatever branch insets were in the copied material,
not paying any attention at all to whether those branches existed, etc.
I'm not sure what that would mean for what would end up on the
clipboard. Probably we can just add a flag to the signature of
pasteSelectionHelper() that means: don't ask about this, just do it (or
not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?


The other issue is the sigsev. Here the problem is that the temporary
Buffer we are using in putClipboard is static. So what we do to it
remains from call to call. We clear the paragraphs, at the end of that
routine, but we don't fully reset the Buffer's InsetText, which is why
we get the crash.

So if you remove the static keyword, the crash vanishes, but that does
give a bit of a performance hit every time you copy something, because
we have to create a new Buffer, with a new tempdir, and so forth. What
we might want instead is a way to completely reset this temporary
Buffer. Another option would be to keep the static (empty) Buffer and
clone it each time, which ought to be cheap.

I did this, and it works fine.


By the way, I note that this copy is also very slow, because we are
converting images to formats suitable for XHTML export, which never get
used. We probably need another flag that means: don't do that, or bother
creating math images, etc. We might also want to force math to be export
as HTML, since the clipboard probably does not know what to do with
MathML.

I changed it to use MathML. Before copying HTML, only plaintext was
copied,
which did not play well to formulas at all. Now, there is at least the
chance to recover formulas by applications that understand MathML (MS
Office
is supposed to understand it). If MathML is not understood, some
applications (e.g. libreoffice) are still able to display the pure text,
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help  Introduction, select all, and
do ctrl + c and then ctrl + c again quickly after the first one.
Or do ctrl + c, wait for the copy to finish, and then do ctrl + c
twice more.

Scott

I hope I fixed this issue today.

Vincent

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!


The last one puzzles me a bit. But none of these errors should be shown 
on copy.


Richard



Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Vincent van Ravesteijn wrote:

 Thanks Vincent, I no longer get a crash. I still have the following
 issues (let me know if I should open up tickets):
 
 I'm not too enthusiastic about opening tickets just because code has
 been committed which hasn't been tested beforehand.

It has been tested, although I admit that I did not test it with all doc 
files (and it is not my fault that I did not see a windows-only crash on 
linux).

 - When selecting all and copying UserGuide.lyx, I get the dialogs
 mentioned before.

This is known. I asked whether these branches should just be created, but 
got no reply so far. If the answer is yes, this problem is easy to fix.

 - When selecting all and copying Addional.lyx, I get the following
 message: LyX does not know how to include non-LyX files when generating
 HTML output. Offending file:
 SpecialParagraphShape.tex

This is a message box. I wonder why it is generated at all? Insets that do 
not support plain text export simply output something like [include 
foo.bar]. I do not see the difference to HTML here: If a message box is 
needed, it should be used in both cases.

 - When selecting all and copying EmbeddedObjects.lyx, I get the
 following errors:
 File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
 support/FileName.cpp (732): File
 '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
 support/FileName.cpp (732): File
 '/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!

This is terminal output, and it happens because the included file is not 
found in the temp buffer. This is BTW also a problem for the already 
existing plain text clipboard copy (but was not noticed so far). I could fix 
this if needed.

 Maybe I will even request to revert this and readd this after LyX2.1 has
 been released. I'm afraid that this will have too many problems in
 practice.

I thought of disabling the HTML clipboard copy as well. However, I believe 
Richard should decide, since he can judge best whether there will likely be 
other problems.

BTW, thanks for your fixes, I indeed did not intend to remove the static 
keyword, this was a leftover of trying to keep only the temporary directory, 
but not the buffer static.


Georg

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/29/2013 04:03 PM, Georg Baum wrote:

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

This is known. I asked whether these branches should just be created, but
got no reply so far. If the answer is yes, this problem is easy to fix.


I would say yes, as well. Though we need, as I said before, some kind 
of flag to signal that we are copying, not exporting. We actually need 
the same flag, I think, for generation of ViewSource code. So it may be 
a more general issue. Or else maybe we already have some such flag we 
can use. I'm not sure.



- When selecting all and copying Addional.lyx, I get the following
message: LyX does not know how to include non-LyX files when generating
HTML output. Offending file:
SpecialParagraphShape.tex

This is a message box. I wonder why it is generated at all? Insets that do not 
support plain text export simply output something like [include
foo.bar]. I do not see the difference to HTML here: If a message box is
needed, it should be used in both cases.


Here again, it looks like we think we are actually exporting. This would 
happen in InsetInclude::xhtml().


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Vincent van Ravesteijn]

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):


I'm not too enthusiastic about opening tickets just because code has 
been committed which hasn't been tested beforehand.



- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
"LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex"

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!


Maybe I will even request to revert this and readd this after LyX2.1 has 
been released. I'm afraid that this will have too many problems in practice.


Vincent

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/29/2013 01:32 AM, Scott Kostyshak wrote:

On Sun, Apr 28, 2013 at 4:26 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:

Op 28-4-2013 0:32, Scott Kostyshak schreef:


On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
<georg.b...@post.rwth-aachen.de> wrote:

Richard Heck wrote:


There are a couple issues here. One is the problem of branches.
Previously, we'd have "pasted" the copied paragraphs into the temporary
Buffer, and with it whatever branch insets were in the copied material,
not paying any attention at all to whether those branches existed, etc.
I'm not sure what that would mean for what would end up on the
clipboard. Probably we can just add a flag to the signature of
pasteSelectionHelper() that means: don't ask about this, just do it (or
not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?


The other issue is the sigsev. Here the problem is that the temporary
Buffer we are using in putClipboard is static. So what we do to it
remains from call to call. We clear the paragraphs, at the end of that
routine, but we don't fully reset the Buffer's InsetText, which is why
we get the crash.

So if you remove the static keyword, the crash vanishes, but that does
give a bit of a performance hit every time you copy something, because
we have to create a new Buffer, with a new tempdir, and so forth. What
we might want instead is a way to completely reset this temporary
Buffer. Another option would be to keep the static (empty) Buffer and
clone it each time, which ought to be cheap.

I did this, and it works fine.


By the way, I note that this copy is also very slow, because we are
converting images to formats suitable for XHTML export, which never get
used. We probably need another flag that means: don't do that, or bother
creating math images, etc. We might also want to force math to be export
as HTML, since the clipboard probably does not know what to do with
MathML.

I changed it to use MathML. Before copying HTML, only plaintext was
copied,
which did not play well to formulas at all. Now, there is at least the
chance to recover formulas by applications that understand MathML (MS
Office
is supposed to understand it). If MathML is not understood, some
applications (e.g. libreoffice) are still able to display the pure text,
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help > Introduction, select all, and
do "ctrl + c" and then "ctrl + c" again quickly after the first one.
Or do "ctrl + c", wait for the copy to finish, and then do "ctrl + c"
twice more.

Scott

I hope I fixed this issue today.

Vincent

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
"LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex"

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!


The last one puzzles me a bit. But none of these errors should be shown 
on copy.


Richard



Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Vincent van Ravesteijn wrote:

>> Thanks Vincent, I no longer get a crash. I still have the following
>> issues (let me know if I should open up tickets):
> 
> I'm not too enthusiastic about opening tickets just because code has
> been committed which hasn't been tested beforehand.

It has been tested, although I admit that I did not test it with all doc 
files (and it is not my fault that I did not see a windows-only crash on 
linux).

>>> - When selecting all and copying UserGuide.lyx, I get the dialogs
>>> mentioned before.

This is known. I asked whether these branches should just be created, but 
got no reply so far. If the answer is yes, this problem is easy to fix.

>>> - When selecting all and copying Addional.lyx, I get the following
>>> message: "LyX does not know how to include non-LyX files when generating
>>> HTML output. Offending file:
>>> SpecialParagraphShape.tex"

This is a message box. I wonder why it is generated at all? Insets that do 
not support plain text export simply output something like [include 
foo.bar]. I do not see the difference to HTML here: If a message box is 
needed, it should be used in both cases.

>>> - When selecting all and copying EmbeddedObjects.lyx, I get the
>>> following errors:
>>> File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
>>> support/FileName.cpp (732): File
>>> '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
>>> support/FileName.cpp (732): File
>>> '/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!

This is terminal output, and it happens because the included file is not 
found in the temp buffer. This is BTW also a problem for the already 
existing plain text clipboard copy (but was not noticed so far). I could fix 
this if needed.

> Maybe I will even request to revert this and readd this after LyX2.1 has
> been released. I'm afraid that this will have too many problems in
> practice.

I thought of disabling the HTML clipboard copy as well. However, I believe 
Richard should decide, since he can judge best whether there will likely be 
other problems.

BTW, thanks for your fixes, I indeed did not intend to remove the static 
keyword, this was a leftover of trying to keep only the temporary directory, 
but not the buffer static.


Georg

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/29/2013 04:03 PM, Georg Baum wrote:

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

This is known. I asked whether these branches should just be created, but
got no reply so far. If the answer is yes, this problem is easy to fix.


I would say "yes", as well. Though we need, as I said before, some kind 
of flag to signal that we are copying, not exporting. We actually need 
the same flag, I think, for generation of View>Source code. So it may be 
a more general issue. Or else maybe we already have some such flag we 
can use. I'm not sure.



- When selecting all and copying Addional.lyx, I get the following
message: "LyX does not know how to include non-LyX files when generating
HTML output. Offending file:
SpecialParagraphShape.tex"

This is a message box. I wonder why it is generated at all? Insets that do not 
support plain text export simply output something like [include
foo.bar]. I do not see the difference to HTML here: If a message box is
needed, it should be used in both cases.


Here again, it looks like we think we are actually exporting. This would 
happen in InsetInclude::xhtml().


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Vincent van Ravesteijn]

Op 28-4-2013 0:32, Scott Kostyshak schreef:

On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:

Richard Heck wrote:


There are a couple issues here. One is the problem of branches.
Previously, we'd have pasted the copied paragraphs into the temporary
Buffer, and with it whatever branch insets were in the copied material,
not paying any attention at all to whether those branches existed, etc.
I'm not sure what that would mean for what would end up on the
clipboard. Probably we can just add a flag to the signature of
pasteSelectionHelper() that means: don't ask about this, just do it (or
not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?


The other issue is the sigsev. Here the problem is that the temporary
Buffer we are using in putClipboard is static. So what we do to it
remains from call to call. We clear the paragraphs, at the end of that
routine, but we don't fully reset the Buffer's InsetText, which is why
we get the crash.

So if you remove the static keyword, the crash vanishes, but that does
give a bit of a performance hit every time you copy something, because
we have to create a new Buffer, with a new tempdir, and so forth. What
we might want instead is a way to completely reset this temporary
Buffer. Another option would be to keep the static (empty) Buffer and
clone it each time, which ought to be cheap.

I did this, and it works fine.


By the way, I note that this copy is also very slow, because we are
converting images to formats suitable for XHTML export, which never get
used. We probably need another flag that means: don't do that, or bother
creating math images, etc. We might also want to force math to be export
as HTML, since the clipboard probably does not know what to do with
MathML.

I changed it to use MathML. Before copying HTML, only plaintext was copied,
which did not play well to formulas at all. Now, there is at least the
chance to recover formulas by applications that understand MathML (MS Office
is supposed to understand it). If MathML is not understood, some
applications (e.g. libreoffice) are still able to display the pure text,
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help  Introduction, select all, and
do ctrl + c and then ctrl + c again quickly after the first one.
Or do ctrl + c, wait for the copy to finish, and then do ctrl + c
twice more.

Scott

I hope I fixed this issue today.

Vincent

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sun, Apr 28, 2013 at 4:26 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 28-4-2013 0:32, Scott Kostyshak schreef:

 On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
 georg.b...@post.rwth-aachen.de wrote:

 Richard Heck wrote:

 There are a couple issues here. One is the problem of branches.
 Previously, we'd have pasted the copied paragraphs into the temporary
 Buffer, and with it whatever branch insets were in the copied material,
 not paying any attention at all to whether those branches existed, etc.
 I'm not sure what that would mean for what would end up on the
 clipboard. Probably we can just add a flag to the signature of
 pasteSelectionHelper() that means: don't ask about this, just do it (or
 not, which would be the old behavior).

 I'd simply create the branches. Does it have any drawback?

 The other issue is the sigsev. Here the problem is that the temporary
 Buffer we are using in putClipboard is static. So what we do to it
 remains from call to call. We clear the paragraphs, at the end of that
 routine, but we don't fully reset the Buffer's InsetText, which is why
 we get the crash.

 So if you remove the static keyword, the crash vanishes, but that does
 give a bit of a performance hit every time you copy something, because
 we have to create a new Buffer, with a new tempdir, and so forth. What
 we might want instead is a way to completely reset this temporary
 Buffer. Another option would be to keep the static (empty) Buffer and
 clone it each time, which ought to be cheap.

 I did this, and it works fine.

 By the way, I note that this copy is also very slow, because we are
 converting images to formats suitable for XHTML export, which never get
 used. We probably need another flag that means: don't do that, or bother
 creating math images, etc. We might also want to force math to be export
 as HTML, since the clipboard probably does not know what to do with
 MathML.

 I changed it to use MathML. Before copying HTML, only plaintext was
 copied,
 which did not play well to formulas at all. Now, there is at least the
 chance to recover formulas by applications that understand MathML (MS
 Office
 is supposed to understand it). If MathML is not understood, some
 applications (e.g. libreoffice) are still able to display the pure text,
 which is very similar to the plain text export.

 BTW, thanks for fixing the update problem.

 Is this still being worked on or is it supposed to be fixed? I still
 get SIGSEGVs. To reproduce, open Help  Introduction, select all, and
 do ctrl + c and then ctrl + c again quickly after the first one.
 Or do ctrl + c, wait for the copy to finish, and then do ctrl + c
 twice more.

 Scott

 I hope I fixed this issue today.

 Vincent

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Vincent van Ravesteijn]

Op 28-4-2013 0:32, Scott Kostyshak schreef:

On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
<georg.b...@post.rwth-aachen.de> wrote:

Richard Heck wrote:


There are a couple issues here. One is the problem of branches.
Previously, we'd have "pasted" the copied paragraphs into the temporary
Buffer, and with it whatever branch insets were in the copied material,
not paying any attention at all to whether those branches existed, etc.
I'm not sure what that would mean for what would end up on the
clipboard. Probably we can just add a flag to the signature of
pasteSelectionHelper() that means: don't ask about this, just do it (or
not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?


The other issue is the sigsev. Here the problem is that the temporary
Buffer we are using in putClipboard is static. So what we do to it
remains from call to call. We clear the paragraphs, at the end of that
routine, but we don't fully reset the Buffer's InsetText, which is why
we get the crash.

So if you remove the static keyword, the crash vanishes, but that does
give a bit of a performance hit every time you copy something, because
we have to create a new Buffer, with a new tempdir, and so forth. What
we might want instead is a way to completely reset this temporary
Buffer. Another option would be to keep the static (empty) Buffer and
clone it each time, which ought to be cheap.

I did this, and it works fine.


By the way, I note that this copy is also very slow, because we are
converting images to formats suitable for XHTML export, which never get
used. We probably need another flag that means: don't do that, or bother
creating math images, etc. We might also want to force math to be export
as HTML, since the clipboard probably does not know what to do with
MathML.

I changed it to use MathML. Before copying HTML, only plaintext was copied,
which did not play well to formulas at all. Now, there is at least the
chance to recover formulas by applications that understand MathML (MS Office
is supposed to understand it). If MathML is not understood, some
applications (e.g. libreoffice) are still able to display the pure text,
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help > Introduction, select all, and
do "ctrl + c" and then "ctrl + c" again quickly after the first one.
Or do "ctrl + c", wait for the copy to finish, and then do "ctrl + c"
twice more.

Scott

I hope I fixed this issue today.

Vincent

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sun, Apr 28, 2013 at 4:26 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:
> Op 28-4-2013 0:32, Scott Kostyshak schreef:
>
>> On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
>> <georg.b...@post.rwth-aachen.de> wrote:
>>>
>>> Richard Heck wrote:
>>>
>>>> There are a couple issues here. One is the problem of branches.
>>>> Previously, we'd have "pasted" the copied paragraphs into the temporary
>>>> Buffer, and with it whatever branch insets were in the copied material,
>>>> not paying any attention at all to whether those branches existed, etc.
>>>> I'm not sure what that would mean for what would end up on the
>>>> clipboard. Probably we can just add a flag to the signature of
>>>> pasteSelectionHelper() that means: don't ask about this, just do it (or
>>>> not, which would be the old behavior).
>>>
>>> I'd simply create the branches. Does it have any drawback?
>>>
>>>> The other issue is the sigsev. Here the problem is that the temporary
>>>> Buffer we are using in putClipboard is static. So what we do to it
>>>> remains from call to call. We clear the paragraphs, at the end of that
>>>> routine, but we don't fully reset the Buffer's InsetText, which is why
>>>> we get the crash.
>>>>
>>>> So if you remove the static keyword, the crash vanishes, but that does
>>>> give a bit of a performance hit every time you copy something, because
>>>> we have to create a new Buffer, with a new tempdir, and so forth. What
>>>> we might want instead is a way to completely reset this temporary
>>>> Buffer. Another option would be to keep the static (empty) Buffer and
>>>> clone it each time, which ought to be cheap.
>>>
>>> I did this, and it works fine.
>>>
>>>> By the way, I note that this copy is also very slow, because we are
>>>> converting images to formats suitable for XHTML export, which never get
>>>> used. We probably need another flag that means: don't do that, or bother
>>>> creating math images, etc. We might also want to force math to be export
>>>> as HTML, since the clipboard probably does not know what to do with
>>>> MathML.
>>>
>>> I changed it to use MathML. Before copying HTML, only plaintext was
>>> copied,
>>> which did not play well to formulas at all. Now, there is at least the
>>> chance to recover formulas by applications that understand MathML (MS
>>> Office
>>> is supposed to understand it). If MathML is not understood, some
>>> applications (e.g. libreoffice) are still able to display the pure text,
>>> which is very similar to the plain text export.
>>>
>>> BTW, thanks for fixing the update problem.
>>
>> Is this still being worked on or is it supposed to be fixed? I still
>> get SIGSEGVs. To reproduce, open Help > Introduction, select all, and
>> do "ctrl + c" and then "ctrl + c" again quickly after the first one.
>> Or do "ctrl + c", wait for the copy to finish, and then do "ctrl + c"
>> twice more.
>>
>> Scott
>
> I hope I fixed this issue today.
>
> Vincent

Thanks Vincent, I no longer get a crash. I still have the following
issues (let me know if I should open up tickets):

- When selecting all and copying UserGuide.lyx, I get the dialogs
mentioned before.

- When selecting all and copying Addional.lyx, I get the following message:
"LyX does not know how to include non-LyX files when generating HTML
output. Offending file:
SpecialParagraphShape.tex"

- When selecting all and copying EmbeddedObjects.lyx, I get the
following errors:
File '/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/DummyTextDocument.txt' is not readable!
support/FileName.cpp (732): File
'/tmp/lyx_tmpdir.n11551/EmbeddedObjects.lyx' is not readable!

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 Richard Heck wrote:

 There are a couple issues here. One is the problem of branches.
 Previously, we'd have pasted the copied paragraphs into the temporary
 Buffer, and with it whatever branch insets were in the copied material,
 not paying any attention at all to whether those branches existed, etc.
 I'm not sure what that would mean for what would end up on the
 clipboard. Probably we can just add a flag to the signature of
 pasteSelectionHelper() that means: don't ask about this, just do it (or
 not, which would be the old behavior).

 I'd simply create the branches. Does it have any drawback?

 The other issue is the sigsev. Here the problem is that the temporary
 Buffer we are using in putClipboard is static. So what we do to it
 remains from call to call. We clear the paragraphs, at the end of that
 routine, but we don't fully reset the Buffer's InsetText, which is why
 we get the crash.

 So if you remove the static keyword, the crash vanishes, but that does
 give a bit of a performance hit every time you copy something, because
 we have to create a new Buffer, with a new tempdir, and so forth. What
 we might want instead is a way to completely reset this temporary
 Buffer. Another option would be to keep the static (empty) Buffer and
 clone it each time, which ought to be cheap.

 I did this, and it works fine.

 By the way, I note that this copy is also very slow, because we are
 converting images to formats suitable for XHTML export, which never get
 used. We probably need another flag that means: don't do that, or bother
 creating math images, etc. We might also want to force math to be export
 as HTML, since the clipboard probably does not know what to do with
 MathML.

 I changed it to use MathML. Before copying HTML, only plaintext was copied,
 which did not play well to formulas at all. Now, there is at least the
 chance to recover formulas by applications that understand MathML (MS Office
 is supposed to understand it). If MathML is not understood, some
 applications (e.g. libreoffice) are still able to display the pure text,
 which is very similar to the plain text export.

 BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help  Introduction, select all, and
do ctrl + c and then ctrl + c again quickly after the first one.
Or do ctrl + c, wait for the copy to finish, and then do ctrl + c
twice more.

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sun, Apr 21, 2013 at 3:22 PM, Georg Baum
<georg.b...@post.rwth-aachen.de> wrote:
> Richard Heck wrote:
>
>> There are a couple issues here. One is the problem of branches.
>> Previously, we'd have "pasted" the copied paragraphs into the temporary
>> Buffer, and with it whatever branch insets were in the copied material,
>> not paying any attention at all to whether those branches existed, etc.
>> I'm not sure what that would mean for what would end up on the
>> clipboard. Probably we can just add a flag to the signature of
>> pasteSelectionHelper() that means: don't ask about this, just do it (or
>> not, which would be the old behavior).
>
> I'd simply create the branches. Does it have any drawback?
>
>> The other issue is the sigsev. Here the problem is that the temporary
>> Buffer we are using in putClipboard is static. So what we do to it
>> remains from call to call. We clear the paragraphs, at the end of that
>> routine, but we don't fully reset the Buffer's InsetText, which is why
>> we get the crash.
>>
>> So if you remove the static keyword, the crash vanishes, but that does
>> give a bit of a performance hit every time you copy something, because
>> we have to create a new Buffer, with a new tempdir, and so forth. What
>> we might want instead is a way to completely reset this temporary
>> Buffer. Another option would be to keep the static (empty) Buffer and
>> clone it each time, which ought to be cheap.
>
> I did this, and it works fine.
>
>> By the way, I note that this copy is also very slow, because we are
>> converting images to formats suitable for XHTML export, which never get
>> used. We probably need another flag that means: don't do that, or bother
>> creating math images, etc. We might also want to force math to be export
>> as HTML, since the clipboard probably does not know what to do with
>> MathML.
>
> I changed it to use MathML. Before copying HTML, only plaintext was copied,
> which did not play well to formulas at all. Now, there is at least the
> chance to recover formulas by applications that understand MathML (MS Office
> is supposed to understand it). If MathML is not understood, some
> applications (e.g. libreoffice) are still able to display the pure text,
> which is very similar to the plain text export.
>
> BTW, thanks for fixing the update problem.

Is this still being worked on or is it supposed to be fixed? I still
get SIGSEGVs. To reproduce, open Help > Introduction, select all, and
do "ctrl + c" and then "ctrl + c" again quickly after the first one.
Or do "ctrl + c", wait for the copy to finish, and then do "ctrl + c"
twice more.

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Richard Heck wrote:

 There are a couple issues here. One is the problem of branches.
 Previously, we'd have pasted the copied paragraphs into the temporary
 Buffer, and with it whatever branch insets were in the copied material,
 not paying any attention at all to whether those branches existed, etc.
 I'm not sure what that would mean for what would end up on the
 clipboard. Probably we can just add a flag to the signature of
 pasteSelectionHelper() that means: don't ask about this, just do it (or
 not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?

 The other issue is the sigsev. Here the problem is that the temporary
 Buffer we are using in putClipboard is static. So what we do to it
 remains from call to call. We clear the paragraphs, at the end of that
 routine, but we don't fully reset the Buffer's InsetText, which is why
 we get the crash.
 
 So if you remove the static keyword, the crash vanishes, but that does
 give a bit of a performance hit every time you copy something, because
 we have to create a new Buffer, with a new tempdir, and so forth. What
 we might want instead is a way to completely reset this temporary
 Buffer. Another option would be to keep the static (empty) Buffer and
 clone it each time, which ought to be cheap.

I did this, and it works fine.

 By the way, I note that this copy is also very slow, because we are
 converting images to formats suitable for XHTML export, which never get
 used. We probably need another flag that means: don't do that, or bother
 creating math images, etc. We might also want to force math to be export
 as HTML, since the clipboard probably does not know what to do with
 MathML.

I changed it to use MathML. Before copying HTML, only plaintext was copied, 
which did not play well to formulas at all. Now, there is at least the 
chance to recover formulas by applications that understand MathML (MS Office 
is supposed to understand it). If MathML is not understood, some 
applications (e.g. libreoffice) are still able to display the pure text, 
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.


Georg

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Richard Heck wrote:

> There are a couple issues here. One is the problem of branches.
> Previously, we'd have "pasted" the copied paragraphs into the temporary
> Buffer, and with it whatever branch insets were in the copied material,
> not paying any attention at all to whether those branches existed, etc.
> I'm not sure what that would mean for what would end up on the
> clipboard. Probably we can just add a flag to the signature of
> pasteSelectionHelper() that means: don't ask about this, just do it (or
> not, which would be the old behavior).

I'd simply create the branches. Does it have any drawback?

> The other issue is the sigsev. Here the problem is that the temporary
> Buffer we are using in putClipboard is static. So what we do to it
> remains from call to call. We clear the paragraphs, at the end of that
> routine, but we don't fully reset the Buffer's InsetText, which is why
> we get the crash.
> 
> So if you remove the static keyword, the crash vanishes, but that does
> give a bit of a performance hit every time you copy something, because
> we have to create a new Buffer, with a new tempdir, and so forth. What
> we might want instead is a way to completely reset this temporary
> Buffer. Another option would be to keep the static (empty) Buffer and
> clone it each time, which ought to be cheap.

I did this, and it works fine.

> By the way, I note that this copy is also very slow, because we are
> converting images to formats suitable for XHTML export, which never get
> used. We probably need another flag that means: don't do that, or bother
> creating math images, etc. We might also want to force math to be export
> as HTML, since the clipboard probably does not know what to do with
> MathML.

I changed it to use MathML. Before copying HTML, only plaintext was copied, 
which did not play well to formulas at all. Now, there is at least the 
chance to recover formulas by applications that understand MathML (MS Office 
is supposed to understand it). If MathML is not understood, some 
applications (e.g. libreoffice) are still able to display the pure text, 
which is very similar to the plain text export.

BTW, thanks for fixing the update problem.


Georg

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Scott Kostyshak wrote:

 I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
 following: 1. Open the User's Guide, Additional Features, Embedded
 Objects, or Math manual. 2. Select all
 3. Copy

Thanks, I can reproduce it. The attached patch works around the problem. It 
looks like the temp buffer misses the math macro definitions (a call to 
updateMacros() which should set docit_ did not help). Does anybody know a 
better solution?


Georgdiff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 4cfdbca..b3bca44 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -2181,7 +2181,7 @@ docstring InsetMathHull::xhtml(XHTMLStream  xs, OutputParams const  op) const
 	// aren't doing LaTeX, in which case we are doing Images.
 	if (!success  mathtype != BufferParams::LaTeX) {
 		graphics::PreviewImage const * pimage = 0;
-		if (!op.dryrun) {
+		if (!op.dryrun  docit_.buffer()) {
 			loadPreview(docit_);
 			pimage = preview_-getPreviewImage(buffer());
 			// FIXME Do we always have png?

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 12:16 PM, Georg Baum wrote:

Scott Kostyshak wrote:


I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
following: 1. Open the User's Guide, Additional Features, Embedded
Objects, or Math manual. 2. Select all
3. Copy

Thanks, I can reproduce it. The attached patch works around the problem. It
looks like the temp buffer misses the math macro definitions (a call to
updateMacros() which should set docit_ did not help). Does anybody know a
better solution?


My general thought after looking at this is that we need to do some work 
on the paragraphs, after we paste them into the new buffer, and that the 
work we need to do is very much like what happens when we do a real 
paste. So perhaps the thing to do is try to use pasteParagraphList() 
here, or something of the sort, since all that work does actually get 
done there.


Of course, the problem here is that we need to pass a Cursor to 
pasteParagraphList(), and we do not have a BufferView for the temp 
Buffer. But it seems the right idea.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 06:37 PM, Richard Heck wrote:

On 04/20/2013 12:16 PM, Georg Baum wrote:

Scott Kostyshak wrote:


I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
following: 1. Open the User's Guide, Additional Features, Embedded
Objects, or Math manual. 2. Select all
3. Copy
Thanks, I can reproduce it. The attached patch works around the 
problem. It

looks like the temp buffer misses the math macro definitions (a call to
updateMacros() which should set docit_ did not help). Does anybody 
know a

better solution?


My general thought after looking at this is that we need to do some 
work on the paragraphs, after we paste them into the new buffer, and 
that the work we need to do is very much like what happens when we do 
a real paste. So perhaps the thing to do is try to use 
pasteParagraphList() here, or something of the sort, since all that 
work does actually get done there.


Of course, the problem here is that we need to pass a Cursor to 
pasteParagraphList(), and we do not have a BufferView for the temp 
Buffer. But it seems the right idea.


So what we really needed here is an updateMacros() call, but the other 
issue was that this only does what we need it to do---call 
recordLocation() to set docit_---if we are exporting the Buffer. So that 
had to be set, as well.


The attached patch works for me, but there are some things about it that 
are a bit hackish at this point. I'll work on it a bit more and fix that 
problem.


Richard

From 009078790608fd7f33e6279dd275a5926cc77aaa Mon Sep 17 00:00:00 2001
From: Richard Heck rgh...@lyx.org
Date: Sat, 20 Apr 2013 19:15:00 -0400
Subject: [PATCH] Temp.

---
 src/Buffer.cpp  | 18 --
 src/Buffer.h| 19 ++-
 src/CutAndPaste.cpp |  8 ++--
 src/DocIterator.h   |  3 +++
 4 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index adda71f..1d9061c 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -3726,24 +3726,6 @@ bool Buffer::autoSave() const
 }
 
 
-// helper class, to guarantee this gets reset properly
-class Buffer::MarkAsExporting {
-public:
-	MarkAsExporting(Buffer const * buf) : buf_(buf)
-	{
-		LASSERT(buf_, /* */);
-		buf_-setExportStatus(true);
-	}
-	~MarkAsExporting()
-	{
-		buf_-setExportStatus(false);
-	}
-private:
-	Buffer const * const buf_;
-};
-
-
-
 void Buffer::setExportStatus(bool e) const
 {
 	d-doing_export = e;
diff --git a/src/Buffer.h b/src/Buffer.h
index 18e57f9..81b50c5 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -94,6 +94,9 @@ typedef std::setBuffer * CloneList;
  * minimal, probably not.
  * \author Lars Gullik Bjønnes
  */
+
+class MarkAsExporting;
+
 class Buffer {
 public:
 	/// What type of log will \c getLogName() return?
@@ -717,7 +720,6 @@ public:
 	int charCount(bool with_blanks) const;
 
 private:
-	class MarkAsExporting;
 	friend class MarkAsExporting;
 	/// mark the buffer as busy exporting something, or not
 	void setExportStatus(bool e) const;
@@ -753,6 +755,21 @@ private:
 };
 
 
+class MarkAsExporting {
+public:
+	MarkAsExporting(Buffer const * buf) : buf_(buf)
+	{
+		buf_-setExportStatus(true);
+	}
+	~MarkAsExporting()
+	{
+		buf_-setExportStatus(false);
+	}
+private:
+	Buffer const * const buf_;
+};
+
+
 } // namespace lyx
 
 #endif
diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index def5683..53547f0 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -99,7 +99,7 @@ bool checkPastePossible(int index)
 
 
 pairPitPosPair, pit_type
-pasteSelectionHelper(Cursor const  cur, ParagraphList const  parlist,
+pasteSelectionHelper(DocIterator const  cur, ParagraphList const  parlist,
 		 DocumentClassConstPtr oldDocClass, ErrorList  errorlist)
 {
 	Buffer const  buffer = *cur.buffer();
@@ -472,9 +472,13 @@ void putClipboard(ParagraphList const  paragraphs,
 	static Buffer * buffer = theBufferList().newInternalBuffer(
 		FileName::tempName(clipboard.internal).absFileName());
 	buffer-setUnnamed(true);
-	buffer-paragraphs() = paragraphs;
 	buffer-inset().setBuffer(*buffer);
 	buffer-params().setDocumentClass(docclass);
+	DocIterator dit = doc_iterator_begin(buffer, buffer-inset());
+	ErrorList el;
+	pasteSelectionHelper(dit, paragraphs, docclass, el);
+	MarkAsExporting mex(buffer);
+	buffer-updateMacros();
 	string lyx;
 	ostringstream oslyx;
 	if (buffer-write(oslyx))
diff --git a/src/DocIterator.h b/src/DocIterator.h
index 3d5647c..8ca29d5 100644
--- a/src/DocIterator.h
+++ b/src/DocIterator.h
@@ -143,6 +143,9 @@ public:
 	/// are we in regexp-mode ?
 	bool inRegexped() const;
 
+	///
+	virtual void forceBufferUpdate() const {}
+
 	//
 	// math-specific part
 	//
-- 
1.7.11.7

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sat, Apr 20, 2013 at 7:15 PM, Richard Heck rgh...@lyx.org wrote:
 So what we really needed here is an updateMacros() call, but the other issue
 was that this only does what we need it to do---call recordLocation() to set
 docit_---if we are exporting the Buffer. So that had to be set, as well.

 The attached patch works for me, but there are some things about it that are
 a bit hackish at this point. I'll work on it a bit more and fix that
 problem.

I tested after your recent commit (db358a43) and with the User's Guide
open I do select all and copy, and I get The pasted branch Question
is undefined. Do you want to add it to the document's branch list?
Note that this message appears after a copy, before anything else.

After clicking Add or Don't Add on the message box and the
following ones, the copy seems to work. Then, if I do select all and
copy again, I immediately get a SIGSEGV.

Can anyone else reproduce this?

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 09:37 PM, Scott Kostyshak wrote:

On Sat, Apr 20, 2013 at 7:15 PM, Richard Heck rgh...@lyx.org wrote:

So what we really needed here is an updateMacros() call, but the other issue
was that this only does what we need it to do---call recordLocation() to set
docit_---if we are exporting the Buffer. So that had to be set, as well.

The attached patch works for me, but there are some things about it that are
a bit hackish at this point. I'll work on it a bit more and fix that
problem.

I tested after your recent commit (db358a43) and with the User's Guide
open I do select all and copy, and I get The pasted branch Question
is undefined. Do you want to add it to the document's branch list?
Note that this message appears after a copy, before anything else.

After clicking Add or Don't Add on the message box and the
following ones, the copy seems to work. Then, if I do select all and
copy again, I immediately get a SIGSEGV.

Can anyone else reproduce this?


Confirmed. I'm not terribly surprised by this. We're asking the 
temporary Buffer to do more work now than we were before. We saw similar 
behavior with the advanced FR stuff at first.


There are a couple issues here. One is the problem of branches. 
Previously, we'd have pasted the copied paragraphs into the temporary 
Buffer, and with it whatever branch insets were in the copied material, 
not paying any attention at all to whether those branches existed, etc. 
I'm not sure what that would mean for what would end up on the 
clipboard. Probably we can just add a flag to the signature of 
pasteSelectionHelper() that means: don't ask about this, just do it (or 
not, which would be the old behavior).


The other issue is the sigsev. Here the problem is that the temporary 
Buffer we are using in putClipboard is static. So what we do to it 
remains from call to call. We clear the paragraphs, at the end of that 
routine, but we don't fully reset the Buffer's InsetText, which is why 
we get the crash.


So if you remove the static keyword, the crash vanishes, but that does 
give a bit of a performance hit every time you copy something, because 
we have to create a new Buffer, with a new tempdir, and so forth. What 
we might want instead is a way to completely reset this temporary 
Buffer. Another option would be to keep the static (empty) Buffer and 
clone it each time, which ought to be cheap.


By the way, I note that this copy is also very slow, because we are 
converting images to formats suitable for XHTML export, which never get 
used. We probably need another flag that means: don't do that, or bother 
creating math images, etc. We might also want to force math to be export 
as HTML, since the clipboard probably does not know what to do with MathML.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Georg Baum]

Scott Kostyshak wrote:

> I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
> following: 1. Open the User's Guide, Additional Features, Embedded
> Objects, or Math manual. 2. Select all
> 3. Copy

Thanks, I can reproduce it. The attached patch works around the problem. It 
looks like the temp buffer misses the math macro definitions (a call to 
updateMacros() which should set docit_ did not help). Does anybody know a 
better solution?


Georgdiff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 4cfdbca..b3bca44 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -2181,7 +2181,7 @@ docstring InsetMathHull::xhtml(XHTMLStream & xs, OutputParams const & op) const
 	// aren't doing LaTeX, in which case we are doing Images.
 	if (!success && mathtype != BufferParams::LaTeX) {
 		graphics::PreviewImage const * pimage = 0;
-		if (!op.dryrun) {
+		if (!op.dryrun && docit_.buffer()) {
 			loadPreview(docit_);
 			pimage = preview_->getPreviewImage(buffer());
 			// FIXME Do we always have png?

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 12:16 PM, Georg Baum wrote:

Scott Kostyshak wrote:


I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
following: 1. Open the User's Guide, Additional Features, Embedded
Objects, or Math manual. 2. Select all
3. Copy

Thanks, I can reproduce it. The attached patch works around the problem. It
looks like the temp buffer misses the math macro definitions (a call to
updateMacros() which should set docit_ did not help). Does anybody know a
better solution?


My general thought after looking at this is that we need to do some work 
on the paragraphs, after we paste them into the new buffer, and that the 
work we need to do is very much like what happens when we do a real 
paste. So perhaps the thing to do is try to use pasteParagraphList() 
here, or something of the sort, since all that work does actually get 
done there.


Of course, the problem here is that we need to pass a Cursor to 
pasteParagraphList(), and we do not have a BufferView for the temp 
Buffer. But it seems the right idea.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 06:37 PM, Richard Heck wrote:

On 04/20/2013 12:16 PM, Georg Baum wrote:

Scott Kostyshak wrote:


I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the
following: 1. Open the User's Guide, Additional Features, Embedded
Objects, or Math manual. 2. Select all
3. Copy
Thanks, I can reproduce it. The attached patch works around the 
problem. It

looks like the temp buffer misses the math macro definitions (a call to
updateMacros() which should set docit_ did not help). Does anybody 
know a

better solution?


My general thought after looking at this is that we need to do some 
work on the paragraphs, after we paste them into the new buffer, and 
that the work we need to do is very much like what happens when we do 
a real paste. So perhaps the thing to do is try to use 
pasteParagraphList() here, or something of the sort, since all that 
work does actually get done there.


Of course, the problem here is that we need to pass a Cursor to 
pasteParagraphList(), and we do not have a BufferView for the temp 
Buffer. But it seems the right idea.


So what we really needed here is an updateMacros() call, but the other 
issue was that this only does what we need it to do---call 
recordLocation() to set docit_---if we are exporting the Buffer. So that 
had to be set, as well.


The attached patch works for me, but there are some things about it that 
are a bit hackish at this point. I'll work on it a bit more and fix that 
problem.


Richard

>From 009078790608fd7f33e6279dd275a5926cc77aaa Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Sat, 20 Apr 2013 19:15:00 -0400
Subject: [PATCH] Temp.

---
 src/Buffer.cpp  | 18 --
 src/Buffer.h| 19 ++-
 src/CutAndPaste.cpp |  8 ++--
 src/DocIterator.h   |  3 +++
 4 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index adda71f..1d9061c 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -3726,24 +3726,6 @@ bool Buffer::autoSave() const
 }
 
 
-// helper class, to guarantee this gets reset properly
-class Buffer::MarkAsExporting {
-public:
-	MarkAsExporting(Buffer const * buf) : buf_(buf)
-	{
-		LASSERT(buf_, /* */);
-		buf_->setExportStatus(true);
-	}
-	~MarkAsExporting()
-	{
-		buf_->setExportStatus(false);
-	}
-private:
-	Buffer const * const buf_;
-};
-
-
-
 void Buffer::setExportStatus(bool e) const
 {
 	d->doing_export = e;
diff --git a/src/Buffer.h b/src/Buffer.h
index 18e57f9..81b50c5 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -94,6 +94,9 @@ typedef std::set CloneList;
  * minimal, probably not.
  * \author Lars Gullik Bjønnes
  */
+
+class MarkAsExporting;
+
 class Buffer {
 public:
 	/// What type of log will \c getLogName() return?
@@ -717,7 +720,6 @@ public:
 	int charCount(bool with_blanks) const;
 
 private:
-	class MarkAsExporting;
 	friend class MarkAsExporting;
 	/// mark the buffer as busy exporting something, or not
 	void setExportStatus(bool e) const;
@@ -753,6 +755,21 @@ private:
 };
 
 
+class MarkAsExporting {
+public:
+	MarkAsExporting(Buffer const * buf) : buf_(buf)
+	{
+		buf_->setExportStatus(true);
+	}
+	~MarkAsExporting()
+	{
+		buf_->setExportStatus(false);
+	}
+private:
+	Buffer const * const buf_;
+};
+
+
 } // namespace lyx
 
 #endif
diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index def5683..53547f0 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -99,7 +99,7 @@ bool checkPastePossible(int index)
 
 
 pair
-pasteSelectionHelper(Cursor const & cur, ParagraphList const & parlist,
+pasteSelectionHelper(DocIterator const & cur, ParagraphList const & parlist,
 		 DocumentClassConstPtr oldDocClass, ErrorList & errorlist)
 {
 	Buffer const & buffer = *cur.buffer();
@@ -472,9 +472,13 @@ void putClipboard(ParagraphList const & paragraphs,
 	static Buffer * buffer = theBufferList().newInternalBuffer(
 		FileName::tempName("clipboard.internal").absFileName());
 	buffer->setUnnamed(true);
-	buffer->paragraphs() = paragraphs;
 	buffer->inset().setBuffer(*buffer);
 	buffer->params().setDocumentClass(docclass);
+	DocIterator dit = doc_iterator_begin(buffer, >inset());
+	ErrorList el;
+	pasteSelectionHelper(dit, paragraphs, docclass, el);
+	MarkAsExporting mex(buffer);
+	buffer->updateMacros();
 	string lyx;
 	ostringstream oslyx;
 	if (buffer->write(oslyx))
diff --git a/src/DocIterator.h b/src/DocIterator.h
index 3d5647c..8ca29d5 100644
--- a/src/DocIterator.h
+++ b/src/DocIterator.h
@@ -143,6 +143,9 @@ public:
 	/// are we in regexp-mode ?
 	bool inRegexped() const;
 
+	///
+	virtual void forceBufferUpdate() const {}
+
 	//
 	// math-specific part
 	//
-- 
1.7.11.7

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Sat, Apr 20, 2013 at 7:15 PM, Richard Heck  wrote:
> So what we really needed here is an updateMacros() call, but the other issue
> was that this only does what we need it to do---call recordLocation() to set
> docit_---if we are exporting the Buffer. So that had to be set, as well.
>
> The attached patch works for me, but there are some things about it that are
> a bit hackish at this point. I'll work on it a bit more and fix that
> problem.

I tested after your recent commit (db358a43) and with the User's Guide
open I do select all and copy, and I get "The pasted branch Question
is undefined. Do you want to add it to the document's branch list?"
Note that this message appears after a copy, before anything else.

After clicking "Add" or "Don't Add" on the message box and the
following ones, the copy seems to work. Then, if I do select all and
copy again, I immediately get a SIGSEGV.

Can anyone else reproduce this?

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Richard Heck]

On 04/20/2013 09:37 PM, Scott Kostyshak wrote:

On Sat, Apr 20, 2013 at 7:15 PM, Richard Heck <rgh...@lyx.org> wrote:

So what we really needed here is an updateMacros() call, but the other issue
was that this only does what we need it to do---call recordLocation() to set
docit_---if we are exporting the Buffer. So that had to be set, as well.

The attached patch works for me, but there are some things about it that are
a bit hackish at this point. I'll work on it a bit more and fix that
problem.

I tested after your recent commit (db358a43) and with the User's Guide
open I do select all and copy, and I get "The pasted branch Question
is undefined. Do you want to add it to the document's branch list?"
Note that this message appears after a copy, before anything else.

After clicking "Add" or "Don't Add" on the message box and the
following ones, the copy seems to work. Then, if I do select all and
copy again, I immediately get a SIGSEGV.

Can anyone else reproduce this?


Confirmed. I'm not terribly surprised by this. We're asking the 
temporary Buffer to do more work now than we were before. We saw similar 
behavior with the advanced F stuff at first.


There are a couple issues here. One is the problem of branches. 
Previously, we'd have "pasted" the copied paragraphs into the temporary 
Buffer, and with it whatever branch insets were in the copied material, 
not paying any attention at all to whether those branches existed, etc. 
I'm not sure what that would mean for what would end up on the 
clipboard. Probably we can just add a flag to the signature of 
pasteSelectionHelper() that means: don't ask about this, just do it (or 
not, which would be the old behavior).


The other issue is the sigsev. Here the problem is that the temporary 
Buffer we are using in putClipboard is static. So what we do to it 
remains from call to call. We clear the paragraphs, at the end of that 
routine, but we don't fully reset the Buffer's InsetText, which is why 
we get the crash.


So if you remove the static keyword, the crash vanishes, but that does 
give a bit of a performance hit every time you copy something, because 
we have to create a new Buffer, with a new tempdir, and so forth. What 
we might want instead is a way to completely reset this temporary 
Buffer. Another option would be to keep the static (empty) Buffer and 
clone it each time, which ought to be cheap.


By the way, I note that this copy is also very slow, because we are 
converting images to formats suitable for XHTML export, which never get 
used. We probably need another flag that means: don't do that, or bother 
creating math images, etc. We might also want to force math to be export 
as HTML, since the clipboard probably does not know what to do with MathML.


Richard

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Fri, Apr 12, 2013 at 4:16 PM, Georg Baum b...@lyx.org wrote:
 The branch, master, has been updated.

 - Log -

 commit 0613a218aad1482ff3003a7cc4755c0b9651f3c2
 Author: Georg Baum b...@lyx.org
 Date:   Fri Apr 12 22:12:47 2013 +0200

 Also put HTML on the clipboard when copying

 The HTML export is now mature enough so that it can be used to transfer
 formatted text to the clipboard. This enhances interoperability e.g. with
 office applications.

I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the following:
1. Open the User's Guide, Additional Features, Embedded Objects, or Math manual.
2. Select all
3. Copy

Below is the backtrace I get from following the above steps with the
User's Guide:

#0  0x00960b2a in lyx::Buffer::listMacroNames (this=0x0, macros=...)
at /home/scott/lyxbuilds/master/build/src/Buffer.cpp:3259
#1  0x00bf3f83 in lyx::InsetMathHull::preparePreview (this=0x421abc0,
pos=..., forexport=true)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:599
#2  0x00bf48bd in lyx::InsetMathHull::loadPreview (this=0x421abc0,
pos=...)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:649
#3  0x00bfebc8 in lyx::InsetMathHull::xhtml (this=0x421abc0, xs=...,
op=...)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:2185
#4  0x00a4da02 in lyx::Paragraph::simpleLyXHTMLOnePar (this=0x421a780,
buf=..., xs=..., runparams=..., outerfont=..., initial=0)
at /home/scott/lyxbuilds/master/build/src/Paragraph.cpp:2939
#5  0x00b05825 in lyx::(anonymous namespace)::makeParagraphs (buf=...,
xs=..., runparams=..., text=..., pbegin=..., pend=...)
at /home/scott/lyxbuilds/master/build/src/output_xhtml.cpp:726
#6  0x00b06be8 in lyx::xhtmlParagraphs (text=..., buf=..., xs=...,
runparams=...)
at /home/scott/lyxbuilds/master/build/src/output_xhtml.cpp:1021
#7  0x00959696 in lyx::Buffer::writeLyXHTMLSource (this=0x45edbf0,
os=..., runparams=..., output=lyx::Buffer::FullSource)
at /home/scott/lyxbuilds/master/build/src/Buffer.cpp:1947
#8  0x00aedc77 in lyx::(anonymous namespace)::putClipboard (
paragraphs=..., docclass=..., plaintext=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:484
#9  0x00af0799 in lyx::cap::copySelection (cur=..., plaintext=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:935
#10 0x00aefc57 in lyx::cap::copySelection (cur=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:837
#11 0x00bb6106 in lyx::Text::dispatch (this=0x26387b0, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/Text3.cpp:1292
#12 0x00d89a48 in lyx::InsetText::doDispatch (this=0x2638790, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/insets/InsetText.cpp:316
#13 0x00d368b2 in lyx::Inset::dispatch (this=0x2638790, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/insets/Inset.cpp:319
#14 0x00b2befb in lyx::Cursor::dispatch (this=0x35b8bf8, cmd0=...)
at /home/scott/lyxbuilds/master/build/src/Cursor.cpp:409
#15 0x00e018a5 in lyx::frontend::GuiView::dispatchToBufferView (
this=0x16e9170, cmd=..., dr=...)
at /home/scott/lyxbuilds/master/build/src/frontends/qt4/GuiView.cpp:3235
#16 0x00e04e1b in lyx::frontend::GuiView::dispatch (this=0x16e9170,
cmd=..., dr=...)
at /home/scott/lyxbuilds/master/build/src/frontends/qt4/GuiView.cpp:3774

Scott

Re: [LyX master] Also put HTML on the clipboard when copying

[Scott Kostyshak]

On Fri, Apr 12, 2013 at 4:16 PM, Georg Baum <b...@lyx.org> wrote:
> The branch, master, has been updated.
>
> - Log -
>
> commit 0613a218aad1482ff3003a7cc4755c0b9651f3c2
> Author: Georg Baum <b...@lyx.org>
> Date:   Fri Apr 12 22:12:47 2013 +0200
>
> Also put HTML on the clipboard when copying
>
> The HTML export is now mature enough so that it can be used to transfer
> formatted text to the clipboard. This enhances interoperability e.g. with
> office applications.

I'm getting a SIGSEGV now. I can reproduce on Ubuntu 12.04 with the following:
1. Open the User's Guide, Additional Features, Embedded Objects, or Math manual.
2. Select all
3. Copy

Below is the backtrace I get from following the above steps with the
User's Guide:

#0  0x00960b2a in lyx::Buffer::listMacroNames (this=0x0, macros=...)
at /home/scott/lyxbuilds/master/build/src/Buffer.cpp:3259
#1  0x00bf3f83 in lyx::InsetMathHull::preparePreview (this=0x421abc0,
pos=..., forexport=true)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:599
#2  0x00bf48bd in lyx::InsetMathHull::loadPreview (this=0x421abc0,
pos=...)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:649
#3  0x00bfebc8 in lyx::InsetMathHull::xhtml (this=0x421abc0, xs=...,
op=...)
at /home/scott/lyxbuilds/master/build/src/mathed/InsetMathHull.cpp:2185
#4  0x00a4da02 in lyx::Paragraph::simpleLyXHTMLOnePar (this=0x421a780,
buf=..., xs=..., runparams=..., outerfont=..., initial=0)
at /home/scott/lyxbuilds/master/build/src/Paragraph.cpp:2939
#5  0x00b05825 in lyx::(anonymous namespace)::makeParagraphs (buf=...,
xs=..., runparams=..., text=..., pbegin=..., pend=...)
at /home/scott/lyxbuilds/master/build/src/output_xhtml.cpp:726
#6  0x00b06be8 in lyx::xhtmlParagraphs (text=..., buf=..., xs=...,
runparams=...)
at /home/scott/lyxbuilds/master/build/src/output_xhtml.cpp:1021
#7  0x00959696 in lyx::Buffer::writeLyXHTMLSource (this=0x45edbf0,
os=..., runparams=..., output=lyx::Buffer::FullSource)
at /home/scott/lyxbuilds/master/build/src/Buffer.cpp:1947
#8  0x00aedc77 in lyx::(anonymous namespace)::putClipboard (
paragraphs=..., docclass=..., plaintext=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:484
#9  0x00af0799 in lyx::cap::copySelection (cur=..., plaintext=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:935
#10 0x00aefc57 in lyx::cap::copySelection (cur=...)
at /home/scott/lyxbuilds/master/build/src/CutAndPaste.cpp:837
#11 0x00bb6106 in lyx::Text::dispatch (this=0x26387b0, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/Text3.cpp:1292
#12 0x00d89a48 in lyx::InsetText::doDispatch (this=0x2638790, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/insets/InsetText.cpp:316
#13 0x00d368b2 in lyx::Inset::dispatch (this=0x2638790, cur=...,
cmd=...) at /home/scott/lyxbuilds/master/build/src/insets/Inset.cpp:319
#14 0x00b2befb in lyx::Cursor::dispatch (this=0x35b8bf8, cmd0=...)
at /home/scott/lyxbuilds/master/build/src/Cursor.cpp:409
#15 0x00e018a5 in lyx::frontend::GuiView::dispatchToBufferView (
this=0x16e9170, cmd=..., dr=...)
at /home/scott/lyxbuilds/master/build/src/frontends/qt4/GuiView.cpp:3235
#16 0x00e04e1b in lyx::frontend::GuiView::dispatch (this=0x16e9170,
cmd=..., dr=...)
at /home/scott/lyxbuilds/master/build/src/frontends/qt4/GuiView.cpp:3774

Scott

Copy'n'Paste without modifying Clipboard

[Tommaso Cucinotta]

Hi,

does anyone have a hint on the code needed to copy the current selection 
from one buffer and paste it into another buffer, without affecting the 
user's clipboard ?


On a related note, what is the Cut stack ?

Also, is it true that all of these paste methods [1] (from 
CutAndPaste.h) work only in text mode ?


What is the simplest way to copy a segment of LyX text (inclusive of 
maths and whatever may be there), and paste it into another LyX buffer, 
just emulating C-c followed by C-v ?


Thanks,

T.

[1]
/// Paste the current selection at \p cur
/// Does handle undo. Does only work in text, not mathed.
void pasteSelection(Cursor  cur, ErrorList );
/// Replace the current selection with the clipboard contents as text
/// (internal or external: which is newer).
/// Does handle undo. Does only work in text, not mathed.
void pasteClipboardText(Cursor  cur, ErrorList  errorList,
bool asParagraphs = true);
/// Replace the current selection with the clipboard contents as graphic.
/// Does handle undo. Does only work in text, not mathed.
void pasteClipboardGraphics(Cursor  cur, ErrorList  errorList,
Clipboard::GraphicsType preferedType = Clipboard::AnyGraphicsType);
/// Replace the current selection with cut buffer \c sel_index
/// Does handle undo. Does only work in text, not mathed.
void pasteFromStack(Cursor  cur, ErrorList  errorList, size_t sel_index);
/// Paste the clipboard as simple text, removing any formatting
void pasteSimpleText(Cursor  cur, bool asParagraphs);

/// Paste the paragraph list \p parlist at the position given by \p cur.
/// Does not handle undo. Does only work in text, not mathed.
void pasteParagraphList(Cursor  cur, ParagraphList const  parlist,
DocumentClass const * const textclass, ErrorList  errorList);

Copy'n'Paste without modifying Clipboard

[Tommaso Cucinotta]

Hi,

does anyone have a hint on the code needed to copy the current selection 
from one buffer and paste it into another buffer, without affecting the 
user's clipboard ?


On a related note, what is the "Cut stack" ?

Also, is it true that all of these paste methods [1] (from 
CutAndPaste.h) work only in text mode ?


What is the simplest way to copy a segment of LyX text (inclusive of 
maths and whatever may be there), and paste it into another LyX buffer, 
just emulating C-c followed by C-v ?


Thanks,

T.

[1]
/// Paste the current selection at \p cur
/// Does handle undo. Does only work in text, not mathed.
void pasteSelection(Cursor & cur, ErrorList &);
/// Replace the current selection with the clipboard contents as text
/// (internal or external: which is newer).
/// Does handle undo. Does only work in text, not mathed.
void pasteClipboardText(Cursor & cur, ErrorList & errorList,
bool asParagraphs = true);
/// Replace the current selection with the clipboard contents as graphic.
/// Does handle undo. Does only work in text, not mathed.
void pasteClipboardGraphics(Cursor & cur, ErrorList & errorList,
Clipboard::GraphicsType preferedType = Clipboard::AnyGraphicsType);
/// Replace the current selection with cut buffer \c sel_index
/// Does handle undo. Does only work in text, not mathed.
void pasteFromStack(Cursor & cur, ErrorList & errorList, size_t sel_index);
/// Paste the clipboard as simple text, removing any formatting
void pasteSimpleText(Cursor & cur, bool asParagraphs);

/// Paste the paragraph list \p parlist at the position given by \p cur.
/// Does not handle undo. Does only work in text, not mathed.
void pasteParagraphList(Cursor & cur, ParagraphList const & parlist,
DocumentClass const * const textclass, ErrorList & errorList);

Re: creating lyx note causes clipboard copy

[Helge Hafting]

On 05. jan. 2011 21:47, Georg Baum wrote:

Helge Hafting wrote:


On 28. des. 2010 23:22, Pavel Sanda wrote:

Jack Tanner wrote:

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed
inside a new note.
5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)


iirc this is because inserting word1 into the note inset (4) is actually
done via clipboard.


As a linux user, when I mark something, I expect it to be in the
clipboard already - because I marked it. (In linux, you don't need to
copy. This saves keypresses.) With this model, LyX is correct:
* select word2, putting it on the clipboard
* redundant copy
* select word1, putting it on the clipboard replacing word2
* Insert Note
* Paste, and get word1 which is still on the clipboard as it is still
selected.


You are confusing selection and clipboard (as do all X11 clipboard
managers I know).

Thanks for clearing that up.


Well, saving and resetting the clipboard would be one possible way to fix
this bug.


It would, but it also causes LyX to do extra work. Compare:

1. My approach
 a.  Save selection in some temporary storage,
 b.  insert box/note/whatever
 c.  re-insert selection inside box/note

2. The clipboard approach
 a. Save the clipboard to temporary storage
 b. Move selection to clipboard
 c. insert box/note/whatever
 d. paste clipboard into box/note
 e. reinstate clipboard from temporary storage

The clipboard approach *may* be easier to program because of existing 
code to access the system clipboard. But it does more work, and who 
knows how big the contents of the clipboard may be? There could be 
something really big there - some other app might cut/paste big images 
or uncompressed video files.


In some cases, the first approach might be possible without moving data
to temporary storage at all - i.e. allocate a box/note, move selection 
from the LyX buffer into the box/note, then insert the box/note with 
content into LyX.


Helge Hafting

Re: creating lyx note causes clipboard copy

[Helge Hafting]

On 05. jan. 2011 21:47, Georg Baum wrote:

Helge Hafting wrote:


On 28. des. 2010 23:22, Pavel Sanda wrote:

Jack Tanner wrote:

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed
inside a new note.
5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)


iirc this is because inserting word1 into the note inset (4) is actually
done via clipboard.


As a linux user, when I mark something, I expect it to be in the
clipboard already - because I marked it. (In linux, you don't need to
"copy". This saves keypresses.) With this model, LyX is correct:
* select word2, putting it on the clipboard
* redundant "copy"
* select word1, putting it on the clipboard replacing word2
* Insert Note
* Paste, and get word1 which is still on the clipboard as it is still
selected.


You are confusing selection and clipboard (as do all X11 "clipboard
managers" I know).

Thanks for clearing that up.


Well, saving and resetting the clipboard would be one possible way to fix
this bug.


It would, but it also causes LyX to do extra work. Compare:

1. My approach
 a.  Save selection in some temporary storage,
 b.  insert box/note/whatever
 c.  re-insert selection inside box/note

2. The clipboard approach
 a. Save the clipboard to temporary storage
 b. Move selection to clipboard
 c. insert box/note/whatever
 d. paste clipboard into box/note
 e. reinstate clipboard from temporary storage

The clipboard approach *may* be easier to program because of existing 
code to access the system clipboard. But it does more work, and who 
knows how big the contents of the clipboard may be? There could be 
something really big there - some other app might cut/paste big images 
or uncompressed video files.


In some cases, the first approach might be possible without moving data
to temporary storage at all - i.e. allocate a box/note, move selection 
from the LyX buffer into the box/note, then insert the box/note with 
content into LyX.


Helge Hafting

Re: creating lyx note causes clipboard copy

[Georg Baum]

Helge Hafting wrote:

 On 28. des. 2010 23:22, Pavel Sanda wrote:
 Jack Tanner wrote:
 1. Create a new document.
 2. Type in two words, word1 and word2.
 3. Select and copy word2.
 4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed
 inside a new note.
 5. Paste.

 Expected: paste outputs word2, as copied in (3)

 Actual: paste outputs word1, from (4)

 iirc this is because inserting word1 into the note inset (4) is actually
 done via clipboard.

 As a linux user, when I mark something, I expect it to be in the
 clipboard already - because I marked it. (In linux, you don't need to
 copy. This saves keypresses.) With this model, LyX is correct:
 * select word2, putting it on the clipboard
 * redundant copy
 * select word1, putting it on the clipboard replacing word2
 * Insert Note
 * Paste, and get word1 which is still on the clipboard as it is still
selected.

You are confusing selection and clipboard (as do all X11 clipboard 
managers I know). The selection is filled automatically and can be pasted 
with middle mouse button, and the clipboard is only filled by explicit user 
request (C-C) and can be pasted with C-V. So, what you describe above is not 
the clipboard, but basically the selection (modulo the 'redundant copy').

 Unfortunately, some other systems wants to do this the harder way. In
 that case, the behavior is a mild bug. The users do not expect the
 clipboard to be involved - unless they involve it explicitly. Please
 don't add code to save the system clipboard state to fix this.

Well, saving and resetting the clipboard would be one possible way to fix 
this bug. I agree that the selection should continue to work as it does, and 
it should indeed contain the note contents after inserting the note, but the 
clipboard should definitely not be altered by this operation.


Georg

Re: creating lyx note causes clipboard copy

[Georg Baum]

Helge Hafting wrote:

> On 28. des. 2010 23:22, Pavel Sanda wrote:
>> Jack Tanner wrote:
>>> 1. Create a new document.
>>> 2. Type in two words, word1 and word2.
>>> 3. Select and copy word2.
>>> 4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed
>>> inside a new note.
>>> 5. Paste.
>>>
>>> Expected: paste outputs word2, as copied in (3)
>>>
>>> Actual: paste outputs word1, from (4)
>>
>> iirc this is because inserting word1 into the note inset (4) is actually
>> done via clipboard.
>
> As a linux user, when I mark something, I expect it to be in the
> clipboard already - because I marked it. (In linux, you don't need to
> "copy". This saves keypresses.) With this model, LyX is correct:
> * select word2, putting it on the clipboard
> * redundant "copy"
> * select word1, putting it on the clipboard replacing word2
> * Insert Note
> * Paste, and get word1 which is still on the clipboard as it is still
>selected.

You are confusing selection and clipboard (as do all X11 "clipboard 
managers" I know). The selection is filled automatically and can be pasted 
with middle mouse button, and the clipboard is only filled by explicit user 
request (C-C) and can be pasted with C-V. So, what you describe above is not 
the clipboard, but basically the selection (modulo the 'redundant "copy"').

> Unfortunately, some other systems wants to do this the harder way. In
> that case, the behavior is a mild bug. The users do not expect the
> clipboard to be involved - unless they involve it explicitly. Please
> don't add code to "save" the system clipboard state to fix this.

Well, saving and resetting the clipboard would be one possible way to fix 
this bug. I agree that the selection should continue to work as it does, and 
it should indeed contain the note contents after inserting the note, but the 
clipboard should definitely not be altered by this operation.


Georg

Re: creating lyx note causes clipboard copy

[Helge Hafting]

On 28. des. 2010 23:22, Pavel Sanda wrote:

Jack Tanner wrote:

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside
a new note.
5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)


iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.


As a linux user, when I mark something, I expect it to be in the 
clipboard already - because I marked it. (In linux, you don't need to 
copy. This saves keypresses.) With this model, LyX is correct:

* select word2, putting it on the clipboard
* redundant copy
* select word1, putting it on the clipboard replacing word2
* Insert Note
* Paste, and get word1 which is still on the clipboard as it is still
  selected.

Unfortunately, some other systems wants to do this the harder way. In 
that case, the behavior is a mild bug. The users do not expect the 
clipboard to be involved - unless they involve it explicitly. Please 
don't add code to save the system clipboard state to fix this. 
Consider instead some sort of LyX-internal clipboard that the code can 
use when inserting a box (or just about anything else) around a piece of 
text. The user should never see this internal clipboard, it'd be for 
internal transformations only.


Helge Hafting

Re: creating lyx note causes clipboard copy

[Vincent van Ravesteijn]

 As a linux user, when I mark something, I expect it to be in the clipboard
 already - because I marked it. (In linux, you don't need to copy. This
 saves keypresses.) With this model, LyX is correct:
 * select word2, putting it on the clipboard
 * redundant copy
 * select word1, putting it on the clipboard replacing word2
 * Insert Note
 * Paste, and get word1 which is still on the clipboard as it is still
  selected.

 Unfortunately, some other systems wants to do this the harder way. In that
 case, the behavior is a mild bug. The users do not expect the clipboard to
 be involved - unless they involve it explicitly. Please don't add code to
 save the system clipboard state to fix this. Consider instead some sort of
 LyX-internal clipboard that the code can use when inserting a box (or just
 about anything else) around a piece of text. The user should never see this
 internal clipboard, it'd be for internal transformations only.


Please add this to bug #6570 (http://www.lyx.org/trac/ticket/6570) so
someone will remember when he/she tries to fix this.

Vincent

Re: creating lyx note causes clipboard copy

[Helge Hafting]

On 28. des. 2010 23:22, Pavel Sanda wrote:

Jack Tanner wrote:

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside
a new note.
5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)


iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.


As a linux user, when I mark something, I expect it to be in the 
clipboard already - because I marked it. (In linux, you don't need to 
"copy". This saves keypresses.) With this model, LyX is correct:

* select word2, putting it on the clipboard
* redundant "copy"
* select word1, putting it on the clipboard replacing word2
* Insert Note
* Paste, and get word1 which is still on the clipboard as it is still
  selected.

Unfortunately, some other systems wants to do this the harder way. In 
that case, the behavior is a mild bug. The users do not expect the 
clipboard to be involved - unless they involve it explicitly. Please 
don't add code to "save" the system clipboard state to fix this. 
Consider instead some sort of "LyX-internal" clipboard that the code can 
use when inserting a box (or just about anything else) around a piece of 
text. The user should never see this internal clipboard, it'd be for 
internal transformations only.


Helge Hafting

Re: creating lyx note causes clipboard copy

[Vincent van Ravesteijn]

> As a linux user, when I mark something, I expect it to be in the clipboard
> already - because I marked it. (In linux, you don't need to "copy". This
> saves keypresses.) With this model, LyX is correct:
> * select word2, putting it on the clipboard
> * redundant "copy"
> * select word1, putting it on the clipboard replacing word2
> * Insert Note
> * Paste, and get word1 which is still on the clipboard as it is still
>  selected.
>
> Unfortunately, some other systems wants to do this the harder way. In that
> case, the behavior is a mild bug. The users do not expect the clipboard to
> be involved - unless they involve it explicitly. Please don't add code to
> "save" the system clipboard state to fix this. Consider instead some sort of
> "LyX-internal" clipboard that the code can use when inserting a box (or just
> about anything else) around a piece of text. The user should never see this
> internal clipboard, it'd be for internal transformations only.
>

Please add this to bug #6570 (http://www.lyx.org/trac/ticket/6570) so
someone will remember when he/she tries to fix this.

Vincent

Re: creating lyx note causes clipboard copy

[Liviu Andronic]

On Wed, Dec 29, 2010 at 4:55 AM, Jack Tanner i...@hotmail.com wrote:
 Perhaps creation of the note inset could save and then restore the clipboard
 state? The bug is even more annoying if the clipboard contents come not from 
 LyX
 but from some other application. Creation of a note inset may cause data loss.

Not if you use a clipboard manager. If on Linux look into
xfce4-clipman, or similar [1].
Liviu

[1] http://alternativeto.net/software/clipman/

Re: creating lyx note causes clipboard copy

[Liviu Andronic]

On Wed, Dec 29, 2010 at 4:55 AM, Jack Tanner <i...@hotmail.com> wrote:
> Perhaps creation of the note inset could save and then restore the clipboard
> state? The bug is even more annoying if the clipboard contents come not from 
> LyX
> but from some other application. Creation of a note inset may cause data loss.
>
Not if you use a clipboard manager. If on Linux look into
xfce4-clipman, or similar [1].
Liviu

[1] http://alternativeto.net/software/clipman/

creating lyx note causes clipboard copy

[Jack Tanner]

In LyX 1.6.8,

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed 
inside a new note.

5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)

Re: creating lyx note causes clipboard copy

[Pavel Sanda]

Jack Tanner wrote:
 1. Create a new document.
 2. Type in two words, word1 and word2.
 3. Select and copy word2.
 4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside 
 a new note.
 5. Paste.

 Expected: paste outputs word2, as copied in (3)

 Actual: paste outputs word1, from (4)

iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.

pavel

Re: creating lyx note causes clipboard copy

[Jack Tanner]

Pavel Sanda sanda at lyx.org writes:

 
 Jack Tanner wrote:
  1. Create a new document.
  2. Type in two words, word1 and word2.
  3. Select and copy word2.
  4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside 
  a new note.
  5. Paste.
 
  Expected: paste outputs word2, as copied in (3)
 
  Actual: paste outputs word1, from (4)
 
 iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.

Perhaps creation of the note inset could save and then restore the clipboard 
state? The bug is even more annoying if the clipboard contents come not from 
LyX 
but from some other application. Creation of a note inset may cause data loss.

creating lyx note causes clipboard copy

[Jack Tanner]

In LyX 1.6.8,

1. Create a new document.
2. Type in two words, word1 and word2.
3. Select and copy word2.
4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed 
inside a new note.

5. Paste.

Expected: paste outputs word2, as copied in (3)

Actual: paste outputs word1, from (4)

Re: creating lyx note causes clipboard copy

[Pavel Sanda]

Jack Tanner wrote:
> 1. Create a new document.
> 2. Type in two words, word1 and word2.
> 3. Select and copy word2.
> 4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside 
> a new note.
> 5. Paste.
>
> Expected: paste outputs word2, as copied in (3)
>
> Actual: paste outputs word1, from (4)

iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.

pavel

Re: creating lyx note causes clipboard copy

[Jack Tanner]

Pavel Sanda  lyx.org> writes:

> 
> Jack Tanner wrote:
> > 1. Create a new document.
> > 2. Type in two words, word1 and word2.
> > 3. Select and copy word2.
> > 4. Highlight word1 and Insert, Note, LyX Note. word1 will be placed inside 
> > a new note.
> > 5. Paste.
> >
> > Expected: paste outputs word2, as copied in (3)
> >
> > Actual: paste outputs word1, from (4)
> 
> iirc this is because inserting word1 into the note inset (4) is actually done 
via clipboard.

Perhaps creation of the note inset could save and then restore the clipboard 
state? The bug is even more annoying if the clipboard contents come not from 
LyX 
but from some other application. Creation of a note inset may cause data loss.

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Sun, May 9, 2010 at 7:13 AM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 8-5-2010 13:01, John McCabe-Dansted schreef:

 If a patch isn't commented on in a couple of weeks, shall I resend?
 For now, I will do so.


 Yes, that's good. Just remind us. There are so many issues, questions, bugs,
 new features and other problems that ask for attention that we forget some
 things or two.

 But, the patch is still in my tree, and I put it again on the todo-list a
 few days again.

 It would be nice if I could reproduce the problem you're fixing. But, as far
 as I remember, the patch was pretty reasonable anyway.

I have been able to reproduce this on e.g. Ubuntu 9.10 and FC10.

The only reason I can think of that you might not be able reproduce
this is that some applications don't actually pause when you hit
Ctrl-Z. E.g. with gedit, if gedit is already running then running
gedit again will just send a message to the existing gedit process to
open a new tab and so pressing Ctrl-Z on the terminal won't freeze the
main process.

Here is the precise process I use to reproduce bug 6597

0) Notice that LyX normally takes a couple of seconds to start
1) Open a terminal
2) Make sure gedit isn't running
3) Type gedit
4) In Gedit type asdf
5) Copy the asdf text you just typed
6) Make sure you *can* paste the asdf text you just typed.
7) Go to the terminal and press Ctrl-Z, stopping gedit.
8) Make sure you *cannot* paste asdf
9) Run lyx (branch will do)
10) Notice that LyX now takes over a minute to start up.
11) Notice that LyX requires over a minute to display the Edit menu.

Does this sequence reproduce the bug for you? If not is it step (8) or
(10/11) that you cannot reproduce?

-- 
John C. McCabe-Dansted

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[Vincent van Ravesteijn]

 Here is the precise process I use to reproduce bug 6597


Ok, I'll have to try this when I am at home again. I can run Ubuntu there.

For now, I want to ask you whether you've read the following:

void QClipboard::dataChanged ()   [signal]

[...]

On Mac OS X and with Qt version 4.3 or higher, clipboard changes made by
other applications will only be detected when the application is activated.

[...]

from: http://doc.qt.nokia.com/4.6/qclipboard.html#dataChanged

Does this break copy-pasting from external applications on Mac with your
patch ?

Vincent

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Tue, May 11, 2010 at 7:45 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 On Mac OS X and with Qt version 4.3 or higher, clipboard changes made by
 other applications will only be detected when the application is activated.

 [...]

 from: http://doc.qt.nokia.com/4.6/qclipboard.html#dataChanged

 Does this break copy-pasting from external applications on Mac with your
 patch ?

I presume not because LyX already relies on the messages being
delivered for correctness. Presumably LyX is activated before it is
pasted into, and the message is delivered then.

I don't have an OS X machine to test this on though.

-- 
John C. McCabe-Dansted

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Sun, May 9, 2010 at 7:13 AM, Vincent van Ravesteijn  wrote:
> Op 8-5-2010 13:01, John McCabe-Dansted schreef:
>>
>> If a patch isn't commented on in a couple of weeks, shall I resend?
>> For now, I will do so.
>>
>
> Yes, that's good. Just remind us. There are so many issues, questions, bugs,
> new features and other problems that ask for attention that we forget some
> things or two.
>
> But, the patch is still in my tree, and I put it again on the todo-list a
> few days again.
>
> It would be nice if I could reproduce the problem you're fixing. But, as far
> as I remember, the patch was pretty reasonable anyway.

I have been able to reproduce this on e.g. Ubuntu 9.10 and FC10.

The only reason I can think of that you might not be able reproduce
this is that some applications don't actually pause when you hit
Ctrl-Z. E.g. with gedit, if gedit is already running then running
gedit again will just send a message to the existing gedit process to
open a new tab and so pressing Ctrl-Z on the terminal won't freeze the
main process.

Here is the precise process I use to reproduce bug 6597

0) Notice that LyX normally takes a couple of seconds to start
1) Open a terminal
2) Make sure gedit isn't running
3) Type "gedit"
4) In Gedit type "asdf"
5) Copy the "asdf" text you just typed
6) Make sure you *can* paste the asdf text you just typed.
7) Go to the terminal and press Ctrl-Z, stopping gedit.
8) Make sure you *cannot* paste asdf
9) Run lyx (branch will do)
10) Notice that LyX now takes over a minute to start up.
11) Notice that LyX requires over a minute to display the "Edit" menu.

Does this sequence reproduce the bug for you? If not is it step (8) or
(10/11) that you cannot reproduce?

-- 
John C. McCabe-Dansted

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[Vincent van Ravesteijn]

>
> Here is the precise process I use to reproduce bug 6597
>

Ok, I'll have to try this when I am at home again. I can run Ubuntu there.

For now, I want to ask you whether you've read the following:

void QClipboard::dataChanged ()   [signal]

[...]

On Mac OS X and with Qt version 4.3 or higher, clipboard changes made by
other applications will only be detected when the application is activated.

[...]

from: http://doc.qt.nokia.com/4.6/qclipboard.html#dataChanged

Does this break copy-pasting from external applications on Mac with your
patch ?

Vincent

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Tue, May 11, 2010 at 7:45 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:
> On Mac OS X and with Qt version 4.3 or higher, clipboard changes made by
> other applications will only be detected when the application is activated.
>
> [...]
>
> from: http://doc.qt.nokia.com/4.6/qclipboard.html#dataChanged
>
> Does this break copy-pasting from external applications on Mac with your
> patch ?

I presume not because LyX already relies on the messages being
delivered for correctness. Presumably LyX is activated before it is
pasted into, and the message is delivered then.

I don't have an OS X machine to test this on though.

-- 
John C. McCabe-Dansted

[Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

If a patch isn't commented on in a couple of weeks, shall I resend?
For now, I will do so.

On Mon, Mar 29, 2010 at 4:50 AM, Vincent van Ravesteijn
v.f.vanraveste...@tudelft.nl wrote:
 +QMimeData const * read_clipboard() {
 +    LYXERR(Debug::ACTION, Getting Clipboard\n);
 +    QMimeData const * source =
 +        qApp-clipboard()-mimeData(QClipboard::Clipboard);
 +    if (!source) {
 +        LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
 +        return new QMimeData();
 +    }

 Why do you want to return a new object ? Why not just 0 ?

In one of the cases in the original code we replaced NULL with
QMimeData(). In other places the original code simply did not check
for NULL at all. It seems that it would be safest to do this all the
time, and also that replacing NULL with QMimeData in one place is
cleaner than putting if (source == 0) statements all through the
code.

Actually we never expect to source to be NULL here, because by having
a look at the Qt source, mimeData(X) only returns NULL the clipboard
type X is not supported, and all current Qt targets (mac,win,x11,qws)
support ::Clipboard.
   // maybe we should LASSERT(source, /**/)?

 @@ -76,14 +141,13 @@
     LYXERR(Debug::ACTION, GuiClipboard::getAsLyX(): `);
     // We don't convert encodings here since the encoding of the
     // clipboard contents is specified in the data itself
 -    QMimeData const * source =
 -        qApp-clipboard()-mimeData(QClipboard::Clipboard);
 +    QMimeData const * source = read_clipboard();
     if (!source) {
         LYXERR(Debug::ACTION, ' (no QMimeData));
         return string();
     }

 Source can't be zero now ? Right ?

I guess not. Should I remove this check or the one above?

  -    if (source-hasFormat(lyxMimeType())) {
 +    if (cache_.hasFormat(lyxMimeType())) {

 Why can't we use source here ?   It gets a bit confusing if we use both
 source as cache in one function.

Using cache_ is because it is faster. In the revised patch (attached) cache_
forwards data() requests onto the real clipboard we only need to use
cache_.

    +    //Note: we do not really need to run cache_.update() unless the
 +    //data has been changed *and* the GuiClipboard has been queried.
 +    //However if run cache_.update() the moment a process grabs the
 +    //clipboard, the process presumably won't yet be frozen, and so
 +    //we will not need to wait 5 seconds for Qt to time-out waiting
 +    //for the clipboard and won't cache the invalid empty QMimeData.

 I don't understand this command. Especially not if I look at this in the
 future. It is then not clear which process can be frozen. What is the moment
 a process grabs the clipboard ?

Roughly when X server changes it record of which process holds the
clipboard I guess.

I could just remove this comment.

 And do we want to cache the invalid' QMimeData or don't we want that ?

I was thinking not, as the process could become unfrozen, but all the
LyX GUI paste commands would remain greyed out.

It probably isn't that serious as the User would probably just re-copy
the text from  the original application as that would be the obvious
reaction to having the clipboard contents appear to go missing, and
this problem only occurs when the other process (the one holding the
clipboard) is misbehaving anyway.


  private:
 +    FileName getPastedGraphicsFileName(QMimeData const * const cache,
 +        Cursor const  cur, Clipboard::GraphicsType  type) const;
 +    bool hasLyXContents(QMimeData const * const source) const;
 +    bool hasGraphicsContents(QMimeData const * const source,
 +                 GraphicsType type = AnyGraphicsType) const;
 +    bool hasTextContents(QMimeData const * const source) const;
 +

 What's this ?

 Trailing garbage from an earlier attempt. I have removed this from
the revised patch.

I note that we have three bools in clipboard.h.
       bool text_clipboard_empty_;
       bool has_lyx_contents_;
       bool has_graphics_contents_;
These bools are only used in  GuiClipboard::empty() Perhaps we should
1) merge these into a single bool clipboard_empty_; or
2) replace the second two with ::HasLyxContents() and ::HasGraphicsContents()

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33845)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include support/filetools.h
 #include support/gettext.h
 #include support/lstrings.h
+#include support/lyxtime.h
 
 #ifdef Q_WS_MACX
 #include support/linkback/LinkBackProxy.h
@@ -55,7 +56,65 @@
 
 namespace frontend {
 
+QMimeData const * read_clipboard() {
+	LYXERR(Debug::ACTION, Getting Clipboard\n);
+	QMimeData const * source =
+		qApp-clipboard()-mimeData(QClipboard::Clipboard);
+	if (!source) {
+		LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
+		return new QMimeData();
+	}
+	//It appears that doing IO between getting a mimeData object
+	//and using it can

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[Vincent van Ravesteijn]

Op 8-5-2010 13:01, John McCabe-Dansted schreef:

If a patch isn't commented on in a couple of weeks, shall I resend?
For now, I will do so.
   


Yes, that's good. Just remind us. There are so many issues, questions, 
bugs, new features and other problems that ask for attention that we 
forget some things or two.


But, the patch is still in my tree, and I put it again on the todo-list 
a few days again.


It would be nice if I could reproduce the problem you're fixing. But, as 
far as I remember, the patch was pretty reasonable anyway.


I'll try to have a look tomorrow (today).

Vincent

[Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

If a patch isn't commented on in a couple of weeks, shall I resend?
For now, I will do so.

On Mon, Mar 29, 2010 at 4:50 AM, Vincent van Ravesteijn
<v.f.vanraveste...@tudelft.nl> wrote:
>> +QMimeData const * read_clipboard() {
>> +    LYXERR(Debug::ACTION, "Getting Clipboard\n");
>> +    QMimeData const * source =
>> +        qApp->clipboard()->mimeData(QClipboard::Clipboard);
>> +    if (!source) {
>> +        LYXERR(Debug::ACTION, "0 bytes (no QMimeData)");
>> +        return new QMimeData();
>> +    }
>
> Why do you want to return a new object ? Why not just 0 ?

In one of the cases in the original code we replaced NULL with
QMimeData(). In other places the original code simply did not check
for NULL at all. It seems that it would be safest to do this all the
time, and also that replacing NULL with QMimeData in one place is
cleaner than putting "if (source == 0)" statements all through the
code.

Actually we never expect to source to be NULL here, because by having
a look at the Qt source, mimeData(X) only returns NULL the clipboard
type X is not supported, and all current Qt targets (mac,win,x11,qws)
support ::Clipboard.
   // maybe we should LASSERT(source, /**/)?

>> @@ -76,14 +141,13 @@
>>     LYXERR(Debug::ACTION, "GuiClipboard::getAsLyX(): `");
>>     // We don't convert encodings here since the encoding of the
>>     // clipboard contents is specified in the data itself
>> -    QMimeData const * source =
>> -        qApp->clipboard()->mimeData(QClipboard::Clipboard);
>> +    QMimeData const * source = read_clipboard();
>>     if (!source) {
>>         LYXERR(Debug::ACTION, "' (no QMimeData)");
>>         return string();
>>     }
>
> Source can't be zero now ? Right ?

I guess not. Should I remove this check or the one above?

>>  -    if (source->hasFormat(lyxMimeType())) {
>> +    if (cache_.hasFormat(lyxMimeType())) {
>
> Why can't we use source here ?   It gets a bit confusing if we use both
> source as cache in one function.

Using cache_ is because it is faster. In the revised patch (attached) cache_
forwards data() requests onto the real clipboard we only need to use
cache_.

>>    +    //Note: we do not really need to run cache_.update() unless the
>> +    //data has been changed *and* the GuiClipboard has been queried.
>> +    //However if run cache_.update() the moment a process grabs the
>> +    //clipboard, the process presumably won't yet be frozen, and so
>> +    //we will not need to wait 5 seconds for Qt to time-out waiting
>> +    //for the clipboard and won't cache the invalid empty QMimeData.
>
> I don't understand this command. Especially not if I look at this in the
> future. It is then not clear which process can be frozen. What is the moment
> a process grabs the clipboard ?

Roughly when X server changes it record of which process holds the
clipboard I guess.

I could just remove this comment.

> And do we want to cache the invalid' QMimeData or don't we want that ?

I was thinking not, as the process could become unfrozen, but all the
LyX GUI paste commands would remain greyed out.

It probably isn't that serious as the User would probably just re-copy
the text from  the original application as that would be the obvious
reaction to having the clipboard contents appear to go missing, and
this problem only occurs when the other process (the one holding the
clipboard) is misbehaving anyway.

>>
>>  private:
>> +    FileName getPastedGraphicsFileName(QMimeData const * const cache,
>> +        Cursor const & cur, Clipboard::GraphicsType & type) const;
>> +    bool hasLyXContents(QMimeData const * const source) const;
>> +    bool hasGraphicsContents(QMimeData const * const source,
>> +                 GraphicsType type = AnyGraphicsType) const;
>> +    bool hasTextContents(QMimeData const * const source) const;
>> +
>
> What's this ?

 Trailing garbage from an earlier attempt. I have removed this from
the revised patch.

I note that we have three bools in clipboard.h.
       bool text_clipboard_empty_;
       bool has_lyx_contents_;
       bool has_graphics_contents_;
These bools are only used in  GuiClipboard::empty() Perhaps we should
1) merge these into a single bool "clipboard_empty_"; or
2) replace the second two with ::HasLyxContents() and ::HasGraphicsContents()

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33845)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include "support/filetools.h"
 #include "support/gettext.h"
 #include "support/

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[Vincent van Ravesteijn]

Op 8-5-2010 13:01, John McCabe-Dansted schreef:

If a patch isn't commented on in a couple of weeks, shall I resend?
For now, I will do so.
   


Yes, that's good. Just remind us. There are so many issues, questions, 
bugs, new features and other problems that ask for attention that we 
forget some things or two.


But, the patch is still in my tree, and I put it again on the todo-list 
a few days again.


It would be nice if I could reproduce the problem you're fixing. But, as 
far as I remember, the patch was pretty reasonable anyway.


I'll try to have a look tomorrow (today).

Vincent

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Mon, Mar 29, 2010 at 4:50 AM, Vincent van Ravesteijn
v.f.vanraveste...@tudelft.nl wrote:
 +QMimeData const * read_clipboard() {
 +    LYXERR(Debug::ACTION, Getting Clipboard\n);
 +    QMimeData const * source =
 +        qApp-clipboard()-mimeData(QClipboard::Clipboard);
 +    if (!source) {
 +        LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
 +        return new QMimeData();
 +    }

 Why do you want to return a new object ? Why not just 0 ?

In one of the cases in the original code we replaced NULL with
QMimeData(). In other places the original code simply did not check
for NULL at all. It seems that it would be safest to do this all the
time, and also that replacing NULL with QMimeData in one place is
cleaner than putting if (source == 0) statements all through the
code.

Actually we never expect to source to be NULL here, because by having
a look at the Qt source, mimeData(X) only returns NULL the clipboard
type X is not supported, and all current Qt targets (mac,win,x11,qws)
support ::Clipboard.
// maybe we should LASSERT(source, /**/)?

 @@ -76,14 +141,13 @@
     LYXERR(Debug::ACTION, GuiClipboard::getAsLyX(): `);
     // We don't convert encodings here since the encoding of the
     // clipboard contents is specified in the data itself
 -    QMimeData const * source =
 -        qApp-clipboard()-mimeData(QClipboard::Clipboard);
 +    QMimeData const * source = read_clipboard();
     if (!source) {
         LYXERR(Debug::ACTION, ' (no QMimeData));
         return string();
     }

 Source can't be zero now ? Right ?

I guess not. Should I remove this check or the one above?

  -    if (source-hasFormat(lyxMimeType())) {
 +    if (cache_.hasFormat(lyxMimeType())) {

 Why can't we use source here ?   It gets a bit confusing if we use both
 source as cache in one function.

Using cache_ is because it is faster. In the revised patch cache_
forwards data() requests onto the real clipboard we only need to use
cache_.

    +    //Note: we do not really need to run cache_.update() unless the
 +    //data has been changed *and* the GuiClipboard has been queried.
 +    //However if run cache_.update() the moment a process grabs the
 +    //clipboard, the process presumably won't yet be frozen, and so
 +    //we will not need to wait 5 seconds for Qt to time-out waiting
 +    //for the clipboard and won't cache the invalid empty QMimeData.

 I don't understand this command. Especially not if I look at this in the
 future. It is then not clear which process can be frozen. What is the moment
 a process grabs the clipboard ?

Roughly when X server changes it record of which process holds the
clipboard I guess.

I could just remove this comment.

 And do we want to cache the invalid' QMimeData or don't we want that ?

I was thinking not, as the process could become unfrozen, but all the
LyX GUI paste commands would remain greyed out.

It probably isn't that serious as the User would probably just re-copy
the text from  the original application as that would be the obvious
reaction to having the clipboard contents appear to go missing, and
this problem only occurs when the other process (the one holding the
clipboard) is misbehaving anyway.


  private:
 +    FileName getPastedGraphicsFileName(QMimeData const * const cache,
 +        Cursor const  cur, Clipboard::GraphicsType  type) const;
 +    bool hasLyXContents(QMimeData const * const source) const;
 +    bool hasGraphicsContents(QMimeData const * const source,
 +                 GraphicsType type = AnyGraphicsType) const;
 +    bool hasTextContents(QMimeData const * const source) const;
 +

 What's this ?

 Trailing garbage from an earlier attempt. I have removed this from
the revised patch.

I note that we have three bools in clipboard.h.
bool text_clipboard_empty_;
bool has_lyx_contents_;
bool has_graphics_contents_;
These bools are only used in  GuiClipboard::empty() Perhaps we should
1) merge these into a single bool clipboard_empty_; or
2) replace the second two with ::HasLyxContents() and ::HasGraphicsContents()


-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33845)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include support/filetools.h
 #include support/gettext.h
 #include support/lstrings.h
+#include support/lyxtime.h
 
 #ifdef Q_WS_MACX
 #include support/linkback/LinkBackProxy.h
@@ -55,7 +56,65 @@
 
 namespace frontend {
 
+QMimeData const * read_clipboard() {
+	LYXERR(Debug::ACTION, Getting Clipboard\n);
+	QMimeData const * source =
+		qApp-clipboard()-mimeData(QClipboard::Clipboard);
+	if (!source) {
+		LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
+		return new QMimeData();
+	}
+	//It appears that doing IO between getting a mimeData object
+	//and using it can cause a crash (maybe Qt used IO
+	//as an excuse to free() it? Any lets not introduce
+	//any new IO

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Mon, Mar 29, 2010 at 4:50 AM, Vincent van Ravesteijn
<v.f.vanraveste...@tudelft.nl> wrote:
>> +QMimeData const * read_clipboard() {
>> +    LYXERR(Debug::ACTION, "Getting Clipboard\n");
>> +    QMimeData const * source =
>> +        qApp->clipboard()->mimeData(QClipboard::Clipboard);
>> +    if (!source) {
>> +        LYXERR(Debug::ACTION, "0 bytes (no QMimeData)");
>> +        return new QMimeData();
>> +    }
>
> Why do you want to return a new object ? Why not just 0 ?

In one of the cases in the original code we replaced NULL with
QMimeData(). In other places the original code simply did not check
for NULL at all. It seems that it would be safest to do this all the
time, and also that replacing NULL with QMimeData in one place is
cleaner than putting "if (source == 0)" statements all through the
code.

Actually we never expect to source to be NULL here, because by having
a look at the Qt source, mimeData(X) only returns NULL the clipboard
type X is not supported, and all current Qt targets (mac,win,x11,qws)
support ::Clipboard.
// maybe we should LASSERT(source, /**/)?

>> @@ -76,14 +141,13 @@
>>     LYXERR(Debug::ACTION, "GuiClipboard::getAsLyX(): `");
>>     // We don't convert encodings here since the encoding of the
>>     // clipboard contents is specified in the data itself
>> -    QMimeData const * source =
>> -        qApp->clipboard()->mimeData(QClipboard::Clipboard);
>> +    QMimeData const * source = read_clipboard();
>>     if (!source) {
>>         LYXERR(Debug::ACTION, "' (no QMimeData)");
>>         return string();
>>     }
>
> Source can't be zero now ? Right ?

I guess not. Should I remove this check or the one above?

>>  -    if (source->hasFormat(lyxMimeType())) {
>> +    if (cache_.hasFormat(lyxMimeType())) {
>
> Why can't we use source here ?   It gets a bit confusing if we use both
> source as cache in one function.

Using cache_ is because it is faster. In the revised patch cache_
forwards data() requests onto the real clipboard we only need to use
cache_.

>>    +    //Note: we do not really need to run cache_.update() unless the
>> +    //data has been changed *and* the GuiClipboard has been queried.
>> +    //However if run cache_.update() the moment a process grabs the
>> +    //clipboard, the process presumably won't yet be frozen, and so
>> +    //we will not need to wait 5 seconds for Qt to time-out waiting
>> +    //for the clipboard and won't cache the invalid empty QMimeData.
>
> I don't understand this command. Especially not if I look at this in the
> future. It is then not clear which process can be frozen. What is the moment
> a process grabs the clipboard ?

Roughly when X server changes it record of which process holds the
clipboard I guess.

I could just remove this comment.

> And do we want to cache the invalid' QMimeData or don't we want that ?

I was thinking not, as the process could become unfrozen, but all the
LyX GUI paste commands would remain greyed out.

It probably isn't that serious as the User would probably just re-copy
the text from  the original application as that would be the obvious
reaction to having the clipboard contents appear to go missing, and
this problem only occurs when the other process (the one holding the
clipboard) is misbehaving anyway.

>>
>>  private:
>> +    FileName getPastedGraphicsFileName(QMimeData const * const cache,
>> +        Cursor const & cur, Clipboard::GraphicsType & type) const;
>> +    bool hasLyXContents(QMimeData const * const source) const;
>> +    bool hasGraphicsContents(QMimeData const * const source,
>> +                 GraphicsType type = AnyGraphicsType) const;
>> +    bool hasTextContents(QMimeData const * const source) const;
>> +
>
> What's this ?

 Trailing garbage from an earlier attempt. I have removed this from
the revised patch.

I note that we have three bools in clipboard.h.
bool text_clipboard_empty_;
bool has_lyx_contents_;
bool has_graphics_contents_;
These bools are only used in  GuiClipboard::empty() Perhaps we should
1) merge these into a single bool "clipboard_empty_"; or
2) replace the second two with ::HasLyxContents() and ::HasGraphicsContents()


-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33845)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include "support/filetools.h"
 #include "support/gettext.h"
 #include "support/lstrings.h"
+#include "support/lyxtime.h"
 
 #ifdef Q_WS_MACX
 #include "support/link

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Mon, Mar 22, 2010 at 1:50 AM, John McCabe-Dansted gma...@gmail.com wrote:
 Hi, the attached fixed fixes #6597. Does it look alright?
-- http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg158837.html

Has anyone have time to look at this patch, which introduces a
CacheMimeData type so we don't need to query the clipboard dozens of
times on startup and on display of the edit menu. With this patch we
only poll the clipboard once on startup and once when we get an
clipboard changed event.

Amusing anecdote: this bug seemed fairly serious when I was giving a
informal presentation on how wonderful LyX was and LyX just wouldn't
start no matter how many times I killed and restarted it. I ended up
borrowing a laptop another presenter who happened to have LyX
installed, but it still wasn't the look I was going for.

Also this patch seems like it could be a worthwhile optimization even
when the clipboard is responding normally. I benchmarked the following
operation on my Core2Duo:

QMimeData-HasImage()
(5 seconds if process holding clipboard is frozen)
1.4ms when QtCreator/gedit/LyX holds clipboard
0.1ms when gimp holds clipboard

CacheMimeData-HasImage()
5us (microseconds)

Obviously, the time taken by CacheMimeData is negligible. However a
dozens of unnecessary queries to QMimeData, each of which usually take
over 1ms, every time the Edit menu is displayed is getting to the
point where the user may actually notice the delay (~20ms?), at least
on a subconscious level. This is roughly the same amount of time it
takes me to run svnversion on src/lyx.

-- 
John C. McCabe-Dansted

Re: [Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

On Mon, Mar 22, 2010 at 1:50 AM, John McCabe-Dansted <gma...@gmail.com> wrote:
> Hi, the attached fixed fixes #6597. Does it look alright?
-- http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg158837.html

Has anyone have time to look at this patch, which introduces a
CacheMimeData type so we don't need to query the clipboard dozens of
times on startup and on display of the edit menu. With this patch we
only poll the clipboard once on startup and once when we get an
clipboard changed event.

Amusing anecdote: this bug seemed fairly serious when I was giving a
informal presentation on how wonderful LyX was and LyX just wouldn't
start no matter how many times I killed and restarted it. I ended up
borrowing a laptop another presenter who happened to have LyX
installed, but it still wasn't the look I was going for.

Also this patch seems like it could be a worthwhile optimization even
when the clipboard is responding normally. I benchmarked the following
operation on my Core2Duo:

QMimeData->HasImage()
(5 seconds if process holding clipboard is frozen)
1.4ms when QtCreator/gedit/LyX holds clipboard
0.1ms when gimp holds clipboard

CacheMimeData->HasImage()
5us (microseconds)

Obviously, the time taken by CacheMimeData is negligible. However a
dozens of unnecessary queries to QMimeData, each of which usually take
over 1ms, every time the Edit menu is displayed is getting to the
point where the user may actually notice the delay (~20ms?), at least
on a subconscious level. This is roughly the same amount of time it
takes me to run svnversion on src/lyx.

-- 
John C. McCabe-Dansted

[Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

Hi, the attached fixed fixes #6597. Does it look alright?

--

Suggested log message:
   Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen
   Implements CacheMimeData type so that we only need to query the
clipboard once on startup and once each time the contents of the
clipboard change.
   This is important as Qt takes 5 seconds to time-out when the
clipboard is non-responsive.

--

I have considered a number of other alternatives, for example, instead
of implementing a CacheMimeData data type, we could just store the
formats as a QStringList and hardcode the various mimetype in
GuiClipboard.cpp, but all of these seemed to have serious drawbacks
(e.g. hardcoding is bad, and in this case more work than a proper
solution.)


-- 
John C. McCabe-Dansted
http://www.lyx.org/trac/ticket/6597
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33816)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include support/filetools.h
 #include support/gettext.h
 #include support/lstrings.h
+#include support/lyxtime.h
 
 #ifdef Q_WS_MACX
 #include support/linkback/LinkBackProxy.h
@@ -55,7 +56,71 @@
 
 namespace frontend {
 
+QMimeData const * read_clipboard() {
+	LYXERR(Debug::ACTION, Getting Clipboard\n);
+	QMimeData const * source =
+		qApp-clipboard()-mimeData(QClipboard::Clipboard);
+	if (!source) {
+		LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
+		return new QMimeData();
+	}
+	//It appears that doing IO between getting a mimeData object
+	//and using it can cause a crash (maybe Qt used IO
+	//as an excuse to free() it? Any lets not introduce
+	//any new IO here, so e.g. leave the following line commented.
+	//lyxerr  Got Clipboard (  (long) source  )\n ;
+	return source;
+}
 
+
+CacheMimeData::CacheMimeData()
+{
+	cached_formats_ = QStringList();
+	//LyX calls on_dataChanged on startup, so it is not necessary to
+	//query the clipboard here.
+	//update();
+}
+
+
+void CacheMimeData::update()
+{
+	time_t start_time = current_time();
+	LYXERR(Debug::ACTION, Creating CacheMimeData object\n);
+	QMimeData const * const orig = read_clipboard();
+	cached_formats_ = orig-formats();
+
+	//Qt times out after 5 seconds if it does not recieve a response.
+	if (current_time()  (start_time + 3) ) {
+		string msg = No timely response from clipboard, perhaps process holding clipboard is frozen?\n;
+		lyxerr  msg;
+		//We could perhaps emit a status message, but we are unlikely
+		//to get this unless starting up, and then there is no
+		//status bar to display it onto (resulting in a SIGSEGV).
+		//lyx::frontend::theGuiApp()-currentView()-message(_(msg));
+	}
+}
+
+
+// We can't really cache this so we will just use the original
+// QMimeData to retrieve the actual data... but thats protected
+// so we only use CacheMimeData fore MimeTypes, not
+// actual data.
+QVariant CacheMimeData::retrieveData(const QString format,
+		  QVariant::Type preferredType) const {
+	(void)format; (void)preferredType;
+	lyxerr  Attempt to retrieveData from a CacheMimeData object\n 
+		(should retrieve the data from the original QMimeData object instead)\n;
+	LASSERT(false, /**/);
+	return 0;
+}
+
+
+QStringList CacheMimeData::formats() const
+{
+	return this-cached_formats_;
+}
+
+
 QString const lyxMimeType(){ return application/x-lyx; }
 QString const pdfMimeType(){ return application/pdf; }
 QString const emfMimeType(){ return image/x-emf; }
@@ -76,14 +141,13 @@
 	LYXERR(Debug::ACTION, GuiClipboard::getAsLyX(): `);
 	// We don't convert encodings here since the encoding of the
 	// clipboard contents is specified in the data itself
-	QMimeData const * source =
-		qApp-clipboard()-mimeData(QClipboard::Clipboard);
+	QMimeData const * source = read_clipboard();
 	if (!source) {
 		LYXERR(Debug::ACTION, ' (no QMimeData));
 		return string();
 	}
 
-	if (source-hasFormat(lyxMimeType())) {
+	if (cache_.hasFormat(lyxMimeType())) {
 		// data from ourself or some other LyX instance
 		QByteArray const ar = source-data(lyxMimeType());
 		string const s(ar.data(), ar.count());
@@ -248,8 +312,7 @@
 	}
 	
 	// get mime data
-	QMimeData const * source =
-	qApp-clipboard()-mimeData(QClipboard::Clipboard);
+	QMimeData const * source = read_clipboard();
 	if (!source) {
 		LYXERR(Debug::ACTION, 0 bytes (no QMimeData));
 		return FileName();
@@ -266,7 +329,7 @@
 	}
 	
 	// get data
-	if (!source-hasFormat(mime))
+	if (!cache_.hasFormat(mime))
 		return FileName();
 	// data from ourself or some other LyX instance
 	QByteArray const ar = source-data(mime);
@@ -336,17 +399,13 @@
 
 bool GuiClipboard::hasLyXContents() const
 {
-	QMimeData const * const source =
-		qApp-clipboard()-mimeData(QClipboard::Clipboard);
-	return source  source-hasFormat(lyxMimeType());
+	return cache_.hasFormat(lyxMimeType());
 }
 
 
 bool GuiClipboard::hasTextContents() const
 {
-	QMimeData const * const source =
-		qApp-clipboard

[Patch] Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen.

[John McCabe-Dansted]

Hi, the attached fixed fixes #6597. Does it look alright?

--

Suggested log message:
   Fix #6597: LyX Appears frozen if the process holding the clipboard is frozen
   Implements CacheMimeData type so that we only need to query the
clipboard once on startup and once each time the contents of the
clipboard change.
   This is important as Qt takes 5 seconds to time-out when the
clipboard is non-responsive.

--

I have considered a number of other alternatives, for example, instead
of implementing a CacheMimeData data type, we could just store the
formats as a QStringList and hardcode the various mimetype in
GuiClipboard.cpp, but all of these seemed to have serious drawbacks
(e.g. hardcoding is bad, and in this case more work than a "proper"
solution.)


-- 
John C. McCabe-Dansted
http://www.lyx.org/trac/ticket/6597
Index: frontends/qt4/GuiClipboard.cpp
===
--- frontends/qt4/GuiClipboard.cpp	(revision 33816)
+++ frontends/qt4/GuiClipboard.cpp	(working copy)
@@ -27,6 +27,7 @@
 #include "support/filetools.h"
 #include "support/gettext.h"
 #include "support/lstrings.h"
+#include "support/lyxtime.h"
 
 #ifdef Q_WS_MACX
 #include "support/linkback/LinkBackProxy.h"
@@ -55,7 +56,71 @@
 
 namespace frontend {
 
+QMimeData const * read_clipboard() {
+	LYXERR(Debug::ACTION, "Getting Clipboard\n");
+	QMimeData const * source =
+		qApp->clipboard()->mimeData(QClipboard::Clipboard);
+	if (!source) {
+		LYXERR(Debug::ACTION, "0 bytes (no QMimeData)");
+		return new QMimeData();
+	}
+	//It appears that doing IO between getting a mimeData object
+	//and using it can cause a crash (maybe Qt used IO
+	//as an excuse to free() it? Any lets not introduce
+	//any new IO here, so e.g. leave the following line commented.
+	//lyxerr << "Got Clipboard (" << (long) source << ")\n" ;
+	return source;
+}
 
+
+CacheMimeData::CacheMimeData()
+{
+	cached_formats_ = QStringList();
+	//LyX calls "on_dataChanged" on startup, so it is not necessary to
+	//query the clipboard here.
+	//update();
+}
+
+
+void CacheMimeData::update()
+{
+	time_t start_time = current_time();
+	LYXERR(Debug::ACTION, "Creating CacheMimeData object\n");
+	QMimeData const * const orig = read_clipboard();
+	cached_formats_ = orig->formats();
+
+	//Qt times out after 5 seconds if it does not recieve a response.
+	if (current_time() > (start_time + 3) ) {
+		string msg = "No timely response from clipboard, perhaps process holding clipboard is frozen?\n";
+		lyxerr << msg;
+		//We could perhaps emit a status message, but we are unlikely
+		//to get this unless starting up, and then there is no
+		//status bar to display it onto (resulting in a SIGSEGV).
+		//lyx::frontend::theGuiApp()->currentView()->message(_(msg));
+	}
+}
+
+
+// We can't really cache this so we will just use the original
+// QMimeData to retrieve the actual data... but thats protected
+// so we only use CacheMimeData fore MimeTypes, not
+// actual data.
+QVariant CacheMimeData::retrieveData(const QString ,
+		  QVariant::Type preferredType) const {
+	(void)format; (void)preferredType;
+	lyxerr << "Attempt to retrieveData from a CacheMimeData object\n" <<
+		"(should retrieve the data from the original QMimeData object instead)\n";
+	LASSERT(false, /**/);
+	return 0;
+}
+
+
+QStringList CacheMimeData::formats() const
+{
+	return this->cached_formats_;
+}
+
+
 QString const lyxMimeType(){ return "application/x-lyx"; }
 QString const pdfMimeType(){ return "application/pdf"; }
 QString const emfMimeType(){ return "image/x-emf"; }
@@ -76,14 +141,13 @@
 	LYXERR(Debug::ACTION, "GuiClipboard::getAsLyX(): `");
 	// We don't convert encodings here since the encoding of the
 	// clipboard contents is specified in the data itself
-	QMimeData const * source =
-		qApp->clipboard()->mimeData(QClipboard::Clipboard);
+	QMimeData const * source = read_clipboard();
 	if (!source) {
 		LYXERR(Debug::ACTION, "' (no QMimeData)");
 		return string();
 	}
 
-	if (source->hasFormat(lyxMimeType())) {
+	if (cache_.hasFormat(lyxMimeType())) {
 		// data from ourself or some other LyX instance
 		QByteArray const ar = source->data(lyxMimeType());
 		string const s(ar.data(), ar.count());
@@ -248,8 +312,7 @@
 	}
 	
 	// get mime data
-	QMimeData const * source =
-	qApp->clipboard()->mimeData(QClipboard::Clipboard);
+	QMimeData const * source = read_clipboard();
 	if (!source) {
 		LYXERR(Debug::ACTION, "0 bytes (no QMimeData)");
 		return FileName();
@@ -266,7 +329,7 @@
 	}
 	
 	// get data
-	if (!source->hasFormat(mime))
+	if (!cache_.hasFormat(mime))
 		return FileName();
 	// data from ourself or some other LyX instance
 	QByteArray const ar = source->data(mime);
@@ -33

Re: Possible bug: Insert-Note-(any action) copies selection to clipboard

[Jean-Marc Lasgouttes]

Le 01/03/2010 21:03, Stephan Witt a écrit :

I can confirm this bug for 1.6.5 branch version.


This bug is a feature of the inset insertion code and is probably 
known for ages. It would not be difficult to fix, but annoying because

the Clipboard API is so horrible. The simplest version would be to add
yet another bool (or change the bools to enum) in curSelection and use 
that in doInsertInset (Text3.cpp). Another solution is to pop() somehow
the new selection from the cutstack. This is not as good since the 
oldest clipboard entry may get lost.


JMarc

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

[Jean-Marc Lasgouttes]

Le 01/03/2010 21:03, Stephan Witt a écrit :

I can confirm this bug for 1.6.5 branch version.


This bug is a "feature" of the inset insertion code and is probably 
known for ages. It would not be difficult to fix, but annoying because

the Clipboard API is so horrible. The simplest version would be to add
yet another bool (or change the bools to enum) in curSelection and use 
that in doInsertInset (Text3.cpp). Another solution is to pop() somehow
the new selection from the cutstack. This is not as good since the 
oldest clipboard entry may get lost.


JMarc

Possible bug: Insert-Note-(any action) copies selection to clipboard

[Manoj Rajagopalan]

Hi,

   I've created a bug report on trac:

   http://www.lyx.org/trac/ticket/6570

  I'm still learning lyx-iquette and I'm sorry I jumped the gun this time by 
filing a bug report before emailing the lyx-devel list.

Thanks,
Manoj

RE: Possible bug: Insert-Note-(any action) copies selection to clipboard

[Vincent van Ravesteijn - TNW]

 
   I've created a bug report on trac:

   http://www.lyx.org/trac/ticket/6570

 I'm still learning lyx-iquette and I'm sorry I jumped the gun this
time
 by filing a bug report before emailing the lyx-devel list.

It is ok to report a bug on trac without mailing the devel list.
However, when you find a bug that is recently introduced and in trunk
only, it can probably be fixed quickly and you can mail the list to draw
the attention of the responsible developer to it. It's then also easier
for him to fix it as the change is still fresh in memory.

One note, if you report a bug for trunk, please also check whether the
bug is in branch too (or a recently released version). Then you can mark
the lyx version as 1.6.5 in stead of 2.0.0svn.

Vincent

Re: Possible bug: Insert-Note-(any action) copies selection to clipboard

[Manoj Rajagopalan]

On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote:

 One note, if you report a bug for trunk, please also check whether the
 bug is in branch too (or a recently released version). Then you can mark
 the lyx version as 1.6.5 in stead of 2.0.0svn.

 Vincent

I don't use any of the branches - 2.0.0 has many nice features that may not be 
in the branches. I can probably email the users group also inviting someone 
to check for the bug? If someone responds, I can modify the bug report on 
trac to show an earlier version. Unless there is a better way, of course ...

-- Manoj

Re: Possible bug: Insert-Note-(any action) copies selection to clipboard

[Stephan Witt]

Am 01.03.2010 um 20:25 schrieb Manoj Rajagopalan:

 
 
 
 On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote:
 
 One note, if you report a bug for trunk, please also check whether the
 bug is in branch too (or a recently released version). Then you can mark
 the lyx version as 1.6.5 in stead of 2.0.0svn.
 
 Vincent
 
 I don't use any of the branches - 2.0.0 has many nice features that may not 
 be 
 in the branches. I can probably email the users group also inviting someone 
 to check for the bug? If someone responds, I can modify the bug report on 
 trac to show an earlier version. Unless there is a better way, of course ...
 
 -- Manoj

I can confirm this bug for 1.6.5 branch version.

Stephan

Possible bug: Insert->Note->(any action) copies selection to clipboard

[Manoj Rajagopalan]

Hi,

   I've created a bug report on trac:

   http://www.lyx.org/trac/ticket/6570

  I'm still learning lyx-iquette and I'm sorry I jumped the gun this time by 
filing a bug report before emailing the lyx-devel list.

Thanks,
Manoj

RE: Possible bug: Insert->Note->(any action) copies selection to clipboard

[Vincent van Ravesteijn - TNW]

 
>   I've created a bug report on trac:
>
>   http://www.lyx.org/trac/ticket/6570
>
> I'm still learning lyx-iquette and I'm sorry I jumped the gun this
time
> by filing a bug report before emailing the lyx-devel list.

It is ok to report a bug on trac without mailing the devel list.
However, when you find a bug that is recently introduced and in trunk
only, it can probably be fixed quickly and you can mail the list to draw
the attention of the responsible developer to it. It's then also easier
for him to fix it as the change is still fresh in memory.

One note, if you report a bug for trunk, please also check whether the
bug is in branch too (or a recently released version). Then you can mark
the lyx version as 1.6.5 in stead of 2.0.0svn.

Vincent

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

[Manoj Rajagopalan]

On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote:
>
> One note, if you report a bug for trunk, please also check whether the
> bug is in branch too (or a recently released version). Then you can mark
> the lyx version as 1.6.5 in stead of 2.0.0svn.
>
> Vincent

I don't use any of the branches - 2.0.0 has many nice features that may not be 
in the branches. I can probably email the users group also inviting someone 
to check for the bug? If someone responds, I can modify the bug report on 
trac to show an earlier version. Unless there is a better way, of course ...

-- Manoj

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

[Stephan Witt]

Am 01.03.2010 um 20:25 schrieb Manoj Rajagopalan:

> 
> 
> 
> On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote:
>> 
>> One note, if you report a bug for trunk, please also check whether the
>> bug is in branch too (or a recently released version). Then you can mark
>> the lyx version as 1.6.5 in stead of 2.0.0svn.
>> 
>> Vincent
> 
> I don't use any of the branches - 2.0.0 has many nice features that may not 
> be 
> in the branches. I can probably email the users group also inviting someone 
> to check for the bug? If someone responds, I can modify the bug report on 
> trac to show an earlier version. Unless there is a better way, of course ...
> 
> -- Manoj

I can confirm this bug for 1.6.5 branch version.

Stephan

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
  Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
  in order to discriminate between tocString and a new clipboardString (or
  somesuch) method. Of course, all uses of asString should be audited.
 
 Or maybe a flag like AS_COMPACT_INSETS that we could use for TOC.

Yes, a flag would be a good idea.

Enrico, you can commit your patch to branch.

Jürgen

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> > Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
> > in order to discriminate between tocString and a new clipboardString (or
> > somesuch) method. Of course, all uses of asString should be audited.
> 
> Or maybe a flag like AS_COMPACT_INSETS that we could use for TOC.

Yes, a flag would be a good idea.

Enrico, you can commit your patch to branch.

Jürgen

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Enrico Forestieri]

On Sat, Oct 03, 2009 at 11:56:50AM +0200, Jürgen Spitzmüller wrote:
 Is it really correct to assume utf8 in plaintext (after all, other plaintext 
 methods use the runparams' encoding, so we would get a mish-mash of encodings,
 wouldn't we)? I agree that utf8 is te correct encoding for pasting and 
 probably also the TOC, but then, wouldn't we have to separate this tocString 
 method from plaintext?

Unless someone shouts, I am going to apply to trunk the attached patch.
I know it is the right one, as I reintroduced runparams here (when
converting mathed to unicode) in order to take advantage of specific
encodings. However, it turns out that plaintext() is called with an empty
runparams (see tocString(), for example), such that no encoding at all is
specified. This means that when a character is not listed in the
unicodesymbols file, an exception is always thrown.
No mish-mash of encodings can occur, as the encoding is only used for
determining whether the character is encodable, but then it is always
returned as ucs-4.

I'll leave to others the decision about renaming tocString as textString
(which is the most obvious and easy thing to do, IMHO).

-- 
Enrico
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(revision 31556)
+++ src/mathed/InsetMathHull.cpp(working copy)
@@ -30,6 +30,7 @@
 #include BufferParams.h
 #include BufferView.h
 #include CutAndPaste.h
+#include Encoding.h
 #include FuncStatus.h
 #include LaTeXFeatures.h
 #include Cursor.h
@@ -1656,7 +1657,7 @@ bool InsetMathHull::readQuiet(Lexer  le
 }
 
 
-int InsetMathHull::plaintext(odocstream  os, OutputParams const  runparams) 
const
+int InsetMathHull::plaintext(odocstream  os, OutputParams const ) const
 {
if (0  display()) {
Dimension dim;
@@ -1670,7 +1671,8 @@ int InsetMathHull::plaintext(odocstream 
return tpain.textheight();
} else {
odocstringstream oss;
-   WriteStream wi(oss, false, true, WriteStream::wsDefault, 
runparams.encoding);
+   Encoding const * const enc = encodings.fromLyXName(utf8);
+   WriteStream wi(oss, false, true, WriteStream::wsDefault, enc);
// Fix Bug #6139
if (type_ == hullRegexp)
write(wi);

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jürgen Spitzmüller]

Enrico Forestieri wrote:
 I'll leave to others the decision about renaming tocString as textString
 (which is the most obvious and easy thing to do, IMHO).

I still think it should not be renamed, but splitted up to two functions. We 
should not use the same function for pasting and the toc.

Jürgen

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Enrico Forestieri]

On Fri, Oct 09, 2009 at 11:38:10AM +0200, Jürgen Spitzmüller wrote:
 Enrico Forestieri wrote:
  I'll leave to others the decision about renaming tocString as textString
  (which is the most obvious and easy thing to do, IMHO).
 
 I still think it should not be renamed, but splitted up to two functions. We 
 should not use the same function for pasting and the toc.

Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
in order to discriminate between tocString and a new clipboardString (or
somesuch) method. Of course, all uses of asString should be audited.

-- 
Enrico

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jean-Marc Lasgouttes]

Enrico Forestieri for...@lyx.org writes:
 Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
 in order to discriminate between tocString and a new clipboardString (or
 somesuch) method. Of course, all uses of asString should be audited.

Or maybe a flag like AS_COMPACT_INSETS that we could use for TOC.

JMarc

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Enrico Forestieri]

On Sat, Oct 03, 2009 at 11:56:50AM +0200, Jürgen Spitzmüller wrote:
> Is it really correct to assume utf8 in plaintext (after all, other plaintext 
> methods use the runparams' encoding, so we would get a mish-mash of encodings,
> wouldn't we)? I agree that utf8 is te correct encoding for pasting and 
> probably also the TOC, but then, wouldn't we have to separate this tocString 
> method from plaintext?

Unless someone shouts, I am going to apply to trunk the attached patch.
I know it is the right one, as I reintroduced runparams here (when
converting mathed to unicode) in order to take advantage of specific
encodings. However, it turns out that plaintext() is called with an empty
runparams (see tocString(), for example), such that no encoding at all is
specified. This means that when a character is not listed in the
unicodesymbols file, an exception is always thrown.
No mish-mash of encodings can occur, as the encoding is only used for
determining whether the character is encodable, but then it is always
returned as ucs-4.

I'll leave to others the decision about renaming tocString as textString
(which is the most obvious and easy thing to do, IMHO).

-- 
Enrico
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(revision 31556)
+++ src/mathed/InsetMathHull.cpp(working copy)
@@ -30,6 +30,7 @@
 #include "BufferParams.h"
 #include "BufferView.h"
 #include "CutAndPaste.h"
+#include "Encoding.h"
 #include "FuncStatus.h"
 #include "LaTeXFeatures.h"
 #include "Cursor.h"
@@ -1656,7 +1657,7 @@ bool InsetMathHull::readQuiet(Lexer & le
 }
 
 
-int InsetMathHull::plaintext(odocstream & os, OutputParams const & runparams) 
const
+int InsetMathHull::plaintext(odocstream & os, OutputParams const &) const
 {
if (0 && display()) {
Dimension dim;
@@ -1670,7 +1671,8 @@ int InsetMathHull::plaintext(odocstream 
return tpain.textheight();
} else {
odocstringstream oss;
-   WriteStream wi(oss, false, true, WriteStream::wsDefault, 
runparams.encoding);
+   Encoding const * const enc = encodings.fromLyXName("utf8");
+   WriteStream wi(oss, false, true, WriteStream::wsDefault, enc);
// Fix Bug #6139
if (type_ == hullRegexp)
write(wi);

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jürgen Spitzmüller]

Enrico Forestieri wrote:
> I'll leave to others the decision about renaming tocString as textString
> (which is the most obvious and easy thing to do, IMHO).

I still think it should not be renamed, but splitted up to two functions. We 
should not use the same function for pasting and the toc.

Jürgen

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Enrico Forestieri]

On Fri, Oct 09, 2009 at 11:38:10AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I'll leave to others the decision about renaming tocString as textString
> > (which is the most obvious and easy thing to do, IMHO).
> 
> I still think it should not be renamed, but splitted up to two functions. We 
> should not use the same function for pasting and the toc.

Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
in order to discriminate between tocString and a new clipboardString (or
somesuch) method. Of course, all uses of asString should be audited.

-- 
Enrico

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jean-Marc Lasgouttes]

Enrico Forestieri  writes:
> Maybe a new flag AS_STR_TOC should be introduced for Paragraph::asString,
> in order to discriminate between tocString and a new clipboardString (or
> somesuch) method. Of course, all uses of asString should be audited.

Or maybe a flag like AS_COMPACT_INSETS that we could use for TOC.

JMarc

Re: [patch] bug 6250: LyX 1.6.4 crashes when copying Japanese text in math to clipboard

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 Notice that I wrote called. The culprit is Paragraph::asString. Does
 the cut and paste code need to call that (I am not sure where it is
 done), and in this case should we add a new flag to the function?

I would also think that we need a separate copyString (or somesuch) for 
this.

Jürgen