date:20110911

Re: drag in outline panel?

2011-09-11 Thread Jürgen Spitzmüller

Xu Wang wrote:
 bump

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

Jürgen

Re: autoconf vs cmake vs scons

2011-09-11 Thread Kornel

Am Sonntag, 11. September 2011 schrieb Julien Rioux:
 On 10/09/2011 1:07 PM, Kornel wrote:
...
  I'm not sure whether I prefer cmake to move the tex2lyx
  binary to a tex2lyx subdir, or autoconf to move all binaries to the
  same bin dir. I do feel that version suffixes should be used only when
  installing. Again, maybe I did a wrong configuration of cmake.
  
  I would prefer that too, but it may be contrary to cmake philosophy.
  
  Build-dir is not the same as Install-dir for tex2lyx
 
 I only did `make`, not `make install`. So I think this must be the build
 dir. Are you saying this is the install dir, hence the suffixes?

No, i was mixing install-prefix and program-suffix here. I was confused by to 
move the tex2lyx binary to a tex2lyx subdir

 I have the binaries in
 $LYX_SVN_ROOT/build-cmake/bin/lyx2.1
 $LYX_SVN_ROOT/build-cmake/bin/tex2lyx2.1
 Compare
 $LYX_SVN_ROOT/build-autoconf/src/lyx
 $LYX_SVN_ROOT/build-autoconf/src/tex2lyx/tex2lyx
 
 I don't really feel like telling you guys to change your build systems.
 Personally both of them feel wrong: I would say binaries would go in bin
 dir and have no suffixes. In any case I could figure out a patch for
 tex2lyx detection with the status quo in mind.

+1
In cmake it was originally to mimic autoconf behaviour (I think), and it is not 
difficult to adapt something else.
I am not sure if installing in autoconf does not add the suffix?

I never use LYX_PACKAGE_SUFFIX, instead I use 
-DCMAKE_INSTALL_PREFIX=/usr/local/lyx2.1 in order to install
different versions simultaneously.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: autoconf vs cmake vs scons

2011-09-11 Thread Julien Rioux


On 11/09/2011 12:02 PM, Kornel wrote:

Am Sonntag, 11. September 2011 schrieb Julien Rioux:

On 10/09/2011 1:07 PM, Kornel wrote:

...

I'm not sure whether I prefer cmake to move the tex2lyx
binary to a tex2lyx subdir, or autoconf to move all binaries to the
same bin dir. I do feel that version suffixes should be used only when
installing. Again, maybe I did a wrong configuration of cmake.


I would prefer that too, but it may be contrary to cmake philosophy.


Build-dir is not the same as Install-dir for tex2lyx


I only did `make`, not `make install`. So I think this must be the build
dir. Are you saying this is the install dir, hence the suffixes?


No, i was mixing install-prefix and program-suffix here. I was confused by to move 
the tex2lyx binary to a tex2lyx subdir


I have the binaries in
$LYX_SVN_ROOT/build-cmake/bin/lyx2.1
$LYX_SVN_ROOT/build-cmake/bin/tex2lyx2.1
Compare
$LYX_SVN_ROOT/build-autoconf/src/lyx
$LYX_SVN_ROOT/build-autoconf/src/tex2lyx/tex2lyx

I don't really feel like telling you guys to change your build systems.
Personally both of them feel wrong: I would say binaries would go in bin
dir and have no suffixes. In any case I could figure out a patch for
tex2lyx detection with the status quo in mind.


+1
In cmake it was originally to mimic autoconf behaviour (I think), and it is not 
difficult to adapt something else.
I am not sure if installing in autoconf does not add the suffix?



With autoconf, when you `make` you get binaries, without suffix, in the 
src/ subdir of the build dir (and in the case of tex2lyx, in the 
src/tex2lyx subsubdir). This is the finicky part for me.


When you `make install` these binaries are moved to the install dir with 
their suffix added. I think this is right. I presume cmake does the 
same. If that's right then it's only the `make` part that needs some 
changes on one side or the other to have them consistent.



I never use LYX_PACKAGE_SUFFIX, instead I use 
-DCMAKE_INSTALL_PREFIX=/usr/local/lyx2.1 in order to install
different versions simultaneously.

Kornel



If I don't use a version suffix, wouldn't that mean that my user 
directory is $HOME/.lyx for all of my installs?


--
Julien

(more on) document language changing

2011-09-11 Thread PhilipPirrip



When one chooses to change the global document language in the Document 
Settings dialog, can someone tell me why is the test being made (now in 
BufferView.cpp,  line 1905) on !buffer_.isMultiLingual().
I'm asking that because I'm trying to find *which other code* is 
responsible for changing the language if the buffer IS multilingual. 
What happens in that case is that all the text that had no explicitly 
marked language (!) gets marked as a foreign language (and the user 
might have just started with the wrong choice).
Even worse, the cursor is not updated, and it's impossible to start 
writing in the new language until a manual intervention is made (Text 
Style - language).



An example:

start a new document, main language is English, be default
write two words: Berlin Paris

Change the language of the first word to German (through Text Style).

Now the document is multilingual.

Change the language of the whole document (Document Settings) to, say, 
French (because you just realized that you didn't do that at the beginning)



Question 1:
The code in BufferView.cpp finds itself NOT responsible for changing the 
language, but which part of the code does then?


Question 2:
Why is the word Paris now marked as being in English (pure guess)?

Question 3:
Why can't one go to the end of the line and continue writing in French, 
i.e. why is the cursor still before \selectlanguage{French}

(this was fixed for monolingual documents in r7681)



In my opinion, changing the global document language should leave no 
trace in the text markup. Only manual changes of the language, not guesses!
Finally, shouldn't the changing of language be moved from the Text Style 
(i.e. fonts) to its own dialog.




I'd like to (learn to) fix this myself, but still lacking a lot of 
knowledge :(

Re: Output file-name when exporting from command-line.

2011-09-11 Thread Tommaso Cucinotta


Il 10/09/2011 01:39, Tommaso Cucinotta ha scritto:
However, graphics files are not copied, so the exported latex cannot 
compile unless you copy the additionally needed external files.


Independently on whether the output folder is explicitly provider or 
automatically inferred from an output filename, copying the files to the 
export folder seems not too difficult as well, like in the attached patch.


One note: I guess it's impossible for me to understand the whole logic 
behind these complex file name manipulations. I would largely prefer to 
leave this part to some expert of this area of the code.


T.

Index: src/LyX.cpp
===
--- src/LyX.cpp	(revisione 39654)
+++ src/LyX.cpp	(copia locale)
@@ -112,6 +112,9 @@
 
 string geometryArg;
 
+/// Output filename to be used when issuing an export request (-e).
+string output_file;
+
 LyX * singleton_ = 0;
 
 void showFileError(string const  error)
@@ -1054,6 +1057,9 @@
 		Look on Tools-Preferences-File formats-Format\n
 		to get an idea which parameters should be passed.\n
 		Note that the order of -e and -x switches matters.\n
+		  \t-E [--export-to] fmt filename\n
+		where fmt is the export format of choice (see --export),\n
+		and filename is the destination filename.\n
 		  \t-i [--import] fmt file.xxx\n
 		where fmt is the import format of choice\n
 		and file.xxx is the file to be imported.\n
@@ -1123,6 +1129,24 @@
 }
 
 
+int parse_export_to(string const  type, string const  output_file, string  batch)
+{
+	if (type.empty()) {
+		lyxerr  to_utf8(_(Missing file type [eg latex, ps...] after 
+	 --export-to switch))  endl;
+		exit(1);
+	}
+	if (output_file.empty()) {
+		lyxerr  to_utf8(_(Missing destination filename after 
+	 --export-to switch))  endl;
+		exit(1);
+	}
+	batch = buffer-export  + type +   + output_file;
+	use_gui = false;
+	return 2;
+}
+
+
 int parse_export(string const  type, string const , string  batch)
 {
 	if (type.empty()) {
@@ -1216,8 +1240,10 @@
 	cmdmap[-userdir] = parse_userdir;
 	cmdmap[-x] = parse_execute;
 	cmdmap[--execute] = parse_execute;
-	cmdmap[-e] = parse_export;
+ 	cmdmap[-e] = parse_export;
 	cmdmap[--export] = parse_export;
+	cmdmap[-E] = parse_export_to;
+	cmdmap[--export-to] = parse_export_to;
 	cmdmap[-i] = parse_import;
 	cmdmap[--import] = parse_import;
 	cmdmap[-geometry] = parse_geometry;
Index: src/Buffer.h
===
--- src/Buffer.h	(revisione 39654)
+++ src/Buffer.h	(copia locale)
@@ -602,11 +602,12 @@
 
 	
 
-	///
-	bool doExport(std::string const  format, bool put_in_tempdir,
+	/// target is a format name optionally followed by a space
+	/// and a destination file-name
+	bool doExport(std::string const  target, bool put_in_tempdir,
 		bool includeall, std::string  result_file) const;
 	///
-	bool doExport(std::string const  format, bool put_in_tempdir,
+	bool doExport(std::string const  target, bool put_in_tempdir,
 		  bool includeall = false) const;
 	///
 	bool preview(std::string const  format, bool includeall = false) const;
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revisione 39654)
+++ src/Buffer.cpp	(copia locale)
@@ -1928,10 +1928,18 @@
 
 		case LFUN_BUFFER_EXPORT: {
 			docstring const arg = cmd.argument();
-			enable = arg == custom || params().isExportable(to_utf8(arg));
+			if (arg == custom) {
+enable = true;
+break;
+			}
+			string format = to_utf8(arg);
+			size_t pos = format.find(' ');
+			if (pos != string::npos)
+format = format.substr(0, pos);
+			enable = params().isExportable(format);
 			if (!enable)
 flag.message(bformat(
-	_(Don't know how to export to format: %1$s), arg));
+	_(Don't know how to FUCK export to format: %1$s), arg));
 			break;
 		}
 
@@ -3391,12 +3399,20 @@
 }
 
 
-bool Buffer::doExport(string const  format, bool put_in_tempdir,
-	bool includeall, string  result_file) const
+bool Buffer::doExport(string const  target, bool put_in_tempdir,
+		  bool includeall, string  result_file) const
 {
+	OutputParams runparams(params().encoding());
+	string format = target;
+	string filename;
+	size_t pos = target.find(' ');
+	if (pos != string::npos) {
+		filename = target.substr(pos + 1, target.length() - pos - 1);
+		format = target.substr(0, pos);
+		runparams.export_folder = FileName(filename).onlyPath().realPath();
+	}
 	MarkAsExporting exporting(this);
 	string backend_format;
-	OutputParams runparams(params().encoding());
 	runparams.flavor = OutputParams::LATEX;
 	runparams.linelen = lyxrc.plaintext_linelen;
 	runparams.includeall = includeall;
@@ -3439,10 +3455,12 @@
 			runparams.flavor = OutputParams::XETEX;
 	}
 
-	string filename = latexName(false);
-	filename = addName(temppath(), filename);

Re: [patch] update and merge lyxpreview mechanisms

2011-09-11 Thread Julien Rioux


On 08/09/2011 6:15 PM, Julien Rioux wrote:

On 03/09/2011 9:30 PM, José Matos wrote:

On 09/02/2011 07:36 PM, Richard Heck wrote:

If extensibility isn't really an issue, then it's more a matter of
taste.

Richard


+1 :-)



Thanks for the feedback. Without further objections, I'll probably put
this into svn tomorrow or on the weekend.



It's in.

One neat feature now is you can customize the lyxpreview-latex 
converter by adding your own flags. A useful one is -v for verbose, 
which will show the progress on the terminal. You can see for the math 
manual that a lot of time is spent running ghostcript on individual files.


The attached patch further simplifies the color handling in lyxpreview. 
I find that I can remove all the \ifpdf etc. The only distinction now is 
between either we run dvipng, which doesn't need the color info in the 
latex file, or we run ghostscript, which does it. Any reason to keep 
those \ifpdf etc. around, i.e. were these used for something else 
besides the color handling?


--
Julien
diff --git a/lib/scripts/legacy_lyxpreview2ppm.py b/lib/scripts/legacy_lyxpreview2ppm.py
index 86d9b17..604c7d5 100644
--- a/lib/scripts/legacy_lyxpreview2ppm.py
+++ b/lib/scripts/legacy_lyxpreview2ppm.py
@@ -194,42 +194,45 @@ def extract_resolution(log_file, dpi):
 return dpi * (10.0 / fontsize) * (1000.0 / magnification)
 
 
-def legacy_latex_file(latex_file, fg_color, bg_color, bg_color_gr):
-use_preview_dvi_re = re.compile((\s*usepackage\[[^]]+)(dvips\]{preview}))
-use_preview_pdf_re = re.compile((\s*usepackage\[[^]]+)(pdftex\]{preview}))
+def legacy_latex_file(latex_file, fg_color, bg_color):
+use_preview_re = re.compile(r\s*\\usepackage\[([^]]+)\]{preview})
+fg_color_gr = make_texcolor(fg_color, True)
+bg_color_gr = make_texcolor(bg_color, True)
 
 tmp = mkstemp()
 
 success = 0
 try:
-for line in open(latex_file, 'r').readlines():
-match = use_preview_dvi_re.match(line)
-if match == None:
-match = use_preview_pdf_re.match(line)
-if match == None:
-tmp.write(line)
-continue
-success = 1
-tmp.write(  \\usepackage{color}\n \
-\\pagecolor[rgb]{%s}\n \
-  %s\n \
-  % (bg_color_gr, match.group()))
-continue
-
-success = 1
-tmp.write(%stightpage,%s\n \
-\\AtBeginDocument{\\AtBeginDvi{%%\n \
-\\special{!userdict begin/bop-hook{//bop-hook exec\n \
-%s%s{255 div}forall setrgbcolor\n \
-clippath fill setrgbcolor}bind def end}}}\n \
-  % (match.group(1), match.group(2), fg_color, bg_color))
-
+f = open(latex_file, 'r')
 except:
 # Unable to open the file, but do nothing here because
 # the calling function will act on the value of 'success'.
 warning('Warning in legacy_latex_file! Unable to open %s' % latex_file)
 warning(`sys.exc_type` + ',' + `sys.exc_value`)
 
+for line in f.readlines():
+if success:
+tmp.write(line)
+continue
+match = use_preview_re.match(line)
+if match == None:
+tmp.write(line)
+continue
+success = 1
+# Package order: color should be loaded before preview
+# Preview options: add the options lyx and tightpage
+tmp.write(r
+\usepackage{color}
+\definecolor{fg}{rgb}{%s}
+\definecolor{bg}{rgb}{%s}
+\pagecolor{bg}
+\usepackage[%s,lyx,tightpage]{preview}
+\makeatletter
+\g@addto@macro\preview{\begingroup\color{bg}\special{ps::clippath fill}\color{fg}}
+\g@addto@macro\endpreview{\endgroup}
+\makeatother
+ % (fg_color_gr, bg_color_gr, match.group(1)))
+
 if success:
 copyfileobj(tmp, open(latex_file,wb), 1)
 
@@ -284,10 +287,10 @@ def legacy_conversion(argv, skipMetrics = False):
 def legacy_conversion_step1(latex_file, dpi, output_format, fg_color, bg_color,
 latex, pdf_output = False, skipMetrics = False):
 
-# Move color information into the latex file.
-bg_color_gr = make_texcolor(bg_color, True)
-if not legacy_latex_file(latex_file, fg_color, bg_color, bg_color_gr):
-error(Unable to move color info into the latex file)
+# Move color information, lyx and tightpage options into the latex file.
+if not legacy_latex_file(latex_file, fg_color, bg_color):
+error(Unable to move the color information, and the lyx and tightpage
+options of preview-latex, into the latex file)
 
 # Compile the latex file.
 latex_call = '%s %s' % (latex, latex_file)
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 674c33e..398d7fb 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -153,42 +153,6 @@

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

2011-09-11 Thread Richard Heck

On 09/11/2011 03:38 PM, alexandre.depou...@ulg.ac.be wrote:
 Hi all, 

 I have tried to install LyX 2.0.0  2.0.1 several times on my Ubuntu-run 
 laptop ... without success. After apparently successfully compiling, LyX 
 spits out the following error when launched:

 lyx: symbol lookup error: lyx: undefined symbol: 
 _ZN9QListData11detach_growEPii 

 A quick browse on the internet established a link between this error and the 
 Qt 4 Frontend libraries as similar errors have been reported for other 
 programs. I have nonetheless not been able to find a solution when it comes 
 to dealing with LyX.

 Any help will be welcome. I attach:
  - config.log: the log file of the ./configure command;
  - configure.log: the output to stdout of the ./configure command;
  - make.log: the output to stdout of the make all command.

None of those came through.

What version of Qt are you trying to use here?

Richard

PS I'm cross-posting to lyx-devel, which is probably a better bet.

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

2011-09-11 Thread Vincent van Ravesteijn


Op 11-9-2011 22:06, Richard Heck schreef:

On 09/11/2011 03:38 PM, alexandre.depou...@ulg.ac.be wrote:

Hi all,

I have tried to install LyX 2.0.0  2.0.1 several times on my Ubuntu-run laptop 
... without success. After apparently successfully compiling, LyX spits out the 
following error when launched:

lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

A quick browse on the internet established a link between this error and the Qt 
4 Frontend libraries as similar errors have been reported for other programs. I 
have nonetheless not been able to find a solution when it comes to dealing with 
LyX.

Any help will be welcome. I attach:
  - config.log: the log file of the ./configure command;
  - configure.log: the output to stdout of the ./configure command;
  - make.log: the output to stdout of the make all command.


None of those came through.

What version of Qt are you trying to use here?

Richard

PS I'm cross-posting to lyx-devel, which is probably a better bet.


It looks like you're trying to run lyx with a different version of Qt 
than the one which you used during building.


Vincent

Re: drag in outline panel?

2011-09-11 Thread Xu Wang

exactly what I was looking for, thanks! I'm guessing if there hasn't been
much movement in 3 years then I'm out of luck. Oh well.

On Sun, Sep 11, 2011 at 4:42 AM, Jürgen Spitzmüller sp...@lyx.org wrote:

 Xu Wang wrote:
  bump

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

 Jürgen

Crash while editing table

2011-09-11 Thread J. Gardner

I'm guessing this is a useless bug report since I was working
furiously when this happened and I'm not sure what exact operation I
was doing when I experienced the crash. Just in case the console
report is of any diagnostic use, I thought I'd forward it to the
developer's list. This was using 2.0.1 on OS X 10.6.8. While the crash
happened I was editing a complicated table containing inline equations
and a lot of merged cells. I think I was either pasting (using ctrl-v)
a column or using undo. Stupidly, the doc wasn't saved, otherwise I'd
attach it.


rocess: lyx [38874]
Path:/Applications/LyX.app/Contents/MacOS/lyx
Identifier:  org.lyx.lyx
Version: 2.0.1 (???)
Code Type:   X86 (Native)
Parent Process:  launchd [93]

Date/Time:   2011-09-06 20:35:26.886 -0400
OS Version:  Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:  40365 sec
Crashes Since Last Report:   1
Per-App Interval Since Last Report:  8411 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:  3CF72956-77A4-4C1D-9E7E-40B97B46AAA8

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0030
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.lyx.lyx 0x000aa505
lyx::DocIterator::inMathed() const + 27
1   org.lyx.lyx 0x000a99ce
std::maplyx::support::FileName, lyx::DepTable::dep_info,
std::lesslyx::support::FileName,
std::allocatorstd::pairlyx::support::FileName const,
lyx::DepTable::dep_info  ::operator[](lyx::support::FileName
const) + 4152
2   org.lyx.lyx 0x0009ab4a
std::mapstd::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t , lyx::Counter,
std::lessstd::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t  ,
std::allocatorstd::pairstd::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t  const,
lyx::Counter  ::operator[](std::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t  const) + 10898
3   org.lyx.lyx 0x0009c199
std::mapstd::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t , lyx::Counter,
std::lessstd::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t  ,
std::allocatorstd::pairstd::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t  const,
lyx::Counter  ::operator[](std::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t  const) + 16609
4   org.lyx.lyx 0x00079c14
lyx::Translatorstd::string,
lyx::InsetQuotes::QuoteLanguage::addPair(std::string const,
lyx::InsetQuotes::QuoteLanguage const) + 36352
5   org.lyx.lyx 0x00461d6e
QListlyx::frontend::Action*::operator[](int) + 6674
6   org.lyx.lyx 0x00473ca5
QListlyx::frontend::Action*::operator[](int) + 80201
7   org.lyx.lyx 0x00311dae
lyx::frontend::InGuiThreadint::~InGuiThread() + 58328
8   org.lyx.lyx 0x0030d34b
lyx::frontend::InGuiThreadint::~InGuiThread() + 39285
9   org.lyx.lyx 0x000f3911 lyx::Lexer::Pimpl::~Pimpl() 
+ 1463
10  org.lyx.lyx 0x0030c73c
lyx::frontend::InGuiThreadint::~InGuiThread() + 36198
11  org.lyx.lyx 0x00487167
Ui_VSpaceUi::setupUi(QWidget*) + 25825
12  QtGui   0x00ebf621 QWidget::event(QEvent*) + 
2417
13  QtGui   0x011dfb38 QFrame::event(QEvent*) + 40
14  QtGui   0x0125bad2
QAbstractScrollArea::event(QEvent*) + 130
15  org.lyx.lyx 0x004890fe
Ui_VSpaceUi::setupUi(QWidget*) + 33912
16  QtGui   0x00e71e1c
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 188
17  QtGui   0x00e7afa3
QApplication::notify(QObject*, QEvent*) + 5715
18  org.lyx.lyx 0x0030e69d
lyx::frontend::InGuiThreadint::~InGuiThread() + 44231
19  QtCore  0x00c21c9c
QCoreApplication::notifyInternal(QObject*, QEvent*) + 108
20  QtGui   0x00e7227c
qt_sendSpontaneousEvent(QObject*, QEvent*) + 60
21  QtGui   0x00edb127
QKeyMapper::sendKeyEvent(QWidget*, bool, QEvent::Type, int,
QFlagsQt::KeyboardModifier, QString const, bool, int, unsigned int,
unsigned int, unsigned int, bool*) + 167
22  QtGui   0x00edc338
QKeyMapperPrivate::translateKeyEvent(QWidget*,
OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, bool) + 744
23  QtGui   0x00e147a8
QApplicationPrivate::globalEventProcessor(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) + 2888
24  com.apple.HIToolbox 0x91228c2f
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,

Re: [patch] update and merge lyxpreview mechanisms

2011-09-11 Thread Jürgen Spitzmüller

Julien Rioux wrote:
 Any reason to keep 
 those \ifpdf etc. around, i.e. were these used for something else 
 besides the color handling?

We used it to pass the correct driver (pdftex,dvips,xetex) to preview-latex. 
You should check the package's manual if/why this is necessary.

Jürgen

Re: drag in outline panel?

2011-09-11 Thread Jürgen Spitzmüller

Xu Wang wrote:
> bump

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

Jürgen

Re: autoconf vs cmake vs scons

2011-09-11 Thread Kornel

Am Sonntag, 11. September 2011 schrieb Julien Rioux:
> On 10/09/2011 1:07 PM, Kornel wrote:
...
> >>> I'm not sure whether I prefer cmake to move the tex2lyx
> >>> binary to a tex2lyx subdir, or autoconf to move all binaries to the
> >>> same bin dir. I do feel that version suffixes should be used only when
> >>> installing. Again, maybe I did a wrong configuration of cmake.
> >> 
> >> I would prefer that too, but it may be contrary to cmake philosophy.
> > 
> > Build-dir is not the same as Install-dir for tex2lyx
> 
> I only did `make`, not `make install`. So I think this must be the build
> dir. Are you saying this is the install dir, hence the suffixes?

No, i was mixing install-prefix and program-suffix here. I was confused by "to 
move the tex2lyx binary to a tex2lyx subdir"

> I have the binaries in
> $LYX_SVN_ROOT/build-cmake/bin/lyx2.1
> $LYX_SVN_ROOT/build-cmake/bin/tex2lyx2.1
> Compare
> $LYX_SVN_ROOT/build-autoconf/src/lyx
> $LYX_SVN_ROOT/build-autoconf/src/tex2lyx/tex2lyx
> 
> I don't really feel like telling you guys to change your build systems.
> Personally both of them feel wrong: I would say binaries would go in bin
> dir and have no suffixes. In any case I could figure out a patch for
> tex2lyx detection with the status quo in mind.

+1
In cmake it was originally to mimic autoconf behaviour (I think), and it is not 
difficult to adapt something else.
I am not sure if installing in autoconf does not add the suffix?

I never use LYX_PACKAGE_SUFFIX, instead I use 
-DCMAKE_INSTALL_PREFIX=/usr/local/lyx2.1 in order to install
different versions simultaneously.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: autoconf vs cmake vs scons

2011-09-11 Thread Julien Rioux


On 11/09/2011 12:02 PM, Kornel wrote:

Am Sonntag, 11. September 2011 schrieb Julien Rioux:

On 10/09/2011 1:07 PM, Kornel wrote:

...

I'm not sure whether I prefer cmake to move the tex2lyx
binary to a tex2lyx subdir, or autoconf to move all binaries to the
same bin dir. I do feel that version suffixes should be used only when
installing. Again, maybe I did a wrong configuration of cmake.


I would prefer that too, but it may be contrary to cmake philosophy.


Build-dir is not the same as Install-dir for tex2lyx


I only did `make`, not `make install`. So I think this must be the build
dir. Are you saying this is the install dir, hence the suffixes?


No, i was mixing install-prefix and program-suffix here. I was confused by "to move 
the tex2lyx binary to a tex2lyx subdir"


I have the binaries in
$LYX_SVN_ROOT/build-cmake/bin/lyx2.1
$LYX_SVN_ROOT/build-cmake/bin/tex2lyx2.1
Compare
$LYX_SVN_ROOT/build-autoconf/src/lyx
$LYX_SVN_ROOT/build-autoconf/src/tex2lyx/tex2lyx

I don't really feel like telling you guys to change your build systems.
Personally both of them feel wrong: I would say binaries would go in bin
dir and have no suffixes. In any case I could figure out a patch for
tex2lyx detection with the status quo in mind.


+1
In cmake it was originally to mimic autoconf behaviour (I think), and it is not 
difficult to adapt something else.
I am not sure if installing in autoconf does not add the suffix?



With autoconf, when you `make` you get binaries, without suffix, in the 
src/ subdir of the build dir (and in the case of tex2lyx, in the 
src/tex2lyx subsubdir). This is the finicky part for me.


When you `make install` these binaries are moved to the install dir with 
their suffix added. I think this is right. I presume cmake does the 
same. If that's right then it's only the `make` part that needs some 
changes on one side or the other to have them consistent.



I never use LYX_PACKAGE_SUFFIX, instead I use 
-DCMAKE_INSTALL_PREFIX=/usr/local/lyx2.1 in order to install
different versions simultaneously.

Kornel



If I don't use a version suffix, wouldn't that mean that my user 
directory is $HOME/.lyx for all of my installs?


--
Julien

(more on) document language changing

2011-09-11 Thread PhilipPirrip



When one chooses to change the global document language in the Document 
Settings dialog, can someone tell me why is the test being made (now in 
BufferView.cpp,  line 1905) on !buffer_.isMultiLingual().
I'm asking that because I'm trying to find *which other code* is 
responsible for changing the language if the buffer IS multilingual. 
What happens in that case is that all the text that had no explicitly 
marked language (!) gets marked as a foreign language (and the user 
might have just started with the wrong choice).
Even worse, the cursor is not updated, and it's impossible to start 
writing in the new language until a manual intervention is made (Text 
Style -> language).



An example:

start a new document, main language is English, be default
write two words: Berlin Paris

Change the language of the first word to German (through Text Style).

Now the document is multilingual.

Change the language of the whole document (Document Settings) to, say, 
French (because you just realized that you didn't do that at the beginning)



Question 1:
The code in BufferView.cpp finds itself NOT responsible for changing the 
language, but which part of the code does then?


Question 2:
Why is the word Paris now marked as being in English (pure guess)?

Question 3:
Why can't one go to the end of the line and continue writing in French, 
i.e. why is the cursor still before \selectlanguage{French}

(this was fixed for monolingual documents in r7681)



In my opinion, changing the global document language should leave no 
trace in the text markup. Only manual changes of the language, not guesses!
Finally, shouldn't the changing of language be moved from the Text Style 
(i.e. fonts) to its own dialog.




I'd like to (learn to) fix this myself, but still lacking a lot of 
knowledge :(

Re: Output file-name when exporting from command-line.

2011-09-11 Thread Tommaso Cucinotta


Il 10/09/2011 01:39, Tommaso Cucinotta ha scritto:
However, graphics files are not copied, so the exported latex cannot 
compile unless you copy the additionally needed external files.


Independently on whether the output folder is explicitly provider or 
automatically inferred from an output filename, copying the files to the 
export folder seems not too difficult as well, like in the attached patch.


One note: I guess it's impossible for me to understand the whole logic 
behind these complex file name manipulations. I would largely prefer to 
leave this part to some expert of this area of the code.


T.

Index: src/LyX.cpp
===
--- src/LyX.cpp	(revisione 39654)
+++ src/LyX.cpp	(copia locale)
@@ -112,6 +112,9 @@
 
 string geometryArg;
 
+/// Output filename to be used when issuing an export request (-e).
+string output_file;
+
 LyX * singleton_ = 0;
 
 void showFileError(string const & error)
@@ -1054,6 +1057,9 @@
 		  "  Look on Tools->Preferences->File formats->Format\n"
 		  "  to get an idea which parameters should be passed.\n"
 		  "  Note that the order of -e and -x switches matters.\n"
+		  "\t-E [--export-to] fmt filename\n"
+		  "  where fmt is the export format of choice (see --export),\n"
+		  "  and filename is the destination filename.\n"
 		  "\t-i [--import] fmt file.xxx\n"
 		  "  where fmt is the import format of choice\n"
 		  "  and file.xxx is the file to be imported.\n"
@@ -1123,6 +1129,24 @@
 }
 
 
+int parse_export_to(string const & type, string const & output_file, string & batch)
+{
+	if (type.empty()) {
+		lyxerr << to_utf8(_("Missing file type [eg latex, ps...] after "
+	 "--export-to switch")) << endl;
+		exit(1);
+	}
+	if (output_file.empty()) {
+		lyxerr << to_utf8(_("Missing destination filename after "
+	 "--export-to switch")) << endl;
+		exit(1);
+	}
+	batch = "buffer-export " + type + " " + output_file;
+	use_gui = false;
+	return 2;
+}
+
+
 int parse_export(string const & type, string const &, string & batch)
 {
 	if (type.empty()) {
@@ -1216,8 +1240,10 @@
 	cmdmap["-userdir"] = parse_userdir;
 	cmdmap["-x"] = parse_execute;
 	cmdmap["--execute"] = parse_execute;
-	cmdmap["-e"] = parse_export;
+ 	cmdmap["-e"] = parse_export;
 	cmdmap["--export"] = parse_export;
+	cmdmap["-E"] = parse_export_to;
+	cmdmap["--export-to"] = parse_export_to;
 	cmdmap["-i"] = parse_import;
 	cmdmap["--import"] = parse_import;
 	cmdmap["-geometry"] = parse_geometry;
Index: src/Buffer.h
===
--- src/Buffer.h	(revisione 39654)
+++ src/Buffer.h	(copia locale)
@@ -602,11 +602,12 @@
 
 	
 
-	///
-	bool doExport(std::string const & format, bool put_in_tempdir,
+	/// target is a format name optionally followed by a space
+	/// and a destination file-name
+	bool doExport(std::string const & target, bool put_in_tempdir,
 		bool includeall, std::string & result_file) const;
 	///
-	bool doExport(std::string const & format, bool put_in_tempdir,
+	bool doExport(std::string const & target, bool put_in_tempdir,
 		  bool includeall = false) const;
 	///
 	bool preview(std::string const & format, bool includeall = false) const;
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revisione 39654)
+++ src/Buffer.cpp	(copia locale)
@@ -1928,10 +1928,18 @@
 
 		case LFUN_BUFFER_EXPORT: {
 			docstring const arg = cmd.argument();
-			enable = arg == "custom" || params().isExportable(to_utf8(arg));
+			if (arg == "custom") {
+enable = true;
+break;
+			}
+			string format = to_utf8(arg);
+			size_t pos = format.find(' ');
+			if (pos != string::npos)
+format = format.substr(0, pos);
+			enable = params().isExportable(format);
 			if (!enable)
 flag.message(bformat(
-	_("Don't know how to export to format: %1$s"), arg));
+	_("Don't know how to FUCK export to format: %1$s"), arg));
 			break;
 		}
 
@@ -3391,12 +3399,20 @@
 }
 
 
-bool Buffer::doExport(string const & format, bool put_in_tempdir,
-	bool includeall, string & result_file) const
+bool Buffer::doExport(string const & target, bool put_in_tempdir,
+		  bool includeall, string & result_file) const
 {
+	OutputParams runparams(().encoding());
+	string format = target;
+	string filename;
+	size_t pos = target.find(' ');
+	if (pos != string::npos) {
+		filename = target.substr(pos + 1, target.length() - pos - 1);
+		format = target.substr(0, pos);
+		runparams.export_folder = FileName(filename).onlyPath().realPath();
+	}
 	MarkAsExporting exporting(this);
 	string backend_format;
-	OutputParams runparams(().encoding());
 	runparams.flavor = OutputParams::LATEX;
 	runparams.linelen = lyxrc.plaintext_linelen;
 	runparams.includeall = includeall;
@@ -3439,10 +3455,12 @@
 			runparams.flavor = OutputParams::XETEX;
 	}
 
-

Re: [patch] update and merge lyxpreview mechanisms

2011-09-11 Thread Julien Rioux


On 08/09/2011 6:15 PM, Julien Rioux wrote:

On 03/09/2011 9:30 PM, José Matos wrote:

On 09/02/2011 07:36 PM, Richard Heck wrote:

If extensibility isn't really an issue, then it's more a matter of
taste.

Richard


+1 :-)



Thanks for the feedback. Without further objections, I'll probably put
this into svn tomorrow or on the weekend.



It's in.

One neat feature now is you can customize the lyxpreview->latex 
converter by adding your own flags. A useful one is -v for verbose, 
which will show the progress on the terminal. You can see for the math 
manual that a lot of time is spent running ghostcript on individual files.


The attached patch further simplifies the color handling in lyxpreview. 
I find that I can remove all the \ifpdf etc. The only distinction now is 
between either we run dvipng, which doesn't need the color info in the 
latex file, or we run ghostscript, which does it. Any reason to keep 
those \ifpdf etc. around, i.e. were these used for something else 
besides the color handling?


--
Julien
diff --git a/lib/scripts/legacy_lyxpreview2ppm.py b/lib/scripts/legacy_lyxpreview2ppm.py
index 86d9b17..604c7d5 100644
--- a/lib/scripts/legacy_lyxpreview2ppm.py
+++ b/lib/scripts/legacy_lyxpreview2ppm.py
@@ -194,42 +194,45 @@ def extract_resolution(log_file, dpi):
 return dpi * (10.0 / fontsize) * (1000.0 / magnification)
 
 
-def legacy_latex_file(latex_file, fg_color, bg_color, bg_color_gr):
-use_preview_dvi_re = re.compile("(\s*usepackage\[[^]]+)(dvips\]{preview})")
-use_preview_pdf_re = re.compile("(\s*usepackage\[[^]]+)(pdftex\]{preview})")
+def legacy_latex_file(latex_file, fg_color, bg_color):
+use_preview_re = re.compile(r"\s*\\usepackage\[([^]]+)\]{preview}")
+fg_color_gr = make_texcolor(fg_color, True)
+bg_color_gr = make_texcolor(bg_color, True)
 
 tmp = mkstemp()
 
 success = 0
 try:
-for line in open(latex_file, 'r').readlines():
-match = use_preview_dvi_re.match(line)
-if match == None:
-match = use_preview_pdf_re.match(line)
-if match == None:
-tmp.write(line)
-continue
-success = 1
-tmp.write("  \\usepackage{color}\n" \
-  "  \\pagecolor[rgb]{%s}\n" \
-  "%s\n" \
-  % (bg_color_gr, match.group()))
-continue
-
-success = 1
-tmp.write("%stightpage,%s\n" \
-  "  \\AtBeginDocument{\\AtBeginDvi{%%\n" \
-  "  \\special{!userdict begin/bop-hook{//bop-hook exec\n" \
-  "  <%s%s>{255 div}forall setrgbcolor\n" \
-  "  clippath fill setrgbcolor}bind def end}}}\n" \
-  % (match.group(1), match.group(2), fg_color, bg_color))
-
+f = open(latex_file, 'r')
 except:
 # Unable to open the file, but do nothing here because
 # the calling function will act on the value of 'success'.
 warning('Warning in legacy_latex_file! Unable to open "%s"' % latex_file)
 warning(`sys.exc_type` + ',' + `sys.exc_value`)
 
+for line in f.readlines():
+if success:
+tmp.write(line)
+continue
+match = use_preview_re.match(line)
+if match == None:
+tmp.write(line)
+continue
+success = 1
+# Package order: color should be loaded before preview
+# Preview options: add the options lyx and tightpage
+tmp.write(r"""
+\usepackage{color}
+\definecolor{fg}{rgb}{%s}
+\definecolor{bg}{rgb}{%s}
+\pagecolor{bg}
+\usepackage[%s,lyx,tightpage]{preview}
+\makeatletter
+\g@addto@macro\preview{\begingroup\color{bg}\special{ps::clippath fill}\color{fg}}
+\g@addto@macro\endpreview{\endgroup}
+\makeatother
+""" % (fg_color_gr, bg_color_gr, match.group(1)))
+
 if success:
 copyfileobj(tmp, open(latex_file,"wb"), 1)
 
@@ -284,10 +287,10 @@ def legacy_conversion(argv, skipMetrics = False):
 def legacy_conversion_step1(latex_file, dpi, output_format, fg_color, bg_color,
 latex, pdf_output = False, skipMetrics = False):
 
-# Move color information into the latex file.
-bg_color_gr = make_texcolor(bg_color, True)
-if not legacy_latex_file(latex_file, fg_color, bg_color, bg_color_gr):
-error("Unable to move color info into the latex file")
+# Move color information, lyx and tightpage options into the latex file.
+if not legacy_latex_file(latex_file, fg_color, bg_color):
+error("""Unable to move the color information, and the lyx and tightpage
+options of preview-latex, into the latex file""")
 
 # Compile the latex file.
 latex_call = '%s "%s"' % (latex, latex_file)
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 674c33e..398d7fb 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

2011-09-11 Thread Richard Heck

On 09/11/2011 03:38 PM, alexandre.depou...@ulg.ac.be wrote:
> Hi all, 
>
> I have tried to install LyX 2.0.0 & 2.0.1 several times on my Ubuntu-run 
> laptop ... without success. After apparently successfully compiling, LyX 
> spits out the following error when launched:
>
> lyx: symbol lookup error: lyx: undefined symbol: 
> _ZN9QListData11detach_growEPii 
>
> A quick browse on the internet established a link between this error and the 
> Qt 4 Frontend libraries as similar errors have been reported for other 
> programs. I have nonetheless not been able to find a solution when it comes 
> to dealing with LyX.
>
> Any help will be welcome. I attach:
>  - config.log: the log file of the ./configure command;
>  - configure.log: the output to stdout of the ./configure command;
>  - make.log: the output to stdout of the make all command.
>
None of those came through.

What version of Qt are you trying to use here?

Richard

PS I'm cross-posting to lyx-devel, which is probably a better bet.

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

2011-09-11 Thread Vincent van Ravesteijn


Op 11-9-2011 22:06, Richard Heck schreef:

On 09/11/2011 03:38 PM, alexandre.depou...@ulg.ac.be wrote:

Hi all,

I have tried to install LyX 2.0.0&  2.0.1 several times on my Ubuntu-run laptop 
... without success. After apparently successfully compiling, LyX spits out the 
following error when launched:

lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

A quick browse on the internet established a link between this error and the Qt 
4 Frontend libraries as similar errors have been reported for other programs. I 
have nonetheless not been able to find a solution when it comes to dealing with 
LyX.

Any help will be welcome. I attach:
  - config.log: the log file of the ./configure command;
  - configure.log: the output to stdout of the ./configure command;
  - make.log: the output to stdout of the make all command.


None of those came through.

What version of Qt are you trying to use here?

Richard

PS I'm cross-posting to lyx-devel, which is probably a better bet.


It looks like you're trying to run lyx with a different version of Qt 
than the one which you used during building.


Vincent

Re: drag in outline panel?

2011-09-11 Thread Xu Wang

exactly what I was looking for, thanks! I'm guessing if there hasn't been
much movement in 3 years then I'm out of luck. Oh well.

On Sun, Sep 11, 2011 at 4:42 AM, Jürgen Spitzmüller  wrote:

> Xu Wang wrote:
> > bump
>
> http://www.lyx.org/trac/ticket/5778
>
> Jürgen
>

Crash while editing table

2011-09-11 Thread J. Gardner

I'm guessing this is a useless bug report since I was working
furiously when this happened and I'm not sure what exact operation I
was doing when I experienced the crash. Just in case the console
report is of any diagnostic use, I thought I'd forward it to the
developer's list. This was using 2.0.1 on OS X 10.6.8. While the crash
happened I was editing a complicated table containing inline equations
and a lot of merged cells. I think I was either pasting (using ctrl-v)
a column or using undo. Stupidly, the doc wasn't saved, otherwise I'd
attach it.


rocess: lyx [38874]
Path:/Applications/LyX.app/Contents/MacOS/lyx
Identifier:  org.lyx.lyx
Version: 2.0.1 (???)
Code Type:   X86 (Native)
Parent Process:  launchd [93]

Date/Time:   2011-09-06 20:35:26.886 -0400
OS Version:  Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:  40365 sec
Crashes Since Last Report:   1
Per-App Interval Since Last Report:  8411 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:  3CF72956-77A4-4C1D-9E7E-40B97B46AAA8

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0030
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.lyx.lyx 0x000aa505
lyx::DocIterator::inMathed() const + 27
1   org.lyx.lyx 0x000a99ce
std::map >::operator[](lyx::support::FileName
const&) + 4152
2   org.lyx.lyx 0x0009ab4a
std::map, lyx::Counter,
std::less >,
std::allocator const,
lyx::Counter> > >::operator[](std::basic_string const&) + 10898
3   org.lyx.lyx 0x0009c199
std::map, lyx::Counter,
std::less >,
std::allocator const,
lyx::Counter> > >::operator[](std::basic_string const&) + 16609
4   org.lyx.lyx 0x00079c14
lyx::Translator::addPair(std::string const&,
lyx::InsetQuotes::QuoteLanguage const&) + 36352
5   org.lyx.lyx 0x00461d6e
QList::operator[](int) + 6674
6   org.lyx.lyx 0x00473ca5
QList::operator[](int) + 80201
7   org.lyx.lyx 0x00311dae
lyx::frontend::InGuiThread::~InGuiThread() + 58328
8   org.lyx.lyx 0x0030d34b
lyx::frontend::InGuiThread::~InGuiThread() + 39285
9   org.lyx.lyx 0x000f3911 lyx::Lexer::Pimpl::~Pimpl() 
+ 1463
10  org.lyx.lyx 0x0030c73c
lyx::frontend::InGuiThread::~InGuiThread() + 36198
11  org.lyx.lyx 0x00487167
Ui_VSpaceUi::setupUi(QWidget*) + 25825
12  QtGui   0x00ebf621 QWidget::event(QEvent*) + 
2417
13  QtGui   0x011dfb38 QFrame::event(QEvent*) + 40
14  QtGui   0x0125bad2
QAbstractScrollArea::event(QEvent*) + 130
15  org.lyx.lyx 0x004890fe
Ui_VSpaceUi::setupUi(QWidget*) + 33912
16  QtGui   0x00e71e1c
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 188
17  QtGui   0x00e7afa3
QApplication::notify(QObject*, QEvent*) + 5715
18  org.lyx.lyx 0x0030e69d
lyx::frontend::InGuiThread::~InGuiThread() + 44231
19  QtCore  0x00c21c9c
QCoreApplication::notifyInternal(QObject*, QEvent*) + 108
20  QtGui   0x00e7227c
qt_sendSpontaneousEvent(QObject*, QEvent*) + 60
21  QtGui   0x00edb127
QKeyMapper::sendKeyEvent(QWidget*, bool, QEvent::Type, int,
QFlags, QString const&, bool, int, unsigned int,
unsigned int, unsigned int, bool*) + 167
22  QtGui   0x00edc338
QKeyMapperPrivate::translateKeyEvent(QWidget*,
OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, bool) + 744
23  QtGui   0x00e147a8
QApplicationPrivate::globalEventProcessor(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) + 2888
24  com.apple.HIToolbox 0x91228c2f
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*) + 1567
25  com.apple.HIToolbox 0x91227ef6
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,
HandlerCallRec*) + 411
26

Re: [patch] update and merge lyxpreview mechanisms

2011-09-11 Thread Jürgen Spitzmüller

Julien Rioux wrote:
> Any reason to keep 
> those \ifpdf etc. around, i.e. were these used for something else 
> besides the color handling?

We used it to pass the correct driver (pdftex,dvips,xetex) to preview-latex. 
You should check the package's manual if/why this is necessary.

Jürgen

Re: drag in outline panel?

Re: autoconf vs cmake vs scons

Re: autoconf vs cmake vs scons

(more on) document language changing

Re: Output file-name when exporting from command-line.

Re: [patch] update and merge lyxpreview mechanisms

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

Re: drag in outline panel?

Crash while editing table

Re: [patch] update and merge lyxpreview mechanisms

Re: drag in outline panel?

Re: autoconf vs cmake vs scons

Re: autoconf vs cmake vs scons

(more on) document language changing

Re: Output file-name when exporting from command-line.

Re: [patch] update and merge lyxpreview mechanisms

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

Re: Cannot run LyX - lyx: symbol lookup error: lyx: undefined symbol: _ZN9QListData11detach_growEPii

Re: drag in outline panel?

Crash while editing table

Re: [patch] update and merge lyxpreview mechanisms

22 matches

Site Navigation

Mail list logo

Footer information