Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:

 LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
 LyXFunc::dispatch: primary-selection-paste [15] is disabled at this  

This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE instead of 
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that because I 
always pasted when the selection in the other program was still available, 
so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch 
should now do exactly the same as current trunk if the external clipboard 
does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a console log if 
this still does not work, but I am pretty sure that it works now.


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16664)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor  
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1814,10 +1814,13 @@ bool InsetTabular::copySelection(LCursor
 	odocstringstream os;
 	OutputParams const runparams;
 	paste_tabular-plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the Edit-Paste recent menu and the system clipboard.
+	cap::copySelection(cur, os.str());
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelection.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16664)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor 
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16664)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor 
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16664)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,39 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::readString(std::string const  s)
+{
+	params().compressed = false;
+
+	// remove dummy empty par
+	paragraphs().clear();
+	LyXLex lex(0, 0);
+	std::istringstream is(s);
+	lex.setStream(is);
+	FileName const name(tempName());
+	switch (readFile(lex, name)) {
+	case failure:
+		return false;
+	case wrongversion: {
+		// We need to call lyx2lyx, so write the input to a file
+		std::ofstream os(name.toFilesystemEncoding().c_str());
+		os  s;
+		os.close();
+		return readFile(name) == success;
+	}
+	case success:
+		break;
+	}
+
+	// After we have read a file, we must ensure that the buffer
+	// language is set and used in the gui.
+	// If you know of a better place to put this, please tell me. (Lgb)
+	updateDocLang(params().language);
+
+	return true;
+}
+
+
 bool Buffer::readFile(FileName const  filename)
 {
 	// Check if the file is compressed.
@@ -578,7 +611,7 @@ bool Buffer::readFile(FileName const  f
 	paragraphs().clear();
 	LyXLex lex(0, 0);
 	lex.setFile(filename);
-	if (!readFile(lex, filename))
+	if (readFile(lex, filename) != success)
 		return false;
 
 	// After we have read a file, we must ensure that the buffer
@@ -602,14 +635,15 @@ void Buffer::fully_loaded(bool const val
 }
 
 
-bool Buffer::readFile(LyXLex  lex, FileName const  filename)
+Buffer::ReadStatus Buffer::readFile(LyXLex  lex, FileName const  filename,
+		bool fromstring)
 {
 	BOOST_ASSERT(!filename.empty());
 
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	lex.next();
@@ -618,7 +652,7 @@ bool Buffer::readFile(LyXLex  lex, File
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return 

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 13, 2007, at 7:37 AM, Georg Baum wrote:


Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:


LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
LyXFunc::dispatch: primary-selection-paste [15] is disabled at this


This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE  
instead of
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that  
because I
always pasted when the selection in the other program was still  
available,

so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch
should now do exactly the same as current trunk if the external  
clipboard

does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a  
console log if

this still does not work, but I am pretty sure that it works now.


That works! Thanks again.

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Mittwoch, 10. Januar 2007 23:46 schrieb Jean-Marc Lasgouttes:

 A question: what happens to relative filenames when copy-pasting a
 graphics or include inset? (the answer is probably: the same thing as
 before :)

Yes (i.e. nothing happens).


Georg

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:

> LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
> LyXFunc::dispatch: primary-selection-paste [15] is disabled at this  

This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE instead of 
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that because I 
always pasted when the selection in the other program was still available, 
so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch 
should now do exactly the same as current trunk if the external clipboard 
does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a console log if 
this still does not work, but I am pretty sure that it works now.


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16664)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor & 
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1814,10 +1814,13 @@ bool InsetTabular::copySelection(LCursor
 	odocstringstream os;
 	OutputParams const runparams;
 	paste_tabular->plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the "Edit->Paste recent" menu and the system clipboard.
+	cap::copySelection(cur, os.str());
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelection.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16664)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor &
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16664)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor &
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16664)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,39 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::readString(std::string const & s)
+{
+	params().compressed = false;
+
+	// remove dummy empty par
+	paragraphs().clear();
+	LyXLex lex(0, 0);
+	std::istringstream is(s);
+	lex.setStream(is);
+	FileName const name(tempName());
+	switch (readFile(lex, name)) {
+	case failure:
+		return false;
+	case wrongversion: {
+		// We need to call lyx2lyx, so write the input to a file
+		std::ofstream os(name.toFilesystemEncoding().c_str());
+		os << s;
+		os.close();
+		return readFile(name) == success;
+	}
+	case success:
+		break;
+	}
+
+	// After we have read a file, we must ensure that the buffer
+	// language is set and used in the gui.
+	// If you know of a better place to put this, please tell me. (Lgb)
+	updateDocLang(params().language);
+
+	return true;
+}
+
+
 bool Buffer::readFile(FileName const & filename)
 {
 	// Check if the file is compressed.
@@ -578,7 +611,7 @@ bool Buffer::readFile(FileName const & f
 	paragraphs().clear();
 	LyXLex lex(0, 0);
 	lex.setFile(filename);
-	if (!readFile(lex, filename))
+	if (readFile(lex, filename) != success)
 		return false;
 
 	// After we have read a file, we must ensure that the buffer
@@ -602,14 +635,15 @@ void Buffer::fully_loaded(bool const val
 }
 
 
-bool Buffer::readFile(LyXLex & lex, FileName const & filename)
+Buffer::ReadStatus Buffer::readFile(LyXLex & lex, FileName const & filename,
+		bool fromstring)
 {
 	BOOST_ASSERT(!filename.empty());
 
 	if (!lex.isOK()) {
 		Alert::error(_("Document could not be read"),
 			 bformat(_("%1$s could not be read."), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	lex.next();
@@ -618,7 +652,7 @@ bool Buffer::readFile(LyXLex & lex, File
 	if (!lex.isOK()) {
 		Alert::error(_("Document could not be read"),
 			 bformat(_("%1$s could not be read."), 

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 13, 2007, at 7:37 AM, Georg Baum wrote:


Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm:


LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
LyXFunc::dispatch: primary-selection-paste [15] is disabled at this


This is of course wrong. I used LFUN_PRIMARY_SELECTION_PASTE  
instead of
LFUN_CLIPBOARD_PASTE in pasteClipboard(). I did not notice that  
because I
always pasted when the selection in the other program was still  
available,

so LFUN_PRIMARY_SELECTION_PASTE did work for me.
I cannot use LFUN_CLIPBOARD_PASTE (infinite recursion), but this patch
should now do exactly the same as current trunk if the external  
clipboard

does not contain LyX formatted stuff.
Bennet, could you test this once again please? I only need a  
console log if

this still does not work, but I am pretty sure that it works now.


That works! Thanks again.

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Mittwoch, 10. Januar 2007 23:46 schrieb Jean-Marc Lasgouttes:

> A question: what happens to relative filenames when copy-pasting a
> graphics or include inset? (the answer is probably: the same thing as
> before :)

Yes (i.e. nothing happens).


Georg

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 10, 2007, at 8:46 PM, Bennett Helm wrote:


On Jan 10, 2007, at 4:28 PM, Georg Baum wrote:


Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:

This I agree is a good goal. I was afraid that you intended to  
replaced
the internal Clipboard for all platforms. If that is not the case  
then I

think this will be a very good contribution to 1.5 new Clipboard
functionality. An html formatted Clipboard would be nice also.


I cleaned the patch up and tested it a bit more. The clipboard  
does now
only go through a file if lyx2lyx is used. I also removed some  
debugging
stuff and put the remaining one in an if(debugging), because that  
avoids

some string conversions (fromqstr() etc).

Bennet, do you see any speed improvement? BTW it is normal that  
copy/paste

to/from other apps looses formatting. We are not using html on the
clipboard yet, I would prefer to wait with this until we use mime  
types

for our formats.


I get what seems to be minor speed improvement. Cutting and pasting  
an entire 110,000 word document, it's still on the order of 2  
seconds (just under, perhaps) for cutting and 1 second (again just  
under, perhaps) for pasting.


For more normal cut-and-paste operations, it's fast enough I don't  
notice a time lag on my new Intel Mac.


I just noticed: although this new patch works within LyX, it does not  
work pasting text from other applications: it either pastes the last  
clipboard from within LyX or it says Command disabled.


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:

 I just noticed: although this new patch works within LyX, it does not  
 work pasting text from other applications: it either pastes the last  
 clipboard from within LyX or it says Command disabled.

And that does work without the patch?


Georg

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:


I just noticed: although this new patch works within LyX, it does not
work pasting text from other applications: it either pastes the last
clipboard from within LyX or it says Command disabled.


And that does work without the patch?


Yes.

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:
 On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:
 
  Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:
 
  I just noticed: although this new patch works within LyX, it does not
  work pasting text from other applications: it either pastes the last
  clipboard from within LyX or it says Command disabled.
 
  And that does work without the patch?
 
 Yes.

Strange. I'll have a look.


Georg

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:
 On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:
 
  Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:
 
  I just noticed: although this new patch works within LyX, it does not
  work pasting text from other applications: it either pastes the last
  clipboard from within LyX or it says Command disabled.
 
  And that does work without the patch?
 
 Yes.

I had a look and have no clue why it does not work for you (it does for 
me).
Can you please try this updated patch and send the console output that is 
generated with -dbg action?


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16654)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor  
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1814,10 +1814,13 @@ bool InsetTabular::copySelection(LCursor
 	odocstringstream os;
 	OutputParams const runparams;
 	paste_tabular-plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the Edit-Paste recent menu and the system clipboard.
+	cap::copySelection(cur, os.str());
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelection.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16654)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor 
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16654)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor 
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16654)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,39 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::readString(std::string const  s)
+{
+	params().compressed = false;
+
+	// remove dummy empty par
+	paragraphs().clear();
+	LyXLex lex(0, 0);
+	std::istringstream is(s);
+	lex.setStream(is);
+	FileName const name(tempName());
+	switch (readFile(lex, name)) {
+	case failure:
+		return false;
+	case wrongversion: {
+		// We need to call lyx2lyx, so write the input to a file
+		std::ofstream os(name.toFilesystemEncoding().c_str());
+		os  s;
+		os.close();
+		return readFile(name) == success;
+	}
+	case success:
+		break;
+	}
+
+	// After we have read a file, we must ensure that the buffer
+	// language is set and used in the gui.
+	// If you know of a better place to put this, please tell me. (Lgb)
+	updateDocLang(params().language);
+
+	return true;
+}
+
+
 bool Buffer::readFile(FileName const  filename)
 {
 	// Check if the file is compressed.
@@ -578,7 +611,7 @@ bool Buffer::readFile(FileName const  f
 	paragraphs().clear();
 	LyXLex lex(0, 0);
 	lex.setFile(filename);
-	if (!readFile(lex, filename))
+	if (readFile(lex, filename) != success)
 		return false;
 
 	// After we have read a file, we must ensure that the buffer
@@ -602,14 +635,15 @@ void Buffer::fully_loaded(bool const val
 }
 
 
-bool Buffer::readFile(LyXLex  lex, FileName const  filename)
+Buffer::ReadStatus Buffer::readFile(LyXLex  lex, FileName const  filename,
+		bool fromstring)
 {
 	BOOST_ASSERT(!filename.empty());
 
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	lex.next();
@@ -618,7 +652,7 @@ bool Buffer::readFile(LyXLex  lex, File
 	if (!lex.isOK()) {
 		Alert::error(_(Document could not be read),
 			 bformat(_(%1$s could not be read.), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	// the first token _must_ be...
@@ -628,7 +662,7 @@ bool Buffer::readFile(LyXLex  lex, File
 		Alert::error(_(Document format failure),
 			 

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 11, 2007, at 4:29 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:

On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:

I just noticed: although this new patch works within LyX, it  
does not
work pasting text from other applications: it either pastes the  
last

clipboard from within LyX or it says Command disabled.


And that does work without the patch?


Yes.


I had a look and have no clue why it does not work for you (it does  
for

me).
Can you please try this updated patch and send the console output  
that is

generated with -dbg action?


07:09:09 | bennett:~ /Applications/LyX-devel.app/Contents/MacOS/lyx - 
dbg action

Setting debug level to action
Debugging `action' (User commands)
LyXComm: Pipe /Users/bennett/Library/Application Support/ 
LyX-1.5svn/.lyxpipe.in already exists.
If no other LyX program is active, please delete the pipe by hand and  
try again.

GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0

LyXFunc::dispatch: cmd:  action: 3 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is

LyXFunc::dispatch: cmd:  action: 14 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
virtual void lyx::InsetText::doDispatch(lyx::LCursor,  
lyx::FuncRequest) [ cmd.action = 14]

LyXText::dispatch: cmd:  action: 14 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::hasLyXContents(): 0

LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
LyXFunc::dispatch: primary-selection-paste [15] is disabled at this  
location

GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is Command disabled
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is Command disabled

Bennett

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 10, 2007, at 8:46 PM, Bennett Helm wrote:


On Jan 10, 2007, at 4:28 PM, Georg Baum wrote:


Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:

This I agree is a good goal. I was afraid that you intended to  
replaced
the internal Clipboard for all platforms. If that is not the case  
then I

think this will be a very good contribution to 1.5 new Clipboard
functionality. An html formatted Clipboard would be nice also.


I cleaned the patch up and tested it a bit more. The clipboard  
does now
only go through a file if lyx2lyx is used. I also removed some  
debugging
stuff and put the remaining one in an if(debugging), because that  
avoids

some string conversions (fromqstr() etc).

Bennet, do you see any speed improvement? BTW it is normal that  
copy/paste

to/from other apps looses formatting. We are not using html on the
clipboard yet, I would prefer to wait with this until we use mime  
types

for our formats.


I get what seems to be minor speed improvement. Cutting and pasting  
an entire 110,000 word document, it's still on the order of 2  
seconds (just under, perhaps) for cutting and 1 second (again just  
under, perhaps) for pasting.


For more normal cut-and-paste operations, it's fast enough I don't  
notice a time lag on my new Intel Mac.


I just noticed: although this new patch works within LyX, it does not  
work pasting text from other applications: it either pastes the last  
clipboard from within LyX or it says "Command disabled".


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:

> I just noticed: although this new patch works within LyX, it does not  
> work pasting text from other applications: it either pastes the last  
> clipboard from within LyX or it says "Command disabled".

And that does work without the patch?


Georg

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:


I just noticed: although this new patch works within LyX, it does not
work pasting text from other applications: it either pastes the last
clipboard from within LyX or it says "Command disabled".


And that does work without the patch?


Yes.

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:
> On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:
> 
> > Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:
> >
> >> I just noticed: although this new patch works within LyX, it does not
> >> work pasting text from other applications: it either pastes the last
> >> clipboard from within LyX or it says "Command disabled".
> >
> > And that does work without the patch?
> 
> Yes.

Strange. I'll have a look.


Georg

Re: another small bug for status 1.5.x

[Georg Baum]

Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:
> On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:
> 
> > Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:
> >
> >> I just noticed: although this new patch works within LyX, it does not
> >> work pasting text from other applications: it either pastes the last
> >> clipboard from within LyX or it says "Command disabled".
> >
> > And that does work without the patch?
> 
> Yes.

I had a look and have no clue why it does not work for you (it does for 
me).
Can you please try this updated patch and send the console output that is 
generated with -dbg action?


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16654)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor & 
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1814,10 +1814,13 @@ bool InsetTabular::copySelection(LCursor
 	odocstringstream os;
 	OutputParams const runparams;
 	paste_tabular->plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the "Edit->Paste recent" menu and the system clipboard.
+	cap::copySelection(cur, os.str());
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelection.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16654)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor &
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16654)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor &
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16654)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,39 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::readString(std::string const & s)
+{
+	params().compressed = false;
+
+	// remove dummy empty par
+	paragraphs().clear();
+	LyXLex lex(0, 0);
+	std::istringstream is(s);
+	lex.setStream(is);
+	FileName const name(tempName());
+	switch (readFile(lex, name)) {
+	case failure:
+		return false;
+	case wrongversion: {
+		// We need to call lyx2lyx, so write the input to a file
+		std::ofstream os(name.toFilesystemEncoding().c_str());
+		os << s;
+		os.close();
+		return readFile(name) == success;
+	}
+	case success:
+		break;
+	}
+
+	// After we have read a file, we must ensure that the buffer
+	// language is set and used in the gui.
+	// If you know of a better place to put this, please tell me. (Lgb)
+	updateDocLang(params().language);
+
+	return true;
+}
+
+
 bool Buffer::readFile(FileName const & filename)
 {
 	// Check if the file is compressed.
@@ -578,7 +611,7 @@ bool Buffer::readFile(FileName const & f
 	paragraphs().clear();
 	LyXLex lex(0, 0);
 	lex.setFile(filename);
-	if (!readFile(lex, filename))
+	if (readFile(lex, filename) != success)
 		return false;
 
 	// After we have read a file, we must ensure that the buffer
@@ -602,14 +635,15 @@ void Buffer::fully_loaded(bool const val
 }
 
 
-bool Buffer::readFile(LyXLex & lex, FileName const & filename)
+Buffer::ReadStatus Buffer::readFile(LyXLex & lex, FileName const & filename,
+		bool fromstring)
 {
 	BOOST_ASSERT(!filename.empty());
 
 	if (!lex.isOK()) {
 		Alert::error(_("Document could not be read"),
 			 bformat(_("%1$s could not be read."), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	lex.next();
@@ -618,7 +652,7 @@ bool Buffer::readFile(LyXLex & lex, File
 	if (!lex.isOK()) {
 		Alert::error(_("Document could not be read"),
 			 bformat(_("%1$s could not be read."), from_utf8(filename.absFilename(;
-		return false;
+		return failure;
 	}
 
 	// the first token _must_ be...
@@ -628,7 +662,7 @@ bool Buffer::readFile(LyXLex & lex, File
 		

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 11, 2007, at 4:29 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 21:21 schrieb Bennett Helm:

On Jan 11, 2007, at 3:18 PM, Georg Baum wrote:


Am Donnerstag, 11. Januar 2007 18:26 schrieb Bennett Helm:

I just noticed: although this new patch works within LyX, it  
does not
work pasting text from other applications: it either pastes the  
last

clipboard from within LyX or it says "Command disabled".


And that does work without the patch?


Yes.


I had a look and have no clue why it does not work for you (it does  
for

me).
Can you please try this updated patch and send the console output  
that is

generated with -dbg action?


07:09:09 | bennett:~> /Applications/LyX-devel.app/Contents/MacOS/lyx - 
dbg action

Setting debug level to action
Debugging `action' (User commands)
LyXComm: Pipe /Users/bennett/Library/Application Support/ 
LyX-1.5svn/.lyxpipe.in already exists.
If no other LyX program is active, please delete the pipe by hand and  
try again.

GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0

LyXFunc::dispatch: cmd:  action: 3 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is

LyXFunc::dispatch: cmd:  action: 14 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
virtual void lyx::InsetText::doDispatch(lyx::LCursor&,  
lyx::FuncRequest&) [ cmd.action = 14]

LyXText::dispatch: cmd:  action: 14 arg: '' x: 0 y: 0
GuiClipboard::isInternal(): 0
GuiClipboard::isInternal(): 0
GuiClipboard::hasLyXContents(): 0

LyXFunc::dispatch: cmd:  action: 15 arg: 'paragraph' x: 0 y: 0
LyXFunc::dispatch: primary-selection-paste [15] is disabled at this  
location

GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is Command disabled
GuiClipboard::isInternal(): 0
GuiClipboard::empty(): 0
dispatch msg is Command disabled

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Abdelrazak Younes wrote:

 Quite frankly I am not very confident that you can achieve the same
 performance as the internal Clipboard.

I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string - stringstream -
string, so I believe that Bennets numbers are not bad. I would have
expected worse numbers.

 You are putting in the chain 
 lyx2lyx parsing + lyx format parsing which is known to take some time.

lyx2lyx only if the format is not recent, so lyx2lyx will not be called if
this is used as a workaround on the Mac. And according to Andre LyX format
parsing is fast.

 Right now, I can copy and paste the full UserGuide.lyx into another
 document without _any_ delay. I doubt this would ever be possible with
 your solution.
 
 Moreover, we have now the multiple view feature so we don't need this
 feature anymore.

I strongly disagree. First, the multiple view feature is still not finished,
and AFAIK it is still not decided whether it will be made visible in 1.5.0
or not.

Second, I usually start several instances of LyX for several documents. This
has the advantage that if one instance crashes the other ones do still
live, and I don't have to load the ither documents again. Sometimes one
instance is even running on another machine, e.g. when I am prerparing
large lecture notes that need to be compiled often and take some time.

 If we are going that route then I would prefer that you use binary dump
 of the internal structure instead.

I already explained that I expect several problems with that and why I am
not going to do that.

 Sorry for not being optimistic about this. Moreover I really think that
 the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem
 can be cured without this hammer solution IMHO.

It can be cured with a workaround, yes. To me it looks far better to use
this patch:

- It has the advantage of increased interoperability
- Mac users with a working QCliboard::ownsClipboard() will automatically use
the fast internal version. The workaround would probably not allow that,
since testing for it would

I agree with you that clipboard/selection is OK for 1.5.0 (almost; I'll
write a summary later). My reasons for finishing this patch where simply:

- It was lying around here unfinished for over a year, and I wanted to have
that since ages
- It solves the Mac problem without the need to invent another workaround.


Georg

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:

Abdelrazak Younes wrote:


Quite frankly I am not very confident that you can achieve the same
performance as the internal Clipboard.


I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string - stringstream -
string, so I believe that Bennets numbers are not bad. I would have
expected worse numbers.


Me too ;-)
The numbers look OK.



You are putting in the chain 
lyx2lyx parsing + lyx format parsing which is known to take some time.


lyx2lyx only if the format is not recent, so lyx2lyx will not be called if
this is used as a workaround on the Mac.


OK.


And according to Andre LyX format
parsing is fast.


I am going to make it even faster...




Right now, I can copy and paste the full UserGuide.lyx into another
document without _any_ delay. I doubt this would ever be possible with
your solution.

Moreover, we have now the multiple view feature so we don't need this
feature anymore.


I strongly disagree. First, the multiple view feature is still not finished,
and AFAIK it is still not decided whether it will be made visible in 1.5.0
or not.


Have you tried it lately?

[...]

I agree with you that clipboard/selection is OK for 1.5.0 (almost; I'll
write a summary later). My reasons for finishing this patch where simply:

- It was lying around here unfinished for over a year, and I wanted to have
that since ages
- It solves the Mac problem without the need to invent another workaround.


If we still uses the internal clipbard when possible, that's OK with me 
then. Thanks for the precisions.


Abdel.

Re: another small bug for status 1.5.x

[Jürgen Spitzmüller]

Abdelrazak Younes wrote:
 This I agree is a good goal. I was afraid that you intended to replaced
 the internal Clipboard for all platforms. If that is not the case then I
 think this will be a very good contribution to 1.5 new Clipboard
 functionality. An html formatted Clipboard would be nice also.

I did not have a look at the patch, but could this be theoretically extended 
to what some people requested in the wiki's feature poll as:

Paste Latex Section (Relyx in Place). And if LyX know the latex constructs it 
relyx's them. I have a lot of old latex documents wich i want to reuse. but 
not all of it just some tabels and stuff. But if I paste the into LyX i have 
them as evil red. Or have to create a file and must run relyx and copy and 
paste.

Just curious.

Jürgen

Re: another small bug for status 1.5.x

[Georg Baum]

Jürgen Spitzmüller wrote:

 Abdelrazak Younes wrote:
 This I agree is a good goal. I was afraid that you intended to replaced
 the internal Clipboard for all platforms.

That is Bo, not me.

 If that is not the case then I 
 think this will be a very good contribution to 1.5 new Clipboard
 functionality. An html formatted Clipboard would be nice also.
 
 I did not have a look at the patch, but could this be theoretically
 extended to what some people requested in the wiki's feature poll as:
 
 Paste Latex Section (Relyx in Place). And if LyX know the latex
 constructs it relyx's them. I have a lot of old latex documents wich i
 want to reuse. but not all of it just some tabels and stuff. But if I
 paste the into LyX i have them as evil red. Or have to create a file and
 must run relyx and copy and paste.

It could, and it would probably not be more than 50 additional lines of
code: In the function that gets the clipboard contents, just look at the
other available mimetypes, and instead of calling Buffer::read, call the
import lfun. That would either require that we associate mimetypes to the
formats (something that I want to do for a long time, because then we would
not need our hand made and unflexible getFormatFromContents(), but could
use utilities like file instead). Or we would need an internal list of
mimetypes for the more common formats (with tex and html probably the most
important ones).


Georg

Re: another small bug for status 1.5.x

[Jean-Marc Lasgouttes]

 José == José Matos [EMAIL PROTECTED] writes:

 José, can this version go in please?

José   Assuming it works I like your solution. :-) Does anyone has a
José strong objection to this patch?

As Georg said, this is not something we are supposed to add now, but
since it is done... 

A question: what happens to relative filenames when copy-pasting a
graphics or include inset? (the answer is probably: the same thing as
before :)

JMarc

Re: another small bug for status 1.5.x

[Juergen Spitzmueller]

Georg Baum wrote:

 It could, and it would probably not be more than 50 additional lines of
 code

Cool. Meanwhile, I filed an enhancement request:
http://bugzilla.lyx.org/show_bug.cgi?id=3096

Jürgen

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 10, 2007, at 4:28 PM, Georg Baum wrote:


Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:

This I agree is a good goal. I was afraid that you intended to  
replaced
the internal Clipboard for all platforms. If that is not the case  
then I

think this will be a very good contribution to 1.5 new Clipboard
functionality. An html formatted Clipboard would be nice also.


I cleaned the patch up and tested it a bit more. The clipboard does  
now
only go through a file if lyx2lyx is used. I also removed some  
debugging
stuff and put the remaining one in an if(debugging), because that  
avoids

some string conversions (fromqstr() etc).

Bennet, do you see any speed improvement? BTW it is normal that  
copy/paste

to/from other apps looses formatting. We are not using html on the
clipboard yet, I would prefer to wait with this until we use mime  
types

for our formats.


I get what seems to be minor speed improvement. Cutting and pasting  
an entire 110,000 word document, it's still on the order of 2 seconds  
(just under, perhaps) for cutting and 1 second (again just under,  
perhaps) for pasting.


For more normal cut-and-paste operations, it's fast enough I don't  
notice a time lag on my new Intel Mac.


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Abdelrazak Younes wrote:

> Quite frankly I am not very confident that you can achieve the same
> performance as the internal Clipboard.

I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string -> stringstream ->
string, so I believe that Bennets numbers are not bad. I would have
expected worse numbers.

> You are putting in the chain 
> lyx2lyx parsing + lyx format parsing which is known to take some time.

lyx2lyx only if the format is not recent, so lyx2lyx will not be called if
this is used as a workaround on the Mac. And according to Andre LyX format
parsing is fast.

> Right now, I can copy and paste the full UserGuide.lyx into another
> document without _any_ delay. I doubt this would ever be possible with
> your solution.
> 
> Moreover, we have now the multiple view feature so we don't need this
> feature anymore.

I strongly disagree. First, the multiple view feature is still not finished,
and AFAIK it is still not decided whether it will be made visible in 1.5.0
or not.

Second, I usually start several instances of LyX for several documents. This
has the advantage that if one instance crashes the other ones do still
live, and I don't have to load the ither documents again. Sometimes one
instance is even running on another machine, e.g. when I am prerparing
large lecture notes that need to be compiled often and take some time.

> If we are going that route then I would prefer that you use binary dump
> of the internal structure instead.

I already explained that I expect several problems with that and why I am
not going to do that.

> Sorry for not being optimistic about this. Moreover I really think that
> the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem
> can be cured without this hammer solution IMHO.

It can be cured with a workaround, yes. To me it looks far better to use
this patch:

- It has the advantage of increased interoperability
- Mac users with a working QCliboard::ownsClipboard() will automatically use
the fast internal version. The workaround would probably not allow that,
since testing for it would

I agree with you that clipboard/selection is OK for 1.5.0 (almost; I'll
write a summary later). My reasons for finishing this patch where simply:

- It was lying around here unfinished for over a year, and I wanted to have
that since ages
- It solves the Mac problem without the need to invent another workaround.


Georg

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:

Abdelrazak Younes wrote:


Quite frankly I am not very confident that you can achieve the same
performance as the internal Clipboard.


I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string -> stringstream ->
string, so I believe that Bennets numbers are not bad. I would have
expected worse numbers.


Me too ;-)
The numbers look OK.



You are putting in the chain 
lyx2lyx parsing + lyx format parsing which is known to take some time.


lyx2lyx only if the format is not recent, so lyx2lyx will not be called if
this is used as a workaround on the Mac.


OK.


And according to Andre LyX format
parsing is fast.


I am going to make it even faster...




Right now, I can copy and paste the full UserGuide.lyx into another
document without _any_ delay. I doubt this would ever be possible with
your solution.

Moreover, we have now the multiple view feature so we don't need this
feature anymore.


I strongly disagree. First, the multiple view feature is still not finished,
and AFAIK it is still not decided whether it will be made visible in 1.5.0
or not.


Have you tried it lately?

[...]

I agree with you that clipboard/selection is OK for 1.5.0 (almost; I'll
write a summary later). My reasons for finishing this patch where simply:

- It was lying around here unfinished for over a year, and I wanted to have
that since ages
- It solves the Mac problem without the need to invent another workaround.


If we still uses the internal clipbard when possible, that's OK with me 
then. Thanks for the precisions.


Abdel.

Re: another small bug for status 1.5.x

[Jürgen Spitzmüller]

Abdelrazak Younes wrote:
> This I agree is a good goal. I was afraid that you intended to replaced
> the internal Clipboard for all platforms. If that is not the case then I
> think this will be a very good contribution to 1.5 new Clipboard
> functionality. An html formatted Clipboard would be nice also.

I did not have a look at the patch, but could this be theoretically extended 
to what some people requested in the wiki's feature poll as:

"Paste Latex Section (Relyx in Place). And if LyX know the latex constructs it 
relyx's them. I have a lot of old latex documents wich i want to reuse. but 
not all of it just some tabels and stuff. But if I paste the into LyX i have 
them as evil red. Or have to create a file and must run relyx and copy and 
paste."

Just curious.

Jürgen

Re: another small bug for status 1.5.x

[Georg Baum]

Jürgen Spitzmüller wrote:

> Abdelrazak Younes wrote:
>> This I agree is a good goal. I was afraid that you intended to replaced
>> the internal Clipboard for all platforms.

That is Bo, not me.

>> If that is not the case then I 
>> think this will be a very good contribution to 1.5 new Clipboard
>> functionality. An html formatted Clipboard would be nice also.
> 
> I did not have a look at the patch, but could this be theoretically
> extended to what some people requested in the wiki's feature poll as:
> 
> "Paste Latex Section (Relyx in Place). And if LyX know the latex
> constructs it relyx's them. I have a lot of old latex documents wich i
> want to reuse. but not all of it just some tabels and stuff. But if I
> paste the into LyX i have them as evil red. Or have to create a file and
> must run relyx and copy and paste."

It could, and it would probably not be more than 50 additional lines of
code: In the function that gets the clipboard contents, just look at the
other available mimetypes, and instead of calling Buffer::read, call the
import lfun. That would either require that we associate mimetypes to the
formats (something that I want to do for a long time, because then we would
not need our hand made and unflexible getFormatFromContents(), but could
use utilities like file instead). Or we would need an internal list of
mimetypes for the more common formats (with tex and html probably the most
important ones).


Georg

Re: another small bug for status 1.5.x

[Jean-Marc Lasgouttes]

> "José" == José Matos <[EMAIL PROTECTED]> writes:

>> José, can this version go in please?

José>   Assuming it works I like your solution. :-) Does anyone has a
José> strong objection to this patch?

As Georg said, this is not something we are supposed to add now, but
since it is done... 

A question: what happens to relative filenames when copy-pasting a
graphics or include inset? (the answer is probably: the same thing as
before :)

JMarc

Re: another small bug for status 1.5.x

[Juergen Spitzmueller]

Georg Baum wrote:

> It could, and it would probably not be more than 50 additional lines of
> code

Cool. Meanwhile, I filed an enhancement request:
http://bugzilla.lyx.org/show_bug.cgi?id=3096

Jürgen

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 10, 2007, at 4:28 PM, Georg Baum wrote:


Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:

This I agree is a good goal. I was afraid that you intended to  
replaced
the internal Clipboard for all platforms. If that is not the case  
then I

think this will be a very good contribution to 1.5 new Clipboard
functionality. An html formatted Clipboard would be nice also.


I cleaned the patch up and tested it a bit more. The clipboard does  
now
only go through a file if lyx2lyx is used. I also removed some  
debugging
stuff and put the remaining one in an if(debugging), because that  
avoids

some string conversions (fromqstr() etc).

Bennet, do you see any speed improvement? BTW it is normal that  
copy/paste

to/from other apps looses formatting. We are not using html on the
clipboard yet, I would prefer to wait with this until we use mime  
types

for our formats.


I get what seems to be minor speed improvement. Cutting and pasting  
an entire 110,000 word document, it's still on the order of 2 seconds  
(just under, perhaps) for cutting and 1 second (again just under,  
perhaps) for pasting.


For more normal cut-and-paste operations, it's fast enough I don't  
notice a time lag on my new Intel Mac.


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:
 On Jan 5, 2007, at 12:39 PM, Georg Baum wrote:
 
  Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:
 
  In addition, cut and paste is currently not working well: it only
  pastes unformatted text (and omits footnotes and other insets). I
  haven't reported this given the flux in the cut-and-paste code,
  though I don't know if it's a Mac specific bug.
 
  This looks like QClipboard::ownsClipboard() always returns false.  
  Can you
  please verify that by a debug message in GuiClipboard::isInternal?  
  If you
  just add the line
 
  lyxerr  GuiClipboard::isInternal:  
  qApp-clipboard()-ownsClipboard()  endl;
 
  , do a copy and then paste it should print
 
  GuiClipboard::isInternal: 1
 
  If my guess it right it will print
 
  GuiClipboard::isInternal: 0
 
  instead.
 
 You're right: GuiClipboard::isInternal: 0

This patch should work around that problem by using the system clipboard to 
store LyX formatted stuff. As a side effect, it also fixes this bug: 
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)

Seriously: I started to implement this as a fix for 2138 over a year ago, 
but never found the time to finish it, because at that time it was far 
more complicated. When I realized that it could fix this problem as well 
(at a possible performance cost, we need to investigate that) I could not 
resist to try to finish it. Thanks to some cleanup that has happened 
during the last months it was now quite easy to get it working. This patch 
is not well tested and has a lot of debug output (+ some error handling 
missing), but if this is OK to go in I plan to polish it when I find time.


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16633)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor  
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1811,13 +1811,13 @@ bool InsetTabular::copySelection(LCursor
 	paste_tabular-setRightLine(paste_tabular-getLastCellInRow(0),
 true, true);
 
-	odocstringstream os;
-	OutputParams const runparams;
-	paste_tabular-plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the Edit-Paste recent menu and the system clipboard.
+	cap::copySelectionToStack(cur);
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelectionToStack.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16633)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor 
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16633)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor 
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty()  !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16633)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,20 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::read(std::istream  is)
+{
+	// We need to construct a temp file in order to be able to use lyx2lyx
+	FileName const tmpfile(tempName());
+	if (tmpfile.empty()) {
+		return false;
+	}
+	ofstream os(tmpfile.toFilesystemEncoding().c_str(), ios::binary | ios::out | ios::trunc);
+	os  is.rdbuf();
+	os.close();
+	return readFile(tmpfile);
+}
+
+
 bool Buffer::readFile(FileName const  filename)
 {
 	// Check if the file is compressed.
@@ -763,20 +777,20 @@ bool Buffer::writeFile(FileName const  
 		if (!ofs)
 			return false;
 
-		retval = do_writeFile(ofs);
+		retval = write(ofs);
 	} else {
 		ofstream ofs(fname.toFilesystemEncoding().c_str(), ios::out|ios::trunc);
 		if (!ofs)
 			return false;
 
-		retval = do_writeFile(ofs);
+		retval = write(ofs);
 	}
 
 	return retval;
 }
 
 
-bool Buffer::do_writeFile(ostream  ofs) const
+bool Buffer::write(ostream  

Re: another small bug for status 1.5.x

[Bo Peng]

As a side effect, it also fixes this bug:
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)


I am happy to see that you are going toward the removal of internal
clipboards. :-)

Bo

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:
This patch should work around that problem by using the system clipboard to 
store LyX formatted stuff. As a side effect, it also fixes this bug: 
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)


Seriously: I started to implement this as a fix for 2138 over a year ago, 
but never found the time to finish it, because at that time it was far 
more complicated. When I realized that it could fix this problem as well 
(at a possible performance cost, we need to investigate that) I could not 
resist to try to finish it. Thanks to some cleanup that has happened 
during the last months it was now quite easy to get it working. This patch 
is not well tested and has a lot of debug output (+ some error handling 
missing), but if this is OK to go in I plan to polish it when I find time.


Quite frankly I am not very confident that you can achieve the same 
performance as the internal Clipboard. You are putting in the chain 
lyx2lyx parsing + lyx format parsing which is known to take some time. 
Right now, I can copy and paste the full UserGuide.lyx into another 
document without _any_ delay. I doubt this would ever be possible with 
your solution.


Moreover, we have now the multiple view feature so we don't need this 
feature anymore.


If we are going that route then I would prefer that you use binary dump 
of the internal structure instead.


Sorry for not being optimistic about this. Moreover I really think that 
the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem 
can be cured without this hammer solution IMHO.


Abdel.

Re: another small bug for status 1.5.x

[Bo Peng]

Quite frankly I am not very confident that you can achieve the same
performance as the internal Clipboard. You are putting in the chain
lyx2lyx parsing + lyx format parsing which is known to take some time.


I do not think you need to do lyx2lyx stuff. Technically speaking,
what we need is boost::serialization which is quite fast from my
experience.

Bo

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 9, 2007, at 5:42 PM, Abdelrazak Younes wrote:


Georg Baum wrote:
This patch should work around that problem by using the system  
clipboard to store LyX formatted stuff. As a side effect, it also  
fixes this bug: http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)
Seriously: I started to implement this as a fix for 2138 over a  
year ago, but never found the time to finish it, because at that  
time it was far more complicated. When I realized that it could  
fix this problem as well (at a possible performance cost, we need  
to investigate that) I could not resist to try to finish it.  
Thanks to some cleanup that has happened during the last months it  
was now quite easy to get it working. This patch is not well  
tested and has a lot of debug output (+ some error handling  
missing), but if this is OK to go in I plan to polish it when I  
find time.


Quite frankly I am not very confident that you can achieve the same  
performance as the internal Clipboard. You are putting in the chain  
lyx2lyx parsing + lyx format parsing which is known to take some  
time. Right now, I can copy and paste the full UserGuide.lyx into  
another document without _any_ delay. I doubt this would ever be  
possible with your solution.


Moreover, we have now the multiple view feature so we don't need  
this feature anymore.


If we are going that route then I would prefer that you use binary  
dump of the internal structure instead.


Sorry for not being optimistic about this. Moreover I really think  
that the Clipboard/Selection stuff is OK right now for 1.5, the Mac  
problem can be cured without this hammer solution IMHO.


Well, it does work on Mac: insets and formatting are correctly cut- 
and-pasted within LyX (though cutting and pasting between LyX and  
other programs destroys the formatting and deletes the contents of  
insets, which I assume is intended behavior).


As for speed, I can cut a 110,000 word document in about 2 seconds  
and paste it in about 1 second with this patch. (Without the patch  
it's very quick --  .25 second -- but, of course, without formatting  
or insets.)


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:
> On Jan 5, 2007, at 12:39 PM, Georg Baum wrote:
> 
> > Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:
> >
> >> In addition, cut and paste is currently not working well: it only
> >> pastes unformatted text (and omits footnotes and other insets). I
> >> haven't reported this given the flux in the cut-and-paste code,
> >> though I don't know if it's a Mac specific bug.
> >
> > This looks like QClipboard::ownsClipboard() always returns false.  
> > Can you
> > please verify that by a debug message in GuiClipboard::isInternal?  
> > If you
> > just add the line
> >
> > lyxerr << "GuiClipboard::isInternal: " <<
> > qApp->clipboard()->ownsClipboard() << endl;
> >
> > , do a copy and then paste it should print
> >
> > GuiClipboard::isInternal: 1
> >
> > If my guess it right it will print
> >
> > GuiClipboard::isInternal: 0
> >
> > instead.
> 
> You're right: GuiClipboard::isInternal: 0

This patch should work around that problem by using the system clipboard to 
store LyX formatted stuff. As a side effect, it also fixes this bug: 
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)

Seriously: I started to implement this as a fix for 2138 over a year ago, 
but never found the time to finish it, because at that time it was far 
more complicated. When I realized that it could fix this problem as well 
(at a possible performance cost, we need to investigate that) I could not 
resist to try to finish it. Thanks to some cleanup that has happened 
during the last months it was now quite easy to get it working. This patch 
is not well tested and has a lot of debug output (+ some error handling 
missing), but if this is OK to go in I plan to polish it when I find time.


Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(Revision 16633)
+++ src/insets/insettabular.C	(Arbeitskopie)
@@ -723,7 +723,7 @@ void InsetTabular::doDispatch(LCursor & 
 	case LFUN_CLIPBOARD_PASTE:
 	case LFUN_PRIMARY_SELECTION_PASTE: {
 		docstring const clip = (cmd.action == LFUN_CLIPBOARD_PASTE) ?
-			theClipboard().get() :
+			theClipboard().getAsText() :
 			theSelection().get();
 		if (clip.empty())
 			break;
@@ -1811,13 +1811,13 @@ bool InsetTabular::copySelection(LCursor
 	paste_tabular->setRightLine(paste_tabular->getLastCellInRow(0),
 true, true);
 
-	odocstringstream os;
-	OutputParams const runparams;
-	paste_tabular->plaintext(cur.buffer(), os, runparams, 0, true, '\t');
-	theClipboard().put(os.str());
+	// Needed for the "Edit->Paste recent" menu and the system clipboard.
+	cap::copySelectionToStack(cur);
+
 	// mark tabular stack dirty
 	// FIXME: this is a workaround for bug 1919. Should be removed for 1.5,
 	// when we (hopefully) have a one-for-all paste mechanism.
+	// This must be called after cap::copySelectionToStack.
 	dirtyTabularStack(true);
 
 	return true;
Index: src/mathed/InsetMathGrid.C
===
--- src/mathed/InsetMathGrid.C	(Revision 16633)
+++ src/mathed/InsetMathGrid.C	(Arbeitskopie)
@@ -1213,7 +1213,7 @@ void InsetMathGrid::doDispatch(LCursor &
 		cap::replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			idocstringstream is(cmd.argument());
 			int n = 0;
Index: src/mathed/InsetMathNest.C
===
--- src/mathed/InsetMathNest.C	(Revision 16633)
+++ src/mathed/InsetMathNest.C	(Arbeitskopie)
@@ -440,7 +440,7 @@ void InsetMathNest::doDispatch(LCursor &
 		replaceSelection(cur);
 		docstring topaste;
 		if (cmd.argument().empty() && !theClipboard().isInternal())
-			topaste = theClipboard().get();
+			topaste = theClipboard().getAsText();
 		else {
 			size_t n = 0;
 			idocstringstream is(cmd.argument());
Index: src/buffer.C
===
--- src/buffer.C	(Revision 16633)
+++ src/buffer.C	(Arbeitskopie)
@@ -566,6 +566,20 @@ void Buffer::insertStringAsLines(Paragra
 }
 
 
+bool Buffer::read(std::istream & is)
+{
+	// We need to construct a temp file in order to be able to use lyx2lyx
+	FileName const tmpfile(tempName());
+	if (tmpfile.empty()) {
+		return false;
+	}
+	ofstream os(tmpfile.toFilesystemEncoding().c_str(), ios::binary | ios::out | ios::trunc);
+	os << is.rdbuf();
+	os.close();
+	return readFile(tmpfile);
+}
+
+
 bool Buffer::readFile(FileName const & filename)
 {
 	// Check if the file is compressed.
@@ -763,20 +777,20 @@ bool Buffer::writeFile(FileName const & 
 		if (!ofs)
 			return false;
 
-		retval = do_writeFile(ofs);
+		retval = write(ofs);
 	} else {
 		ofstream ofs(fname.toFilesystemEncoding().c_str(), ios::out|ios::trunc);
 		if (!ofs)
 			return false;
 
-		retval = do_writeFile(ofs);
+		retval = write(ofs);
 	}
 
 	return 

Re: another small bug for status 1.5.x

[Bo Peng]

As a side effect, it also fixes this bug:
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)


I am happy to see that you are going toward the removal of internal
clipboards. :-)

Bo

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:
This patch should work around that problem by using the system clipboard to 
store LyX formatted stuff. As a side effect, it also fixes this bug: 
http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)


Seriously: I started to implement this as a fix for 2138 over a year ago, 
but never found the time to finish it, because at that time it was far 
more complicated. When I realized that it could fix this problem as well 
(at a possible performance cost, we need to investigate that) I could not 
resist to try to finish it. Thanks to some cleanup that has happened 
during the last months it was now quite easy to get it working. This patch 
is not well tested and has a lot of debug output (+ some error handling 
missing), but if this is OK to go in I plan to polish it when I find time.


Quite frankly I am not very confident that you can achieve the same 
performance as the internal Clipboard. You are putting in the chain 
lyx2lyx parsing + lyx format parsing which is known to take some time. 
Right now, I can copy and paste the full UserGuide.lyx into another 
document without _any_ delay. I doubt this would ever be possible with 
your solution.


Moreover, we have now the multiple view feature so we don't need this 
feature anymore.


If we are going that route then I would prefer that you use binary dump 
of the internal structure instead.


Sorry for not being optimistic about this. Moreover I really think that 
the Clipboard/Selection stuff is OK right now for 1.5, the Mac problem 
can be cured without this hammer solution IMHO.


Abdel.

Re: another small bug for status 1.5.x

[Bo Peng]

Quite frankly I am not very confident that you can achieve the same
performance as the internal Clipboard. You are putting in the chain
lyx2lyx parsing + lyx format parsing which is known to take some time.


I do not think you need to do lyx2lyx stuff. Technically speaking,
what we need is boost::serialization which is quite fast from my
experience.

Bo

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 9, 2007, at 5:42 PM, Abdelrazak Younes wrote:


Georg Baum wrote:
This patch should work around that problem by using the system  
clipboard to store LyX formatted stuff. As a side effect, it also  
fixes this bug: http://bugzilla.lyx.org/show_bug.cgi?id=2138 ;-)
Seriously: I started to implement this as a fix for 2138 over a  
year ago, but never found the time to finish it, because at that  
time it was far more complicated. When I realized that it could  
fix this problem as well (at a possible performance cost, we need  
to investigate that) I could not resist to try to finish it.  
Thanks to some cleanup that has happened during the last months it  
was now quite easy to get it working. This patch is not well  
tested and has a lot of debug output (+ some error handling  
missing), but if this is OK to go in I plan to polish it when I  
find time.


Quite frankly I am not very confident that you can achieve the same  
performance as the internal Clipboard. You are putting in the chain  
lyx2lyx parsing + lyx format parsing which is known to take some  
time. Right now, I can copy and paste the full UserGuide.lyx into  
another document without _any_ delay. I doubt this would ever be  
possible with your solution.


Moreover, we have now the multiple view feature so we don't need  
this feature anymore.


If we are going that route then I would prefer that you use binary  
dump of the internal structure instead.


Sorry for not being optimistic about this. Moreover I really think  
that the Clipboard/Selection stuff is OK right now for 1.5, the Mac  
problem can be cured without this hammer solution IMHO.


Well, it does work on Mac: insets and formatting are correctly cut- 
and-pasted within LyX (though cutting and pasting between LyX and  
other programs destroys the formatting and deletes the contents of  
insets, which I assume is intended behavior).


As for speed, I can cut a 110,000 word document in about 2 seconds  
and paste it in about 1 second with this patch. (Without the patch  
it's very quick -- < .25 second -- but, of course, without formatting  
or insets.)


Bennett

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 4, 2007, at 3:44 PM, Abdelrazak Younes wrote:


Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is  
first displayed after you switch to another tab.

Uwe,
it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly  
eradicate all important bugs or crashes. We should probably close  
it down and count the points. So who's winning?


Abdel.

PS: But I would not mind a status update on Mac.


On Mac, things are working much better.

* Performance is not an issue on Intel Macs. (I tried last night to  
compile on a PPC Mac, but failed: I probably need to upgrade gcc to a  
more recent version, but that's not something I can do easily; I'll  
try again later, but time is tight.)


* Toolbar issues are resolved.

* Dialogs are mostly better, though it's still not possible to select  
dialog buttons with the keyboard. In general, Mac doesn't do this to  
the extent that Linux and Windows do, but there are some standard  
shortcuts that ought to work but don't.


* Menu bar still disappears when dialogs are opened (though I believe  
Jean-Marc plans to work on that).


There are some new issues that I've reported elsewhere, such as that  
pressing down-arrow results in the cursor moving down 2 lines  
instead of 1, and bugs 3068 and 3069, both of which seem to be Mac  
specific.


In addition, cut and paste is currently not working well: it only  
pastes unformatted text (and omits footnotes and other insets). I  
haven't reported this given the flux in the cut-and-paste code,  
though I don't know if it's a Mac specific bug.


Were it not for cut-and-paste and cursor navigation problems, I'd  
probably try to start using 1.5 for some real work just to see how it  
goes.


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:

 In addition, cut and paste is currently not working well: it only  
 pastes unformatted text (and omits footnotes and other insets). I  
 haven't reported this given the flux in the cut-and-paste code,  
 though I don't know if it's a Mac specific bug.

This looks like QClipboard::ownsClipboard() always returns false. Can you 
please verify that by a debug message in GuiClipboard::isInternal? If you 
just add the line

lyxerr  GuiClipboard::isInternal:   
qApp-clipboard()-ownsClipboard()  endl;

, do a copy and then paste it should print

GuiClipboard::isInternal: 1

If my guess it right it will print

GuiClipboard::isInternal: 0

instead.


Georg

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 5, 2007, at 12:39 PM, Georg Baum wrote:


Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:


In addition, cut and paste is currently not working well: it only
pastes unformatted text (and omits footnotes and other insets). I
haven't reported this given the flux in the cut-and-paste code,
though I don't know if it's a Mac specific bug.


This looks like QClipboard::ownsClipboard() always returns false.  
Can you
please verify that by a debug message in GuiClipboard::isInternal?  
If you

just add the line

lyxerr  GuiClipboard::isInternal:  
qApp-clipboard()-ownsClipboard()  endl;

, do a copy and then paste it should print

GuiClipboard::isInternal: 1

If my guess it right it will print

GuiClipboard::isInternal: 0

instead.


You're right: GuiClipboard::isInternal: 0

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:

 You're right: GuiClipboard::isInternal: 0

Bad. Abdel do you have an idea what to do here?


Georg

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:


You're right: GuiClipboard::isInternal: 0


Bad. Abdel do you have an idea what to do here?


Seems like a Qt bug. Which version Bennett? Is it still your own 
compiled Qt or the official one?


If we cannot solve that, the only solution would be to compare the 
system clipboard with the internal one (converted as string). If it the 
same then we use the internal one. Of course, for performance reason, we 
should limit the comparison to the string size and the first 10 or 20 
characters.


Abdel.

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 5, 2007, at 3:03 PM, Abdelrazak Younes wrote:


Georg Baum wrote:

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:

You're right: GuiClipboard::isInternal: 0

Bad. Abdel do you have an idea what to do here?


Seems like a Qt bug. Which version Bennett? Is it still your own  
compiled Qt or the official one?


Qt-4.2.2; my own.

Bennett

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 4, 2007, at 3:44 PM, Abdelrazak Younes wrote:


Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is  
first displayed after you switch to another tab.

Uwe,
it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly  
eradicate all important bugs or crashes. We should probably close  
it down and count the points. So who's winning?


Abdel.

PS: But I would not mind a status update on Mac.


On Mac, things are working much better.

* Performance is not an issue on Intel Macs. (I tried last night to  
compile on a PPC Mac, but failed: I probably need to upgrade gcc to a  
more recent version, but that's not something I can do easily; I'll  
try again later, but time is tight.)


* Toolbar issues are resolved.

* Dialogs are mostly better, though it's still not possible to select  
dialog buttons with the keyboard. In general, Mac doesn't do this to  
the extent that Linux and Windows do, but there are some standard  
shortcuts that ought to work but don't.


* Menu bar still disappears when dialogs are opened (though I believe  
Jean-Marc plans to work on that).


There are some new issues that I've reported elsewhere, such as that  
pressing  results in the cursor moving down 2 lines  
instead of 1, and bugs 3068 and 3069, both of which seem to be Mac  
specific.


In addition, cut and paste is currently not working well: it only  
pastes unformatted text (and omits footnotes and other insets). I  
haven't reported this given the flux in the cut-and-paste code,  
though I don't know if it's a Mac specific bug.


Were it not for cut-and-paste and cursor navigation problems, I'd  
probably try to start using 1.5 for some real work just to see how it  
goes.


Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:

> In addition, cut and paste is currently not working well: it only  
> pastes unformatted text (and omits footnotes and other insets). I  
> haven't reported this given the flux in the cut-and-paste code,  
> though I don't know if it's a Mac specific bug.

This looks like QClipboard::ownsClipboard() always returns false. Can you 
please verify that by a debug message in GuiClipboard::isInternal? If you 
just add the line

lyxerr << "GuiClipboard::isInternal: " << 
qApp->clipboard()->ownsClipboard() << endl;

, do a copy and then paste it should print

GuiClipboard::isInternal: 1

If my guess it right it will print

GuiClipboard::isInternal: 0

instead.


Georg

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 5, 2007, at 12:39 PM, Georg Baum wrote:


Am Freitag, 5. Januar 2007 18:27 schrieb Bennett Helm:


In addition, cut and paste is currently not working well: it only
pastes unformatted text (and omits footnotes and other insets). I
haven't reported this given the flux in the cut-and-paste code,
though I don't know if it's a Mac specific bug.


This looks like QClipboard::ownsClipboard() always returns false.  
Can you
please verify that by a debug message in GuiClipboard::isInternal?  
If you

just add the line

lyxerr << "GuiClipboard::isInternal: " <<
qApp->clipboard()->ownsClipboard() << endl;

, do a copy and then paste it should print

GuiClipboard::isInternal: 1

If my guess it right it will print

GuiClipboard::isInternal: 0

instead.


You're right: GuiClipboard::isInternal: 0

Bennett

Re: another small bug for status 1.5.x

[Georg Baum]

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:

> You're right: GuiClipboard::isInternal: 0

Bad. Abdel do you have an idea what to do here?


Georg

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Georg Baum wrote:

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:


You're right: GuiClipboard::isInternal: 0


Bad. Abdel do you have an idea what to do here?


Seems like a Qt bug. Which version Bennett? Is it still your own 
compiled Qt or the official one?


If we cannot solve that, the only solution would be to compare the 
system clipboard with the internal one (converted as string). If it the 
same then we use the internal one. Of course, for performance reason, we 
should limit the comparison to the string size and the first 10 or 20 
characters.


Abdel.

Re: another small bug for status 1.5.x

[Bennett Helm]

On Jan 5, 2007, at 3:03 PM, Abdelrazak Younes wrote:


Georg Baum wrote:

Am Freitag, 5. Januar 2007 18:59 schrieb Bennett Helm:

You're right: GuiClipboard::isInternal: 0

Bad. Abdel do you have an idea what to do here?


Seems like a Qt bug. Which version Bennett? Is it still your own  
compiled Qt or the official one?


Qt-4.2.2; my own.

Bennett

Re: another small bug for status 1.5.x

[Michael Gerz]

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.

Please add the bug to bugzilla.

Michael

Re: another small bug for status 1.5.x

[Bo Peng]

it looks like we shifting back from Status.15x to bugzilla.


Why? Status.15x serves for

1. a constant, easy-to-access reminder of things that must be fixed for 1.5.0.

2. a place for short-term easy-to-fix bugs that do not deserve the
trouble (Create, search, discuss, close, etc) of a bugzilla entry.

For anything else, bugzilla should be used.

Bo

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly eradicate 
all important bugs or crashes. We should probably close it down and 
count the points. So who's winning?


Abdel.

PS: But I would not mind a status update on Mac.

Re: another small bug for status 1.5.x

[Michael Gerz]

Bo Peng schrieb:

Why? Status.15x serves for

1. a constant, easy-to-access reminder of things that must be fixed 
for 1.5.0.


2. a place for short-term easy-to-fix bugs that do not deserve the
trouble (Create, search, discuss, close, etc) of a bugzilla entry.

For anything else, bugzilla should be used.
I agree with you in principle. However, that doesn't stop people from 
using bugzilla and we shouldn't try to manage bug reports at two 
different places.


Anyway, I don't want to start a lengthy discussion. Report bugs as you 
like :-)


Michael

Re: another small bug for status 1.5.x

[Michael Gerz]

Abdelrazak Younes schrieb:

Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is 
first displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly 
eradicate all important bugs or crashes. We should probably close it 
down and count the points. So who's winning?
IMHO there are at least two equal winners: Georg and you. You can both 
start thinking about your favourite present :-)



PS: But I would not mind a status update on Mac.
Yes. Most reports are on performance   Mac. and change 
tracking! :-(


Michael

Re: another small bug for status 1.5.x

[Uwe Stöhr]

Michael Gerz schrieb:


- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.



it looks like we shifting back from Status.15x to bugzilla.
Please add the bug to bugzilla.


Done:
http://bugzilla.lyx.org/show_bug.cgi?id=3070

Uwe

Re: another small bug for status 1.5.x

[Michael Gerz]

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.

Please add the bug to bugzilla.

Michael

Re: another small bug for status 1.5.x

[Bo Peng]

it looks like we shifting back from Status.15x to bugzilla.


Why? Status.15x serves for

1. a constant, easy-to-access reminder of things that must be fixed for 1.5.0.

2. a place for short-term easy-to-fix bugs that do not deserve the
trouble (Create, search, discuss, close, etc) of a bugzilla entry.

For anything else, bugzilla should be used.

Bo

Re: another small bug for status 1.5.x

[Abdelrazak Younes]

Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly eradicate 
all important bugs or crashes. We should probably close it down and 
count the points. So who's winning?


Abdel.

PS: But I would not mind a status update on Mac.

Re: another small bug for status 1.5.x

[Michael Gerz]

Bo Peng schrieb:

Why? Status.15x serves for

1. a constant, easy-to-access reminder of things that must be fixed 
for 1.5.0.


2. a place for short-term easy-to-fix bugs that do not deserve the
trouble (Create, search, discuss, close, etc) of a bugzilla entry.

For anything else, bugzilla should be used.
I agree with you in principle. However, that doesn't stop people from 
using bugzilla and we shouldn't try to manage bug reports at two 
different places.


Anyway, I don't want to start a lengthy discussion. Report bugs as you 
like :-)


Michael

Re: another small bug for status 1.5.x

[Michael Gerz]

Abdelrazak Younes schrieb:

Michael Gerz wrote:

Uwe Stöhr schrieb:

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is 
first displayed after you switch to another tab.


Uwe,

it looks like we shifting back from Status.15x to bugzilla.


Year. I think Status.15x achieved its goal and that we mostly 
eradicate all important bugs or crashes. We should probably close it 
down and count the points. So who's winning?
IMHO there are at least two equal winners: Georg and you. You can both 
start thinking about your favourite present :-)



PS: But I would not mind a status update on Mac.
Yes. Most reports are on performance  & Mac. and change 
tracking! :-(


Michael

Re: another small bug for status 1.5.x

[Uwe Stöhr]

Michael Gerz schrieb:


- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first 
displayed after you switch to another tab.



it looks like we shifting back from Status.15x to bugzilla.
Please add the bug to bugzilla.


Done:
http://bugzilla.lyx.org/show_bug.cgi?id=3070

Uwe

another small bug for status 1.5.x

[Uwe Stöhr]

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first displayed 
after you switch to another tab.

regards Uwe

another small bug for status 1.5.x

[Uwe Stöhr]

- open two documents
- save one of the opened files under a different name
Result: The new name of the file isn't displayed in the tab. Is first displayed 
after you switch to another tab.

regards Uwe